原作者 | Taiko Labs
編集：Odaily Planet Daily ( @OdailyChina )
翻訳者 | ディンダン ( @XiaMiPP )
編集者注: シャーディングについての興奮をまだ覚えていますか?当時、それはブロックチェーン業界の「トラフィックパスワード」でした。その結果、イーサリアムは冷静に考え、この厄介な問題を放棄しました。今日、ローカルRollupが復活しました。プリコンパイルされたコントラクト（EXECUTE Precompile）を実行し、Ethereumブロック処理構造を最適化することで、Rollupをより安全で柔軟にするだけでなく、Ethereum L1に大規模な水平拡張をもたらし、将来のリアルタイム証明への道を開きます。
以下は、Taiko Lab が公開し、Odaily Planet Daily が翻訳したオリジナルコンテンツです。この記事は高度に技術的な内容であるため、記事の読みやすさを確保するために、Odaily では適切な削除を行い、できるだけ明確かつ簡単に提示しています。
導入
シャーディングは2017年から2020年にかけて話題になりました。当時、Harmony、Zilliqa、Elrondなどのさまざまなチームがブロックチェーンにシャーディング技術を実装していました。このテクノロジーは基本的に、分散システムを拡張するための簡単な方法として、トランザクションを同時に処理できる複数の小さな並列実行チェーン（「シャード」と呼ばれる）にネットワークを分割します。
シャーディングは、Ethereum 2.0 時代のコミュニティで真剣に議論されているトピックでもあります。しかし、イーサリアムは最終的に、主に次の 4 つの課題に基づいて、シャーディング ソリューションを採用しないことを決定しました。
1. マインドセットの差別化
このシャーディング モデルでは、プロトコル自体が上から下までのシャードの正確な数を強制します。これらのシャードは、事前定義されたテンプレートに従って実行される単一のチェーンであり、プログラム可能性がなく、本質的には L1 (レイヤー 1 ブロックチェーン) の複数の同一コピーにすぎません。
2. 楽観的なセキュリティ
当時、シャードの誠実さを保証するために楽観的証明が必要でしたが、ゼロ知識（ZK）技術はまだ成熟していませんでした。つまり、不正防止ロジックはチェーン上で体系的に管理される必要があります。
3. 複雑さ
L1 レイヤーでシャーディングを実装すると、特に高速な事前確認と低速な最終確認システムの管理、および異なるセキュリティ レベルのシャードの調整において、プロトコルの複雑さが大幅に増加します。
4. 過負荷コンセンサス
L1 レイヤーでより高いスケーラビリティを追求すると、集中化のリスクが増大する可能性があります。シャーディングがベースレイヤーで実装されると、このリスクは現在のように単一の L2 (第 2 レイヤーのスケーリング ソリューション) に限定されるのではなく、プロトコル全体に影響を及ぼす可能性があります。
ネイティブ ロールアップは、本質的にはシャーディングへの回帰と見ることができますが、今回は異なります。私たちは教訓を学び、より優れた技術と経験を身につけました。
ローカルロールアップとは何ですか?
ロールアップは、データ、シーケンス、および実行モジュールで構成されていることに注意してください。 Local Rollup は、実行モジュールとして Ethereum 独自の実行環境 (Execution Environment) を直接使用します。これを L1プログラマブル実行シャードと呼ぶことができます。
L1 実行環境をロールアップとして使用する方法を理解するのは少し複雑です。 Rollup で L1 実行環境を使用するには、EVM 内で別の EVM (EVM 内 EVM) を実行できる必要があります。したがって、L1 は各ブロック内のローカル ロールアップの状態遷移を認識できる必要があります。これを実現するには、サポートを提供するための <precompile コントラクト> が必要です。
コンパイル済みコントラクトを実行する
EXECUTEプリコンパイル済みコントラクトは、同じ実行ルールと状態遷移ロジックを維持しながら、1 つの EVM コンテキストが別の EVM コンテキストの実行結果を検証できるようにするメカニズムを提供します。
プリコンパイルされたコントラクトは、次の 3 つの入力パラメータを受け入れます。
pre_state: 実行前の32バイトの状態ルート
post_state: 実行後の32バイトの状態ルート
witness_trace: トランザクションと状態アクセスの証明を含む実行トレース
プリコンパイルされたコントラクトの中核はアサーションです。これは、pre_state からトレースを実行すると post_state を取得できるかどうかを検証します。状態遷移関数が有効な場合、プリコンパイルされたコントラクトは true を返します。
バリデーターが計算を再実行し、状態遷移の正確性を検証できるように、実行トレースはすべてのバリデーターで利用可能である必要があります (BLOB または calldata の形式で)。この事前コンパイルされた契約は証明を入力として受け取らないことに注意してください。これは、プロトコル自体は特定の証明システムを強制するのではなく、代わりに P2P ネットワークのゴシップ チャネルを通じてさまざまな種類の証明を伝播することを意味します。
ガス料金モデル
Ethereum のコンピューティング リソースは限られているため、これらのリソースを管理するために Gas メカニズムが使用されます。 EXECUTE プリコンパイル済みコントラクトは、コンピューティング リソースを管理するための Gas 課金モデルを実装します。
基本コスト:プリコンパイルされたコントラクトは、固定のガス料金EXECUTE_GAS_COSTと、実行軌跡で使用されたガスに現在のガス価格を乗じた金額を請求します。
累積ガス制限: EIP-1559 メカニズムと同様に、L1 ブロック内のすべての EXECUTE 呼び出しの合計ガス消費量を管理し、価格を設定します。
EXECUTE_CUMULATIVE_GAS_LIMIT: ブロック内のすべての EXECUTE 呼び出しの最大 Gas 制限。
EXECUTE_CUMULATIVE_GAS_TARGET: 効率的な価格設定のためのターゲット ガス使用量。
このモデルは、BLOB のデータ可用性 (DA) の価格設定メカニズムに似ています。
ローカル ロールアップと L1 の SNARK 化の概念は混同されることが多いので、覚えておくことが重要です。 SNARK 化された L1 は、SNARK 化された実行 (zkEVM など) とコンセンサス (Beam など) を通じて Gas 制限を排除し、L1 パフォーマンスを向上させる垂直スケーリング方法です。ローカル ロールアップは水平スケーリングL1 であり、プログラム可能な方法で任意の数の EVM コピーを作成して、より高いスケーラビリティを実現できます。
ローカルロールアップの方が有利なのはなぜですか?
1. セキュリティ
現在のロールアップ設計では、セキュリティ協議会がチェーンを更新して潜在的な脆弱性に対処する必要があります。ローカル ロールアップは、ガバナンスのために Ethereum の <Social Consensus> に依存しています。メンテナンスと修正は Ethereum コミュニティが担当するため、オペレーターは脆弱性について心配する必要はありません。
2. L1同期構成を簡素化する
L1 ベースのロールアップは同期構成の実現に近づいていますが、L1 ブロックと L2 ブロックを同じビルダーによって同時に構築する必要があります。ローカル ロールアップは、追加の信頼の仮定なしに、EXECUTE プリコンパイル済みコントラクトを通じて別のローカル ロールアップのステータスを直接検証できます。
3. 前方互換性
L1 EVM が進化するにつれて、ローカル ロールアップは個別の適応を必要とせずにすべての改善を自動的に継承し、Ethereum の開発パスとの長期的な互換性を実現します。
初期実装: 再実行
ローカル ロールアップのコンテキストでは、再実行が初期実装と見なされます。再実行とは、SNARK 証明に頼るのではなく、バリデータがトランザクション トレースを直接実行して、ローカル ロールアップの状態遷移が有効かどうかを確認することを指します。 EXECUTE_CUMULATIVE_GAS_LIMIT が小さく保たれている場合、この再実行はバリデーターにとって管理可能なものになります。
実行の最適化: リアルタイム検証
再実行モードでは、バリデータはすべてのトランザクションを自身で処理する必要があり、スループットはEXECUTE_CUMULATIVE_GAS_LIMITパラメータによって制限されます。リアルタイム証明では、バリデーターはすべてのトランザクションを再実行せずに証明を検証するだけでよいため、この制限を大幅に改善できます。
業界がリアルタイム認証へと急速に移行するにつれて、ローカル ロールアップの認証ウィンドウを拡大するための措置を講じる必要があります。証明時間を増やすには、現在の Ethereum ブロック処理構造を調整する必要があります。
認証期間を延長するにはどうすればいいですか?
現在のイーサリアムブロック処理フロー
現在の構造では、次のブロックに入る前に、以下のすべてのステップを 12 秒以内 (4 秒ごとに 1 ステージ) に完了する必要があります。
ブロックN提案取引
ブロックを検証/確認する前に、次の作業を完了する必要があります。
すべての取引を実行する
状態変化の計算
状態ルートを計算する (stateRoot)
取引の領収書とログを計算する
上記のすべての手順が完了した後にのみ、ブロックを検証および確認することができます。
現在のプロセスでは、L1 との同期構成可能性を実現するには、証明を 4 秒以内に完了する必要があります。しかし、ZK テクノロジーはまだ成熟しておらず、4 秒以内に Ethereum ブロックの証明を生成することはできないため、証明プロセスにさらなる柔軟性を導入する必要があります。
ローカルロールアップにさらに証明時間を与えるためには、Ethereum の現在のブロック処理構造を調整する必要があります。例えば：
state_root 計算の遅延:クリティカル パスから state_root 計算を削除し、バリデーターのアイドル時間中に計算されるようにします。
遅延実行:ブロック検証をトランザクション実行から分離し、コンセンサスの効率を最適化しながら、証明生成に多くの時間を提供します。
よくある質問
Taiko はどのような種類の証明を使用するのでしょうか?
単一の種類の証明は使用されません。私たちは証明者とクライアントの両方に多様性を求めています。検証者は、自分の選択に基づいて、どの証明方法を使用するかを主観的に決定できます。
さまざまな証明タイプについては、EthProofs を参照してください。
誰が証明を生成するのでしょうか?
誰でも証明を生成できます。証明者が 1 人しかいない場合でも、チェーンは正常に機能します。未解決の問題が残っています。それは、プロトコル レベルで証明者にインセンティブを与える方法です。
証明の間で合意が得られるでしょうか?
しません。証明はオンチェーンで合意されるのではなく、オフチェーンで伝播されます。ネットワークで必要なのは、有効な証明がどこかに存在するというコンセンサスだけです。
