From 88ec7c9c74b677d0eee8076f016eb0c67b2eef6c Mon Sep 17 00:00:00 2001 From: Dominic Letz Date: Tue, 29 Oct 2019 17:12:31 +0100 Subject: [PATCH] Added EIP-2330: SLOAD2 and ABI --- EIPS/eip-2330.md | 81 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 EIPS/eip-2330.md diff --git a/EIPS/eip-2330.md b/EIPS/eip-2330.md new file mode 100644 index 00000000000000..fdaed7b08c6d47 --- /dev/null +++ b/EIPS/eip-2330.md @@ -0,0 +1,81 @@ +--- +eip: 2330 +title: SLOAD2 and ABI +author: Dominic Letz (@dominicletz) +discussions-to: https://ethereum-magicians.org/t/eip-2330 +status: Draft +type: Standards Track +category: Core +created: 2019-10-29 +--- + + + +## Simple Summary + +A new `SLOAD2
` EVM opcode to read external contract storage data and corresponding Solidity extensions to use this in the language and ABI. Making contracts use less gas and allowing off-chain apps to read storage data with guaranteed variable placement. + +## Abstract + +The Solidity ABI as is (https://solidity.readthedocs.io/en/develop/abi-spec.html) does not allow creating ABI specs for storage data, instead only function calls to contracts are standardized. This EIP adds an ABI for specifying storage layout of contract data and an EVM opcode to directly read external contract storage. This brings several benefits: + +* "EVM less devices" are enabled to access smart contract storage data in a meaningful way. +* Smart Contracts can directly read other contracts storage data and rely on storage addresses of named variables. +* Gas cost of calling/using registry style contracts including token contracts can be greatly reduced + +## Motivation + +1. Currently when off-chain applications want to consume data from smart contracts, they have to use the existing ABI function calls defined in the corresponding contracts. This means that these off-chain consumers must have a) a full & up-to-date EVM and b) download the contracts storage data locally to execute and fetch the result of the ABI calls -- or that these consumers **must fallback to use a centralized gateway** that can execute an ABI call for them such as with the "eth_call" RPC API. A work-around to this has been to **hard-code in off-chain clients the actual memory layout** of the compiled smart contract storage and to access variables directly, validating the storage against the merkle tree. This works with careful engineering but is very brittle since the actual memory slot position of smart contract variables can change easily when there are compiler changes, addition/removal of smart contract variables or variable re-ordering. Also this mechanism can not be expressed in a common interface such an ERC as slot calculations need to be made on a per contract basis. + +2. The gas cost when interacting with registry style contract such as ERC-20s, ENS or a membership lists is very high, because they incur cross contract call cost, cost for ABI decoding and dispatching and finally loading the data. In many cases the underlying storage that is being queried is though just a simple mapping. In these cases a new SLOAD2 call directly accessing the mapping in storage could not only **reduce the gas cost** of the interaction more than 10x, but also it would make the gas cost **predictable** for the reading contract. + +## Specification + +**Proposal** + +There are two additions to solidity and one new opcode in the EVM: + +* A new EVM instruction `SLOAD2 (0x5c)` that works like `SLOAD (0x54)` with the same gas cost but has an additional parameter representing the contract that is to be read from. + +``` +SLOAD (0x5c) +``` + +* A "fixed(@N)" solidity keyword that marks a contract storage variable as externally readable. The @N is a storage slot address and forces the compiler to put the contract variable at the specified slot N. The data position is thus becoming part of the interface. + +* Syntax addition for solidity exposing the new SLOAD2 function and allowing to access storage of an external contracts when the "fixed(@N)" keyword has been used. + +**Example** + +An Example interface using a public fixed mapping: + +```solidity +interface MemberList { + public fixed(@5) mapping(address => bool) members; +} +``` + +And a corresponding contract function that uses this member list. Similarly tokens or other registries could be implemented. + +```solidity +function membersOnly(address list, address member) { + MemberList ml = MemberList(list); + if (ml.members[client] == false) revert("Nonmember!"); +} +``` + +The call `ml.members[client]` here should let the Solidity compiler generate the normal map access logic but using the `SLOAD2
` instructions to read from the `ml` contract storage instead of the local contract storage. + +## Backwards Compatibility +This change is fully backwards compatible since it only adds a new feature. + +## Test Cases + +Not started yet. + +## Implementation + +Not started yet. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).