Skip to content

Commit

Permalink
Merge pull request #1221 from darkfire-rain/master
Browse files Browse the repository at this point in the history
Add files via upload
  • Loading branch information
timbeiko authored Dec 18, 2024
2 parents 7d4a0ae + ec1e307 commit 00cf257
Show file tree
Hide file tree
Showing 12 changed files with 1,096 additions and 0 deletions.
100 changes: 100 additions & 0 deletions Breakout-Room-Meetings/PeerDAS/Meeting 02.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
---
title: Meeting 02

---

# PeerDAS Breakout Room #2

Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq)

## Meeting Info:
**Date**: 2024.06.25

**Agenda**: https://github.com/ethereum/pm/issues/1070

**YouTube Video**: https://www.youtube.com/watch?v=P86Dr9ABGeg

## Notes
### Peerdas-devnet-1
- https://notes.ethereum.org/@ethpandaops/peerdas-devnet-1 (v1.5.0-alpha.3)
- Pandaops needs peerdas-devnet-1 branches from Nimbus, Lodestar, and Grandine. Please check if these branch names are correct:
- prysm: peerDAS
- lighthouse: das
- teku: nashatyrev-das
- nimbus: wip-peerdas
- grandine: das
- lodestar: peerDAS

### Configuration
DATA_COLUMN_SIDECAR_SUBNET_COUNT=64

SAMPLES_PER_SLOT=16

CUSTODY_REQUIREMENT=4

TARGET_NUMBER_OF_PEERS=70
- ACTION: Check the above info on Discord:
- https://discord.com/channels/595666850260713488/1252403418941624532/1255111016702935060

### Client updates
- **Prysm**
- Implemented reconstruction - with a delay. The node waits for 3 seconds into the slot, before sending via gossip
- Improvements to sampling, and implemented LossyDAS / IncrementalDAS
- **Lighthouse**
- improvements to reconstruction to make it non-blocking
- 1.5.0-alpha.3 spec compliant and passing spec tests
- devnet-1 ready, although still working on a sync bug
- Next:
- Fix sync and implement checkpoint sync
- Try out Kev's Rust PeerdasKzg library (ckzg alternative)
- Experiment with fetching blobs from EL for reconstruction and publishing (distributed blob building). Michael has a PR for Deneb, and the team is planning to port it over to PeerDAS.
- **Teku**
- Comply with alpha.3 spec
- Grandine, lodestar, and nimbus are not ready for devnet-1
-
### spec discussion
- Blob max limit
- Solution 1: pass 'max_blobs_per_block'
- https://github.com/ethereum/consensus-specs/pull/3800
- Solution 2: pass `​​base_fee_per_blob_gas`
- https://github.com/ethereum/consensus-specs/pull/3813
- Client teams favor solution 1 today
- **Gajinder** (Lodestar) is in favor of passing the target gas limit (#1), less inclined for #2
- **Lion:** Gas calculation requires UIN256 calculation, most CLs don't do this yet.
- **Nishant:** Prefers #1 as well, as we can leave the gas computation in the EL.
- ACTION: Add this to Thursday's call agenda
- 'get_extended_sample_count'
- https://github.com/ethereum/consensus-specs/pull/3782 ready to merge? -> will merge before Thursday if no objection
- https://github.com/ethereum/consensus-specs/pull/3794 -> will merge before Thursday if no objection
### Open discussion
- Do we want to increase the blob count on devnet-1?
- Some devs think it would be useful, however, MAX_BLOBS_PER_BLOCK is currently a preset value and not configurable in some clients
- Everyone agreed MAX_BLOBS_PER_BLOCK should be configurable
- ACTIONS:
- Lion to make a spec PR for this
- Barnabas will launch devnet-1 without blob increase for now to not delay the launch and will test the blob increase on a few clients with higher blob count later
- **Lion**: Micheal's experiment on fetching from EL pool - apply this technique to PeerDAS
- This would make it more feasible for home stakers in remote areas without good internet
- If blobs are made available in the mempool, supernodes can help reconstruct and distribute
- Nishant (Prysm) also likes this
- Nishant raised concern about the EL bandwidth increase however no one on the call knows exactly what the impact would be
- ACTION: Lion to make a writeup on this
- [20240701 update] Lion’s writeup: https://hackmd.io/@dapplion/blob_fetch
- Devenet-1 num of supermodes per client
- People agreed that we should launch supernode on multiple clients so that the network still has nodes to serve all columns if one client has a bug - more data availability to keep the network alive (likely the reason devnet-0 died)
- ACTION: DevOps would like Prysm / Teku flag for this - teams to share on discord

## Zoom chat links
https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.94w8lt9y3mc7

https://github.com/ethpandaops/ethereum-package/blob/606ba6401241a12bd972980a4df9c77ba03b18a2/.github/tests/peerdas-fork.yaml

https://github.com/ethereum/consensus-specs/pull/3800

https://github.com/ethereum/consensus-specs/pull/3813

https://github.com/ethereum/consensus-specs/pull/3782

https://github.com/ethereum/consensus-specs/pull/3794

https://eips.ethereum.org/EIPS/eip-4844#networking
116 changes: 116 additions & 0 deletions Breakout-Room-Meetings/PeerDAS/Meeting 03.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,116 @@
---
title: Meeting 03

---

# PeerDAS Breakout Room #3
Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq)
## Meeting info
**Date**: 2024.07.09
**Agenda**: https://github.com/ethereum/pm/issues/1093
**YouTube Video**: https://www.youtube.com/watch?v=P86Dr9ABGeg
## Notes
### Client updates
- **Prysm:**
- testing with new KZG APIs
- working on fixing bugs in devnet-1
- **Lighthouse:**
- Mostly working on sync, fixed an issue with rpc limits, and able to serve by range requests
- Got sync to work a branch, but there are still some open issues that cause it to be slow
- Tested kev's rust kzg library and it works well. Potentially merge and switch to it soon.
- Tried to revive devnet-1 with Michael's lcli http-sync tool but no luck with Lighthouse. Best to relaunch devnet.
- ACTION: Raise rate limit on Lighthouse supernode (instead of disabling rate limiter for safety)
- **Lodestar:**
- Able to sync Lodestar using supernodes (without validation) 🎉
- Will work on validation next to participate in running validators on next devnet
- **Grandine:** fixing the sync. Probably won’t participate in the next devnet

### Peerdas-devnet-1

Many forks at the moment. 6 different forks(!!!!): https://dora.peerdas-devnet-1.ethpandaops.io/forks

Should relaunch with a higher rate limit.

Bug 1: rate limiting

Bug 2: syncing

Bug 3: ENR update

- Can be improved with metadata v3 PR: https://github.com/ethereum/consensus-specs/pull/3821

Why did the LH supernode issue break the network?
- Both LH supernodes restarted, and one of them started sending excessive sampling requests to the other. Neither supernode was able to serve requests to others, potentially causing the network to split
- Teku and Prysm supernodes all died too
- Prysm: when Lighthouse died, it triggered a few bugs in Prysm. Prysm is hoping to have these fixed by end of this week.
- DevOps suspected a potential ENR issue, there were a few ENR format mismatches between clients
- LH: using ENR to identify supernodes isn't reliable as they aren't always available. Lion raised a metadata v3 spec PR, that would help with this.
- Prysm: may require a bit of work, and would delay relaunch devnet-2
MetaDataV3 is potentially in the next devnet after devnet-2 since it's nice to have for now.

ACTION: Relaunch with the same specs with bug fixes by the end of this week

### Specs discussion

Decouple network subnet: https://github.com/ethereum/consensus-specs/pull/3832
- already have this for attestation and would like this for data columns
- custody group instead of subnets
- Csaba: good idea, concerned that we're grouping columns just to make it efficient, but need to look into more details
- ACTION: client teams to review and potentially target devnet-3

Passing blob limit from CL: https://github.com/ethereum/consensus-specs/pull/3800
- CL clients generally support it.
- Re: do we realistically see ourselves changing the blob target to anything other than MAX // 2? if we do, then we should also have the CL send target along with max values (with the resulting extension of the EL header to have both values)
- **Barnabas**: more flexibility if we just always send both, even we don't need it in the foreseeable future. Francesco agrees.
- **Pop**: Is there any reason why it's divided by 2?
- **Francesco**: no specific reason. Danrad also chimed in but I missed it. Should we include it in Pectra?
- **Dankrad**: good to include in Pectra, so we don't need to fork the EL to increase blob limit
- ACTION: EIP update and change engine-api interface? and raise in ACD call

### Open discussion
**Kev**: plan to gather P2P metrics?
- Barnabas posted some essential metrics on discord
- Prysm and Lighthouse have most of the metrics
- LH: We need a large-ish network to get realistic metrics, What about Grandine?
- Grandine is currently experimenting PeerDAS development with EPF, unlikely to participate in the next devnet

**Kev**: Rust PeerDAS KZG library
- Teku merged the PR, can we get some part of the network to run the Rust KZG library?
- Lighthouse is likely going to switch to it soon, possibly in the next devnet.

**Jimmy**: Lighthouse working on decentralized block building (Dankrad proposed)
- WIP PR for Deneb: https://github.com/sigp/lighthouse/pull/5829
- Reth fork: https://github.com/michaelsproul/reth/pull/1
- Lion’s HackMD: https://hackmd.io/@dapplion/blob_fetch
- execution-api spec: https://github.com/ethereum/execution-apis/pull/559

**Saulius**: What are the KZG crypto bottleneck
- Kev: the Rust PeerDAS KZG lib does not currently use GPU for "MSM"
- Saulius: NVIDIA GPU should be significantly faster than utilizing cpu fully
- Kev: Be good to get some metrics once it's implemented in Grandine
- Csaba: Having nodes do faster reconstructions in the network is helpful. With more blobs, it will be time-consuming.

## Zoom chat links
https://github.com/ethereum/pm/issues/1093

https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit

https://dora.peerdas-devnet-1.ethpandaops.io/forks

https://github.com/ethereum/consensus-specs/pull/3832

https://github.com/ethereum/consensus-specs/pull/3800

https://github.com/ethereum/pm/issues/1093#issuecomment-2215630809

https://discord.com/channels/595666850260713488/1252403418941624532/1256084227926003793

https://github.com/sigp/lighthouse/pull/5829

https://github.com/michaelsproul/reth/pull/1

https://hackmd.io/@dapplion/blob_fetch

https://github.com/ethereum/execution-apis/pull/55

https://github.com/grandinetech/rust-kzg?tab=readme-ov-file#blob-to-kzg-commitment-1
80 changes: 80 additions & 0 deletions Breakout-Room-Meetings/PeerDAS/Meeting 04.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
---
title: Meeting 04

---

# PeerDAS Breakout Room #4

## Meeting info

**Date**: 2024.07.23

**Agenda**: https://github.com/ethereum/pm/issues/1103

**YouTube Video**: https://www.youtube.com/watch?v=Rqd_DuPQMvg
## Notes
### Client updates

**Prysm**
- Optimized reconstruction to run in parallel across multiple blobs
- Optimisation to make blob available once 64 columns is available since node can always reconstruct

**Lighthouse**
- Working on devnet-1 issues, including the stack overflow issue with peerdas-kzg. Hoping to have a fix this week.
- Still working on sync issues, hoping to stabilize data column rpc methods before the next devnet
- Focused on getting das branch changes into our main branch

**Teku**
- All spec tests updated and passing
- Working on client stability and more tests
- Refactor sampler and added LossyDAS sampler

**Nimbus**
- Solidifying the code around p2p
- Found issues around syncing - full node sending out bad range requests
- Working with Kev on PeerDAS KZG lib and refactor reconstruction logic
- Working on sampling this week

**Grandine**
- EPF working on PeerDAS
- Still working on some sync issues

**Lodestar**
- Refactored syncing
- PeerDAS functionalities mostly working now, also support supernode via CLI params
- Added tests for block production, passing and should be able to participate in the next devnet
- ACTION: Before the next devnet start, we should have MetaDataV3 rpc methods to make sure nodes can identify peer custody columns correctly.

### Devnet Update

'peerdas-devnet-1' was shut down last week. There was a discussion on Discord on client readiness for the next devnet - client teams agree to postpone devnet-2 launch and focus on fixing current issues

**Prysm:** in the last devnet, clients had issues with initial syncing, we should aim to have this working before the next devnet so we can deploy new nodes

**Lighthouse:** Agree, also adding that clients should be able to serve data column rpc queries reliably

**Nimbus** asked how other clients are activating PeerDAS. Having PeerDAS activated at the same epoch as Deneb is difficult for Nimbus

- Lodestar and Prysm are able to activate the PeerDAS fork from Deneb without issue, however it's difficult for Nimbus to activate PeerDAS at the same time as Deneb as PeerDAS is a separate fork.
- Lodestar suggested that as a workaround for Nimbus, we could start with Deneb + PeerDAS at genesis but not send any blobs until Nimbus is ready. Nimbus agreed this would be helpful.
- ACTION: note to delay blob flooding when launching the next devnet

Clients talked about rebasing PeerDAS on Electra
- Prysm has already worked this out and can activate at Electra
- Will require Teku a week to rebase on Electra

Question raised: why are we activating PeerDAS at Deneb? It's never going to happen
- Teams agree that Electra is not stable enough for the purpose of testing PeerDAS, it makes sense to focus on getting PeerDAS functionality working properly on deneb, and rebase at a later time.

### Spec updates

No agenda items this week, however there are two significant upcoming spec changes that teams are encouraged to look at, and be good to finalize these
- PeerDAS fork-choice, validator custody and parameter changes #3779
- EIP-7594: Decouple network subnets from das-core #3832

Prysm raised a question regarding validator custody: if node doesn't reply with their custody columns, it can downscore the peer but not sure how this can be done with validator custody?
- ACTION: Manu to comment on the PR, as there wasn't a solution on the call.

## Zoom

https://github.com/ethereum/consensus-specs/pull/3821
91 changes: 91 additions & 0 deletions Breakout-Room-Meetings/PeerDAS/Meeting 05.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
---
title: Meeting 05

---

# PeerDAS Breakout Room #5

Note: This file is copied from [here](https://docs.google.com/document/d/1Ng2IrCe28kTt1BnIsjtMlKHq2MHgaja24LhFXSvqfJQ/edit#heading=h.tubwqb51zcjq)

## Meeting info

Date: 2024.08.06
Agenda: https://github.com/ethereum/pm/issues/1114
YouTube Video: ​​https://www.youtube.com/watch?v=scOJSLiMFy4

## Notes

### Client updates
**Prysm**
- Fixed initial sync
- Implemented MetaDataV3 query, not yet merged
- Fixing BlobSidecar beacon API for PeerDAS

**Lighthouse**
- Fixed some networking issues and kzg library issues
- Focused on refactoring and merging PeerDAS changes to the main branch. About half way there, and will be focused on finishing it the next 1-2 weeks
- Disabled sampling by default and local network seems be a lot more stable

**Lodestar**

- Should be good to participate in devnet without sampling
- Question: are we going to include the data availability changes to fork choice?
- not for the next (few) devnets

**Grandine**

- Made progress with some EPF participants
- Would like to hear about scope with sampling as well

**Teku**
- Implemented Lossy sampler, but difficult to test with local testnet. Currently just log results and not updating fork choice
- Implemented data column gossip validation

**Nimbus**
- Upstream c-kzg to latest
- Started Lossy sampling but not much progress recently
- Discovered some issues with spec-tests, will likely be fixed in 1.5.0-alpha-4
-
### Devnet-2 spec

No active devnet testing

Features and dates for next devnet?
- **Gajinder**: Are we going to do sampling for the current slot? Is this how it would behave when we go live?
- trailing fork choice was for sampling which may not be included
- no change to fork choice if we exclude sampling

Are we excluding Sampling for next devnet or production?
- Francesco will refine and update the spec PR with regards to fork choice updates

New devnet spec: https://notes.ethereum.org/@ethpandaops/peerdas-devnet-1

### Spec test release soon

Mostly KZG updates and should not impact everyone much
**Nimbus:** would be good to include MetaDataV3 PR in the release

ACTION: Hsiao-wei to merge and include in the release

Note: Next (few) devnet will NOT have sampling changes included

### Spec PR for custody groups (decouple subnet from das-core, proposal from Pop)

client teams generally agree with it, Prysm suggests to target spec alpha-5

### Proposal to make this call weekly instead of biweekly, and moving time

Changing time makes it hard for APAC implementers to join

No one on the call feels that we should reschedule this

### Franceso's new documentation to exclude sampling

https://hackmd.io/@fradamt/no-peer-sampling

Potentially no peer sampling in devnet testing, just to help with iteration cycles, and potentially ok with no peer sampling in production

Prysm: not having sampling will simplify for more clients, but concerned that adding peer sampling may be harder later (requires a hard fork)
- It's not a last minute idea, SubnetDAS was something that's been considered for a long time
- It's mainly to help with implementation cycles, we could go live with sampling if we feel that it's easier later. This is an option to consider.
- The goal is to ship something soon, with some scalability improvements.
Loading

0 comments on commit 00cf257

Please sign in to comment.