High-Level Language Support for Transient Storage

[ekpyron]

Comprehensive high-level language support for transient storage decomposes into the following tasks:

Tasks

Beta Give feedback

1. transient is not a keyword, so we need a parser hack to introduce it non-breakingly as a first step: Transient storage parser support: accept transient as a data location or as an identifier #15006
2. Support for value types in transient storage.
3. Support for auxiliary compiler output artifacts like a transient storage layout, etc.
4. Support for reference types (structs, arrays) in transient storage; no copies between data locations.
5. Iterative support of copying.
6. Independently of reference types: support for mapping in transient storage.

Starting from the second step each step decomposes into a Yul and legacy part. We currently plan to start with Yul implementations and to merely backport functionality to legacy on demand.

Questions to be settled during the process:

• Layout of transient storage variables.
  • current proposal: storage and transient storage have independent layouts (both starting at zero and overlapping), otherwise the layout (including packing) is the same between transient storage and storage.
• Autoclearing, no autoclearing, optional autoclearing.
  • So far we assume that despite the connected dangers unconditional compiler-generated autoclearing is not expected and also not possible for all types. If we were to decide for opt-in or opt-out autoclearing behaviour, we would need to decide syntax for it. We're open to community input on the question.
  • Given the design of transient storage there is unfortunately no optimal choice here; current tendency is to expose the bare EVM functionality directly in the first instance; only consider optional opt-in autoclearing separately.