EIPIP Meeting 13 Agenda

[poojaranjan]

Date and Time

Wednesday, July 29, 2020, at 15:00 UTC

Location

Zoom: The link will be shared in the telegram group.
YouTube Live Stream/Recording - https://youtu.be/8dxGtomafP4

Agenda

1. Network upgrade process

2. Onboarding EIP editors

• survey to set expectations of an EIP Editor
• triaging permission

3. New EIP validator and a suggestion to handle current validator

4. Standard citation format to the footer of all EIPs

5. Constraining the EIP repository scope

6. Discussion on Muir Glacier postmortem report PR-2809 and Network upgrade postmortem template PR-2810

7. Explore the idea of working groups

8. Clarifications for how a precompile address is decided.

9. Discuss the EIP-1 Brainstorming Document

• Goals Outcomes
• What we are not doing.
• EIPs TODO

10. Review action items from previous meeting

Next Call - Aug 12, 2020.

[MicahZoltu]

Agenda Item: Does anyone oppose adding this standard citation format to the footer of all EIPs?
ethereum/EIPs#2738

[poojaranjan]

Agenda Item: Does anyone oppose adding this standard citation format to the footer of all EIPs?
ethereum/EIPs#2738

Added to the agenda!

[MicahZoltu]

I would like to propose that there is a discussion about constraining the EIP repository scope. @poojaranjan just pointed out to me elsewhere that a recent EIPIP meeting resulted in the recommendation to use the EIPs repository as a storage vault for mainnet operations retrospectives, but to me that feels like pretty big scope creep, and somewhat contrary to the idea of getting Ethereum mainnet stuff out of the EIPs repository (like the hardfork meta EIP).

I would like to see this repository be just standards, and anything else can live somewhere else. EIP editors are all volunteer and already way overstretched with work. I think we should be looking into how we can cut scope, not add scope. An example of how we can cut scope would be to extract ERCs into a separate repository and get hardfork consensus process out of this repository.

[lightclient]

I've spent some time reflecting on the discussion last meeting regarding the separation of the EIP process and the network upgrade process. I understand and agree with the desire to separate the two processes. I believe that the network upgrade consensus process requires different parties and must address different concerns than the finalization of specs. However, I disagree that the EIPs repository should not acknowledge the importance of an EIP landing on mainnet. It is valuable to look at an EIP and quickly determine if it is the current state-of-the-art (on mainnet). There is no reason to not mark mainnet EIPs as "state-of-the-art". If the network upgrade process is truly separate, then it is simply a bookkeeping task that the author / editors must undertake to update the metadata. With better tooling, it can even be automated. I urge us to take another look at the statuses and decide upon a name for a new status that denotes an EIP has been deployed to mainnet.

--

On another note, there are a lot of other aspects of the EIP process that can be improved. However, I believe that many of those will dissipate if we address the lack of ownership that currently exists in the process. While our protocol must be tustless and resistant to censorship, the default avenue in our standardization process does not necessarily need to embody those principles. Without any ownership in the process, there is little desire to improve it. It becomes a tragedy of the commons.

I would like us to explore the idea of working groups. Essentially all standardization organizations have them--Ethereum shouldn't be special in this regard. We already have them informally. We should acknowledge them explicitly and give them ownership of their track (again, this is separate from network upgrade coordination). Editors can focus on generic EIP requirements and act as custodians of the repository, while working groups should help direct resources and ideas towards existing efforts. Working groups shouldn't be gatekeepers. They should have high level goals and help elevate new ideas and participants which align with their goals by connecting them to resources which can help them accomplish their goals. A quick sketch of a few working groups I envision:

What	Who	Goals
Meta	This group + editors	Maintain EIP-1, facilitate work group processes, maintain and develop tools to improve the EIP process
EVM	EVM devs	Improve the EVM and study the effect of changes to it
Clients	Core devs	Improve client design and development, reduce resources needed to operate clients
Networking	devp2p devs	Improve the networking infrastructure of the Etheruem network
ERC	Authors of existing ERCs, defi folks	Design token standards and maintain interoperability across various standards
RPC	web3 library maintainers / dapp devs	Improve the interface between application developers and clients
Eth 1.x	The eth 1.x group	Research and propose the optimal path to transitioning eth1 to a more stateless network
Eth 2.0	The eth 2 research + client teams	Design and develop the Ethereum 2.0 protocol, propose and review changes needed in the eth1 protocol
...	...	and more

I believe that establishing working groups will not only help relieve some of the duties of EIP editors, it will improve the quality of EIPs in the repository and increase the velocity of ideation and collaboration. If others believe that this would be valuable step to make, I would be happy to flesh it out more and shepherd its adoption.

[MicahZoltu]

However, I disagree that the EIPs repository should not acknowledge the importance of an EIP landing on mainnet. It is valuable to look at an EIP and quickly determine if it is the current state-of-the-art (on mainnet).

To be clear, I think documenting mainnet operations and what is state-of-the-art on Ethereum mainnet is incredibly important. I only disagree that such things should live in the EIPs repository.

I suspect this difference of opinion stems from a difference in belief in what the purpose of EIPs are. If you believe that EIPs are specifically related to the chain known as Ethereum, then your stance has much more strength. If you believe that EIPs are a place to standardize things which may be used on Ethereum, but may also be used on Ethereum Classic, or any other of the Ethereum-like chains then I think my stance is strengthened.

I'm in the camp that the purpose of the EIPs repository should be to standardize things that make sense on any Ethereum-like chain, which includes Ethereum 1.x, Ethereum Classic, Ethereum 2.x, etc. and this means that sometimes stuff will be final without ever making it to Ethereum mainnet, but that doesn't mean it isn't state of the art.

Another thing to keep in mind is that eventually Ethereum 1.x will diverge from Ethereum 2 and so "state of the art" will become pretty fuzzy even for Ethereum mainnet since there will, effectively, be two Ethereum mainnets.

[lightclient]

I suspect this difference of opinion stems from a difference in belief in what the purpose of EIPs are. If you believe that EIPs are specifically related to the chain known as Ethereum, then your stance has much more strength. If you believe that EIPs are a place to standardize things which may be used on Ethereum, but may also be used on Ethereum Classic, or any other of the Ethereum-like chains then I think my stance is strengthened.

I think you stated the differences well. Hopefully from my original post my stance is clear -- I believe the EIPs repo should be a place for Ethereum standards.

Another thing to keep in mind is that eventually Ethereum 1.x will diverge from Ethereum 2 and so "state of the art" will become pretty fuzzy even for Ethereum mainnet since there will, effectively, be two Ethereum mainnets.

Although this is true in the shorter term, there will eventually be a consolidation and there will be only one Ethereum mainnet. I don't think we should overcomplicate things in the interim. Therefore, I continue to believe that the EIPs repo should be solely focused on Ethereum.

[edsonayllon]

@poojaranjan Can we move talking about the Network Upgrade process first? I think it's a priority, more than the other tasks. I'd like to get the process spec'd out and finished soon, before tackling onboarding and EIP document format.

[edsonayllon]

If possible, I'd prefer we kept items like:

• Working groups
• Onboarding editors
• EIP sections

in the project board until the decision-making process is finalized.

[edsonayllon]

I'd also like to propose a process we can use to create solutions for the Network Upgrade spec.

[alita-moore]

Agenda item: Transform the current EIP-1 standards to a table format. This is based off of Edson's link to the javascript process https://tc39.es/process-document/

[alita-moore]

generally speaking, working groups are outside of the scope of the EIPIP group. It'd be a good topic to discuss ECH project submissions (e.g. forming a framework for working groups); I think ECH would need more funding to give another group the focus, organization, and documentation it deserves, though.

[poojaranjan]

@poojaranjan Can we move talking about the Network Upgrade process first? I think it's a priority, more than the other tasks. I'd like to get the process spec'd out and finished soon, before tackling onboarding and EIP document format.

Rearranged the agenda. However, the group is free to shuffle items as per the availability of the proposer and agreement on the topic to be discussed during the meeting hour.

[poojaranjan]

Closing in favor of #26