Try   HackMD

EPF Week 11 and 12

In the weekly meeting I discussed about the database layer of Nimbus. Zahary shared that they are going to change to a db which a flat database (similar to besu) and has very good performance so integrating verkle trie should not be a problem.

After getting the updates from everyone - seems like we are close to the completion.

Nim trie + Rust Crypto

Now to do comparative testing I will import the Rust libraries used for commitments into our project. This is going to be very tricky (not even sure if it would work).

Different tests has shown that rust cryptography is defineatly slower but since we have to do the comparative testing taking into account the trie we will have to integrate it.

Todo

  • Attempt to compile the Rust Banderwagon library into a library format Nim can interface with (e.g. DLL). As well as other libraries used as part of Commitments computation.
  • Extend these libraries with required markup on exported methods (e.g. C calling convention, extern)
  • Add them as submodules in our git repo
  • Create a Makefile to compile them, and to run nbindgen to generate header files
  • Have our project import these headers and make the exported methods accessible in Nim

After this is done - I will be on my last step i.e. integrating Nim trie + Nim Crypto 🚀

Real-World Test

This issue has been very painful. I researched about this during start and left for the end because this is performance analysis.
I took this issue up again and later realized that I am not able to setup a node because of large storage requirement (Verkle tries aim to solve this 😉).

Coincidentely I talked with Tanishq and he suggested me that this is not useful because the algorithm done is similar to bulk converstion method i.e. basically walking the state tree and re-inserting all key-values in a fresh VKT. Code

And Ignacio and Gballet are bringing up the Kaustinen testnet again. After that is stable, Guillaume had the idea of trying to export the initial state plus some blocks and start building a kind of test-vector based on the testnet.
That's pretty useful to have some self-contained test data that we need! Eliminating the need of doing this test.

Verkle Tree Structure Blog

I have started to write a blog on Verkle tree structure

This blog - Verkle tree structure by EF has many parts that can be explained in a better way for first time readers - Aim to solve this

Last changed by 
 
Naman Garg
0
57

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