diff --git a/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md b/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md index 9bea8df5..32a64d53 100644 --- a/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md +++ b/Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md @@ -1,7 +1,10 @@ -# enshrined Proposer Builder Separation a.k.a (e)PBS +# enshrined Proposer Builder Separation a.k.a (e)PBS [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) -In (e)PBS Breajout Room, client developers discuss ePBS, its essential components and possible inclusion in Ethereum Network Upgrade. -Useful Resources +In EIP-7732 or (e)PBS Breakout Room, client developers discuss specs & implementation for ePBS and possible inclusion in Ethereum Network Upgrade. EIP-7732 fundamentally changes the way an Ethereum block is validated by decoupling the execution validation from the consensus validation both logically as well as temporally. + +**Useful Resources** +- [EIP-7732: Enshrined Proposer-Builder Separation](https://eips.ethereum.org/EIPS/eip-7732) +- [Discussion link](https://ethereum-magicians.org/t/eip-7732-enshrined-proposer-builder-separation-epbs/19634) - [Beacon chain spec](https://github.com/potuz/consensus-specs/blob/f31929acd92efea3d3ac92ce7a8c6ea05bb2472c/specs/_features/epbs/beacon-chain.md) - [Fork choice spec](https://github.com/potuz/consensus-specs/blob/f31929acd92efea3d3ac92ce7a8c6ea05bb2472c/specs/_features/epbs/fork-choice.md) - [General design notes](https://github.com/potuz/consensus-specs/blob/f31929acd92efea3d3ac92ce7a8c6ea05bb2472c/specs/_features/epbs/design.md) @@ -13,7 +16,10 @@ Useful Resources | # | Date | Agenda | Recording | Notes | | -- | --| -- | -- | -- | -|2| June 07, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1060) | [Recording] | [Notes] | +|5| July 19, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1095) | [Recording] | [Notes]| +|4| July 05, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1083) | [Recording](https://youtu.be/WC9XsungamU) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2004.md)| +|3| June 21, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1060) | [Recording](https://youtu.be/J1e5iUvcTDU) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2003.md) | +|2| June 07, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1060) | [Recording](https://youtu.be/w7Wa6oprEhQ) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2002.md) | |1| Feb 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/953) | [Recording](https://youtu.be/63juNVzd1P4) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2001.md) | diff --git a/Breakout-Room-Meetings/(e)PBS/Meeting 02.md b/Breakout-Room-Meetings/(e)PBS/Meeting 02.md new file mode 100644 index 00000000..543d92e6 --- /dev/null +++ b/Breakout-Room-Meetings/(e)PBS/Meeting 02.md @@ -0,0 +1,53 @@ +# (e)PBS Breakout Room #2 + +Note: This file is copied from [here](https://hackmd.io/@ttsao/epbs-breakout2) + +### Meeting Info + +**Agenda**: https://github.com/ethereum/pm/issues/1060 + +**Date & Time**: [June 07, 2024, 14:00-15:00 UTC](https://www.timeanddate.com/worldclock/converter.html?iso=20240213T140000&p1=1440&p2=37&p3=136&p4=237&p5=923&p6=204&p7=671&p8=16&p9=41&p10=107&p11=28) + +**Recording**: https://youtu.be/w7Wa6oprEhQ + + +### Meeting notes: + +#### Action items: + +1. The consensus layer client should check if it can process a consensus block in under 1 second. This includes the entire end-to-end process, similar to a pre-merge setting. +2. The consensus layer client should provide a beacon API to retrieve the fork choice weight of a specific block. +3. The fork choice specification should include a backoff scheme to recover from prolonged network liveness degradation. +4. The fork choice specification would benefit from more reviewers to examine competitive edge cases. +5. The validator specification should move the sync committee duty from 4 seconds to 3 seconds into the slot. +6. The consensus specification requires more analysis on whether PTC slashing is fully necessary and if the attack vector of spamming multiple PTC statuses is a concern. +7. The consensus specification may need to move the builder reveal cutoff and PTC attestation cutoff to an earlier time to mitigate the builder reveal timing game. + +#### Summary: + +- We proposed to start the meeting with some implementation details and current concerns. +- The first concern is the timing of block processing. +- Today, everything (consensus, execution, blobs) happens in the hot path within 2-4 seconds. + +![image](https://github.com/poojaranjan/pm/assets/29681685/4123a476-fa4f-4aeb-a3d2-ab4c54152e37) + + +- In ePBS, the hot path is pipelined across the slot. We assume a consensus client can process a block in under 1 second, which we believe is feasible. + +![image](https://github.com/poojaranjan/pm/assets/29681685/db27a95b-a561-48ae-b521-08b399a854ca) + + +- Builders should release the block as soon as there is sufficient weight. The consensus layer client should provide a beacon API to return the fork choice weight of a block root. We shouldn’t expect builders to figure this out themselves. +- PTC votes on the timeliness and availability of the payload, not its execution validity. Execution validation can be deferred until the beacon attestation deadline of the next slot, which is a significant improvement. +- We discussed the complications of withdrawals, given the concept of empty slots in ePBS. If there are dependencies between consensus and execution, like withdrawals, they need careful design. Currently, withdrawals originate from the consensus layer and finish at the execution layer. If there is an empty slot, the withdrawal must be remembered and fulfilled in the next slot. To reduce complexity, we should minimize interdependencies. +- We clarified that there will be two post states: one for consensus and one for execution. The current fork choice specification reflects this. +- We talked about local building, which follows the same process as today. Geth could return the bid or the full execution block, and the execution block could be gossiped early since both the proposer and builder are trusted. +- We agreed that we need to conduct a fork choice liveness analysis to account for performance under poor network conditions. If chain growth stops completely when block latency exceeds SECONDS_PER_SLOT / 3, we could implement a backoff scheme similar to the one Francesco originally designed for Peerdas. +- We are looking for more people to review fork choice, as it is the most critical part of the ePBS change. More reviews on competitive edge cases will be helpful. +- We confirmed that no team has started implementation except for Prysm. +- We discussed the current ePBS block auction versus forward-compatible designs like slot auctions and ticket auctions. Since slot and ticket auctions don’t have a Python spec, it’s hard to analyze them. We think slot auctions are relatively easy if we can prove that builder double proposing won’t cause much damage. There hasn’t been much progress until someone seriously examines slot auctions under current LMD ghost and FFG. +- We mentioned the need to change the sync committee deadline from 4 seconds to 3 seconds. We talked about whether the current sync committee could be used for PTC duty. It’s difficult because of aggregation, and the sync committee is long-lived rather than shuffled every slot. +- We discussed whether to add slashing for PTC. If PTC members gossip all possible outcomes, there’s no hard penalty. If PTC is not included in the block, it loses the reward. We need more analysis on how this might negatively affect the network. +- We talked about the builder timing game. It could be an issue, so we might move the builder reveal time and PTC attestation cutoff time earlier. This seems feasible since attestations arrive in under a second, and builders are well connected. +- We discussed PTC rewards. Currently, PTC members are borrowed from the beacon committee, a very small subset (521 out of 30,000). PTC members get rewards for sending correct attestations and are penalized for incorrect ones. They are welcome to send beacon attestations, which will be counted but not rewarded. This approach simplifies specification and implementation. PTC doesn’t add LMD weight; it’s only for the next slot attestation to apply reveal boost. +- Finally, We were asked, "What incentive do current builders and proposers have to switch to ePBS?" This is an important question, but we didn’t have time to cover it. We decided to discuss this in the next call. diff --git a/Breakout-Room-Meetings/(e)PBS/Meeting 03.md b/Breakout-Room-Meetings/(e)PBS/Meeting 03.md new file mode 100644 index 00000000..816938e5 --- /dev/null +++ b/Breakout-Room-Meetings/(e)PBS/Meeting 03.md @@ -0,0 +1,45 @@ +# (e)PBS Breakout Room #3 + +Note: This file is copied from [here](https://hackmd.io/@ttsao/epbs-breakout3) + +### Meeting Info + +**Agenda**: https://github.com/ethereum/pm/issues/1067 + +**Date & Time**: [June 21, 2024, 14:00-15:00 UTC](https://www.timeanddate.com/worldclock/converter.html?iso=20240213T140000&p1=1440&p2=37&p3=136&p4=237&p5=923&p6=204&p7=671&p8=16&p9=41&p10=107&p11=28) + +**Recording**: https://youtu.be/J1e5iUvcTDU + + +### Meeting notes: + +#### Highlights: + +1. A new version of the consensus specification, rebased on top of Electra, will be opened soon. +2. We reviewed changes to the beacon block and state structure, considering whether it makes sense to use header.block_root instead of header.block_hash. +3. We discussed using the SSZ option for the payload withheld message. +4. We believe the slot auction is feasible and preferable in the current EPBS design and worth exploring. +5. Finally, we discussed pre conf and EPBS, including potential contentions and the long-term winning design of pre conf on top of EPBS, as well as how EPBS can improve pre conf. + +#### Summary: + +- We began the call by reviewing the latest progress on the consensus specification. Efforts are focused on rebasing to the latest Electra release, including moving consolidation out of the block body to the execution payload. Additional time is required to audit changes to attesting indices, ensuring they do not return PTC indices. Currently, no inclusion list is needed as validators can self-build. The specification will be opened soon with the following priorities: + 1. Open the consensus spec first, which includes beacon chain, validator, builder, P2P, and fork choice components. + 2. Follow with the EIP and engine API. Minimal changes are expected to the engine API specification. + 3. No changes are anticipated for the execution specification. +- We debated the potential benefits of changing header.block_hash to header.block_root. This change could simplify proving processes, assuming relevant use cases arise. Currently, the block hash is used for its simplicity and because the EL already tracks it. +- We agreed to remove state.latest_execution_payload_header, a field necessary during the pre-merge phase but largely redundant post-merge. Instead, tracking the parent block hash would have sufficed. In EPB, this field is updated to execution_payload_header to monitor the builder’s header. +- We discussed using SSZ optional for the withheld status. There was consensus that the optional approach is preferable to the current withheld status. The key question is the timeline for implementing optional and targeting it for future forks. The current specification can proceed as is, switching to optional once it gains full popularity and a target fork is defined. +- It was clarified that if a payload is invalid but the consensus block and header are valid, the consensus block remains valid. +- We explored scenarios where a proposer sees a withheld message, but PTC has not. If the proposer sees the payload and PTC does not vote on it, an honest proposer can import the payload. Even without reorg or boost, the payload will extend the head. +- We noted that there cannot be an attack on equivocation from the builder's side, which is significant for moving towards slot auction-based designs. +- We clarified the lack of rewards for PTC. PTC is a subset of the beacon committee and receives attestation rewards, but cannot earn additional beacon attestation rewards. It’s crucial that honest validators prevent PTC members from attesting. + +The call concluded with a discussion on EPBS and pre-confirmation: + +- Processing in-contention payloads during beacon block processing is problematic for EPBS. +- Large inclusion lists are detrimental to EPBS and other applications like DVT because they require simultaneous validation by both the execution and consensus layer clients. +- EPBS benefits from having a staked builder. Once staked, the builder is compatible with some pre-confirmation designs. Designs requiring a restaked builder complement EPBS and perform better within EPBS. +- If MEV-Boost is discontinued, any necessary functions can be redefined under the beacon API and engine API. + +In summary, EPBS implementors should assess how pre-confirmation transactions are handled in every design, particularly whether they must be included in the consensus block or can be enforced at the builder level. Ideally, all enforcement should be on the execution side. Long-term, pre-confirmation designs are more suitable within the EPBS framework because staked builder. diff --git a/Breakout-Room-Meetings/(e)PBS/Meeting 04.md b/Breakout-Room-Meetings/(e)PBS/Meeting 04.md new file mode 100644 index 00000000..4cb44288 --- /dev/null +++ b/Breakout-Room-Meetings/(e)PBS/Meeting 04.md @@ -0,0 +1,30 @@ +# (e)PBS Breakout Room #4 + +Note: This file is copied from [here](https://hackmd.io/@ttsao/epbs-breakout4) + +### Meeting Info + +**Agenda**: https://github.com/ethereum/pm/issues/1083 + +**Date & Time**: [July 05, 2024, 14:00-15:00 UTC](https://www.timeanddate.com/worldclock/converter.html?iso=20240213T140000&p1=1440&p2=37&p3=136&p4=237&p5=923&p6=204&p7=671&p8=16&p9=41&p10=107&p11=28) + +**Recording**: https://youtu.be/WC9XsungamU + + +### Meeting notes: +#### Highlight: + +1. EIP is here : [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) +2. Consensus spec pull request is here: [PR-3828](https://github.com/ethereum/consensus-specs/pull/3828) +3. Processing withdrawals as part of the execution payload has additional complications, such as engine API fcu+payload_attribute withdrawals being fresh. +4. Bid gossip P2P is vulnerable to DoS if we don't constrain bid values. + +#### Summary: + +- We have an EIP number! ePBS as we know it today specific to block auction, will now be referred to as EIP-7732. +- Potuz is wrestling with the consensus layer spec unit tests. Given the structural changes and 700+ failed tests post-ePBS, this will be the main focus for the coming week. The current PR could be merged as is, with subsequent PRs to specifically address the failing tests. +- We brought up the first agenda item: Advantages/Disadvantages for builders/proposers not using the in-protocol auction. No one had anything to say on this topic, so we moved forward. +- We discussed processing withdrawals as part of the execution payload. This shifts the withdrawal to the payload itself, making it cleaner and similar to how Electra processes deposit/withdrawal requests today. We considered edge cases, such as empty slots where withdrawals are not honored in the EVM. The following execution proposer would then have to honor it, but by that time, the validator's balance could be lower. Another main tradeoff discussed was the execution-API change where we call FCU and payload attribute to the local execution client, ensuring the withdrawals in the payload attribute are "fresh," meaning the head state should be processed to the latest slot. +- We talked about PTC equivocations. A malicious builder could split the PTC votes to half reveal and half withhold, using the last PTC vote to equivocate and split the network under two views. It's unclear what advantage a builder could gain from this attack, other than causing network issues. A potential solution is to change the threshold from 50% to 66%, requiring a builder to cause this attack with 33%. However, it's uncertain if this is worth pursuing. +- We discussed the gas limit. A proposer could use a bid from RPC or P2P. For RPC, we could update get header to include a gas limit field, where builders may already cache different bids by different gas limits based on validator preferences. We don't need a registration RPC call like today. For P2P, we talked about the current P2P DoS concern since any validator could gossip a low-value bid. We could change the DoS pipeline to top N bids or use a simple heuristic. +- Finally, we discussed pre-confirmation and the inclusion list. Nothing major was noted, so I won't include them here, but feel free to watch the recording if you want more details.