search

concrete-eth / concrete-geth

Concrete is a framework for building application-specific rollups on the OP Stack
GNU Lesser General Public License v3.0
47 stars 19 forks source link

Add EIP-1153 transient storage methods to the Concrete environment #31

Closed therealbytes closed 4 weeks ago

therealbytes commented 1 month ago

Rationale

Motivation behind EIP-1153:

Running a transaction in Ethereum can generate multiple nested frames of execution, each created by CALL (or similar) instructions. Contracts can be re-entered during the same transaction, in which case there are more than one frame belonging to one contract. Currently, these frames can communicate in two ways: via inputs/outputs passed via CALL instructions, and via storage updates. If there is an intermediate frame belonging to another untrusted contract, communication via inputs/outputs is not secure. Notable example is a reentrancy lock which cannot rely on the intermediate frame to pass through the state of the lock. Communication via storage (SSTORE/SLOAD) is costly. Transient storage is a dedicated and gas efficient solution to the problem of inter frame communication.

This applies to Concrete precompiles as well, e.g., right now there is no way to implement a transient reentrancy lock.

Implementation

Add TransientLoad and TransientStore methods to the Concrete environment. These should work almost exactly like StorageLoad and StorageStore but call the StateDB.GetTransientState and StateDB.SetTransientState methods instead. Transient storage access (both reads and writes) are priced the same as a warm SSTORE of a dirty slot (100 gas), which is declared as params.WarmStorageReadCostEIP2929 in geth.

About transient storage (EIP-1153 added as part of the Dencun Upgrade):

This proposal introduces transient storage opcodes, which manipulate state that behaves identically to storage, except that transient storage is discarded after every transaction, and TSTORE is not subject to the gas stipend check as defined in EIP-2200.

Gas cost for TSTORE is the same as a warm SSTORE of a dirty slot (i.e. original value is not new value and is not current value, currently 100 gas), and gas cost of TLOAD is the same as a hot SLOAD (value has been read before, currently 100 gas). Gas cost cannot be on par with memory access due to transient storage’s interactions with reverts.

See:

[ODHack 4.0] Contributors: Note that we highly recommend that you comment on the issue by introducing yourself and how you plan on tackling the issue! Just saying you want an issue is not helpful. This will help with assigning tasks, especially if many comment.

princeibs commented 1 month ago

Can I hop on this?

RajeshRk18 commented 1 month ago

Shall I take up this?

therealbytes commented 1 month ago

Hey @RajeshRk18 @princeibs Would you mind providing some context about yourselves so I can better assign the issue?

Adecom16 commented 1 month ago

I am Adeoluwa a smart contract developer can i work on this ?

PhantomOz commented 1 month ago

I can implement this and would love to work on this

princeibs commented 1 month ago

Hi @therealbytes, my comment came first on this issue but you assigned it to someone else. Is there any particular reason for that please?

therealbytes commented 1 month ago

@RajeshRk18 Any progress here?

therealbytes commented 1 month ago

@princeibs Hey! Issues are not assigned by the order of comments. If @RajeshRk18 doesn't provide any updates I will re-assign the issue.

RajeshRk18 commented 1 month ago

@RajeshRk18 Any progress here?

I am on it! Went through the eip and codebase. Started implementing

therealbytes commented 1 month ago

What's your status on this? @RajeshRk18

RajeshRk18 commented 1 month ago

What's your status on this? @RajeshRk18

Working on it rn sir! Will make a pr soon