坎昆のアップグレードにはどんな利点がありますか？

スケーリングの背景：#

個々のブロックのガスには上限があります。 Ethereum では、ブロックのデータ容量の上限をガス料金に基づいて定義しており、1 つのブロックは最大で 3000 万ガスのデータ容量を持つことができます。
大きなブロックにはコストがかかります。 Ethereum は、各ブロックのデータ容量が大きすぎないようにしたいため、各ブロックにはガスターゲット（目標ガス）として 1500 万ガスのデータ容量があります。
ガスの自動調整メカニズム。ブロックのガス消費がガスターゲット（つまり、1500 万ガス）を超えると、次のブロックの基本料金が 12.5％高くなります。それより低い場合は、基本料金が低くなります。これにより、トランザクションのピーク時にコストを増やして混雑を緩和し、トランザクションの低迷時にコストを下げてさらに多くのトランザクションを引き付けることができます。

スケーリングのソリューション（Layer2+Sharding）：#

Layer2：

Optimism Rollup：すべてのトランザクションが正直で信頼できるものと仮定し、多くのトランザクションを 1 つのトランザクションに圧縮して Ethereum に提出します。** 提出後に一定の時間ウィンドウ（チャレンジ期間 - 現在は 1 週間）** があり、誰でもトランザクションの真正性を検証するためにチャレンジを発行できますが、ETH を Optimism Rollup から Ethereum に移す場合は、チャレンジ期間が終了するまで最終的な確認を待たなければなりません。
ZK Rollup：ゼロ知識証明と最終的な状態変化のデータのみをアップロードするだけで済みます。これは、OP Rollup よりもさらに多くのデータを圧縮することができ、OP Rollup のように 1 週間もの長いチャレンジ期間を待つ必要もありません。ただし、技術的な開発の難しさがあります。

シャーディング（Sharding）：

Sharding に入る前に、Ethereum のブロック生成プロセスを振り返りましょう。

統合された Ethereum は、PoW から PoS に移行し、12 秒ごとに 1 つのスロットが生成されます。32 個のブロックが 1 つのサイクル（エポック）で生成されるのには 6.4 分かかります。マイナーが 32ETH をステーキングしてバリデータノードになると、ビーコンチェーンはランダムアルゴリズムを使用してブロックをパッキングするためのブロック生成ノードとしてバリデータノードを選択します。各ブロックはランダムに 1 回だけブロック生成ノードを選択します。同時に、各エポック中の各ブロック（スロット）は、ブロック生成ノードがパッキングしたブロックを検証するためのバリデータノードの委員会で構成されます。ブロック生成ノードがブロックをパッキングした後、3 分の 2 以上のバリデータノードが投票を通過すれば、ブロック生成は成功します。

シャーディング 1.0（廃止されましたが、読み飛ばしても構いません）

Sharding 1.0 は、Danksharding 以前の Ethereum のシャーディングデザインの総称であり、それについて大まかに理解することは重要です。初期のシャーディング 1.0 のデザインコンセプトでは、本質的には「ステートシャーディング」を実現することを目指していました。 Ethereum は、元々の 1 つのメインチェーンから最大で 64 のシャードチェーンに変更され、スケーリングを実現するために複数の新しいチェーンが追加されました。このプランでは、各シャードチェーンが Ethereum のデータを処理し、ビーコンチェーンに渡す役割を担当し、各シャードチェーンのブロック生成ノードと委員会はランダムにビーコンチェーンによって割り当てられますが、データ同期と増加し続ける MEV の問題がありました。

Danksharding（今日の主役）#

Danksharding は、Ethereum のスケーリング問題を解決するための新しいシャーディングアプローチを使用しています。具体的には、Layer2 の Rollup を中心に展開されるシャーディングソリューションであり、この新しいシャーディングアプローチは、ノードの負荷を大幅に増やすことなく、分散化とセキュリティを確保しながらスケーラビリティの問題を解決し、MEV による負の影響も解決します。

Untitled 1.png

EIP-4844：#

EIP-4844 は、Ethereum に新しいトランザクションタイプである Blob Transaction を導入しました。この新しいトランザクションタイプの Blob は、Ethereum に追加の外部データベース（実際には大きなブロック）を提供します。

Blob のサイズは約 128KB です（平均的なブロックのデータサイズは約 60〜70KB です）。
1 つのトランザクションには最大で 2 つの Blob（256KB）を携帯できます。
各ブロックのターゲット Blob は 8 つ（1MB）であり、最大で 16 個の Blob（2MB）を保持できます。
Blob は callData と同様に履歴ログとして永久に保存する必要はありません（現在のコミュニティの提案では 30 日間保存することが推奨されています）。

Untitled 2.png

Blob は Ethereum に追加のストレージスペースをもたらし、Ethereum のすべての台帳データの総量は約 1TB 程度ですが、Blob は年間に 2.5TB〜5TB の追加データ量を提供し、Ethereum の台帳データ量の数倍になります。

EIP-4844 によって導入された Blob トランザクションは、Rollup に最適化されたものと言えます。Rollup のデータは Blob の形式で Ethereum にアップロードされ、追加のデータスペースにより Rollup のより高い TPS とより低いコストを実現し、元々Rollup が占めていたブロックスペースを他のユーザーに開放します。

Danksharding のスケーリングソリューション#

完全な Danksharding ソリューションでは、Blob が保持できるデータ量を 1 つのブロックあたりの 1〜2MB から 16MB〜32MB に拡大し、MEV の問題を解決するために新しいメカニズムであるブロックビルダーとパッカーの分離（PBS）を提案しています。

Danksharding は、データの可用性を確保するためにデータ可用性サンプリング（DAS）というメカニズムを提案し、ノードの負荷を軽減しながらデータの可用性を確保します。

データの可用性サンプリング（DAS）によるノードのストレージ負荷の軽減と中心化の回避（エラーコレクション技術と KZG 多項式コミットメント）

データの可用性サンプリング（DAS）のアイデアは、Blob のデータをデータフラグメントに分割し、ノードが Blob データをダウンロードする代わりにランダムに Blob データフラグメントをサンプリングすることです。つまり、Blob のデータフラグメントが Ethereum の各ノードに分散するようにし、完全な Blob データは Ethereum の全体の台帳に保存されることを前提としますが、ノードは十分に多くかつ分散化されている必要があります。

例えば、Blob のデータが 10 個のフラグメントに分割され、ネットワーク全体に 100 個のノードがある場合、各ノードはランダムに 1 つのデータフラグメントをサンプリングし、サンプリングしたフラグメントの番号をブロックに提出します。1 つのブロックにすべてのフラグメントの番号が揃えば、Ethereum はその Blob のデータが利用可能であるとみなします。フラグメントを組み合わせることで元のデータを復元することができます。ただし、極めて低い確率で 100 個のノードが特定の番号のフラグメントをサンプリングしない場合、データが欠落する可能性があり、セキュリティが低下する可能性がありますが、確率的には受け入れられる範囲です。

Untitled 3.png

Untitled 4.png

Untitled 5.png

しかし、問題が 1 つあります。元のデータをエンコードする責任は誰にあるのでしょうか？

ブロックビルダーとパッカーの分離（PBS）によるブロックのパッキングとデータの配布の分業

Blob の元のデータをエンコードするには、エンコードを行うノードが完全な元のデータを持っている必要があります。これを実現するには、ノードには高い要件があります。そこで、Danksharding は MEV の問題を解決するために新しいメカニズムである ** ブロックビルダーとパッカーの分離（PBS）** を提案しました。実際、このソリューションは MEV の問題を解決するだけでなく、エンコードの問題も解決しています。

パフォーマンスの高い構成のノードはパッカー（Builder）になることができます。パッカーは Blob データをダウンロードし、エンコードしてブロック（Block）を作成し、他のノードにブロードキャストするだけです。パッカー（Builder）にとっては、同期データ量と帯域幅の要件が高いため、比較的中心化されています。
パフォーマンスの低い構成のノードはプロポーザー（Proposer）になることができます。プロポーザーはデータの有効性を検証し、ブロックヘッダ（Block Header）を作成してブロードキャストするだけです。プロポーザー（Proposer）にとっては、同期データ量と帯域幅の要件が低いため、分散化されています。

抗検閲リスト（crList）によるブロックビルダーの MEV 能力の制限

ただし、パッカー（Builder）にはトランザクションを検閲する能力があります。パッカーは意図的に特定のトランザクションを無視したり、順序を変更したり、自分が挿入したいトランザクションをランダムに挿入したりして MEV を取得することができますが、抗検閲リスト（crList）はこれらの問題を解決します。

Untitled 6.png

抗検閲リスト（crList）のメカニズムは次のとおりです：

パッカー（Builder）がブロックトランザクションをパッキングする前に、プロポーザー（Proposer）は crList と呼ばれる抗検閲リストを公開します。この crList には、mempool 内のすべてのトランザクションが含まれています。
パッカー（Builder）は crList 内のトランザクションを選択して並べ替えるだけであり、パッカーは自分自身のプライベートトランザクションを挿入して MEV を取得したり、特定のトランザクションを意図的に拒否したりすることはできません（ガスリミットがいっぱいの場合を除く）。
パッカー（Builder）がパッキングを完了した後、最終的なトランザクションリストのハッシュをプロポーザー（Proposer）にブロードキャストします。プロポーザーはその中から 1 つのトランザクションリストを選び、ブロックヘッダ（Block Header）を生成してブロードキャストします。
ノードはデータを同期する際に、プロポーザー（Proposer）からブロックヘッダを取得し、パッカー（Builder）からブロックボディを取得して、ブロックボディが最終的に選択されたバージョンであることを確認します。

最後に#

Danksharding は、Ethereum に「ブロックチェーンの不可能三角形」を解決する革新的なソリューションを提供し、Ethereum の分散化とセキュリティを確保しながらスケーラビリティを実現します。

EIP-4844：Proto-Danksharding を導入することで、新しいトランザクションタイプである Blob を導入しました。Blob が提供する 1MB〜2MB の追加データ量により、Rollup 上でより高い TPS とより低いコストを実現できます。
データの可用性サンプリング（DAS）により、ノードのストレージ負荷を軽減し、中心化を回避しながらデータの可用性を確保します。
データの可用性サンプリング（DAS）を実現することで、Blob の追加データ量を 16MB〜32MB に拡大し、さらなるスケーリング効果を実現します。
プロポーザー（Proposer）とパッカー（Builder）の分離（PBS）により、ブロックの構築とデータの配布を分離し、パッカーノードの中心化とプロポーザーノードの分散化を実現します。
抗検閲リスト（crList）とダブルスロット PBS により、MEV の負の影響を大幅に低減し、パッカーがプライベートトランザクションを挿入したり、トランザクションを意図的に拒否したりすることを防ぎます。

予想外のことがなければ、Danksharding の前提となる EIP-4844 は、Ethereum の上海アップグレード（カンクンアップグレード）の後に正式に導入される予定です。EIP-4844 の導入後、最も直接的な利点は Rollup と Rollup 上のエコシステムにあります。より高い TPS とより低いコストは、オンチェーンの高頻度アプリケーションに非常に適しています。私たちは「キラーアプリ」が生まれる可能性を想像してみることができます。

参考：https://research.web3caff.com/zh/archives/6259