--- tags: acd, nyota --- # Nyota ACD & Network Upgrade Breakout ## Pre-Session pol.is Prior to the session Thursday, please respond to this poll: https://pol.is/7rnaxthkev Feel free to also suggest additional questions. On Thursday AM, I'll analyze the responses and we'll spend the session discussing the results. This is meant as a conversation starter for the session more than anything: in other words, don't see this as a list of formal proposals we should agree on, but rather an overview of the design space so we can map clusters of alignment/disagreement. If you aren't familiar with pol.is, I suggest reviewing their [FAQ](https://compdemocracy.org/FAQ/) ## Resources - [Session slides](https://drive.google.com/file/d/1kTVz9ugmfZZ0FZ_pb0adkYRqxJliB2B8/view?usp=sharing) - [Polis Report](https://pol.is/report/r7bvdkkasercnfyp4wenb) - Note: the report keeps updating with new responses, so is now different than the one used during the session. ## Session Notes **Note: these were written after the session, and may be missing parts of the conversation. Contributions welcome!** ### Context - Polis answers fragmented respondents in two groups - Group A: - Bias towards long term roadmap (and don’t bias towards current users) - Network upgrades should *not* happen more frequently - “CFI” is a useful status - ethresear.ch is a good venue for research proposals - Group B: - We should *not* ossify - Bias towards current users, remain - pragmatic when planning forks - More frequent, incremental upgrades - Don’t CFI/Include EIPs on first ACD - where presented - **Highest agreement statement**: *"There is a growing number of areas in the Ethereum protocol where client teams are not the best informed stakeholders to make a decision (e.g. issuance/MEV, affordances for smart contract developers, L2 standardization)."* - **Most divisive statement:** *"Changes introduced to Ethereum today should bias towards current developers & users' needs, even if it means compromising or delaying long-term roadmap items."* ### Open Conversation - Most client devs do not deeply understand how "the other layer" works. This has led to delays in finding certain issues that arise due to cross-layer interactions, e.g. Inclusion Lists & AA. To improve this: better comms between clients (up to spending time on other teams), better abstractions (e.g. Engine API). That said EL/CL understanding is better than ACD <> community. That is worth emphasizing more. - **Community engagement** - ACD is not the place for this, breakouts are better, but their format should be standardized (notes, recaps, outreach, etc.). It should be on the breakout lead to then surface the important takeaways to ACD. - Default to inviting "domain experts" to breakouts vs. ACD, in order to avoid them spending 90m on a call where they only will be involved for ~5m. - There is value in ACD being open to community proposals, but conversations are often unproductive if people have little context. Instead of people "randomly showing up on ACD to disscuss a new EIP", there should first be an async process. - :bulb: **Idea: Flag an EIP for "Review Request" on ACD, assign reviews on call.** :bulb: - Avoid reviewing new EIPs with little context live on ACD. - It should be OK for teams to say "this is not a priority, will not review". - Get an async review by 1+ teams before next call - EthMagicians not great for this because of low signal:noise ratio. :bulb: **Idea: create a "formal review space" for core devs (and others?) to provide reviews without them being buried in 100s of comments.** :bulb: - Have synchronous discussion on later ACD. - **Ethereum Magicians is not great today to do this: few admins, no ways to get notifications, etc. but we should improve it.** - notes.ethereum.org if perceived to be "official", rather than an internal EF tool. :bulb: **Idea: make the EF domain notes.ethereum.org and allow broader access to notes.ethereum.org.** :bulb: - EIP Process - CFI is useful, but we should use it better. - We need better discoverability, somewhere people can easily go to see "everything that's being considered for inclusion". - CFI should be somewhat independent from the implementation process. Having something on a devnet should not "imply" CFI. - Unclear if we need an additional status in addition to CFI. For Pectra we had: - 8 (currently) included EIPs - 4-14 CFI'd EIPs (4 if "EOF" counts as 1, 14 if each EOF EIP counts as 1) - 21 more "proposed" EIPs - **Should `Proposed` be a formal status?** - Agreement that EIPs should not be CFI'd/Included on the same call. Less agreement on whether CFI should be mandatory. - EIP Champions should have the responsibility to get core devs to pay attention to their EIP, and provide reviews. - Very different skillsets to "implement the EIP" vs. "champion the EIP": we don't want advertisement campaign for EIPs. - EIP editors: client devs don't want to be involved in the "process discussion", but less reluctance to participate in the "technical review process". - Perception that EIPIP has gone on "forever", not clear what the use is, etc. :bulb: **Idea: consider a different approach to implement process changes going forward.** :bulb: - Network Upgrade Processs - [Tim's current view of the process](https://storage.googleapis.com/ethereum-hackmd/upload_2a3d1e9ee619e0a35d7c5bf5fdbac12b.png) - Given the nature of Ethereum development (there actually are many teams working on this!), we can't impose a top down, extremely clear process: better to iterate from our current state. - Does asking "Are there any objections?" default to including things? - Tim: Probably not: because we discuss things clients _want_ to do. Still, hard to say "no" to things! No one wants to be the "bad guy". - Ideally, teams would align on a position for EIP inclusion before calls. Doesn't have to be fully aligned, we want to tolerate disagreements and empower individuals to express their concerns, but teams should do a "first pass" internally. - Easier to collect support async vs. objections. - Big vs. Small forks, targetting dates vs. scope - Tim: Small forks don't exist (except in emergencies). Impossible to predict the time it takes to implement complex software with non-trivial R&D component. A better model to think of fork scope: music festivals. - Plan the festival around the headliner (most important/complex) EIP, and accepted that in nearly all cases, we'll do what it takes to ship that. We can estimate how long that will be, but we'll likely be wrong. Smaller EIPs can be kicked out if they delay the main thing, but if "the main thing" is removed, you now have to rethink the ~~festival~~ fork from scratch. ## Next Steps Tim will own formalizing proposals/next steps on this. Feedback welcome! Pari can help with devops/technical tasks. A big constraint for many of these efforts is "basic grunt engineering work". Assitance welcome!