---
tags: ["[rcnyc]"]
---

# [rcnyc1]

**Consensus**

- Implementation considerations
- Each validator must broadcast and run a set agreement, increasing time and message-passing complexities with each additional validator. Regardless of the particular multi-proposer implementation, we must "eat the complexity"...
- ...in the fork choice rule design (since storing subtrees in node memory)
- ...in the union and merging of transactions across proposers
- ...in having to account for the fact that proposers will play timing games to the point of forced simultaneous release
- *n.b.*, this is part of why it's key to move the state root outside the critical path
- Privacy
- For any given slot, it seems critical to shield information between proposers to avoid consensus destability
- w/r/t/ the proposer lookahead period?
- w/r/t/ the proposer selection round of consensus?
- Vitalik: "The main weakness of multiple-proposers that I see is, that you potentially have 4 actors per slot who have the power to split attesters in half for that slot, instead of just one."

- Proposer incentives
- Could an earlier auction/actor strive to capture tips / could it be "gamed" a la `mev-boost`?
- Is there any destabilization threat from the potential of proposers integrating with searchers?
- How do you methodologically design slashing conditions for each fault (from the set of possible faults) given the proposer count has scaled by *k*?
- ...particularly without making staking requirements prohibatively high

- How might we consider having defense in depth against long-tail adversarial behavior (*i.e.*, when all rational proposers are bribed to censor)?

- Decentralization
- How significant is the potential of validator centralization, especially in a world with shorter blocktimes?
- Centralizing factors
- Node hardware requirements and potentially node ops demands increase
- Frequency of a given validator participating in consensus logically increases
- Should we consider parameterizing validator count above 4, or do things get too complex?
- Ethereum's got decentralization going for its network. How can multi-propopser designs not act as headwinds against this? Some form of APS?

**Execution**

- Is there any situation in which it may be insufficient that blocks are built only from the deterministic aggregation of the concurrent proposers' output?
- *i.e.*, Do we absolve the need for any form of inclusion list in this paradigm?
- Recall that censorship resistance is a threshold (Fox, Pai, Resnick, 2023)

- Beyond MEV capture, could and should the protocol address MEV redistribution in the deterministic ordering rule?
- Wen post on "as-needed execution"?

**Applications**

- Reconciling "order-agnostic applications" with the wider tendency of application design towards capturing MEV in app
- May largely depend on the particular in-protocol execution scheduling rule
- The growing tension between app-specific ordering rules and composability (cf. "intra-app interoperability")
- MEV-recapturing designs are siloed; prioritizing maximizing user payoffs comes at the expense of maximizing the global coincidences of wants (across applications) for maximal value extraction (in addition to composability), which could then be bid back to users
- cold-start problem; hard to buy in without seeing the benefits of network effects

**Misc**

- What sorts of out-of-protocol mechanisms might reasonably emerge on the network?
- Could the aim of the deterministic ordering rule be disrupted by another, earlier auction?

- The relevance of shorter blocktimes to all points listed above

- The relevance of increasing the MAX_EFFECTIVE_BALANCE to all points listed above

- Vitalik: "one side benefit of multiple proposers, is that we can get the benefits of SSLE waaaaay more easily Because we can use per-actor-randomness-based solutions Which are like 100x simpler than cryptographic SSLE."

- Should application designers who are already designing in-app consensus be the first to experiment with multiple concurrent proposers in their designs?

**Appendix**

- *Censorship Resistance in On-Chain Auctions* (Fox, Pai, Resnick, 2023)