Moved EIP 2481 to last call

[cburgdorf]

I was asked to move this EIP to "Last Call" to draw attention to the EIP with the intention to move it to final in two weeks.

I'm a bit out of touch with the issue at hand (because I have changed roles and am currently no longer active in client development. For the curious, I'm working on ethereum/fe now)

I did a quick check on the latest development on the issue and my impression is that:

1. All client teams are on board to implement this

2. Most are waiting on Geth to move first

3. @karalabe from Geth said they would implement it before the Berlin fork (Citing from discord)

Option A: We roll out 66 (request id), 67 (typed tx in blocks, tx-announce etc)

• Drawback: Everyone must implement 65 (tx hashes), 66 and 67 before Berlin. - The entire network can drop support for eth<67 after the hard fork passes.

Option B: We allow typed transactions in earlier eth protocol versions. BUT - Geth will implement 66 (request id), before Berlin. So after Berlin, all Geth nodes on the network will guaranteed speak eth/66.

• Geth will drop eth/63 this year, eth/64 by spring 2021 and eth/65 by summer 2021
  Either way, Geth will drop support for anything but the latest eth protocol by next year summer.

Given that, I'm moving this forward to "Last Call" under the impression that this would be in everyone's interest.

[MicahZoltu]

Consider moving this to Review instead of Last Call? Review is a new status and generally comes after Draft, and before Last Call. It indicates that the author doesn't believe any additional normative changes are necessary and wants third parties to start looking at the EIP and possibly authoring test implementations.

Last Call on the other hand indicates that the author is fairly confident there will be no more normative changes ever, and for Core/Networking EIPs that usually means there are one or more implementations out there in multiple clients which indicates there aren't any hidden gotchas.

[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 2481 state from Draft to Review
• EIP 2481 requires approval from one of (christoph@ethereum.org)

[cburgdorf]

@MicahZoltu Sounds good to me. Changed it to Review.

[MicahZoltu]

Before I merge this, @cburgdorf do you plan on championing (actively maintaining/pursuing) this EIP as it gets implemented by clients? If not, we probably should get another author added before moving it to review. If you are planning on actively moving this forward, I can merge as is.

[cburgdorf]

do you plan on championing (actively maintaining/pursuing) this EIP as it gets implemented by clients?

My impression is that not much championing will be needed for this EIP to get implemented by the clients as the change is pretty straight forward all clients teams seem on board with it. That said, since I'm not actively involved in client development atm I wouldn't mind another author (with a stronger intrinsic motivation for moving this forward) to be added.

Who would be better suited than @karalabe himself? 😄

[MicahZoltu]

My impression is that not much championing will be needed for this EIP to get implemented by the clients as the change is pretty straight forward all clients teams seem on board with it.

In my experience, once people start actually implementing an EIP is when you start receiving the most feedback on it and sometimes this leads to the biggest changes. Because of this, it would be nice if there was an author that was actively invested in the EIP's success available to make adjustments, changes, engage in discussion, coordinate between developers, etc. while this was happening. I have seen many EIPs that end up failing to reach final because the author simply isn't around to iterate with people who want to use it.

I have also seen EIPs get pushed to final before they are implemented by anyone and then someone has to go create a new EIP that is almost identical because the first one got pushed to final too quickly.

Note: You don't have to be a client developer to be a champion. You just have to be responsive to questions and quick to iterate when needed. 😄

[cburgdorf]

Fair enough. I also want to make clear that I'm not trying to back down from the EIP. I think it is well under way. By the way Trinity has had an implementation ready to go live (but ultimately waiting for others to also adopt it) since April this year. I will continue to answer questions regarding this EIP if they come up. I just might not be the most active to vocally push for it at the moment. But luckily there has been quite a lot discussion around this EIP in the ACD chat recently (just like 4 weeks ago) and there seems to be broad consensus to implement it from client teams and the discussion wrapped up with Peter concluding the decision of the Geth team to implement this before the Berlin fork.

You just have to be responsive to questions and quick to iterate when needed.

Yes, I can commit to that 👍