Dev Release 13

Dear BlockDAG community,

This week our engineers took a deep dive into the technical trenches of BlockDAG! Buckle up, because we've been busy bees solidifying the foundation for a blazing-fast and secure system. As promised, security was our top priority. We explored potential vulnerabilities and implemented robust safeguards to ensure BlockDAG's integrity. We understand your need for lightning-fast transactions. This week, we researched concurrency, performance optimization techniques, and how to empower developers with the tools they need to build speedy applications on BlockDAG.  We've begun exploring the integration of UTXO and account-based models. We've been digging deep into the data structures, internal workings, and code behind these models to ensure a seamless integration.

This week has been a whirlwind of technical discovery, and we're confident that these advancements will make BlockDAG a resounding success. Now let's get into today's roller-coaster ride. The account-based model (ABM), a cornerstone of blockchain technology pioneered by Ethereum, mirrors traditional bank accounts by tracking user balances and transactions. Unlike the UTXO (Unspent Transaction Output) model prevalent in some Blockchains, ABM offers a more state-oriented approach. This makes it a compelling candidate for projects like BlockDAG, where a focus on user experience and developer familiarity is paramount. Let's delve into the technical specifics – the data structures and core algorithms that drive this model, focusing for a blockchain-oriented perspective.

Data Structures:
 

Account:

Explanation:

• Address: A unique identifier for the account, typically a Keccak-256 hash of the public key (type crypto. Hash from crypto/sha256 ).
• Balance: The total fungible tokens held by the account (represented as an unsigned integer uint64 for larger values). Fungibility implies each unit of the token is equal and interchangeable.
• Nonce: A monotonically increasing sequence number used to prevent replay attacks (unsigned integer uint64).

1. Transaction:

Here's a more details of the transaction processing algorithm:
 

Verification:

• Cryptographic Signature Verification: The VerifySignature function (implementation omitted) utilizes Elliptic Curve Digital Signature Algorithm (ECDSA) to cryptographically verify the transaction signature using the sender's public key retrieved from the From address stored in the Merkle tree (a cryptographically secure hash tree) within the blockchain.
• Balance Sufficiency Check: The sender's account balance (fromAccount.Balance) is compared against the sum of the transfer amount (tx.Value) and transaction fee (calculated based on Gas and GasPrice). This ensures the sender has sufficient funds to cover the transaction cost.
• Nonce Validation: The transaction nonce (tx.Nonce) is compared with the sender's current nonce stored in the Account struct. This prevents replay attacks by ensuring the transaction hasn't been previously processed.

Execution:

• State Update: If all verifications pass, the sender's account balance is decremented by the transfer amount and transaction fee: fromAccount.Balance -= tx.Value + calculateFee(tx.Gas, tx.GasPrice). This reflects the state change within the blockchain.
• Smart Contract Execution (Optional): If the recipient address (tx.To) points to a smart contract, the smart contract code is executed with the provided data (tx.Data) using a platform-specific Virtual Machine (VM). This enables complex programmatic manipulation of balances and state within the blockchain.
• Balance Transfer: Otherwise, the recipient's account balance is incremented by the transfer amount: toAccount.Balance += tx.Value. This reflects the transfer of funds between accounts.

1. State Persistence:

• The sender's account (fromAccount) state update is persisted within the blockchain (potentially involving a consensus mechanism). This update might involve writing the updated account data to a local database or broadcasting it to the network for eventual inclusion in a block or a similar structure within blockchain.
• If applicable, the recipient's account (toAccount) state is also updated and persisted using the same mechanism.
   

Advantages of ABM over UTXO for BlockDAG:
 

• State-Oriented Approach: ABM offers a more intuitive and familiar state-based approach for developers accustomed to traditional financial systems, with clear account balances and direct transfers.
• Seamless Smart Contract Integration: ABM facilitates seamless integration with smart contracts, allowing for programmatic management of account balances

This analysis highlights the Account-Based Model (ABM) as a compelling choice for BlockDAG, particularly considering its focus on user experience and developer familiarity. The state-oriented approach mirrors traditional financial systems and simplifies integration with smart contracts. However, implementing ABM within a DAG structure requires careful consideration for state persistence mechanisms. 
 

Next Steps:

1. We are evaluating: Development Complexity of ABM and UTXO.
2. Prioritize Features: Determining the relative importance of developer experience, smart contract integration, and scalability for our project.
3. Implementation of suitable model: Once we final which model is well suited for our blockchain we will start the implementation, and by next week we will be working on this.
4. We have one more exciting news to share, we’ll be giving more info on the release date and development of the X1 Miner app from next week.