Added EIP-2330: SLOAD2 and ABI

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
+---
+
+<!--You can leave these HTML comments in your merged EIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
+A new `SLOAD2 <address> <slot>` 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
+<!--A short (~200 word) description of the technical issue being addressed.-->
+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
+<!--The motivation is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. EIP submissions without sufficient motivation may be rejected outright.-->
+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
+<!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).-->
+**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 <address> <slot>` 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
+<!--Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.-->
+Not started yet.
+
+## Implementation
+<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
+Not started yet.
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).