Notes on EPF Project Ideas

Some comments on the project ideas that caught my attention.

Ephemery testnet

Contribute to integration of public ephemeral testnet. Research and feedback the spec, create implementations in clients and/or client testing, end user tooling, e.g. dappnode, nicenode, stereum. Check the specs and network details.

So, what is an ephemery testnet?

An ephemeral testnet is a single network that rolls back to the genesis after a set period of time. This kind of network is focused on short term and heavy testing usecases. The purpose of this is also to avoid problems like insufficient testnet funds, inactive validators, state bloat, and similar issues faced by long-running testnets.

Learn more about the idea in the original proposal and specification.

(source: https://github.com/ephemery-testnet/ephemery-resources)

A roadmap can be found in the ephemery-resources repo:

Roadmap

Ephemeral testnet needs a lot of research and development to be stable and widely usable. Here is a simple roadmap and current progress:

• Proposal and initial discussion
• Private network with manual reset mechanism
  • Using external script to reset the network
  • A small private chain was created to identify feasibility issues and to stabilize the devops setup.
• Public network with manual reset mechanism
  • Stable network open to the public and wider debugging, simplifing node/validator setup
• Creating general specifications for automatically reset ephemeral testnet
  • Discussion about implementation details and specifications based on data gathered from the network with manual resets
  • Specs draft
  • Draft EIP
• Automatic onchain infrastracture
  • Refuding validators
  • Deploying primitives for dapps
• Preliminary client implementation work
  • Single client pair, testing on private/public chain
  • Improving and finishing specs
• Cross client implementation
  • Testing all client combos, ACD discussion

This seems important and interesting, but I'm more interested in working directly on functionality of the protocol instead of building testing infrastructure.

Optimism sequencer support for ERC 4337 bundlers

Modify the Optimism (Bedrock) sequencer to add a new RPC for ERC-4337 (account abstraction) bundlers. The new RPC will enable submitting a transaction with certain conditions, and the sequencer will guarantee that the transaction will only be sequenced if these conditions are met. The RPC will be designed to mitigate DoS against the sequencer, require only minimal work from the sequencer, and throttle callers with poor inclusion ratio.

Users in Ethereum have to use Externally Owned Accounts to interact with the EVM. EOAs don't have good UX, specially around security and key management. On the other side, there are Smart Contract Wallets. SCWs are programmable, and this allows a whole new world of ways to approach security for users. However, SCWs can't interact with the EVM. (Without implementing quite complicated logic that might lead to vulnerabilities.)

Account abstraction seeks to close that gap. Allowing users to have the good UX of SCWs while being able to interact with the EVM natively.

Or, as Vitalik would put it:

Account abstraction has for a long time been a dream of the Ethereum developer community. Instead of EVM code just being used to implement the logic of applications, it would also be used to implement the verification logic (nonces, signatures…) of individual users’ wallets. This would open the door for creativity in wallet designs that could provide some important features:

• Multisigs and social recovery
• More efficient and simpler signature algorithms (eg. Schnorr, BLS)
• Post-quantum safe signature algorithms (eg. Lamport, Winternitz)
• Upgradeability

The leading EIP/ERC for AA is ERC-4337. There are others EIPs for AA, like EIP-2771, EIP-9238 and EIP-3074. Those other EIPs are not as popular as 4337 because they need to make changes to the core protocol.

This seems to be more on the app layer side of things, instead of the core, and the project specifically mentions the OP sequencer as the target of the contribution.

Nimbus

• Create a Verkle tree library in Nim.
• Introduce out of order and speculative execution in the Nimbus asynchronous EVM to speed up transaction execution when the Ethereum state data must be fetch dynamically from the Portal network.
• Implement a novel snap sync protocol for the beacon chain.
• Implement a novel distributed validator setup in the Nimbus beacon node, reducing the risk of validator downtime.
• Implement a stateless mode for the Nimbus execution client.
• Implement a management GUI/WebUI for Nimbus.
• Implement a novel append-only database for the Nimbus beacon node.
• Implement instant one-shot syncing based on the zero-knowledge proofs from the DendrETH project.

There are a lot of interesting projects mentioned. I would have lo learn Nim to work on them, but this is not a big issue since learning a new language would be nice.

However, if I decide to learn a new language, I'd prefer to learn go. It's used more widely in the infrastructure of the ecosystem.

SnSLE Implementations

…For consensus researchers, explore fork-choice implementation of https://ethresear.ch/t/secret-non-single-leader-election/11789.

This is an area that is far from implementation:

Current progress

SSLE and SnSLE are both in the research phase. There is no finalized specification for either idea yet. SSLE and SnSLE are competing proposals that couldn't both be implemented. Before shipping they need more research and development, prototyping, and implementing on public testnets.

(source https://ethereum.org/en/roadmap/secret-leader-election/)

Which drags me back a bit because I want to focus more on implementation than research. Even though I want to do some research.

ePBS design and prototyping

We are planning to ramp up engineering design space for ePBS and are looking for interested cohort fellows that are torn between research and software engineering. Tasks will include review of the current literature on ePBS, prototyping and writing design documents adapted to the Prysm CL client, and writing production level code. The literature consists mostly writeups by the RIG, which has an open problem on precisely this same topic. In this project we are more interested in deploying a working product, that can be tested in distributed devnets and compatible with EIP4844.

This project interests me because I’d get to do research as well as implementation.

Currently, a single validator is selected to build and propose a block. Proposer builder separation aims to do just what its name says. This helps with censorship resistance, MEV and danksharding.

PBS is already implemented in infra like mev-boost, but enshrining it into the protocol would be beneficial.

ePBS is not something that has to be done in Prism, I could work on this but implement it for Lighthouse instead of Prism. (So I can keep writing Rust.)

Separate blobs from payload

This project is about studying the implementation and design space for separation of blobs from the execution payload in Deneb. A rationale for this proposed change can be found in this Ethereum magician's post. Tasks include writing design docs for implementation in Prysm, prototyping them, writing (or reviewing) the accompanying consensus layer spec repo pull requests and eventually delivering production code that can be tested on devnets.

This proposal is explained in this ethresear.ch post:

We propose a separation of blob transactions from the rest of the execution payload. This achieves the following objectives:

• Home computers are still able to produce execution blocks and defer blob production to builders.
• The validity of blobs and execution payload can be verified in an independent manner, thus this mechanism is more resilient to bugs in the builder that produce invalid commitments for example.
• Fully compatible with the current design with minimal protocol changes

The main con is in the extra complexity needed on relayers and external software like MEV-Boost. Another con is that transactions will not be able to interact with blob transactions immediately, as blob transaction processing is deferred for one block.

This seems to be more focused on research than the project related to ePBS.

Portal network

Improve Portal Network interop tests (portal-hive), Portal State Network R&D, Portal DAS network R&D.

There are 3 areas suggested here:

• Portal-hive
• Portal State Network
• Portal DAS Network

The portal network has multiple clients and multiple networks. The portal hive tests that all the clients are compatible with each other. Again, testing is not my main area of interest.

The other two suggested areas are specific networks in the portal network.

One of them is the Portal state network, which:

facilitates on-demand retrieval of the Ethereum "state" data. This includes:

• Reading account balances or nonce values
• Retrieving contract code
• Reading contract storage values"

I think the DAS network is officially known as the Portal History Netowrk, which:

The History Network facilitates on-demand retrieval of the history of the Ethereum chain. This includes:

• Headers
• Block bodies
• Receipts

Both of them are at a very early stage, and as the trin repo says:

The Portal Network is still in the research phase, and this client is experimental.

Which means if I choose to work on the PN I would be focusing heavily in research. However, I could focus the project in contributing to one of the clients.

Lighthouse

• Adding and benchmarking new slasher backends. Lighthouse can use either LMDB or MDBX for its slasher backend but we are interested in experimenting with other options like SQLite, Postgres and redb.
• Similar to the slasher backend, we would like to modularise the beacon node database backend. Currently only LevelDB is supported, but it has several issues and is starting to look quite dated. This project would involve abstracting over the backend, and then adding at least one new one (e.g. SQLite).
• Implementing improvements to Lighthouse's attestation packing. We have undertaken previous research on this topic, but have yet to implement all of the ideas we decided upon. See: https://lighthouse-blog.sigmaprime.io/optimising-attestation-packing.html and sigp/lighthouse#3733.

I'm biased towards working on this because I've contributed to Lighthouse in the past.

Other fellows mentioned that they want to work on the first and third one, but the second project still seems quite interesting.

Working on it would help me expand my knowledge in databases, a weak area that I have.

This project is mainly refactoring the beacon node database backend. So, not a lot of room to research besides choosing the other database option.

Conclusions

See my EPF Dev Update #1.