A proposal to safely deliver a maximally impactful Fusaka. tl;dr? the core proposal is here Fusaka, Peerdas and blobs The upcoming Fusaka (Fulu + Osaka) upgrade for Ethereum introduces PeerDAS, a data availability sampling technique, via EIP-7594 that supports a theoretical 8x increase on top of today's data layer. Following the imminent Pectra upgrade, Ethereum will support a target of 6 blobs per block, up to a maximum of 9 blobs per block. PeerDAS then suggests a target of 48 blobs per block, up to a maximum of 72 blobs per block. Given the fact that PeerDAS is an entirely new technique for data availability, there is some concern about moving from Pectra's blob limits directly to the PeerDAS theoretical max. To mitigate this concern, Fusaka could start at a much more conservative blob count with the implication that we would need additional network upgrades to further increase the blob count.

On ACDE #196 the concern around the size of the currently scheduled Pectra fork (along with some possible CFI'd EIPs) came up and a potential resolution was to split the Pectra scope into two forks. I'd like to suggest one way to break the EIP set into two hard forks: Pectra Essentially pectra-devnet-3 today, along with some polish: 6110some outstanding work to resolve this feature along with other CL EIPs, but all of this would be in Pectra 7002

thanks to @metachris, @bertcmiller and @thegostep for helpful discussions on this design intro this document assumes knowledge of the general mev-boost architecture. you will want to be familar with the builder-specs: https://github.com/ethereum/builder-specs and here are some diagrams that are relevant, both from the flashbots/mev-boost repo on github: high-level architecture

what? the merge supports an "external builder network" where proposers can work w/ specialized actors to get execution payloads skillfully crafted to maximize validator rewards. these specialized actors have the responsibility to ensure the availability of the execution payloads they build and if they fail in this responsibility it will look like the proposer failed to propose a block from the protocol's point of view. this failure mode -- a "liveness" failure -- should be prevented at most costs as it means less transaction throughput for users and an overall reduced quality of service. there are several mitigations for this type of failure and this proposal specifies a "last resort". specifically, users of the external builder network will implement a "circuit breaker" (random resource for more info: https://martinfowler.com/bliki/CircuitBreaker.html) using globally available inputs (simply, the chain) to decide if they should make a local decision to stop using the external builder network.

NOTE: This is a draft EIP that is currently incomplete; this version is circulating for discussion purposes. Abstract BLS12-381 precompiles permit efficient cryptographic operations inside the EVM that are otherwise prohibitively expensive. Support for this curve enables interoperability with Eth2.0 and a host of other blockchain projects (ZCash, Filecoin, Chia, Dfinity, Algorand, ...) along with applications to secure zk-SNARKs. Motivation This EIP introduces precompiles to the EVM for arithmetic operations on the elliptic curve BLS12-381, https://electriccoin.co/blog/new-snark-curve/. This pairing-friendly elliptic curve is the host of validator identities in Eth2.0 (as it affords efficient signature aggregation under the BLS signature scheme https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html) and has applications to zk-SNARKS as seen in systems like Zcash (see prior link on electriccoin.co).

# Finality gadget (FG) working group - call #0 ## purpose Have anyone interested in joining the working group to meet and start planning out what the group needs to do and how to do it. ## agenda - intro to group - brief intros of team members - discuss "roadmap" of working group - what are we trying to accomplish - and possibly even, when - finalize next steps - what should we make progress on - possibly, exactly who should do it - possibly before the next ca