福岡ブロックチェーン勉強会#29 エキスパートコース
✅ ブログに書いたよチェック
Eth2.0 phase1, 2について
EIP-1679 Hardfork Meta: Istanbulについて
✅EIP-615:EVMのためのサブルーチンとスタティックジャンプ
✅EIP-663:無制限のSWAPおよびDUP命令
✅EIP-1057:プログラム作業証明書ProgPoW
含まれる前に評価されるべきである、標準的なセキュリティ上の考慮事項の上にそしてそれを超える保留中の監査があり ます。
✅EIP-1108:alt_bn128プリコンパイルガスコストの削減
✅EIP-1109:PRECOMPILEDCALL命令コード(プリコンパイルされた契約のCALL費用を削除)
EIP-1962の要件
✅EIP-1283:ダーティーマップを使用しないSSTOREのネットガス計測
3月にupdateしたConstantinopleに導入されなかったやつ。
✅EIP-1344:ChainIDオペコードの追加
EIP-155は、異なるチェーン間のリプレイ攻撃を防ぐためにチェーンIDを使用することを提案しています。特にEIP-712を使用したレイヤ2シグネチャ方式の場合、シグネチャを処理するときにスマートコントラクト内で同じ可能性があることは大きな利点となります。
EIP-1344とEIP-11965とEIP-1959の3つは競合している。多分この3つのうちどれか1つが採用されるんじゃないかな?
✅EIP-1352:プリコンパイル/システム規約に制限付きアドレス範囲を指定してください
✅EIP-1380:自己召集のためのガス代の削減
すでにロード済みのコードの場合はCALLのgasCostを700から40に引き下げる。
中身の説明では自分自身のメソッド呼び出しがJumpじゃなくてCallで行えるようになる。とかの説明があったので基本的には自分自身への呼び出しに使うことを想定かな?でも、書き方的に一度ロードしたほかのコントラクトのメソッドを何度も呼び出す場合にも安くなる。
EIP-1283の経験から、EVMのステートに依存してgasCostが安くなる系の変更は危ない気がする。。。。
EIP-1559:ETH 1.0チェーンのための手数料市場の変更
premium-feeを追加で支払えるので現状とあんまり変わらないんじゃないの?という気がしている。急激な増加は抑制される?
1wei教のほうが優れていると思う!
✅EIP-1965:chainIDが特定のブロック番号で有効かどうかを調べる方法
EIP-1344の拡張。Ethereum Classicの時のようにチェーンが分裂した際に、リプレイアタックを防ぐために少数派のチェーンがchainIDを変更した場合に、過去のchainIDも引けるようにするための提案。
EIP-1344とEIP-11965とEIP-1959の3つは競合している。多分この3つのうちどれか1つが採用されるんじゃないかな?
EIP-1702:一般アカウントバージョニングスキーム
アカウントにバージョンを識別するステートを追加するという提案。この提案導入後に作成されたアカウント・コントラクトだけにバージョンステートが追加される。導入後はEVMなどのバージョンは追加されたステートを見ることで識別可能となる。この提案が導入前にデプロイされたコントラクトを識別するにはステートの数を見ればよい。
✅EIP-1706:通話料よりも低いガスレフトでSSTOREを無効にする
EIP-1283を導入するための付随の提案。EIP-1283の欠陥を補足する提案ともいえる。
残りのgasが5000未満の場合はSSTOREを禁止する。新しいlogのみ許可するみたいな新しいcontext状態を追加するのはコストが高いなどいろいろ検討した結果、現状のEVMに追加の制限を入れる感じに落ち着いたっぽい?
なので、場合によってはTransaction発行時に5000gas余分に積まないといけない。
✅EIP-1803:わかりやすくするためにオペコードの名前を変更
✅EIP-1829:楕円曲線線形結合のプリコンパイル
任意の楕円曲泉に対してEC_ADDとEC_MULができるプリコンパイルの導入っぽい?
Rationale
Generic Field and Curve. Many important optimizations are independent of the field and curve used. Some missed specific optimizations are:
✅EIP-1884:トライサイズに依存するオペコードの価格変更
トライ木、つまりアカウントのステートを読みだす処理が、最近のアカウントの増加に伴って処理コストも増加してるので、該当する操作を行うOPCODEのgasCostを見直そうというもの。
✅EIP-1930:厳密なガスセマンティクスを持つCALL。ガスが不足している場合は元に戻します。
CALLやDELEGATECALLを実行するときに、利用するgasの量を指定する。call(gas, a, v, in, insize, out, outsize)な感じで。だけど、このコンパイル時に指定されたgas量はあくまで最大値であり、実行時にはCALLを実行するときに残っているgas量がここで指定されたgas量より少なくてもCALLは実行される。(もちろんその時は残っているgasだけでCALL先のコードを実行しなければいけない)
この提案では、strictにgas指定を強制するCALLを追加するという提案。
✅EIP-1985:特定のEVMパラメータに対する適切な制限
実際の実装では、64bitまでとかに制限されている値を、仕様としてその範囲内のものとちゃんと定義しましょう。的な提案。
✅EIP-1959:chainIDがchainIDの履歴の一部であるかどうかをチェックするための新しいオペコード
EIP-1344とEIP-11965とEIP-1959の3つは競合している。多分この3つのうちどれか1つが採用されるんじゃないかな?
✅EIP-1962:EC演算およびランタイム定義との組み合わせ
EIP-1829に代わるもの
EIP-2014:拡張状態オラクル
チェーン内部の情報をオラクルで取得するのがかなり微妙な気がする。。。。
✅EIP-2026:State Rent H - 口座の前払いを修正
賃貸料を実装する前の事前準備的なもの。
実質的にアカウントの新規作成にたいして手数料が課されることになる。
✅EIP-2027:State Rent C - 正味契約規模の会計
コントラクトが消費しているslot数を保持するようにする。
これにより、後々SLOADなどストレージを変化させるgasCostを利用しているstorage数に応じて自動的に増減させるために使えるかも?
高速同期のときに、ちゃんと予定通りのコントラクトを復元できたかどうかパトリシアマークルルートを生成する前に、仮チェックできる。
などなどの恩恵はありそうだけど、現状では実質特に何かが便利になるわけではない。あくまでstate rent導入のロードマップの一部。
最終的には全体のstorage利用数がカウントされた状態になるらしい?
✅EIP-2028:Calldataのガスコスト削減
Transaction.dataに含めるNonZeroなデータのgasCostを68からTBDに変更する提案。これにより1Blockに含まれるデータ量が増加し、スケーラビリティーの改善につながる。Merkle Treeの提出などが安くなる。
✅EIP-2029:State Rent A - State Counters Contract
EIP-2031の要件
AccountのTransaction数や別アカウント作成数などを記録するコントラクトをEthereumにデプロイする。
このコントラクトはすべてのEthereumネットワーク上で同じaddressになるようにデプロイされる。
このコントラクトはアカウントのnonceを記録するためのもの。State Rent導入後に、家賃不足で追い出されたアカウントが、家賃納入して戻ってきたときにnonceを正確にカウントできるようにするもの。
✅EIP-2031:State Rent B - 正味取引カウンター
アカウントごとのトランザクション数をカウントするコントラクト
EIP-2029のコントラクトからリンクされて使われる。
このEIPではこのEIPが導入された後に作成されたトランザクションについてのみカウントする。なのでNet。
State Rentの仕様書
State RentのPoC。こっちのほうが分かりやすいかも。
State Rentの簡単なまとめ
storage利用に家賃が必要になる。
家賃はstorageの状態が変わったときに請求される
家賃が足りなくなったら、code hashとstorage root hashだけ残して残りは0にリセットされる(evict)
家賃を支払ったら再度使えるようになる。(この時nonceが0からリスタートするので、リプレイアタックされてしまう。それを保護するためにEIP-2029や2031が提案されている)。元の提案ではstateに新たにvalid-untilフィールドが追加されるようになってたけどそこは議論の中で変わったのかな?
対象がコントラクトの場合は復帰のプロセスが少し複雑になる。大雑把に言うと、evictされた以前のstorage状態とcodeを完全に復元したうえで、家賃を充填させる必要がある。
本題とはずれるが、Contractにrent feeが請求されるようになった時の、既存のContractモデルの問題点と解決策のアイデアをvitalikがまとめたもの。
✅EIP-2035:ステートレスクライアント - SLOADとSSTOREをブロックプルーフの代金として再評価
State Rentのロードマップの一つ。
ステートレスクライアント導入のための事前の変更提案。SLOADとSSTOREのgasCostを増加させる。
ステートレスクライアントではそのBlock内にそのBlockに含まれているTransactionを実行するのに必要となるstorageの状態と、その実行結果のblock proofを含む。これらの情報はminerによって作成される。よってminerの増加する作業に大して追加の報酬を支払うための提案。
SLOADとSSTOREが多いとそれだけ、block proofの構築処理と、blockに含まれるstorage情報が増えるのでそれもgasCost増加の理由。
✅EIP-2045:EVMオペコードのパーティクルガスコスト
SWAPやDUP、ADD、SUB、MULなどの単純な計算はファイルI/Oが発生するSSTOREなどに比べて高価すぎるので、もっと安くしようという提案
とはいえ、現状ADDなどは3gasのコストであり、gas costは最小値としても1までしか下げられない。なので価格を下げるにも限界がある。
そこで、1gas = 10000 particle gasカウンタを追加する。ADDなどは3000particle gas(= 0.3gas)とすることで現状の1/10にコストを削減する。
✅EIP-2046:プリコンパイルに対するスタティックコールのガスコストの削減
EIP-1109と似たような提案。