Ethereum Forum JP

トピックで絞り込む

すべてのタグ (209) →

極めてリーンなチェーン

24 min read

原文

The Extremely Lean Chain — vbuterin (2026-07-06)

Emile、Potuz、Anders Elowssonには、初期のフィードバックとレビューに感謝します。

この投稿の目的は、「リーン」アップグレード（シングルスロットファイナリティ、再帰的STARK (スケーラブルで透過的な知識の引数)ベースのポスト量子 (PQ)耐性署名集約など）の文脈において、イーサリアムのコンセンサス層チェーンが、ステーク保有者に自身のコンセンサス状態の管理と時折のゼロ知識証明の責任を負わせることで、状態成長要件を積極的に最小化するように設計できることを示すことです。これにより、「エポック終了処理」（数スロットのファイナリティでは、例えば16秒ごとに発生する必要があるかもしれません）の負担が軽減され、必要に応じてコンセンサスが数百万のイーサリアムバリデータにスケールできるようになる可能性があります。これの高度なバージョンでは、イーサリアムバリデータの再匿名化も「無料で」提供されます。

「現状」のチェーンにおける状態会計

ビーコンチェーンのコンセンサス状態には現在、各イーサリアムバリデータについて以下が含まれます。

フィールドサイズ
公開鍵 (Pubkey)48バイト
出金資格情報 (Withdrawal credentials)32バイト
実効残高 (Effective balance)1バイト
スラッシュ済みか？ (Slashed?)1ビット
各フェーズのエポック番号 (アクティベーション資格、アクティベーション、終了、出金可能)8 × 4バイト
アクティブ残高 (Active balance)8バイト

ビーコンチェーンのコンセンサス状態の変更は、エポックごとに非常にコストのかかる操作です。ほとんどの場合、イーサリアムバリデータの参加または不参加に起因するアクティブ残高の変更に関連しています。

フェーズ1A: 公開鍵ツリーの省略

STARK (スケーラブルで透過的な知識の引数)ベースの集約の主要な利点の1つは、署名と集約方法の内部ロジックにおいて、より多くの自由度があることです。私たちはすでにこれを集約 (Aggregation) に利用するつもりであり、その結果、ビットフィールドマージ集約が可能になります。しかし、これを署名にも利用して、イーサリアムバリデータの公開鍵をコンセンサス状態から削除することもできます。

イーサリアムバリデータがデポジットを行うと、その公開鍵はデポジットツリーの固定された場所に保存されることに注意してください。さらに、誰もデポジットツリー全体を保存する必要はありません。デポジットコントラクトは右側ブランチのみを保存し、これは次の値を追加するために必要なすべてです。

デポジットコントラクト.drawio

ビーコンチェーンのコンセンサス状態にイーサリアムバリデータの公開鍵（48バイト）を保存する代わりに、デポジットツリー内のそのインデックス（5バイト）を保存します。ベース署名アルゴリズム（leanWOTS）は、公開鍵がデポジットツリーを通るマークル証明 (Merkle proof) とともに署名に含まれるように調整され、署名検証関数はインデックスを公開鍵として扱い、デポジットツリーの最近の（例：現在の日の開始時点の）ルートを補助的な公開入力として受け取ります。

イーサリアムバリデータは、署名を継続できるように、自身のデポジットの更新されたマークル証明 (Merkle proof) を追跡する必要があります。これは、デポジットが組み込まれた時点でイーサリアムバリデータが右側ブランチを所有しており、それ以降デポジットがあるたびにチェーンを処理してブランチを調整すれば、容易に行えます。

イーサリアムバリデータがデポジットを行う際、出金資格情報は公開鍵の隣にあるため、同じ証明を出金に利用できます（したがって、ビーコンチェーンのコンセンサス状態に出金資格情報を保存する必要はありません）。

フェーズ1B: 残高のゼロ知識証明

ビーコンチェーンの状態遷移関数から、報酬およびペナルティ処理に関連するすべてのロジックを削除します。アテステーション（証明）は、その有効性が（STARK (スケーラブルで透過的な知識の引数)によって）確認されれば、単にブロックに含められ、リアルタイムでの処理は一切行われません。

毎日終了時、イーサリアムバリデータは、前日以降のチェーンを辿り、オンチェーンに含まれた各アテステーション（証明）ビットフィールド内の自身のインデックスのマークルブランチ (Merkle branch) を提供し、これを用いて参加した回数と参加しなかった回数を判断し、新しい残高を計算するSTARK (スケーラブルで透過的な知識の引数)を生成する必要があります。彼らはこのSTARK (スケーラブルで透過的な知識の引数)をプロトコルに提出します。これにより、イーサリアムバリデータの残高が更新され、翌日も有効なままとなります。

チェーンウォーカー.drawio

実用性のため、上記の設計に1つ明確化が必要です。期間 [T, T + 1日] の実効残高は、T - 0.5日 までのブロックに基づいてのみ計算される必要があります。これにより、イーサリアムバリデータは、参加能力が中断されることなく、証明を組み込むための半日間の時間を得られます。また、証明の公開を半日間にわたって分散させることができ、突然の輻輳期間を回避できます（イーサリアムバリデータがブランチ公開時間をある程度ランダム化すると仮定した場合。必要であれば、ずらした最小公開時間を割り当てることでこれを強制できます。例：T_min(validator) = global_T_min + (1/4 day) * validator.pubkey_hash / 2**256）。

注記

新しい会計

イーサリアムバリデータごとのコンセンサス状態は次のとおりです。

フィールドサイズ
実効残高 (Effective balance)1バイト
公開鍵インデックス (Pubkey index)5バイト

その他すべては保存する必要がありません。各残高更新証明は、イーサリアムバリデータの以前のオンチェーン残高更新証明に接続されるため、残高の下位桁は実効残高に入ることなく証明を通じてスレッド化されます。デポジットエポック、終了エポックなどを追跡する必要はありません。その追跡は残高更新証明メカニズムに包含されるためです。

イーサリアムバリデータのN-1番目の残高更新証明は、(i) N-2番目の残高更新証明、(ii) それ以降のオンチェーンデータの決定論的関数であることに注意してください。これは、固定されたバックアップシードからのリカバリが依然として可能であることを意味します。

コンセンサス状態の更新は次のとおりです。

証明のコスト

残高更新証明を作成するために、イーサリアムバリデータは、前日以降、オブジェクトごとに最大1つのマークルブランチ (Merkle branch) （そのオブジェクトの最新のアテステーション（証明））を証明する必要があります。ここでの「オブジェクト」はブロックを意味します。ほとんどの場合、ファイナリティスロットごとに最大1つのブロックしかありません。

1日間の期間と16秒のエポックでは、これは約5400のマークルブランチ (Merkle branch) を意味します。STARK (スケーラブルで透過的な知識の引数)（ZK-SNARKs (ゼロ知識簡潔非対話型知識証明)よりも証明コストがはるかに低い）を使用すれば、弱いハードウェアでも1時間以内に十分可能です。フォークが発生した場合、フォークの一方の側のアテステーション（証明）はその側にのみ含まれるため、各イーサリアムバリデータは参加しているフォークの側のブランチのみを証明すれば済みます。フォークの他の側で更新を維持するための証明ははるかに安価になります。

合計実効残高を証明するコストは高くなります。これは、ビットフィールド全体と実効残高のセット全体を辿るためです（注：最適化のため、公開鍵インデックスと実効残高は別々のツリーに保存し、証明は後者のみ、イーサリアムバリデータあたり1バイトを辿るだけで済むようにすべきです）。

この非ハッシュ部分は「単なる」部分和であるため、コストはビットフィールドのマークルツリー (Merkle tree) 化（100万イーサリアムバリデータあたり128 kB）と実効残高ツリー（100万イーサリアムバリデータあたり1 MB）によって支配されます。今日、ハイエンドのラップトップは50万ハッシュ/秒以上（つまり、16 MB/秒のマークルツリー (Merkle tree) 化）を証明できるため、これは問題ありません。ローエンドのラップトップでもこれを処理できるはずです。

オンチェーンでは、このメカニズムはイーサリアムバリデータあたり1日1つのSTARK (スケーラブルで透過的な知識の引数)を想定しています。100万イーサリアムバリデータの場合、これはスロットあたり100以上のSTARK (スケーラブルで透過的な知識の引数)となり、多すぎます。したがって、これらの証明も署名が集約 (Aggregation) されるのと同様に集約 (Aggregation) される必要があります。

これはすでに非常に効果的で最適化された設計です。次のステップとして、プライバシーを追加します。

フェーズ2: プライバシー

ビーコンチェーンの設計にいくつかの大きな調整を加えます。

まず、「アクティブイーサリアムバリデータレジストリ」は日ごとの独立した構造になります。長期的なイーサリアムバリデータインデックスという概念は存在しません。システムの観点からは、イーサリアムバリデータは毎日新たに現れ、自身の有効残高を宣言・証明し、全員がアクティブになります。特に、委員会の割り当てはすべて、その日の公開鍵から行われる必要があることに注意してください。

第二に、公開鍵の登録を残高証明ステップに移動します。各イーサリアムバリデータは毎日新しい公開鍵を提供します。これは、インデックスがその日のツリーにおけるイーサリアムバリデータの位置に過ぎないため、公開鍵インデックスの概念を削除できることも意味します。

第三に、イーサリアムバリデータがラウンドごとにメッセージを送信する形式のBFTコンセンサス (BFT consensus) を想定します。「サラウンドスラッシュ」はありません。

また、残高更新証明で証明されるクレームも調整します。イーサリアムバリデータは、以前のN個のオンチェーン登録のチェーンについて証明します。これは、デポジットまたは[[glossary/weak-subjectivity-period|弱い主観性の期間]]日以上前の登録に遡ります。

ブロック内のスラッシュは公開鍵の順序である必要があり、マークルブランチ (Merkle branch) サイズの証明を可能にします。これにより、スラッシュのスキャンオーバーヘッドは、アテステーション（証明）のスキャンオーバーヘッドと最大で同じになります（通常、ブロックにはスラッシュはゼロです）。

さらに、使用されるSTARK (スケーラブルで透過的な知識の引数)が**ZK-STARK**であることを確認してください。

また、部分的な出金も別のZK-STARKとします。これは、正確な超過残高（部分的な出金では必然的に漏洩しますが、実効残高は粗粒度であるため漏洩しません）を翌日の鍵に添付し、それによって翌日の鍵を前日の鍵にリンクするのを避けるためです。

また、以前の公開鍵をスラッシュできるようにするために、以下のいずれかを行う必要があります。

  • 公開鍵がデポジット時に固定されたシードから決定論的に生成されることを要求します。これにより、証明は過去[[glossary/weak-subjectivity-period|弱い主観性の期間]]日間の公開鍵を生成し、それらすべての中からスラッシュをチェックできます。
  • 証明が、オンチェーンで[[glossary/weak-subjectivity-period|弱い主観性の期間]]日前までの以前のスラッシュを辿ることを要求します。

前者はより単純で安価です。後者はより集中的で複雑ですが、2つの利点があります。

  • 出金とデポジットのループなしで鍵のローテーションを可能にする
  • イーサリアムバリデータが[[glossary/weak-subjectivity-period|弱い主観性の期間]]よりも古い鍵（出金資格情報を除く）を削除することを可能にし、デバイスが侵害された例外的なケースでのプライバシーを向上させます。ただし、実際にこれを行うとバックアップ手順が複雑になるというコストがかかることに注意してください。

現在アクティブな公開鍵に対するスラッシュは即座に適用され（実効残高をゼロに設定することで）、以前の公開鍵に対するスラッシュは1日遅れてのみ適用されます。

これにより、かなり強力なイーサリアムバリデータの匿名性が得られます。各イーサリアムバリデータのIDは毎日完全に再ランダム化され、現在のIDと過去のIDの間のリンクを知っているのはイーサリアムバリデータ自身だけであり、このリンクを再証明するのは、(i) 最後の証明以降の残高変更、(ii) スラッシュされたかどうか、という2つの情報のみを明らかにするためです。

最後に、デポジットが出金アドレスを平文で公開しないようにしてください。代わりに、隠蔽コミットメント hash(withdrawal_address, secret) を作成します。出金アドレスとシークレットを知っている人だけが出金を行うことができます。したがって、毎日の証明は、出金が行われていないことも証明する必要があります（これには、コンセンサス状態が日ごとの出金イベントのアキュムレータを持つ必要があります）。これにより出金アドレスは公開されますが（実行レイヤー側での平文のETH転送であるため避けられません）、これは「このアドレスがX ETHを受け取った」という以上の情報を公開することはありません。出金アドレスがデポジットやオンチェーン活動に公開でリンクされることは決してありません。

単一秘密リーダー選挙 (SSLE)

この投稿で導入されたメカニズムは、ある意味で単一秘密リーダー選挙 (SSLE)（https://eprint.iacr.org/2020/025.pdf）をほぼ「無料で」提供します。公開で追跡される永続的なイーサリアムバリデータセットの概念がなくなるため、プロポーザーを選出する唯一の場所は、再匿名化された日ごとのイーサリアムバリデータセットになります。実際、イーサリアムバリデータがプロポーザーになるまでアテステーション（証明）しない場合、これはすでに単一秘密リーダー選挙 (SSLE)の主要な特性を満たしています。この設計は、イーサリアムバリデータがプロポーザーになる前にアテステーション（証明）する場合でも単一秘密リーダー選挙 (SSLE)の特性を提供するように拡張できます。

期間長の選択

証明を作成するコストのほとんどは償却されます。それは前のチェックポイントから現在のチェックポイントまで「チェーンを辿る」ことなので、非常に低い閾値を超えれば、期間長に関係なく同程度のコストがかかります。

主なオンチェーンコストは、残高更新証明がオンチェーンで32バイトのコミットメントを必要とすることです。これはアテステーション（証明）（1ビット）よりも256倍高価です。したがって、コストを2倍以下に抑えたい場合、最小の残高更新期間は256ファイナリティ期間となります。ファイナリティ期間が16秒の場合、これは4096秒（約1.1時間）の残高更新期間を意味します。このような非常に積極的なパラメータは、上記の投稿が示唆したように、更新が期間全体にわたってずらして行われる必要があり、1/4の長い範囲だけでなく、更新のレイテンシをいくらか増加させます。

したがって、1時間が下限であり、1日は保守的です。

期間が長くなると、イーサリアムバリデータの匿名性の有効性が低下します。

3投稿 - 3参加者

トピック全文を読む

グラフビュー