イーサリアムは本日、ベルリンハードフォークアップグレードを完了します。知っておくべきこと

この記事では、このハードフォークアップグレードの前後のガスコスト計算、EIP-2929 でこれがどのように変化するか、および EIP-2930 で導入されたアクセスリスト機能の使用方法について説明します。原作者は、Nomic Labs のソフトウェア開発者である Franco Victorio です。

注: この記事は長いですが、重要なポイントをいくつか挙げます。

1. ベルリンハードフォークにより、一部のオペコードのガスコストが変更されました。 Dapp またはスマート コントラクトにハードコードされたガス値がある場合、それらが機能しなくなる可能性があります。このような状況が発生し、スマート コントラクトがアップグレードできない場合は、ユーザーはアクセス リスト (EIP-2930) を使用してスマート コントラクトを有効にする必要があります。

2. アクセス リストを使用するとガス コストをわずかに削減できますが、場合によってはガスの総消費量が実際に増加する可能性があります。

3. geth には、アクセス リストの作成を簡素化する新しい RPC メソッド (eth_createAccessList) が含まれています。

ベルリンハードフォーク前のガスコスト

EVM によって実行される各オペコードには、関連するガス コストがあります。ほとんどのオペコードでは、このコストは固定されています。PUSH1 には常に 3 単位のガスがかかり、MUL には 5 単位のガスがかかります。他のオペコードの場合、コストは可変です。たとえば、SHA3 オペコードのコストは入力のサイズによって異なります。

ベルリン ハードフォークの影響を最も受ける SLOAD および SSTORE オペコードに焦点を当てます。すべての EXT* および CALL* オペコードのように、アドレスをターゲットとするオペコードについては、ガス コストも変化するため、後で説明します。

ベルリンハードフォーク前のSLOAD

EIP-2929 がない場合、SLOAD のコストは単純で、常に 800 ガスを消費します。

ベルリンハードフォーク前のSSTORE

SSTORE は、そのコストがストレージ スロットの現在の値、新しい値、および以前に変更されたかどうかによって異なるため、ガスの観点からはおそらく最も複雑なオペコードです。基本的な理解を得るために、いくつかのシナリオのみを分析します。さらに詳しく知りたい場合は、この記事の最後にあるリンク先の EIP をお読みください。

1. スロットの値が 0 から 1 (またはゼロ以外の値) に変更された場合、コストは 20000 になります。

2. スロットの値が 1 から 2 (または他のゼロ以外の値) に変更された場合、コストは 5000 になります。

3. スロットの値が 1 (またはゼロ以外の値) から 0 に変更された場合、コストも 5000 になりますが、トランザクションの終了時にガスの払い戻しが受けられます。この投稿では、ベルリンハードフォークの影響を受けないため、払い戻しについては詳しく説明しません。

4. 値が以前に同じトランザクションで変更された場合、後続のすべてのストアのコストは 800 になります。

ここでの詳細は少し退屈ですが、重要な点は、SSTORE は非常に高価であり、そのコストはいくつかの要因に依存するということです。

EIP-2929 導入後のガスコスト

EIP-2929 はこれらすべての値を変更しますが、その前に、この EIP が導入する重要な概念である、アクセスされたアドレスとアクセスされたストレージ キーについて説明する必要があります。

アドレスまたはストレージ キーは、トランザクション中に以前に「使用」された場合にアクセスされたとみなされます。たとえば、別の契約を呼び出すと、その契約のアドレスが訪問済みとしてマークされます。同様に、あるスロットを SLOAD または SSTORE すると、トランザクションの残りの間はアクセスされたとみなされます。どのオペコードがそれを実行するかは関係ありません。SLOAD がスロットを読み取る場合、次の SLOAD および SSTORE でアクセスされたと見なされます。

ここで注意すべき点は、ストレージ キーが何らかのアドレスの「内部」にあることです。 EIP は次のように説明しています:

「トランザクションの実行中に、accessed_addresses: Set[Address] と accessed_storage_keys: Set[Tuple[Address, Bytes32]] のセットを維持します。」

つまり、ストレージ スロットがアクセスされると言う場合、実際にはペア (アドレス、ストレージ キー) がアクセスされると言います。

そうは言っても、新しいガソリン価格について話しましょう。

ベルリンハードフォーク後のSLOAD

ベルリン ハードフォーク以前は、SLOAD のコストは 800 GAS の固定でしたが、現在はストレージ スロットにアクセスしたかどうかによってコストが異なります。訪問しない場合は 2100 ガス、訪問する場合は 100 ガスかかります。したがって、スロットがアクセスされたストレージ キーのリストに含まれている場合、SLOAD のコストは 2000 GAS 削減されます。

ベルリンハードフォーク後のSSTORE

EIP-2929 を展開するコンテキストで、前の SSTORE の例をもう一度見てみましょう。

1. スロットの値が 0 から 1 (またはゼロ以外の値) に変更された場合、コストは 22100 (ストレージ キーにアクセスしなかった場合)、20000 (ストレージ キーにアクセスした場合) になります。

2. スロットの値が 1 から 2 (またはその他のゼロ以外の値) に変更された場合、コストは 5000 (ストレージ キーにアクセスしなかった場合)、2900 (ストレージ キーにアクセスした場合) になります。

3. スロットの値が 1 (またはゼロ以外の値) から 0 に変更された場合、コストは前のコストと同じになり、さらに払い戻しが行われます。

4. 値が以前に同じトランザクションで変更されている場合、後続のすべての SSTORE のコストは 100 になります。

ご覧のとおり、変更対象のスロットが以前にアクセスされた場合、最初の SSTORE のコストは 2100 GAS 少なくなります。

次の表は、これまでに変更されたすべての値をまとめたものです。

最後の行では、スロットがアクセスされたかどうかについて話すことは意味がないことに注意してください。なぜなら、以前に書き込まれていた場合は、同様にアクセスされていたはずだからです。

EIP-2930

この記事の冒頭で触れたもう 1 つの EIP は EIP-2930 です。これは、トランザクション ペイロードにアクセス リストを含めることができる新しいタイプのトランザクションを追加します。つまり、トランザクションの実行が開始される前に、どのアドレスとスロットを訪問したと見なすかを事前に宣言できるということです。たとえば、アクセスされていないスロットへの SLOAD には 2100 のコストがかかりますが、そのスロットがトランザクションのアクセス リストに含まれている場合、同じオペコードのコストは 100 になります。

しかし、アドレスまたはストレージ キーがすでにアクセスされている場合にガス コストが低くなる場合、トランザクションのアクセス リストにすべてを追加するだけでガス コストを下げることができるということですか?正確にはそうではありません。追加するアドレスとストレージ キーごとにガス料金を支払う必要があるためです。

例を見てみましょう。契約 A にトランザクションを送信すると仮定すると、アクセス リストは次のようになります。

このアクセス リストを使用してトランザクションを送信し、スロット 0x0 を使用する最初のオペコードが SLOAD だった場合、コストは 100 GAS (2100 GAS ではなく) になり、ガス消費量は 2000 GAS 削減されます。しかし、トランザクション アクセス リストに含まれる各ストレージ キーには 1900 GAS かかるため、節約できたのは 100 GAS だけです。 (そのスロットにアクセスする最初のオペコードが SSTORE だった場合、2100 ガスを節約できます。つまり、キーを保存するコストを考慮すると、合計で 200 ガスを節約できることになります。)

これは、アクセス リストを使用したトランザクションを使用するときに常にガスを節約できることを意味しますか?これは当てはまりません。なぜなら、リスト内のアドレスにアクセスするためにもガス料金を支払うからです（この例では、「

訪問した住所

上記では、SLOAD および SSTORE オペコードについてのみ説明しましたが、ベルリン ハードフォーク後に変更されたオペコードはこれらだけではありません。たとえば、オペコードを呼び出すための元の固定コストは 700 GAS でした。しかし、EIP-2929 を実装した後は、アドレスが訪問リストにない場合、コストは 2600 GAS ですが、訪問リストにある場合はコストは 100 GAS になります。また、アクセスされたストレージ キーと同様に、以前にアドレスにアクセスするために使用されたオペコードは関係ありません (たとえば、EXTCODESIZE が最初に呼び出された場合、そのオペコードは 2600 ガスかかり、同じアドレスを使用する後続の EXTCODESIZE、CALL、STATICCALL は 100 ガスかかります)。

これはアクセス リスト トランザクションによってどのように影響を受けますか?たとえば、別のコントラクト B を呼び出すトランザクションをコントラクト A に送信する場合、次のアクセス リストを含めることができます。

このアクセス リストをトランザクションに含めるには 2400 GAS の手数料を支払う必要がありますが、アドレス B を使用する最初のオペコードのコストは 100 GAS (2600 GAS ではなく) になります。したがって、これを行うことで 100 ガスを節約できます。また、B が何らかの方法でストレージを使用し、どのキーが使用されるかがわかっている場合は、それらをアクセス リストに含めることもでき、キーごとに 100/200 ガスを節約できます (最初のオペコードが SLOAD か SSTORE かによって異なります)。

しかし、なぜ別の契約を交渉する必要があるのでしょうか?私たちが電話した契約はどうなったのですか?これをやってみませんか？

これを実行することもできますが、EIP-2929 では呼び出されたコントラクト アドレス (つまり tx.to) が常に accessed_addresses リストに含まれるように指定されているため、2400 GAS を無駄にするだけなので、価値はありません。

前のセクションの例をもう一度分析してみましょう。

複数のストレージ キーを含めない限り、これは実際には無駄です。 SLOAD が常に最初にストレージ キーを使用すると仮定すると、損益分岐点に達するには少なくとも 24 個のストレージ キーが必要になります。

当然ながら、このようなアクセス リストを分析して作成しても意味がありません。幸いなことに、もっと良い方法があります。

eth_createAccessList RPC メソッド

Geth (バージョン 1.10.2 以降) には、アクセス リストを生成するために使用できる新しい eth_createAccessList RPC メソッドが含まれています。使用方法は eth_estimateGas と似ていますが、ガスを推定する代わりに、次のような結果を返します。

つまり、このトランザクションが使用するアドレスとストレージ キーのリストと、アクセス リストが含まれている場合にかかるガスのコストが提供されます。 (また、eth_estimateGas と同様に、これは推定値であり、実際にトランザクションが行われるとリストが変更される場合があります。)

時間が経てば、正しいやり方がわかってくると思いますが、私の推測では、次のような疑似コードになります。

契約を有効にする

EIP が説明しているように、アクセス リストの主な目的はガスを使用することではないことを指摘することが重要です。

「EIP-2929 が導入するのは、トランザクションがアクセスする予定のアカウントとストレージ スロットをトランザクションが事前に指定して支払うことができるため、契約破棄のリスクを軽減することです。そのため、実際には、SLOAD および EXT* オペコードのコストは 100 GAS のみであり、この EIP による破棄を防ぐだけでなく、EIP 1884 が原因で停止している契約を「アクティブ化」するのに十分低いです。」

つまり、契約で特定の操作を実行するためのコストについて想定している場合、ガス コストの増加により契約が機能しなくなる可能性があります。たとえば、ある関数が正確に 34500 ガスを使用すると想定してコントラクトが別のコントラクト (例: someOtherContract.someFunction{gas: 34500}()) を呼び出すと、コントラクトは壊れますが、トランザクションに適切なアクセス リストが含まれていれば、コントラクトは再び機能します。

これらの EIP を自分でテストしたい場合は、Hardhat と geth を使用して実行できるいくつかの例を含むこのリポジトリをクローンできます。手順については、README ファイルを参照してください。