イーサリアムが真の「世界のコンピュータ」になりたいのであれば、拡張性は常に避けては通れないテーマの 1 つであり、スケーラビリティ、セキュリティ、分散性を同時に備えている必要があります。時間は業界では「ブロックチェーンの不可能な三角形」として知られており、業界全体でまだ解決されていない大きな問題です。
しかし、2021年末、イーサリアムの研究者兼開発者のダンクラッド・ファイスト氏は、イーサリアムの新しいシャーディング・ソリューションであるダンクシャーディングを提案したが、これは「ブロックチェーンの不可能な三角形」に革命的な解決策をもたらしたようで、ゲーム業界全体のルールさえ書き換えられる可能性がある。 。
この調査レポートでは、イーサリアムの新しいシャーディングソリューションである Danksharding とは何か、そしてその起源について分かりやすく説明します。私がこの研究レポートを書いた理由は、ダンクシャルディングに関する中国語の記事が非常に少なく、そのほとんどが高い知識基準を必要とするからです。そのため、Spinach では、その背後にある複雑な原理をわかりやすく説明し、シンプルな言葉を使って、Web3 初心者でも Ethereum の新しいシャーディング ソリューション Danksharding とその前身のソリューション EIP-4844 を理解できるように努めます。
著者: ほうれん草ほうれん草
単語数: この調査レポートは10,000語以上あり、推定読了時間は21分です。
目次
イーサリアムはなぜ拡張する必要があるのでしょうか?
イーサリアムのスケーリングの背景
ブロックチェーンの不可能三角形とは何ですか?
Ethereum の現在のスケーリング ソリューションは何ですか?
イーサリアムの初期のシャーディングソリューションであるシャーディング1.0
Ethereum の POS コンセンサス メカニズムはどのように機能しますか?
初期のシャーディングソリューション Sharding1.0 とは何ですか?
初期のシャーディングソリューションである Sharding1.0 の欠点は何ですか?
Ethereum の新しいシャーディングソリューション Danksharding とは何ですか?
予備的ソリューション EIP-4844: プロトダンクシャーディング — 新しいトランザクションタイプBlob
Danksharding — 完全なスケーリングソリューション
データ可用性サンプリング
消失訂正符号
KZGコミットメント
提案者と施工者の分離
検閲耐性リスト(crList)
双スロットPBS(2スロットプロポーザ・ビルダー分離)
要約する
参考文献
イーサリアムはなぜ拡張する必要があるのでしょうか?
イーサリアムの創設者であるヴィタリック・ブテリンが2014年にイーサリアムのホワイトペーパー「次世代のスマートコントラクトと分散型アプリケーションプラットフォーム」を公開した後、ブロックチェーンは新しい時代を切り開きました。スマート コントラクトの誕生により、イーサリアム上で分散型アプリケーション (DApps) を作成できるようになり、NFT、DeFi、GameFi などの一連のイノベーションがブロックチェーン エコシステムにもたらしました。
イーサリアムのスケーリングの背景
Ethereum チェーンのエコシステムが成長するにつれて、Ethereum を使用する人が増え、Ethereum のパフォーマンスの問題が露呈し始めます。多くの人が同時にイーサリアム上でやりとりすると、ブロックチェーンが「混雑」します。これは、道路の信号機の時間が固定されていて、一定数の車両では交通渋滞が発生しないのと同じです。しかし、ラッシュアワー時に突然多くの車がこの道路に向かって走り、信号が青になったときに道路から出る車の数が、信号待ちで道路に新しく入る車の数よりはるかに少ないため、大きな渋滞が発生し、すべての車両がこの道路を通過する時間が長くなります。ブロックチェーンでも同様で、全員のインタラクションリクエストの確認時間が延長されます。
しかし、ブロックチェーンでは、時間がかかるだけでなく、ガス料金も高くなります(ガス料金とは、ブロックチェーン内のすべてのトランザクションをパッケージ化して処理する責任を持つマイナーに支払われる労働料金と解釈できます)。マイナーは最高入札額の取引を優先するため、相互作用リクエストの確認をより早く得るために全員がガス料金を引き上げ、「ガス戦争」を引き起こします。よく知られている事例としては、2017年にNFTプロジェクトであるCryptoKittiesの人気が爆発し、ガス料金が1回のやり取りあたり数百ドルにまで上昇したケースがある。 Ethereum での 1 回のやり取りに数十ドル、あるいは数百ドルものガス料金がかかるのは非常に高価です。
ガス料金が高額になる主な理由は、イーサリアムのパフォーマンスが既存ユーザーのインタラクションニーズを満たせなくなったことです。パフォーマンス計算の点では、イーサリアムはビットコインとは異なります。ビットコインは転送情報を処理する単純な台帳であるため、TPS は 1 秒あたり 7 トランザクションに固定されていますが、イーサリアムの場合は異なります。
Ethereum にはスマート コントラクトが存在するため、各トランザクションの内容が異なるため、各ブロックが処理できるトランザクション数 (TPS) は、ブロックに含まれるデータ量によって異なります。各トランザクションのデータ量は、リアルタイムの需要に応じて決定されます。イーサリアムのパフォーマンスの仕組みについて学ぶことができます。(以下の情報はダンクシャーディングを理解するのに役立ちますので、必ず読んでください。)
Ethereum はガス料金に応じてブロック内のデータ量の上限を設定します。ブロックには最大 3,000 万 GAS のデータが保存されます。
Ethereum では各ブロックのデータ量が大きくなりすぎないようにするため、各ブロックの Gas Target は 1500 万 Gas に設定されています。
Ethereum には、Gas のデータ消費標準のセットがあります。データの種類によって消費される Gas の量は異なります。ただし、当社の推定によると、各ブロックのサイズは約 5kb ~ 160kb で、ブロックの平均サイズは約 60 ~ 70kb です。
ブロックのガス消費量がガスターゲット(1500万ガス)を超えると、次のブロックの基本料金は12.5%高くなります。低い場合は基本料金が減額されます。このメカニズムは、取引のピーク時間帯に混雑を緩和するためにコストを増やし、取引の少ない時間帯に取引を増やすためにコストを減らすことができる、自動化された動的調整メカニズムです。
上記の仕組みを理解することで、Ethereum の TPS が変動していることがわかります。 **ブロックチェーンブラウザを使用して各ブロックのトランザクション数を確認し、おおよその TPS を計算できます。下の図によると、ガスターゲットに基づいてブロックには平均約 160 件のトランザクションがあり、最高では 300 件を超えるトランザクションに達することがわかります。各ブロックの 12 秒のブロック時間に基づくと、TPS は約 13 ~ 30 件のトランザクションになりますが、現在の知識によれば、Ethereum の TPS は 1 秒あたり最大 45 件のトランザクションに達する可能性があります。

画像ソース:メインネット | Ethereum 2.0 用ビーコンチェーンエクスプローラー(フェーズ 0) – BeaconScan
1秒間に数万件の取引を処理できる世界的に有名な取引システムVISAを例に挙げると、「世界のコンピューター」を目指すイーサリアムは、1秒間に最大45件の取引しか処理できず、これはあまりにも非力です。そのため、イーサリアムは早急に性能問題を解決するために能力を拡大する必要があり、これはイーサリアムの将来に関係しているが、ブロックチェーン業界には「不可能三角形」が存在するため、拡大は容易な作業ではない。
ブロックチェーンの不可能三角形とは何ですか?
「ブロックチェーンの不可能三角形」とは、パブリックブロックチェーンが分散化、セキュリティ、スケーラビリティという3つの特性を同時に満たすことができないという事実を指します。
分散化: ノードの分散化の度合いを指します。ノードの数が増えるほど、分散化が進みます。
セキュリティ: ブロックチェーン ネットワーク全体のセキュリティを指します。攻撃コストが高ければ高いほど、安全になります。
スケーラビリティ: ブロックチェーンのトランザクション処理パフォーマンスを指します。 1 秒あたりに処理できるトランザクションの数が多いほど、スケーラビリティが高まります。
これら 3 つのポイントの重要性を見ると、分散化とセキュリティが最も重視されていることがわかります。分散化はイーサリアムの基礎です。分散化により、イーサリアムは中立性、検閲耐性、オープン性、データの所有権、そしてほぼ破られないセキュリティを実現しています。セキュリティの重要性は自明ですが、Ethereum のビジョンは、分散化とセキュリティを維持しながらスケーラビリティを実現することです。これを実現することの難しさは想像に難くないことから、「ブロックチェーン不可能三角形」とも呼ばれています。

画像ソース: Ethereum Vision |イーサリアム
Ethereum の現在のスケーリング ソリューションは何ですか?
「ブロックチェーン不可能トライアングル」において、イーサリアムが拡張を実現するための前提は、分散化とセキュリティを確保することであることはわかっています。分散化とセキュリティを確保するため、拡張時にノードの容量要件を過度に増やしてはなりません。ノードはイーサリアムネットワーク全体を維持する上で不可欠な役割であるため、要求の高いノードは、より多くの人がノードになることを妨げ、ネットワークの集中化をますます進めてしまいます。もちろん、ノードのしきい値が低いほど良いです。低閾値ノードにより、より多くの人が参加できるようになり、Ethereum はより分散化され、安全になります。
現在、イーサリアムにはレイヤー 2 とシャーディングという 2 つの拡張計画があります。レイヤー 2 は、基盤となるブロックチェーン (レイヤー 1) を拡張するためのオフチェーン ソリューションです。原則としては、ブロックチェーンのオフチェーン上でリクエストを実行することです。レイヤー2 ソリューションはいくつかあります。この調査レポートでは、Layer2 ソリューションの 1 つである Rollup にのみ焦点を当てています。Rollup の原理は、数百のトランザクションをパンケーキのように 1 つのオフチェーン トランザクションにパッケージ化し、Ethereum に送信して容量拡張を実現することです。この方法により、イーサリアムをすべての人にアップロードするためのコストは非常に低くなり、同時にイーサリアムのセキュリティも継承されます。
Rollup は現在、Optimism Rollup と ZK Rollup (ゼロ知識証明ロールアップ) の 2 種類に分かれています。これら 2 つのロールアップの違いは、Optimism Rollup ではすべてのトランザクションが正直で信頼できると想定し、多数のトランザクションを 1 つのトランザクションに圧縮して Ethereum に送信するという点だけです。提出後、一定期間(チャレンジ期間 - 現在は 1 週間)が設けられ、誰でも質問したり、トランザクションの信頼性を確認するためのチャレンジを開始したりできますが、ユーザーが OP Rollup の ETH を Ethereum に転送したい場合は、最終確認を得るためにチャレンジ期間が終了するまで待つ必要があります。
ZK Rollup は、すべてのトランザクションが有効であることを証明するゼロ知識証明を生成し、すべてのトランザクションが実行された後の最終的な状態の変更を Ethereum にアップロードします。 Optimism Rollupと比較すると、ZK Rollupの方が有望です。 ZK Rollup では、Optimism Rollup のように、圧縮されたトランザクションの詳細をすべてアップロードする必要はありません。ゼロ知識証明と最終的な状態変更データをアップロードするだけで済みます。つまり、スケーラビリティの点では OP Rollup よりも多くのデータを圧縮でき、OP Rollup のように 1 週間に及ぶチャレンジ期間を待つ必要がありません。しかし、ZK Rollupの最大の欠点は開発が非常に難しいことであり、短期的にはOptimism Rollupが大きなL2市場を占めることになるでしょう。
Layer2 に加えて、この記事の主役である Sharding という別の拡張ソリューションがあります。 Layer2 はトランザクションを Ethereum オフチェーンに置いて処理することが分かっています。しかし、Layer2がどのようにデータを処理しても、Ethereum自体のパフォーマンスは変わらないため、Layer2が達成できる拡張効果は実際にはそれほど大きくありません。
シャーディングはイーサリアムのレイヤー1レベルでの拡張を実現するものですが、イーサリアム上で拡張を実現する前提はイーサリアムの分散化とセキュリティを確保することにあるため、ノードへの負担をあまり増やすことはできません。
シャーディングの具体的な実装計画は、Ethereum コミュニティで常に議論されてきました。その最新の計画が、この記事の主題である Danksharding です。 Danksharding が最新のシャーディング プランであることも言及されています。 Danksharding について説明する前に、以前のシャーディング計画がどのようなものか、なぜ採用されなかったのかについても簡単に紹介します。
イーサリアムの初期のシャーディングソリューションであるシャーディング1.0
Sharding 1.0 ソリューションについて説明する前に、まず Ethereum の現在の POS コンセンサス メカニズムがどのように機能するかを紹介する必要があります。これは、Sharding 1.0 ソリューションと Danksharding を理解するために必要な前提知識だからです。 Sharding 1.0 ソリューションについて説明するときに簡単にまとめます (大まかに何をすればよいかを知っておくだけで十分です)。
Ethereum の POS コンセンサス メカニズムはどのように機能しますか? [7]
コンセンサスメカニズムとは、ネットワークを維持するブロックチェーン内のすべてのノードが合意に達することを可能にするシステムです。その重要性は自明です。 2022年9月15日、イーサリアムはイーサリアム2.0アップグレードフェーズの「マージ」を完了しました。つまり、POWプルーフオブワークのイーサリアムメインネットとPOSプルーフオブステークメカニズムのビーコンチェーンが統合されました。 POS プルーフ・オブ・ステーク メカニズムは POW プルーフ・オブ・ワーク メカニズムに正式に取って代わり、イーサリアムのコンセンサス メカニズムになりました。
POW プルーフオブワークのメカニズムでは、マイナーが計算能力を積み重ねてブロックを生成する権利を競うことがわかっています。 POS プルーフオブステークの仕組みでは、マイナーは 32 ETH をステークしてイーサリアムの検証ノードになることで、ブロックを生成する権利を競います (ステーキングの方法についてここでは詳しく紹介しません)。
コンセンサスメカニズムの変更に加えて、イーサリアムのブロック時間も以前の変動ブロック時間から固定時間に変更され、スロットとエポックの 2 つの単位に分かれています。スロットは 12 秒、エポックは 6.4 分です。エポックには 32 個のスロットが含まれます。簡単に言うと、12秒ごとに1つのブロックが生成され、6.4分を1サイクル(エポック)として32個のブロックが生成されます。
マイナーが検証ノードになるために 32 ETH を拠出すると、ビーコン チェーンはランダム アルゴリズムを使用して、ブロックをパッケージ化するブロック生成ノードとして検証ノードを選択します。ブロックを生成するノードは、ブロックごとにランダムに選択されます。同時に、各エポックにおいて、ビーコン チェーンは、すべての検証ノードを、ブロックごとに少なくとも 128 個の検証ノードで構成される「委員会」のグループに均等かつランダムに割り当てます。
つまり、各ブロックには全ノードの検証ノード数の 1/32 が割り当てられ、これらの検証ノードで構成される「委員会」は、各ブロック生成ノードによってパッケージ化されたブロックを検証し、投票する必要があります。ブロック生成ノードがブロックをパッケージ化するときに、検証ノードの 3 分の 2 以上が賛成票を投じれば、ブロックは正常に生成されます。

初期のシャーディングソリューション Sharding1.0 とは何ですか? [7]
初期のシャーディングソリューションであるSharding1.0の設計コンセプトでは、Ethereumは元々1つのメインチェーンから最大64のシャードチェーンまで設計され、複数の新しいチェーンを追加することで拡張を実現していました。このスキームでは、各シャード チェーンが Ethereum データを処理し、それをビーコン チェーンに引き渡す役割を担い、ビーコン チェーンは Ethereum 全体の調整を担当します。各シャード チェーンのブロック ノードと委員会は、ビーコン チェーンによってランダムに割り当てられます。

ビーコン チェーンとシャード チェーンはクロスリンクを通じてリンクされます。ビーコン チェーンのブロックは同じブロックのシャード ブロックにハッシュ値を与え、次にシャード ブロックはこのハッシュ値を次のビーコン ブロックに与えてクロスリンクを実現します。失敗した場合は、次のビーコン ブロックに渡されます。

初期のシャーディングソリューションである Sharding1.0 の欠点は何ですか?
簡単に言えば、シャーディング 1.0 ソリューションは、Ethereum を多数のシャード チェーンに分割してデータをまとめて処理し、そのデータをビーコン チェーンに渡して拡張を実現することですが、このソリューションには多くの欠点があります。
**開発の難しさ: **正常な動作を確保しながら Ethereum を 64 個のシャード チェーンに分割することは技術的に非常に困難であり、システムが複雑になるほど、予測できない脆弱性が生じる可能性が高くなります。一度問題が発生すると、修復するには多大な手間がかかります。
**データ同期の問題: **ビーコン チェーンは、エポックごとに検証を担当する「委員会」を再編成します。したがって、検証ノードの再割り当てのたびに、大規模なネットワーク データ同期が発生します。これは、ノードが新しいシャード チェーンに割り当てられた場合、このシャード チェーンのデータを同期する必要があるためです。ノードのパフォーマンス帯域幅は変化するため、指定された時間内に同期が完了することを保証することは困難です。しかし、ノードがすべてのシャードチェーンのデータを直接同期できるようにすると、ノードの負担が大幅に増加し、Ethereum はますます中央集権化されます。 [2]
**データ量増加の問題: **Ethereum の処理速度は大幅に向上しましたが、複数のシャード チェーンによるデータの同時処理により、保存されるデータの量も大幅に増加しました。イーサリアムのデータ量の拡大率はこれまでよりも何倍も速くなり、ノードに対するストレージ性能の要件も増加し続け、より集中化が進むことになります。
**MEV 問題を解決する方法はありません:** 最大抽出可能値 (MEV) とは、ブロック内のトランザクションを追加および除外し、ブロック内のトランザクションの順序を変更することで、標準のブロック報酬とガス料金を超えてブロック生成から抽出できる最大量です。 Ethereum でトランザクションが開始されると、トランザクションはメモリプール (実行されるトランザクションを格納するプール) に配置され、マイナーによってパッケージ化されるのを待ちます。すると、マイナーはメモリプール内のすべてのトランザクションを確認できるようになり、マイナーは大きな力を持つことになります。マイナーはトランザクションの包含、除外、順序を制御します。誰かが、トランザクションプール内のトランザクションの順序を調整するためにマイナーに賄賂を渡してガス料金をさらに支払って利益を得た場合、これが最大抽出可能値 MEV になります。 [6]
例えば:
「サンドイッチ攻撃」または「クランプ攻撃」と呼ばれる MEV 方式があります。この MEV 抽出方法は、チェーン上の大規模な DEX トランザクションを監視するためのものです。たとえば、誰かが Uniswap で 100 万ドル相当のコテージ通貨を購入したいとすると、この取引によってこのコテージ通貨の価格が大幅に上昇します。このトランザクションがメモリプールに入れられると、監視ロボットはこのトランザクションを検出できます。この時、ロボットは、このブロックをパックするマイナーに賄賂を渡して、このコテージ通貨の購入操作をこの人の前に置き、この人の購入操作の後に売却操作を行い、ちょうどサンドイッチのように、大きな DEX 取引を行う人を真ん中に挟みます。このように、「サンドイッチ攻撃」を仕掛けた者は、この者の大規模な取引によってコテージ通貨の利益を得る一方、大規模な取引を行った者は損失を被ることになる。 [6]
MEVの存在は、Ethereumにいくつかの悪影響ももたらしています。例えば、「サンドイッチ攻撃」による損失やユーザーエクスペリエンスの悪化、フロントランナー競争によるネットワークの混雑、ガス料金の高騰、さらにはノードの集中化の問題などです。これは、より多くの MEV 価値を獲得したノードが、収入を通じてネットワーク内でより大きなシェアを占め続けることができるためです。収入が増える = より多くの ETH = より多くのステーク権、そして MEV によってもたらされる高いコスト (ネットワークの混雑とフロントランニングによる高い GAS) により、Ethereum ユーザーは損失を被り続けることになります。 MEV の値がブロック報酬を大幅に上回った場合でも、Ethereum 全体のコンセンサスとセキュリティが不安定になります。 Sharding 1.0 ソリューションでは、MEV によってもたらされる一連の問題を解決できません。
2021年末にイーサリアムの研究者兼開発者であるDankrad Feist氏が新しいイーサリアムシャーディングソリューションであるDankshardingを提案した後、Dankshardingはシャーディング拡張を実現するための最良のソリューションとしてイーサリアムコミュニティから満場一致で認められ、イーサリアムに新たな革命をもたらす可能性さえあります。
Danksharding は、新しいシャーディング アイデア、つまり Layer2 の Rollup に基づくシャーディング ソリューションを使用して、Ethereum のスケーラビリティ問題を解決します。この新しいシャーディング ソリューションは、ノードの負担を大幅に増やすことなくスケーラビリティの問題を解決し、分散化とセキュリティを確保しながら、MEV の悪影響も解決できます。
下の図から、次の Ethereum アップグレード段階「The Surge」と「The Scourge」の目標は、Rollup で 100,000 以上の TPS を達成し、MEV やその他のプロトコル リスクによってもたらされる集中化を回避することであることがわかります。

画像 / 出典: vitalik.eth 翻訳: ethereum.cn
では、Danksharding はどのようにして Ethereum のスケーラビリティ問題を解決するのでしょうか?まずは Danksharding の前身である EIP-4844: Proto-Danksharding から始めましょう。
予備的ソリューション EIP-4844: プロトダンクシャーディング — 新しいトランザクションタイプBlob
EIP-4844 は、Ethereum に新しいトランザクション タイプである Blob トランザクションを導入します。この新しいトランザクション タイプ Blob は、Ethereum に追加のプラグイン データベースを提供できます。
BLOBのサイズは約128KBです
トランザクションは最大2つのBLOB(256KB)を運ぶことができます
各ブロックには 1 MB のターゲット BLOB が 8 個あり、最大 2 MB の BLOB を 16 個収容できます (ターゲットの概念については、拡張の背景で説明されています)。
BLOB データは一時的に保存され、一定期間後に消去されます (現在コミュニティでは 30 日が推奨されています)

現在、各 Ethereum ブロックの平均サイズはわずか 85 KB 程度です。 Blob が Ethereum にもたらす追加のストレージスペースは膨大です。注目すべきは、イーサリアム誕生以来のすべてのイーサリアム台帳の合計データサイズはわずか約 1TB であり、Blob は毎年 2.5TB~5TB の追加データをイーサリアムにもたらす可能性があり、これはイーサリアム台帳全体のデータサイズの何倍にも相当するということです。
EIP-4844 で導入された Blob トランザクションは、Rollup 向けにカスタマイズされていると言えます。ロールアップデータは、Blob 形式で Ethereum にアップロードされます。追加のデータ スペースにより、Rollup はより高い TPS とより低いコストを実現できると同時に、Rollup が元々占有していたブロック スペースをより多くのユーザーに解放できます。
Blob データは一時的に保存されるため、データ量が急増してもノードのストレージ パフォーマンスに負担が増加することはありません。 1 か月分の Blob データのみが一時的に保存される場合、同期されるデータ量の観点から、各ブロック ノードは追加で 1MB ~ 2MB のデータをダウンロードする必要がありますが、これはノードの帯域幅要件にとって負担にはならないようです。データ保存の観点から見ると、ノードは約 200 ~ 400 GB (1 か月分) の固定量のデータをダウンロードして保存するだけで済みます。分散化とセキュリティを確保しながら、ノードの負担をわずかに増やすコストのみを支払います。その見返りとして、TPS の向上とコストの削減は数十倍、数百倍に及ぶと計算されます。これは、Ethereum のスケーラビリティの問題を解決するための優れたソリューションです。
データが消去され、ユーザーが以前のデータにアクセスしたい場合はどうなりますか?
まず第一に、イーサリアムのコンセンサス プロトコルの目的は、すべての履歴データの永続的な保存を保証することではありません。代わりに、他の分散型プロトコル向けに、非常に安全なリアルタイム掲示板と長期ストレージを提供することが目標です。掲示板の目的は、掲示板に投稿されたデータが十分な期間保持されるようにすることです。このデータを必要とするユーザーまたはプロトコルには、データをキャプチャして保存するのに十分な時間があります。したがって、このBlobデータを保存する責任は、Layer2プロジェクト関係者や分散ストレージプロトコルなどの他の役割に委ねられています。[3]
Danksharding — 完全なスケーリングソリューション
EIP-4844は、Rollupを中心としたイーサリアムの拡張の第一歩を実現しますが、EIP-4844によって達成される拡張効果は、イーサリアムにとって十分ではありません。完全な Danksharding ソリューションは、Blob が運ぶことができるデータ量をブロックあたり 1 ~ 2 MB から 16 MB ~ 32 MB にさらに拡張し、MEV によって引き起こされる問題を解決するための新しいメカニズムであるブロックプロデューサーパッケージャー分離 (PBS) を提案します。
次に、EIP-4844 に基づいて容量を拡大し続けるとどのような困難が生じるかを知る必要があります。
**ノードに過負荷がかかります: **EIP-4844 の 1〜2MB の BLOB によるノードへの負荷増加はまったく許容範囲内ですが、BLOB のサイズが 16 倍の 16〜32MB に増加すると、データ同期とデータ保存の両方の負荷によってノードに過負荷がかかり、Ethereum の分散化の度合いが低下します。
**データ可用性の問題: **ノードがすべての Blob データをダウンロードしない場合、データはチェーン上で公開されておらず、いつでもアクセスできないため、データ可用性の問題に直面します。たとえば、Ethereum ノードは Optimism Rollup 上のトランザクションに疑問を持ち、異議を申し立てたいのですが、Optimism Rollup はデータを渡しません。そうすると、元のデータがなければ、取引に問題があることを証明することはできません。したがって、データの可用性の問題を解決するには、データがいつでもオープンでアクセス可能であることを保証する必要があります。
では、Danksharding はこれらの問題をどのように解決するのでしょうか?
データ可用性サンプリング
Danksharding は、データの可用性を確保しながらノードの負担を軽減するソリューションとして、データ可用性サンプリングを提案しました。
データ可用性サンプリング(DAS)のアイデアは、Blob内のデータをデータフラグメントに分割し、ノードがBlobデータのダウンロードからBlobデータフラグメントのランダムチェックに変更することです。これにより、十分なノードがあり、分散化されていることを前提に、BlobデータフラグメントはEthereumの各ノードに分散されますが、完全なBlobデータはEthereum台帳全体に格納されます。
たとえば、Blob のデータが 10 個のフラグメントに分割され、ネットワーク全体に 100 個のノードがある場合、各ノードはランダムにデータ フラグメントを選択してダウンロードし、選択したフラグメントの番号をブロックに送信します。番号が付けられたフラグメントがすべてブロックに集められる限り、Ethereum はこの Blob のデータが利用可能であると想定し、フラグメントをつなぎ合わせることで元のデータを復元できます。ただし、100 個のノードのうちのいずれもが特定の番号のフラグメントを描画しないという極めて低い確率があり、そのためデータが欠落することになり、ある程度セキュリティが低下しますが、確率的には許容範囲内です。

Dankshardingは、データ可用性サンプリング(DAS)を実現するために、消失訂正符号とKZGコミットメントという2つの技術を使用しています。
消失訂正符号
Erasure Coding はコーディングのフォールト トレラント テクノロジです。消失訂正符号を使用してデータを分割すると、データフラグメントの 50% 以上しか利用できない場合でもすべての Ethereum ノードが元のデータを復元できるため、データ損失の可能性が大幅に減少します。具体的な実施原理は比較的複雑です。ここでは数式を使って例を挙げ、原理を大まかに説明します。[2]
まず関数f(x) = ax + bを構築し、4つのxの値をランダムに選択します。
m = f(0) = b、n = f(1) = a + bと仮定すると、a = n – b、b = mと結論付けられます。
p = f(2)、q = f(3)とすると、p = 2a + b = 2n – m、q = 3a + b = 3n – 2mとなる。
次に、4 つのフラグメント m、n、p、q がネットワーク全体のノード間に分散されます。
数式によれば、残りの 2 つの断片が何であるかを知るには、断片のうちの 2 つを見つけるだけで済みます。
nとmがわかれば、q=3n-2mとp=2n-mを直接計算できる。
q と p がわかったら、(2p=4n-2m)-(q=3n-2m) を引いて 2p-q=n を取得し、m を直接計算できます。
簡単に言うと、消去コードは数学的原理を使用して、Blob データを多数のデータ断片に分割します。 Ethereum ノードはすべてのデータフラグメントを収集する必要はありません。 Blob の元のデータを復元するには、フラグメントの 50% 以上を収集するだけで済みます。これにより、フラグメント収集が不十分になる確率が大幅に減少し、その確率は無視できるようになります。

KZGコミットメント
KZG コミットメントは、消去コードのデータ整合性問題を解決するために使用される暗号化技術です。ノードは、消去コードによってカットされた後のデータフラグメントをランダムにチェックするだけなので、ノードはデータフラグメントが実際に Blob の元のデータからのものであるかどうかを認識しないため、エンコードを担当するロールは、消去コードのデータフラグメントが実際に元のデータの一部であることを証明するために、KZG 多項式コミットメントも生成する必要があります。 KZG の役割は Merkle ツリーに多少似ていますが、形状が異なります。すべての KZG 証明は同じ多項式に基づいています。

Danksharding は、消去コードと KZG 多項式コミットメントを通じてデータ可用性サンプリング (DAS) を実装し、Blob によって運ばれる追加データが 16MB ~ 32MB に拡張された場合のノードの負担を大幅に軽減します。 Ethereum コミュニティは、データフラグメントをさらに削減して帯域幅とコンピューティング要件を削減する 2D KZG スキームと呼ばれるソリューションも提案していますが、コミュニティは、継続的に最適化および改善されている DAS の設計など、使用する特定のアルゴリズムについてまだ議論しています。
Ethereum では、Data Availability Sampling (DAS) によって、ノードの負担を軽減しながら Blob データ量を 16MB ~ 32MB に拡張するという問題が解決されていますが、元のデータを誰がエンコードするかという問題があるようです。
Blob の生データをエンコードする場合、エンコードを実行するノードが完全な生データを持っていることが前提条件となります。これを実現するには、ノードに高い要件が課せられます。前述のように、Danksharding は MEV によって引き起こされる問題を解決するために、新しいメカニズム **Blocker-Packager Separation (PBS)** を提案しました。実際、このソリューションは MEV 問題を解決するだけでなく、エンコードの問題も解決します。
提案者と施工者の分離
まず、データ可用性サンプリング (DAS) によって、Blob のノード検証の負担が軽減され、低構成かつ分散化された検証が実現されることがわかっています。ただし、このブロックを作成するには、完全な Blob データを取得してエンコードする必要があり、多くの Ethereum フルノードの要件が増加します。 Proposer-Packager Separation (PBS) は、ノードを Builder と Proposer の 2 つの役割に分割することを提案します。パフォーマンスの高いノードは Builder になることができ、パフォーマンスの低いノードは Proposer になることができます。
現在、Ethereum ノードには、フルノードとライトノードの 2 種類があります。フルノードは、トランザクションリストやブロック本体など、Ethereum 上のすべてのデータを同期する必要があります。フルノードは、ブロックのパッケージ化とブロックの検証という 2 つの役割を果たします。フルノードはブロック内のすべての情報を見ることができるため、ブロック内のトランザクションを並べ替えたり、追加したり、削除したりして MEV 値を取得できます。ライトノードはすべてのデータを同期する必要はなく、ブロック ヘッダーを同期してブロックを検証するだけで済みます。 [1]
プロポーザー・パッカー分離 (PBS) を実装した後:
高性能構成のノードはパッケージャー (ビルダー) になることができます。パッケージャーは、ブロックをエンコードして作成するための Blob データをダウンロードし、スポット チェックのために他のノードにブロードキャストする役割のみを担います。パッケージャー (ビルダー) の場合、同期されたデータ量と帯域幅に対する要件が高いため、比較的集中化されます。
パフォーマンス構成が低いノードがプロポーザーになることができます。提案者は、データの有効性を検証し、ブロック ヘッダーを作成してブロードキャストするだけで済みます。ただし、提案者にとっては、同期データの量と帯域幅の要件が低いため、分散化されます。

PBS は、パッケージングと検証の役割を分離することで、ノード間の分業を実現します。高パフォーマンス構成のノードは、エンコードと配信のためにすべてのデータをダウンロードする役割を担い、低パフォーマンス構成のノードはスポットチェックと検証を担当します。では、MEV 問題はどのように解決されるのでしょうか?
検閲耐性リスト(crList)
PBS はパッケージ化と検証の作業を分離しているため、パッケージ作成者 (ビルダー) は実際にトランザクションを検閲する能力がより高くなります。パッケージャーは、MEV を取得するために、特定のトランザクションを意図的に無視し、挿入したいトランザクションを任意に並べ替えて挿入することができますが、検閲防止リスト (crList) はこれらの問題を解決します。
検閲防止リスト(crList)の仕組み:[1]
ビルダーがブロックトランザクションをパッケージ化する前に、プロポーザーはまず、メモリプール内のすべてのトランザクションを含む検閲耐性リスト (crList) を公開します。
ビルダーは、crList内のトランザクションをパッケージ化して並べ替えることしか選択できません。つまり、ビルダーは独自のプライベートトランザクションを挿入してMEVを取得することはできず、意図的にトランザクションを拒否することもできません(ガス制限がいっぱいでない限り)。
ビルダーはトランザクション リストをパッケージ化した後、トランザクション リスト ハッシュの最終バージョンをプロポーザーにブロードキャストします。プロポーザーはトランザクション リストの 1 つを選択してブロック ヘッダーを生成し、ブロードキャストします。
ノードがデータを同期する場合、プロポーザーからブロック ヘッダーを取得し、次にビルダーからブロック本体を取得して、ブロック本体が最終的に選択されたバージョンであることを確認します。
「サンドイッチ攻撃」などの MEV の悪影響は、検閲耐性リスト (crList) を通じて解決され、ノードはプライベートトランザクションを挿入することで同様の MEV を取得できなくなります。

Ethereum の PBS に関する具体的な実装計画はまだ議論中ですが、現在のところ初期実装計画としてはデュアルスロット PBS が考えられます。
双スロットPBS(2スロットプロポーザ・ビルダー分離)
デュアルスロットPBSは入札モデルを使用してブロックを決定します。[2]
crList を受け取った後、ビルダーはトランザクション リストのブロック ヘッダーを作成し、入札を行います。
提案者は最終的に成功するブロックヘッダーとパッケージャー(ビルダー)を選択し、提案者は(有効なブロックが生成されたかどうかに関係なく)無条件に落札手数料を受け取ります。
検証委員会(委員会)は、勝利したブロックヘッダーを確認する
ビルダーは勝利ブロック本体を公開します
検証委員会は、当選したブロック本体を確認し、検証投票を実施します(合格すればブロックが生成されます。パッケージャーが意図的にブロック本体を提供しない場合は、ブロックは存在しないものとみなされます)
ビルダーはトランザクション順序を調整することで MEV を取得できますが、ダブルスロット PBS の入札メカニズムにより、これらのビルダー間で「巻き込み」が発生します。誰もがブロックに入札して競争しなければならない場合、MEV を通じて中央集権型パッケージャーが得る利益は継続的に圧迫され、最終的な利益は分散型提案者に分配されることになります。これにより、MEV を取得することで集中型パッケージャーがますます集中化されるという問題が解決されます。
しかし、2 スロット PBS には設計上の欠陥があります。この設計の名前には「2 スロット」が含まれており、これはスロットが 2 つあることを意味します。つまり、この方式では有効なブロック時間が 24 秒 (1 スロット = 12 秒) に延長されます。この問題をいかに解決するかは、Ethereum コミュニティで熱く議論されてきました。

要約する
Danksharding は、イーサリアムの「ブロックチェーンの不可能三角形」を解決する革新的なソリューションを提供します。つまり、イーサリアムの分散化とセキュリティを確保しながらスケーラビリティを実現します。
新しいトランザクション タイプ Blob は、プレソリューション EIP-4844: Proto-Danksharding を通じて導入されました。 Blob によって運ばれる 1MB ~ 2MB の追加データにより、Ethereum は Rollup でより高い TPS とより低いコストを実現できます。
データ可用性サンプリング (DAS) は、消失訂正符号化と KZG 多項式コミットメントを通じて実装され、ノードが一部のデータ フラグメントのみをスポット チェックしてデータの可用性を検証し、ノードの負担を軽減できるようにします。
DAS (Data Availability Sampling) を実装することで、Blob の追加データ量が 16MB ~ 32MB に拡張され、拡張効果がさらに高まります。
プロポーザ・パッカー分離 (PBS) により、ブロックの検証とパッケージ化の作業が 2 つのノード ロールに分離され、パッケージ化ノードの部分的な分散化と検証ノードの分散化が実現されます。
MEV の悪影響は、検閲防止リスト (crList) とダブルスロット PBS によって大幅に軽減されます。パッケージャーはプライベート トランザクションを挿入したり、トランザクションを検閲したりすることはできません。
何も予期せぬ事態が発生しなければ、Danksharding の前身ソリューションである EIP-4844 は、イーサリアムの上海アップグレード後のカンクン アップグレードで正式に実装される予定です。 EIP-4844 ソリューションが実装された後、最も直接的なメリットは、Layer2 のロールアップとロールアップ上のエコシステムになります。より高い TPS とより低いコストは、チェーン上の高頻度アプリケーションに非常に適しています。いくつかの「キラーアプリケーション」が誕生する可能性もあると想像できます。 Danksharding によって実現される集中型のブロック生成 + 分散型の検証 + 検閲防止は、イーサリアムにパブリック チェーンの物語の新たなラウンドをもたらすでしょう。レイヤー2に加えて、ダンクシャーディング後のモジュラーブロックチェーンとイーサリアムはどのような化学反応を生み出すのでしょうか?
Danksharding の実装によりゲームのルールが書き換えられ、Ethereum がブロックチェーン業界を新しい時代へと導くと信じています。
参考文献
[1] ブロックチェーンのデータ可用性、ストレージ拡張
[2] 新しいイーサリアムアップグレード計画を理解するための記事 Danksharding
[3] プロトダンクシャーディングFAQ – HackMD
[4] 「ダンクシャルディング」とは何でしょうか?
[5] V Godの推奨: イーサリアムのシャーディングロードマップをより深く理解するには、このレポートを読むだけで十分です。
[6] Buidler DAOの記事: ウォレットが盗まれた後、ハッカーからNFTを救出するにはどうすればいいか?
[7] 歴史は繰り返すのか?イーサリアム2.0とハードフォークについて解説