前稿では、トランザクションのオンチェーンへの適用とスクリプトの検証結果が、トランザクションを送信する前にローカルで正確に予測可能となることを保証する、Alonzo台帳におけるトランザクションおよびスクリプト検証の決定性について考察しました。
Alonzo台帳の決定性設計が提供する保証を前提に、私たちは独自の二段階検証スキームを実装しました。これは、ノードがネットワークのトランザクションを検証するために使用するリソースを最小化するとともに、ユーザーにとって予想外となるコストを排除することを意図して設計されています。本稿では、この二段階検証の仕組みについて掘り下げます。
Shelley期、Allegra期、そしてMary期では、トランザクション検証はワンステップで処理されました。有効なトランザクションが台帳に与える影響は、トランザクションが適用される前に完全に予測が可能です。トランザクションが有効な場合、そのトランザクションはブロックに組み込まれ台帳に追加されます。有効でなければ、ノードは検証が失敗となった後にこれを却下し、トランザクションがブロックに含まれることはありません。しかし、受信したトランザクションを検証したノードは、トランザクションがブロックに含まれようと含まれまいとにかかわらず、時間とリソースを費やすことになります。
AlonzoはPlutusスクリプトを導入します。このスクリプトの検証に要するリソースは、過去期の単純なスクリプトの場合と比較して大幅に増加する可能性があります。ノードが却下されるトランザクションのスクリプトを検証するためにリソースを消費するという問題に対処するために、Alonzoは二段階検証アプローチを採用しました。この戦略は、トランザクションを台帳へ適用することによる結果の予測可能性を維持し、ノードに作業と消費したリソースに対する公正な補償を確保するためのものです。
二段階トランザクション検証
Cardanoのトランザクション検証は二段階にわかれています。二段階検証を採用する主な理由は、ノードによる無償の検証作業を制限することです。各段階は、この目的を達するためのものです。大まかに言って、第一段階はトランザクションが正しく作成されているか、そして、処理手数料を支払うことができるかをチェックします。第二段階ではトランザクションに含まれるスクリプトを実行します。トランザクションが第一段階で有効な場合、第二段階のスクリプトが実行されます。第一段階の結果が失敗だった場合、スクリプトは実行されず、トランザクションは即座に破棄されます。
したがって、ノードは、第二段階が有効でなくとも、処理可能なトランザクションをブロックに追加することが期待されます。これは以下のいずれかを意味します。
- ノードにより、トランザクションが処理可能かどうかを判断するための少量の無償作業が実行されるが、高額な第二段階の検証作業は実行されない、または、
- トランザクションは処理可能。次に、ノードは第二段階のスクリプト検証を実行し、第二段階が有効か無効かに従ってトランザクションにタグ付けし、ブロックに追加することができる。 いずれの場合も、ノードは後にこのトランザクションで回収した手数料または担保により両段階の検証を補償される。
第二段階での失敗は稀であることが期待されます。これは、失敗するようなスクリプトを使ってトランザクションを送信しても、ユーザーは何も達成できず、ADAを失うことになるだけだからです。これはローカルで予測できる、回避可能なイベントです。この段階は、リソースが集中する可能性があるスクリプト計算への補償を保証するために必要なセーフガードです。
では、各段階の詳細を見ていきましょう。
第一段階
最初の検証段階は単純でなければなりません。この段階が失敗すると、処理不可能なトランザクションから処理手数料を受けられないため、ノードは実行した作業に対して補償を得ることができません。
第一段階では2つの事項を確認します。トランザクションが正しく作成されていること、そして、台帳に追加可能であることです。この検証には、以下の確認といくつかの追加事項が含まれます。
- 正確な額の手数料を支払い、正確な額の担保(スクリプトが失敗した場合に回収されるADA、後述)を提供している
- Plutusスクリプトを実行するためのすべてのデータを含む
- プロトコルパラメーターで設定されたいかなる制限(アウトプットサイズなど)も超過していない
- インプットが台帳に存在しているUTXOを参照している
- トランザクション用に指定された計算バジェットがトランザクション当たりの最大リソースを超過していない
- インテグリティハッシュの確認、その他
メモリープールに(さらに最終的にはブロックに)受信したトランザクションを追加する前に、ノードは第一段階検証のチェック項目すべてを実行する必要があります。これらいずれかのチェックが失敗すると、トランザクションはブロックに含まれることなく、また、手数料を課金されることなく却下されます。過去期では、これが唯一の検証段階であり、Cardanoはすべての検証の失敗をこの方法で処理していました。
誠実な、侵害されていないノードが、意図してプロセスできないトランザクションを生成することは期待されていません。ノードはまた、第一段階で無効なトランザクションの敵対的な拡散を実行する接続を断つこともできます。
第二段階
検証の第二段階では、Plutusスクリプトを実行します。ここではより多くの計算コストが消費される可能性があります。したがって、手数料は第二段階の成功または失敗の後に課金されます。徴収されたADAは手数料ポットに納められ、検証処理でリソースを使用したノードはここから補償を受けます。
第一段階の検証が成功しても、トランザクションのすべてのアクションがプロセス可能とは限りません。担保の収集が可能であるということだけが保障されます。第二段階では、Plutusスクリプトの検証が実行され、検証結果に基づいてすべてのプロセスを実行するか、担保を収集するだけにするかが決定されます。
- トランザクションを完全に適用する(Alonzo前は唯一のオプション) - Plutusスクリプトがトランザクションのすべてのアクションを検証した場合、または、
- 担保のADAを回収し、残りのトランザクションを無視する - Plutusスクリプトの1つでも失敗した場合
前述のように、スクリプト検証結果はローカルで予測可能であり、終了することが保証されます。ユーザーは、スクリプトの検証結果をローカルで確認できるため、誠実なノード間では所与のトランザクションとそこに含まれるスクリプトがどのように処理されるかについて異論はでません。
担保
スクリプトが検証されない場合でも、ノードに行った作業の補償をする必要があります。しかし、トランザクションインプットから資産を単に取得できるわけではありません。スクリプトにロックされているかもしれないからです。そしてそのスクリプトは失敗しています。したがって、その代わりに、Alonzoはこのための特則を設けました。トランザクションの担保(Collateral)は第二段階検証が失敗した場合に手数料として回収されるADAです。処理可能なトランザクションでは、この額は少なくともトランザクション手数料の一定の割合であり、プロトコルパラメーターで指定されています。
この額は、トランザクションを作成する時点で指定されます。これは、直接ではなく、トランザクションにCollateral Inputs(担保インプット)を追加する際に適用されます。この特殊なインプットに対応するUTXOの合計残高が、トランザクションの担保額です。このUTXOは公開鍵(スクリプトではなく)アドレスをもっている必要があり、またここにADA以外のトークンが含まれてはいけません。
担保インプットは、スクリプトが第二段階検証で失敗した場合にのみ台帳UTXOから回収されます。すべてのスクリプトがパスした場合は、過去期同様に指定されたトランザクション手数料が回収されます。特に、金額は担保でない通常インプットからのものであり、担保インプットは単に無視されます。そして、いいお知らせです。担保用と通常用には、同じインプットを使用することができます。2つのうちいずれか1つしかUTXOから回収されないためです。
担保インプットの支払いを承認するために必要な署名も、トランザクションの完全性を維持するために重要な役割を果たします。攻撃者が、処理可能なままで第二段階検証を失敗するように内容を変更することを妨げます。攻撃者によるリディーマーの置換はこの一例です。このような変更を行うには、担保の鍵保有者による署名が必要です。担保の鍵保有者は、スクリプト検証が失敗するとADAを失うことになる唯一のユーザーでもあります。
スクリプト評価に決定性があるため、担保の鍵保有者はトランザクションがオンチェーンで第二段階検証をパスするかどうかを、署名する前にローカルで確認できます。ローカルでパスすれば、オンチェーンでも確実に成功するため、担保を失うことはありません。誠意を持って行動しているユーザーは、決して担保を失うことはありません。また、同じ担保インプットを複数のトランザクションに使用し、担保が確実に回収されないようにすることもできます。
現在Alonzoパブリックテストネットが配信されています。ここでPlutusスクリプトを作成、実行して査定してくれるすべてのユーザーそして開発者を歓迎します。詳細は、専用のAlonzoテストネットリポジトリを参照し、また、多様なコミュニティとPlutusとAlonzoに関するトピックについて話し合ってください。
最新の記事
Input | Output chief scientist receives prestigious Lovelace computing award 筆者: Fergie Miller
3 December 2024
Delivering change in Ethiopia: lessons and reflections 筆者: Staff Writer
28 November 2024
Applying formal methods at Input | Output: real-world examples 筆者: James Chapman
26 November 2024