イーサリアムのベルリンハードフォークが完了しました。ガス料金にどのような影響があるでしょうか？

クイックファクト

ベルリンハードフォークにより、一部のオペコードのガスコストが変更されます。ガス料金の値が dapp またはスマートコントラクトにハードコードされている場合、それらの実行が停止する可能性があります。このような状況が発生し、スマートコントラクトが更新できない場合、コンシューマーは EIP-2930 のアクセスリストを使用して、オペコードのその部分を使用する必要があります。
アクセスリストを使用するとガスコストを少し削減できますが、場合によってはガスの総消費量が実際に増加する可能性があります。
geth は、アクセスリストの作成を簡素化するために、eth_createAccessList という新しい RPC メソッドを追加します。

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

EVM によって実行されるすべてのオペコードには、関連するガスコストがあります。それらのほとんどは固定コストを持ちます。PUSH1 は常に 3 単位のガス、MUL は 5 単位のガスがかかります。その他は変化します。たとえば、SHA3 のオペコードコストは入力のサイズによって異なります。

ベルリンハードフォークの影響を最も受けるオペコードである SLOAD と SSTORE に焦点を当てます。 EXT* や CALL* などのアドレス固有のオペコードについては、ガスコストも変化するため、後で説明します。

ベルリン前のSLOADのガスコスト

EIP-2929 より前は、SLOAD のガスコストは単純で、常に 800 ガスを消費していました。だから、（今のところ）何も言うことはありません。

ベルリン以前のSSTOREのガス料金

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

ストレージスロットの値が 0 から 1 (またはゼロ以外の値) に変更された場合、ガス消費量は 20000 になります。
ストレージスロットの値が 1 から 2 (またはその他のゼロ以外の値) に変更された場合、ガス消費量は 5000 になります。
ストレージスロットの値が 1 (またはゼロ以外の値) から 0 に変更された場合、ガス消費量も 5000 ですが、トランザクションの終了時に 1 ガス料金が払い戻されます。ガス払い戻しはベルリンハードフォークの影響を受けないため、この記事ではこれについては説明しません。
ストレージスロットの値が以前に同じトランザクションで変更されている場合、後続のすべての SSTORE のガス消費量は 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 ガスを消費していました。ここで、ストレージスロットにアクセスしたかどうかが重要になります。アクセスされていない場合、ガスコストは 2100 です。アクセスされている場合は 100 です。したがって、スロットがアクセスされたストレージキーのリストに含まれている場合、SLOAD のガス消費量は 2000 未満になります。

ベルリン後のSSTORE

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

ストレージスロットの値が 0 から 1 (またはゼロ以外の値) に変更された場合、ガスコストは次のようになります。

ストレージキーにアクセスしていない場合、22100
訪問された場合、20000

ストレージスロットの値が 1 から 2 (またはその他のゼロ以外の値) に変更された場合、ガス消費量は次のようになります。

ストレージキーにアクセスしていない場合、5000
訪問された場合、2900

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

ストレージスロットの値が以前に同じトランザクションで変更されている場合、後続のすべての SSTORE のガス消費量は 100 になります。

ご覧のとおり、SSTORE が変更しているスロットが以前にアクセスされた場合、最初の SSTORE は 2100 ガス未満を消費します。

要約する

次の表は上記の値を比較したものです。

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

EIP-2930: オプションのアクセスリストトランザクション

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

しかし、すでにアクセスされたアドレスやストレージキーのガス消費量が少ない場合、ガス消費量を削減するためにすべてをトランザクションアクセスリストに追加すればよいということでしょうか?素晴らしい！ガス代を支払う必要はありません！ただし、これは完全に真実ではありません。アドレスを追加してキーを保存するたびに、ガス料金を支払う必要があるからです。

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

アクセスリスト: [{
  住所： ""、
  ストレージキー: [
    「0x0 ...」
  ]
}]

このアクセスリストを添付したトランザクションを送信すると、slot0x0 を使用する最初のオペコードは SLOAD となり、2100 ガスではなく 100 ガスを消費します。これにより、ガスが 2000 削減されます。ただし、ストレージキーがトランザクションのアクセスリストに追加されるたびに、1900 ガスが消費されます。つまり、ガソリン100円しか節約できなかったのです。 (スロットにアクセスする最初のオペコードが SLOAD ではなく SSTORE だった場合、2100 ガスを節約できます。つまり、キーを保存するコストを考慮すると、合計で 200 ガスを節約できることになります。)

これは、トランザクションアクセスリストを使用する限りガスを節約できることを意味しますか?いいえ、アクセスリストにアドレスを追加するにも料金を支払う必要があるためです (つまり、「

（）のガス。

訪問したアドレス

これまでは、オペコード SLOAD と SSTORE についてのみ説明してきましたが、Berlin アップグレードで変更されたオペコードはこれらだけではありません。たとえば、オペコード CALL の前の固定消費量は 700 です。ただし、EIP-2929 以降では、アドレスがアクセスリストにない場合は消費量が 2600 になり、リストにある場合は 100 になります。また、アクセスされたストレージキーと同様に、以前にどのオペコードでアクセスしたかは関係ありません (たとえば、EXTCODESIZE が初めて呼び出された場合、そのオペコードは 2600 GAS かかりますが、同じアドレスを使用する後続の EXTCODESIZE、CALL、または STATICCALL は 100 GAS しかかかりません)。

これはアクセスリストを使用したトランザクションにどのような影響を与えますか?たとえば、トランザクションをコントラクト A に送信し、そのコントラクトが別のコントラクト B を呼び出す場合、次のようなリストを追加できます。

アクセスリスト: [{ アドレス: "", ストレージキー: [] }]

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

しかし、なぜ別の契約について話しているのでしょうか?私たちが呼んでいる契約はどうですか?この契約でこれらの操作を実行しないのはなぜですか?

アクセスリスト: [
  {アドレス: "", ストレージキー: []},
  {アドレス: "", ストレージキー: []},
]

これを実行することは可能ですが、EIP-2929 では、呼び出されるコントラクトのアドレス (つまり tx.to) がデフォルトで accessed_addresses リストに追加されることが明確に規定されているため、コスト効率は良くありません。したがって、追加の 2400 ガスを支払う必要はありません。

前の例をもう一度分析してみましょう。

アクセスリスト: [{
  住所： ""、
  ストレージキー: [
    「0x0 ...」
  ]
}]

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

ご想像のとおり、分析を行うことと、アクセスリストを手動で作成することは、それほど楽しいことではありません。幸いなことに、もっと良い方法があります。

eth_createAccessList RPC メソッド

Geth (バージョン 1.10.2 以降) には、アクセスリストを生成するために使用できる新しい eth_createAccessListRPC メソッドがあります。これは eth_estimateGas と同様に使用されますが、ガスの推定値を返す代わりに、次のようなものを返します。

 {
  "アクセスリスト": [
    {
      「アドレス」: 「0xb0ee076d7779a6ce152283f009f4c32b5f88756c」、
      「ストレージキー」: [
        「0x0 ...
        「0x0000000000000000000000000000000000000000000000000000000000000000000000001」
      ]
    }
  ]、
  "ガス使用": "0x8496"
}

つまり、トランザクションで使用されるアドレスとストレージキーのリストと、アクセスリストが追加された場合に消費されるガスが提供されます。 (eth_estimateGas と同様に、これは推定値であり、トランザクションが実際にマイニングされたときにこのリストは変更される可能性があります。) ただし、これは、リストにアクセスせずに同じトランザクションを送信する場合よりもガス消費量が低くなることを意味するものではありません。

時間の経過とともに正しい使用方法がわかってくると思いますが、疑似コードは次のようになると思います。

ガス推定 = 推定ガス(tx)とする
アクセスリスト、ガス使用済み } を createAccessList(tx) にします。
ガス使用量 > ガス推定値の場合
  アクセスリスト[tx.to]を削除する
}
tx.accessList = アクセスリスト;
送信トランザクション(tx)

契約を緩める

アクセスリストの主な目的はガスを使用することではないことに注意する必要があります。 EIP で説明されているとおり:

「トランザクションは、アクセスして前払いする予定のアカウントとストレージスロットを事前に指定できるため、EIP-2929 によってもたらされる契約破棄のリスクが軽減されます。最終的に、実際の実行では、オペコード SLOAD と EXT* は 100 ガスしか消費しません。この低いガス消費は、この EIP によって引き起こされる破棄を防ぐだけでなく、EIP-1884 によって制限されている契約を「緩和」します。」

つまり、契約でトランザクションの実行コストについて想定している場合、ガスコストの増加によって契約が機能しなくなる可能性があります。たとえば、コントラクトが someOtherContract.someFunction{gas: 34500}() のように別のコントラクトを呼び出すと、someFunction が正確に 34500 ガスを消費すると想定されるため、エラーが発生します。しかし、適切なアクセスリストを追加すると、契約は再び機能します。