✏️

Proto-Danksharding(EIP-4844) Study

2023/04/25に公開1件

Solidity

要約

Dankshardingは、Ethereumが真にスケーラブルなブロックチェーンになるための方法で、その達成にはいくつかのプロトコルのアップグレードが必要です。Proto-Dankshardingはその中間ステップです。両方とも、レイヤー2のトランザクションをできるだけ安価にし、Ethereumを秒間10万トランザクション以上にスケーリングすることを目指しています。

Proto-Danksharding（EIP-4844）とは、ロールアップがブロックにより安価なデータを追加する方法です。この名前は、このアイデアを提案した2人の研究者、ProtolambdaとDankrad Feistに由来します。現在、ロールアップはCALLDATAにトランザクションを投稿するため、ユーザートランザクションのコストをどれだけ安くできるかに制限があります。これは、すべてのEthereumノードが処理し、ロールアップが短期間しかデータを必要としないにもかかわらず、チェーン上に永久に存在するため、コストが高くなります。Proto-Dankshardingは、ブロックに送信および添付できるデータブロブを導入します。これらのブロブのデータはEVMにアクセスできず、固定の期間（1〜3か月）後に自動的に削除されます。これにより、ロールアップはデータをはるかに安価に送信し、エンドユーザーに安いトランザクションとして節約を還元できます。

Dankshardingは、Proto-Dankshardingで始まったロールアップスケーリングの完全な実現です。Dankshardingは、Ethereumにロールアップが圧縮されたトランザクションデータを大量に投入できるスペースをもたらし、Ethereumが何百もの個別のロールアップを簡単にサポートし、1秒あたり数百万回のトランザクションを実現できるようになります。

これは、Proto-Dankshardingの1つのブロブから、Dankshardingでの64のブロブへとブロックに添付されるブロブを拡張することによって機能します。Dankshardingに必要なその他の変更は、すべてコンセンサスクライアントが新しい大容量ブロブを処理できるようにするためのアップデートです。これらの変更のいくつかは、Dankshardingとは独立して他の目的のためにロードマップに既に含まれています。たとえば、Dankshardingでは、提案者とビルダーの分離が実装されている必要があります。これは、ブロックの構築と提案を異なる検証者に分けるアップグレードです。同様に、Dankshardingにはデータ可用性サンプリングが必要ですが、これは歴史的データをほとんど保持しない軽量クライアント（ステートレスクライアント）の開発にも必要です。

現在の進捗状況:
フルDankshardingはまだ数年先ですが、Proto-Dankshardingは比較的近いうちに登場するでしょう。執筆時点（2023年2月）では、KZGセレモニーはまだオープンであり、これまでに5万人以上の貢献者が参加しています。Proto-DankshardingのEIPは成熟しており、仕様が合意され、クライアントは現在試験中で、実稼働に向けて準備されているプロトタイプを実装しています。次のステップは、公開テストネットでの変更の実装です。EIP 4844の準備チェックリストを使って最新情報を入手できます。

DankshardingとProto-Dankshardingは、ブロックチェーンを複数の部分に分割することを目的とした従来の「シャーディング」モデルには従っていません。シャードチェーンはもはやロードマップの一部ではありません。代わりに、Dankshardingは、ブロブ間で分散データサンプリングを使用してEthereumをスケーリングします。これは実装がはるかに簡単です。このモデルは、時々「データシャーディング」と呼ばれることがあります。

ロールアップ時に、blobに短期的にデータを保存する

blobの目的は、rollupがブロックに安価なデータを追加できるようにすることです。現在、rollupはCALLDATAにトランザクションを投稿することで、ユーザートランザクションのコストを下げることが制限されています。CALLDATAはすべてのEthereumノードで処理され、チェーンに永久に保存されるため、コストが高くなります。一方、rollupは短期間だけデータが必要です。

Proto-Dankshardingで導入されるblobは、一定期間（1〜3ヶ月）経過すると自動的に削除されるデータを格納できます。これにより、rollupはデータをはるかに安価に送信でき、エンドユーザーに安価なトランザクションとして節約分を渡すことができます。

blobデータは、KZG（Kate-Zaverucha-Goldberg）スキームを使用して圧縮され、小さな暗号化された「コミットメント」に減らされます。このコミットメントは、データの整合性と正確性を確認するために使用されます。データが正確であることを証明するために、多項式関数がデータに適用され、検証者はその多項式関数を評価して結果を確認します。

EIP-4844 のblobとは

EIP-4844で提案されている「blob-carrying transactions」は、Ethereumのトランザクション形式の新しい種類で、大量のデータを格納できるように設計されています。これにより、データを効率的に扱い、スケーラビリティを向上させることができます。

「Blob」とは、バイナリデータの塊を意味し、このトランザクション形式では、EVM（Ethereum Virtual Machine）が直接アクセスできないデータを含めることができます。これは、ブロックチェーン上で効率的にデータを保存し、転送することを可能にします。

ただし、EVMが直接アクセスできないとしても、データのコミットメント（一種のデータの証明）にはアクセスが可能です。これにより、トランザクションの正当性や完全性を検証することができます。

EIP-4844のblobは、Ethereumブロックチェーンに新しいデータ構造として格納されます。Rollupなどのアプリケーションでは、blobにデータを格納して利用します。blobに格納されたデータは、正直なアクターがロールアップの状態を構築できるだけの時間だけ利用可能であれば十分ですが、永続的には保存されません。

Optimistic Rollupsの場合: 詐欺証明（fraud proofs）を提出する際に、実際に基本データを提供する必要があります。詐欺証明は、blobからいくつかの値を一度にロードして検証し、KZG証明を使用してバージョン化されたハッシュに対して値を検証します。その後、現在の方法と同様に、そのデータに対して詐欺証明の検証を実行します。
ZK Rollupsの場合: トランザクションまたは状態デルタデータに対して2つのコミットメントを提供します。1つはblobのkzgで、もう1つはZKロールアップが内部で使用する証明システムを使用したコミットメントです。コミットメント証明の同等性プロトコルを使用して、kzg（プロトコルが利用可能なデータを指すことを保証）とZKロールアップ自身のコミットメントが同じデータを参照していることを証明します。

バージョン化されたハッシュ（versioned hashes）を使用して、SolidityはEVM内でblobにアクセスできます。これにより、スマートコントラクトは、将来のコミットメントと証明を使用できるように構築され、アップグレードが不要になります。

このEIPでは、新しいデータ構造が導入されるため、web3 APIからトランザクションの一部にアクセスできなくなることに注意してください。また、メモリプール（mempool）において、blobトランザクションは大きなデータサイズを持つため、DoSリスクが考慮されています。EIP-5793を導入することで、ノードはトランザクションタイプとサイズを含むNewPooledTransactionHashesアナウンスメッセージを拡張し、より細かな制御が可能になります。さらに、メモリプールのトランザクション置換ルールに1.1倍のデータガス価格の要件を追加することが推奨されています。これにより、ノードはblobトランザクションのスループットを適切なレベルに抑えることができます。

導入された新しいTransaction

EIP-4844では、新しいTransactionインターフェースが導入されています。これは、データ可用性のためのブロブ（Blob）を扱うためのもので、EIP-2718のTransactionタイプの拡張です。新しいTransactionインターフェースの使い方を説明します。

新しいTransactionタイプの作成:
EIP-4844では、新しいTransactionタイプ（BLOB_TX_TYPE）が導入されます。これは、ブロブ関連のデータを扱うためのものです。

新しいTransaction構造の定義:
新しいTransactionタイプでは、次のような構造が定義されています。

class SignedBlobTransaction(Container):
    message: BlobTransaction
    signature: ECDSASignature

class BlobTransaction(Container):
    chain_id: uint256
    nonce: uint64
    max_priority_fee_per_gas: uint256
    max_fee_per_gas: uint256
    gas: uint64
    to: Union[None, Address]  # Address = Bytes20
    value: uint256
    data: ByteList[MAX_CALLDATA_SIZE]
    access_list: List[AccessTuple, MAX_ACCESS_LIST_SIZE]
    max_fee_per_data_gas: uint256
    blob_versioned_hashes: List[VersionedHash, MAX_VERSIONED_HASHES_LIST_SIZE]

新しいTransactionの作成と署名:
トランザクションを作成するには、まずBlobTransactionオブジェクトを作成し、その後SignedBlobTransactionオブジェクトを作成して署名を行います。署名は、ECDSA署名アルゴリズムを使用して行われます。
トランザクションの検証:
ブロックチェーン上で新しいTransactionを検証する際には、いくつかのチェックが行われます。これには、blob_versioned_hashesが空でないこと、すべてのハッシュがBLOB_COMMITMENT_VERSION_KZGで始まること、有効なブロック内でのブロブコミットメントの最大数、KZGコミットメントとブロブの内容の一致などが含まれます。
トランザクションの実行:
トランザクションが検証された後、通常のEthereumトランザクションと同様に実行されます。ただし、EIP-4844では、ブロブ関連のデータを扱うための新しいデータガス価格が導入されています。
ブロブデータの取り扱い:
EIP-4844では、ブロブデータを格納し、検証するための新しいデータ構造が導入されています。これにより、データ可用性を向上させることができます。ブロブデータは、トランザクションの一部としてネットワークを通じて伝播され、検証された後、Ethereumの状態に適用されます。
ヘッダーの拡張:
EIP-4844では、ブロックヘッダーが拡張され、新しいフィールドexcess_data_gasが追加されます。これは、EIPがアクティブ化されてからのデータガス消費の累計を表します。トータルのデータガスがターゲット以下の場合、excess_data_gasはゼロに制限されます。

これらの手順により、EIP-4844の新しいTransactionインターフェースを使用して、データ可用性を改善するためのブロブデータを扱うことができます。この新しいインターフェースは、Ethereumのスケーラビリティを向上させるために役立ちます。

Discussion

Kenshiro

素晴らしい記事ありがとうございます!!