response to "biggest blocker" on eip-4444 ama: question: https://www.reddit.com/r/ethereum/comments/qzvsfq/comment/hloqmpr/?utm_source=share&utm_medium=web2x&context=3 from `HarryZKE` --- I don't think the biggest challenges are technical following the roadmap of EIP-4444. Clients today already implement some form of pruning so it is not a big ask to extend this mechanism to more types of data a node already manages. The bigger challenge will be coordinating around the guarantees the protocol provides for history on the network and how expired history will still be accessible if something along these lines is deployed. In an ideal world, there will be several high-quality sources for historic Ethereum data, just like the role the Internet Archive intends to serve for Internet data. And moreover, these sources would provide this data for free, acting altruistically, even if only as a token of good faith to support other for-profit endeavors they undertake. While this may sounds like a lot of load to put on a few players, the Ethereum community can lighten the burden with mechanisms like Bittorrent so that only a few "bridge" nodes are needed to have a highly-available swarm of peers providing the data to whoever needs it. And if it becomes necessary, we can brainstorm further incentivization schemes like those used by Graph and others to index the protocol history.
Last changed by  
 
Alex Stokes
487

Read more

relay monitor design doc

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

8/5/2022
mev-boost circuit breaker proposal

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.

7/27/2022
Precompiles for BLS12-381

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).

2/21/2020
Finality gadget (FG) working group - call #0

8/15/2019
Read more from Alex Stokes
Published on HackMD