Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: add support for transient storage in the solidity #14957

Draft
wants to merge 19 commits into
base: develop
Choose a base branch
from

Conversation

Amxx
Copy link

@Amxx Amxx commented Mar 20, 2024

EIP-1153 is now live on mainnet since DenCun, a week ago. The community shows a lot of interrest for transient storage, yet it is not nativelly supported by solidity. A quick search did not bring any ongoing effort to add that support.

EIP-1153 states that:

Language support could be added in relatively easy way. For example, in Solidity, a qualifier transient can be introduced (similar to the existing qualifiers memory and storage, and Java’s own transient keyword with a similar meaning). Since the addressing scheme of TSTORE and TLOAD is the same as for SSTORE and SLOAD, code generation routines that exist for storage variables, can be easily generalised to also support transient storage.

Its unfortunatrlly not that easy ... but come on, I'm sure as a community we can do this!


Note: this is very early ... No where near ready ... Probably not doing things the right way ... but at least its something.
I'l try to work on that. Anyone if free to comment on this, or start another effort (based or not on this).


My analysis so far

transient is both a "Mutation" and a "Location"

  • its a mutation because you should be able to declare a variable as "transient", just like you would mark it as "constant" or "immutable"
contract Test {
    uint256 constant public A = 1;
    uint256 immutable public B;
    uint256 transient internal C;
    ///...
}

Note that this mutation applies to non-value type (struct, string, array, even mapping!)

contract Test {
    mapping(address => mapping(address => uint256)) transient internal _temporaryAllowances;
    ///...
}
  • transient is also (and mostly) a storage location. In that regard it behaves very similarly to Storage (same slot derivation and everything), but code generation needs to replace sload/sstore with tload/tstore
contract Test {
    struct MyStruct { ... };
    mapping(address => MyStruct) transient internal _temporaryDetails;
    ///...
    
    function something(...) public {
        MyStruct transient ref = _temporaryDetails[msg.sender];
        //...
    }
}

TODO

Copy link

Thank you for your contribution to the Solidity compiler! A team member will follow up shortly.

If you haven't read our contributing guidelines and our review checklist before, please do it now, this makes the reviewing process and accepting your contribution smoother.

If you have any questions or need our help, feel free to post them in the PR or talk to us directly on the #solidity-dev channel on Matrix.

@Amxx Amxx changed the title WIP:wip WIP: add support for transient storage in the solidity Mar 20, 2024
@Amxx Amxx marked this pull request as draft March 20, 2024 14:00
@Amxx Amxx force-pushed the features/transient-storage-support branch 4 times, most recently from 890cbef to 432df7f Compare March 21, 2024 20:11
@Tudmotu
Copy link

Tudmotu commented Mar 21, 2024

Great initiative!

I think it should also allow declaring function arguments as transient, e.g. someFn (uint transient num) like with storage.

@Amxx
Copy link
Author

Amxx commented Mar 21, 2024

Great initiative!

I think it should also allow declaring function arguments as transient, e.g. someFn (uint transient num) like with storage.

Yes, AFAIK

  • everywhere storage or memory is allowed, transient should also be allowed (that is the location part).
    • function args
    • function returns
    • non-value-type declaration
  • everywhere constant of immutable is allowed, transient should also be allowed (that is the mutation part)
    • that is basically state variable
    • unlike the other two, that only apply to value-type, transient should also apply to non value type (structs, arrays, mappings)

cfromknecht and others added 8 commits March 22, 2024 12:00
NOTE: This is far from being complete or usable in production.

The parser is modified to expect the "transient" keyword on
contract-level declarations, as well as local variables. Most of the
focus is spent on making the former correct, so YMMV with the latter,
espcially in regards to array/reference handling.

The CompilerContext internally separates storage variables from
transient variables and computes a StorageOffset map for each. This is
used to ensure transient and persistent storage aren't overwriting each
other in the same namespace.

Compiling the Test.sol and TestStorage.sol contracts and diffing the
bytecode results in the SLOAD/SSTORE instructions being replaced by
TLOAD/TSTORE instructions. AFAICT there are unreachable portions of the
bytecode that differ between the two, which presumably relates to the
metadata hash appended by the compiler.

There are certainly a ton of edge cases in regard to properly processing
the AST, but this should suffice for some demos.
mapping(uint256 => uint256) transient myMapping; not processed correctly
- support Transient location in ArrayType and ArrayUtils.
- support location in derivation of Mapping. (mapping might be in a
  storage struct or a transient struct)
@Amxx Amxx force-pushed the features/transient-storage-support branch from 162a193 to ba8e5e7 Compare March 23, 2024 08:02
@Amxx
Copy link
Author

Amxx commented Mar 25, 2024

WIP:

  • Current version affects the optimizer, and transient operation get removed
  • Bad resolution of mapping types
  • Public getters to transiant variables are not using tload as they should
  • Figure out the mess in YulUtilFunctions. Is everything needed/used ? What is the best way of adding transient support?

@Amxx Amxx force-pushed the features/transient-storage-support branch from 1f83e79 to 5ad7fb7 Compare March 25, 2024 15:12
Amxx added a commit to Amxx/v4-core that referenced this pull request Mar 29, 2024
Amxx added a commit to Amxx/v4-core that referenced this pull request Mar 29, 2024
@k06a
Copy link

k06a commented Apr 2, 2024

@Amxx thank you for your effort!

@mehtavishwa30
Copy link
Contributor

Hey @Amxx!

Thanks so much for putting in the time and effort in understanding the compiler and putting this PR together. We appreciate you for taking this crucial first step and helping the team gauge the community's interest for high-level language support for transient storage.

We just posted a discussion thread on our forum as our public response to recognise the current community interest and efforts around support for transient storage and share the challenges around implementation discussed with you during the previous language design call. Our post also outlines the next steps that the team will be working on to further the progress in this area. You can check out the catch-all issue to stay updated.

Cheers!

@k06a
Copy link

k06a commented Apr 16, 2024

Interesting fact, that @1inch team started using transient keyword in Solidity in Dec 2023: 1inch/solidity-utils/.../BySig.sol#L50

Can't wait to uncomment transient data location.

@nishim3
Copy link

nishim3 commented May 3, 2024

Hey @Amxx ! I would like to assist in this build. Please let me know if you need any help or have any tasks for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants