Add draft for ESO (extended state oracle) (#2014)

* Add draft for ESO (extended state oracle)

* Add mention of revert to ESO

* Add EIP-2014 number and rename file

* Add reference to EIP-1959 and EIP-1965

* Add discussions-to URL

EIPS/eip-2014.md

@@ -0,0 +1,94 @@
+---
+eip: 2014
+title: Extended State Oracle
+author: Alex Beregszaszi (@axic)
+discussions-to: https://ethereum-magicians.org/t/eip-2014-extended-state-oracle/3301
+status: Draft
+type: Standards Track
+category: Core
+created: 2019-05-10
+requires: 140
+---
+
+## 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.-->
+
+## Abstract
+
+Introduce a new system contract with an extensible interface following the [Contract ABI Encoding] to access extended data sets, such as chain identifiers, block hashes, etc.
+
+This allows Ethereum contract languages to interact with this contract as if it were a regular contract and not needing any language support.
+
+## Motivation
+
+Over the past couple of years several proposals were made to extend the EVM with more data. Some examples include extended access to block hashes ([EIP-210]) and chain identifiers ([EIP-1344]).
+
+Adding them as EVM opcodes seems to be using the scarce opcode space for relatively less frequently used features, while adding them as precompiles is perceived as more complicated due to an interface
+needs to be defined and agreed on for every case.
+
+This proposal tries to solve both issues with defining an extensible standard interface.
+
+## Specification
+
+A new system contract ("precompile") is introduced at address `0x0000000000000000000000000000000000000009` called ESO (Extended State Oracle).
+
+It can be queried using `CALL` or `STATICCALL` and follows the [Contract ABI Encoding] for the inputs and outputs. Using elementary types in the ABI encoding is encouraged to keep complexity low.
+
+In the future it could be possible to extend ESO to have a state and accept transactions from a system address to store the passed data -- similarly to what [EIP-210] proposed.
+
+Proposals wanting to introduce more data to the state, which is not part of blocks or transactions, should aim to extend the ESO.
+
+At this time it is not proposed to make the ESO into a contract existing in the state, but to include it as a precompile and leave the implementation details to the client.
+In the future if it is sufficiently extended and a need arises to have a state, it would make sense to move it from being a precompile and have actual code.
+
+### Chain identifier
+
+Initially, a feature to read the current chain identifier is introduced: `getCurrentChainId()` returns the current chain identifier as a `uint64` encoded value.
+It should be a non-payable function, which means sending any value would revert the transaction as described in [EIP-140].
+This has been proposed as [EIP-1344].
+
+The contract ABI JSON is the following:
+```json
+[
+    {
+	"constant": true,
+	"inputs": [],
+	"name": "getCurrentChainId",
+	"outputs": [
+	    {
+		"name": "",
+		"type": "uint64"
+	    }
+	],
+	"payable": false,
+	"stateMutability": "pure",
+	"type": "function"
+    }
+]
+```
+
+This will be translated into sending the bytes `5cf0e8a4` to the ESO and returning the bytes `0000000000000000000000000000000000000000000000000000000000000001` for Ethereum mainnet.
+
+**Note:** It should be possible to introduce another interface checking the validity of a chain identifier in the chain history or for a given block (see [EIP-1959] and [EIP-1965]).
+
+## Rationale
+<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+## Backwards Compatibility
+<!--All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.-->
+
+## 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.-->
+
+## 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.-->
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+[Contract ABI Encoding]: https://solidity.readthedocs.io/en/latest/abi-spec.html
+[EIP-140]: https://eips.ethereum.org/EIPS/eip-140
+[EIP-210]: https://eips.ethereum.org/EIPS/eip-210
+[EIP-1344]: https://eips.ethereum.org/EIPS/eip-1344
+[EIP-1959]: https://github.com/ethereum/EIPs/pull/1959
+[EIP-1965]: https://github.com/ethereum/EIPs/pull/1965