はじめに

トランザクションを処理する際にブロックチェーンが保存し参照する内容を状態と呼びます。イーサリアムでは、状態はノードのコンセンサスを可能にするプロパティです。すべてのフルノードは、有効なブロックの毎期間にこの状態を保存および更新する必要があります。ブロックチェーンにとって重要な状態は、時間とともに成長しますが、そのスペースの増加に伴い、ハードウェア要件も同様に増加します。スペースのしきい値は、時間とともに一部のノードを段階的に排除し、中央集権化を引き起こします。EIP-2935EIP-2935は、イーサリアムの状態を無状態にし、ノードにサイズの負担を軽減することを提案します。これは最後の8192ブロックのハッシュを状態から保存して提供することで、イーサリアムの無状態実行を実現しようとする改善提案です。

イーサリアムの現在の構造の概要

ブロック

ブロックは、チェーンに含まれる前のブロックの参照（ハッシュ）を持つトランザクションのバッチです。各ブロックのハッシュは、ブロックデータ自体から暗号的に導出されます。この含有は、ハッシュを使って鎖をつなぎ、バッチ処理はネットワーク内のすべての参加者が一度に合意し、状態を同期することを意味します。さらに、バッチ処理されたブロックに関する合意は、各ノードの参加者ごとにEthereumにそのグローバル状態を更新するように指示します。

Alt: イーサリアムの状態変更

新しいブロックがネットワーク上の検証者とともに処理およびブロードキャストされると、他の参加者はそれを自身のストレージに追加し、グローバルステートを更新します。各ブロックの検証者はランダムに選択されます。ランダム化分散型自律組織（RANDAO）パラメータ。ブロック構造は厳密に順序付けされており、ブロックの作成およびコンセンサスプロセスは、イーサリアムのプルーフオブステークプロトコルの下で指定されています。

ブロックにはヘッダーと本文に複数のフィールドが含まれています。たとえば、ブロックヘッダーにはスロット、提案者インデックス、親ルート、ステートルート、および本文フィールドが含まれます。ブロック本文には、randao_reveal、eth1_data、graffiti、提案者スラッシング、Attesterスラッシング、Attestations、Deposits、Voluntary_exits、sync_aggregate、およびexecution_payloadが含まれます。各フィールドには異なるパラメータがあり、異なるニーズを処理します。

イーサリアムの12秒ブロック作成期間は、「スロット」とも呼ばれ、ネットワーク参加者が新しいブロックと合意に達するために十分な時間を確保することから来ています。この期間中：

1. ブロック提案者はランダムにバリデータを選択します。
2. バリデーターは取引をまとめて実行し、新しいグローバル状態を決定します。
3. 彼らはこの情報を新しいブロックに含め、ゴシッププロトコルを介して検証者セットの残りにブロードキャストします。
4. 他のバリデータは、取引を再実行して妥当性を確認し、合意に基づいてグローバルステートの変更に同意します。
5. もし検証者が新しいブロックを有効として検証した場合、それを彼らのストレージに追加します。

ブロックとトランザクションの最終性は、分散ネットワーク内で重要なETHの焼却なしに変更できないことを意味します。 Ethereumは「チェックポイントブロック」アプローチを採用して最終化を管理しています。各エポックの最初のブロックがそのスロットのチェックポイントと見なされます。バリデータはこの仮定に投票して、有効なチェックポイントにします。バリデータの投票権を持つ合計ETHの三分の二が一対のチェックポイントを選出した場合、チェックポイントは正当化されます。前回の正当化されたチェックポイントは、次のチェックポイントのアップグレード後にアップグレードされ、最終化されます。悪意のある行為者が最終化されたブロックを元に戻そうとする場合、合計供給ETHの三分の一以上を失うことを約束する必要があります。非アクティブリーク存在することは、大勢の検証者の永続的な失敗の場合に、検証者の資金に大きなペナルティを課し、証人の報酬を削減することで最終的な確定を回復することを目的としています。

ブロックを処理する際、Ethereumはブロックのデータを取り、ハッシュ関数を適用してユニークな文字列に縮小します。ハッシュ関数では、すべての入力がユニークな出力を生成します。ブロック内のハッシュ値は唯一の不変の部分です。これは、総ステークされたETHの三分の一が燃やされることで変更可能です。ただし、この金額はMerkle Trieのハッシュを再計算してチェックポイントまで到達するまでのものです。各ブロックのハッシング処理の出力は、blockHashパラメータとともに返されます。blockHashパラメータにはブロック内のすべてのデータが含まれています。

ブロックのハッシュ値や他の必要なパラメータは、マークル木に格納されています。イーサリアムは、マークル・トライのアーキテクチャを異なるバージョンで使用しており、メルクル・パトリシア・トライなどがあります。

MerkleとMerkle Patricia Tries

トライ構造、特にマークル・トライは、ブロックチェーンのストレージにとって基本的です。マークル・トライがないと、ブロックチェーンは毎回処理が難しい単一ブロックになります。マークル・トライ、または一般的なトライアーキテクチャによって、ブロックチェーンは基本的なシャードで完全性を実現します。これにより、低ハードウェア要件でネットワーク参加者となることが可能となります。

Merkle木は、大量のチャンクをハッシュ化し、それらを部分に分割するための構造化された方法です。Merkle化により、データはペアで整理されます。それぞれが一緒にハッシュ化されます。Merkle化プロセスは、単一のMerkleルートが得られるまで繰り返されます。

Ethereumは、基本的なデータ処理（トランザクションデータなど）にはバイナリTriesを使用し、このアプローチはそのような状況に対してより効率的ですが、より複雑な状況（状態の処理など）では、より複雑なMerkle Patricia Triesを使用しています。Merkle Patricia Triesは、Merkle Trie構造のデュアルMerkle Trie構造を好みます。

ステートトライのデータストレージシナリオでは、Ethereumはキーバリューマップを活用しています。キーはアドレスを表し、値はアカウント宣言を表します。ステートトライはバイナリトライよりも動的です。したがって、新しいアカウントを頻繁に挿入したり、キーを頻繁に挿入および削除したりできます。このプロセスには、全データセット全体を再計算する必要がない、迅速に更新可能なデータ構造が必要です。

トライの根はデータにのみ依存し、順序には依存しません。異なる順序でデータを更新しても、根自体は変わりません。

Alt: バイナリメルクルトライ

Ethereumは一部の機能を持つ改変されたMerkle Patricia Trieを使用していますPATRICIA（Practical Algorithm to Retrieve Information Coded in Alphanumeric）および修正されたマークルトライとともに。このアーキテクチャは決定論的であり、暗号的に検証可能です。この構造における状態ルートを生成する唯一の方法は、それぞれの状態の個々の部分から計算することです。2つの同一の状態は、ルートハッシュとそれにつながるハッシュを比較することで簡単に証明することができます。

最終的に、異なる値で状態を変更することは不可能です。なぜなら、異なる状態ルートハッシュが生じるからです。Ethereumの実行レイヤーのすべてのトライ構造はMerkle Patricia Trieを使用しています。ネットワークには3つのトライがあります：State Trie、Storage Trie、Transaction Trie。さらに、すべてのブロックには独自のReceipts Trieがあります。Merkle Patricia Triesは多くの点で効率的ですが、Ethereumは状態の無効化を達成するためにそれらをVerkle Triesで置き換えることを目指しています。

Alt: Merkle Patricia Trie

ガス

Gasは、実行に必要なプロパティです。EVMは実行に計算リソースを使用し、これらの努力の戻りは、EVMのセキュリティを確保するためにガスで支払われます。ガス料金は、必要なガス量に単位ごとのコストを乗じたものとして計算されます。これは動的な値であり、操作の種類に依存します。

Alt: https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

EIP-1559トランザクション手数料メカニズムにいくつかの重要な変更を加えました。過去にはブロックにトランザクションを含めるためのガス料金は、オークションのような方法で支払われていました。EIP-1559では、ベース料金と呼ばれる最小限度が導入され、プライオリティ料金と呼ばれるチップが導入されました。ブロックは最も優先度の高い料金を持つトランザクションから開始することが提案されています。ブロック処理後、ベース料金は燃やされ、プライオリティ料金はバリデーターをインセンティブするために使用されます。

状態

ブロックチェーンの状態とは、特定の時点で特定のシステムを記述するデータ（または変数）のセットとして定義できます。インターネットはほぼ始まりから状態を持っていましたが、それは単一のサーバーに格納されていました。Web3では、分散された方法を介してセキュリティが確保されたオープンで分散されたネットワークでグローバルな状態が維持されました。誰もが分散ネットワークの状態をいつでも表示および検証できます。

イーサリアムには、グローバルステート内のアカウント、残高、展開されたスマートコントラクト、関連するストレージが含まれています。イーサリアムのステートは、これらのパラメータの追加と変更に伴い成長します。ノード全体をホスティングするハードウェアコストが高くなりすぎると、ステートの成長が問題になります。これらの課題を踏まえて、Vitalik Buterin導入2017年に提案されたステートレスなEthereumのコンセプト。Ethereumにおけるステートの成長を修正するために提案された方法には、データとステートの有効期限が含まれています。

データ有効期限と状態有効期限の違い

データ有効期限

データまたは履歴の有効期限切れとは、一定期間後にクライアントから不要なデータを削除することを意味します。 「弱い主観的チェックポイント」を使用することで、クライアントは起源から同期し、過去の無駄なデータを削除する方法を見つけることができます。

主観性とは、ネットワークのノードが現在の状態について合意に達するために社会的情報に依存することを指します。この観点から、弱い主観性とは、社会的に取得された情報の初期シードを持ちながら客観的に進行できるチェーンを指します。ただし、弱い主観性のチェックポイントは、合意に責任を持つネットワーク上のすべてのノードが正規のチェーンに属していることを意味します。弱い主観性のチェックポイントは、イーサリアムPoSが信頼できるソースから最新の状態（弱い主観性のチェックポイント）を同期するのに役立ちます。

EIP-4444実践的な道を提供します@hBXHLw_9Qq2va4pRtI4bIA"/ryzBaf7fJx?ref=ghost-2077.arvensis.systems">弱主観を介してデータの有効期限を達成します。この提案の目的は、Ethereumノードが状態データを処理する方法を変更することではなく、むしろ、過去のデータへのアクセス権を変更します。

ステートの有効期限

State Expiryは、最近アクセスされていない場合、個々のノードから状態を排除することを目指しています。有効期限は、家賃または時間の要因で終了することで実装される可能性があります。家賃による有効期限は、状態を保存するための口座に追加料金を課すことを意味します。一方、時間経過による有効期限は、一定期間アクティブでないままの口座を無効にすることを意味します。

データとステートの有効期限は、オープンな研究領域です。これらの提案されたステータスを達成するための現在のアプローチには、それらを中央集権化されたネットワーク/プロバイダを通過させることが含まれています。現時点では、弱いステートレス性とステートの有効期限は、イーサリアムで部分的に達成されています。

ステートレスイーサリアム

ステートレスネスとステートレスなイーサリアムの紹介

Stateless Ethereumは、コアプロトコルに新しい概念を導入します。理想的には、状態のないことは状態が存在しないことを意味しません。むしろ、クライアントは保持する状態を選択できるということです。クライアントが検証されたブロックを受け取ると、そのブロックに対応するウィットネスも受け取ります。各ブロックのウィットネスには、そのブロックに含まれるトランザクションを実行するために必要なすべてのデータが含まれています。

EIP-161最初の状態縮小アプローチを導入しました。 EthereumはDoS（サービス拒否）攻撃を受け、この脆弱性により、グローバルなEthereumの状態を増やす空のアカウントを作成することができました。 EIP-161は、この攻撃から来たnonceがゼロ（0）の空のアカウントを削除することを提案し、低コストで実行されました。この提案が実行され、状態が巻き戻されました。

状態のない方向へのもう一つの取り組みが提案されましたEIP-4788この提案は、EVM内のビーコンチェーンブロックのルーツを明らかにしようとしたものです。Gate.ioのアプローチに類似しています。Eth1-Eth2ブリッジビーコンチェーン（コンセンサスレイヤー）と実行レイヤーを接続することで、この提案はEVMとコンセンサスレイヤーの間で最小限の信頼を必要とするアクセスを可能にします。

各実行ブロックには親ビーコンブロックのルートが含まれているため、ミスしたスロットイベントは以前のブロックルートを変更する必要はありません。したがって、実行の前提条件は、各実行ブロックに信頼最小限のオラクルのための小さなスペースを確保することに絞られます。この提案では、ルートコントラクトにブロックルートの小さな履歴を保存してオラクルの効率を向上させることを提案しています。

Ethereumにおける無状態性は、弱い無状態性または強い無状態性のいずれかとして可能です。

弱い無国籍

弱い無状態は、すべてのノードに状態の保存が必要なくなるわけではありません。代わりに、Ethereumの状態の変更をノードが確認する方法が異なります。状態の保存の責任をブロック提案者に置き、他のノードに完全な状態データを保存せずにブロックを検証するよう要求します。

ブロック提案者は完全な状態データを保存する必要があります。ただし、検証クライアントはネットワーク上で状態データを保存する必要はありません。代わりに、状態ルート（完全な状態のハッシュ）を保存できます。弱いステートレス性が必要です提案者-ビルダー分離（PBS） and ヴァークルが試みます実装。

提案者は、状態の変化を証明するために状態データを使用して証人を作成し、検証者はその証明を状態ルートハッシュに対して検証します。

強力な無国籍

強力な無状態性は、任意のノードが状態データを保存する必要がないことを実現します。これは、ブロック提案者によって集約された送信トランザクションと証人を取り込むことで機能します。ブロック提案者は、取り組んでいる唯一の状態を保存し、関連するアカウントのための証人を生成します。提案には引き続き開発が必要であり、要件が含まれます。アクセスリストまたはEIP-2930。

ただし、一部の変更とプロパティを使用すると、ステートレスを実現することができます。EIP-2935は、ステートレス実行を許可するために、状態から歴史的なブロックハッシュを提供することを提案しています。

EIP-2935の紹介

EIP-2935は、特別なストレージスロットであるHISTORY_STORAGE_ADDRESSにブロックの履歴ハッシュを保存することを目的としています。このプロセスにより、ステートレスクライアントで必要な履歴情報に簡単にアクセスできるため、ステートレス実行が可能になります。

EIP-2935は、ブロック処理ロジックの一部として使用するために、最後の8192個の歴史的なブロックハッシュをシステム契約に保存することを提案しています。この提案が解決しようとしている問題は、EVMがクライアントが最近のブロックハッシュを持っているという前提に依存していることです。この前提に基づいたアプローチは、将来のEthereumや特にステートレスクライアントには適用されません。

過去のブロックハッシュを状態に含めることで、これらのハッシュを証人の視点でハッシュ関数とバンドルすることが可能になります。証人は後で状態レスクライアントに提供され、実行を検証し状態レス実行を達成します。この提案は、Verkleトライへの適応前に実装できるため「事前Verkle種特化」と呼ばれ、コアプロトコルでのVerkleトライへの適応を容易にします。

blockHashが提供するブロックの範囲を8192ブロックに拡張すると、実行方法へのソフトな移行が可能になります。ロールアップは、この契約を直接クエリすることで、この長い履歴ウィンドウから利益を得ることができます。さらに、このEIPは、HISTORY_SERVE_WINDOWの8192ブロック量に関連する証明の検証を現在の状態に対して容易にします。

EIP-2935の理解

EIP-2935は、特にステートレスのEthereumクライアントが最近のブロックハッシュに簡単にアクセスできるようにします。これを実現するために、4つの新しいパラメータを導入しています。

• BLOCKHASH_SERVE_WINDOW: クライアントに過去のブロックハッシュをいくつ保持すべきかを伝えます。デフォルト値は256です。
• HISTORY_SERVE_WINDOW: このパラメータは、保存されるハッシュのブロック数を定義します。デフォルト値は8191です。
• SYSTEM_ADDRESS: ストレージにブロックハッシュを書き込むための「呼び出し元」として機能する特別なアドレス（もともとEIP-4788で導入された）です。
• HISTORY_STORAGE_ADDRESS: これらのブロックハッシュが格納されている契約アドレス。

提案の仕様では、最後のHISTORY_SERVE_WINDOWブロックハッシュを、長さがHISTORY_SERVE_WINDOWのリングバッファストレージに格納するように指示されています。

リングバッファ

EIP-2935は一時的なストレージ用にリングバッファーと呼ばれる追加機能を使用します。リングバッファーはネットワークが異なるデータに同じストレージを再利用できるという特性です。ストレージはリングバッファー内で常に同じストレージ位置に制限されます。EIP-2935のリングバッファーはEIP-4788やビーコンステートアキュムレーターと同様に、必要なHISTORY_SERVE_WINDOWを提供するためだけに使用されます。

Fork選択ルールと仕様

フォーク後、ネットワークがこれらのEIP考慮事項で開始されると、HISTORY_STORAGE_ADDRESSパラメータは、block.parent.hash入力（デフォルト32バイト）、30,000,000のガスリミット、および0の値を使用してSYSTEM_ADDRESSとして参照されます。このプロセスにより、履歴契約のset()関数がトリガーされます。

提案後のフォークプロセスは通常のフォークプロセスとは異なります。このset()操作は一般的なシステム操作ですが、呼び出しはこれらの規則に従います。

• 完了する必要があります
• ブロックのガス制限にはカウントされません
• EIP-1559の燃焼メカニズムに従わない
• HISTORY_STORAGE_ADDRESSにコードが存在しない場合、致命的なエラーなしで呼び出しは失敗する必要があります。

このプロセスは、リングバッファトリガ期間に適合するために、ブロック期間HISTORY_SERVE_WINDOWを埋める必要があります。履歴契約には、フォークブロックの親ハッシュのみが含まれ、参照ハッシュおよび新しいハッシュ開始点として機能します。

ブロックハッシュ履歴契約には、get() と set() の2つの操作があります。set() 操作は、トランザクション内で契約の呼び出し元がEIP-4788で導入されたSYSTEM_ADDRESSと等しい場合にアクティブ化されます。呼び出し元とSYSTEM_ADDRESSが等しくないか、条件を満たさない場合は、get() 操作がアクティブ化されます。

get()操作は、EVM内でブロックハッシュを特定するために使用されます。呼び出し元がクエリを行うブロック番号を指定できるようにし、calldata入力が32バイトでない場合（つまり、有効なblock.parent.hashである場合）やリクエストが範囲外の場合（[block.number-HISTORY_SERVE_WINDOW、block.number-1]）、トランザクションをリバートします。

set()は、呼び出し元がトランザクションを使用してコントラクトを呼び出す際に、入力としてblock.parent.hashをcalldataとして受け取ります。また、block.number-1 % HISTORY_SERVE_WINDOWで、ストレージ値をcalldata[0:32]に設定します。

HISTORY_STORAGE_ADDRESSは、EIP-4788を介して展開されます。これは、コンセンサスレイヤーを通じてEVMでブロックハッシュに直接アクセスする方法として上記で言及されています。HISTORY_STORAGE_ADDRESSはnonce値が1であり、EIP-161のゼロnonceクリーンアップ標準の対象外となります。

BLOCKHASHトランジディアンロジック

このEIPに関する懸念事項は、フォーク後にBLOCKHASH解決ロジックを最も適切に移行する方法です。 2つの主要なアプローチが検討されています。

• 関連する履歴全体が永続化するのを待ってください，HISTORY_SERVE_WINDOWブロック
• フォークブロックにすべての最後のHISTORY_SERVE_WINDOWブロックハッシュを保存します。

開発者は最初のオプションを選択します。一時的な変更を必要としないため、より実用的です。

EIP-2935と類似のEIPとの違いは何ですか？

以前にも類似のEIPが提案されてきましたが、状態レスの実行を許可および実現するためのEIP-2935は、以下で強調された複雑さを対象としている点でこれら以前の提案と異なります。

• Trie構造アプローチ：EIP-2935は、複数のレイヤーを持つトライのような構造を使用せず、代わりに単一のリストを選択しています。それに対して、EIP-4444は、実行クライアントの過去1年よりも古い歴史的データの剪定を提案しています。同様の意欲を持つ他のEIPには、Verkleトライが要件としてあります。
• EVMコードでEIPを記述する：EIP-2935はEVMの変更を必要としません。
• ハッシュの連続無制限ストレージ：シリアル無制限ハッシュストレージは効率的ではありません。このEIPは、ハッシュをバンドルすることでこの問題を克服します。

セキュリティの考慮事項

EIP-2935はスマートコントラクトを使用しているため、枝毒攻撃のリスクがあります。ただし、状態ルートのサイズが更新試行を遅くし、毒攻撃をかなり高価にします。

何をもたらすか？

• 信頼できるオラクルシステムをより速く: Uniswap v2ベースのオラクルでは、Ethereumノードアクセスを持つ誰でもUniswapのストレージの証拠を生成し、オンチェーン検証のために提出することができます。平均価格は、現在のブロックと提供された証拠のブロックの間で決定され、検証された証拠は256ブロックまで有効です。なぜならblockHashは256ブロックまでサポートされているからです。EIP-2935の恩恵を受けることで、このプロセスは古いブロックハッシュへのアクセスを許可することで改善され、つまり証拠はより長い期間にわたって検証されることができます。
• 契約が過去の状態の主張を考慮することを許可し、信頼できるようにする：EIP-2935の改善により、EVM内部からブロックチェーンデータを見る可能性が生まれます。クライアントは履歴を問い合わせ、ハッシュ化し、他のノードと検証できます。このソリューションにより、軽量クライアントが効率的かつ簡単に実装できる可能性があります。
• L1とL2の間のブリッジング：L2からのメッセージを検証するには、L1がL2の状態ルートとブロックハッシュについて知る必要があります。ただし、現在の状態のL1は、ガス制限やアーキテクチャ上の制約により、任意のブロックハッシュにアクセスできません。EIP-2935により、L1は古いイベントの含有証明を調査する能力を備えて、任意の歴史的データを検証できるようになります。アクセスおよび検証の権限が向上し、ブリッジングのパフォーマンスが向上します。

結論

EIP-2935は、ステートレスなEthereumの長期的な目標を達成するための重要な一歩を表しています。最後の8192個のブロックハッシュを状態内の専用契約に格納することは、現行の設計における基本的な制限に対処しています。Ethereumは、クライアントが最新のブロックハッシュに固有にアクセスできるという前提に基づいています。しかし、ステートレスな実行の文脈では、クライアントが完全な状態を維持しなくなるため、この前提は時代遅れになります。EIP-2935は、EVMを変更せずに、またVerkleトライのような複雑なデータ構造に依存せずに、ステートレスクライアントが必要な歴史的データにアクセスできるようにする、軽量で効率的で非侵襲的なメカニズムを導入することで、この問題を解決します。

ステートレスな実行を超えて、この提案はEthereumエコシステム全体にさらなる利益をもたらします。これにより、信頼できるオラクルの機能が向上し、軽量クライアントの利便性が拡張され、信頼性のある古いステートデータの検証が可能になることで、レイヤー1とレイヤー2のソリューション間の相互運用性が強化されます。その実装は、リングバッファストレージとシステムレベルの契約を使用し、EVMへのハードコーディングを回避することで、クリーンでガス効率の良い設計に依存しており、シンプルさと拡張性の両方を提供しています。

Ethereumはより分散化、スケーラビリティ、およびアクセシビリティに向けて進化を続ける中、EIP-2935は基盤となる改善策となっています。これは現在の状態保持アーキテクチャと将来の状態レスの間のギャップを埋め、ブロックチェーンエコシステム全体でより強固で効率的、かつ許可されていないインフラの基盤を築いています。

免責事項：

1. この記事は[から転載されています2077research]. すべての著作権は元の著者に帰属します[イイット イェクティン]. If there are objections to this reprint, please contact the Gate Learnチームが迅速に対応します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、いかなる投資アドバイスを構成するものではありません。
3. Gate Learnチームは記事を他の言語に翻訳します。翻訳された記事のコピー、配布、または盗用は、特に言及されていない限り禁止されています。