今回も引き続き、福岡ブロックチェーン勉強会#29 エキスパートコースでQ&A形式で発表した、EIP-1679についてまとめていきます。
github.com
本記事は連載記事となっております。よろしければ前回の記事もご覧ください。
y-nakajo.hatenablog.com
y-nakajo.hatenablog.com
このEIP-1679は次のEthereum1.0のアップデートであるIstanbulで導入されるEIPについてまとめたものです。EIP-1679は現在はまだ導入される候補(Proposal)EIPをリストアップしたものであり、この中から期限までに実装可能で十分にテストされたものだけが、最終的にIstanbulとしてEthereumに導入されます。
リストをみてわかる通り、多くのEIPが候補に上がっており、また似たようなEIPも多数含まれています。引き続きこれらのEIPをカテゴライズしながら紹介します。
State Rent関係の提案
EIP-1679のリストの後半のいくつかはState Rentに関係する提案です。State RentはEth1.0で増加を続けるデータ容量を改善するための提案であり、かなり大規模な変更が予定されています。今回はIstanbulの導入候補のリストからStare Rentに関係するEIPを解説していきます。
State Rentとは
EIPの解説をする前に、State Rentの目的と概要を簡単に説明します。より詳細なState Rentの仕様とロードマップは以下のサイトを参照ください。
github.com
github.com
ethresear.ch
ethereum-magicians.org
現在はver3を議論中のようです。
目的
State Rentの目的はシンプルで、EthereumのStateデータの増加をある一定サイズにとどめることを目的としています。
理由としてはEIP-1884でデータとして提示されているようにStorageデータの増加に伴い、EVMの処理速度やブロックデータの同期に関して非常に時間がかかってしまうという問題を解決するためです。
State Rentの仕様
まだ議論の最中ではありますが、State Rentの主な仕様は以下のようなものになります。
- Stateの利用に関して家賃(Rent)を徴収する。
- Rent Feeを支払えないAccount(主にContractだがEOAも対象となる)はState Root HashとCode Hash以外のデータが削除される。
- Rent FeeはStateが変更された時(Contractのstorageに変更があった時や、ETHの送金時など)に請求される。
- 削除されたAccountは削除された時と全く同じState DataとCodeと必要なRent Feeを支払うことで復活できる。
それでは、上記を踏まえてState Rent関係のEIPを解説します。
EIP-2026：State Rent H - Fixed Prepayment for accounts （account作成費用）
State Rent導入のための最初のロードマップとなるこの提案は、Account Stateに「rentbalance」fieldを追加し、またaccount作成時に固定料金の費用を請求するように変更する提案です。対象がaccountなのでEOA(External Owned Account)とContractの両方が対象となります。account作成時に徴収された費用(ETH)はrentbalanceに保存されます。また、rentbalanceに保存された費用(ETH)はmining報酬には含まれません。これにより、理論上accountの作成数に上限が加えられることになります。
rentbalanceはself-destructが実行されContractを削除する時にbalanceと一緒に返金されます。
この提案ではaccount作成時に固定料金を請求することしか定義されていません。家賃の請求やstroageに対する家賃設定などは別のEIPに提案されています。
EIP-2027：State Rent C - 正味コントラクトサイズの計算
State Rentのロードマップの一部であるこの提案では、Contractのstorageの正味サイズをカウントする仕組みを導入します。「正味」としているのは、この提案が導入されたブロック以降のstorageの増減のみをカウントするためです。Contractが利用している全ての厳密なstorageサイズを計測する提案はまた別のEIPとして提案される予定となっています。
この提案ではHUGE_NUMBER(2^63が予定されている)を基準値として、storageのサイズを増減させます。これは、後から導入される厳密なstorageカウントが導入された際に、厳密なカウントか正味のカウントかを識別するためです。
この提案はあくまで、storageの正味サイズの計測方法を提案しているだけみたいです。
EIP-2029：State Rent A - State Counters Contract
この提案はState Rentで必要となる色々な情報を保存するためのカウンターコントラクトを追加する提案です。
このカウンターコントラクトには、EIP-2027で提案されているContract(=Storage) Sizeや、そのほかにState Size、Transaction Sizeを保存します。
State Rentを導入するにあたって必要となる様々な情報をEthereumにどのように追加するかの議論が行われ、結果としてコントラクトで追加するのが一番コストが低くなりそうということになったみたいです。
この提案では、カウンターコントラクトのbytecodeおよびデプロイ方法などがまとめられています。特に、全てのEthereum Network上に同じaddressで展開する方法なども紹介されています。
なお、この提案は次で紹介するEIP-2031を導入する際の前提となっています。
EIP-2031：State Rent B - 正味トランザクションカウンター
この提案は、家賃を払えずに削除されてしまったaccountが復帰した時にリプレイアタックされないようにするための提案です。
EthereumではEOAが送信したTransactionはnonceという値によって区別されます。しかし、State Rentが導入された後は以下の手順でリプレイアタックが可能になってしまいます。
- Rent Feeが払えずにaccount Aが削除される。このaccount Aはトランザクションを3回発行済みでnonce=3である。
- Rent Feeをチャージしてaccount Aを復活させる。この時nonceは0にリセットされる。
- account Aは十分なRent Feeを持っており、かつnonceは0のため、削除前に発行していたトランザクションが再度有効となる。（リプレイアタックが成立する）
この問題を回避するために、EIP-2029で作成されたCounterContractに全ての発行されたトランザクションの数量を保存し、復帰したaccountはこのトランザクション数量をnonceとして用いるように変更します。これにより、nonce値が必ず新しい値となりリプレイアタックを防ぐことが可能になります。注意点としてはCounterContractに保存するトランザクションの数量はアカウントごとではなく、Ethereum全体での発行数になります。
なお、この提案では上記のトランザクションの保存方法や、CounterContractのどこに保存するかなどの仕様がまとめられています。
まとめ
３回目となる今回はEth2.0のロードマップにも含まれているState Rentおよびそれに関連するEIPについて解説しました。Ethereumで今一番問題となっているstateデータの増加を抑制するためにもこれらのState Rent関連のEIPは出来るだけ早く導入を進めていく必要があると思います。
カテゴリとしてまとめられそうなEIPについては今回で最後になると思います。次回は残りのEIPについて個別に解説しようと思います。
