eth-protocol-fellows/cohort-one

Repository for the second cohort of the apprenticeship program

cohort-one's Issues

Project Idea: Improve nanoeth

Hey everyone,

I'm Nicolas and I am in cohort zero (you can find my dev updates here).

As part of my apprenticeship, I started building nanoeth which attempts to be a super simple, super clean, super thoroughly-documented implementation of Ethereum's execution layer (everything that has to do with validating blocks & executing transactions).

There's one month left in my apprenticeship, after which the time available to work on this project will diminish drastically. I intend to keep working on it however - I think it's nice enough that it would be a shame to abandon.

This is where you can help. If you're interested in learning about something, why not implement it in nanoeth as a learning experience? Some ideas:

• EVM implementation - I intend to start working on this, but I could use some help
• on-disk storage: running the main chain requires storing state & blocks on disk - many implementations use a key value store (like LevelsDB) for this purpose, but it could be interesting to see what the design space is
• networking: nanoeth was not intended as a full client, but why not
  • block sync: in particular, the highest value item would be the ability to pull blocks from the network to run them (this is synergistic with the on-disk storage part)
• geth/... bridge: alternatively, it would be nice to be able to run the chain by getting blocks from another client (local or remote), using the JSON-RPC API

To be clear, if you have the opportunity to help out a team that works on something that is currently being used in the ecosystem, you probably should do that instead. But nanoeth might be an easier environment to try a thing or two, and I'd be happy to assist you if you have any questions.

Cheers, & hoping to hear from some of you!

Project Idea: Formalize different approaches to "Account Migration"

There is a high level goal to improve the usability of base accounts on Ethereum. Today, EOAs are very limited in what they can do. There are two main camps currently to improving this situation:

Account migration -- some process that eradicates EOAs from the protocol
Protocol-level authorization -- an EVM change that allows EOAs to delegate control to smart contracts

Some reading material:

• https://ethereum-magicians.org/t/we-should-be-moving-beyond-eoas-not-enshrining-them-even-further-eip-3074-related/6538
• https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603
• https://eips.ethereum.org/EIPS/eip-3074

dm me on discord or twitter for more info

Project idea: beacon chain light clients

Efficient proof-of-stake light client designs are possible starting with the Altair fork of the beacon chain.

A project idea would be to prototype a beacon chain light client and help bootstrap the ecosystem around them, possibly starting with the spec here: https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/sync-protocol.md

This project would be a great way to get your hands dirty with building a protocol client as you will need to touch all the various parts of "building a client" but the light client protocol is fairly self-contained and lightweight (by design!). I'd expect anyone working on this to leave with a great understanding of Ethereum's proof-of-stake consensus and a better understanding of the issues and concerns involved with building and maintaining protocol software.

Anyone who is interested in this should reach out to me and I'm very happy to discuss ideas further and/or can help guide efforts during cohort-one.

Project Idea: Static Analysis to predict access list

When a client to the Portal Network executes something like eth_call or eth_estimateGas, they will typically be doing so without the actual state data, and thus, they will need to retrieve state on demand from the network.

The simple initial implementation would pause EVM execution each time state data is accessed, retrieve that data from the network, and then proceed with execution. This approach suffers from all of the data needing to be retrieved one piece at a time. We can do better.

Given a transaction payload, some collection of known state data (which might be empty), we should be able to predict a significant amount of the accounts and storage slots that will be accessed.

Lets pretend we have such a function:

def divine_access_list(transaction, known_state) -> AccessList:
    ...

At the very beginning of the transaction we can "predict" that the tx.sender and tx.to accounts will be needed, along with the bytecode for the tx.to account. Once these values have been retrieved, we can call the function again, but this time with known_state containing this account information and bytecode.

Now, suppose that the bytecode was something like:

PUSH1 0x00 SLOAD ...

From this, we can perform some very simple static analysis to know that we will be needing the value at storage slot 0.

This logic could then be run in a loop that looked something like this.

# start with zero state
known_state = []

while True:
    # figure out which state we're able to determine that we need
    state_data_to_retrieve = divine_access_list(tx, known_state)

    # if we cannot determine any additional state needs from static 
    # analysis then maybe we're at a dead end and can only determine 
    # the remaining needs via execution
    if not state_data_to_retrieve:
        break
    
    # fetch the state from wherever we're getting it from and 
    # merge it in with the state we may already have
    new_state_data = retrieve_state(state_data_to_retrieve)
    known_state.merge(new_state_data)

This could be run alongside the EVM execution, passively determining values we are going to need and retrieving them, while the other process actually performs the EVM execution.

So the project would be to write a version of this predictive engine, and then to do some experiment with real transactions on mainnet to measure how effective it can be at predicting what state will be needed during execution.

Project Idea: IPLD codec for SSZ

If it was possible to create an IPLD codec for SSZ then it appears that would allow us to use IPFS/Filecoin for storage/retrieval of SSZ objects. Since the beacon chain state is all SSZ, that means that we could use IPFS/Filecoin as a data provider for beacon chain light clients.

• https://ipld.io/docs/
• https://ssz.dev/

Project Idea: Research removal of gas stipend for CALL opcodes

See: https://hackmd.io/@vbuterin/evm_feature_removing#The-2300-gas-stipend

Figure out what research needs to be done to move this forward.

Project Idea/Help Wanted: Portal Network implementation in Typescript

I'm currently working on building out an implementation in Typescript of the Portal Network client that will run in the browser to expand the reach of the network and looking for collaborators.

Reference links:
Ultralight Browser Client - Simple React App that demos Portal Network client running in browser
TS Portal Network module - work in progress implementation of Portal Network protocols
DIscv5 Module - My fork of Chainsafe's Discv5 implementation that adds Websocket transport so Discv5 can be run in the browser
UDP Proxy service - Simple UDP proxy service written that connects browser based discv5 clients to the UDP based discv5 network

Project Idea: MTP circuit

Here's a project proposal from Barry

https://hackmd.io/CDmIbMafR5SLnHlCIXxE3A?view

Project Idea: Compare Tracing API outputs across clients

One of the main reason for the "stickiness" of clients is their tracing APIs. When sophisticated users (e.g. exchanges, block explorers, infrastructure providers, etc.) need to read the data from Ethereum, not only do they need the full blocks/transactions, but they also require the entire traces for them. Different clients provide different ways to access these traces, and applications tend to be built around their client of choice's specific output.

To make it easier for users to swap clients, ideally these trace formats would be standardized. A first step towards getting there, is having a clear view of the various tracing APIs across clients, and how their output differs. At a high level, what I would suggest is:

1. Review the various APIs available in go-ethereum, Open Ethereum, Nethermind, Erigon and Besu.
2. Create a table listing which clients support which tracing modes (and ideally the different method name for each client).
3. For the API calls which are supported across multiple clients, trace the last ~100,000 blocks on mainnet using each client and document any inconsistencies in the results.

R&D Discord Invites

If you would like an invite to the R&D discord, please leave an email address in a comment on this issue and we'll get one sent your way.

Project Idea: On-chain analysis of missed attestations and related data

The beaconchain is pushing the limits of software engineering on clients which are constantly finding new optimizations in order to maintain this high participation rate. In the last few weeks as the validator set reached a quarte of a million validators, reports of missed attestations have increased. I would be good to have some study of the data on-chain about missed attestations, late-included attestations, and soon sync committee participation. In rough terms the following are medium term objectives of this project

• Develop tools to gather on-chain data and visualize it (here chaind is a good tool to gather data, so participants can either add functionality to it or use it as source for visualization apps)
• Develop visualization schemes to understand the data: It's not really clear how to visualize attestation and/or participation data. Here are some examples:
  • Pintail's medalla challenge: https://pintail.medium.com/the-medalla-data-challenge-tl-dr-fb565372a860
  • when studying the slot zero problem: https://hackmd.io/@potuz/SyU-uNZnv
  • Some interesting alternative formats by @protolambda https://discord.com/channels/595666850260713488/598292067260825641/890354477016707122
• Understanding the network topology of the p2p stack of Consensus layer.

Here are some concrete problems to tackle in the short term: understanding pools' role in late blocks or rather if clustering on mainnet is causing missed attestations. The thesis is that there are very large chunks of validator keys being run by pools on highly peered networks of their own, that produce blocks fast and they pack them with their own attestations. Those blocks are then arriving late to the single validator. If this is the case this should be checkable with on-chain data.

1. There are large lists of validators associated to pools in Beaconcha.in . Find those, just the first 5 pools would be more than enough.
2. Grab several blocks and gather the average attestation performance of these validators: that is, for each block, get the committe, match how many of these pool validators were supposed to attest and then how many did correctly.
3. Do the same for the network as a whole.
4. Find blocks with a large number of missed attestations: Given the information in 3) you can filter now some blocks that were statistically not voted.
5. On these blocks, determine the percentage of them that were proposed by the pools (see if it is more than their validator share)
6. On these blocks determine if pool validators attested with average performance as in 2)

Other projects include analysis of sync committee participation on Altair forked networks: find correlation between sync committee particpation and attestation participation and/or slot position in epoch. Specially useful would be to have tools (inexistent currently) to visualize sync committee participation.

Meu

Eth

Project Idea: Portal Client implementation in Geth

@zsfelfoldi is getting started with an implementation of a portal client in the go-ethereum codebase. There is room for additional collaborators/contributors to assist in this effort. Getting in touch with Felföldi is probably a good first step.

Portal Network specs here: https://github.com/ethereum/portal-network-specs

Project idea: Low-level Rust tooling for EVM

There are several projects picking up steam:

• dapptools-rs
  • Symbolic execution especially
  • hevm replacement
  • great interactive debugger
• evm-rs - rust evm
• evmodin - rust evm by erigon team
• etk - evm toolkit, mainly an assembler / disassembler, but also many other aspirations

dm me on discord or twitter for more info - there are a handful of group chats I can link people up with who are interested

Project Idea: Improve testing infrastructure for JSON-RPC apis

We've been working recently to create a canonical specification for the JSON-RPC api in execution clients. Progress has been relatively good so far, but we're reaching the limits of what's possible without more serious testing infrastructure.

A few things that I think could be done:

• integrate the Open RPC spec into Hive and test edge cases against clients to make sure they are all in agreement and that spec is in agreement
• some sort of intelligent fuzzing of the RPCs, while validating responses against the spec
• generally improving the readability of the spec

dm me on discord or twitter for more info

Eu