EIP-2014: Extended State Oracle

EIPs EIPs core
1

Discussion board for

2

Some interesting comments from @fubuloubu were made on the PR

3

I wanted to explain this a bit more. Initially this started out as defining a standard extensible API for data, such as chain id.

Then I also wrote up a draft, which includes EIP-210 (blockhash) support in it, but never pushed that change.

Currently I am considering changing it into a meta EIP describing the guidelines how data contracts (such as chainid history – however @fubuloubu has a nice proposal for that, blockhash, logs, etc.) could work.

4

I do think you should leave the chain ID example out of this. As has been pointed out in one of the chain ID EIPs, returning a simple chain ID isn’t enough, since for mainnet-derived chains, multiple chain IDs have been valid at different points in the past. To avoid this EIP getting bogged down in discussions about the correct interface for checking chain ID, it probably makes more sense to leave this to other EIPs.

A few other thoughts:

  • “Non payable” is a Solidity level concept. Instead, you should spell out the consequences, such as that it should revert if value is sent with the call.
  • All existing precompiles can have value sent to them. Requiring that this one can’t may impose implementation complexities for clients.
  • You need to say something about gas costs for the precompile (even if it’s just that each extension sets its own gas costs).
  • You need to specify what happens if it’s called with a nonexistent function ID, or with too little data.
  • Unused sections should be marked with a todo or deleted, probably.
2 Likes
5

Good points @Arachnid. To add to that :

  • If a user sends 4byte 5cf0e8a4 and also data, should it fail or ignore?

Also, the points listed could be moved into the tests-section as suggested tests.
I do, however, think it’s good to include chainid into this EIP, instead of splitting it out into separate EIPs. It helps to keep things simple.

6

Chain ID has proven far from being simple. There’s a lot of complexity tied up in how this little uint256 number is used and what it means, as well as under what conditions it is modified.

I’m comfortable if it just returns the current value, as that’s basically just EIP-1344, but if it has to account for all the complex behavior that can arise from accounting for when the number changes in other calls (such as EIP-1959 and EIP-1965 try and account for), I would not include it into this proposal.

But if nothing else related is included, then this proposal is essentially just EIP-1344 with stubs for “other” stuff, which has not been defined yet. That alongside the fact that calls cost extra gas and chainId isn’t really a part of the “extended state” (EIP-1344 lifts it from the transaction context) makes me want to recommend differing on this EIP.

It’s complicated enough by itself, all these more complicated proposals for behavior we largely have no historical record for makes me nervous. On top of that, this is going to be a widely-used feature (alongside EIP-712), I want getting chainId to be as simple and flexible as possible.