Cardanoで驚きのないトランザクション検証

AlonzoハードフォークによりPlutusスマートコントラクトのコア機能がCardanoにもたらされるに連れ、ますます高まる分散型ソリューションデプロイのニーズに応えるために台帳も進化します。Cardano台帳の設計は、高保証性、セキュリティ、証明されたフォーマル検証に焦点を当てています。この戦略と併せて、トランザクション処理の決定性（determinism）、すなわち、トランザクションの実行前にユーザーがその影響と結果を予測できることも重要です。

トランザクションの実行コストを保証できる機能性、そして、トランザクションが台帳上でいかに動作するかを送信前に知ることの重要性は、スマートコントラクトサポートの導入とともにさらに高まっています。Cardanoのような未使用トランザクションアウトプット（UTXO）ベースのブロックチェーンは、このような機能性を提供します。イーサリアムなどのアカウントベースのブロックチェーンは非決定性であり、トランザクションのオンチェーンへの影響についての予測を保証できません。これは金銭的損失、予想外の高額手数料、そして敵対的な行動の機会増加のリスクに繋がります。

本稿では、安全なトランザクションと実行前のスクリプト評価を可能とするCardanoの決定性設計の利点を掘り下げます。また、今週中に公開される次稿では、Cardanoにおけるトランザクションの二段階検証について紹介します。

トランザクション決定性とは何か、なぜ重要なのか

トランザクションおよびスクリプト処理という文脈において、決定性とは予測可能性と同義です。すなわち、ユーザーはローカル（オフチェーン）で、以下の懸念なくトランザクションが台帳のオンチェーンステータスに与える影響を予測できます。

• 予想外のスクリプト検証結果または失敗
• 予想外の手数料
• 予想外の台帳またはスクリプトステータスの更新

決定性システムにおけるトランザクションにしても、正しく構築されている場合であっても却下されることはあります。却下（リジェクト）とは、トランザクションが台帳にまったく適用されないことです。したがって台帳のステータスには何の影響もなく、手数料も支払われません。こうしたことが生じるのは、最初のトランザクションが構築されてからそれが処理されるまでの間に別のトランザクションが処理されたことによって、台帳に変更が生じるためです。これは単純なトランザクションでも生じ得ます。たとえば、別のトランザクションが、ユーザーが使おうとしたUTXOを使用する場合があります。決定性システムでは、トランザクションがいつ受け入れられても、台帳ステータスへの影響は予測可能です。

非決定性の問題に対処

非決定性とは、トランザクションを実行する前に、台帳への影響を予測できないことを意味します。台帳やスマートコントラクトを設計する際に、非決定性が生じる可能性のある条件を予見し、これを回避するような設計を行うことが重要です。こうしたケースにおける主な危険の1つは、台帳の可変データ、すなわち変更可能なデータへのアクセスです。トランザクションやスマートコントラクトが台帳に加える変更が、単にトランザクションの中身よりもむしろ処理時のステータスに依存すると、非決定性が問題となる可能性があります。

イーサリアムはこの問題の影響を受けやすいことで知られています。たとえば、ガス価格や分散型取引所（DEX）のレートは、ユーザーがトランザクションを送信してからそれが処理されるまでの間に変動する可能性があります。これが、予想外のガス代や購入する資産の価格変更という結果を招きます。または、スクリプトが単純に失敗し、高額の実行コスト（数百ドル）だけ生じて何の効果もないという結果となります。これは、たとえば、実行中にガス代をカバーする資金が尽きてしまった場合などに起こり得ます。決定性を考慮した台帳設計はこうした可能性を排除します。

その他の非決定性の可能性には、スクリプトが以下を確認することが可能であることが含まれます。

• トランザクションを含むブロック内のデータ、ただしすべてのトランザクションに含まれるわけではない。例：システムのランダム性、ブロックヘッダー、現在のスロット番号など
• トランザクション自体は処理可能なままでありながら、スクリプト検証の結果を変える可能性のある、攻撃者により変更または置換されたデータ

ほとんどのシステムでは、こうした問題をスクリプト作成の改良やレイヤー2ソリューションで軽減する方法が採用されています。Cardanoはすべてのスクリプトおよびトランザクションの結果予測を保証できるように設計されています。

決定性の観点からみた、基本的なUTXOモデルのメリット

Cardano台帳はUTXO会計モデルに基づいています。これは、資産がアカウント形式でなく未使用アウトプットの形式で台帳に保存されることを意味しています。これらの各アウトプットは、そこに保存されている資産の量を、アドレスとともに保存します。未使用アウトプットは変更不可能であるため、トランザクションはアウトプット全体を使用することはできますが、変更することはできません。

資産を移すためには、トランザクションは1つ以上のアウトプットを使用し、新しいアウトプットを作成します。これは合計すると、消費したアウトプットと同量の資産を含むことになります。この量（およびUTXOアドレス）は、トランザクションのアウトプットで指定されます。台帳に適用された別のトランザクションに影響を及ぼす唯一の方法は、後者のトランザクションが使用しようとしたUTXOを先に使用することです。これで、ノードは後者を却下することになります。これが、UTXOが決定性を維持するために依存する主要な機能です。

UTXO台帳は、アカウントベースモデルに対し優劣両方の要素があります。たとえば、アカウントベースモデルの方が、トランザクションがブロックし合うケースが少なくなります。UTXOと異なり、アカウントの台帳データは変更可能です。したがって、たとえば、トランザクションが認識するアカウント内の資産額が、別のトランザクションが同アカウントを更新する前か後かによって変わる場合があります。この環境では、トランザクションが却下されることはありませんが、台帳に異なる、そして予測不可能な変更をもたらす可能性があります。

UTXOの使用は、トランザクションが実行するアクションの一例にすぎません。次に、トランザクションのアクションとは何か、そして、それがどのように検証されるかについて説明します。Alonzoで導入された最も重要な変更は、アクション検証の処理における変更です。

署名とスクリプトを使ったアクション検証

トランザクションを処理する重要なポイントは、トランザクションによって実行されるアクションの検証です。トランザクションは、アクションに関連する特定のフィールドにデータが含まれる場合に、そのアクションを実行します。たとえば、インプットフィールドにUが含まれていればUTXO Uを使用し、ミントフィールドにXが含まれているとトークンXをミントします。

ノードがトランザクションを処理するとき、意図されたアクションを実行できるかどうかを検証します。このために、トランザクションの作成者は関連するデータ、すなわち、スクリプトやリディーマー、署名などを提供しなくてはなりません。検証を必要とするアクションの一般的な例は、公開鍵でロックされたUTXOの使用です。トランザクションは、このアクションを実行するために、対応する秘密鍵から署名を提供する必要があります。

Cardanoでは、アクションを検証するためにスクリプトを使用します。これらのスクリプトはコードの一部ですが、TrueまたはFalseのアウトプットを使用した純粋関数を実装します。スクリプト検証は、所与のスクリプトを適切な引数で実行するためにスクリプトインタープリターを起動するプロセスです。

スクリプト検証は、以下のアクションのために使用できます。

• スクリプトアドレスでロックされたUTXOを使用する：実行されるスクリプトはハッシュがアドレスであるもの
• トークンのミント：実行されるスクリプトはハッシュがミントされるトークンのポリシーIDであるもの
• 報酬の引き出し：実行されるスクリプトはハッシュがステーキングアドレスであるもの
• 証明書の申請：実行されるスクリプトはハッシュが証明書作成者のクレデンシャルであるもの

どのスクリプトを実行するかをノードに知らせることに加えて、すべてのトランザクションアクションはそのスクリプトに渡す引数をアセンブルする方法を指定します。

Cardanoのマルチ資産台帳（Mary）は、単純なマルチシグおよびタイムロックスクリプト言語をサポートしています。ユーザーはこれによってアクション（UTXOを使用する、NFTをミントするなど）を実行するために必要な署名と、アクションを実行できる期間を指定することができます。タイムロックスクリプトはこれを含むトランザクションの実際のスロット番号を確認することはできません。タイムロックが確認できるのは、トランザクションを実行する有効期間だけです。タイムロックスクリプトが現行のスロット番号を確認できるようにする（すなわち作成者ではなくブロックからデータを得ることになる）と、決定性が破られます。これは、トランザクションが処理される実際のスロットをユーザーが知り得ず、したがって彼らがスクリプトがどう作用するかを捕捉し得ないという事実により保証されます。

多くのスクリプトは、AlonzoのPlutusコントラクトとは異なり、表現できることが極めて限られています。Alonzoハードフォークは、台帳の決定性が損なわれることのない、パワフルでステートフルなコントラクトの新時代へと導きます。

Plutusスクリプト

Alonzoは、Plutusスクリプトの実装により、Cardanoのトランザクション検証に新たなアプローチを導入しました。Alonzoの一部としてデプロイされた拡張未使用トランザクションアウトプット （EUTXO）モデルは、Plutusコントラクトをサポートする台帳インフラストラクチャーを提供します。以下では、台帳とトランザクションの変化の概略を紹介します。台帳およびPlutusスクリプトを使った機能の詳細は、Plutusパイオニアプログラムを参照してください。

Alonzoは台帳のデータを次のように変更します。

1. PlutusスクリプトはUTXOをロックできる。

2. UTXOのアウトプット部分のコンテンツに追加された新コンポーネントが、スクリプトステータス的な機能を可能にする。PlutusスクリプトにロックされたUTXOは、資産とアドレスに加えてデータムも含む。データムは、スクリプトステータスの解釈と見なしうる一片のデータ。

3. トランザクションで追加的な検証要件を課すために使用される新たなプロトコルパラメーターが多数存在する。ここにはスクリプトが消費できる計算リソースの上限が含まれる。

Plutusスクリプトをサポートするために、トランザクションは以下のようにアップグレードされました。

1. トランザクションは、各アクションのために、リディーマーと呼ばれるユーザー指定の引数を運ぶ。リディーマーはスクリプトに応じて異なる目的に使用できる。たとえば、オークションでのユーザーのビッドや、ゲッシングゲームでのユーザーの推測など、多くの機能に使用可能。

2. トランザクションは、各スクリプトの計算実行バジェットを指定する。

3. トランザクションが実行手数料を支払えることを確認するために、Alonzoは追加的なデータを採用（詳細は次稿を参照）。
4. トランザクションには、欠陥がないか、期限切れでないかなどを確認するのに必要な、インテグリティハッシュが含まれる。

また、Maryと比較して、Alonzoトランザクション検証の詳細にも変更があります。各アクションのために、ノードはPlutusインタープリターが期待する以下のスクリプト引数をアセンブルします。

• データム
• リディーマー
• 実行バジェット
• トランザクションの概要

ノードは、トランザクションが正しく構築されたことを確認する、Alonzo特有の新しいチェックを実行します。たとえば、これは、最大実行リソースバジェットを超過することはできません。これはまた、スクリプトを実行するPlutusスクリプトインタープリターを起動します。

データムオブジェクト対スクリプトステータス

変更可能なアカウント同様、変更可能なスクリプトステータスも、非決定性の原因となる「変更可能な台帳データ」カテゴリーに当然のごとく含まれます。前述したように、UTXOモデルは変更可能なアカウントの非決定性問題を回避します。これはまた、決定性を維持するうえでスクリプトステータスのコンセプトを再解釈するのに役立ちます。UTXOがPlutusスクリプトによってロックされると、このUTXOのスクリプトコードはアドレスに紐づけられます。このスクリプトのステータスアナログはUTXOに保存されたデータムです。トランザクションがそのUTXOを使用すると、データムごと台帳から削除されます。しかし、Plutusスクリプトの内容によっては、これを運ぶトランザクションが、更新されたスクリプトステータスとして表示することのできる特定のデータムを含むUTXOも作成することを強制する場合があります。

スクリプト実行バジェット

非決定性ガスモデルはユーザーに予測不可能なほど高額の手数料を課すことができます。Cardanoスクリプトでは、リソースバジェット、そしてそのバジェットをカバーするために必要な手数用をトランザクションに含むことを要件とすることによって、この非決定性の原因に対処しています。Alonzoでは、ユーザーはトランザクションを構築するときに両方をローカルで予測することができます。スクリプトを実行すると、必然的にTrueまたはFalseのいずれかが返され、永久にループすることはありません。この理由は、スクリプトが実行するすべての操作はゼロでないリソース量を使用するためです。これはインタープリターによって追跡されます。トランザクションで指定されたバジェットを超過すると、スクリプトの実行は終了し、Falseを返します。

Alonzoにおけるトランザクション検証

潜在的な非決定性の原因に対処するにあたり、以下のキーポイントによってスクリプトおよびトランザクション検証の結果が予測可能となります。

• スクリプトインタープリターは、同じ引数に適用された場合必ず終了し、同じ検証結果を返す
• トランザクションは検証中にスクリプトインタープリターに渡されるすべての引数を必然的に修正する
• トランザクションは、スクリプト検証に必要なすべてのアクションを指定する
• トランザクションの強制署名により、スクリプトの失敗を引き起こすような方法で攻撃者がこれを変更することができないようにする
• EUTXO台帳モデルでトランザクションの適用は決定性を持つ

最後のポイントは、大部分がUTXOモデルから受け継がれたものです。Alonzo台帳プロトコルのアップデートは、ほとんどの部分が前期のアップデートと一貫性を保っています（委任スキームなどを含む）。Alonzoアップグレード後、スクリプト検証の失敗または成功はトランザクションの処理方法に影響します（詳細はパート2で後述）。しかし、TrueまたはFalseの結果は、いずれかの結果に関連する台帳の変更とともに、所与のトランザクションで予測可能です。

Cardanoスクリプトおよびトランザクション検証の持つ決定性は、EUTXOモデルから生じる当然の結果ではありません。IOGチームは、このプロパティを確保するために、スクリプトが確認できるすべてのデータソースを注意深く追跡する必要がありました。

決定性評価プロパティは、Alonzoの仕様で形式的仕様記述がなされています。また、IOGチームもインタープリターがプロパティを損なわない引数のみを取得するという証拠を示しています。

次稿では、Cardanoトランザクションの二段階検証について詳細に説明します。今週後半のパート2をお楽しみに。