タイトル：A step-by-step roadmap for scaling rollups with calldata expansion and sharding

著者：Vitalik Buterin、イーサリアム共同創設者

編纂：南風、Unitimes

イーサリアムにとって、Rollupsは短期的、中期的、さらには長期的に信頼を必要としない唯一のスケーラビリティソリューションです。イーサリアムL1の取引手数料は数ヶ月間高止まりしており、今こそ全エコシステムをRollupsに移行させるために必要な行動を取ることが急務です。Rollupsは多くのイーサリアムユーザーの手数料を大幅に削減しました：l2fees.infoサイトでは、OptimismとArbitrumネットワークの手数料がイーサリアムの基盤レイヤーよりも約3-8倍低いことがよく示されています。また、zk-Rollupsはより優れたデータ圧縮を提供し、署名を含める必要がないため、手数料はイーサリアムの基盤レイヤーよりも約40-100倍低くなります。

しかし、多くのユーザーにとって、これらの（Rollups内の）手数料でさえも高すぎるのです。長い間、データシャーディングは現在のRollupsの長期的な不足を解決するためのソリューションと見なされてきました。データシャーディングは、イーサリアムチェーン上でRollupsに約1-2MB/sの専用データスペースを追加することが期待されています。本稿では、このソリューションを実現するための実用的な道筋を説明し、Rollupsのデータスペースをできるだけ早く解放し、時間の経過とともに追加のスペースとセキュリティを増加させる方法を示します。

ステップ1: 取引calldataの拡張

現在のRollupsは取引calldataを使用しています。したがって、各Rollupsチームに追加の作業をさせることなく、短期間でRollupsの容量を増やしコストを削減したい場合、取引calldataのガスコストを削減する必要があります。現在の平均ブロックサイズは、イーサリアムネットワークの安定性を脅かすほどの大きさには達していないため、これを安全に行うことは可能です。ただし、非常に不安全なエッジケースを防ぐために、いくつかの追加のロジックが必要になるかもしれません。

EIP-4488提案を参照してください。または、別の（より簡単で効果が穏やかな）EIP-4490提案を参照してください。

• EIP-4488：

https://github.com/ethereum/EIPs/pull/4488

• EIP-4490：

https://github.com/ethereum/EIPs/pull/4490

EIP 4488は、各スロットでRollupsに利用可能なデータスペースを理論的に最大約1MBに増加させ、Rollups上のコストを約5倍削減することができるはずです。これは後のステップよりも早く実現可能です。

ステップ2: 数本のシャード

同時に、「適切な」シャーディングを導入するための作業を開始できます。完全な（機能的な）形でシャーディングを実現するにはまだ長い時間がかかりますが、私たちができることはそれを段階的に実現し、各ステップから利益を得ることです。最初に実現すべきは、シャーディング仕様の「ビジネスロジック」です。ただし、最初にオンラインになるシャードの数を非常に少なく（例えば4本のシャード）する必要があります。これにより、シャーディングネットワークの大多数の課題を回避できます。各シャードは自分のサブネットワーク内でブロードキャストされます。デフォルトでは、バリデーターは委員会を信頼しますが、彼らが望む場合、各サブネットワークで選択することができます。ただし、彼らが信号ブロックで確認されたシャードブロックのすべてのデータを見た場合に限ります。

シャーディング仕様自体は特に難しくありません。最近リリースされたAltairハードフォークと同様の規模のテンプレートコードの変更が必要です（Altairの信号変更仕様ファイルは728行、シャーディングの信号変更仕様ファイルは888行です）。したがって、Altairの実装と展開と同様のタイムフレーム内で実現できると合理的に予測できます。

シャーディングデータが実際にRollupsで使用できるようにするためには、Rollupsはその証明をシャーディングデータに組み込む必要があります。2つの選択肢があります：

1. BEACONBLOCKROOTオペコードを追加する。Rollupsは、歴史的な信号チェーンブロックのルートに根ざしたマークル証明を検証するためのコードを追加します。

2. 将来の状態と歴史的アクセスのためのプリコンパイルを追加します。これにより、コミットメントスキームが将来変更される場合、Rollupsはコードを変更する必要がなくなります。

これにより、各スロットのRollupデータスペースが約2MB（各シャード250kB * 4本のシャード、さらに上記のステップ1で拡張されたcalldata）に増加します。

ステップ3: N本のシャード、委員会によって保護される

アクティブなシャードの数を4本から64本に増やします。この時点で、シャーディングデータはサブネットワークに入るため、その時のP2P層は、より多くのサブネットワークに分割するのが実行可能なほど十分に堅牢でなければなりません。データの可用性のセキュリティは、大多数（バリデーター）が誠実であるという仮定に基づき、委員会のセキュリティに依存します。

これにより、各スロットのRollupデータスペースが約16MB（各シャード250kB * 64本のシャード）に増加します。この時点でRollupsはすでにイーサリアム実行チェーンから移行していると仮定します。

ステップ4: データ可用性サンプリング（DAS）

データ可用性サンプリング（DAS）を追加して、より高いレベルのセキュリティを確保します。これにより、大多数（バリデーター）が不誠実な攻撃を行った場合でも、ユーザーは保護されます。データ可用性サンプリングは段階的に行うことができます。最初に、制約のない方法でネットワークがそれをテストできるようにし、その後、信号ブロックを受信するための必要条件としてそれを導入し、特定のクライアントで先に行うことも可能です。

データ可用性サンプリングが完全に導入されると、シャーディングの展開が完了します。

シャーディングベースのOptimistic RollupsとZK Rollups

現在のイーサリアムと、シャーディングを実施した後のイーサリアムの主な違いは、シャーディングの世界では、Rollupデータが実際にスマートコントラクトにRollupブロックを提出する取引の一部になることが不可能であるということです。逆に、Rollupデータの公開とRollupブロックの提出は分けられなければなりません。最初に、データ公開はデータをチェーン上（つまりシャーディングチェーンに）配置し、その後ブロック提出はブロックヘッダーと基盤データへの証明を提出します。

OptimismとArbitrumは、Rollupブロックの提出に二段階設計を使用しているため、両者にとっては小さなコード変更で済みます。

ZK Rollupsに関しては、取引を提出するためにデータを直接操作する証明を提供する必要があるため、少し厄介です。彼らはZK-SNARKを通じてシャーディング内のデータが信号チェーン上のコミットメントと一致することを証明できますが、この操作は非常に高価です。幸いなことに、より安価な代替案があります。

もしそのZK-SNARKがBLS12-381に基づくPLONK証明であれば、彼らは単純にシャーディングデータのコミットメントを入力としてパッケージ化できます。BLS12-381のシャーディングデータコミットメントはKZGコミットメントであり、PLONK内のコミットメントタイプと同じですので、公共入力として直接証明に渡すことができます。

もしZK-SNARKが異なるメカニズムを使用している場合（あるいはBLS12-381 PLONKであっても、より大きな信頼設定を持っている場合）、それは独自のデータコミットメントを含め、等価性証明を使用してその証明内のコミットメントが信号チェーン内のコミットメントと同じデータに対するものであることを検証できます。

シャーディングの世界で、誰が歴史データを保存するのか？

データスペースを増やすための必要条件は、イーサリアムコアプロトコルが合意に達したすべてのデータを永続的に維持する責任を取り除くことです。なぜなら、これらのデータ量は非常に大きいためです。例えば：

1. EIP-4488が理論的にもたらす最大チェーンサイズは、12秒ごとのスロットで約1,262,861バイト、つまり年間約3.0TBですが、実際には年間約250-1000GBになる可能性が高いです。特に初期段階では。

2. 4本のシャード（各スロット1MB）は、年間約2.5TBの追加をもたらします。

3. 64本のシャード（各スロット16MB）は、年間約40TBのストレージをもたらします。

ほとんどのユーザーのハードドライブのサイズは256GBから2TBの間であり、1TBが中央値のようです。以下の図は、コンピュータのハードドライブの容量に関する内部調査の結果です：

これは、ユーザーが現在ノードを実行できることを意味しますが、このロードマップのいずれかの部分が変更されずに実施される場合、ユーザーはノードを実行できなくなるでしょう。もちろん、より大きなドライブも利用可能ですが、ユーザーはそれを購入するために努力しなければならず、ノードを運営する複雑さが大幅に増加します。現在の主要な解決策はEIP-4444であり、この提案はノードオペレーターが1年以上のブロックまたはレシートを保存する責任を排除します。シャーディングの場合、この1年の期間はさらに短縮される可能性が高く、ノードは自分が積極的に参加しているサブネットワーク上のシャードのみを担当する必要があります。

これにより、1つの疑問が生じます：イーサリアムコアプロトコルがこれらのデータを保存しない場合、誰が保存するのでしょうか？

まず重要なのは、シャーディングがあってもデータ量はそれほど大きくないということです。はい、年間40TBは「デフォルト」の消費ハードウェアを運営する個人の能力を超えています（実際、年間1TBでもそうです）。しかし、いくつかのリソースを投入し、これらのデータを保存する方法を見つけることを望む人にとっては、許容範囲内です。現在、48TBのHDD（ハードドライブ）の価格は1729ドル、14TBのものは約420ドルです。ステーキング報酬を得るために、1つの32ETHバリデーターのスロットを運営している人は、シャーディング実施後の全チェーンを保存するために支払うことを望むかもしれません。したがって、実際には「誰も特定のシャードのいくつかの歴史データを保存しないために、これらのデータが完全に失われる」という状況は不可能に思えます。

では、誰がこれらのデータを保存するのでしょうか？私のいくつかの考え：

• 個人および機関のボランティア；
• ブロックエクスプローラー（etherchain.org、etherscan.io、amberdata.ioなど）は、すべてのデータを保存することは間違いありません。なぜなら、ユーザーにデータを提供することが彼らのビジネスモデルだからです。
• Rollup DAOsは、参加者に歴史データを保存し、彼らのRollupに関連するデータを提供するために指定し、支払います。
• 歴史データはトレントを通じてアップロードおよび共有できます。
• クライアントは自発的にブロックチェーンの0.05%の歴史データをランダムに保存することを選択できます（エラー訂正コードを使用して、同時に多くのクライアントがオフラインになった場合にのみ小さなデータが失われるようにします）。
• Portal Network内のクライアントは、ブロックチェーンの歴史データの一部をランダムに保存し、Portal Networkは自動的にそのデータを保存しているノードにデータリクエストを導きます。
• プロトコル内で歴史データの保存を奨励することができます。
• The Graphのようなプロトコルは、クライアントがサーバーに料金を支払い、歴史データとその正当性を証明するマークル証明を取得するインセンティブ市場を作成できます。これにより、人々や機関が歴史データを保存するサーバーを運営し、必要に応じてこれらのデータを提供することが奨励されます。

これらの解決策のいくつか（個人および機関のボランティア、ブロックエクスプローラー）はすでに利用可能です。また、現在のP2Pトレントシーンは、主にボランティアによって駆動され、大量のコンテンツを保存するエコシステムの優れた例です。他のプロトコルベースの解決策はより強力ですが、インセンティブメカニズムを提供するため、開発により長い時間がかかるかもしれません。長期的には、これらのL2プロトコルを通じて歴史データにアクセスすることは、現在のイーサリアムプロトコルを通じてアクセスするよりも効率的である可能性があります。