A little bit about myself:

Hello all, I'm Aritra. (You can refer to these blogs to know more about me). Without much introduction, let's dive into what I've been up to this summer and what I will continue working on.

Progress till now

One of the core components I worked on is the Braid data structure, which is the heart of our BlockDAG implementation. Let me show you what it looks like: 

#[derive(Clone, Debug)]
pub struct Braid {
    pub beads: Vec<Bead>,
    pub tips: HashSet<usize>,
    pub cohorts: Vec<Cohort>,
    pub cohort_tips: Vec<HashSet<usize>>,
    pub orphan_beads: Vec<Bead>,
    pub genesis_beads: HashSet<usize>,
    pub bead_index_mapping: HashMap<BeadHash, usize>,
    pub parents: HashMap<usize, HashSet<usize>>,
    pub children: HashMap<usize, HashSet<usize>>,
}

impl Braid {
    /// Attempts to extend the braid with the given bead.
    /// Returns true if the bead successfully extended the braid, false otherwise.
    pub fn extend(&mut self, bead: &Bead) -> AddBeadStatus {
        // Check if bead already exists
        let bead_hash = bead.block_header.block_hash();
        if self.beads.iter().any(|b| b.block_header.block_hash() == bead_hash) {
            return AddBeadStatus::DagAlreadyContainsBead;
        }

        // Verify all parents are available
        for parent_hash in &bead.committed_metadata.parents {
            if !self.bead_index_mapping.contains_key(parent_hash) {
                self.orphan_beads.push(bead.clone());
                return AddBeadStatus::ParentsNotYetReceived;
            }
        }

        // Add bead to the DAG structure
        self.beads.push(bead.clone());
        let new_bead_index = self.beads.len() - 1;
        self.bead_index_mapping.insert(bead_hash, new_bead_index);

        // Update parent-child relationships
        // Update tips (leaf nodes of the DAG)
        // Reorganize cohorts for consensus ordering
        
        AddBeadStatus::BeadAdded
    }
}
Rust

Let me break down what each part of the Braid struct does:

  • beads: Stores all the beads (weak blocks) in our DAG
  • tips: Keeps track of the "leaf nodes" - beads with no children yet
  • cohorts: Groups beads that can be processed together for consensus
  • orphan_beads: Temporary storage for beads whose parents haven't arrived yet
  • bead_index_mapping: Quick lookup from bead hash to its position in the array
  • parents/children: Maps showing which beads reference each other

The extend function is where the magic happens. When a new bead arrives, it goes through several checks:

  1. Duplicate check: Make sure we haven't seen this bead before
  2. Parent validation: Verify all parent beads are already in our DAG
  3. Orphan handling: If parents are missing, store the bead temporarily
  4. DAG integration: Add the bead and update all the relationship mappings
  5. Tip management: Remove parents from tips, add new bead as a tip
  6. Cohort reorganization: Group beads for proper consensus ordering

This design lets us handle beads arriving out of order while maintaining the DAG structure needed for consensus. It's pretty cool how a BlockDAG can handle multiple concurrent chains unlike a traditional blockchain!
Apart from that, we have also implemented the RPC interface for the frontend client to interact with our DAG.

Pull requests



Beyond the Internship

The internship period has officially ended, but we have planned to collaborate to continue improving the project. We still have a lot of work to do. I will briefly explain the key areas I will try to focus on.

  • Implementing Difficulty Adjustment Algorithm: Currently, we are working on integrating the descendant work and highest work path algorithm so that we can start adding beads to the braid server. But we still need to implement a difficulty adjustment algorithm to ensure the network remains stable, efficient and fault tolerant. We also need to explore and test different algorithms for this.
  • RPC endpoints: Currently we have a few basic RPC endpoints. But, most of the planned RPC endpoints need us to implement the highest work path and functionality to support them.
  • Integrating Miners: We already have dedicated frontend components for miner management, but we need to implement the backend logic to support miner registration, job assignment, and result collection. It's challenging to integrate all kinds of miners and we are planning to use PyASIC for this. Our initial plan is to write an LLM based Rust translation and use that in the backend. We also need to register the miners in the braid database.
  • Optimizing the consensus functions: After all of these, we need to optimize the consensus functions to ensure they are efficient and can handle high throughput. This might involve refactoring some of the existing code and implementing caching mechanisms. We also need to explore possibilities for further optimization in the descendant work calculation.
  • Adding tests: Finally, we need to add comprehensive tests to ensure the reliability and stability of the system. This includes unit tests, integration tests, and end-to-end tests. We want to make sure that all components work together seamlessly and that we can catch any issues early in the development process.

Really excited to continue working on braidpool and contribute to its success! I am immensely grateful for the opportunity to work with such a talented team and to be a part of this innovative project. Every discussion with Bob, Ansh, Priya, Abhishek, Abdullah and Mohd has been a valuable learning experience. Again, thanks to Adi and Summer of Bitcoin for this opportunity!

P.S. The character in the background is Monkey D. Luffy from One Piece. The character below is Portgas D. Ace from One Piece again.


Ace