Summary

This week quite heavy on learning at the depths, it was like a rabbit hole which I felt like keep going down. I dived deep into the consensus layer of eth2. I learnt about the Byzantine Generals Problem, and the Practical Byzantine Fault Tolerance (PBFT). I also learnt about the LMD GHOST and the Casper FFG. I also learnt about the different clients and their implementations. I also learnt about the different types of validators and the different types of attestations.

Also back of the mind I frequently kept navigating about the possible areas in which I could be working on and making contributions, also what I would be interested to learn and make some contributions. For now I think my contributions areas would majorly will be

    • Nimbus
    • execution-apis
    • lighthouse
    • verkle tree implementation in Nim

I also read about the Ephemery Testnet, I am interested in it, but not sure what are the exact areas which requires significant contributions in it. I will be exploring it further, and also discussing about the in which directions I should be trying to make the improvements.
In the coming week I decide to narrow down and finalize 2-3 areas in which I will be making contributions. This is help me to focus on the specific areas and make significant contributions in those areas.

Learning

Started with learning about The Byzantine Generals Problem. It is a classic computer science challenge that explores how to achieve consensus among unreliable participants in the presence of potential traitors. It has implications in distributed systems and fault-tolerant algorithms, offering insights into the complexities of consensus in real-world scenarios with unreliable nodes.

Then I learnt about the Practical Byzantine Fault Tolerance (PBFT), this provides a possible solution the previous mentioned problem.
This exploration was part of the extended reading of the Eth2Book, also it just updated the new section for Casper FFG. Give it a read if possible.

While learning about the consensus layer or the beacon chain, I came to various resources but one of the best resources I found was this video. It provides both the zoomed out and zoomed in view of the consensus mechanism. This gave me a much better clarity on the consensus layer. This blog also gave a huge insight on the consensus layer. Also during the a question came up to my mind which was unanswered over ethereum stack exchange, “What is the difference between Votes and Attestations?” initally it seemed simple, but later I got a bit confused, so again started reading the nitigrity details of the

class AttestationData(Container):
    slot: Slot
    index: CommitteeIndex
    # LMD GHOST vote
    beacon_block_root: Root
    # FFG vote
    source: Checkpoint
    target: Checkpoint

It was a bit confusing, but I finally gave a try answering the question, and I think I got it right. Here is the link to the answer.

While learning experimentation is good, atleast for me. So I also played around with different clients geth, nimbus, reth. Spinning up private networks, making different types of genesis files, etc. This also gave me a better understanding of how the bootnode works and why it is needed. Also tried teku & besu together, but didn’t explore it much.
Was also exploring good-first issues in the reth & geth clients. I found some issues which interested me. Also I realized that I need a refresh on my rust skills. So for a quick refresher project I make a simple TCP-client-server in rust, and then made a simple API over HTTP in rust. This helped me to get back my fluency in rust.

I also took time to understand the splitting of validators & time slots and epochs. Each epoch is of 32 time slots and each time slot is of 12 seconds. So each epoch is of 384 seconds. And each validator is assigned to a time slot, and each time slot has a committee. So each validator is assigned to a committee.
All validators are randomly split into 32 committees. And each committee is responsible for 1 time slot in the epoch. The first member of the committee is the proposer for the time slot. And the rest of the committee members are supposed to provide attestation for the block proposed by the proposer. This is the basic idea of how the consensus works.

Others

  • Started to explore the JSON-RPC wrapper and the other improvements that are needed. Also joined the telegram created for ethereum/execution-apis
  • while learning about the consensus layer, somehow got interested in the polygon core implementation, so gave it a read.
  • took a look at the staking contract code
  • continued learning Nim
  • EthCC hapenning and as I couldn’t attend, keeping an eye on the updates, majorly in the core-protocol area.