From 63a5cd8feab59492425edce5b6aab74759316510 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 11:01:04 -0400 Subject: [PATCH 01/17] Create Meeting 01.md --- Breakout-Room-Meetings/eip-4844/Meeting 01.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 01.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 01.md b/Breakout-Room-Meetings/eip-4844/Meeting 01.md new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 01.md @@ -0,0 +1 @@ + From 3e8974c2ef9ae004b6c2a3e80cf072434b2a9369 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 11:01:38 -0400 Subject: [PATCH 02/17] Create README.md --- Breakout-Room-Meetings/eip-4844/README.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 Breakout-Room-Meetings/eip-4844/README.md diff --git a/Breakout-Room-Meetings/eip-4844/README.md b/Breakout-Room-Meetings/eip-4844/README.md new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/README.md @@ -0,0 +1 @@ + From 4d8ab1c104fb285ad45db5ce0c8f85960b3bfa9c Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:41:58 -0400 Subject: [PATCH 03/17] Update and rename Meeting 01.md to Meeting 013.md --- Breakout-Room-Meetings/eip-4844/Meeting 01.md | 1 - .../eip-4844/Meeting 013.md | 63 +++++++++++++++++++ 2 files changed, 63 insertions(+), 1 deletion(-) delete mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 01.md create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 013.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 01.md b/Breakout-Room-Meetings/eip-4844/Meeting 01.md deleted file mode 100644 index 8b137891..00000000 --- a/Breakout-Room-Meetings/eip-4844/Meeting 01.md +++ /dev/null @@ -1 +0,0 @@ - diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 013.md b/Breakout-Room-Meetings/eip-4844/Meeting 013.md new file mode 100644 index 00000000..012c0006 --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 013.md @@ -0,0 +1,63 @@ + + +# EIP-4844 Implementers' Call #13 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/716) +### Date: Jan 31, 2023 +### [Video Link](https://youtu.be/O1LLyKIMHUM) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.yo0u0frgagsa) + +### Notes + +* Updates from interop + * Had participation from every client except for Nimbus + * Client interop with all sorts of combinations + * Did some spamming of the devnet as an appetizer 🙂 + * Lighthouse had a couple sync related bugs that they made fixes to + * Besu is connected externally to Devnet and are progressing + * Have some problems with some blocks that they are addressing and hope to fully join the devnet in the next few days + * Teku joined on the very last day and are following the chain correctly, but they were accidentally deleting the blobs that were being finalized (now fixed) + * Nethermind is still working to sync with lighthouse as their primary priority +* KZG Ceremony Output format for clients + * Hex-encoded with newlines + * Believe this is the same format that c-kzg already uses +* KZG Libraries status update + * Decision: Changing APIs so that clients just pass in bytes and the KZG library takes care of everything + * Decision: switching go-kzg to use Gnark backend for the library, given Gnark has been audited + * Have some audits coming up, so going to gradually slow down the pace of changes +* [Transaction Pool updates](https://gist.github.com/karalabe/e1c4e4c2a226926498cc9816d383cecb) + * A number of open questions and it would be good to have this ironed out AND have some tests that implement attack vectors to ensure we have some levle of compatibility + * Agreed that the transaction pool will not contain zero blob transactions but not for it to be a consensus pool change + * Should we bring up the issue of zero blob transactions on ACDE? + * Yes + * Discuss on ACD - what is the right way to test this? +* adding dataGasConsumed to the tx receipt format + * Perspective is that we should return this as part of the receipt, but not planning to change the consensus objects + * Open a PR on the json-rpc spec +* Blob/block sync decoupling + * Terrence reviewed and left some comments + * Yasick will come back to it soon + * This affects the cryptography layer quite a bit - have we decided we’re fully going for this? + * Decision: reached consensus at Interop + * Dankrad / Roberto + * Both feel like this is somewhat unnecessary + * Will only provide incremental gains + * All based on people’s intuitions + * Decision: we should talk about this on the call on Thursday + * Could have intermediate solution where the proposer would sign the fragments of the blobs, which wouldn’t require us to change the cryptography + * Dankrad: if we do this chang, we might as well change the cryptography so we get a bunch of nice cryptography things + * Even if we do change the crypto, not going to make the crypto more complicated +* Bandwidth/networking considerations + * No real input here +* Multiclient Sync + * Lighthouse was trying to sync with Teku but they had an issues there; Lighthouse seems to be ratelimiting Prysm - seanis still trying to dig in there +* Blob Transaction hashing + * There is a broader conversation going on around moving the EL over to SSZ entirely - some discussions and proposals that have popped up on the discord + * Proposal are around moving all the transactions within a block + * https://notes.ethereum.org/@vbuterin/transaction_ssz_refactoring +* Devnet transaction spamming +* Breaking Spec changes & devnet 5 + * Goal is to get breaking spec changes in over the next two weeks (before mid-Feb) + * Then aim to get a devnet-5 two weeks after that +* Client & testing updates From 208bda5e329647354b4e7c6148f6176a4e19b7e6 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:42:37 -0400 Subject: [PATCH 04/17] Create Meeting 014.md --- .../eip-4844/Meeting 014.md | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 014.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 014.md b/Breakout-Room-Meetings/eip-4844/Meeting 014.md new file mode 100644 index 00000000..cc389483 --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 014.md @@ -0,0 +1,67 @@ +# EIP-4844 Implementers' Call #14 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/718) +### Date: Feb 7, 2023 +### [Video Link](https://youtu.be/vQGk9FDs_CM) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.tyz3rvf5q08q) + +### Notes + +* [Introduce Deneb to remove EIP-4844 references beacon-APIs#289](https://github.com/ethereum/beacon-APIs/pull/289) + * Clients should already have this implemented in order to participate on Devnet + * Just about getting the spec updated, so we can work on top of it with other beacon API changes that will be necessary for block and blob decoupling + * This PR just need a rubber stamp to merge + * After that, can work to add the more information re: decoupling + * For signatures + * For validator behavior + * Sean @ Lighthouse will implement today / early this week +* [Add API to retrieve blobs sidecar beacon-APIs#298](https://github.com/ethereum/beacon-APIs/pull/298) + * Need to come to consensus, but not blocking interop (this is user facing) + * Terence @ Prysm is going to follow up with this to merge +* [EIP-4844: Free the blobs consensus-specs#3244](https://github.com/ethereum/consensus-specs/pull/3244) + * During interop week, there was rough consensus to decouple block and blob + * Have been iterating on the design doc and are now moving from design doc to PR + * Asking folks for review on the PR, so we can come to consensus + * This is the biggest blocker before Devnet-5 + * Client teams will need 2-3 weeks to implement + * Jesse: is this strictly necessary to do the decoupling work now? + * Going to be easier to productionize decoupled design then start with a coupled design and then move to a decoupled design + * Decoupled design is also more flexible, which helps us with the fact that it’s hard to gather information about what this looks like on mainnet + * Hard to model what a dynamic and diverse network looks like when we’re making + * Answer: at the current blob sizes, could ship without this, but once we ship it, there will be more challenges in modifying it + * Blob decoupling is a lot of consensus layer work and the SSZ is a lot of the execution layer work, so not generally overlapping + * EF clients are working on the blob mempool - can use this time for decoupling + * Tim: does anyone on the client teams feel strongly they shouldn’t decouple? + * Roberto: If consensus teams are comfortable with it, we should be comfortable + * Re: SSZ, will be some consensus layer changes + * Discussion about verification of KZG proof with cryptography library + * Have solved the changes on the KZG cryptography library side + * Getting more data on the verification costs and whether we can move forward + * LIkely that we will be able to move forward + * We won’t be able to do aggregated proof on the mempool + * Likely that the difference between the two is very minor + * Transaction pool discussion + * Do we want to have a limitation on single blob per transaction? + * Started here thinking about aggregated proofs for max one blob per transaction + * Originally introduced aggregated proof technique just for the mempool to be faster + * If we are switching to one blob per transaction on the mempool, we less likely need aggregated proof + * Tim going to follow up with Geth on the transaction pool design + * Given the number of blobs is smaller than the number of cores, should be able to be parallelized well with multithreading and doing on multiple cores + * Shouldn’t be a part of the spec, but do think that if libraries can multithread something, they should +* Devnet-4 - how are clients tracking? + * Besu + * Now following devnet-4 chain correctly + * Locally they are now able to build blocks without any blob transactions + * Still having issues validating blob transactions that they are working on + * Should be the last issue before they can fully join devnet-4 as a supported client + * Lighthouse + * Just merged a fix for serving finalized blocks that have blob transactions + * Previously couldn’t sync by a lighthouse node by range + * Prysm + * Working on decoupling, doing implementation + * Nethermind + * Good devnet-4 implementation + * Just synchronized with lighthouse which was the last CL client we’re trying to synchronize +* Etan + From 56f98e094008a0210c570d8ea27c61a66beced3a Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:43:17 -0400 Subject: [PATCH 05/17] Create Meeting 15.md --- Breakout-Room-Meetings/eip-4844/Meeting 15.md | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 15.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 15.md b/Breakout-Room-Meetings/eip-4844/Meeting 15.md new file mode 100644 index 00000000..bf9064ab --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 15.md @@ -0,0 +1,77 @@ +# EIP-4844 Implementers' Call #15 #722 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/722) +### Date: Feb 14, 2023 +### [Video Link](https://youtu.be/poTKRryqrzU) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.451zbopl8rnb) + +### Notes +* +* Spec updates + * [EIP-4844: Free the blobs consensus-specs#3244](https://github.com/ethereum/consensus-specs/pull/3244) + * Network tests looked really good + * Goal is to have this fully done by Thursday so we can get any final notes on ACDE + * Plan is to ship this in the consensus-specs release on Friday + * Going to flag on the ACDE to let folks know and “ask for any problems” + * Basically exactly on the schedule set on interop + * Do any clients have this implemented? + * Prysm started, but stopped as final tweaks were getting done + * Terence is going to pick it up this week again + * Going to do another old vs. new simulation with additional framework + * 0-blob transactions and how it relates to [ETH68](https://ethereum-magicians.org/t/eip-5793-eth-68-add-transaction-type-to-tx-announcement/11364/2) + * Right now, when we use a type 4 transaction, we always require it to have a blob when it enters the mempool, but don’t require this in consensus + * Should we add the number of blobs to the announcement + * Not sure we need to include the transaction type - only needed for ETH66 + * May be able to include just the number of blobs + * Lukas: don’t like having the number of blobs because it’s now starting to leak out everywhere - could we instead use size? + * Mofi: point of using size was brought up at Bogota and decision to use the transaction type was because the cost of verifying the transactions could be incorporated (not just the size). For instance, if you have a large transaction that wasn’t a blob, then you’d you wouldn’t know this. + * Tim: does anyone see an issue with using size instead of type or data gas? + * Dankrad: geth won’t broadcast transactions over a certain size + * Dankrad: set rule to be don’t broadcast transactions >128kb + * Marius: we should disallow 0 blob transactions + * Enables us to have much better structure in the code + * Don’t have all these types that do the same things + * Dankrad: does this still exist if we also want SSZ transactions? + * Dankrad pushes for filtering transactions based on size vs. by the type + * Observation: transaction pool and transaction types are hard to get everyone on the same page about + * Recommendation from Tim: fully ban zero blob transactions + * Proto: for adding it as a tx-pool only rule, + * Marius: supportive, but wants it as a consensus rule if we have the restriction + * Decision: Adding this to ACDE agenda + * If you disallow zero blob transactions, do we do that + * In TX Pool + * In consensus + * If you do allow them, how you discriminate between 0 blob and 1+ blob transactions in mempool, validation, broadcasting, etc + * [SSZ List[T, 1] / Optional for Address: Update EIP-4844: Use SSZ Optional for Address EIPs#6495](https://github.com/ethereum/EIPs/pull/6495) + * SSZ unions are not standardized right now / unclear whether they will be + * Proposal from Etan is to replace the union with a list or optional type + * This avoids introducing the union discussion and getting blocked on that + * Dankrad: pushing back on the whether union is not standardized right now + * Sean: in favor of justing using what’s in the SSZ spec, seems as likely to change as doing something else and is already implemented + * Decision: discuss on PR and make a final decision next week + * 16 million blobs capacity: Would like to understand the design space + * Dankrad: for serialization, doesn’t matter, only matters for merkle proof + * Etan: theoretical limit is very unlikely to be met + * Decision: Dankrad going to tune this to an upper limit + * [HTR based signatures: 4844: use hash_tree_root for tx hash EIPs#6385(https://github.com/ethereum/EIPs/pull/6385) + * Right now, we are using keccack of transaction that is being signed for hash + * Mostly a discussion for SSZ tomorrow + * Goal is to optimize the tranasction to be a part of the SSZ transaction tree + * [Add blob signing endpoints #302](https://github.com/ethereum/beacon-APIs/pull/302) + * Adds core components to engine API + * Generally looking for feedback and would love folks to take a look +* Client progress + * Besu + * We are now feature complete + * Asking to join devnet-4 testnet + * Lighthouse + * Working on decoupling + * Prysm + * Working on decoupling and making their DBs more reasonable + * Teku + * Released the new image on Friday for devnet-4 with some fixes around sync and blob handling on DB + * So far so good, synced from genesis + * Starting to work on decoupling + * Nethermind + * Waiting for the SSZ discussion tomorrow From d935dfdd6519c65f8762d3ac8973ff16768b6f96 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:43:28 -0400 Subject: [PATCH 06/17] Rename Meeting 014.md to Meeting 14.md --- Breakout-Room-Meetings/eip-4844/{Meeting 014.md => Meeting 14.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename Breakout-Room-Meetings/eip-4844/{Meeting 014.md => Meeting 14.md} (100%) diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 014.md b/Breakout-Room-Meetings/eip-4844/Meeting 14.md similarity index 100% rename from Breakout-Room-Meetings/eip-4844/Meeting 014.md rename to Breakout-Room-Meetings/eip-4844/Meeting 14.md From 890b2f268d020ac7af80d44c27f9288b9af18d6f Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:43:44 -0400 Subject: [PATCH 07/17] Rename Meeting 013.md to Meeting 13.md --- Breakout-Room-Meetings/eip-4844/{Meeting 013.md => Meeting 13.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename Breakout-Room-Meetings/eip-4844/{Meeting 013.md => Meeting 13.md} (100%) diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 013.md b/Breakout-Room-Meetings/eip-4844/Meeting 13.md similarity index 100% rename from Breakout-Room-Meetings/eip-4844/Meeting 013.md rename to Breakout-Room-Meetings/eip-4844/Meeting 13.md From 953c374edf35af872e6eca104c290859391eb8ab Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:44:16 -0400 Subject: [PATCH 08/17] Create Meeting 16.md --- Breakout-Room-Meetings/eip-4844/Meeting 16.md | 64 +++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 16.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 16.md b/Breakout-Room-Meetings/eip-4844/Meeting 16.md new file mode 100644 index 00000000..fa0a1040 --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 16.md @@ -0,0 +1,64 @@ +# EIP-4844 Implementers' Call #16 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/726) +### Date: Feb 21, 2023 +### [Video Link](https://youtu.be/hWcpSlwNTBU) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.ngbel4ohs4ye) + +### Notes + +* Spec updates + * [New CL spec release](https://github.com/ethereum/consensus-specs/releases/tag/v1.3.0-rc.3) + * Primary inclusion is the free the blobs change (go Jasik) + * Some cryptography modifications + * Breaking change: excess data gas field is moved to end of transaction data + * Spec tests are out, so anyone can test it + * Beacon APIs need an update for signing blobs + * [Active PR](https://github.com/ethereum/beacon-APIs/pull/302) that will be discussed on Thursday + * Jesse: how are you feeling about spec? + * On consensus layer, feeling good + * Only big question is whether we need to change the engine APIs to handle the mempool stuff + * Danny is a strong “no” on this + * [KZG library refactor](https://github.com/ethereum/c-kzg-4844/pull/123) + * Moves library to doing isolated proofs rather than aggregated proofs + * Now we can verify blobs with individual proofs OR batch verify blobs with slightly faster verification + * After merging the spec, we started working on this on the implementation + * Base code of c-kzg now implements the new spec + * Python, Golang, and Java bindings updates + * Still work to be done on C#, Nodejs, and Rust bindings + * In particular, there is work that needs to be done on the Nodejs side for c-kzg + * Terence: are there spec tests for these bindings? + * Want to implement tests for each functions + * Likely going to have them in the spec tests + * George agrees that doing this in spec tests would be nice but py-acc will be very slow, so need a new library for BST + * Can’t use Milagro because it doesn’t have the group functions + * Kev is working on getting an API for arkworks and then we’ll have it + * Jesse: Dan is transitioning out so need someone to maintain bindings + * Dapplion from Lodestar is looking into it and will likely be able to take care of it + * Zero blob + * Ansgar going to land PR on EIP in time for ACDC on Thursday + * Ongoing discussion in the Etheruem Magicians thread [here](https://ethereum-magicians.org/t/eip-4844-shard-blob-transactions/8430/28?u=true&=true) + * Tim’s feeling is makes sense to apply the restrictions Roberto suggested + * Replace only w/ equal or > # of blobs, plus data gas & regular gas bump. + * Blob-holding txs should only be replaced by blob txs consuming at least as much datagas + * There can only be one blob-containing tx per account. + * Roberto: feels like we need to make this somewhat formal to make progress + * Client updates + * Prysm + * Focused on implementing the free the blobs PR - pretty significant change + * Lighthouse + * Working on the free the blobs PR, same as Prysm - considerable change + * Two weeks seems OK, but wouldn’t promise it + * Teku + * Started working on the decoupling - don’t have a timeline yet + * Lodestar + * Has also started working on decoupling as well + * Will handle the node bindings now that the implementation is complete + * EthereumJS + * No major updates + * Merged branch and synced devnet-4 + * Hoping to work more on rust-kzg and implementation over the next couple weeks + * Nethermind + * Still on devnet-4, no major updates + * Plan to update KZG bindings From fc2e027fe32a76051caa65d006ecafcf149469ee Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:44:48 -0400 Subject: [PATCH 09/17] Create Meeting 17.md --- Breakout-Room-Meetings/eip-4844/Meeting 17.md | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 17.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 17.md b/Breakout-Room-Meetings/eip-4844/Meeting 17.md new file mode 100644 index 00000000..696a5a1a --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 17.md @@ -0,0 +1,70 @@ +# EIP-4844 Implementers' Call #17 #732 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/732) +### Date: Mar 7, 2023 +### [Video Link]( https://youtu.be/8hDlg-x6MjE) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.7ln6lr3j4ti6) + +### Notes +* Spec updates + * Decoupled blobs + * Gajinder - what is the exact signing flow? + * We introduced the blindness flow and realized it has the nice side effect of not sending beacon traffic + * Plan is to continue the conversation [on the PR directly](https://github.com/ethereum/beacon-APIs/pull/302) + * This problem doesn’t really exist if you are outsourcing the builder - only exists in a fallback scenario + * Since people are using an outsourced builder, and long term if we have PBS, maybe this is less of an issue to go with this by default + * If we’re only signing blinded blobs, we might want to update the consensus spec because it still says we’re still signing the whole sidecar + * Danny: don’t think it’s necessary to include this bc the spec doesn’t know these details today + * Having the them combined if we go to the blinded simplifies the handling of the decoupling PR + * Trying to get this done for final discussion on Thursday or merge before Thursday + * Danny - local heuristics on when you start requesting this new information + * When you get the block, do you immediately request or wait some portion of the slot until you request, etc + * Design decision around which heuristics you use to do when + * No right answer, but something for people to be considering - main other point of uncertainty + * Terence: not a blocker for the next devnet, will take us a while to figure out when to request and when to wait + * **For initial version, wait patiently for gossip and hope we get it, if we don’t get it request at 2s market** + * This isn’t something that would make it into the spec - local design decision + * PR that [aggregates to proofs](https://github.com/ethereum/EIPs/pull/6610/files) - need a review + * Crypto library + * All of the bindings support the new KZG interface - in the process of polishing all bindings + * We have an audit in a month, so planning to make final changes in next two weeks, then freeze entire codebase + * Things are moving smoothly + * SSZ + * Complexity of SSZ EIPs is still growing and not finished yet + * Wouldn’t want to make a change to transaction type, unless we agree to SSZ before + * Should assume that 4844 is moving forward independently, then if we agree to do SSZ, we can update 4844 + * Trying to couple / keep both efforts in sync is the highest overhead and least valuable thing + * Decision: keep them decoupled for now, if we decide to couple them, deal with it at that point + * Transaction pool + * Ideas we discussed last time were in ETH Magicians thread - going to assume that means they are not controversial and we can go ahead and add them + * Nothing on the geth side + * Goal is to get all on the same page on transaction minimalism by next week ACDEs + * Client updates + * Prysm + * Shanghai is priority + * Terence is implementing free the blobs and then will launch a Prysm only devnet, then we will be ready to launch a multi-client testnet + * Lighthouse + * Have a few people working on 4844 even while we’re doing Capella + * Still have work to do on the implementation before we have someting working + * Over the next month, working on a local devnet, then focus on interop + * Nimbus + * Henri is continuing to work on 4844 and has been making progress on the decoupled blobs implementation - coming along + * All leads to a much nicer implementation as a side benefit + * Targeting pairing up with other clients sometime this month + * Teku + * Already started the decoupling PR + * Not currently at full speed, but planning to get back to full speed soon + * Makes sense to have something by end of month to start playing with other clients + * Lodestar + * Likely to be ready for a devnet at the end of this week + * Geth + * Working on getting a tool for SSZ - lot of other stuff going on + * Want to have more specialized transaction types + * Not sure if people agree with the assumption that transaction types should be getting more specialized + * Nethermind + * Haven’t started work on the transaction pool yet + * Cadence + * Should we switch to bi-weekly for the next while? + * Two weeks from today, we can meet together and check where the implementations are at / decide if we want to move to a multiclient devnet + * Decision: moving to bi-weekly From 534b72681c09917092081b4d61ad54f67f9053c2 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:45:22 -0400 Subject: [PATCH 10/17] Create Meeting 18.md --- Breakout-Room-Meetings/eip-4844/Meeting 18.md | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 18.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 18.md b/Breakout-Room-Meetings/eip-4844/Meeting 18.md new file mode 100644 index 00000000..3991e1b7 --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 18.md @@ -0,0 +1,35 @@ +# EIP-4844 Implementers' Call #18 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/739) +### Date: Mar 20, 2023 +### [Video Link](https://youtu.be/gdy5svsnFrM) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.cj7cnyhygaz0) + +### Notes +* Stuff to discuss: Spec stuff, fee market, where teams are at. +* SSZ: From ACD seems unlikely to have SSZ migration alongside 4844 in cancun, so probably makes sense to split those up. That said we are introducing SSZ into 4844 so we still have the question of which format to use. Optimize for storage size of tx or for proof verification of transactions? These result in different encodings. Did not reach agreement on ACD, but that’s roughly where things are at. Would like whatever we do be forward-compatible with the broader roadmap. + * Does changing the ssz layout involve a lot of work if we change it in a month? Probably not, biggest change would be if we require merkelization in EL as the current spec doesn’t require it. + * Let’s leave the tx type as specified for now, we can make the change after we have broader SSZ consensus. + * https://eips.ethereum.org/EIPS/eip-4844#new-transaction-type +* Fee market analysis: https://ethresear.ch/t/eip-4844-fee-market-analysis/15078 + * Good post, and something we will want to get right as early as possible. Terence Summary: Given the spec today, it would take 1 - 1.5 years for usage to reach the target to reach threshold. Even without that we would want to deter spamming, so do we want to raise the min price? Post assumes gas is inelastic but would argue it’s more elastic than indicated. + * Re: pricing what to do when more blobs than space in block: Mofi: The priority fee from 1559 serves the same purpose. + * Proto: Strong statement that blocks won’t be full. Today the only reason they use as much as they do is they are already maxing out gas in ethereum. Rollups are paying well over 90% of fees towards data already, so we know users are ready to pay a premium for data. No reason to think that those fees wouldn’t go towards using all those resources. Will be unstable for a week or longer, but not >1 year. Prefer not biasing fee markets too much with things like minimums.. Tim: Wonder if there’s a way to figure out true economic cost of this data. But this is hard since we don’t control eth/usd minimum exchange rate. + * Is there any strong opinions on whether there should be a higher minimum? Proto: I think a higher one is fine if it’s well justified and accounts for costs. But even if there is a spike in throughput it will pay for it in price adjustments. If consistently below target, sure blobs are cheap but it’s within our ability to handle it and in 18 days it’s gone again. + * From the chat comments, Mofi noted that Ansgar had a strong view that there should be no minimum because users shouldn’t have to pay for data gas that the network “already has”. + * Jesse: Are we worried we’ll be either at the minimum or hit the max, e.g. the 1559 rules might not work? Proto: curve will adjust to the blob throughput. The adjustment doesn’t account for removal of blobs but if you look beyond 18 days it is just a small change in price due to excess blocks. This discussion has been had before in original EIP that changed it from base fee like mechanism. + * Tim: Most worrisome thing the post is if it goes for >1 year at min price. + * Proto: Another thing to think of is the Shanghai DoS attacks; there is this persistent problem with syncing because of it. But because blobs are pruned after 18 days there’s no more obligation to ethereum today. It’s a very different long term cost than regular gas usage. + * Saulius: We might be worried someone will spam at full capacity of what the network will handle. But personally don’t see how there would be too much damage from fees too low. Network will adjust. + * Tim/Roberto: Based on discussion no need to take any action on min fee for now, but let’s continue discussion on the fee market analysis post. Please add your thoughts there. +* Client dev progress + * Terence: Still running tests on decoupling blocks and blobs. But majority of resources are still in Shapella right now. In one week we’ll have more resources, multi-client testnet for 4844 might be ready in 2 weeks from now. + * Lodestar: Ready in the sense that without including changes in blob signing endpoints. We are independently fetching & signing the blobs. So ready for multiclient devnet. + * Lighthouse: Made a lot of progress on decoupling but still don’t have something fully workable. Our goal is to get that ready this week, something that is ready for testing locally. + * Nethermind: Have something ready that can work with lodestar + * C-KZG work has gone well, asking client teams to finalize code before April 5. + * Teku: Are not yet full speed on 4844, but we are progressing a bit. Will get back to full speed this week. + * Tim: Should we prioritize a longerlived devnet? Maybe that ends up serving for a Cancun devnet where we can potentially add other stuff. + +See everyone in 2 weeks! From fdaa5731e4e0dd65ee90f752fc9f38e1f80ebb6a Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:46:14 -0400 Subject: [PATCH 11/17] Create Meeting 19.md --- Breakout-Room-Meetings/eip-4844/Meeting 19.md | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 19.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 19.md b/Breakout-Room-Meetings/eip-4844/Meeting 19.md new file mode 100644 index 00000000..f386c532 --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 19.md @@ -0,0 +1,28 @@ +# EIP-4844 Implementers' Call #19 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/745) +### Date: Apr 3, 2023 +### [Video Link](https://youtu.be/k6TDcU2aBDw) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.xdp8lfakhesv) + +### Notes + +* Mofi: EIP spec update [pull 6791](https://github.com/ethereum/EIPs/pull/6791) to validate excess data gas. This makes sure the excess data gas field in headers are validated correctly. We will get this merged upon approval. +* Client team progress. Where are we in terms of readiness, does it make sense to target a devnet launch on top of Shapella? + * Prysm: Terence: working on implementation mostly on free the blobs which is the one thing taking the longest. We can now do local testnet between prysm & geth, can process blobs, bobs by root & blobs by range implemented & tested. Now working on initial sync from genesis. After that we are pretty close to multi-client devnet. Main blocker is that initial syncing. Target devnet in a few weeks is fairly possible. + * Lodestar can do devnet locally w/ ethereum js. + * Lighthouse: at the point trying to get something working locally but not quite there yet. A few features such as caching smarter, mechanic off single block/blob lookup in different scenarios, etc. But close to have something working. 2 weeks might be when we have something running. + * Marius: For geth, not started looking into it but can ujse mofi/roberto fork. Peter looking into tx pool for blobs. Marius Working on SSZ library with casey (?) from Prysm team, which looks good now. We have prerequisites down and should get someone on 4844 soonish. Great we have the Mofi/Roberto fork and will build on that at some point. Tim: Does peter plan on wrwiting something up on tx pool impl? Would be great if had documented all the solutions to the problems from the workshop. Marius: Yes in his PR he has a brain dump of ideas in [comments in the code](https://github.com/ethereum/go-ethereum/blob/8ea65c59c13fd5a8069ff074d227656549290bf3/core/txpool/blobpool/blobpool.go#L128). + * Do txpool things belong in spec? What about datagas field in receipt? Marius: For txpool, probably no. Better to have different impls for DoS prevention. Datagas should be in spec. Lukasz: disagree with some. Overall for security & performance reasons, we have converged to have more similar rules than geth implementation. Tim: At least if we have the code well documented, people can use that as the docs. + * Nethermind: a couple of weeks seems feasible for next devnet, free the blobs mostly done, a few things backloggged + * Teku: Same, we are working on things in parallel, mostly on orchestration of gossip of blobs & lookups / arrival of block, & on API signing flow. If we can’t join the first version we’ll be ready for the second one. + * Erigon: Roberto has a draft implementation but have only started looking at changes & understanding of them. Started merging some but not entire PR. Roberto: Plan to get it the fork merged with upstream this week. + * Nethermind: Alexey: we are basically ready. + * Besu side: FabioWe are devnet4 level so need to check for what we need to do after that. If we can target 2 weeks it depends on priority of things we are working on at the moment. Need to check with the team. + * Mofi: The next devnet should be long-running so that client teams can join at leisure. Tim: Agree that probably makes sense. Ideally we’ll be in state where devnet is running or near running by next call. Potentially we can get geth and erigon & eth js running off of the branches not necessarily master. But a free the blobs devnet with 2+ EL/CLs that are stable we can gradually add more clients and keep things running. Prysm / Lodestar … Can we do a week for now? Terence: may need another week, but feel free to start without us. Might have issues with initial syncing. Tim: Also this is easter weekend so ppl might be away. Let’s aim for early next week to try & start setting this up w/ geth, do changes to Erigon, this week, early next week try to launch it and see how it goes. Goal: have at least an attempt to launch a devnet! Best case we have a couple clients going and others can go in, worst case we have some things identified to debug. We’ll also obviously have the CL call before all core devs can discuss things that pop up. +* Receipt datagas field: let’s put it in the execution API. We wanted to bring it up to the EL call / all core devs call. Tim: Once we have this PR up we can link to it from the EIP itself & mention the changes to the receipt are tried that. Acolytec3: will try to get a PR up today or tomorrow. Will keep us posted in sharding channel of Eth R&D. +* Roberto: Do we want to implement the 2 txpool tweaks for devnet? Tim: Yes let’s try and get prototype implementations and we can do spam tests. +* Timeline for next fork? Tim: Biggest thing is the work for 4844, last ACD there was a strong desire not to add anything that would significantly delay the EL side. E.g. SSZ, and some similar concerns around EOF but not clear where the consensus is going to land there. Every time something big comes around the concern is will it delay 4844. +* Alexey: what is the feedback from the L2s? Tim: from optimistic side, Optimism has obviously invested a lot in getting this to happen, so has Coinbase. Arbitrum also providing very positive feedback. From ZK side we’ve checked it’s usable for them, but they may not priority it as #1 but none have objection / incompatibility, but perhaps just not top of their roadmap. If there are any ZK L2s that have problems with it now would be the time to reach out. So far nothing critical / blocking has come up. Terence: We are implementing it from the Arbitrum side, but worth discussing more about datagas / parameters to use, there is that research thread about it. Arbitrum labs has posted its thoughts about it: https://ethresear.ch/t/eip-4844-fee-market-analysis/15078/9 Tim: Should we discuss at upcoming ACD / CL forum? Terence: I don’t think the L2 reps show up at these necessarily. Tim: We can pass it along then to get more feedback from client teams for next time. +* Chance blob size/count/block would change? Tim: Would be extremely surprised if things were changed upwards from 2 blobs target max blobs 4. If there were to be a change it might go to 1 target 2 blobs, but would be very surprised otherwise. Roberto: One simplification might be to limit to 1 blob per tx. Not sure if that’s important, don’t have strong opinion. Proto: This is something that might be important for zk rollups, not so important for us. Terence: Not so important either. From f11cfb6aebddaa6f0e345d553eb4f6d220a890cd Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:46:50 -0400 Subject: [PATCH 12/17] Create Meeting 20.md --- Breakout-Room-Meetings/eip-4844/Meeting 20.md | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 20.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 20.md b/Breakout-Room-Meetings/eip-4844/Meeting 20.md new file mode 100644 index 00000000..2892cfaa --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 20.md @@ -0,0 +1,60 @@ +# EIP-4844 Implementers' Call #20 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/755) +### Date: Apr 17, 2023 +### [Video Link](https://youtu.be/oCqfxb5CWAI) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.h6sis7kl7ys4) + + +### Notes + +* Spec updates: + * Small one-value change by Mikhail in error code fixing small discrepancy: https://github.com/ethereum/execution-apis/pull/399/files + * getPayloadV3 & getBlobsBundleV1 merge. Mikhail: these were introduced separately because easier to prototype, but since we’re heading towards spacing out engine API changes for cancun this is one of the outstanding questions to resolve, & question was raised in discord recently. This is basically same process as obtaining payload & blobs, and at first glance it seems there’s no need to keep separate (get payload can return both). If we merge we would have to more extensively test, so not clear if it’s in scope for devnet. Gajinder: don’t see need to keep separate. (Nobody advocating to keep them separate). Tim: my preference is to not include it in next devnet but have PR open for it to do multiclient testing. Roberto: that might work against having devnet be persistent. Tim/Gajinder: we might have better chance of next devnet being persistent. + * Tentatively in scope for devnet 5 (though need more feedback from CL devs, not many are on call today) + * Gajinder has 3 PRs to highlight + * https://github.com/ethereum/execution-apis/pull/392 add proofs to transaction wrapper. + * Mofi: Had something like this before free the blobs where proofs generated on CL side, but got rid of it to minimize time for block building. Is this still a concern / would it lengthen time to build the blocks? Gajinder: Proofs are coming through tx wrapper and come in the serialized tx so no need to compute on the EL side. Mofi: Main issue before was aggregated proof computation which is no more. Flcl42: do we still need to verify proofs on execution layer side or can we just send to CL to spend less time on tx verification? Gajinder: since EL broadcasts better to have checks on EL side. + * Mofi: Adding proofs is required to decouple the blobs so we should make this change for devnet v5. + * Should add for devnet 5. + * https://github.com/ethereum/EIPs/pull/6610 + * Updates to remove aggregated proof & other minor updates, already implemented in geth. In scope for devnet 5. + * https://github.com/ethereum/beacon-APIs/pull/302 Extend current endpoints to prove & publish + * Extrends produce/publish APi endpoints to use block contents rather than the block. It is sort of an optional thing for devnet 5 to push the implementation forward. Optional communication between beacon node & validator. (Lodestar has implemented it, Teku started implementing it. ) + * Optional for devnet 5. + * These are in scope for devnet 5, but not yet implemented in geth, should be easy to add. + + + Tim: Should we then just merge getpayloadv3/blobsbundlev1? Gajinder: change on the CL side is not a big deal I am OK with doing merge before V5. EL side would be caching all the data anyway so could return the full content in getPayloadV3. Any other CL client thoughts? Terence is not on the call but we should ping him. + +* Devnet 5: + * https://hackmd.io/@inphi/HJZo4vQGn + * Nimbus: have sync working, finishing up gossip. Last PR probably going out today/tomorrow and then some tying up loose ends. Guessing 1-2 weeks. + * Lighthouse: + * Nethermind: 2 weeks timeframe hopefully. Join after devnet 5 launch. + * Ethereumjs should be able to join in + * Besu needs a week or so to be in part for devnet 4. + * Tim: Stand up by CL call? + * Mofi: Probably not, next monday or tuesday would be a better date. + * Tim: Blockers to figure out this week or is it just implementing? + * Mofi: It’s implementing and availability of devs here to do the interop. + * Tim: In that case let’s check in on this in the CL call and aim for early next week going live. + * Let’s keep 4844 devs only call for 2 weeks, will discuss whether to shut down devnet5 and go to devnet6 + +* Testing: + * Lukasz : Question about testing, are there hive tests? + * Mario: Working on them, for engine API we still have to work on it. PRobably next week we’ll have something to test changes on hive. + + +* Mempool: + * We have been punting on making a decision on rebuilding blob txs on reorg. Danny: wanted to make sure we haven’t dropped this. + * + * Peter would like to have quality of service so that blob txs could be put back in mempool upon reorg, same as normal txs. To make that happen you have to break barrier between EL/CL a bit more, new payload would have to have access to rebuild full transactions. Danny/Peter spoke about this and if you bypass mempool you don’t have blobs available to rebuild the txs. This does seem like an unknown point around whether there is a change here that should happen. Don’t have discussion points beyond that. + * Peter’s solution was to implement blobs via newpayload + * But, could we instead guarantee only that all blob txs that hit the mempool should be rebuilt? EL can choose to rebuild those txs since it can cache the blobs. Danny: Do think this is a very reasonable quality of service, especially if you think about full sharding design. + * Once you put it in new payload can rebuild if you feel like it, but have broken abstraction a bit. + * **We should loop in Peter / geth team & see if he feels strongly one way or the other. We can potentially cover this on the CL call, especially in the case if the opinion is we should change this.** + * Mikhail: Probably CL can do something about it since it keeps blobs anyway, and could fill the gaps. Not sure what the edge cases / complexity of that will be. Danny: Worry that makes too much of a stateful assumption between layers. E.g. if you come online during the reorg you won’t have the blobs. + * Danny: my opinion is rebuild only if in mempool is simplest and doesn’t make new assumptions required for full sharding. + From a1a7d270e6e9f373606e8a0efab3a92b822f51df Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:47:13 -0400 Subject: [PATCH 13/17] Create Meeting 21.md --- Breakout-Room-Meetings/eip-4844/Meeting 21.md | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 21.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 21.md b/Breakout-Room-Meetings/eip-4844/Meeting 21.md new file mode 100644 index 00000000..3c25824a --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 21.md @@ -0,0 +1,34 @@ +# EIP-4844 Implementers' Call #21 #760 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/760) +### Date: May 1, 2023 +### [Video Link](https://youtu.be/M2pYYEtM3Gw) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.orhz57s01hb1) + +### Notes + +Agenda: Spec stuff, devnet-5, tool for DATAHASH, conversations around libraries/tests for moving this to prod with all bases covered. +* Spec updates: + * Merging getpayload/blobsbundlev1: Is there an execution api update for this? + * Yes: https://github.com/ethereum/execution-apis/pull/402. And it’s part of devnet-5 spec & implementations. + * On last ACDE, we discussed EIP-6475 which introduces optionals EIP type, agreed to move it forward with a few small changes. https://ethereum-magicians.org/t/eip-6475-ssz-optional/12891/17?u=etan-status + * Lightclient: Do we even want ability to create contracts? If not we don’t even need optional field. One might say create behavior we have isn’t ideal. (Could argue there should be a separate tx for contract creation.) Stokes from chat: you could still use create op codes if you really needed to do this. Lightclient: maybe time to show a bit of restraint and not have everything be fully compatible with previous txs types. One argument against is Etan’s idea of having a normalized tx type in which case we need optionals anyway. Idea here is you have one format that can represent all txs in the protocol. Marginally prefer dropping optional. Gajinder: more or less agree that when we implement normalized transactions we could enable it at that time. Lightclient: If we do have a normalized tx type we’d probably have a clear discriminator that this is not a blob tx, so the normalized type would unlikely build from blob txs. Would be good to get Etan’s thoughts on this. Matt/Etan probably have the strongest opinions on this. Tim: We can chat async on the discord, try to get Etan’s thoughts in a day or two and try to get a decision by ACDE call this week. Let’s assume that unless Etan has a strong opinion we will remove. Will not change on devnet 5 but as we get it ironed out we’ll have it finalized for next one. + * EIP-6943: Signature scheme for SSZ. Lightclient: Why have fork id in the domain hash? In this case it looks like it only protects case where competing chain has same genesis and introduces same tx type. Gajinder: In the CL when a new fork comes on, some messages become old and need to be expired & this is the mechanism to expire those. Lightclient: Dont’ think we have that problem in the EL, and if it was wanted we should think about it a bit more. There may be unintended side effects for txs to expire at fork boudnaries. Also enshrining checksum into the protocol is probably something we don’t want to do. To be compatible with CL we could set fork hash to fixed value. Roberto: Sounds like we should get rid of fork version, let’s continue discussion in eth magician’s here? https://ethereum-magicians.org/t/eip-6493-ssz-transaction-signature-scheme/13050/3?u=roberto-bayardo + * Lightclient: More broadly, does it make sense to bring CL mechanism in here into the EL? Or make more sense to define a more EL aligned signature scheme. Imagine a world where we don’t add new tx types but we have this more specific type with a totally different format they have to learn. Unlikely we’ll ever be able to move away entirely from old rlp signature hash. There might be simpler things we can do: imagine that you just compute the hash_tree_root of transaction & sign that w/ tx type added. So there are simpler ways to achieve this. Roberto: Etan’s concern was RLP-encoded tx of same type on different chains could lead to collisions. This is what genesis hash solves. + * Roberto: Hate to suggest but why SSZ at all then and not RLP when it feels like we haven’t figured out the ultimate solution of how to move EL to SSZ? Inphi from chat: One nice thing is ssz lets us access blob versioned hash without leaking the entire tx schema. + * Andrew Ashikmin: Maybe we can add consistent serialization of chain id to prefix to avoid this collision issue. Can then exclude chainid from main serialization. Can make sure this prefix doesn’t coincide with any valid RLP serialization. (Thinking of a way to solve the more limited problem of solving clashes between different chains.) + * Lightclient: Most “correct” thing to do would be to compute the hash tree root of the SSZ, which is roughly what this EIP tries to do, but it brings in CL stuff we don’t really care about. Best and simplest thing might be to compute keccak hash of some RLP serialization of the components. Against keccak hash of SSZ serialization because it is a part-way adoption of SSZ. Would prefer Etan’s proposal or failing back to whatever already exists which is an RLP list. + * Andrew: Agree w/ lightclient we either should revert back to RLP or figure out a proper path to SSZ everything and invest more time to make sure 6493 is a good way forward. + * Justin: Do want to point out that intent behind SSZ adoption EIPs is towards incremental adoption. These half measures are by design. + * Lightclient: What SSZ helps most with is ability to create proofs over pieces of transaction in a contract. With RLP you need the entire transaction. Would like a strong argument for the SSZ signature scheme otherwise probably doesn’t make a lot of sense & should stick with the formats that we already have. + * Tim: Make sense to pause this conversation here and continue discussion on the discord, aim to align overall approach for devnet-6. + * Roberto: Will try to lay out the options that have been discussed in the discord so we can try and hash this out for devnet-6. + * Quick updates on devnet-5? It’s running. + * Tool for blob-hash-getter: https://github.com/ethstorage/eip4844-blob-hash-getter + * Small library able to pull customized assembly code to get data hash and return to parent smart contract, to experiment in rollup contracts to experiment with these ideas. + * Peter raised concerns about the crypto library. + * Tim: Should we have a tracker for these open issues? (ssz, blobs & reorgs, crypto libs, + whatever else comes up) Roberto: think it would help us keep them top of mind to make consistent progress. E.g. think Kev is fixing the go crypto libs but not sure if anyone fixing c-kzg. + * Testing: Mario Vega: Have updates on testing vectors to share. We have a couple of test vectors update:
https://github.com/ethereum/execution-spec-tests/releases/tag/v0.2.5
and
https://github.com/ethereum/hive/pull/759
both for EL clients. Can help you out run any of these vectors if you can provide a docker image if your client. + +githgith From 264be954b2100e8f3140613776d9867dd25c472c Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:47:39 -0400 Subject: [PATCH 14/17] Create Meeting 26.md --- Breakout-Room-Meetings/eip-4844/Meeting 26.md | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Breakout-Room-Meetings/eip-4844/Meeting 26.md diff --git a/Breakout-Room-Meetings/eip-4844/Meeting 26.md b/Breakout-Room-Meetings/eip-4844/Meeting 26.md new file mode 100644 index 00000000..a01342dc --- /dev/null +++ b/Breakout-Room-Meetings/eip-4844/Meeting 26.md @@ -0,0 +1,39 @@ +# EIP-4844 Implementers' Call #26 + +## Meeting Details +### [Agenda](https://github.com/ethereum/pm/issues/818) +### Date: Jul 10, 2023 +### [Video Link](https://youtu.be/vdFD5w0OIqA) +## Notes: Orignally Documented [here](https://docs.google.com/document/d/15EatedrJanNxBZGPVASvwq9xgbTs5UxjsDfjpM6ppSY/edit#heading=h.ub6g85pp78v) + +### Notes + +**Devnet 7 updates:** +https://forkmon.4844-devnet-7.ethpandaops.io + +Parithosh: mainly have lighthouse / teku, with geth/nethermind sharing. Network is stable. Blob explorer: https://blobscan.com has been updated to spec and works. Any other blob testing can happen on this testnet. Avoiding too much load spamming because we did trigger an issue w/ Besu and wanted to give it some time. We are sending some blobs however. Issue tracker +https://notes.ethereum.org/@parithosh/dencun-issue-tracker +Some issues with deposits, will look into potential fork digest issues. + +Besu status: some issue with datahash operation, think we have it covered under hive tests, so should be fixed any hour now. This was a regression (worked on previous devnet). Expect to continue with chain once resolved. + +Devnet-8: specs are out. https://notes.ethereum.org/@ethpandaops/dencun-devnet-8 Release date unknown. + +Devnet-9: no specs out but we will move to capella genesis. + +**APIs for L2s.** Had call to action around whether current beacon API is ok for layer 2 (especially get blobs). Terence had asked Arbitrum for feedback. Suggested they would like to retrieve blobs using versioned hash, so created beacon hash issue to enable this. https://github.com/ethereum/beacon-APIs/issues/332 + +Not sure if this should be mandatory or optional for clients, but seems layer 2 teams should find it useful. If not implemented then you’d have to identify which block the tx made it into and you’d have to look it up that way. Proto: block-id introduced in Feb works for Optimism as L2. Ideally we can fetch it by something that can be identified by EL. Identification by slot, and then consistency checks of result, works. Additional endpoints would require indexing. L2s currently follow L1 EL chain, not beacon chain. +When is L2 not aware of blocks tx made it into? For Arbitrum only version hash is stored on chain, no block id, etc. Additional comments please leave in the issue above. +Are arbitrum / optimism on our testnets or plan to join? Arbitrum plans to join as soon as possible but waiting for things to stabilize a bit, e.g. devnet 8. Should invite more teams to prototype as we get into the future devnets. Optimism is looking to rebase prototype and join … just a matter of timing. + +**Spec PR:** https://github.com/ethereum/execution-apis/pull/426 : Helps to clarify some corner case around handling payloads v2. Reorders some checks. Defines order of validations for new payload / get payload methods to make it more clear in terms of testing & which errors codes we should expect in different situations connected to timestamp. Expects v2 & v3 methods should decline requests when timestamp is not for correct fork. Additionally if any additional fields are parsed / not parsed or contain null values it should be treated as invalid params. This is purely clarifications, useful for hive tests. Would be good to have for next devnet. Lucasz has approved. Will leave another day or two for eyes and then hopefully get it in. + +Had time slated for CL gossip sub modifications that are under discussion. Anton: Should disable flood/publish for blob topics. Unfortunately this is currently a global option. Another approach is to disable for messages larger than some threshold. Status of misc clients for supporting the flood/publish changes somewhat unknown. This is one of the single biggest things that might change success of these large messages. If a client or two don’t do it then it just affects the client in question, but would be best to have this across the board. + +Staggered sending would also be good to have, an optimization we could enable later. + +Should we have our own Libp2p version? Would be best to work with libp2p and not have to fork, but if we run into issues it’s certainly an option. Could also fork temporarily and merge upstream later if we are having timing issues. Would try to play in same environment if at all possible. + +Replacing of blob transactions: do we have some consensus on max increases? Are there rules on switching blob tx to non-blob tx? Geth has 100% required bump for everything right now. Some older discussion around replacement was here: https://ethereum-magicians.org/t/eip-4844-shard-blob-transactions/8430/29?u=roberto-bayardo +Will try to bring up on ACDE with Peter. From f48de5ec5e5ade5ff92b6329c00c15f7c37692ee Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 12:48:20 -0400 Subject: [PATCH 15/17] Update README.md --- Breakout-Room-Meetings/eip-4844/README.md | 24 +++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/Breakout-Room-Meetings/eip-4844/README.md b/Breakout-Room-Meetings/eip-4844/README.md index 8b137891..611d9b40 100644 --- a/Breakout-Room-Meetings/eip-4844/README.md +++ b/Breakout-Room-Meetings/eip-4844/README.md @@ -1 +1,25 @@ +# EIP-4844 Meetings + +## Purpose +EIP-4844 introduces a new kind of transaction type to Ethereum which accepts "blobs" of data to be persisted in the beacon node for a short period of time. These changes are forwards compatible with Ethereum's scaling roadmap, and blobs are small enough to keep disk use manageable. + +### Previous Meetings + + № | Meeting | Date | Agenda | Notes | Recording | +--- | ------- |-------------------------------- | :--------------: | :--------------------: | :----------------: | +6 | EIP 4844 Community Call 6 | Nov 29, 2022 | [🔗](https://github.com/ethereum/pm/issues/679) | [🔗](link) | [📺](https://youtu.be/MVGnY7vAPeg) | +5 | EIP 4844 Community Call 5 | Nov 22, 2022 | [🔗](https://github.com/ethereum/pm/issues/670) | N/A | [📺](https://youtu.be/tTF2VHcAMzE) | +4 | EIP 4844 Community Call 4 | Nov 15, 2022 | [🔗](https://github.com/ethereum/pm/issues/663) | N/A | [📺](https://www.youtube.com/watch?v=3vWBTEJSeSY) | +3 | EIP 4844 Community Call 3 | Nov 08, 2022 | [🔗](https://github.com/ethereum/pm/issues/655) | N/A | [📺](https://youtu.be/GoUTXA9cPpA) | +2 | EIP 4844 Community Call 2 | Nov 01, 2022 | [🔗](https://github.com/ethereum/pm/issues/650) | N/A | N/A | +1 | EIP 4844 Community Call 1 | Oct 25, 2022 | [🔗](https://github.com/ethereum/pm/issues/647) | N/A | N/A | + +### Who Can Attend + + +### Agenda + +The agendas are posted under the [Issues tab](https://github.com/ethereum/pm/issues/) of this repository. + + From aa00dd5669bb7dca038fe3657450336eb71c4a5c Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 13:02:58 -0400 Subject: [PATCH 16/17] Update README.md --- Breakout-Room-Meetings/eip-4844/README.md | 32 ++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/Breakout-Room-Meetings/eip-4844/README.md b/Breakout-Room-Meetings/eip-4844/README.md index 611d9b40..d51778ae 100644 --- a/Breakout-Room-Meetings/eip-4844/README.md +++ b/Breakout-Room-Meetings/eip-4844/README.md @@ -7,7 +7,37 @@ EIP-4844 introduces a new kind of transaction type to Ethereum which accepts "bl № | Meeting | Date | Agenda | Notes | Recording | --- | ------- |-------------------------------- | :--------------: | :--------------------: | :----------------: | -6 | EIP 4844 Community Call 6 | Nov 29, 2022 | [🔗](https://github.com/ethereum/pm/issues/679) | [🔗](link) | [📺](https://youtu.be/MVGnY7vAPeg) | +26 | EIP 4844 Community Call 26 | Jul 10, 2023 | [🔗](https://github.com/ethereum/pm/issues/818) | N/A | [📺](https://www.youtube.com/watch?v=vdFD5w0OIqA) | +25 | EIP 4844 Community Call 25 | Jun 26, 2023 | [🔗](https://github.com/ethereum/pm/issues/807) | N/A | [📺](https://youtu.be/WFwXitiwv-Q) | +24 | EIP 4844 Community Call 24 | Jun 12, 2023 | [🔗](https://github.com/ethereum/pm/issues/794) | N/A | [📺](https://youtu.be/jQ86ItkOfm0) | +23 | EIP 4844 Community Call 23 | May 29, 2023 | [🔗](https://github.com/ethereum/pm/issues/782) | N/A | [📺](https://youtu.be/lZiotV3nNIU) | +22 | EIP 4844 Community Call 22 | May 15, 2023 | [🔗](https://github.com/ethereum/pm/issues/772) | N/A | [📺](https://youtu.be/IckYm8ZXZtE) | +21 | EIP 4844 Community Call 21 | May 01, 2023 | [🔗](https://github.com/ethereum/pm/issues/760) | N/A | [📺](https://youtu.be/M2pYYEtM3Gw) | +20 | EIP 4844 Community Call 20 | Apr 17, 2023 | [🔗](https://github.com/ethereum/pm/issues/755) | N/A | [📺](https://www.youtube.com/watch?v=oCqfxb5CWAI) | +19 | EIP 4844 Community Call 19 | Apr 03, 2023 | [🔗](https://github.com/ethereum/pm/issues/745) | N/A | [📺](https://youtu.be/MVGnY7vAPeg) | +18 | EIP 4844 Community Call 18 | Mar 20, 2023 | [🔗](https://github.com/ethereum/pm/issues/739) | N/A | [📺](https://youtu.be/gdy5svsnFrM) | +17 | EIP 4844 Community Call 17 | Mar 07, 2023 | [🔗](https://github.com/ethereum/pm/issues/732) | N/A | [📺](https://youtu.be/8hDlg-x6MjE) | +16 | EIP 4844 Community Call 16 | Feb 21, 2023 | [🔗](https://github.com/ethereum/pm/issues/726) | N/A | [📺](https://youtu.be/hWcpSlwNTBU) | +15 | EIP 4844 Community Call 15 | Feb 14, 2023 | [🔗](https://github.com/ethereum/pm/issues/722) | N/A | [📺](https://youtu.be/poTKRryqrzU) | +14 | EIP 4844 Community Call 14 | Feb 07, 2023 | [🔗](https://github.com/ethereum/pm/issues/718) | N/A | [📺](https://youtu.be/vQGk9FDs_CM) | +13 | EIP 4844 Community Call 13 | Jan 31, 2023 | [🔗](https://github.com/ethereum/pm/issues/716) | N/A | [📺](https://youtu.be/O1LLyKIMHUM) | +12 | EIP 4844 Community Call 12 | Jan 17, 2023 | [🔗](https://github.com/ethereum/pm/issues/709) | N/A | [📺](https://youtu.be/zDjF3AGypbM) | +11 | EIP 4844 Community Call 11 | Jan 10, 2023 | [🔗](https://github.com/ethereum/pm/issues/707) | N/A | [📺](https://youtu.be/FnKOHR92dXU) | +10 | EIP 4844 Community Call 10 | Jan 03, 2023 | [🔗](https://github.com/ethereum/pm/issues/701) | N/A | [📺](https://youtu.be/9ZwTy0msVdU) | +9 | EIP 4844 Community Call 9 | Dec 20, 2022 | [🔗](https://github.com/ethereum/pm/issues/789) | N/A | [📺](https://youtu.be/pgJxQuAizMw) | +8 | EIP 4844 Community Call 8 | Dec 13, 2022 | [🔗](https://github.com/ethereum/pm/issues/686) | N/A | [📺](https://youtu.be/MQGJgdWOTpI) | +7 | EIP 4844 Community Call 7 | Dec 06, 2022 | [🔗](https://github.com/ethereum/pm/issues/684) | N/A | [📺](https://youtu.be/2lSGS9weOv0) | + + + + + + + + + + +6 | EIP 4844 Community Call 6 | Nov 29, 2022 | [🔗](https://github.com/ethereum/pm/issues/679) | N/A | [📺](https://youtu.be/MVGnY7vAPeg) | 5 | EIP 4844 Community Call 5 | Nov 22, 2022 | [🔗](https://github.com/ethereum/pm/issues/670) | N/A | [📺](https://youtu.be/tTF2VHcAMzE) | 4 | EIP 4844 Community Call 4 | Nov 15, 2022 | [🔗](https://github.com/ethereum/pm/issues/663) | N/A | [📺](https://www.youtube.com/watch?v=3vWBTEJSeSY) | 3 | EIP 4844 Community Call 3 | Nov 08, 2022 | [🔗](https://github.com/ethereum/pm/issues/655) | N/A | [📺](https://youtu.be/GoUTXA9cPpA) | From d05883c5c5b8e04e3908e14605d4bd3a20b39644 Mon Sep 17 00:00:00 2001 From: Darkfire_rain <67558925+darkfire-rain@users.noreply.github.com> Date: Tue, 18 Jun 2024 16:42:04 -0400 Subject: [PATCH 17/17] Update README.md --- Breakout-Room-Meetings/eip-4844/README.md | 30 ++++++++--------------- 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/Breakout-Room-Meetings/eip-4844/README.md b/Breakout-Room-Meetings/eip-4844/README.md index d51778ae..6391dbfb 100644 --- a/Breakout-Room-Meetings/eip-4844/README.md +++ b/Breakout-Room-Meetings/eip-4844/README.md @@ -7,36 +7,26 @@ EIP-4844 introduces a new kind of transaction type to Ethereum which accepts "bl № | Meeting | Date | Agenda | Notes | Recording | --- | ------- |-------------------------------- | :--------------: | :--------------------: | :----------------: | -26 | EIP 4844 Community Call 26 | Jul 10, 2023 | [🔗](https://github.com/ethereum/pm/issues/818) | N/A | [📺](https://www.youtube.com/watch?v=vdFD5w0OIqA) | +26 | EIP 4844 Community Call 26 | Jul 10, 2023 | [🔗](https://github.com/ethereum/pm/issues/818) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2026.md) | [📺](https://www.youtube.com/watch?v=vdFD5w0OIqA) | 25 | EIP 4844 Community Call 25 | Jun 26, 2023 | [🔗](https://github.com/ethereum/pm/issues/807) | N/A | [📺](https://youtu.be/WFwXitiwv-Q) | 24 | EIP 4844 Community Call 24 | Jun 12, 2023 | [🔗](https://github.com/ethereum/pm/issues/794) | N/A | [📺](https://youtu.be/jQ86ItkOfm0) | 23 | EIP 4844 Community Call 23 | May 29, 2023 | [🔗](https://github.com/ethereum/pm/issues/782) | N/A | [📺](https://youtu.be/lZiotV3nNIU) | 22 | EIP 4844 Community Call 22 | May 15, 2023 | [🔗](https://github.com/ethereum/pm/issues/772) | N/A | [📺](https://youtu.be/IckYm8ZXZtE) | -21 | EIP 4844 Community Call 21 | May 01, 2023 | [🔗](https://github.com/ethereum/pm/issues/760) | N/A | [📺](https://youtu.be/M2pYYEtM3Gw) | -20 | EIP 4844 Community Call 20 | Apr 17, 2023 | [🔗](https://github.com/ethereum/pm/issues/755) | N/A | [📺](https://www.youtube.com/watch?v=oCqfxb5CWAI) | -19 | EIP 4844 Community Call 19 | Apr 03, 2023 | [🔗](https://github.com/ethereum/pm/issues/745) | N/A | [📺](https://youtu.be/MVGnY7vAPeg) | -18 | EIP 4844 Community Call 18 | Mar 20, 2023 | [🔗](https://github.com/ethereum/pm/issues/739) | N/A | [📺](https://youtu.be/gdy5svsnFrM) | -17 | EIP 4844 Community Call 17 | Mar 07, 2023 | [🔗](https://github.com/ethereum/pm/issues/732) | N/A | [📺](https://youtu.be/8hDlg-x6MjE) | -16 | EIP 4844 Community Call 16 | Feb 21, 2023 | [🔗](https://github.com/ethereum/pm/issues/726) | N/A | [📺](https://youtu.be/hWcpSlwNTBU) | -15 | EIP 4844 Community Call 15 | Feb 14, 2023 | [🔗](https://github.com/ethereum/pm/issues/722) | N/A | [📺](https://youtu.be/poTKRryqrzU) | -14 | EIP 4844 Community Call 14 | Feb 07, 2023 | [🔗](https://github.com/ethereum/pm/issues/718) | N/A | [📺](https://youtu.be/vQGk9FDs_CM) | -13 | EIP 4844 Community Call 13 | Jan 31, 2023 | [🔗](https://github.com/ethereum/pm/issues/716) | N/A | [📺](https://youtu.be/O1LLyKIMHUM) | +21 | EIP 4844 Community Call 21 | May 01, 2023 | [🔗](https://github.com/ethereum/pm/issues/760) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2021.md) | [📺](https://youtu.be/M2pYYEtM3Gw) | +20 | EIP 4844 Community Call 20 | Apr 17, 2023 | [🔗](https://github.com/ethereum/pm/issues/755) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2020.md) | [📺](https://www.youtube.com/watch?v=oCqfxb5CWAI) | +19 | EIP 4844 Community Call 19 | Apr 03, 2023 | [🔗](https://github.com/ethereum/pm/issues/745) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2019.md) | [📺](https://youtu.be/MVGnY7vAPeg) | +18 | EIP 4844 Community Call 18 | Mar 20, 2023 | [🔗](https://github.com/ethereum/pm/issues/739) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2018.md) | [📺](https://youtu.be/gdy5svsnFrM) | +17 | EIP 4844 Community Call 17 | Mar 07, 2023 | [🔗](https://github.com/ethereum/pm/issues/732) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2017.md) | [📺](https://youtu.be/8hDlg-x6MjE) | +16 | EIP 4844 Community Call 16 | Feb 21, 2023 | [🔗](https://github.com/ethereum/pm/issues/726) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2016.md) | [📺](https://youtu.be/hWcpSlwNTBU) | +15 | EIP 4844 Community Call 15 | Feb 14, 2023 | [🔗](https://github.com/ethereum/pm/issues/722) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2015.md) | [📺](https://youtu.be/poTKRryqrzU) | +14 | EIP 4844 Community Call 14 | Feb 07, 2023 | [🔗](https://github.com/ethereum/pm/issues/718) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2014.md) | [📺](https://youtu.be/vQGk9FDs_CM) | +13 | EIP 4844 Community Call 13 | Jan 31, 2023 | [🔗](https://github.com/ethereum/pm/issues/716) | [🔗](https://github.com/Ethereum/pm/blob/master/Breakout-Room-Meetings/eip-4844/Meeting%2013.md) | [📺](https://youtu.be/O1LLyKIMHUM) | 12 | EIP 4844 Community Call 12 | Jan 17, 2023 | [🔗](https://github.com/ethereum/pm/issues/709) | N/A | [📺](https://youtu.be/zDjF3AGypbM) | 11 | EIP 4844 Community Call 11 | Jan 10, 2023 | [🔗](https://github.com/ethereum/pm/issues/707) | N/A | [📺](https://youtu.be/FnKOHR92dXU) | 10 | EIP 4844 Community Call 10 | Jan 03, 2023 | [🔗](https://github.com/ethereum/pm/issues/701) | N/A | [📺](https://youtu.be/9ZwTy0msVdU) | 9 | EIP 4844 Community Call 9 | Dec 20, 2022 | [🔗](https://github.com/ethereum/pm/issues/789) | N/A | [📺](https://youtu.be/pgJxQuAizMw) | 8 | EIP 4844 Community Call 8 | Dec 13, 2022 | [🔗](https://github.com/ethereum/pm/issues/686) | N/A | [📺](https://youtu.be/MQGJgdWOTpI) | 7 | EIP 4844 Community Call 7 | Dec 06, 2022 | [🔗](https://github.com/ethereum/pm/issues/684) | N/A | [📺](https://youtu.be/2lSGS9weOv0) | - - - - - - - - - - 6 | EIP 4844 Community Call 6 | Nov 29, 2022 | [🔗](https://github.com/ethereum/pm/issues/679) | N/A | [📺](https://youtu.be/MVGnY7vAPeg) | 5 | EIP 4844 Community Call 5 | Nov 22, 2022 | [🔗](https://github.com/ethereum/pm/issues/670) | N/A | [📺](https://youtu.be/tTF2VHcAMzE) | 4 | EIP 4844 Community Call 4 | Nov 15, 2022 | [🔗](https://github.com/ethereum/pm/issues/663) | N/A | [📺](https://www.youtube.com/watch?v=3vWBTEJSeSY) |