EIP-1153: Transient storage opcodes

[codyborn]

PR description

• Implement EIP-1153: Transient storage opcodes
• Create new EIP1153 spec for including this feature post Paris.
• Added a new ByteCodeBuilder class to make it easier to construct the E2E test cases.

Eip1153 Tests 🆕

TStoreEVMOperationTest.java

• load arbitrary value is 0 at beginning of transaction: TLOAD(x) is 0
• loading after storing returns the stored value: TSTORE(x, y), TLOAD(x) returns y
• loading any other slot after storing to a slot returns 0: TSTORE(x, y), TLOAD(x + n) where n > 0 returns 0
• contracts have separate transient storage—loading a slot in a separate contract after storing returns 0: TSTORE(x, y), CALL(z, ...), TLOAD(x) returns 0
• reentrant calls access the same transient storage: TSTORE(x, y), CALL(self, ...), TLOAD(x) returns y
• reentrant calls can manipulate the same transient storage: TSTORE(x, y), CALL(self, ...), TSTORE(x, z), TLOAD(x) returns z
• successfully returned calls do not revert transient storage writes: TSTORE(x, y), CALL(self, ...), TSTORE(x, z), RETURN, TLOAD(x) returns z
• revert undoes the transient storage write from the failed call: TSTORE(x, y), CALL(self, ...), TSTORE(x, z), REVERT, TLOAD(x) returns y
• revert undoes all the transient storage writes to the same key from the failed call, i.e. applies the modifications in reverse order: TSTORE(x, y), CALL(self, ...), TSTORE(x, z), TSTORE(x, z + 1) REVERT, TLOAD(x) returns y
• revert undoes transient storage writes from inner calls that successfully returned: TSTORE(x, y), CALL(self, ...), CALL(self, ...), TSTORE(x, y + 1), RETURN, REVERT, TLOAD(x) returns y
• delegatecall manipulates transient storage in the context of the current address: TSTORE(x, y), DELEGATECALL(a, ...), TSTORE(x, z), RETURN, TLOAD(x) returns z
• delegatecall reads transient storage in the context of the current address: TSTORE(x, y), DELEGATECALL(a, ...), TLOAD(x) returns y
• transient storage cannot be manipulated in a static context: TSTORE(x, y), STATICCALL(a, ...), TSTORE(x, z) reverts
• transient storage cannot be manipulated in a static context when calling self: TSTORE(x, y), STATICCALL(self, ...), TSTORE(x, z) reverts
• transient storage cannot be manipulated in a nested static context: TSTORE(x, y), STATICCALL(self, ...), CALL(self, ...), TSTORE(x, z) reverts
• Transient storage can be accessed in a static context when calling selfTSTORE(x, y), STATICCALL(self, ...), CALL(self, ...), TLOAD(x) returns y
• transient storage does not persist beyond a single transaction: TSTORE(x, y), RETURN, (new transaction to same contract), TLOAD(x, y) returns 0

TStoreOperationTest.java

• Insufficient gas
• Simple tstore test
• TLoad uninitialized
• TStore/TLoad
• TStore->TStore->TLoad
• No gas refund

Documentation

• I thought about documentation and added the doc-change-required label to this PR if
  updates are required.

Changelog

Unclear if I should add a new record to the changelog. Please advise.

• I thought about the changelog and included a changelog update if required.

[siladu]

Thanks for the contribution @codyborn!

Please can you point me to where EIP-1153 is confirmed for Shanghai?
I can't see it in this list: https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md#eips-considered-for-inclusion

Also, you'll need to sign off your commits for the DCO check to pass, see https://wiki.hyperledger.org/display/BESU/DCO

[codyborn]

Thanks @siladu! It's not yet confirmed for any hardfork; I just put it in the Merge++ hardfork as a placeholder. Do you have a recommended practice for features like this that aren't yet scheduled?

For the DCO, do I need to recreate the PR entirely with new commits or is there a way to roll all these up into a new commit?

[siladu]

Hi @codyborn,

Do you have a recommended practice for features like this that aren't yet scheduled?

You could put it behind an experimental feature toggle. The toggle code has been removed but something similar was done for EIP-1559, see #641

Since it's not yet planned to go into Shanghai, it would be best to remove the Shanghai hard fork code and just use the toggle. Then it can be added to the appropriate fork when the time comes.

For the DCO, do I need to recreate the PR entirely with new commits or is there a way to roll all these up into a new commit?

Shouldn't need to recreate the PR. You can either amend your existing commits with the sign-off and force push; or squash, sign-off and force push.

[atoulme]

Good code contrib. A few nits and things to clean up. 👍

[codyborn]

Hi @shemnon, I've merged the latest upstream changes into this PR. Let me know if there are any outstanding things to address. Thanks!

[shemnon]

@codyborn I updated the codebase to deal with some large changes underneath relating to optimizations. I also updated the storage to be attached to the MessageFrame instead of the account. It greatly simplified the implication for the EVM library as well, Went from 44 files down to 12.

Let me know what you think.

tstore is now CFI for cancun, moved into Cancun spec.

[codyborn]

@codyborn I updated the codebase to deal with some large changes underneath relating to optimizations. I also updated the storage to be attached to the MessageFrame instead of the account. It greatly simplified the implication for the EVM library as well, Went from 44 files down to 12.

Let me know what you think.

Looks great! Just gave it a pass and agree it's much simpler with the MessageFrame approach. Nice work 👏