画像を読み込み中Lawrence Mondal
画像を読み込み中オリビア・ステファニー
画像を読み込み中イーサリアムのドラフト、バッチ証明向けの支払い共有を提案 - 1
画像を読み込み中レール

共有

イーサリアムのコントリビューターであるMarchhill氏は、汎用的な証明検証とスポンサー付きバッチ処理を可能にする草案提案を提出した。これにより、複数のトランザクションのクレームが、支払いと署名をそれぞれ個別に保持したまま、1つの証明を共有できるようになる。

• スポンサーがバッチ証明の費用を負担し、メンバーのトランザクションは個々のクレームの費用を支払うことが可能になる。

• 有効なサブセットは、メンバーがトランザクションに再度署名することを必要とせずにブロックに入ることができる。

• 提案されている手数料とリソース制限は暫定的なものであり、有効化は性能測定の結果に依存する。

• この提出物はドラフトのプルリクエストであり、EIP番号の割り当てもメインネットでの有効化日も定まっていない。

マーチヒル氏の提案は11月13日にイーサリアムのEIPリポジトリに提出され、EIP-8288で予約されているLEANSTARK_SCHEMEを有効化し、スポンサー付きバッチのルールを導入するものだ。この提出物は開発中であり、イーサリアムのネットワークアップグレードとして採用されてはいない。

この草案は、汎用的な検証、証明の識別、リソース制限、依存関係の要約、バッチ支払いを一つの提案にまとめたものだ。これは以前の提出物であるプルリクエスト#12654を置き換えるものであり、EIP番号と専用のディスカッションスレッドはまだ割り当てられていない。

イーサリアムのバッチ証明はスポンサーとメンバーの支払いを分離する

この草案の中心にあるのは、スポンサーが保持される各バッチリーフ（複数のクレームを含む個々の証明コンポーネント）の費用を負担するという支払いの仕組みだ。メンバーのトランザクションは、各自が提出したクレームに応じて支払いを行う。

ビルダーはメンバーに再署名を求めることなく、任意の有効なサブセットを含めることができる。したがって、提案された仕組みによれば、トランザクションが包含可能な状態にある者が、元のグループの他のメンバーが除外されたという理由だけで新たな署名を必要とすることはない。

この草案は個々のトランザクションのナンスとレシートを保持する。ナンスはアカウントのトランザクション順序におけるそのトランザクションの位置を識別し、レシートはその実行結果を記録する。証明作業を共有しても、これらの記録は個別のトランザクションに紐づいたままとなる。

支払いの照合はファイナライズ時に確認され、再帰的証明によってバッチで使用されたソースが認証される。この提案は、クレームが有効であることを確立する作業と、必要な支払いがそれらに伴っていることを確認する作業とを区別している。

割引されたクレームとスポンサーによる支払いは、ブロックビルダーに直接送られる。単一のステートメントを対象とする通常の証明は、トランザクションがブロックに取り込まれるのを待つパブリックメムプールへの利用資格を引き続き有する。

汎用的な検証はEIP-8288を基盤としている

基盤となるEIP-8288は、Vitalik Buterin氏とThomas Coratger氏が執筆し、イーサリアムのメイン実行プロセスの外側で暗号署名と証明を集約することを提案している。トランザクションは検証が必要なステートメントを識別し、再帰的STARKがブロックレベルでその有効性を確立する。

STARKは、すべての検証者が計算を繰り返すことを必要とせずに、計算が正しく実行されたことを示す暗号証明である。再帰により、1つの証明が他の証明を検証し、それらの結果を統合することができる。

EIP-8288は現在、汎用のleanSTARKスキームを予約しているが、依存フレーム内での使用は許可していない。Marchhill氏の提出は、その経路を有効化し、基本草案の単なるデータハッシュのステートメントを、クレームのリストを表す安定したダイジェストに置き換えることを提案している。

この設計は、集約証明を通じて複雑な暗号技術を扱うことへのButerinの支持を含む、暗号検証に関する以前の議論を踏まえたものである。彼のコメントは基盤となるアーキテクチャに関するものであり、Marchhillの草案は具体的な検証と支払いの取り決めを提示している。

提案された手数料は依然として調整の対象である

提供された改訂版には、ネイティブ検証に15,400ガス、通常の汎用検証に572,000ガスという暫定的な手数料が記載されている。これによると、固有の証明分担分に5,100ガス、リーフ支払いに675,000ガス、バッチ請求に4,200ガスが割り当てられている。

草案は、リーフ決済が別途の手数料を伴うと説明している。拘束的な決済は通常の検証を超えた固定の作業を追加するためだ。クレームと決済には追加の内在的なプルーフ分担が発生しない。これらの数値は共同での調整を必要とするため、最終的な手数料体系やユーザーにとって確定した節約額を確立するものではない。

リソース制御には、ガスとは独立して適用される16,384個の異なる依存関係という暫定的なブロック上限と、それに対応するインクルージョンリストの適合ルールが含まれる。リーフには最大256件のクレームを含めることができ、プルーフステップには16個の入力を持たせることができる。いずれの数値もブロック全体の上限ではない。

アクティベーションにはフルブロックのパフォーマンス測定が必要となる

有効化に先立ち、この提案では、トランザクションのガス上限内に収まる完全な処理スケジュール、遅延したスポンサーによる修復、およびプルーフごとの手数料を、必要なオーバーヘッドを含めて測定することを求めている。

そのベンチマーク資料では、測定された個々のノードおよび単一マシンでのブロック結果と、モデル化された16ワーカーでの数値を区別している。この草案では、その証拠と残存する性能ギャップをベンチマーク資料に記録することを求めている。

無効化されたスポンサーシップはビルダーの作業を無駄にする可能性があり、提出文書によれば、インクルージョンガスはその作業を補償しない。具体的なコミットメントの構築とエンコーディングは、固定されたプルーフシステム仕様に残されている。この提案は新たなネットワーキングメッセージを導入しない。