Donate to BlockDAG

FAQS

Disclaimer: Cryptocurrency may be unregulated in your jurisdiction. The value of cryptocurrencies may fluctuate. Profits may be subject to capital gains or other taxes applicable in your jurisdiction


Every contribution, regardless of its size, has a meaningful impact for our team, together have the power to bring about lasting change and forge a brighter future for everyone involved. Our community thrives on collaboration and shared commitment.The management of our community wallet rests in the capable hands of three elected members: XCat, Leopard Win, and Technix, who have earned the trust of the public through a democratic voting process. Operating as a multi-signature wallet, any spending transaction requires the authorization of at least two of these appointed Treasurers, ensuring a secure and transparent financial process.

Support Our Mission

Dev Releases

Daily Dev Releases

Greetings BlockDAG Community,&nbsp;This week, the development team made significant strides in refining our BlockDAG mining process. We focused on integrating SHA-3 hashing for enhanced security and efficiency, while also addressing debugging challenges to ensure a smooth implementation. In parallel, we explored various mining algorithms, including the RandomX protocol, to identify the optimal solution for our project. Additionally, we continued making progress on the X1 miner application, ensuring a robust and user-friendly experience for our community.

In the realm of blockchain development, the integration of offchain data with BlockDAG (Block Directed Acyclic Graph) architecture introduces a new dimension of scalability, efficiency, and flexibility. This guide explores the technical intricacies of incorporating offchain data into BlockDAG blockchain systems and the opportunities it presents for developers.

Leveraging Offchain Data in BlockDAG Blockchain Systems:

BlockDAG represents a departure from the linear structure of traditional blockchains. It utilizes a Directed Acyclic Graph (DAG) architecture, allowing for concurrent processing of multiple blocks. This enhances transaction throughput and reduces confirmation times, making it an attractive solution for high-volume environments.&nbsp;The Technical Significance of Offchain Data Offchain data refers to information stored and processed outside the main blockchain network but can be referenced or validated by onchain transactions. Incorporating offchain data into BlockDAG systemsOffers several technical advantages: &nbsp;<ul><li>Scalability: Offloading large datasets to offchain storage solutions alleviates the burden on the main blockchain network, ensuring optimal performance even with increasing transaction volumes.</li><li>Cost Efficiency: Storing data offchain reduces the cost associated with onchain storage and transaction fees, making blockchain technology more accessible and cost-effective.</li><li>Enhanced Privacy: By keeping sensitive or voluminous data offchain, developers can preserve user privacy and reduce the onchain footprint, while maintaining the integrity and immutability of critical information on the blockchain.</li></ul>

Understanding BlockDAG Blockchain Systems

Integrating offchain data with BlockDAG blockchain systems requires a strategic approach and understanding of various techniques: &nbsp;<ol><li>Hashing and Anchoring: Store cryptographic hashes of offchain data on the blockchain to ensure integrity and provide a reference point for verification. Implement algorithms like SHA-3 for secure hashing and Merkle trees for efficient data organization.</li><li>Decentralized Storage Platforms: Utilize decentralized storage solutions such as IPFS (InterPlanetary File System) or Swarm to store large datasets offchain. Implement protocols for content addressing and retrieval, such as CID (Content Identifier), to seamlessly link offchain data with onchain references.</li><li>Oracle Services: Integrate oracle services to securely fetch and validate external data. Implement smart contracts to interact with oracles and establish trustless data feeds. Consider oracles like Chainlink for decentralized and tamper-proof data oracles.</li></ol>

Strategies for Technical Integration

The technical integration of offchain data with BlockDAG blockchain systems enables developers to build a wide range of innovative applications: &nbsp;<ul><li>Supply Chain Management: Implement offchain storage for product information and use the blockchain for transaction validation, ensuring transparency and authenticity throughout the supply chain.</li><li>Decentralized Finance (DeFi): Leverage offchain data for market analytics, identity verification, and risk assessment in DeFi applications. Utilize blockchain for transparent and auditable transaction settlement.</li><li>Content Distribution: Store multimedia files offchain and utilize blockchain for copyright verification and royalty distribution. Implement decentralized content delivery networks (CDNs) for efficient content distribution.</li></ul>

Applications and Use Cases

By embracing offchain data integration, developers can unlock the full potential of BlockDAG blockchain systems, achieving unparalleled scalability, efficiency, and privacy. Understanding the technical nuances of offchain data integration empowers developers to architect robust and innovative blockchain solutions across various industries.&nbsp;Join the journey of blockchain innovation and explore the endless possibilities of offchain data integration in BlockDAG blockchain systems.&nbsp;<img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f31f.png" alt=":star2:" width="22" height="22"> Exciting News Alert! <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f680.png" alt=":rocket:" width="22" height="22"> Our Beta Version of X1 Miner App is Ready for Approval in 24 Hours! <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f31f.png" alt=":star2:" width="22" height="22"><img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f680.png" alt=":rocket:" width="22" height="22"> Hold onto your hats, folks! <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f680.png" alt=":rocket:" width="22" height="22">&nbsp;The moment we've all been eagerly anticipating is almost here. Our team has been hard at work crafting something truly extraordinary, and we're thrilled to announce that the beta version of our app is set to be submitted for approval within the next 24 hours!&nbsp;<img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f31f.png" alt=":star2:" width="22" height="22"> Crafting Brilliance: <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f31f.png" alt=":star2:" width="22" height="22"> This is a major milestone in our journey, marking the culmination of countless hours of dedication and innovation. From the initial spark of an idea to the meticulous design process, we've poured our hearts and souls into making this app the best it can be. Every line of code, every pixel perfected—it all comes together to create an experience that's truly exceptional.<img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f4a1.png" alt=":bulb:" width="22" height="22"> Innovative Features: <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f4a1.png" alt=":bulb:" width="22" height="22"> But what makes our app stand out from the rest? It's not just about aesthetics—though our sleek design is certainly eye-catching. It's about the innovative features that set us apart from the crowd. From advanced mining algorithms to intuitive user interfaces, we've thought of everything to ensure that your experience with our app is nothing short of extraordinary.<img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f4f1.png" alt=":iphone:" width="22" height="22"> Unleashing Greatness: <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f4f1.png" alt=":iphone:" width="22" height="22"> Stay tuned for more updates as we prepare to unleash our app on the world. The countdown to launch is officially on—get ready to experience greatness! <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f389.png" alt=":tada:" width="22" height="22">&nbsp;<img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f310.png" alt=":globe_with_meridians:" width="22" height="22"> Navigating the Blockchain Landscape: <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f310.png" alt=":globe_with_meridians:" width="22" height="22"> But our journey doesn't end here. As we prepare to enter the next phase of development, we're committed to staying at the forefront of blockchain technology. Stay tuned for further insights and developments as we navigate the dynamic landscape of blockchain technology and X1 Miner application. The future is bright, and we can't wait to embark on this journey with you. Together, let's redefine what's possible in the world of blockchain technology.

Conclusion

Dev Release 33

Greetings BlockDAG Community,&nbsp;Developing SHA3, the cryptographic hash function, wasn't a straightforward task, especially when integrating it into a BlockDAG blockchain system. Here's a fictionalized story of the challenges we faced during the development process.

In the heart of our development lab, a team of blockchain engineers gathered around a whiteboard, deep in discussion about implementing SHA3 into our BlockDAG protocol. The excitement of enhancing security and efficiency in our blockchain was palpable, but little did we know the hurdles that lay ahead.The journey began optimistically, with our team diving headfirst into the specifications of SHA3. We meticulously dissected the algorithm, understanding its inner workings and cryptographic properties. However, as we delved deeper, we realized that integrating SHA3 into our BlockDAG architecture was not as seamless as we initially thought. One of the first challenges we encountered was the computational overhead.&nbsp;&nbsp;SHA3, being a complex cryptographic algorithm, demanded significant computational resources. In BlockDAG system where every node is expected to perform numerous hash calculations, this posed a scalability issue. Our early simulations revealed a notable increase in processing time and resource consumption, threatening the system's performance.To mitigate this, we experimented with various optimization techniques, from parallel processing to hardware acceleration. While these approaches showed promise in reducing computation time, they introduced new complexities in maintaining consensus and synchronicity across the BlockDAG. Achieving a delicate balance between performance and security became our paramount concern. As we pushed forward, another obstacle emerged – data fragmentation. BlockDAGs, unlike traditional blockchains, store data in a more distributed and interconnected manner. This posed a challenge for SHA3, which relies on sequential hashing of data blocks. Our attempts to adapt SHA3 to accommodate the dynamic structure of a BlockDAG led to data fragmentation issues, compromising the integrity of the blockchain.In our pursuit of a solution, we revisited the fundamentals of BlockDAG architecture, exploring novel approaches to data organization and traversal. By reimagining how transactions were propagated and validated within the BlockDAG, we devised a hybrid hashing scheme that leveraged both SHA3 and customized cryptographic primitives tailored to the DAG structure. This hybrid approach not only addressed data fragmentation but also enhanced the overall security and efficiency of our blockchain.After this much of effort and collaboration, we finally achieved a breakthrough – a robust implementation of SHA3 within our BlockDAG protocol. Our blockchain now stood resilient against security threats while maintaining scalability and decentralization. The challenges we faced along the way had not only tested our technical prowess but also forged a stronger, more resilient team ready to tackle the next frontier in blockchain innovation.

SHA-3 in BlockDAG:

Apart from the blockchain development, a parallel team is working on the X1 miner application, let's get into the current progress for that commitment: As we're near to the delivery of the first phase of X1 Miner application, we are working on security pointers for the App users and for their privacy. We are implementing cache feature in the app so it can load without any delay. As we are also moving forward with the deployment architecture, as we are going to use Kubernetes so the App backend will be up all the time and it will be able to manage all of the users seamlessly.&nbsp;Our Beta Version of X1 Miner App is Ready for App Store Approvals in 24-48 Hours! <img src="https://a.slack-edge.com/production-standard-emoji-assets/14.0/google-medium/1f31f@2x.png" alt=":star2:" width="22" height="22">&nbsp;Hold onto your hats, folks! The moment we've all been eagerly anticipating is almost here. Our team has been hard at work crafting something truly extraordinary, and we're thrilled to announce that the beta version of our app is set to be submitted for approval on all app stores within the next 24 to 48 hours! Ready for launch on June 1st. &nbsp;

X1 Miner application status:

Dev Release 32

Greetings BlockDAG Community, Today was all about continuing our implementing process in blockDAG mining techniques. It was more about the debugging part in the mining implementation to resolve the existing error that we were facing in yesterday's implementation part and less of the coding part. Still there were few successful implementation that was done during the day. Let's delve deeper into the more advanced techniques and considerations for leveraging our BlockDAG algorithm.

To maximize the effectiveness of SHA-3 within the BlockDAG ecosystem, we're introducing several optimizations: &nbsp;<ul><li>Parallelization: Utilizing multi-threading or parallel processing techniques can significantly enhance mining performance. By dividing the workload across multiple cores or nodes, miners can expedite the hashing process, increasing overall throughput.</li><li>Memory-Hard Functions: While SHA-3 offers competitive hashing speeds, integrating memory-hard functions can further deter potential ASIC dominance. Algorithms like Argon2 or BalloonHash introduce memory-intensive computations, leveling the playing field for CPU and GPU miners.</li><li>Dynamic Difficulty Adjustment: Implementing dynamic difficulty adjustment mechanisms ensures that mining remains challenging yet feasible, adapting to fluctuations in network hash rate. By fine-tuning difficulty levels based on computational power, we maintain a stable block generation rate while mitigating the risk of network congestion.</li></ul>

Optimizing SHA-3 for BlockDAG Mining

Let's refine our pseudocode to incorporate these optimizations:&nbsp;function mineBlock(transactions, previousBlockHash, targetDifficulty, numThreads):&nbsp;// This function mines a new block in the BlockDAG blockchain using SHA-3&nbsp;&nbsp;nonce = 0&nbsp;blockData = concatenate(transactions, previousBlockHash, nonce)&nbsp;&nbsp;while true:&nbsp;# Initialize an array to store hashes from different threads&nbsp;hashResults = []&nbsp;&nbsp;# Launch multiple threads for parallel hashing&nbsp; &nbsp; &nbsp; &nbsp;for i in range(numThreads):&nbsp;# Generate block data for each thread&nbsp;threadBlockData = concatenate(blockData, i)&nbsp;# Execute SHA-3 hashing in parallel&nbsp;hashResults.append(calculateSHA3(threadBlockData))&nbsp;&nbsp;# Check if any of the hashes meet the target difficulty&nbsp;for hashResult in hashResults:&nbsp;if meetsDifficulty(hashResult, targetDifficulty):&nbsp;return hashResult, nonce # Found a valid block hash&nbsp;&nbsp;# Increment the nonce for the next iteration&nbsp;nonce = nonce + numThreads

Pseudocode for Enhanced SHA-3 Mining

As we advance our understanding of SHA-3 mining, let's explore additional topics: &nbsp;<ul><li>Quantum Resistance: Assessing SHA-3's resilience against quantum computing threats is imperative for long-term blockchain security. Investigating post-quantum cryptographic primitives ensures the integrity of BlockDAG transactions in the face of evolving technological landscapes.</li><li>Network Congestion Management: Developing congestion control mechanisms enables BlockDAG networks to adapt to varying transaction volumes. By implementing efficient propagation protocols and fee structures, we enhance network scalability and user experience.</li></ul>Together, let's continue pushing the boundaries of BlockDAG mining with SHA-3, embracing innovation and collaboration to forge a more secure and resilient decentralized future.

Exploring New Topics in SHA-3 Mining

Apart from the blockchain development, a parallel team is working on the x1 miner application, let's get into the current progress for that commitment: As we're near to the delivery of the first phase of x1 Miner application, the user onboarding module is complete with the privilege of sign up through phone number and Google. Adding on, the platform has been added with the pre-sale functionality too along with the setting, notification and home functionality. Currently the phase 1 of the application is under testing and bug fixes phase. We'll be delivering the application on store shortly.

x1 Miner application status

Stay tuned for further insights and developments as we navigate the dynamic landscape of blockchain technology and x1 Miner application.

Stay tuned!

Dev Release 31

Hey BlockDAG Community, Today was all about exploring more mining algorithm techniques for BlockDAG. BlockDAG with their unique structures, require robust mechanisms to ensure data integrity and validate transactions. SHA-3 (Secure Hash Algorithm 3) emerges as a compelling contender for the hashing function within the BlockDAG mining process. Let's delve deeper into how SHA-3 integrates with BlockDAG's Proof-of-Work (PoW) consensus mechanism.

SHA-3 stands out for its sponge function capability. In essence, it can act in two modes:&nbsp;<ul><li>Hashing: Takes data of any size and produces a fixed-length output string (hash). This one-way property is crucial for ensuring data integrity in BlockDAG.</li><li>Extending: Allows for incremental data incorporation, making it adaptable to the potentially varying data sizes encountered during BlockDAG mining.</li></ul>

SHA-3: A Sponge for Secure Hashing

The core concept behind SHA-3's role in mining lies in Proof-of-Work (PoW) consensus mechanisms. Here's the gist: &nbsp;<ol><li>Block Construction: Miners prepare a block containing transaction data and a reference to the previous block's hash (ensuring immutability).</li><li>Nonce Introduction: A nonce (number used once) is added to the block data.</li><li>Hashing Challenge: The entire block data, including the nonce, is fed into the SHA-3 function.</li><li>Mining the Hash: Miners iterate through different nonce values, re-hashing the block data each time. The goal is to find a hash that falls within a specific target range (often achieved by adding leading zeroes). &nbsp;</li></ol>Pseudocode for BlockDAG Mining with SHA-3function MineBlock(blockData, difficulty):
 &nbsp; &nbsp;while True:
 &nbsp; &nbsp; nonce = GenerateRandomNonce()
 &nbsp; &nbsp; dataToHash = Concatenate(blockData, nonce)
 &nbsp; &nbsp; hash = SHA3(dataToHash)
 &nbsp; &nbsp; if CheckHashValidity(hash, difficulty):
 &nbsp; &nbsp; &nbsp; return blockData, nonce # Block is valid, return data and nonce
 &nbsp; &nbsp; else:
 &nbsp; &nbsp; &nbsp; continue # Hash doesn't meet difficulty, loop again &nbsp;Explanation:<ol><li>The MineBlock function takes the block data and mining difficulty as input.</li><li>A loop iterates until a valid hash is found.</li><li>Inside the loop, a random nonce is generated.</li><li>The block data and nonce are concatenated to form the data to be hashed.</li><li>The SHA-3 function is used to hash the data.</li><li>The CheckHashValidity function (not shown here) compares the hash with the difficulty target. This typically involves checking for a certain number of leading zeroes in the hash string.</li><li>If the hash meets the difficulty criteria, the block data and nonce are returned, indicating a successful mining operation.</li><li>If the hash fails the check, the loop continues, and a new nonce is attempted.</li></ol>

SHA-3 in Proof-of-Work (PoW)

During the implementing process of SHA-3 within our BlockDAG blockchain several steps will be included, which are hashing transactions or blocks for security and integrity within the chain. Below is a simplified pseudocode example of how SHA-3 will be implemented in our blockchain system:&nbsp;function calculateSHA3(data):
 &nbsp; &nbsp;// This function calculates the SHA-3 hash of the given data&nbsp;

 &nbsp; &nbsp;// Step 1: Initialize the SHA-3 hashing algorithm
 &nbsp; &nbsp;hash_instance = initializeSHA3()&nbsp;

 &nbsp; &nbsp;// Step 2: Update the hash with the data
 &nbsp; &nbsp;hash_instance.update(data)&nbsp;

 &nbsp; &nbsp;// Step 3: Finalize the hash and obtain the digest
 &nbsp; &nbsp;digest = hash_instance.finalize()&nbsp;

 &nbsp; &nbsp;// Return the hexadecimal representation of the digest
 &nbsp; &nbsp;return hexadecimalRepresentation(digest)&nbsp;

function mineBlock(transactions, previousBlockHash, targetDifficulty):
 &nbsp; &nbsp;// This function is responsible for mining a new block in the DAG-based blockchain&nbsp;

 &nbsp; &nbsp;nonce = 0
 &nbsp; &nbsp;blockData = concatenate(transactions, previousBlockHash, nonce)&nbsp;

 &nbsp; &nbsp;while true:
 &nbsp; &nbsp; &nbsp; &nbsp;blockHash = calculateSHA3(blockData)&nbsp;

 &nbsp; &nbsp; &nbsp; &nbsp;// Check if the block hash meets the target difficulty
 &nbsp; &nbsp; &nbsp; &nbsp;if meetsDifficulty(blockHash, targetDifficulty):
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;break &nbsp;// Found a valid block hash that satisfies the PoW condition&nbsp;

 &nbsp; &nbsp; &nbsp; &nbsp;// Increment the nonce and update the block data
 &nbsp; &nbsp; &nbsp; &nbsp;nonce = nonce + 1
 &nbsp; &nbsp; &nbsp; &nbsp;blockData = concatenate(transactions, previousBlockHash, nonce)&nbsp;

 &nbsp; &nbsp;// Return the valid block hash and nonce
 &nbsp; &nbsp;return blockHash, nonce&nbsp;

// Example usage:
// Assume transactions and previousBlockHash are defined elsewhere
targetDifficulty = "0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"
&nbsp;
// Mine a new block
validBlockHash, nonce = mineBlock(transactions, previousBlockHash, targetDifficulty)&nbsp;Here's why we are now considering SHA-3 over RandomX: &nbsp;<ul><li>Security: SHA-3 boasts a robust design, addressing potential vulnerabilities in older SHA versions.</li><li>Efficiency: It offers competitive hashing speeds compared to other secure algorithms.</li></ul>

high-level look at the algorithm

SHA-3 presents a promising avenue for BlockDAG security. However, ongoing research and development are crucial. Here's what to consider:&nbsp;<ul><li>Real-World Implementation: More BlockDAG projects need to adopt SHA-3 to solidify its position in the BlockDAG security landscape.</li><li>ASIC Resistance: The debate regarding SHA-3's impact on Application-Specific Integrated Circuits (ASICs) in mining continues. Staying updated on this evolving landscape is essential.</li></ul>

Next steps

Dev Release 30

Greeting BlockDAG Community, Hope you'll had a blasting weekend Building on our BlockDAG Mining Discussion: Following up on our conversation about mining algorithms last week, let's delve deeper into the RandomX protocol. It emerged as a promising candidate during our discussions, and we believe it warrants a closer technical examination to understand its suitability for our BlockDAG project. Key Points: &nbsp;<ul><li>We'll be resuming our exploration of BlockDAG mining implementation.</li><li>As a reminder, Mondays are typically filled with planning meetings.</li><li>Building on our initial discussion about mining algorithms, let's focus on RandomX.</li><li>We'll explore the technical aspects of RandomX to assess its viability.</li></ul>

RandomX has become a cornerstone for many blockchain projects prioritizing decentralization and fair mining practices. This Proof-of-Work (PoW) algorithm stands out for its focus on CPU utilization, making it resistant to specialized hardware like ASICs. There are various reasons why we're considering it as an optimized algorithm for us:<ul><li>Performance Optimization: While RandomX is CPU-centric, knowledge of its workings can help optimize mining software for better performance on specific CPU architectures. CPU mining allows regular users to participate in the mining process, fostering a more inclusive network.</li><li>Security Audits: Familiarity with RandomX's design principles can aid in security audits, allowing you to identify potential vulnerabilities in your own PoW implementation. The algorithm leverages established cryptographic tools like AES, Blake2, and Argon2 to ensure overall security.</li></ul>As we claim for performance and security this protocol has been our very first choice for the algorithm.

What is RandomX protocol and let's understand the importance for us

RandomX achieves its CPU-friendliness and ASIC resistance through a combination of techniques:<ol><li>Random Code Execution:</li></ol><ul><li>Pseudo Code:</li></ul>function GenerateRandomInstruction():
 // Generate random instruction from SRVVM instruction set
 // (integer/floating-point arithmetic, conditional branches, memory access)
 return instruction&nbsp;

 function GenerateProgram():
 program = []
 for i in range(program_size):
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; program.append(GenerateRandomInstruction())
 return program&nbsp;&nbsp;<ul><li>The algorithm dynamically generates instructions (code) at runtime using the SRVVM instruction set.</li><li>This thwarts ASICs, which are designed to excel at executing pre-defined sets of instructions efficiently. &nbsp;</li></ul>Now let's get into the implementation of RandomX protocol in BlockDAG: As our blockchain is DAG (Directed Acyclic Graph) based, the mining process and consensus mechanism may differ from a traditional blockchain with a linear structure. In a BlockDAG blockchain, transactions will be represented as vertices in a graph, and blocks are not necessarily organized in a linear sequence.

RandomX in BlockDAG: A Technical Deep Dive

Here's how the RandomX algorithm could be adapted for BlockDAG: &nbsp;<ol><li>Transaction Inclusion: Miners select transactions from the DAG to include in the block they are mining. These transactions will be chosen based on factors like transaction fees and priority.</li><li>RandomX Initialization: the RandomX algorithm initializes a dataset based on the state of the DAG. However, since the DAG structure may change dynamically with new transactions, the dataset initialization process needs to account for this by incorporating the latest DAG state.</li><li>Cache Initialization: Miners create a cache from the RandomX dataset, as before, but they may need to adjust the cache creation process to accommodate the DAG structure. Each mining thread creates its own cache, potentially incorporating different parts of the dataset based on the DAG state.</li><li>Mining Process:</li></ol><ul><li>Miners execute the RandomX hashing function on the cache and the block data, as before.</li><li>The resulting hash is compared against the target difficulty, and if it meets the criteria, the miner successfully mines a block. &nbsp;</li><li>5. Verification: Other nodes in the network verify the mined block by independently executing the RandomX hashing function and validating the transactions included in the block. Since the blockchain is DAG-based, nodes may need to traverse the DAG to verify the transactions' validity.</li></ul>&nbsp;Here's a high-level pseudocode representation of the mining process: &nbsp;function RandomX(cache, input):
 &nbsp; &nbsp;// Perform a series of mathematical operations on the cache and input
 &nbsp; &nbsp;// to generate a hash result
 &nbsp; &nbsp;result = ComputeHash(cache, input)
 &nbsp; &nbsp;return result&nbsp;

function MineBlock():
 &nbsp; &nbsp;// Initialize RandomX dataset based on the current state of the DAG
 &nbsp; &nbsp;dataset = InitializeDataset()&nbsp;

 &nbsp; &nbsp;// Create cache for each mining thread
 &nbsp; &nbsp;for thread in mining_threads:
 &nbsp; &nbsp; &nbsp; &nbsp;cache[thread] = CreateCache(dataset)&nbsp;

 &nbsp; &nbsp;// Mining loop
 &nbsp; &nbsp;while true:
 &nbsp; &nbsp; &nbsp; &nbsp;for thread in mining_threads:
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Select transactions to include in the block from the DAG
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;selected_transactions = SelectTransactionsFromDAG()

 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Execute RandomX hashing function on cache and block data
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;hash_result = RandomX(cache[thread], selected_transactions)&nbsp;

 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Check if hash result meets difficulty criteria
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if hash_result &lt; target_difficulty:
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Block successfully mined
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return hash_result&nbsp;This pseudocode outlines the basic steps involved in mining a block on BlockDAG using the RandomX algorithm.

 RandomX algorithm

Here is the detailed pseudo code our implementation: &nbsp;function GenerateRandomInstruction():&nbsp; &nbsp;// Generates a random instruction from the SRVVM instruction set&nbsp; &nbsp;// (includes integer/floating-point arithmetic, conditional branches, memory access)&nbsp; &nbsp;return instruction&nbsp;function GenerateProgram():&nbsp; &nbsp;program = []&nbsp; &nbsp;for i in range(program_size):&nbsp; &nbsp; &nbsp; &nbsp;program.append(GenerateRandomInstruction())&nbsp; &nbsp;return program&nbsp;function InitializeRandomXDataset(dag):&nbsp; &nbsp;// Initialize RandomX dataset based on the current state of the DAG&nbsp; &nbsp;dataset = [] &nbsp; &nbsp;for vertex in dag.vertices:&nbsp; &nbsp; &nbsp; &nbsp;dataset.append(Hash(vertex.data))&nbsp;// Hashing each vertex's data for dataset initialization&nbsp; &nbsp;return dataset&nbsp;function CreateCache(dataset):&nbsp; &nbsp;// Create cache for RandomX computation&nbsp; &nbsp;cache = []&nbsp; &nbsp;for i in range(cache_size):&nbsp; &nbsp; &nbsp; &nbsp;cache.append(dataset[RandomIndexInRange(0, len(dataset))]) // Randomly select dataset entries for cache &nbsp; &nbsp;return cache&nbsp;function RandomX(cache, input):&nbsp; &nbsp;// Perform RandomX hashing function on cache and input&nbsp; &nbsp;result = ComputeHash(cache, input)&nbsp; &nbsp;return result&nbsp;function MineBlock(dag, mining_threads):&nbsp; &nbsp;// Initialize RandomX dataset based on the current state of the DAG&nbsp; &nbsp;dataset = InitializeRandomXDataset(dag)&nbsp;&nbsp; &nbsp;// Create cache for each mining thread&nbsp; &nbsp;for thread in mining_threads:&nbsp; &nbsp; &nbsp; &nbsp;cache[thread] = CreateCache(dataset)&nbsp;&nbsp; &nbsp;// Mining loop&nbsp; &nbsp;while true:&nbsp; &nbsp; &nbsp; &nbsp;for thread in mining_threads:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Select transactions to include in the block from the DAG&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;selected_transactions = SelectTransactionsFromDAG(dag)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Execute RandomX hashing function on cache and block data&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;hash_result = RandomX(cache[thread], selected_transactions)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Check if hash result meets difficulty criteria&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if hash_result &lt; target_difficulty:&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Block successfully mined&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return hash_result

Detailed pseudo code

As we move forward towards the core of the technical implementation these algorithms will become more and more meaningful. Stay tuned for further updates!

Dev Release 29

Greetings BlockDAG Community, Let's first go through a quick recap of this week! To start our week, we began by implementing libP2P, where we discovered the processes for identifying nodes and addresses. There were three key discovery mechanisms introduced: bootstrap nodes, mDNS, and Kademlia. Following the identification phase, we moved on to construct connections between nodes. After a successful connection, a sub-stream is established. A few basic implementation algorithms were described in conjunction with libP2P. Additionally, the request-response protocol was investigated and implemented alongside the notification protocol. Finally, synchronizing is required, thus an implementation method and rapid algorithms were developed around this. Today, we began exploring the mining process and the tactics that surround it. Let's dig into more information about today's research:

The linear holds transaction records on the blockchain by connecting a series of blocks. That each block is adding a new chain in the linear. Contrastingly, in BlockDAGs, a more sophisticated structure is introduced, where multiple blocks can be mutually referenced, forming a directed complex graph which does no longer need to have a strict linear sequence. In BlockDAG mining, the primary goal remains the same: towards the validation of transactions and to secure the network. The DAG formation based on consideration of transaction selections features a big deviation as compared to the linear blockchains. Miners in the BlockDAG network need to take into account parameters like dependency relation between the transactions, graph topology and accord rules. Let's understand a conceptual algorithm of how mining will work in blockchains based on DAG implementation:<ol><li>Transaction Validation: In a DAG, transactions are not organized into blocks that are added sequentially to a chain. Instead, each transaction directly references and validates two previous transactions. To participate in mining, nodes (or participants) in the network validate transactions by approving two previous transactions through a voting process.</li><li>Consensus Mechanism:</li></ol><ul><li>Proof of Work (PoW) in DAG: Nodes perform a small amount of computational work to validate transactions and reach consensus. However, the main focus is on approving transactions by referencing previous transactions.</li><li>Other Consensus Mechanisms: Some DAG-based blockchains use unique consensus algorithms like Tangle's "Markov Chain Monte Carlo" (MCMC) or similar voting-based systems to achieve agreement on transaction validity.</li></ul><ol><li>Approving Transactions: Miners (or nodes) in a DAG network contribute to the approval of transactions by referencing previous transactions and adding new transactions to the DAG structure. Each approved transaction confirms and strengthens the network, contributing to its security and reliability.</li><li>Transaction Confirmation: Transactions in a DAG blockchain are considered confirmed when they are referenced (approved) by subsequent transactions. This confirmation process does not rely on block creation or mining rewards in the traditional sense but instead on the collective validation and approval of transactions by network participants.</li><li>Network Growth and Security: As more transactions are added to the DAG, the network grows and becomes more secure. The structure of the DAG allows for parallel processing and potentially higher scalability compared to linear blockchains. Nodes contribute to the network's security by actively participating in the approval of transactions.</li><li>Incentives and Rewards: In some DAG-based blockchains, there may still be incentives or rewards for participants (miners) who contribute to the network's operation and security. These incentives will vary and will also include some transaction fees, network token rewards, or other mechanisms to encourage participation and network growth.</li></ol>In summary, mining in a DAG-based blockchain focuses on transaction approval and consensus through a decentralized voting process rather than traditional block creation and PoW(Proof Of Work) mechanisms. Participants contribute to the network's security and reliability by validating transactions and building on the DAG structure, leveraging its unique properties for scalable and efficient decentralized transactions.

Understanding the mining process in BlockDAG

Here's an example algorithm implementation which can be used to implement the mining process in BlockDAG. &nbsp;<ul><li>Initialization:</li><li>Inputs: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;transactions: List of transactions to be included in the new block. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;previousBlockHash: Hash of the previous block in the blockchain.</li><li>&nbsp; &nbsp; &nbsp;difficulty: Mining difficulty level (e.g., number of leading zeros required in the block hash) &nbsp;</li><li>Mining Loop: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Initialize nonce to 0.</li><li>Repeat the following steps until a valid block hash is found:</li><li>Construct Block Data:</li><li>Create block data containing: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;index: Index of the new block (incremented from the previous block index). &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;previousBlockHash: Hash of the previous block. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;transactions: List of transactions. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; timestamp: Current timestamp. &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp;nonce: Current nonce value.</li><li>Calculate Block Hash:</li><li>Calculate the hash of the block data using a cryptographic hash function (e.g., SHA-256).</li><li>Check Difficulty:</li><li>Verify if the calculated block hash meets the required mining difficulty: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Convert the hash into a binary string. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Count the number of leading zeros in the binary string. &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Compare the count of leading zeros with the specified difficulty.</li><li>Increment Nonce: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; If the block hash does not meet the difficulty, increment the nonce and repeat the calculation. &nbsp;</li><li>Block Validation:</li><li>Once a valid block hash is found (i.e., meets the required difficulty), create a new block:</li><li>Assign the calculated block hash to the hash field of the new block.</li><li>Create a new block object with the index, previous block hash, transactions, timestamp, nonce, and calculated hash. &nbsp;</li><li>Adding to Blockchain:</li><li>Add the newly created block to the blockchain by appending it to the list of blocks.</li></ul>

An example algorithm implementation

The above mentioned algorithm is just a conceptual explanation, the actually implementation of mining will begin from next week, stay tuned for more technical dive ins!

Next steps!

Dev Release 28

Greetings BlockDAG Community, As mentioned in previous post, the next step is to start the syncing process between the nodes. Today's post is all about doing the syncing implementation in the BlockDAG project.&nbsp; Here's an introduction to what's the purpose of syncing is in our implementation. Syncing algorithm is designed to make sure that the particular chain is in the latest state and synced with the rest of the network by downloaded and importing new data as soon as possible. The node then steps in, either through the one of the initial synchronization methods mentioned above, and then the keep-up sync is used to download new blocks. These two methods satisfy the requirements for a network to produce a cryptocurrency. Syncing substreams involves the process of ensuring that a node's local representation of the BlockDAG is updated and aligned with the network's state, particularly focusing on specific substreams of interest to that node. This synchronization process is fundamental for maintaining consensus and coherence across a decentralized network where different nodes may have varying views of the DAG due to network latency and propagation delays.

Now let's understand few types of syncing processes that can be used in the implementation process: &nbsp;<ol><li>Full and light sync: By default, this is auto-sync option for the first and follow-up patterns. This algorithm starts with the current block best and downloads progressively block data from several peers in the multiple peer-to-peer streams if available. This is done so that the request will hold there till the time when they are available. Heavy nodes will fully download and execute the whole blocks while light-weighted nodes import block headers. This will be repeated repeatedly until every block is investigated from the other student until everyone has no new block to reveal. In every sync, the node has to keep the number of the block both nodes have by every peer. When peer share with us a new block or we discover new best block. Thanks to this technique when known citizen suddenly announces new information peers that are interested in it can easily react and request it. In addition to regular monitoring of the best-case blocks, we mark all the announced peer children in all branches. The synch algorithm wants to consume as much data promised by freedom modes as possible. &nbsp;</li></ol>Steps to implement the full sync process:<ul><li>Initial Block Download (IBD):</li><li>We'll start by connecting to the network and downloading the entire blockchain starting from the genesis block.</li><li>Fetch each block sequentially from network peers and store them locally.</li><li>Transaction Verification:</li><li>Validate each block and its transactions against the consensus rules (e.g., Proof of Work for Bitcoin, Proof of Stake for Ethereum) to ensure integrity.</li><li>State Update:</li><li>Process each transaction within the blocks to update the node's local state (e.g., account balances, contract states).</li><li>Compute and store the state after processing each block.</li><li>Continued Block Retrieval:</li><li>Continue downloading blocks and validating transactions until reaching the current tip of the blockchain.</li><li>Final Verification:</li><li>Validate the entire downloaded blockchain up to the latest block to confirm consistency and correctness. &nbsp;</li></ul>Steps to implement the light sync process:<ul><li>Initial Block Header Download:</li><li>Connect to the network and retrieve block headers (containing essential block information but not full transactions) from network peers.</li><li>Checkpoint Block Retrieval:</li><li>Identify specific checkpoint blocks at regular intervals (e.g., every 1,000 blocks) in the blockchain's history.</li><li>Request full blocks for these checkpoints from network peers to ensure data integrity.</li><li>State Trie Pruning:</li><li>Prune unnecessary historical state trie data to reduce storage requirements.</li><li>Discard transaction details not needed for current state verification.</li><li>Fast Sync State Retrieval:</li><li>Download recent state trie data (e.g., current account balances, contract states) from network peers without processing all historical transactions.</li><li>Validation and Verification:</li><li>Validate received checkpoint blocks and state trie data against consensus rules and cryptographic proofs.</li><li>Ensure the integrity and correctness of the blockchain up to the latest known state.</li></ul>

Few types of syncing processes 

Fast sync: The download mode is the instant one of in this mode downloads the full header history. The process of transformation of authority set operations and comes up with a most recent header is possible by that. The node checks the header chain throughput spot and saves these records. Then importing the state, a short process, starts. Each StateResponse provides a storage key, which is void for the first one. StateResponse comprises proof of storage location thus indicating where the key and all the other keys starts (but not including the key that is in the request). After running the proof trie in the storage root that is currently on target header, the node sends the next request element of StateResponse with key range that will start from that last key from the previous response. This process repeatedly carries out until the shift in trie reaches its last point. The state is then shipped to the database and the normal full/lite sync starts in your way. Steps to implement the fast sync process:<ul><li>Initialization:</li><li>Initialize the node's database and networking components.</li><li>Connect to peers in the BlockDAG network.</li><li>Download Recent Block Headers:</li><li>Initiate the synchronization process by requesting recent block headers from network peers.</li><li>Start with the genesis block and progressively download block headers up to the current tip of the BlockDAG.</li><li>Select Checkpoint Blocks:</li><li>Identify specific checkpoint blocks at regular intervals in the BlockDAG's history (e.g., every 1,000 blocks).</li><li>Request full blocks for these checkpoints from network peers to establish synchronization points.</li><li>Prune Unnecessary Data:</li><li>Prune unnecessary historical data from the node's local database to optimize storage usage.</li><li>Discard transaction details and state trie data not required for current state validation.</li><li>Retrieve Recent State Data:</li><li>Download recent state trie data (e.g., account balances, contract states) corresponding to the latest checkpoint blocks.</li><li>Fetch state data from network peers using efficient retrieval methods (e.g., Merkle proofs).</li><li>Validate State Data:</li><li>Validate the received state trie data against cryptographic proofs and consensus rules to ensure integrity.</li><li>Verify the correctness and consistency of account states and other critical data.</li><li>Finalize Synchronization:</li><li>Complete the synchronization process by confirming that the node's local state matches the state derived from the received data.</li><li>Ensure that the node has synchronized up to the latest state of the BlockDAG network.</li><li>Enable Operational Mode:</li><li>Transition the node into an operational mode, where it can participate in network activities such as transaction processing and block validation.</li></ul>

Fast sync

Warp sync: BFT sync also known as warp sync is a brand new technique utilized by blockchains such as Ethereum to speed up the process of logging a new node or syncing it with the latest state on the chain. Unlike the full synchronizing method of traditional thinking about every network node finishing downloading and verifying each block and transaction starting with the very first one, warp sync attempts to speed up the whole process. The process is started by the Initial Block Download (IBD) phase and it involves retrieving recent block headers from network peers. Contrary to the download of all historical raw data, the node regulates the checkpointing of those blocks in intervals whereby it only acquires specific checkpoint blocks—the historical blocks ranging at intervals. g. , they do mining every 10 minutes on the average (10 minutes is equivalent to about 100,000 blocks, 1 block in about every 10 minutes)—to form the bridge between the current state and the future one. These checkpoint points comprise a core element of the blockchain which have 'data sets' been verified by that particular points. Having been granted the checkpoint block nodes shave off the historical state trie's redundant information to ease on storage. Latterly "fast sync" mode is enabled in the the node where is it synchronize the recent state trie data (e. g. We will inherit the ability to validate and transfer funds, settle accounts, and get the state of contract without having so to much work on historical transactions. Steps to implement the wrap sync process:<ul><li>Initial Block Download (IBD) Phase:</li><li>The warp sync process begins with an Initial Block Download (IBD) phase where the node starts by downloading recent block headers from peers on the network.</li><li>Instead of downloading and verifying each block and transaction sequentially from the genesis block, the node focuses on retrieving the most recent block headers.</li><li>Checkpoint Synchronization:</li><li>Once a sufficient number of block headers are downloaded, the node identifies and retrieves checkpoint blocks. Checkpoint blocks are specific historical blocks chosen at regular intervals (e.g., every 100,000 blocks) that serve as synchronization points.</li><li>Checkpoint blocks are requested in full from network peers to ensure the integrity of the blockchain up to those points.</li><li>State Trie Pruning and Fast Sync:</li><li>After acquiring checkpoint blocks, the node prunes unnecessary historical state trie data, reducing storage requirements.</li><li>The node then initiates a "fast sync" mode where it retrieves recent state trie data (account balances, contract states, etc.) from network peers without downloading all historical transactions.</li><li>Validation and Verification:</li><li>As the node receives checkpoint blocks and recent state data, it validates and verifies the integrity of the blockchain up to the latest known state.</li><li>The node ensures that the received state data matches the consensus rules and cryptographic proofs of the blockchain.</li><li>Finalization and Node Activation:</li><li>Once the node has synchronized up to the latest state of the blockchain and validated the received data, it finalizes the warp sync process.</li><li>The node transitions into an operational state, where it can participate in network activities like transaction processing, block validation, and smart contract execution.</li></ul>

Warp sync

After the successful implementation of the syncing progress we will shift to the implementation of mining progress. By this once the block is generated it will be sent out to other fellow miners to validate the produced blocks.&nbsp;

Dev Release 27

Greeting BlockDAG Community, As mentioned in previous update, as a part of substream implementation in blockDAG today we're implementating request-response protocol along with notification protocol. In this technical post, we'll delve into the details of how request-response protocols function within substreams and it's importance in BlockDAG project.

Substreams are the virtual connections or data transmission channels logically created between the network nodes in a BlockDAG layout. Consequently, the existence of these side-chains enables peers to trade data and store the blocks and transactions as they are relayed across the network. For more details refer to the previous post <a href="https://blockdag.network/dev-releases/dev-release-25" target="_blank">here</a> . Purpose: Substream request-response protocol is tailored to ensure the continuation of sophisticated information querying and retrieval from peers within a distributed network. This protocol is an indispensable part of the whole cycle in tasks like block validation, consensus making and data synchronization which can result in emergence of a BlockDAG. Each request is performed in a new separate substream.

A quick recap of what substreams are and the purpose of request-response protocol

The essential elements of Request-Response method: &nbsp;<ul><li>Initiation of Requests: Node start a search by sending a special formatted request to the node it is directly connected to within a sub stream. This type of message usually contains the details of the data being requested, with inclusive participation of population, stakeholders and organizations in making a decision which means the entire history of who sent how much money to whom is recorded for everyone to see (e.g., a specific transaction or a certain block).</li><li>Handling Requests: In case of a request from a peer node, the node processes it and draws up an appropriate answer. And the answer is again to be sent back to the client via the same substream.</li><li>Response Handling: The node delivering a response will be noticed by the requesting node and the information inside it will be processed. It might be a matter of validating the block, entering it into the local register or subsequently transmitting the received data across the network.</li></ul>

Elements of Request-Response method

Deployment of request-response protocol as a primary means of internode communication in substreams within BlockDAG network entails several steps and concerns which must be taken into account to avoid potential issues. Below is a technical algorithm outline detailing how this protocol can be implemented:<ul><li>Message Structures: Create message structures that are standardized by which nodes can communicate every time with their neighbors through requests and responses. These messages should have available identifiers, data payloads, and metadata. A distinguishing code is known as an identifier; this facilitates quick tracking and identification of danger.</li></ul>&nbsp;<ul><li>Substream Establishment: Create link-branches between the elements to provide direct information channels subheadings. This is enabled by the use of TCP/IP or P2P protocols which can be customized.</li></ul>&nbsp;<ul><li>Requester Node Behavior:</li></ul>Send Request: The situation is that the when a node requires certain data, the node determines the shortest path by using the distributed network and it sends the data request to the node with the highest opportunity to generate the block. By creating a request message with a block or transaction format, it sends it via a substream to the peer node with which connection has been previously established. Wait for Response: Requester node patiently waits for reply message from the peer node, after those request messages are sent. It also a timeout option to deal with the cases where no response has been received within a timely manner. &nbsp;<ul><li>Responder Node Behavior:</li></ul>Receive Request: The peer node is the receiving get source from the substream. Process Request: On receiving a query, the peer node examines it, in case the data is available it will be retrieved and prepared for a reply before the acknowledgement message is sent by the node. Send Response: The peer node sends an acknowledgment message to the querier node using the identical substream as the one used to forward the queries. &nbsp;<ul><li>Error Handling:</li></ul>Develop mechanisms of error handling that take care of communication failures, timeouts, or incorrect requests. To do this, we will gradually increase the complexity of our systems and test their readiness by performing stress tests. Retry Mechanism: The requester node has to react in such a manner that within the time frame that has been set, if no reply is received, it retries the request, or the process is handled accordingly. &nbsp;<ul><li>Asynchronous Processing:</li></ul>Adopt asynchronous programming techniques to solve the issue of various simultaneous requests handling efficiency. Implement callback operations or event handlers to react to response messages, processing them as they come in and keeping instance as responsive as it is.

Algorithm to implement the request-response protocol

It's also a part of above protocol's implementation, below is a quick summary of how Notification protocol would work. &nbsp;<ul><li>As a handshake message is the first message which is sent when a substream is opened, it has the content of a protocol. The head message must be prefixed with a 2+bytes length number which was encoded with the LEB128. The encrypted handshake message can have a length of 0 which for the sender simply means that a single 0 must be sent.</li><li>The receiver then sends either back a LEB128-prefixed R-ack handshake to the substream closure, or answers with its own specific protocol handshake that begins with a LEB128. Along with it, the message length will also be of 0. So the receiver has to send back a single 0.</li><li>When you finished shaking hands, your communications protocol becomes unidirectional. The stream can only be revealed if the node which initiated the substream pushes out notification. If the remote also wants to send notifications, it has to open its own unidirectional substream, since the main transmission has to be multicast.</li><li>Every alert has to start with an LEB128(a)-translated length. All codecs that art transcoded for each protocol are different from the other.</li><li>Both parties, either of them can demonstrate that it doesn't want to have a notification substream by closing their writing-side. Besides, the counter message should surface immediately following the other party`s writing side.</li></ul>The sc-network API enables the registration of notification protocols as user-defined entities. sc-network will be trying automatically for each node substream to open where the previous counterpart from Legacy Substream will be opened by it. Then comes the Handshake thing without conscious thought.What is currently in place, for a manner of backward-compatibility, a group of notification protocols are joined with the legacy Substrate branch. Additionally, the handshake message is hardcoded to be a single 8-bits integer representing the role of the node: To run an accomplished full node, you shall set aside 1 GB of memory, while for much less achieved ones, 32 MB will do the secret. 2 for concealing a light source on node lighting. 4 for an authority. In addition, in the future, these restrictions will be totally scrapped.

Notification protocol in BlockDAG

<ul><li>Sending a Notification:</li></ul>A node triggers a notification event by invoking notify_peers() with specific event_type and the information in it. This function forwards the information message contain event type, data, and the event issuers address to all the peer nodes connected. &nbsp;<ul><li>Receiving and Processing Notifications:</li></ul>Every peer node receives the alert sent at render_headers() method. The receiving node examines the relevance and is configured to carry out actions based on the event type. Example implementation: &nbsp;&nbsp; &nbsp; # Create BlockDAG&nbsp; &nbsp;nodes
 &nbsp; &nbsp;node1 = BlockDAGNode(node_id=1)
 &nbsp; &nbsp;node2 = BlockDAGNode(node_id=2)&nbsp;

 &nbsp; &nbsp;# Add peer nodes for communication
 &nbsp; &nbsp;node1.peer_nodes.append(node2)
 &nbsp; &nbsp;node2.peer_nodes.append(node1)&nbsp;

 &nbsp; &nbsp;# Simulate notification - Node 1 notifies peers about a new block
 &nbsp; &nbsp;new_block = Block(block_id=1, transactions=["Tx1", "Tx2"], parent_blocks=[])
 &nbsp; &nbsp;node1.notify_peers(event_type="new_block_received", event_data=new_block)&nbsp;

 &nbsp; &nbsp;# Node 2 receives and processes the notification
 &nbsp; &nbsp;# This triggers Node 2 to process the new block received from Node 1
 &nbsp; &nbsp;# The notification protocol can be extended to handle various types of events and data

Algorithm to implement the notification protocol

After the successful implementation of the communication protocols between the nodes and a notification service it's essential to sync all the nodes with the same information to maintain a consistency in the ledger. Therefore, the next step after this would be working on the syncing process and implementing the same.

Dev Release 26

Hey BlockDAG community! Hope you're having a great day As a part of libP2P implementation process today is all about implementing the substreams request-response protocols in blockDAG.

Substreams refer to a concept related to transaction processing and parallelism. Having already formed a channel and used multiplexing, the substream can be opened now. If the substream is live, the multistream-select protocol is used for the sessions to negotiate the protocol that will be used on that particular substream. A protocol that is customary/common to just one particular chain has a &lt;protocol-id&gt; at its mention. The "protocol ID" that is part of the chain specification is the identifier of the protocol being used. During the installation the protocol names below have to be changed with the assigned protocol ID instead of a &lt;protocol-id&gt; .

Let's understand about sub-streams

<ul><li>/ipfs/ping/1.0.0 : At times the main channel diverts and joins a temporary minor canyon in order to contact the remote party and check if it is still switched on. In the case of a missed response, the remote will cause the player to disconnect.</li><li>/ipfs/id/1.0.0:&nbsp; Part of our natural resource conservation efforts is to have an occasional short-lived stream where we would obtain information from remotely.</li><li>/&lt;protocol_id&gt;/kad: &nbsp;We do this every now and then by using the conversion operator to open fleeting substreams of Kademlia or random walks. Each query of Kademlia searches for appropriate swarm's substreams separately.</li></ul>

Following are the standard libP2P protocols

Here's a basic implementation of libP2P protocol in blockDAG:&nbsp;<ol><li>Initialize libp2p Node</li></ol><ul><li>Set up a libp2p node instance with required configuration (e.g., peer identity, transport, host address).</li></ul>Configure supported transports (e.g., TCP/IP, WebSockets) and encryption options. 2. Define Protocol ID<ul><li>Choose a unique protocol ID for your custom protocol (e.g., /myapp/1.0.0).</li></ul>This ID will be used to identify and multiplex your protocol over libp2p connections.&nbsp; 3. Implement Protocol Handler<ul><li>Define a message format for your protocol (e.g., using Protocol Buffers, JSON, or custom serialization).</li><li>Implement handler functions to handle incoming and outgoing protocol messages.</li></ul>const myProtocolHandler = {
 &nbsp; // Handle incoming messages
 &nbsp; async handle(stream) &nbsp;{
 &nbsp; &nbsp;for await (const message of stream) {
 &nbsp; &nbsp; &nbsp;console.log('Received message:', message.toString());
 &nbsp; &nbsp;}
 &nbsp;},
&nbsp; // Send a message
 &nbsp;async send(stream, message) {
 &nbsp; &nbsp;await stream.write(message);
 &nbsp;}
 &nbsp; &nbsp;};&nbsp;&nbsp;4. Register Protocol Handler<ul><li>Register your protocol handler with the libp2p node.</li><li>Specify the protocol ID and the handler functions.</li></ul>await node.handle('/myapp/1.0.0', async (protocol, stream) =&gt; {
 &nbsp;await myProtocolHandler.handle(stream);
});&nbsp;5. Start libp2p Node<ul><li>Start the libp2p node and listen for incoming connections.</li><li>Handle incoming connections and protocol negotiations.</li></ul>await node.start();
console.log('libp2p node started, listening on addresses:', node.multiaddrs);&nbsp;6. Establish Connections<ul><li>Connect to other libp2p peers (e.g., using peer discovery mechanisms).</li><li>Initiate protocol handshakes and establish streams for your custom protocol.</li></ul>const peerId = '...'; // ID of the peer to connect to
await node.dial(peerId);
const { stream } = await node.newStream(peerId, ['/myapp/1.0.0']); &nbsp;7. Send and Receive Messages<ul><li>Use the protocol handler to send and receive messages over the established stream.</li></ul>await myProtocolHandler.send(stream, 'Hello, libp2p!'); 8. Handle Errors and Cleanup<ul><li>Implement error handling and cleanup logic to gracefully shut down the libp2p node.</li><li>Close connections and release resources.</li></ul>// Gracefully stop the libp2p node
await node.stop();

Algorithm

As the putting into practice of substreams will become successful, we will carry on our way to the realization of request-response protocol in addition to notification protocol

Dev Release 25

Greetings BlockDAG Community! Surely you had the weekend of your life and I hope you had a lot of fun. In consideration to our roadmap in May, we integrate the LibP2P engine in blockDAG . The libp2p framework is highly flexible, users to expand this library to support other protocols.

In a network without a center, every node takes a network private key and a network public key. Starting with the node's public key, the process of identifying the node is begun. Libp2p, the communication method employed by Sia, relies on the [PeerId] struct to identify each node. These make it impossible for both ends in the communication of networks to create a fake identity, as their keys are the keys to encryption that are used by all nodes. A node’s identity always sets off as a unique identifier on the network and it is merely to distinguish different machine. If we simultaneously diversify network key data, there is a higher chance to encounter large interferences

Node identities and addresses

In order to join certain peer-to-peer network our node is required to know a list of nodes that are already included in that network. In this regard, it is pertinent to mention node's details and their address (how to be connected them). Formation of such a list can be referred to as the discovery approach. There are three mechanisms that will be used in blockDAG:<ul><li>Bootstrap nodes. The are bootstrap nodes in which node identities and addresses are specified in the netcode in seated next to the configuration of the network.</li><li>mDNS. Here we do a UDP broadcast on the tracts network Nodes exhibiting this characteristic will authenticate themselves by identifying themselves to the authority. mDNS can be disabled at Network configuration settings.</li><li>Kademlia random walk. Afterwards, we execute the Kademlia FIND_NODE requests that are random on our stack of Kademlia DHTs (one request using a DHT for each chain-specific protocol) to help other nodes broadcast their view of the network to us.</li></ul>

Discovery mechanisms

When node Alice indices node Bob's identity and address, it means she can build a connection with node Bob. Each link must necessarily employ multilevel encryption and meet high standards of security. Similarly, although (eg. addresses using /quic) represents the encryption, and /multiplex addresses of which encryption and/or multiplexing to use, the multistream-select protocol is used to negotiate a choice for /encrypt and/or /multiplex. The process used to set up the connection is the transport and is usually referred to as the transport layer. As of the writing of this documentation, the following base-layer protocols are supported by BlockDAG:<ul><li>The IP/TCP model, a path of the format /ip4/1.2.3.4/tcp/5, is more commonly used now for this type of work. Upon the opening of TCP highway, there are handshakes concluding with an SSL session and multiplexing arranged.</li><li>WebSockets with /ip4/1.2.3.4/tcp/5/ws being the designated address. An open TCP/IP connection is now running with WebSockets protocol performed on top. Message communication between the components (Sender and the Asynchronous Server) happens through those WebSocket data frames. Despite all the progress in previous channels encryption and multiplexing get negotiated again in this channel.</li><li>DNS for the /dns/example.com/tcp/5 or /dns/example.com/tcp/5/ws. address pattern is one of the services supported by the resource. A node address can use a domain name.</li></ul>(This being the case, the IPv6 will be used instead of IPv4 for all the above stated.) Most notable is the usage of Noise protocol which is negotiated between the base-layer protocol and the application level. In the final version, we intend to carry out an observation-based study of the handshake protocols which dynamics can greatly vary even from population to population and thus the experimental setup will be likely changed. The following multiplexing protocols are supported: Yamux.

Connection establishment

We are going to integrate Substreams request-response protocols with core bank-wallet communications. Such technical frameworks give the adopted "LibP2P engine" a foundational structure for working with blockDAG securely transmitting information amongst the network peers.&nbsp;

Dev Release 24

Greeting BlockDAG Community!This week marked significant progress on the P2P implementation front for BlockDAG, paving the way for faster and more secure communication between nodes. Key Highlights: &nbsp;<ul><li>P2P Fundamentals: We delved into the core concepts of P2P networking and explored its potential integration within the BlockDAG chain.</li><li>Protocol Exploration: We examined various P2P protocols, including the gossip protocol, and analyzed their applicability within our architecture.</li><li>Network Building: We laid the groundwork for robust node-to-node communication by implementing stream channels and the MPSC (Multi Procedure Single Consumer) pattern.</li><li>Remote procedure call (RPC): Integrating RPCs into a BlockDAG system is crucial for enabling external interactions and providing a seamless user experience.</li></ul>This is an ongoing effort. Since we have crux of previous days now, Today, I'm thrilled to introduce libP2P, a high-performance, modular, and developer-friendly P2P library specifically designed for blockDAG projects.

libP2P offers a comprehensive suite of tools and functionalities to seamlessly integrate P2P networking. It empowers developers to establish a robust P2P network, provides simplified node management, modular design and flexibility. Using libP2P in blockDAG:1. Integration with blockDAG blockchain: &nbsp;<ul><li>Runtime Integration: libP2P seamlessly integrates with the runtime environment. This allows developers to leverage features like modules, pallets, and off-chain workers for efficient P2P functionality within their blockchain applications.</li><li>Event System: libP2P can subscribe to and emit events within the runtime environment. This enables communication between the P2P network and the blockchain logic, facilitating data exchange and triggering blockchain actions based on network events.</li></ul>2. blockDAG-Specific Features: &nbsp;<ul><li>Customizable Network Topologies: modular design allows libP2P to be adapted to various network topologies beyond the typical mesh networks used in traditional blockDAG projects. This opens doors for exploring alternative network structures like directed acyclic graphs (DAGs) or hybrid approaches.</li><li>Integration with the Consensus Mechanisms: libP2P can be integrated with the POW consensus, when miners mine the block they will broadcast it to the network.</li></ul>3. Advanced P2P Functionalities: &nbsp;<ul><li>State Synchronization: libP2P can be used to implement state synchronization mechanisms, ensuring that all nodes within the network maintain a consistent view of the blockchain state. This is crucial for maintaining data integrity and enabling efficient block validation.</li><li>Incentive Mechanisms: the pallet framework allows for the implementation of custom incentive mechanisms within libP2P. This could involve token-based rewards or other economic models to encourage node participation and maintain network health.</li></ul><figure class="image"><img style="aspect-ratio:1450/811;" src="http://res.cloudinary.com/dxqhh15dp/image/upload/v1714740969/softawepost/eswabcj6336rgkrkgvqq.png" width="1450" height="811"></figure>

What is libP2P?

While the core functionalities of libP2P like node discovery and communication are crucial, understanding a specific application like block propagation within a blockDAG context provides a deeper insight into its technical capabilities. Here's an outline of a possible algorithm:&nbsp;1. Block Reception:<ul><li>When a node receives a new block from a neighbor, it verifies the block's signature and validates its adherence to the blockDAG protocol rules (e.g., ensuring it references a valid parent block).</li></ul>2. Block Validation:<ul><li>The node performs necessary validation steps, such as verifying the block's content and any associated transactions. This might involve interacting with runtime for tasks like transaction execution or state updates.</li></ul>3. Gossip-based Propagation:<ul><li>If the block is valid, the node utilizes a gossip protocol to propagate the block to its connected neighbors within the P2P network. This ensures efficient dissemination of new blocks across the network.</li></ul>4. Anti-Entropy:<ul><li>To maintain data consistency, the node periodically performs anti-entropy checks with its neighbors. This involves comparing blockchains and identifying any discrepancies.</li><li>If discrepancies are found, the node initiates a process to resolve them, potentially requesting missing blocks or resolving conflicting forks.</li></ul>5. Integration with Consensus Mechanism:<ul><li>The propagated block is submitted to the chosen consensus mechanism within the blockDAG protocol.</li><li>The consensus mechanism finalizes the block and reaches agreement among nodes on its validity and inclusion in the blockchain.</li></ul>Here's a pseudocode representation of the outlined algorithm for block propagation within a blockDAG:Block Reception:function onBlockReceived(block):&nbsp; &nbsp;if isValidBlock(block) and isAdheringToProtocol(block):&nbsp; &nbsp; &nbsp; &nbsp;validateBlock(block)&nbsp; &nbsp; &nbsp; &nbsp;if blockIsValid(block):&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;propagateBlock(block)&nbsp;Block Validation: function validateBlock(block):&nbsp; &nbsp;if verifySignature(block) and validateContent(block):&nbsp; &nbsp; &nbsp; &nbsp;performTransactionValidation(block)&nbsp; &nbsp; &nbsp; &nbsp;if blockIsFullyValid(block):&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; markBlockAsValid(block)&nbsp;Gossip-based Propagation: function propagateBlock(block):&nbsp; &nbsp;for neighbor in connectedNeighbors:&nbsp; &nbsp; &nbsp; &nbsp;sendBlockToNeighbor(block, neighbor)&nbsp;Anti-Entropy: function performAntiEntropy():&nbsp; &nbsp;for neighbor in connectedNeighbors:&nbsp; &nbsp; &nbsp; &nbsp;compareBlockchainsWithNeighbor(neighbor)&nbsp; &nbsp; &nbsp; &nbsp;if discrepanciesFound():&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;resolveDiscrepanciesWithNeighbor(neighbor)&nbsp;Integration with Consensus Mechanism: function submitBlockToConsensus(block):&nbsp; &nbsp;if consensusMechanismAgrees(block):&nbsp; &nbsp; &nbsp; &nbsp;finalizeBlock(block)&nbsp; &nbsp; &nbsp; &nbsp;includeBlockInBlockchain(block)

Algorithm 

In conclusion, the introduction of libP2P represents a significant milestone in advancing the peer-to-peer networking capabilities of the blockDAG ecosystem. By seamlessly integrating libP2P into the blockDAG architecture, developers gain access to a powerful toolkit for building robust, scalable, and secure P2P networks. Moving forward, continued collaboration, innovation, and refinement will be essential to realizing the full potential of libP2P within the blockDAG ecosystem. By addressing scalability challenges, enhancing security measures, and fostering community engagement, we can build a vibrant and resilient network that enables the seamless exchange of data and transactions, paving the way for the future of decentralized applications and blockchain technology.

Conclusion & next steps!

Dev Release 23

Greetings BlockDAG community! In today's technical post, we'll explore the implementation of Remote Procedure Calls (RPC) within a BlockDAG project. Integrating RPCs into a BlockDAG system is crucial for enabling external interactions and providing a seamless user experience.

Integrating RPCs into a BlockDAG project facilitates external communication with the node or network, enabling functionalities such as: &nbsp;<ol><li>Querying node status</li><li>Submitting transactions</li><li>Retrieving block and transaction data</li><li>Managing network connections</li><li>Monitoring system health</li></ol>RPCs abstract the complexities of direct network communication, providing a convenient interface for developers and external applications to interact with the BlockDAG network. Let's understand an example implementation of Remote procedure calls: // Client-side RPC invocationfunction rpc_call(server_address, procedure_name, args): &nbsp; &nbsp; data = serialize(args) &nbsp;// Serialize arguments &nbsp; &nbsp; send_data_to_server(server_address, procedure_name, data) &nbsp;// Transmit data to server &nbsp; &nbsp; response = receive_data_from_server(server_address) &nbsp;// Receive response from server &nbsp; &nbsp; result = deserialize(response) &nbsp;// Deserialize response &nbsp; &nbsp; return result &nbsp;// Server-side RPC handlingfunction rpc_handle(procedure_name, handler_function): &nbsp; &nbsp; register_procedure(procedure_name, handler_function) &nbsp;// Register procedure with handler &nbsp; &nbsp; while true: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;request = wait_for_incoming_request() &nbsp;// Wait for incoming request &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;args = deserialize(request.data) &nbsp;// Deserialize request arguments &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;result = handler_function(args) &nbsp;// Execute handler function with arguments &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;response = serialize(result) &nbsp;// Serialize result &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;send_response_to_client(request.client_address, response) &nbsp;// Send response back to client &nbsp;In this continuation of our exploration into Remote Procedure Calls (RPC) within a BlockDAG project, let's delve into how RPCs facilitates modules of blockchain

Let's understand why do we want to implement RPC in BlockDAG project

Now let's understand few generic RPC methods that will help us in implementing this functionality into blockchain: 1. getBalance(address) Retrieves the balance associated with a given account or address on the blockchain.FUNCTION getBalance(address)
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;balance = QUERY_BALANCE(address)
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;RETURN balance &nbsp;2. sendTransaction(sender, recipient, amount, gasLimit, gasPrice) Used to initiate and broadcast a transaction from one account to another, transferring digital assets.FUNCTION sendTransaction(sender, recipient, amount, gasLimit, gasPrice)
 &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;transaction = CREATE_TRANSACTION(sender, recipient, amount, gasLimit, gasPrice)
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;transactionHash = BROADCAST_TRANSACTION(transaction)
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;RETURN transactionHash &nbsp;3. getBlock(blockNumber) Retrieves details about a specific block on the blockchain.FUNCTION getBlock(blockNumber)
 &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;blockData = QUERY_BLOCK(blockNumber)
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;RETURN blockData&nbsp;4. getTransaction(transactionHash) Fetches detailed information about a specific transaction using its unique transaction hash.FUNCTION getTransaction(transactionHash)
 &nbsp;&nbsp; &nbsp; &nbsp; transactionDetails = QUERY_TRANSACTION(transactionHash)
 &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; RETURN transactionDetails&nbsp;5. callSmartContractMethod(contractAddress, methodName, args) Enables interaction with smart contracts deployed on the blockchain by executing specific functions within the contract.FUNCTION callSmartContractMethod(contractAddress, methodName, args)
 &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; methodResult = INVOKE_SMART_CONTRACT_METHOD(contractAddress, methodName, args)
 &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; RETURN methodResult

Generic RPC methods 

RPC methods are crucial for interacting with blockchain networks, offering functionalities like querying balances, sending transactions, fetching block and transaction details, and executing smart contract methods. Implementing these methods algorithmically facilitates seamless integration of blockchain technology into various applications and use cases. Stay tuned for further insights and advanced techniques in BlockDAG development, smart contract integration, and decentralized application (dApp) deployment!

Conclusion & stay tuned!

Dev Release 22

Greeting BlockDAG community, We're currently advancing along our development roadmap, focused on integrating peer-to-peer (P2P) networks into blockDAG. An essential part of this integration is establishing effective communication channels between nodes, which requires selecting a robust algorithm for successful implementation. In today's post, we explore protocols to identify the ideal fit for BlockDAG. We've investigated two prominent techniques: stream-based communication and Multi-Producer Single-Consumer (MPSC) architectures. Let's delve into the technical specifics.

Within the context of blockDAG networking, stream channels represent logical pathways established between nodes to facilitate the transmission of critical data, such as transactions or blocks. These channels enable direct and efficient communication between nodes within a decentralized blockDAG network. Key Concepts:<ul><li>Data Transmission: Stream channels facilitate the exchange of transactions, blocks, or other network-related data directly between blockDAG nodes.</li><li>Direct Communication: Nodes communicate peer-to-peer without relying on centralized intermediaries, which enhances network resilience and decentralization.</li></ul>

Stream Channels in BlockDAG Networking

Stream channels can be implemented using various networking protocols tailored to blockDAG environments, including: &nbsp;<ul><li>TCP/IP Connections: Establish reliable and ordered stream channels for transmitting blockDAG data.</li><li>WebSocket Communication: Enable bidirectional communication over a single, long-lived connection, suitable for real-time data exchange. &nbsp;</li></ul>Benefits of Stream Channels in BlockDAG:<ol><li>Efficient Data Exchange: Optimize data transmission between blockDAG nodes, reducing latency and network overhead.</li><li>Decentralization: Enable direct peer-to-peer communication, reducing reliance on centralized infrastructure.</li><li>Resilience: Enhance network resilience by providing multiple pathways for data propagation, mitigating the impact of node failures.</li></ol>

Implementation Details & benefits

In the context of blockDAG, MPSC involves multiple nodes (producers) concurrently generating data or messages intended for consumption by a single node (consumer). This architecture necessitates synchronization and coordination to ensure efficient data delivery.

Multi-Producer Single-Consumer (MPSC) Architecture in BlockDAG

The MPSC algorithm involves several key steps tailored to blockDAG environments: &nbsp;<ol><li>Producers Initiation: Each producer node initiates data generation and message transmission.</li><li>Data/Message Delivery: Producers concurrently transmit data or messages to the single consumer node using synchronization mechanisms.</li><li>Consumer Processing: The consumer node receives and processes incoming data/messages from multiple producers.</li><li>Flow Control: Implement mechanisms to manage data/message delivery rate based on network conditions and consumer's processing capacity. &nbsp;</li></ol>Pseudocode Outline for MPSC in BlockDAG:1. Initialize Producers: - Each producer node starts generating data or messages.&nbsp; 2. Data/Message Transmission: while true: for each producer:generate_data_or_message() send_data_or_message_to_consumer() 3. Consumer Reception and Processing: while true: for each incoming data/message: process_data_or_message()&nbsp; 4. Flow Control: - Implement mechanisms to manage data/message delivery rate based on network conditions.&nbsp;5. Termination: - Close connections and handle any remaining tasks upon data consumption completion.&nbsp; &nbsp;This pseudocode provides an overview of how MPSC can be implemented in a blockDAG network, emphasizing synchronization and coordination mechanisms essential for efficient data delivery from multiple producers to a single consumer. Actual implementations would include error handling, optimization strategies, and scalability considerations tailored to specific blockDAG network requirements.

Algorithm  & Pseudocode Outline for MPSC in BlockDAG

So far we have explored these two protocols and algorithms along with its technical implementation. As the week ends we'll have more concrete decisions around the protocols and algorithms that can be implemented in BlockDAG for best results. Along with this we are also working on remote procedure calls(RPC) which refer to a mechanism that allows nodes to invoke procedures or functions on a remote blockchain node. RPC enables interactions with a blockchain network through a simple and standardized interface, abstracting away the complexities of network communication and node management

Conclusions & Next steps!

Dev Release 21

Today was a long hectic day that included various internal meetings and discussions around gossip protocol which would help us in implementation of P2P networks in blockDAG. One of the available option is the gossip protocol. Now, let's understand why this protocol came into picture.

Gossip protocols, often likened to rumor spreading in a social network, are powerful tools for distributed systems. They enable peer-to-peer communication and state management, fostering scalability and resilience. This post dives into the world of gossip protocols, exploring rumor mongering (information dissemination) and anti-entropy (data consistency) mechanisms, along with some technical algorithms to bring it all to life.

Gossip Protocols: Rumor Mongering with a Purpose (and Anti-Entropy as the Bartender)

Imagine a network of nodes, each with a piece of information. Gossip protocols establish communication channels where nodes exchange data with randomly chosen peers. This "rumor mongering" ensures information propagates throughout the network, eventually reaching all nodes. Here are some popular rumor mongering strategies:<ul><li>Push Model: Nodes with new information proactively push it to a random subset of peers. This is efficient for small updates but can overload the network with frequent pushes.</li></ul>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Here's a code snippet: function PushGossip(rumor): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;peers = select_random_peers(k) # Choose k random peers &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for peer in peers: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send_message(peer, rumor) &nbsp;<ul><li>Pull Model: Nodes periodically pull updates from randomly chosen peers. This reduces network traffic but might lead to slower information dissemination.</li></ul>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;function PullGossip(): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rumors = [] &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;peers = select_random_peers(k) # Choose k random peers &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for peer in peers: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rumors += receive_message(peer) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return rumors &nbsp;<ul><li>Push-Pull Model: A hybrid approach combining push and pull strategies, offering a balance between efficiency and information spread.</li></ul>&nbsp;&nbsp;&nbsp;&nbsp;function PushPullGossip(rumor): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Push phase &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;peers = select_random_peers(k) # Choose k random peers &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for peer in peers: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send_message(peer, rumor) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;# Pull phase (can be integrated into a separate periodic function) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rumors = receive_message_from_all_peers() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return rumors Algorithms for Effective Rumor Mongering:<ul><li>Random Gossiping: Nodes randomly select peers to exchange information with. Simple and scalable, but convergence (all nodes having the same data) can be slow.</li></ul>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;function RandomGossip(): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if has_new_rumor(): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;peer = select_random_peer() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send_message(peer, get_rumor()) &nbsp;<ul><li>Fanout Gossiping: Each node pushes information to a fixed number of random peers in each gossip round. Faster convergence than random gossiping, but requires tuning the fanout value for optimal performance.</li></ul>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;function FanoutGossip(fanout): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if has_new_rumor(): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;peers = select_random_peers(fanout) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for peer in peers: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send_message(peer, get_rumor()) &nbsp;<ul><li>Age-based Gossiping: Nodes prioritize sharing the newest information. This ensures faster propagation of critical updates.</li></ul>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;function AgeBasedGossip(): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;rumor = get_oldest_rumor() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if rumor is not None: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;peer = select_random_peer() &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;send_message(peer, rumor)

Rumor Mongering: Spreading the Word (or the Data)

As discussed internally, blockDAG (Directed Acyclic Graph) projects, gossip protocols play a crucial role in ensuring all nodes possess a consistent view of the ever-growing ledger. These protocols, akin to rumor-mongering in a social network, facilitate data dissemination and state management across the distributed network. But with various gossip protocols at our disposal, selecting the optimal one becomes paramount.&nbsp;Following Factors can Guide for Gossip Protocol Choice in BlockDAGs:<ul><li>Network Dimensions: The sheer size of the blockDAG network significantly impacts the gossip protocol choice. For smaller networks with sporadic updates, a simpler approach might suffice.</li><li>Data Update Frequency: How often new data (transactions or blocks) gets added to the blockDAG is another critical factor. Frequent updates necessitate a more efficient gossip protocol to maintain consistency.</li><li>Desired Consistency Level: The level of consistency required between nodes in the blockDAG network dictates the complexity of the gossip protocol. Higher consistency demands a more robust approach.</li></ul>

Now comes a very important decision of choosing the correct algorithm for blockDAG project.

<ul><li>Small Networks with Infrequent Updates: For fledgling blockDAGs with a limited number of nodes and infrequent data additions, a basic random gossiping protocol combined with periodic state exchange for anti-entropy can be adequate. This approach ensures all nodes eventually receive the updates, albeit at a slower pace.</li><li>Larger Networks or Frequent Updates: As the blockDAG scales or experiences a surge in data updates, a more efficient strategy becomes necessary. Here, fanout gossiping shines. By sending information to a fixed number of randomly chosen peers in each gossip round, fanout gossiping achieves faster information propagation compared to random gossiping. To further optimize network traffic, consider employing digest-based anti-entropy. Nodes exchange digests (checksums) of their data first. If digests differ, only the changed portions are exchanged, reducing bandwidth consumption.</li><li>High Consistency Scenarios: For blockDAG applications demanding a high degree of consistency between nodes, a more sophisticated approach is recommended. Merkle tree-based anti-entropy paired with age-based gossiping provides a potent combination. Merkle trees allow efficient identification of data inconsistencies, while age-based gossiping prioritizes the spread of the latest information, ensuring rapid convergence to a consistent state.</li></ul>

Matching Gossip Protocols to BlockDAG Needs

By tomorrow we'll be able to finalize the gossip protocol that we'll be using and also soon after that we'll delve into the networking between nodes which includes the following concepts; streams , MPSC(multi producer single consumer ) channels, yamux : multiplexing.&nbsp;So, stay tuned for more conclusions around the same.

Dev Release 20

Greetings community! Hope you all had a great weekend This week at BlockDAG project, we're obsessed with pushing the boundaries of blockchain technology. One key area of focus is the power of peer-to-peer (P2P) networks to unlock true scalability and usher in a new era of decentralized applications. By the end of day we came up with an example implementation that we're excited to share with community through today's dev release. Let's jump in!

Traditional blockchains often rely on centralized servers or complex mining mechanisms, creating bottlenecks that hinder transaction speed and network efficiency. P2P networks offer a revolutionary alternative. In a P2P blockchain like blockDAG, each node acts as both a client and a server.

The Power of P2P

BlockDAG's P2P network leverages several key algorithms to achieve its impressive performance: &nbsp;<ol><li>Gossip Protocols: These protocols enable efficient message propagation across the network. Nodes share information with their peers, ensuring all participants are updated on the latest transactions. Popular gossip protocols used in P2P blockchains include:</li></ol>&nbsp;a. Binary Gossiping Protocol (BGP): BGP leverages a push-based approach, where nodes actively push messages to a randomly chosen subset of their peers. This code snippet (in Python) demonstrates a simplified example of BGP message broadcasting: def broadcast_gossip(self, message): &nbsp;&nbsp;# Select a random subset of connected peers &nbsp;&nbsp;peers = random.sample(self.connected_nodes, k=self.fanout) &nbsp;&nbsp;# Send the message to each selected peer &nbsp;&nbsp;for peer in peers: &nbsp;&nbsp;&nbsp;&nbsp;peer.send_message(message) b. Directed Acyclic Graph (DAG) Gossiping Protocol: This protocol leverages the structure of the blockDAG itself for message propagation. Nodes only share transactions with their parents in the DAG, reducing message redundancy and improving efficiency. 2. Consensus Mechanisms:&nbsp; These algorithms ensure agreement among nodes on the validity of transactions and the current state of the ledger. In blockDAG, you might consider employing a variant of Byzantine Fault Tolerance (BFT) consensus, specifically designed for asynchronous networks with potentially faulty nodes. 3. Cryptography:&nbsp; Robust cryptographic primitives are essential for securing communication and transactions within the P2P network. blockDAG can utilize elliptic curve cryptography (ECC). &nbsp;4. Digital Signatures: Transactions are signed with the sender's private key using ECC, ensuring authenticity and preventing unauthorized modifications. Key Management: Public-key cryptography (ECC public keys) can be used for secure communication and identity verification between nodes.

Technical Underpinnings

BlockDAG's P2P network, coupled with our innovative Directed Acyclic Graph (DAG) technology, unlocks a new level of potential for developers. Unlike traditional blockchains with linear chains, blockDAG enables parallel transaction processing, significantly boosting throughput for your dApps To implement the P2P network part we have come with an example implementation as per our understanding so far. Here's a high-level algorithm outlining a possible approach to implementing a P2P network in BlockDAG:1. Node Initialization Each node maintains a local copy of the blockDAG ledger. The node establishes a P2P connection pool to manage connections with other nodes in the network. The node implements a gossip protocol (e.g., Binary Gossiping Protocol or DAG Gossiping Protocol) to receive and propagate information about new transactions and DAG structures.&nbsp;2. Transaction Broadcasting When a new transaction originates at a node, it is digitally signed using the node's private key. The signed transaction is broadcasted to the node's connected peers via the gossip protocol.&nbsp;3. Transaction Validation Upon receiving a transaction broadcast, a node performs validation checks to ensure: The transaction is well-formed and follows the protocol's defined structure. The digital signature on the transaction is valid, confirming the sender's identity. The transaction adheres to any predefined business rules or tokenomics within the blockDAG network.&nbsp;4. Consensus Mechanism Validated transactions are relayed to other nodes through the gossip protocol. Nodes achieve consensus on the validity of transactions and the current state of the ledger using a Byzantine Fault Tolerance (BFT) consensus variant suitable for asynchronous P2P networks. This ensures all nodes agree on the accepted transactions and the DAG structure.&nbsp;5. Ledger Update Once consensus is reached on a transaction's validity, the transaction is added to the local copy of the blockDAG ledger on the node.&nbsp;6. Network Maintenance The node continuously monitors the health of its connections within the P2P pool. It may discover new nodes through gossip protocol messages and establish connections with them to improve network resilience. Nodes with suspicious behavior or prolonged inactivity might be removed from the connection pool to maintain network integrity.

Building on blockDAG's P2P Network

These will be the rough implementation of P2P networks in BlockDAG project, as the week pass by we'll come up with more technical algorithms and pseudo codes around this implementation. P2P networks represent the cornerstone of a future-proof blockchain ecosystem. By leveraging this powerful technology and the technical algorithms that underpin it, blockDAG empowers developers to create a new generation of scalable, secure, and efficient dApps.&nbsp; Stay tuned for more concrete implementation in BlockDAG We're also thrilled to announce a game-changer for mobile mining: The X1 Miner application is blasting off on the Play Store on June 1st.&nbsp;

Dev Release 19 

Hey BlockDAG community, blockchain enthusiasts, and everyone in between!&nbsp;This week, the BlockDAG team continued its in-depth exploration of the technologies that will form the backbone of our network. Our analysis of DAG BFT demonstrated its power to streamline transaction ordering and enable truly independent consensus, paving the way for enhanced scalability. Additionally, we've assessed the value of multi-signature transactions as a critical security mechanism and a tool to empower collaborative governance within the BlockDAG ecosystem.

The cornerstone of secure and reliable decentralized networks in blockchain technology is the consensus mechanism. Among these mechanisms, Proof of Work (PoW) has earned its reputation for robustness and resilience. This article delves into the intricate workings of PoW, its consensus logic, and its unique implementation within BlockDAG's innovative Directed Acyclic Graph (DAG) architecture.&nbsp;PoW: The Algorithmic Underpinnings for BlockDAG At its core, PoW serves as a cryptographic validation mechanism for transactions on a blockchain. It necessitates miners to solve computationally intensive puzzles – cryptographic hash functions – before appending new transaction blocks to the chain. These puzzles demand significant processing power to crack.

Proof of Work (PoW) in BlockDAG's DAG-Based Blockchain:

Hash Functions: SHA-256 stands as a prevalent choice due to its speed and parallelizability. This functions offer crucial properties: &nbsp;<ul><li>Determinism: Identical inputs yield identical outputs (H(x) = H(x) for all inputs x).</li><li>Pre-image Resistance: Finding the original data (x) from a hash (H(x)) is infeasible.</li><li>Collision Resistance: Generating two different inputs (x1 and x2) with the same hash output (H(x1) = H(x2)) is highly improbable. These properties fortify the blockchain's security and immutability.</li></ul>Mining Process: This iterative process involves: &nbsp;<ul><li>Block Header: This data structure typically includes:</li><li>Previous Block Hash: The hash of the most recent block in the chain, ensuring immutability.</li><li>Merkle Root: The cryptographic hash of a Merkle tree, summarizing all transactions within the block for efficient verification.</li><li>Timestamp: The current time to prevent manipulation.</li><li>Nonce: An arbitrary number that gets incremented in each iteration during the mining process.</li><li>Difficulty Target: A numerical value representing the mining difficulty.</li></ul>&nbsp;<ul><li>Hashing: The chosen hashing algorithm (e.g., SHA-256) is applied to the entire block header concatenated with the current nonce value. SHA-256 produces a 256-bit hash output.</li><li>Difficulty Check: The resulting hash must meet a specific difficulty criteria. This is often achieved by requiring a certain number of leading zeroes in the hash output (e.g., a difficulty of 20 mandates 20 leading zeroes in the 256-bit hash). This ensures a consistent block generation rate despite fluctuating network hash rate. Miners increment the nonce and re-hash the block header until a valid hash is found.</li></ul>&nbsp;Difficulty Adjustment: Network hash rate (total computational power) directly impacts difficulty. Experienced developers will recognize functions like retargeting (e.g., Bitcoin's difficulty adjustment every 2016 blocks). Specific algorithms used for this adjustment (e.g., moving average or exponential moving average) can be further explored here. The goal is to maintain a target block generation time (e.g., 10 minutes in Bitcoin) by adjusting the difficulty.&nbsp;BlockDAG's Implementation: BlockDAG is revolutionizing blockchain technology by integrating Proof of Work within its DAG-based architecture. BlockDAG's DAG-based blockchain architecture offers inherent advantages such as scalability, throughput, and parallel processing. By incorporating PoW, BlockDAG ensures the security and decentralization of its network while leveraging the efficiency of DAG structures. This innovative approach paves the way for a new era of decentralized applications and digital assets.

Core Algorithms

SHA256 (Secure Hash Algorithm 256-bit) Cryptographic Algorithm:Technical Explanation: SHA-256 iteratively processes input data through a series of compression functions, resulting in a fixed-size hash output. Miners search for a nonce value to append to the block header, aiming to produce a hash value below a specified target. &nbsp;[[hash = SHA256(block_header + nonce)while hash &gt;= target:&nbsp; &nbsp;nonce++ &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; hash = SHA256(block_header + nonce)]]&nbsp;Mathematical Formulation: The comparison between the hash and the target is typically represented as: &nbsp;[[hash=SHA256(block_header+nonce)&nbsp;hash&lt;target]]&nbsp;Merkle Root: In BlockDAG (Directed Acyclic Graph)-based blockchain, the Merkle root is calculated in a similar way to traditional blockchains but with some differences due to the structure of the DAG. Here's an explanation of how a Merkle root is calculated in BlockDAG blockchain along with pseudocode: Explanation: &nbsp;<ul><li>In BlockDAG, transactions are not necessarily organized into linear blocks but instead form a directed graph structure.</li><li>To calculate the Merkle root, transactions are grouped together into blocks in a specific order (e.g., based on timestamp or some other criterion).</li><li>Each block contains a list of transactions.</li><li>The Merkle root of each block is computed by recursively hashing pairs of transaction hashes until a single hash remains, which is the Merkle root.</li></ul>&nbsp;[[function buildMerkleTree(transactions): &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if len(transactions) == 1: &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return hash(transactions[0]) &nbsp;// Leaf node &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;else: &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;new_transactions = [] &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;for i from 0 to len(transactions) - 1 step by 2: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Concatenate and hash the transaction pairs &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;concat_hash = hash(transactions[i] + transactions[i+1] if i+1 &lt; len(transactions) else transactions[i])&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;new_transactions.append(concat_hash) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;return buildMerkleTree(new_transactions)function verifyTransaction(transaction, merkleRoot, merklePath): &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;hash_result = hash(transaction) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;for sibling_hash in merklePath: &nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if isLeftChild(hash_result): &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;hash_result = hash(sibling_hash + hash_result) &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; else: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;hash_result = hash(hash_result + sibling_hash) &nbsp;&nbsp; &nbsp; &nbsp; &nbsp; return hash_result == merkleRootfunction isLeftChild(hash_result): &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;// Implement a function to determine if a hash is the left child of its parent &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; // This can be based on the index of the hash in the Merkle path]]&nbsp;&nbsp;Example: &nbsp;<ul><li>Suppose we have a block with transactions T1, T2, T3, and T4.</li><li>We start by hashing pairs of transaction hashes:</li><li>hash(T1 + T2) and hash(T3 + T4).</li><li>Then, we hash the resulting hashes:</li><li>hash(hash(T1 + T2) + hash(T3 + T4)).</li><li>The final result of this operation is the Merkle root of the block.</li></ul>This pseudocode demonstrates a simple implementation of calculating the Merkle root in BlockDAG blockchain.

Let's deep dive into today's implementation: Merkle Root and SHA256

Proof of Work (PoW) remains a cornerstone in blockchain technology, offering robustness and resilience to decentralized networks. Within BlockDAG's innovative Directed Acyclic Graph (DAG) architecture, PoW serves as a critical component, ensuring the security and decentralization of the network while capitalizing on the efficiency and scalability inherent in DAG structures. BlockDAG's implementation of PoW involves core algorithms such as SHA-256 for hashing and Merkle tree for transaction verification. The Merkle root calculation in BlockDAG differs slightly from traditional blockchains due to the non-linear structure of the DAG. However, it retains the essential properties of ensuring data integrity and efficient verification.

Conclusion:

<ol><li>Further Research and Development: Continuous research and development are essential to refine BlockDAG's implementation of PoW, optimizing efficiency, security, and scalability. This involves exploring new algorithms, refining difficulty adjustment mechanisms, and enhancing the overall consensus protocol.</li><li>Security Audits: Regular security audits and vulnerability assessments are imperative to ensure the robustness and integrity of BlockDAG's network. Engaging third-party security firms to conduct audits and penetration testing can help identify and address potential vulnerabilities proactively.</li></ol>

Next Steps:

Dev Release 18

Hey BlockDAG community, blockchain enthusiasts, and everyone in between!As we forge ahead with BlockDAG's smart contract development, let's dive deeper into the intricate details of our evolving platform. This post is a developer's delight, exploring technical considerations and the potential standards BlockDAG will leverage for its smart contract ecosystem.

Smart contracts, those self-executing pieces of code residing on the blockchain, are the driving force behind decentralized applications (dApps) on BlockDAG. They enable the automation of agreements, their rules etched immutably into the distributed ledger. BlockDAG's Approach to Standardization To streamline developer experience and foster a thriving smart contract ecosystem, BlockDAG is actively considering the adoption of widely recognized standards. &nbsp;

Smart Contracts: The Heart of BlockDAG's dApp Ecosystem

BlockDAG is actively working towards achieving EVM compatibility, aiming to unlock groundbreaking possibilities for cross-network collaboration. This future interoperability with Ethereum-based tools, wallets, explorers, and its vast user base has the potential to significantly accelerate the adoption of the BlockDAG ecosystem. Developers would find an environment tailored for building scalable EVM-compatible dApps, while the platform's emphasis on community-driven governance would empower users, builders, and validators, promoting a culture of fairness and inclusivity. &nbsp;<ul><li>ERC-20 Token Standard: This Ethereum standard provides a blueprint for fungible tokens on BlockDAG, guaranteeing seamless interaction with wallets and other applications. Specific methods like name(), symbol(), balanceOf(), and transfer() are likely to be incorporated.</li></ul>function name() public view returns (string)
 function symbol() public view returns (string)
 function decimals() public view returns (uint8)
function totalSupply() public view returns (uint256) 
function balanceOf(address _owner) public view returns (uint256 balance) 
function transfer(address _to, uint256 _value) public returns (bool success) 
function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
 function approve(address _spender, uint256 _value) public returns (bool success)
 function allowance(address _owner, address _spender) public view returns (uint256 remaining)&nbsp;<ul><li>ERC-721 Non-Fungible Token (NFT) Standard: BlockDAG may integrate this standard to enable the representation and management of unique digital assets (NFTs) on the platform. &nbsp;</li></ul>Securing the Smart Contract Realm BlockDAG is committed to the security and integrity of its smart contract functionality. Here's a glimpse into the cryptographic and algorithmic foundations:<ul><li>Hashing Algorithms (SHA-256, BLAKE3): These robust algorithms will generate unique identifiers for transactions, safeguarding data integrity and ensuring that our ledger remains tamper-proof.</li><li>Digital Signatures (Elliptic Curve Cryptography): Algorithms like secp256k1 will empower users to authorize transactions, proving ownership and control of their digital assets on BlockDAG.</li><li>Consensus Mechanisms (PoW, PoS, DPoS): BlockDAG's choice of consensus mechanism will play a critical role in how transactions are validated and added to the blockDAG. This decision directly impacts network security and agreement among participants of the network.</li></ul>

EVM Compatibility

The SHA-256 hashing algorithm is a cornerstone of BlockDAG's security infrastructure. Let's break down its mechanics: 1. Preprocessing<ul><li>Padding: The message is padded with a specific bit pattern to ensure a specific length, a multiple of 512 bits. This padding includes a single 1 followed by zeros until the message length becomes 448 bits short of a multiple of 512. Finally, the message length in bits (as a 64-bit word) is appended.</li><li>Message Schedule: The padded message is broken down into 512-bit blocks (16 x 32-bit words). These 16 words are denoted as W[0]...W[15]. &nbsp;</li></ul>2. Hash Initialization Eight 32-bit hash values, h0 to h7, are initialized with specific hexadecimal constants designed for SHA-256. These values serve as starting points for the iterative processing. 3. Compression Function (Main Loop) This is the core of the SHA-256 algorithm, involving 64 rounds of processing each 512-bit block. Here's what happens in each round:<ul><li>Prepare Working Words: Four additional working words (W[16]...W[63]) are calculated using a specific formula involving bit shifts and previous words.</li><li>Round Function: Each round performs a complex series of mathematical operations on the hash values (h0 to h7) and the working words (W[i]). Here's a breakdown of the key algorithms involved:</li><li>Ch(x, y, z): This function performs a conditional selection based on the second bit (y). It returns either (x &amp; y) or (~x &amp; z), where &amp; denotes bitwise AND and ~ denotes bitwise NOT.</li><li>Ma(x, y, z): This function performs a majority function. It returns the value that appears most frequently among the three bits x, y, and z. This can be implemented using bitwise operations and conditional statements.</li><li>Σ⁰(x): This function performs a right circular shift by 2 positions and a bitwise XOR with right circular shifts by 13, 17, and 19 positions (denoted as &gt;&gt;&gt; and ^ for XOR, respectively).</li><li>Σ¹(x): This function performs a right circular shift by 7 positions and a bitwise XOR with right circular shifts by 18, 3, and 14 positions.</li><li>Hash Value Update: The temporary variables (temp1 and temp2) are calculated using the round function, existing hash values, and working words. Finally, the hash values are updated for the next round. &nbsp;</li></ul>4. Finalization After processing all message blocks, the final eight hash values (h0 to h7) represent the SHA-256 hash digest. These values are concatenated to form the final 256-bit hash string. &nbsp;

Deep Dive: The Power of SHA-256

As blockDAG technology matures, smart contracts are expected to play an increasingly significant role in reshaping various industries. Continuous standardization efforts, the development of more secure and efficient virtual machines like WASM &amp; EVM, and the integration of advanced algorithms will further empower developers to build innovative decentralized applications

The Future of Smart Contracts & next steps

Dev Release 17

Greetings BlockDAG community! As we continue fortifying BlockDAG's security, let's delve into the realm of consensus mechanisms. These protocols are the lifeblood of our trustless environment, ensuring nodes adhere to the rules and preventing collusion. Our objective: identify the ideal consensus mechanism for BlockDAG.

<ul><li>Byzantine Fault Tolerance (BFT): The mechanism must guarantee the BlockDAG ledger's immutability and integrity even in asynchronous Byzantine environments where nodes can fail or exhibit malicious behavior.</li><li>Scalability: The chosen approach should support high transaction throughput without sacrificing performance. Throughput should ideally scale linearly with the number of participating nodes.</li><li>Energy Efficiency: Minimizing energy consumption aligns with our commitment to sustainability. We need a mechanism that offers low computational overhead for node operation.</li><li>Decentralization: We target a distributed network where no single entity holds disproportionate power. The consensus mechanism should promote a fair and permissionless environment.</li></ul>

Core Considerations

<ol><li>Proof of Work (PoW):</li></ol><ul><li>Concept: The pioneering approach of Bitcoin. Miners compete to solve a computationally intensive cryptographic puzzle. The winning miner adds the next block and receives a block reward.</li><li>Security: Relies on the network's combined hashing power. Attackers would require more than 51% of the hashing power to manipulate the BlockDAG ledger.</li><li>Limitations: Energy consumption for mining raises concerns about scalability and sustainability. Additionally, PoW's block finality can be slow due to the probabilistic nature of block acceptance. &nbsp;</li></ul>Technical Details:<ul><li>Hashing Algorithm: Secure hash functions like SHA-256 are employed to generate unique block identifiers that are sensitive to any changes in the block data.</li><li>Difficulty Adjustment: The mining difficulty is dynamically adjusted to maintain a desired block generation rate. This ensures a balance between security and efficiency. &nbsp;</li></ul>Algorithm behind PoW:<ul><li>Nodes receive a new transaction.</li><li>Miners bundle transactions into a block candidate.</li><li>A hash function (like SHA-256) is used to generate a unique hash for the block header, which includes the previous block's hash and the bundled transactions.</li><li>Miners modify a nonce value within the block header until the hash meets a specific difficulty requirement (e.g., starting with a certain number of leading zeros). This process requires significant computational power.</li><li>The first miner to find a valid hash broadcasts the block to the network.</li><li>Other nodes verify the block's hash and transaction validity.</li><li>If a majority of nodes accept the block, it's added to the blockchain, and the winning miner receives a reward.</li></ul>

Candidate Consensus Mechanisms: Proof of work (PoW)

Proof of Stake (PoS): &nbsp;<ul><li>Concept: Block validators are chosen probabilistically based on their token stake. Validators with larger stakes have a higher chance of being selected. Malicious behavior leads to stake slashing (loss).</li><li>Security: Economic incentives disincentivize validator misconduct. Attackers would need to acquire a significant stake to attempt a double-spend attack.</li><li>Benefits: More energy-efficient compared to PoW due to the absence of computationally expensive mining. Faster block finality compared to PoW.</li><li>Drawbacks: Security might be weaker than PoW for large-scale attacks, especially if the stake distribution is concentrated. &nbsp;</li></ul>Technical Details:<ul><li>Randomness Beacon: A verifiable random number generator (VRF) or other source of randomness is crucial for selecting validators in a fair and unpredictable manner.</li><li>Slashing Conditions: The consensus mechanism should clearly define the slashing conditions for validator misconduct (e.g., double-signing, equivocation). &nbsp;</li></ul>Algorithm behind PoS:<ul><li>Nodes submit transactions to the network.</li><li>Validators are selected based on a weighted random process, with the weight proportional to their stake.</li><li>Selected validators propose new blocks containing validated transactions.</li><li>Other nodes verify the block's validity and the validator's eligibility (sufficient stake).</li><li>If a majority of nodes agree on the block, it's added to the blockchain.</li><li>Validators who propose valid blocks receive a reward.</li></ul>

Proof of Stake (PoS)

Nominated Proof-of-Stake (NPoS): &nbsp;<ul><li>Concept: Builds on PoS by introducing token holder nominations. Token holders nominate validators they trust, and the stake of both validators and nominators is slashed for misbehavior.</li><li>Security: Enhanced security compared to PoS by aligning validator and nominator incentives. Malicious validators not only lose their stake but also cause nominators to lose theirs.</li><li>Complexity: Introduces additional layers compared to PoS, potentially increasing message overhead. &nbsp;</li></ul>Technical Details:<ul><li>Nomination Game Theory: The nomination scheme should be carefully designed to incentivize rational token holders to nominate honest and competent validators.</li><li>Reputation Systems: Reputation mechanisms can be integrated to inform token holders' nomination decisions and promote the selection of trustworthy validators. &nbsp;</li></ul>Algorithm behind NPoS:<ul><li>Nodes submit transactions to the network.</li><li>Token holders nominate validators they trust, staking tokens on their behalf.</li><li>Validators are chosen based on a combination of their own stake and the stake nominated on them.</li><li>Selected validators propose new blocks containing validated transactions.</li><li>Other nodes verify the block's validity, validator's eligibility, and nominator's stake.</li><li>If a majority of nodes agree on the block, it's added to the blockchain.</li><li>Validators and nominators who contribute to valid blocks receive rewards. In case of misbehavior, both parties lose their stake.</li></ul>

Nominated Proof-of-Stake (NPoS)

Delegated Proof of Stake (DPoS):<ul><li>Concept: Token holders elect a fixed number of delegates (witnesses) to validate transactions. These delegates are responsible for proposing and voting on new blocks.</li><li>Security: Relies on the reputation of elected delegates and the ability of voters to switch delegation if necessary.</li><li>Centralization Risk: A smaller set of validators might reduce decentralization compared to PoS or NPoS. &nbsp;</li></ul>Technical Details:<ul><li>Delegation Mechanisms: Secure and efficient mechanisms are needed for token holders to delegate their voting power to chosen delegates.</li><li>Byzantine Fault Tolerance (BFT) Sub-protocols: Depending on the specific DPoS variant, BFT sub-protocols like Practical Byzantine Fault Tolerance (PBFT) might be employed to ensure finality even in Byzantine fault environments. &nbsp;</li></ul>Algorithm behind DPoS:<ul><li>Nodes submit transactions to the network.</li><li>Token holders participate in a voting process to elect a fixed number of delegates (witnesses).</li><li>Elected delegates are responsible for proposing and validating new blocks.</li><li>Other nodes verify the block's validity and the delegate's eligibility (elected status).</li><li>If a majority of nodes agree on the block, it's added to the blockchain.</li><li>Elected delegates who propose valid blocks receive rewards. Voters can switch their delegation if they're unhappy with a delegate</li></ul>

Delegated Proof of Stake (DPoS)

We've meticulously examined various consensus mechanisms, keeping BlockDAG's unique requirements in mind. While a definitive decision is yet to be made, this analysis equips us with valuable insights to guide our selection process. We'll continue to evaluate these mechanisms, potentially conduct simulations and testbeds, and actively solicit developer community . We'll keep you updated on our progress and the final consensus mechanism chosen for BlockDAG

Next steps & conclusion

Dev Release 16

Hey BlockDAG Community,&nbsp;As we are moving forward with our implementations in our BlockDAG project, we are also looking into the security for our end user. So our developers are also working on MultiSig Module implementation.

Multisig transactions offer enhanced security for blockDAG ecosystems by requiring multiple parties to authorize spending. Here's a detailed breakdown of implementing multisig in blockDAG, incorporating technical details and specific algorithms:Transaction Structure: &nbsp;<ul><li>Inputs: These reference previous transactions in the blockDAG that spend to the current multisig address. Each input includes the previous transaction hash, output index, and the signature script (explained later).</li><li>Outputs: Specify the recipients and amount of cryptocurrency being distributed.</li><li>Signatures: Each participating party signs the transaction using their private key. The signature script specifies how these signatures are combined to authorize spending.</li><li>Metadata: Optional data attached to the transaction, potentially including timestamps, transaction fees, or additional information relevant to the specific blockDAG protocol.</li></ul>&nbsp;Signature Script: The signature script plays a crucial role in multisig transactions. It's a script written in a stack-based scripting language like Forth embedded within the transaction. This script defines the multisig conditions for spending: &nbsp;<ul><li>Public Keys: The script includes the public keys of all parties involved in the multisig.</li><li>Threshold (M): Defines the minimum number of signatures required (M-of-N) to authorize spending.</li><li>Locking Script: This script specifies the cryptographic operation required to unlock the funds. In multisig, it typically involves verifying a specific number of valid signatures against the listed public keys.</li></ul>&nbsp;Algorithms:<ul><li>ECDSA (Elliptic Curve Digital Signature Algorithm): Used for signing transactions with private keys and verifying signatures with public keys.</li><li>SHA-256 (Secure Hash Algorithm 256): This cryptographic hash function can be used within the redeem script to generate unique identifiers for multisig addresses based on public keys and the locking script.</li></ul>&nbsp;Signature Validation and Redeem Script Processing: &nbsp;<ol><li>Miners or validators in the blockDAG network retrieve the transaction.</li><li>They locate the referenced transactions (inputs) and verify their validity.</li><li>The signature script within each input is parsed.</li><li>The script engine executes the redeem script, verifying:</li></ol><ul><li>Presence of all required public keys (N).</li><li>Validity of each signature (M) against their corresponding public keys using ECDSA.</li></ul>&nbsp;Scripting Language Considerations: &nbsp;<ul><li>Existing scripting languages used in blockchains like Bitcoin Script can be adapted for blockDAGs with modifications to handle the specific DAG structure and consensus mechanisms.</li><li>Alternatively, a new scripting language can be designed specifically for the blockDAG, potentially offering more flexibility and features tailored to multisig transactions.</li></ul>&nbsp;Transaction Propagation and Confirmation: &nbsp;<ul><li>BlockDAG networks need to modify their transaction propagation and confirmation processes to handle multisig transactions.</li><li>Consensus rules must be adapted to ensure all validators agree on the validity of multisig transactions based on the redeem script conditions.</li></ul>

Multisignature (Multisig) in BlockDAG

This outlines a high-level algorithmic approach for implementing multisig transactions in a blockDAG system, focusing on core cryptographic operations and validation logic: 1. Multisig Address Generation Algorithm: Input: Public keys (Pk_1, Pk_2, ..., Pk_N) of participating parties and threshold (M) for required signatures. Output: Multisig address (M-of-N address). Steps:<ol><li>Hashing Public Keys: Compute a cryptographic hash (H) of each public key (Pk_i).</li><li>Concatenation: Concatenate the hashed public keys (H(Pk_1) || H(Pk_2) || ... || H(Pk_N)) and threshold (M) into a single data string (Data).</li><li>Final Hash: Apply another cryptographic hash function (H') to the Data string to generate a unique identifier.</li><li>Address Derivation: Encode the resulting hash (H'(Data)) and additional information (e.g., network prefix) to form the final multisig address.</li></ol>2. Multisig Transaction Validation Algorithm: Input: Transaction object (Tx) containing inputs, outputs, and signatures. Output: Boolean (True if valid, False otherwise). Steps:<ol><li>Iterate over Inputs: For each input (Tx_in) in the transaction:</li></ol><ul><li>Extract the signature script (ScriptSig) from Tx_in.</li><li>Parse the ScriptSig to extract:</li><li>Public key index (index_i) referencing a public key (Pk_i) from the redeem script.</li><li>Signature (Sig_i) of the corresponding party.</li></ul><ol><li>Retrieve Redeem Script: Locate the redeem script associated with the multisig address referenced in the transaction.</li><li>Parse Redeem Script: Extract the following from the redeem script:</li></ol><ul><li>Public keys (Pk_1, Pk_2, ..., Pk_N) involved in the multisig.</li><li>Threshold (M) required number of signatures.</li></ul><ol><li>Signature Verification: For each extracted signature (Sig_i):</li></ol><ul><li>Use the corresponding public key (Pk_i) retrieved from the redeem script (based on index_i).</li><li>Verify Sig_i using ECDSA with the previous transaction hash referenced in Tx_in.</li></ul><ol><li>Signature Count: Check if the total number of valid signatures (verified_count) is equal to the threshold (M) defined in the redeem script.</li><li>Output Validation: Perform additional validation specific to the blockDAG protocol (e.g., checking for sufficient funds in referenced outputs).</li></ol>7. Return True if all steps succeed, False otherwise. This algorithmic approach provides a foundational understanding of multisig transactions in blockDAGs. The specific implementation details like cryptographic hash functions (SHA-256, BLAKE2b) and script language syntax will vary depending on the chosen blockDAG platform.

Algorithmic Approach:

Lets explore some pseudo-code on how keys are generated and transactions are signed : // Multisignature Address Setup function setupMultisig(m, n): &nbsp;keys = generateKeyPairs(n) // Generate n key pairs for authorized parties &nbsp;multisigAddress = generateMultisigAddress(keys, m, n) // Generate multisig address &nbsp;return multisigAddress// Transaction Signing function signTransaction(transaction, privateKey): &nbsp;signature = sign(transaction, privateKey) // Sign transaction with private key &nbsp;return signatureMultisignature transactions offer several benefits, including: &nbsp;<ul><li>Enhanced Security: Unauthorized parties cannot spend funds without the required number of signatures.</li><li>Redundancy: If one key is compromised or lost, the funds are still secure as long as the remaining authorized parties can provide their signatures.</li><li>Trustless Cooperation: Multisignature addresses allow parties to collaborate without having to trust a single entity with control over the funds.</li></ul>

pseudo-code

The current multisig implementation provides a secure foundation for multi-party transactions in blockDAGs. Future development will focus on integrating smart contracts to enable more sophisticated spending logic and unlock the full potential of decentralized applications on the blockDAG platform

Conclusion and next step

Dev Release 15

Greetings BlockDAG community! Diving Deeper into DAG BFT: A Technical Exploration Continuing our implementation of blockchain consensus mechanisms, we delve into Directed Acyclic Graph (DAG) Byzantine Fault Tolerance (BFT). This innovative approach departs from traditional linear chains (like Proof of Work or Proof of Stake) by leveraging DAGs to represent transaction history. This post unpacks the core principles of DAG BFT, delves into practical implementation techniques, and lays the groundwork for future discussions about linear ordering within&nbsp; BlockDAG.

Dev Releases

DEV RELEASE
33

Dev Release 33

DEV RELEASE
32

Dev Release 32

DEV RELEASE
31

Dev Release 31

DEV RELEASE
30

Dev Release 30

DEV RELEASE
29

Dev Release 29

DEV RELEASE
28

Dev Release 28

Dev Releases

DEV RELEASE33

Dev Release 33

DEV RELEASE32

Dev Release 32

DEV RELEASE31

Dev Release 31

DEV RELEASE30

Dev Release 30

DEV RELEASE29

Dev Release 29

DEV RELEASE28

Dev Release 28

DEV RELEASE
33

DEV RELEASE
32

DEV RELEASE
31

DEV RELEASE
30

DEV RELEASE
29

DEV RELEASE
28