Try   HackMD

EPF Week 6 and 7

Gm everyone! I am working on Verkle tree implementation for the Nimbus client.

I talked with Mario and he helped me realize that contributing to Nimbus and Besu both might be too much work and focusing on one of them will be better idea and keeping the other for later, which I completely agree with so I am focusing on Nim implementation first.

Research

  • Reading and understanding about the verkle tree structure: I read this in the starting weeks also and thought I understood but when now I started to code, I started getting a lot of doubts. The major reason for this was because it is difficult to visualize verkle tree operations - there is no tool for this.
  • Real-world test: I researched on solving this issue and discussed the possibilities and its importance with Daniel, Gballet and Jsign, and concluded this

Weekly Meeting with Nimbus

This weekly meeting was really informative. Agnish, Advaita discussed a lot of cryptographic stuff with Mamy and I also catched a lot of things from their discussion.
After that I requested Daniel for a quick overview of the code structure and implementation to make sure I am not missing anything. Really appreciate Daniel for spending an hour on this. We also discussed other issues to work on next and he gave a some important pointers on Nim (vv useful).
My work is mostly comman with Daniel i.e. tree implementation part and others have with Mamy the maths part.

Development

After dicussion with Daniel, the steps concluded were -

  1. Implement deletion (insertion is done)
  2. Start implementing basic tests (ref tree_test.go)

Next Steps

  • Writing a blog/article specifically on Verkle tree structure :
    This blog is latest till now to understand, but I believe many improvements can be done, so I decided to write a better version so that anyone can implement verkles without facing problems that I did.
  • Further study the Go implementation and keep on improvising our implementation.

Appreciation

One of the things I felt this time which is an absolute dime of EPF is that you get to work under the mentorship of senior eng with years of experience and their advice and understanding is gold.

Last changed by 
 
Naman Garg
0
67

Read more

Bullshark

BullShark is a protocol that achieves Byzantine Atomic Broadcast (BAB) in a distributed system using a DAG. It lies in the DAG-Rider paradigm, optimized for the common synchronous case, and entails several main enhancements to ensure practical deployability. The core idea is to use the DAG to order transactions in a distributed Byzantine setting, and it gives a sound solution toward distributed consensus for deploying blockchain technologies. BullShark runs on a peer-to-peer message-passing model, where each message is a vertex in the DAG. The key primitive assumes a computationally bounded adversary who is allowed to corrupt at most a third of the parties. The notion of reliable link between honest parties means that all messages eventually arrive, which is what supports the operation of the protocol both in synchronous and asynchronous periods. The work adopts a GST model to be able to reason about synchronous network conditions. BullShark Core: DAG Constructions The protocol has a DAG construction at its core. Each party posts transaction proposals through messages into a DAG. In the DAG, vertices represent messages, and edges represent causal relationships. The parties make a new vertex through combining blocks of transactions and with references to messages which it has previously received. These references are either strong, hence link to vertices in the previous round, or weak, hence link to vertices in rounds which are earlier to ensure their eventual inclusion in the total order. BullShark relies on reliable broadcast mechanisms to give firm guarantees of message integrity, agreement, and validity among parties with the fact that all honest parties will eventually receive the same messages and have a consistent view of the DAG. The protocol further makes use of a global perfect coin for leader election and is charged with leaders who possess fairness and unpredictability in terms of leadership selections for message proposals. Advancing rounds in BullShark The protocol is built itself around certain conditions that drive the process of advancement. By feeding a round with enough vertices, specifically 2 f + 1, parties ensure advancement into the next. Advancing is guaranteed even when messages in the middle of the process of reaching another party are delayed. During synchronous periods, BullShark introduces timeouts to bound the round advancement protocol, and this dual approach gives the best of both worlds: very low latency and high throughput yet with liveness guarantee under worst-case asynchronous conditions

May 26, 2024
Mining Pool

https://github.com/kingstone888/hypepool

Apr 19, 2024
Consensus

https://www.paradigm.xyz/2022/07/consensus-throughput

Mar 18, 2024
Solo Home Staking

Finally my long left dream was to

Feb 21, 2024
Read more from Naman Garg
Published on HackMD