Profile picture
, 25 tweets, 5 min read Read on Twitter
1/ Ok I think I sort of get it now. Thanks @nicksdjohnson for bearing with me. A longish thread. #eipsarentgovernance #eipsaretechnicalstandards
2/ EIPs are not “change requests.” They may born out of the desire to promote a change or implement a feature, but they are actually a proposal to standardize “something” in Ethereum. A process, a property, a feature, or a class of changes.
3/ Just like ERC-20 is a token standard, EIP-XXX is an Ethereum protocol standard. The EIP process is a technical standardization process. We call the EIPs the are subject to this process “Standard Track EIPs.”
4/ The EIP process is supposed to be a purely technical process. Consider it a technical review of the proposed standard for soundness and viability. There is no capacity or capability for handling things like politics or measuring social contention.
5/ EIPs are championed and moved through the stages of technical review from Draft to Last Call to Accepted (core EIPs only) to Final. For Core EIPs, the EIP process technically stops at “Accepted.”
6/ Core EIPs are not “Final” until the standard has been adopted/implemented by 3 clients. This decision to implement is left to the client teams. Often they use the All Core Devs call as a coordination tool to measure consensus to implement with other client devs.
7/ The All Core Devs call is simply a coordination call for a) core devs to coordinate EIP selection for the next scheduled fork and set schedules, b) client devs to obtain feedback and gauge whether other clients are implementing an Accepted EIP or not.
8/ c) discuss other EIPs as time permits that are still in technical review for identified issues or risks, d) discuss other potential features additions or changes that they wish to pursue or think should be potentially standardizer by an EIP.
9/ Again this call is strictly a coordination call, working to achieve rough consensus on what EIPs will be going into an upcoming fork based on what clients have chosen to implement or not implement.
10/ The consensus for what EIPs are going into a HF is not binding. Client devs can release a version with whatever EIPs they choose, it’s their prerogative.
11/ However, since client devs are generally non-adversarial and wish to avoid contentious split scenarios that do not benefit anyone’s interests, it gives them a forum to voice objections of any kind, to inform other clients that moving forward is likely to result in a split.
12/ Generally clients will respect the objection and the EIP will not be included in the upcoming fork release, unless there are some irreconcilable differences, and a split is necessary from the clients’ point of view.
13/ So where does the community come in? The sentiment, the signaling, the politics? If the EIP process is strictly a technical review, and the All Core Devs is simply a coordination call, where id the broader community heard out?
14/ Currently there’s no formal forum centralizing the politicsl debates, discussions over general merit and impact to stakeholder groups, social coordination, or community consensus polling and gaugong. Which isn’t great.
15/ It puts the burden on client devs to stay plugged into all of these scattered forums to gauge sentiment and community consensus themselves, to the best of their ability.
16/ Since there is no forum or format for these discussions, it feels a lot like mobs of people shouting at each other, especially over EIPs the community perceives as political.
17/ Because of the burden placed on client devs to gather non-technical sentiment, the partisan arguments inevitably spill into the All Core Devs call when the teams are trying to coordinate with eachother and understand whether clients support or oppose implementation.
18/ This then causes a cascading breakdown of the All Core Devs call as other core devs, being human, interject with their perspectives, beliefs, or opinions, until the coordination effort turns into a debate over the seemingly controversial EIPs.
19/ Since the EIP process is supposed to be apolitical, and All Core Devs calls are supposed to be scoped to client coordination and technical discussions, some core devs get frustrated over the scope infringement, and additional responsibility imposed on them.
20/ They have good reason to be. It makes decisions to move forward with EIP selections and fork coordination impossible, as conversations are dominated by the controversial EIP and inescapable political debates, which they did not sign up to moderate or accept liability for.
21/ There is a lacking component needed to facilitate such political debates, social coordination, and community consensus gauging to keep this stuff from finding its way into the EIP standardization process, or the All Core Devs coordination calls.
22/ Some kind complementary track or forum to manage all of the social and political baggage some EIPs carry with them. To colllect and present signals and measure non-technical consensus...
23/ But most importantly, to provide client devs with a place where they can see & discuss contentiousness and non-technical consensus, external to the All Core Devs meetings. To provide them with all the information beyond technical soundness they need to make informed decisions
24/ They can then marry that up to the technical review and come to a decision on whether to implement, before adding it to the agenda for the All Core Devs meeting for fork coordination.
25/ I think this is necessary to Make the EIP process Technical Again (#META ?), and help maintain some level of sanity and separation for the core devs who didnt sign up for this and arent paid enough to burden them with more responsibility when controversy accompanies an EIP.
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Andrew
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!