Transient storage opcodes (#1153)

* Create eip-transient_storage.md

* Update eip-transient_storage.md

* Update eip-transient_storage.md

* Update eip-transient_storage.md

* Update eip-transient_storage.md

* Update eip-transient_storage.md

* Update eip-transient_storage.md

* Update and rename eip-transient_storage.md to eip-1153.md

* Add missing colon

EIPS/eip-1153.md

@@ -0,0 +1,75 @@
+---
+eip: 1153 
+title: Transient storage opcodes
+author: Alexey Akhunov (@AlexeyAkhunov)
+discussions-to: https://ethereum-magicians.org/t/eip-transient-storage-opcodes/553
+status: Draft
+type: Standards Track
+category: Core
+created: 2018-06-15
+---
+
+## Simple Summary
+Support for efficient transient storage in EVM. It is like regular storage (SLOAD/SSTORE), but with the lifetime limited to one Ethereum transaction.
+Notable use case is efficient reentrancy lock.
+
+## Abstract
+This proposal introduces transient storage, which behaves similar to storage,
+but the updates will only persist within one Ethereum transaction. Transient storage is accessible to smart contracts via new opcodes: TLOAD and TSTORE (“T” stands for Transient).
+
+## Motivation
+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 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.
+
+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”). Since 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.
+
+Potential use cases unlocked by this EIP include:
+1. Reentrancy lock
+2. Passing error codes and messages from the execution frames up the execution stack
+3. More generic libraries that use callbacks, for example generalised sorting with functions `Less` and `Swap` defined.
+4. Shared memory (borrowed from early draft of similar EIP by @holiman). When implementing contract-proxies using `DELEGATECALL`, all direct arguments are relayed from the caller to the callee via the `CALLDATA`, leaving no room for meta-data between the proxy and the proxee. Also, the proxy must be careful about `storage` access to avoid collision with `target` `storage`-slots. Since `transient storage` would be shared, it would be possible to use `transient storage` to pass information between the `proxy` and the `target`.  
+
+## Specification
+Two new opcodes are added to EVM, `TLOAD` and `TSTORE`.
+
+They use the same arguments on stack as `SLOAD` and `SSTORE`.
+
+`TLOAD` pops one 32-byte word from the top of the stack, treats this value as the address, fetches 32-byte word from the transient storage at that address, and pops the value on top of the stack.
+
+`TSTORE` pops two 32-byte words from the top of the stack. The word on the top is the address, and the next is the value. TSTORE saves the value at the given address in the transient storage.
+
+Addressing is the same as `SLOAD` and `SSTORE`. i.e. each 32-byte address points to a unique 32-byte word.
+
+Gas cost for both is 8 units of gas, regardless of values stored.
+
+The effects of transient storage are discarded at the end of the transaction.
+
+Transient storage is private to the contract that owns it, in the same way as "regular" storage is. Only owning contract frames may access their transient storage. And when they do, all the frames access the same transient store, in the same way as "regular" storage, but unlike "memory".
+
+When transient storage is used in the context of `DELEGATECALL` or `CALLCODE`, then the owning contract of the transient storage is the contract that issued `DELEGATECALL` or `CALLCODE` instruction (the caller). When transient storage is used in the context of `CALL` or `STATICCALL`, then the owning contract of the transient storage is the contract that is the target of the `CALL` or `STATICCALL` instruction (the callee).
+
+Transient storage does not interact with reverts or invalid transactions, that means if a frame reverts, its effects on the transient storage remain until the end of the transaction.
+
+## Rationale
+There is a proposal to alleviate the cost of inter-frame communication by reducing the cost of `SSTORE` when it modifies the same item multiple times within the same transaction (EIP-1087).
+
+Relative cons of the transient storage: new opcodes; new code in the clients; new concept for the yellow paper (more to update); requires separation of concerns (persistence and inter-frame communication) when programming.
+
+Relative pros of the transient storage:  cheaper to use; does not change the semantics of the existing operations; very simple gas accounting rules;
+
+## Backwards Compatibility
+This EIP requires a hard fork to implement.
+
+Since this EIP does not change semantics of any existing opcodes, it does not pose risk of backwards incompatibility for existing deployed contracts.
+
+## Test Cases
+TBD
+
+## Implementation
+Most straightforward implementation would be a dictionary (map), similar to what exists for the ‘dirty’ storage, with the difference that it gets re-initialised at the start of each transaction, and does not get persisted.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).