主页EIPs周刊
EIPsEIP-2014
EIP-2014

Extended State Oracle

StagnantStandards Track: Core
创建时间: 2019-05-10
关联 EIP: EIP-140
Alex Beregszaszi (@axic)
社区讨论原文链接编辑
1 分钟了解
欢迎补充好内容
去提交
相关视频
欢迎补充好内容
去提交
正文

Simple Summary

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:

[ { "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

TBA

Backwards Compatibility

TBA

Test Cases

TBA

Implementation

TBA

Copyright and related rights waived via CC0.

扩展阅读
欢迎补充好内容
去提交
相关项目
欢迎补充好内容
去提交

不想错过最新的 EIP 动态?

订阅 EIPs Fun 周刊以跟进相关更新,建⽴你与 EIP 之间的连接 ,更好地建设以太坊。

详情
支持以太坊贡献者,推动生态建设
资源
GitHub
支持社区