@ethDreamer was kind enough to help me develop a more informed opinion on various EIPs, so 0x/Matcha’s response has been updated
2 Likes
What stakeholder category do you represent?
e.g. wallet devs, DEXs, bridges
Chainbound — R&D Lab focusing on infra layer.
What do you view as the top priority theme in this fork & why?
e.g. censorship resistance, scaling the L1, improving UX, etc.
We see scaling the L1 in terms of throughput and lowering fees as the main theme for this fork. If done properly, without introducing new negative externalities and by lowering down the technical debt of the protocol, it has downstream effects in both the rollup roadmap and for improving UX for a wide variety of users. This process makes Ethereum as a global platform more attractive for everyone, fostering its growth in multiple directions.
We see also censorship resistance as an equally important part of the roadmap, however we’re not completely satisfied with current proposals, as motived below.
Which EIP(s) do you favor as a headliner for Glamsterdam?
note: the process is aiming for one EIP each for the consensus and execution layers
Execution Layer: EIP-7928 — Block Level Access list. This is clearly a low-hanging fruit improvement that is both future-proof (e.g. non-contentious with EVM upgrades) and with basically no tradeoffs. It benefits a wide variety of users: both users of L1 dApps because of cheaper usage of read/writes on storage, and users on L2s, as carefully explained by @donnoh.
Consensus Layer: EIP-7732 — enshrined Proposer-Bulider Separation. This EIP creates a framework to better spreads tasks and resources over the slot, favoring both home-stakers and future improvements like APS and ETs. We basically agree with what’s mentioned in this post.
We acknowledge the following open questions of the proposal:
- The existence of the “Free Option Problem” — Thanks to some comments (see here and here), we consider it more an independent problem of the already existing PBS market structure. In our opinion, this EIP more concerned with efficient slot restructuring rather than enshrining a specific market structure. For example, by requiring a validator signature over the transaction list in the execution header, we could keep the pipelining benefits while killing the PBS market structure.
- DA attestation deadline — The current proposal states that the payload and the blobs must be observed by the Payload-Timeliness-Committee at the same time. As such, moving the PTC deadline to favour execution time would result in less blob propagation time. To contrast this, we’re fully supportive of the Dual-deadline PTC vote proposal.
Lastly, we mark EIP-7805 (FOCIL) as the second best candidate for the Glamsterdam CL headliner. However, we have minor questions regarding its implementation, expressed in the “concern” section.
The leading headliners among client teams are described in a series of blog posts listed here. Do you have any concerns about any particular proposal?
As mentioned above, we consider FOCIL as the 2nd best option for the CL headliner in Glamsterdam. However, we have some minor concerns about its implementation:
-
It doesn’t support blob transactions, so it means support for it must come in another hard-fork that might change how blob transactions are propagated. While some proposals do exist (for example, blob ILs and our own blob notaries design), there isn’t a concrete roadmap to make it happen as far as we know. With Ethereum doubling down in increasing its blob count, supporting them becomes more and more relevant.
-
For rollups, if censored, settling becomes much harder due to the 8KiB as max IL size. Moreover, recent updates such as EIP-7623 make using large amount of calldata more expensive than before.
-
The current proposal of FOCIL states that the inclusion list building logic is up to the consensus clients implementation. In our opinion, assessing which transactions are being censored is a very hard task, unless explicitly part of the OFAC list. This would lead to a risk of wasting a small yet extremely precious resource. Examples include:
- Picking at random from the mempool can lead to not choosing a censored transaction for some slots in a row, degrading eventual censorship resistance UX.
- Picking the highest paying transactions can lead to IL members picking the same small subset of mempool transactions that fit in a 8KiB IL.
- Picking transactions that have been in the mempool for a while can incentivise non-censored users flooding with low-priority transactions (e.g. 1 wei priority fee).
While we acknowledge the difficulty of this problem, we see more suited a design where the user explicitly ask for its transaction to be force-included in the next blocks in exchange for a tip. A tip is justified to avoid spam and because the service done by the protocol is converting from probabilistic inclusion to deterministic inclusion.
Any additional comments?
The above represents the view of the Chainbound team.
1 Like
What stakeholder category do you represent?
Cypherpunks.
What do you view as the top priority theme in this fork & why?
The top priority in this fork must be censorship-resistance. It’s one of the non‑negotiable anchor guys. We don’t build Ethereum to be “convenient” for regulators or comfortable for institutions; we build it so that no one (i.e. not a government, not a corporation, not a cartel of validators etc.) can decide who gets to participate. That’s why we must prioritise censorship-resistance.
I also want to take the opportunity to look ahead beyond this fork. If censorship-resistance is today’s shield, privacy must be tomorrow’s sword. The next fork (i.e. after Glamsterdam) must put privacy as a headliner. Censorship-resistance without privacy is a half measure. I mean a transaction that cannot be blocked but still exposes the sender, receiver, and purpose is still an open invitation to coercion. Real sovereignty means more than just getting a transaction included. It means ensuring that no one can trace it, profile you, or weaponise your activity against you. Let’s never forget this!
Which EIP(s) do you favor as a headliner for Glamsterdam?
On the consensus layer, I strongly favour EIP-7805 (i.e. FOCIL).
On the execution layer, I strongly favour EIP-7928 (i.e. Block-Level Access Lists).
If known, what specific impacts would this have on your community?
Very simply put, it’s one small step towards making Ethereum Cypherpunk again. EIP-7805 ships an important censorship-resistance feature and EIP-7928 improves network efficiency which is important for people running their own nodes.
Does anything make this an urgent feature for you or your community?
Censorship-resistance has always been an urgent priority, because the moment it’s compromised, the network stops being truly permissionless. So there is never a moment where this is not an urgent feature.
The leading headliners among client teams are described in a series of blog posts listed here. Do you have any concerns about any particular proposal?
Look, I understand why many CL teams favour EIP-7732 for their own scaling goals. But this moment is about more than scaling. It’s about making a statement. As core devs, you should send a clear signal that we care first and foremost about a censorship-resistant base layer. Let’s put that as the headline.
Any additional comments?
Let’s make it very clear: our Ethereum base layer will never bow, never bend, and never be silenced. That’s why we wake up every day and pour everything into this fight.
7 Likes
What stakeholder category do you represent?
Gattaca runs PBS infrastructure including the Titan Builder and the Helix Relay
What do you view as the top priority theme in this fork & why?
Scaling the L1 in a manner that is consistent with the strategic protocol initiatives, maximally visible to users,and does not compromise decentralization, censorship resistance, and neutrality.
Which EIP(s) do you favor as a headliner for Glamsterdam?
Consensus Layer:
EIP-7782 (Reduce Block Latency) is the most impactful CL upgrade for users. We want to highlight the following immediate impacts:
- Transaction confirmation time halves.
- Censorship resistance increases alongside the proposer sampling rate.
- LVR imposed on on-chain liquidity decreases by approx. 30%.
We believe that the impact on the geographic decentralization of the validator set can be counteracted by conservatively managing throughput. In comparison to scaling throughput immediately, we favor shorter slot times due to their auxiliary benefits for on-chain use cases (i.e. more frequent information flow), and interoperability.
Execution Layer:
EIP-7928 (BALs) are a high-impact low-complexity addition that paves the way for further scaling. We believe that managing worst-case block processing time is key to robustly scaling in the future (i.e. smoothing tail effects), and that BALs are an effective approach to this. The additional requirements imposed on block builders are easily accommodated and not a hurdle to implementation.
If known, what specific impacts would this have on your community?
We believe that the block production pipeline is ready to accommodate shorter slots and BALs, with ample spare capacity. The reduced transaction confirmation time will directly affect originators positively.
Does anything make this an urgent feature for you or your community?
We believe that now is a good time to use Ethereum’s momentum to introduce upgrades that provide scaling at a fundamental level, like reduced block latency.
The leading headliners among client teams are described in a series of blog posts listed here. Do you have any concerns about any particular proposal?
No significant concerns.
Any additional comments?
We recognize that the combined complexity of shorter slot times and either EIP-7732 (ePBS) or EIP-7886 (Delayed Execution) likely cannot be accommodated in a single hardfork. If feasible, we believe that either EIP is a strong candidate to support slot pipelining and broader scaling efforts, with a slight preference for EIP-7886.
While EIP-7732 is further ahead in the testing cycle and has broader community support, it still has some open research questions (e.g. the “free” option problem), as well as potential negative impacts on the out-of-protocol builder market, with long-term effects on builder competition and concentration. Conversely, EIP-7886 provides 80% of the scaling benefits of ePBS, at reduced complexity, and aligns more closely with the scaling approaches of other L1s (e.g. Monad).
We would additionally like to highlight EIP-7805 (FOCIL) as a valuable additional inclusion if scope allows. We believe that “scaling” entails a maturation of Ethereum’s censorship resistance properties alongside throughput and time-to-finality improvements. FOCIL will allow the network to fully benefit from specialized actors like builders without relying on off-chain discretion for transaction inclusion.
2 Likes
What stakeholder category do you represent?
PBS Foundation, independent researchers, users who care about Ethereum
What do you view as the top priority theme in this fork & why?
The top priority is to make the Ethereum L1 a better, more user-friendly place with smooth, fast and friction-free onchain interactions. Therefore the focus should be on UX improvement, particularly through faster & cheaper TXs for users (L1 scaling & latency).
Which EIP(s) do you favor as a headliner for Glamsterdam?
note: the process is aiming for one EIP each for the consensus and execution layers
Here the condensed preference:
CL: EIP-7782 Reduce Block Latency (1st preference)
alternative: minimal version of EIP-7732 ePBS, subsequently asap EIP-7782
EL: EIP-7928 Block-Level Access Lists (BALs)
More detailed reasoning:
Based on the priority above the most straight-forward answer is EIP-7782 to improve UX with less latency. At this time there’s already a strong push for “slot restructuring first”, with widespread support for ePBS (EIP-7732). Several months ago it would have been more realistic for EIP-7782 to become headliner, currently there seems to be already significant buy-in for ePBS. We still consider EIP-7782 the best choice for users.
With EIP-7732 (ePBS) there’s two main concerns:
- The free option problem
- Complexity and aggregation of multiple things instead of one key thing
The free option problem (1) is described in detail in by Flashbots in The Free Option Problem in ePBS and The Free Option Problem in ePBS, Part II and previously here by RIG.
Through the commit/reveal scheme in ePBS and therefore the builder having the “free option” to cancel the payload just before the PTC deadline there’s a possibility for empty blocks. The more detailed data analysis shows that there’s a high variability of how profitable it is to exercise this option. The average option value is ~3.67 ETH per day with few days of >40 ETH per day.
Regarding the complexity (2) the current ePBS spec consists of three main components:
- Payload-Block Separation
- PTC Committee (Pipelining)
- Trustless Builder Payments
This is a lot for one EIP and yields the above-mentioned free option problem. Recently there’ve been many possible variations of ePBS, Delayed Execution and “slot restructuring”. For further context on the different possibilities and trade-offs there’s @ethDreamer’s Slot Restructuring Tradeoff Matrix as an overview, his 7732 - Late Payload Commitment suggestion, dapplion’s suggestion w/o trustless payments and Toni’s post on Slot Restructuring: Design Considerations and Trade-Offs.
A desirable, minimal version of ePBS could do only Payload-Block Separation and optimistic attesting aka “CL-side delayed execution”. This would still increase the attestation deadline (some scaling) but mitigate the commit/reveal and therefore not have the free option problem. As a second best option instead of directly EIP-7782 such a minimal version of ePBS would be the safest and fastest path to better UX through L1 scaling and decreased latency with 6s slots right after.
If known, what specific impacts would this have on your community?
Apart from the obvious UX impact for users, there’s positive effect on MEV extraction through shorter slots. DEX LPs would lose less money to arbitrageurs through LVR / impermanent loss with smaller price update intervals.
Does anything make this an urgent feature for you or your community?
Improving UX and scaling the L1 is important and urgent for all Ethereum users.
The leading headliners among client teams are described in a series of blog posts listed here. Do you have any concerns about any particular proposal?
Concerns around free option problem for ePBS, complexity and doing “multiple things” have already been raised above. There’s a small fear that it might become another “EOF situation”.
Any additional comments?
FOCIL is great for Censorship Resistance and we’d love to get it in as well. For now we’d prioritize UX higher though.
What stakeholder category do you represent?
User and Genesis Home Staker (I don’t represent anyone else)
What do you view as the top priority theme in this fork & why?
Censorship Resistance
This feels like it should have been raised before, but I guess it is kind of a taboo.
With the amount of ETH staked by institutions on the rise, the appetite for Censorship Resistance will likely decrease and might eventually even be blocked. Since most of this entities are US based, it doubly impacts CR.
…one of the things [tradfi institutions] are looking for are “clean blocks” that have no other transactions to any other unknown entities including unknown validators
– Andrew Keys (The Ether Machine - Chairman)
link to Bankless clip
I’m not sure why “clean blocks” are important since each tx is independent and atomic, but this would effectively halt the chain for “unknown entities” whenever a “clean block” is bought.
Buying a whole block is possible today, but it is not common since proposers are incentivized to propose the highest paying block. But large “institutional stakers/proposers” that can negotiate deals offchain might have other incentives.
Which EIP(s) do you favor as a headliner for Glamsterdam?
note: the process is aiming for one EIP each for the consensus and execution layers
EIP- 7805: FOCIL (needs changes on both layers)
If known, what specific impacts would this have on your community?
Down (a possible) line, transaction inclusion censorship.
Does anything make this an urgent feature for you or your community?
Possibly urgent, given the speed at which institutional stakers are being onboarded
The leading headliners among client teams are described in a series of blog posts listed here. Do you have any concerns about any particular proposal?
Since parts of ePBS are a prerequisite for FOCIL, and CL devs showed preference to working on both together, ePBS could also be included, but imo the priority should be FOCIL, not the other way around (no dropping FOCIL because it “delays the fork”)
Any additional comments?
The 6 month fork cycle should be a guideline, not a rule. If a fork is larger because splitting the included EIPs into two forks requires significant additional work, doing an 9 month fork actually means shipping faster.
1 Like