関連記事：カルダノのトランザクション検証に驚きはない：パート2
以下IOGのブログに掲載された記事「No-surprises transaction validation on Cardano」を翻訳したものです。
カルダノのトランザクション検証に驚きはない
カルダノのEUTXOモデルは、Plutusスクリプトの実行の決定性を可能にする
By Polina Vinogradova 2021年9月6日
はじめに
アロンゾ（Alonzo）ハードフォークにより、コアのPlutusスマートコントラクト機能がカルダノに導入されると、分散型ソリューションの展開に対するニーズの高まりに合わせて、台帳が進化します。カルダノの台帳設計は、高保証、セキュリティ、および実績のある形式的検証に焦点を当てています。この戦略に沿って、トランザクション処理が決定論的であること、つまり、ユーザーが実際に実行する前にその影響や結果を予測できることも重要です。
トランザクションの実行コストを保証し、トランザクションが元帳上でどのように振る舞うかを送信する前に保証する能力は、スマートコントラクトのサポートを導入することで、さらに顕著になります。カルダノのようなUTXO（Unspent Transaction Output）ベースのブロックチェーンは、このような機能を提供します。
イーサリアムのようなアカウントベースのブロックチェーンは、不確定性であるため、取引のオンチェーンでの効果の予測可能性を保証できません。そのため、金銭的損失のリスク、予測不可能な高額の手数料、敵対的な行動の機会が増えることになります。
このブログ記事では、実行前に安全なトランザクションとスクリプトの評価を可能にするカルダノの決定論的設計の利点を詳しく見ていきます。今週末に予定されている次のブログ記事では、Cardanoにおけるトランザクション検証の2つのフェーズについて説明します。
トランザクション決定論とは何か、なぜそれが重要なのか？
トランザクションとスクリプトの処理の文脈における決定性とは、予測可能性の同義語です。これは、ユーザーが自分のトランザクションがオンチェーンの元帳の状態にどのような影響を与えるかをローカル（オフチェーン）で予測できることを意味します。
- 予想外のスクリプト検証結果や失敗
- 予期せぬ手数料
- 予期せぬ元帳やスクリプトの状態の更新
決定論的なシステムでは、たとえ正しく構築されたとしても、トランザクションが拒否される可能性があります。拒否されるということは、そのトランザクションが元帳に全く適用されず、元帳の状態に影響を与えないため、手数料が支払われないということである。なぜこのようなことが起こるかというと、最初のトランザクションが構築されてから処理されるまでの間に、他のトランザクションによって元帳が変更されてしまうからです。これは、単純なトランザクションでも起こりえます。例えば、ユーザーが使う予定だったUTXOを別のトランザクションが使うかもしれない。決定論は、ある取引が受け入れられたときに、その取引が元帳の状態に予測可能な影響しか与えないことを保証する。
不確定性の問題への対応
不確定性とは、トランザクションが元帳にどのような影響を与えるかを、実行前に予測できないことを意味します。元帳やスマートコントラクトのインタープリタを設計する際には、不確定性が発生する可能性のある状況を予測し、それを回避するための設計上の判断が重要となります。このような場合の主な危険性の1つは、変更可能な台帳データへのアクセス、つまり変更や改ざんが可能なデータです。トランザクションやスマートコントラクトが台帳に加える変更が、トランザクションの内容だけでなく、処理時の状態に依存する場合、不確定性が問題となる可能性があります。
イーサリアムは特にこの問題の影響を受けやすい。例えば、ガス料金や分散型取引所（DEX）のレートは、ユーザーがトランザクションを送信してから処理されるまでの間に変動することがあります。その結果、予想外のガソリン代や、購入する資産の価格が変動することがあります。また、スクリプトが単純に失敗し、高い実行コスト（数百ドル）が発生するだけで、他の効果が得られない場合もあります。これは例えば、ガス料金を賄うために用意した資金が実行途中で尽きてしまった場合などに起こります。決定論的な台帳の設計は、このような可能性を排除します。
その他の不確定性の原因としては、スクリプトがトランザクションを含むブロックのデータを見ることができることが考えられます。
- トランザクションを含むブロック内のデータだが、どのトランザクションにも含まれていないデータ（例：システムランダム、ブロックヘッダ、現在のスロット番号）。
- トランザクション自体は処理可能であるが、スクリプトの検証結果を変える可能性がある、敵対者によって変更または置換されたデータ。
ほとんどのシステムでは、スクリプトの書き方の改善やレイヤー2のソリューションにより、これらの問題を軽減する方法があります。カルダノは、すべてのスクリプトとトランザクションについて予測可能な結果を保証するように設計されています。
基本的なUTXOモデルが決定性の面でどのようなメリットをもたらすか
カルダノの台帳はUTXO会計モデルに基づいて構築されています。これは、資産がアカウントではなく、未使用のアウトプットで台帳に保存されることを意味します。これらの出力はそれぞれ、そこに保管されている資産の量と、そのアドレスを指定します。未使用の出力は不変であるため、トランザクションが出力全体を消費することはあっても、それを変更することはできません。
資産を転送するために、トランザクションは1つまたは複数の出力を消費し、新しい出力を作成する。これらの量およびUTXOアドレスは、取引の出力で指定されます。トランザクションが、元帳に適用された別のトランザクションの効果に影響を与える唯一の方法は、 後のトランザクションが消費しようとするのと同じUTXOを消費することであり、その結果、ノードはそれを拒否する。これは、UTXOモデルが決定性を維持するための重要な特徴です。
UTXO台帳には、アカウントベースのモデルと比較して、利点と欠点の両方があります。たとえば、UTXOモデルでは、取引が互いにブロックされるケースが少ない。UTXOとは異なり、アカウントは変更可能な元帳データである。そのため、あるトランザクションが、同じアカウントを更新する別のトランザクションの前に処理されたか後に処理されたかによって、例えば、アカウント内の資産の量が異なる可能性がある。このような状況では、取引が拒否されることはないかもしれませんが、元帳に異なる（予測できない）変更が生じる可能性があります。
UTXOを使用することは、トランザクションが取ることのできるアクションの一例です。次に、トランザクションアクションとは何か、そしてそれをどのように検証するのかについて説明します。アロンゾ（Alonzo）で導入された最も重要な変更点は、アクションの検証プロセスの変更です。
署名とスクリプトによるアクションの検証
トランザクションを処理する上で重要なことは、そのトランザクションが行うアクションを検証することです。トランザクションは、そのアクションの特定のフィールドにデータが含まれているときに、そのアクションを実行していることになります。例えば、入力フィールドにUへの参照が含まれていれば、トランザクションはUTXO Uを消費しており、ミント・フィールドにXが含まれていれば、トークンXを鋳造していることになります。
ノードがトランザクションを処理する際には、それが意図するアクションを実行できるかどうかを検証します。このためには、トランザクションの作成者が関連するデータ（スクリプト、換金者、署名など）を提供しなければならない。検証が必要なアクションの一般的な例は、公開鍵でロックされたUTXOを使うことである。トランザクションは、このアクションを実行するために、対応する秘密鍵からの署名を提供する必要があります。
カルダノはアクションを検証するためにスクリプトを使用します。コードの一部であるこれらのスクリプトは、TrueまたはFalseの出力を持つ純粋な関数を実装しています。スクリプトの検証とは、スクリプト インタープリタを起動して、適切な引数で指定されたスクリプトを実行するプロセスのことです。
スクリプトの検証は、以下のアクションに対して行うことができます。
- スクリプトのアドレスでロックされたUTXOを消費する：実行されるスクリプトは、ハッシュがアドレスを形成しているものである。
- トークンの鋳造：鋳造されるトークンのポリシーIDをハッシュで表したスクリプトが実行されます。
- リワードの引き出し：実行されるスクリプトは、ハッシュがステーキングアドレスを形成するものです。
- 証明書の適用：実行されるスクリプトは、ハッシュが証明書作成者のクレデンシャルを形成するものです。
すべてのトランザクションアクションは、ノードにどのスクリプトを実行するかを知らせるだけでなく、そのスクリプトに渡された引数をどのように組み立てるかを示しています。
カルダノのマルチアセット台帳（Mary）は、シンプルなマルチシグとタイムロックのスクリプト言語をサポートしています。これらにより、ユーザーはアクション（UTXOの消費やNFT[Non-fungible token]の鋳造など）を実行するために必要な署名と、それを実行できる時間間隔を指定することができます。timelockスクリプトは、それを含むトランザクションの実際のスロット番号を見ることはできません。timelockは、運ぶトランザクションの有効期間のみを見ることができます。タイムロックスクリプトに現在のスロット番号（つまり、作者ではなくブロックから来るデータ）を見られるようにすると、決定論が破られてしまいます。これは、ユーザーがトランザクションが処理される正確なスロットを知ることができないため、スクリプトがどのように振る舞うかを予測することができないという事実によって保証されています。
メアリー（Mary）スクリプトは、アロンゾ（Alonzo）のPlutusコントラクトとは異なり、表現できる内容が非常に限られています。アロンゾ（Alonzo）のハードフォークにより、決定論的台帳の特性を損なうことのない、強力でステートフルなコントラクトの新時代が到来しました。
Plutusスクリプト
アロンゾ（Alonzo）では、Plutusスクリプトの実装により、カルダノのトランザクション検証に新しいアプローチを導入しています。アロンゾの一部として導入された拡張未使用トランザクション出力（EUTXO）モデルは、Plutusコントラクトをサポートするための元帳インフラを提供します。以下では、元帳と取引の変更点について、ハイレベルな概要を説明します。元帳やPlutusスクリプトの詳細については、Plutus Pioneerプログラムをご覧ください。
アロンゾは、元帳のデータを以下のように変更します。
- PlutusのスクリプトでUTXOをロックできるようになりました。
- UTXOの出力部分の内容に追加された新しいコンポーネントにより、スクリプトの状態のような機能が可能になりました。PlutusスクリプトによってロックされたUTXOは、アセットとアドレスに加えて、データムを含見ます。データムとは、スクリプトの状態を解釈したものと考えられるデータのことでです。
- トランザクションに追加の検証要件を課すために使用される新しいプロトコルパラメータが多数あります。これらのパラメータには、スクリプトが消費できる計算リソースの上限が含まれています。
Plutusスクリプトをサポートするために、トランザクションは以下のようにアップグレードされました。
- トランザクションは、そのアクションごとに、リディーマーと呼ばれるユーザーが指定した引数を持つようになりました。スクリプトに応じて、リダイマーは異なる目的を果たすことができます。例えば、オークションでのユーザーの入札や、推理ゲームでのユーザーの推測など、様々な役割を果たすことができます。
- トランザクションでは、各スクリプトの計算実行バジェットを指定します。
- トランザクションがその実行料を確実に支払えるようにするために、アロンゾ（Alonzo）は追加のデータを導入します。
- トランザクションには整合性ハッシュが含まれており、それが侵害されていないこと、古くなっていないことなどを確認するために必要です。
また、アロンゾ（Alonzo）のトランザクション検証の仕様には、メアリー（Mary）と比較していくつかの変更点があります。各アクションについて、ノードはPlutusインタプリタが期待する以下のようなスクリプト引数を組み立てます。
- the datum：データム（付与する）
- the redeemer：救済者
- execution budget：実行予算
- a summary of the transaction.：トランザクションのサマリー
このノードは、トランザクションが正しく構築されていることを確認するために、新たにアロンゾ固有のチェックを行います。例えば、最大実行リソースバジェットを超えてはならない。また、Plutusスクリプト＊インタプリタを起動してスクリプトを実行します。
＊インタプリタとは 「通訳者」の意味。 ソースコードを1命令ずつ解釈して実行するプログラムを指す。
データムオブジェクトとスクリプトの状態
変更可能なアカウントと同様に、変更可能なスクリプト状態は、不確定性の原因である「変更可能な元帳データ」の範疇に入ります。UTXOモデルでは、変更可能なアカウントの不確定性の問題を回避できることをすでに説明しました。また、決定性を維持する方法で、スクリプト状態の概念を再考することもできます。UTXOがPlutusスクリプトによってロックされている場合、そのUTXOのスクリプトコードはそのアドレスに関連付けられています。このスクリプトの状態のアナログは、UTXOに格納されたデータです。トランザクションがそのUTXOを使用すると、データを含めて元帳から削除されます。しかし、Plutusスクリプトの内容は、それを運ぶトランザクションが、更新されたスクリプトの状態と見なせる特定のデータを含むUTXOを作成しなければならないことを強制することができます。
スクリプトの実行予算
非決定論的ガスモデルは、ユーザーに予測できないほど大きな手数料を請求することがあります。カルダノスクリプトでは、この不確定性の原因は、リソースバジェット自体と、このバジェットをカバーするために必要な手数料がトランザクションに含まれていることを要求することによって対処されます。アロンゾ（Alonzo）では、ユーザーはトランザクションを構築する際に両方をローカルに予測することができます。スクリプトの実行は、必ずTrueかFalseのどちらかを返し、無限にループすることはありません。その理由は、スクリプトが実行するすべての操作にはゼロではない量のリソースが必要であり、それらはインタプリタによって追跡されるからです。トランザクションで指定された予算を超えた場合、スクリプトの実行は終了し、Falseを返します。
アロンゾ（Alonzo）におけるトランザクションの検証
不確定性の原因となる可能性のあるものに対処するため、以下のキーポイントにより、スクリプトとトランザクションの検証の結果を予測可能にします。
- スクリプトインタプリタは、同じ引数に適用された場合、常に終了し、同じ検証結果を返します。
- トランザクションは、検証中にスクリプトインタープリタに渡されるすべての引数を必ず固定します。
- トランザクションは、スクリプトの検証を必要とするすべてのアクションを指定します。
- トランザクションに強制的に署名を行うことで、敵対者がスクリプトを失敗させるような方法でトランザクションを変更できないようにする。
- EUTXOの台帳モデルにおけるトランザクションの適用は決定論的です。
最後の点はUTXOモデルからほぼ継承されており、アロンゾ（Alonzo）元帳のプロトコルの更新は、ほとんどの場合、以前の時代の更新（委任スキームなど）と一致しています。アロンゾ（Alonzo）のアップグレード後は、スクリプト検証の失敗または成功が、トランザクションの処理方法に影響を与えます（これについてはパート2で詳しく説明します）。しかし、TrueまたはFalseの結果と、どちらの結果にも関連する元帳の変更は、特定のトランザクションについて予測可能です。
カルダノのスクリプトとトランザクション検証の決定論的な動作は、EUTXOモデルを使用することによる自然な結果ではありません。この特性を確保するために、IOGチームは、スクリプトが見ることを許可されているすべてのデータのソースを注意深く追跡する必要がありました。
IOGチームは、決定論的評価特性がアロンゾ（Alonzo）仕様で正式に規定されており、インタープリタがこの特性を破らないような引数のみを取得することを証明するスケッチも作成しました。
第2回目のブログ記事では、カルダノ取引の2段階の検証プロセスについて詳しくご紹介します。それでは、今週末のパート2にご期待ください。
