Transient storage, a transient trend?

Transcript

one two hi I'm Valerian Kal I work at qu stamp and today I will answer this question is transan storage a transient Trend this is the plan for today uh so let's start the story of transan storage or t storage started 6 years ago with EIP 1153 it was then introduced to the evm with the Denon upgrade earlier this year and as of today you can use it in Viper and solidity using op codes or the dedicated keyword transient it's cheaper than persistent

storage each slot is identified by a bite 32 identifier and you can keep in mind that it has two Scopes first scope it's at the level of the contract because only the contract can access its own Tran storage and you need a dedicated view function to make it accessible to other contracts second scope is the level of the transaction because trans storage only exists until the end of the transaction and at the end of the transaction it is set back to zero about the use cases the EIP initially suggested six use cases including transient reentrance guards

tokens with persistent balances but transient approvals and tokens where you can pay a fee to unlock the token transfers until the end of the transactions but what about the usage in practice so you can search for this on GitHub and browse the results you will see that most of the results are clients or Dev tools trying to support the Denon upgrade and you will also see that actors such as uniswap V4 or balanc Serv V3 are using it for um flash accounting and I listed other use cases below as an adoption summary most of the

project start using it with transient reentrance guards then the there is a common pattern for more complex use cases where you use transion context transion context it's a set of transient storage variables that are used together in a consistent way most of the code bases also use um dedicated libraries to manage their transient slots uh and here is oie transient slot Doo Library as an example and the adoption has been postponed in some cases for instance in one case um the code base the rest of the code base was

not ready for the solidity compiler version 0824 let's move on to the security considerations first when you want to check if in a function the CI pattern is enforced consider the persistent storage but also the trans storage the second one is when you target an evm Network make sure that the trans storage is fully and correctly implemented and for this the tool evm D diff is very useful then Beware of the concurrency between different slots especially when you mix uh inent and

delegate calls because you can have some slot collisions or storage slot uh shifts the last consideration is for the concurrent see on the same slot and here you can think about scenarios involving account abstraction multi multic calls and basically it's if the same transon slot can be used by multiple use cases or for multiple actors then there is a risk of unexpected Behavior or of denial of service let's move on to the design patterns the first one is transient readon reur guards so sometimes by Design you cannot avoid to expose some

areas of your of your code to read only rances and this pattern consists in temporarily looking um related view functions before and after an arraya so in this example this contract has a storage variable a a view function get a and a function that is exposed to read onlyy I use the arrow to delimitate um the start and the end of this sensitive area uh for this um pattern you give an ID to the view function here 42 you use a modifier and um in the at the start of

the exposed reeny area you will lock the view function uh with a dedicated function and you will unlock it at the end of the area the second one I think is the most important is to safely manage the life cycle of your transient context so the rule number one is use single purpose slots in other words make sure that the same slot is not used for separate um use cases and the second one is to avoid parallel executions for concurrent actors on the same slots and here is a suggestion with a code if you have a transon context TC

and Ador Bob uh first make sure that the transon context is not already locked or inuse then you lock it for Bob you sanitize all the slots of the trans context you initialize it then the context is active and ready to be used but only for Bob when you finish you clear the slots and you unlock it from Bob and the last uh pattern I will present you today is trans transaction level counters so with this you are able to make sure that a function Can U cannot be called more than uh n times per transactions or M times per

transaction per user or any more complex Logic the advantages is that it's cheaper than using persistent storage and also it can prevent some ta for instance if a mean function uh is used in the same transaction that um redeem function in a repeated amount of time but it has also some disadvantages because it can limit or even break the composability of your protocol in that transaction think about account abstraction and once again thinking about account abstraction maybe some transaction batchers could abuse

the system them and create a denial of service in the advantage and this is the answer to the question so no we are not is a trans storage is not a transient Trend it's we are in a healthy early adoption phase and transion storage is here to stay it's well documented useful supported by most of the networks and de tools uh the main Builders are already using it and the security knowledge uh exists but still has room for improvement I added some resources if

you want to learn more about this topic and that's it for today thank you