EIP-1344: Move to Final after Last Call Review

[fubuloubu]

• One additional reviewer added comment
• No technical updates suggested

Moving to Final, with inclusion into Istanbul determined by EIP-1679, with discussion here.

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• Trying to change EIP 1344 state from Last Call to Final

[axic]

Oh btw, once this is merged, you won't be able to automerge changes to it.

[fubuloubu]

Gotcha. Well, no one has asked for any changes to it in over a month. People just question whether they want it at all, so it's basically all or nothing at this point.

The most I'll change is to link to implementations and testing.

[axic]

I think some of the rationale you have written on #2014 and on FEM are not represented in the EIP yet.

[fubuloubu]

Three things I see missing:

• This proposal is the most flexible of the 3 (4? 5?) proposed, allowing developers to make their own decision for how a change in chain ID should be handled.
• Link to my trustless oracle contract implementation.
• Discussion of the Plasma use case, where it makes more sense for the user to handle it themselves to synchronize with the Plasma block submission process instead of using a global oracle.

Will add

[fubuloubu]

Added: #2079

[axic]

@nicksavers @Arachnid ready to merge (given #2196 documents the state transitions we have)?

[Arachnid]

We've been trying to remove any connection between EIP status and presence in a hard fork. After last call, EIPs move to Final, not to Accepted. To get to Final, the author needs to list any objections that were raised during last call and how they were addressed.

If the core devs decide to implement it, they add it to the relevant fork meta EIP.

[fubuloubu]

@Arachnid I don't see this reflected in EIP-1 yet, is there a change coming that explains the update?

Also, what section would "Last Call Updates" be listed under?

[Arachnid]

What do you mean by "what section would last call updates be listed under"?

[fubuloubu]

To get to Final, the author needs to list any objections that were raised during last call and how they were addressed.

This sentence.

[Arachnid]

That's the requirement. I don't understand what you're asking, though. Section of what?

[fubuloubu]

Where does the "list of any objections that were raised" get recorded?

[Arachnid]

It doesn't get recorded, except insofar as Github PR comments are persistent. But the author needs to show justification that the requirements for moving to last call were met, and the PR requesting the change is a sensible place to do that.

[fubuloubu]

Outside of the comments on this PR, there was nothing actionable besides adding some additional detail to the "Rationale" section to make key considerations for users of this opcode more apparent (which was resolved in #2079).

Discussions from the latest ACD call and the gitter chat mostly resolved around implementation decisions for this particular opcode, which I believe are out of scope of this proposal?

---

Edit: I provided an implementation in the proposal, but the consensus seems to be to try and handle it in a different way, which will be reflected in the client code if accepted for Istanbul.

[fubuloubu]

Full change summary of this proposal after Move to Last Call:

• EIP-1344: add dependency on EIP-155 #2004 - Added dependency on EIP-155
• EIP-1344: Rational adjustment for local handling #2079 - Rationale adjustment about handling chain ID changes
• Updated EIP-1344 Implementation notes #2215 - Added implementation notes and link to sample implementation (currently WIP)
• EIP-1344: Add datatype to opcode return value #2216 - Added datatype uint256 to opcode return value

[Arachnid]

As I said earlier - we're no longer using 'accepted' to track hard fork state, and that would in any case require all core devs approval. The next state after 'last call' is 'final' - feel free to edit this PR to that instead.

[fulldecent]

I raised numerous arguments during last call and I believe [the summary above] #1994 (comment) accurately addresses every technical issue I have seen and they provide clarifications to the specification without doing anything that counts as a material change.

Good to merge, after switch from ACCEPTED to FINAL.

[fubuloubu]

@Arachnid this was discussed/approved on ACD for implementation into Istanbul, so should this standard wait to push to Final until after implementation into Istanbul? Or is that status now decoupled from client implementation in a process simplification?

[Arachnid]

@fubuloubu In theory, nothing can be in a fork unless it's final. In practice, we're not handling things nearly that cleanly.