【完全保存版】EIP-2930（アクセスリスト）の翻訳・解説

０　シンプルな概要

アクセスリストを含むトランザクションタイプを追加します。

翻訳者注
トランザクションタイプにつきましては、下の記事をご参照ください。
ただ、その名の通り、トランザクションの大枠の種類のことです。

アクセスリストとは、トランザクションがアクセスする予定のアドレスとストレージキーのリストのことです。

リスト外へのアクセスも可能ですが、その分費用が高くなります。

１　抽象的な説明

新たなEIP-2718トランザクションタイプを導入します。

そのフォーマットは0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])となります。

アクセスリストはアドレスとストレージキーのリストを指定します。

これらのアドレスとストレージキーは、accessed_addressesとaccessed_storage_keysというグローバルなセット（EIP-2929で導入）に追加されます。

ガスコストが発生しますが、リスト外へのアクセスに比べて割引が適用されます。

２　モチベーション

このEIPは二つの機能を果たします。

EIP-2929によって導入されたコントラクト破壊のリスクを緩和します。

翻訳者注
EIP-2929は、Ethereumのストレージ操作（特にSLOADとEXT*オペコード）のガスコストを増加させる提案で、一部の既存のスマートコントラクトがガスコストの増加によって「壊れる」（正常に機能しなくなる）可能性がありました。

トランザクションは、アクセスする予定のアカウントとストレージスロットを事前に指定し、その分の料金を前払いできます。

その結果、実際の実行時には、SLOADとEXT*オペコードのコストは100ガスだけになります。

翻訳者注
アクセスリストを使ってトランザクションが事前にアクセスを予定しているアカウントとストレージスロットを指定し、それらの使用料を事前に支払っている場合、実際の実行時にSLOADやEXT*オペコードを使ってそのデータにアクセスするときのガスコストは大幅に下がります。

この提案では、それぞれのオペコードのコストが100ガスまで下がることを示しています。

これにより、ガスコストの高騰により実行が困難になってしまったスマートコントラクト（EIP-2929やEIP-1884による影響）が、低いガスコストで正常に機能するようになるという利点があります。

これは、EIP-2929による破壊を防ぐだけでなく、EIP 1884のために停止してしまったコントラクトを解除するのに十分低いコストです。

翻訳者注
EIP-1884も同様に、特定のオペコードのガスコストを増加させる提案で、これにより一部のスマートコントラクトが「行き詰まる」（実行が中断される）可能性がありました。

アクセスリストの形式とその形式を扱うロジックを導入します。

このロジックは、ブロック全体の証人、ReGenesisでの使用、時間をかけて静的な状態アクセスに移行するなど、他の多くの目的に再利用することができます。

翻訳者注
１　ブロック全体の証人（block-wide witnesses）
ブロック全体の状態を証明するために、アクセスリストの概念を利用できます。
これにより、特定のブロックが正当であることを確認する際のデータの取扱いが容易になります。

２　ReGenesisの使用
ReGenesisはEthereumのスケーラビリティと可用性を改善するための提案の一つです。

アクセスリストは、ReGenesisのコンテキストでの状態アクセスの管理を改善するのに役立ちます。

３　時間とともに静的な状態へのアクセスに移行
アクセスリストは、スマートコントラクトが時間とともにある特定の「静的」状態へとアクセスすることを可能にします。

これは、より予測可能な実行と、Ethereumの全体的なパフォーマンスの向上につながる可能性があります。

chatGPT-4

３　仕様

１　定義

１）TransactionType 1
EIP-2718を参照してください。

２）ChainId
このchainIDを持つネットワークでのみ有効なトランザクションです。

３）YParity
secp256k1署名のy値のパリティ（偶数の場合は0、奇数の場合は1）

翻訳者注
YParityは、暗号学的な署名生成で用いられる一つの概念で、特にEthereumなどの暗号通貨で使用されるsecp256k1という楕円曲線暗号に関連しています。

楕円曲線暗号では、一つのメッセージに対する署名は一つの座標(x, y)となり、これは楕円曲線上の一点を表します。
しかし、特定のx座標に対応するy座標は、通常、2つ（1つは曲線の上半分に、もう1つは下半分に）存在します。

これらは、楕円曲線がy軸に対して対称であるためです。

YParityは、これら2つの可能性のあるy座標のうちどちらが選ばれたかを示すために使用されます。もしy座標が偶数（上半分のメタファー）ならば、YParityは0となり、もしy座標が奇数（下半分のメタファー）ならば
ならば、YParityは1となります。

この情報によって、署名を検証する側は正しい座標点を選択することができ、署名が正確かどうかを確認することが可能となります。

この方式を用いる理由の一つは、データの効率的な保存と転送です。

YParityを用いることで、全てのy座標を保存して転送する必要がなく、代わりに1ビットの情報（YParity）だけを使用して、どちらのy座標が使用されたかを示すことができます。

２　パラメータ

FORK_BLOCK_NUMBERから、TransactionType 1の新たなEIP-2718トランザクションが導入されます。

このトランザクションのEIP-2718 TransactionPayloadはrlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList, signatureYParity, signatureR, signatureS])となります。

このトランザクションのsignatureYParity、signatureR、signatureS要素は、keccak256(0x01 || rlp([chainId, nonce, gasPrice, gasLimit, to, value, data, accessList]))に対するsecp256k1署名を表します。

翻訳者注
secp256k1は、楕円曲線暗号のための特定のパラメータを指定する暗号規格の一部です。

この名前は、楕円曲線暗号の特定の部分に対して、Secure Elliptic Curve (secp)と256ビット鍵長を使用することを指しています。

k1という接尾語は、この楕円曲線がKoblitz曲線であることを示しています。Koblitz曲線は、特定の計算を簡略化し、効率化するために設計された特殊な楕円曲線の一種です。

このトランザクションのEIP-2718 ReceiptPayloadはrlp([status, cumulativeGasUsed, logsBloom, logs])です。

トランザクションが有効であるためには、accessListは[[{20バイト}, [{32バイト}...]]...]型である必要があります。

ここで、...は「左のものをゼロ回以上」という意味です。例えば、以下は有効なアクセスリストです（全ての16進数文字列は実際にはバイト表現であります）

実行の開始時（つまり、EIP-2028のルールに従って21000 + 4 * ゼロ + 16 * 非ゼロのスタートガスが課される時点）、

翻訳者注
例を出して考えます。

まず、トランザクションを実行する基本コストは21,000ガスです。

これはトランザクションが単純にETHを送金するだけのもので、スマートコントラクトを呼び出すなどの複雑な処理を行わない場合のコストです。

さらに、トランザクションデータの内容に応じて追加のガスが必要になります。

このデータは、スマートコントラクトの関数を呼び出したり、その関数に引数を渡したりするためのものです。

EIP-2028によると、データの各バイトについて次のガスコストが適用されます。

・ゼロバイト（値が0のバイト）: 4ガス
・非ゼロバイト（値が0以外のバイト）: 16ガス

例えば、次のようなデータを含むトランザクションを考えてみましょう。

0xabcdef0000 

これは16進数表記で、1バイトは2桁の16進数で表されます。

したがって、このデータは5バイトに相当します（ab、cd、ef、00、00）

このデータのうち、最後の2バイトはゼロバイトで、残りの3バイトは非ゼロバイトです。

したがって、このトランザクションデータのガスコストは次のように計算できます。

・ゼロバイト: 4ガス * 2 = 8ガス
・非ゼロバイト: 16ガス * 3 = 48ガス

そのため、データのガスコストは合計で 8ガス + 48ガス = 56ガス になります。

基本コストの21,000ガスとデータのガスコストを合算すると、このトランザクションの全体的なガスコストは 21000ガス + 56ガス = 21056ガス となります。

そして、アクセスリストのための追加ガスを課します。

１アドレスあたり
ACCESS_LIST_ADDRESS_COSTガス、
１ストレージキーあたり
ACCESS_LIST_STORAGE_KEY_COSTガス

例えば、上記の例ではACCESS_LIST_ADDRESS_COST * 2 + ACCESS_LIST_STORAGE_KEY_COST * 2ガスが課されます。

なお、非ユニークなアドレスとストレージキーは禁止されていないことに注意してください。

ただし、それらは複数回課金され、高いガスコスト以外に実行フローや結果には何の違いもありません。

そして、値の複数回の包含によるガスコストの増加を除けば、推奨される単一の包含に対して実行フローや結果に他の違いはありません。

翻訳者注
アドレスを複数入れたとしても、実行フローや結果に何の影響もなく、ガスコストが増えるだけということですね。
つまり、これによるリスクは（ガスコストの増加以外）ないということです。

アドレスとストレージキーは即座にaccessed_addressesとaccessed_storage_keysのグローバルセットに読み込まれます。

これは次のロジックを使って行うことができます。

これはRLPデコードされたアクセスリストの検証の仕様をコード化したものとして二重の役割を果たします。

翻訳者注
これを見れば、どういう仕組みになっているかがわかりますね。

access_listの分だけ繰り返しています。

assert文を使って検証を行なっています。

accessed_addresses, accessed_storage_keysに加えて、gas_costも増加させていることがわかります。

アクセスリストは、トランザクションデータのようにバイトごとに料金が課されるわけではありません。

上記で述べたアイテムごとのコストは、アクセスリストデータの帯域幅コストだけでなく、トランザクションの評価時にこれらのアカウントとストレージキーにアクセスするコストもカバーするためのものです。

翻訳者注
帯域幅とは、通信ネットワークが一定時間内に転送できるデータの量を表す用語で、ここではEthereumのネットワークにおけるデータ転送を指しています。

大量のデータを送受信すると、それだけ多くのネットワークリソースを消費するため、そのコストが発生します。

したがって、このコストはアクセスリストを用いたトランザクションを行う際に、そのリストのデータをネットワーク上で転送するために必要なコストを指しています。

また、それに加え、アクセスするコストのことも言っています。

４　根本原理

１　アクセスリスト内のアクセスに対して少ない料金を課す

これは、トランザクションができるだけアクセスリストを使用することを奨励し、ストレージの読み込みが予測可能であるときにトランザクションの処理が容易になるためです。

クライアントはデータベースからデータを事前に読み込んだり、トランザクションが受信された時点で証人を求めたり、少なくともデータを並列に読み込むことができます。

翻訳者注
"証人（witnesses）"とは、Ethereumのコンテキストでは、ブロックチェーンの特定の部分（アドレス、ストレージキーなど）を証明するための情報のことを指します。

証人データは、トランザクションが特定のアドレスまたはストレージキーにアクセスするときに必要となります。

Ethereumのトランザクションは、通常、ネットワーク上の全てのノードによって検証されます。

トランザクションが特定のデータにアクセスする場合、そのデータが存在し、その状態がトランザクションによって予期される状態であることを証明するために、証人データが必要になります。

例えば、アドレスが存在し、そのアドレスのバランスがトランザクションによって引き出される金額以上であることを証明する必要があります。

２　重複を許す

このアプローチは最大限にシンプルさを追求するために採用されています。

これにより、どの要素に対して重複を防ぐべきかという問題が回避されます。

具体的には、アクセスリスト内の二つのアドレス/キー間で防ぐべきなのか、アクセスリストとトランザクションの送信者/受信者/新規に作成されたコントラクトとの間で防ぐべきなのか、また他に制限すべき箇所があるのか、といった疑問を避けることができます。

ガスはアイテムごとに課金されるため、同じ値をアクセスリストに二度含めることには利点がなく、コストだけが増えます。

したがって、実際にはこれがブロックチェーンの過剰な膨張を引き起こすことはないと考えられています。

３　署名はトランザクションタイプとトランザクションデータの両方に対して行われる

これは、トランザクションが異なるタイプのトランザクションとして「再解釈」されることを防ぐために行われます。

翻訳者注
トランザクションのデータ（TransactionPayload）だけではなく、TransactionTypeも署名することで、解釈の重複を避けることができます。

５　後方互換性

このEIPは、「予期せぬ」SLOADとアカウントアクセスを行うためのガスコストを高くします。

翻訳者注
SLOADは、Ethereumのスマートコントラクトで使用される命令の一つで、ストレージ（ストレージは永続的なデータストレージを指します）からデータを読み込むために使用されます。

つまり、SLOADはスマートコントラクトのストレージから特定のデータを取得するための命令です。

ガスは前払いであり、したがって固定ガスのローカル呼び出しに影響を与えないため、これは以前のガスコストの増加がリスクをもたらすような方法でコントラクトを破ることはありません。

翻訳者注
翻訳者は、この文章が現時点でよくわかっていません。
参考にchatGPTの回答を載せますが、合っているか現時点で判別がついていません。

Ethereumのスマートコントラクトのコンテキストで、「ローカル呼び出し」とは、スマートコントラクト内から他のスマートコントラクトの関数を呼び出すことを指します。（翻訳者はここが疑問です。）

これらの呼び出しは、一般的にはコントラクト間の相互作用やデータの取得などを可能にします。

そして、「固定ガスのローカル呼び出し」とは、これらの関数呼び出しのうち、呼び出される操作が固定のガスコストを持つものを指します。

具体的な例を挙げてみましょう。

あるスマートコントラクトAが、他のスマートコントラクトBの関数を呼び出すケースを考えてみます。

この時、スマートコントラクトBの関数が例えば、数値の加算などの比較的シンプルな操作を行うものであれば、その操作は「固定ガスのローカル呼び出し」となります。

なぜなら、その操作（数値の加算）は固定のガスコストを持つからです。

一方、スマートコントラクトBの関数が、大量のデータを扱う配列の操作や、複雑な計算を行うものであれば、その操作は固定のガスコストを持たない可能性があります。

そのガスコストは、操作が行う具体的な処理内容により変動するためです。

このように、「固定ガスのローカル呼び出し」は、呼び出される操作が固定のガスコストを持つスマートコントラクトの関数呼び出しを指します。

しかし、ストレージへのアクセスを大量に依存するアプリケーションは、経済的にはずっと実行しにくくなります。

６　セキュリティの考慮事項

１　アクセスリストの生成

アクセスリストは多くの状況でリアルタイムで構築するのが難しく、これはトランザクションの生成と署名の間に高いタイムラグがある環境や、トランザクションジェネレータの単純さが非常に重視される環境（例えば、ハードウェアウォレットなど）でさらに悪化します。

しかし、このEIPはアクセスリストに対して初期の10％割引を提案しているだけなので、アクセスリストの生成に手間をかけずにシンプルなトランザクションを作成するだけでほとんどコストがかからないはずです。

翻訳者注
つまり、このアクセスリストを使用しなくても、コストは多くかからないと言っています。

アクセスリスト外の状態にアクセスするコストは、ツールが開発され、アクセスリストの生成がより成熟するにつれて、将来のハードフォークで時間とともに増加すると予想されます。

翻訳者注
つまり、将来的には、アクセスリスト外にアクセスするコストは増加することが想定されています。
（アクセスリストを使った方が良いということを言っています。）

２　トランザクションサイズの膨張

アクセスリストが使用される結果として、平均ブロックサイズが増加します。

しかし、アクセスリストのバイトあたりのコストは、ストレージキーに対して1900 / 32 = 59.375、アドレスに対して2400 / 20 = 120となり、calldataよりもはるかに高価であるため、最悪の場合のブロックサイズは増加しません。

翻訳者注
コストは下のようになっています。

また、ストレージキーは32バイト、アドレスは20バイトなので、バイトあたりのコストを求めるために、割っています。

翻訳者注
つまり、ガスコストが高いので、それを送信者が払うことができず（もしくはためらう）、その結果、アクセスリストは大きくなりすぎないと予想されているようです。
結果として、ブロックサイズは増加しないことも考えられると言っているようです。

さらに、平均ブロックサイズの増加は、トランザクションの受信時にストレージを事前にフェッチしたり、ブロックを受信したときにストレージを並列にロードしたりする能力によって部分的に補償されます。

翻訳者注
事前にフェッチすることで、トランザクションが実行される際に必要となるデータをあらかじめ用意しておけるため、トランザクションの実行速度が向上し、結果としてブロックサイズの増加によるパフォーマンス低下を一部補うことができます。

さらに、「並行ストレージロード能力」により、ブロックを受け取った際に、そのブロック内の各トランザクションに関連するストレージデータを並行してロードすることができます。

これにより、全体的なブロックの処理時間が短縮され、これもブロックサイズの増加に対する影響を軽減します。

７　著作権

著作権および関連する権利はCC0を通じて放棄されます。

８　引用

このドキュメントを引用する際は以下のようにしてください。

Vitalik Buterin (@vbuterin), Martin Swende (@holiman), "EIP-2930: Optional access lists," Ethereum Improvement Proposals, no. 2930, August 2020. [Online serial].