Update Breakout Room Meetings

Breakout-Room-Meetings/(e)PBS/(e)PBS-pm.md

@@ -16,6 +16,8 @@ In EIP-7732 or (e)PBS Breakout Room, client developers discuss specs & implement
 
 | # | Date | Agenda | Recording | Notes |
 | -- | --| -- | -- | -- |
+|10| September 27, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1157) | [Recording](https://youtu.be/s5Bx_CWf5yg) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2010.md)|
+|8| September 13, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1150) | [Recording](https://youtu.be/2BUsiUnUZYc) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2009.md)|
 |8| August 30, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1135) | [Recording](https://youtu.be/BZhYP-JRS7U) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2008.md)|
 |7| August 16, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1133) | [Recording](https://youtu.be/fQx_UbaPX-E) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2007.md)|
 |6| August 02, 2024 | [Agenda](https://github.com/ethereum/pm/issues/1120) | [Recording](https://www.youtube.com/watch?v=Otxw1uXxFCI) | [Notes](https://github.com/poojaranjan/pm/blob/master/Breakout-Room-Meetings/(e)PBS/Meeting%2006.md)|

Breakout-Room-Meetings/(e)PBS/Meeting 09.md

@@ -0,0 +1,36 @@
+# (e)PBS Breakout Room #9
+
+Note: This file is copied from [here](https://hackmd.io/@ttsao/epbs-breakout-9)
+
+### Meeting Info
+
+**Agenda**: https://github.com/ethereum/pm/issues/1150
+
+**Date & Time**: [Sep 13, 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/2BUsiUnUZYc
+
+### Meeting notes:
+# EIP-7732(ePBS) Breakout #9 Notes
+
+## Summary
+
+- Slot auctions give an out-of-protocol trust advantage for running MEV-boost auctions at execution phase.
+- New engine API for retrieving payloads by hash and by range. This could be optimized giving consensus and exectuion are pipelined.
+- Process withdrawals can be moved to execution but need extra sanity checks.
+
+## Notes
+Julian presented a [new argument against slot auctions, stating that slot auctions](https://docs.google.com/presentation/d/1-MnAqDzR7JapIPpUEbScALEtY5axyRcPgJDpgaJ_qVI/edit#slide=id.p) give off-protocol a clear advantage over on-protocol. The new argument can be summarized as follows. A proposer is better off doing the following:
+
+- Modify the client codebase to always select its own header
+- Commit to its own header at second 0
+- Between seconds 6 and 9, run a mev-boost auction
+- The payment between Builder to the Proposer happens off chain
+
+It's likely that the realized block value will be higher than the expected block value, and the proposer will favor the mev-boost auction. There is an out-of-protocol trusted advantage in committing to your own header and then using mev-boost. This is a strong argument in favor of block auctions over slot auctions. There are a few attacks we want to further analyze, such as same-slot unbundling, to see if they can be triggered. The current plan is to stick with block auctions and then switch to slot auctions when we feel safe to do so.
+
+Mark presented a [new engine API methods](https://github.com/ethDreamer/execution-apis/blob/eip-7732/src/engine/eip-7732.md) to get payloads from the EL. These payloads are required to serve syncing by range nodes. Potuz questioned the necessity of getting such payloads since the EL could retrieve them themselves, and when a CL node is syncing, it only needs to verify if the block hash is valid. We will proceed with Mark's engine API changes, but in the background, we’ll continue considering how to optimize it and potentially use a simpler engine API that only checks if a block hash is valid, as this is made possible with ePBS.
+
+Finally, we discussed withdrawals, specifically whether they should be processed in the consensus layer or execution layer. Processing in the execution layer has several unknowns that need to be carefully considered. It's recommended to watch the talk for more details. For now, we'll stick with processing in the consensus layer unless someone confidently steps up and confirms that processing in the execution layer is safe.
+
+Side note happened in Discord, Potuz mentioned: `ePBS in the CL spec was already changed by Lucas's PR https://github.com/ethereum/consensus-specs/pull/3875. I am in the process of rebasing https://github.com/ethereum/consensus-specs/pull/3854 which will be very very painful. If you guys want to move withdrawals to the EL processing please signal this right now cause I won't make these changes twice 🙂`

Breakout-Room-Meetings/(e)PBS/Meeting 10.md

@@ -0,0 +1,25 @@
+# (e)PBS Breakout Room #10
+
+Note: This file is copied from [here](https://hackmd.io/@ttsao/epbs-breakout-10)
+
+### Meeting Info
+
+**Agenda**: https://github.com/ethereum/pm/issues/1157
+
+**Date & Time**: [Sep 27, 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/s5Bx_CWf5yg
+
+### Meeting notes:
+
+We thought it was going to be a 5-minute meeting, but it ended up lasting over an hour. I didn’t capture the open-ended discussions, only the actual action items. For open-ended discussions, please refer to the recording. The action items are the following:
+
+- Process withdrawals will continue to be on the consensus layer. If we move process withdrawals to the execution layer, verifiers would use the post-beacon state (or pre-execution state) to verify withdrawals, causing asymmetry. The builder commits withdrawals using the pre-beacon state, but the verifier uses the post-beacon state. There’s no clean solution to this unless we move to a slot auction.
+- Clients provided their updates with steady progress. Teku is completing the beacon chain spec, Lighthouse is getting to the fork choice spec. Most of us are waiting to implement fork choice last, and we are just now focusing on it. Fork choice remains the critical component and the most non-trivial change in this EIP, so more attention is needed.
+- There were open-ended questions about why payment has to be done on the consensus layer and why builders have to be staked. A simple answer was reduced complexity. Currently, ePBS is only scoped for CL changes, with no engine API or EL changes. Moving payment to EL without staked builders would significantly increase complexity, alongside fork choice and other open questions.
+- There were open questions about what benefits ePBS brings, which are documented in these posts. Feedback is welcome:
+  - https://eips.ethereum.org/EIPS/eip-7732
+  - https://hackmd.io/@ttsao/bypassing-relayer
+  - https://hackmd.io/@potuz/rJ9GCnT1C#Extra-benefits
+- There were open questions about having some sort of ePBS office hours instead of breakout calls to allow more open-ended discussions. Potuz and I are totally open to this, just let us know.
+- We talked about making significant development strides to have a devnet before Devcon. The next few weeks will be crucial as we progress toward this goal. More updates in two weeks.

Breakout-Room-Meetings/PeerDAS/Meeting 01.md

@@ -0,0 +1,51 @@
+# PeerDAS Breakout Room #1
+
+Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq)
+
+## Meeting Info: 
+**Date**: 2024.06.11
+
+**Agenda**: https://github.com/ethereum/pm/issues/1059
+
+**YouTube Video**: https://www.youtube.com/watch?v=P86Dr9ABGeg
+
+## Notes
+
+- 12:04: DappLion nowhere to be found (Fixed by 12:10)
+### Client updates:
+- **Lighthouse:**
+  - Various custody column lookup improvements based on interop feedback (request batching, load balancing among custodial peers etc)
+  - Made PeerDAS network params (custody requirement, subnet count etc) configurable 
+- **Prysm**: database upgrade, more efficient in reconstructing data
+  - get_custody_columns & NodeID generation issues https://hackmd.io/TSLwFcUMTkynfVtf-a9_Ag
+    - Prysm, Lodestar, Nimbus generate new NodeID at each restart for anonymity 
+    - Prysm PR: https://github.com/prysmaticlabs/prysm/pull/14098
+  - Francesco in chat about getting a random privateKey / nodeID at each start for full node (without validator) only: “the current parameters you still won’t have any anonymity because 128 choose 4 is too high”
+- **Teku**: working on the draft sampling PR
+- **Nimbus**: Started after the interop.
+### Specs
+- Considering moving MAX_BLOBS_PER_BLOCK to configuration + removing it from the EL side with EngineAPI update
+  - However, it may break optimistic sync
+- PeerDAS activation
+  - Consensus to leave PeerDAS activation logic same as devnet-0 for the next devnet to keep things moving 
+- PeerDAS bandwidth problem: https://discord.com/channels/595666850260713488/1247156108263555185/1247156110146928640
+
+
+## Actions
+
+- Go through current preset/config.yaml and check if we should move any value into config.yaml
+- Start discussion on CL set blob max limit
+
+## Zoom chat links
+- https://github.com/ethereum/pm/issues/1059
+- https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit?usp=sharing
+- https://hackmd.io/TSLwFcUMTkynfVtf-a9_Ag
+- https://github.com/prysmaticlabs/prysm/pull/14098
+- https://github.com/sigp/lighthouse/pull/5899
+- https://github.com/ethereum/consensus-specs/pull/3782
+- https://github.com/ethereum/consensus-specs/pull/3772
+- https://github.com/ethereum/consensus-specs/pull/3717
+- Discord thread here: 
+	https://discord.com/channels/595666850260713488/1247156108263555185/1247156110146928640
+- Full zoom chat [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit)
+