Dev Release 132

Greetings BlockDAG Community,

As we approach the end of this sprint, we’re thrilled to report that the team has made significant strides in developing key contract-related modules for the BlockDAG Explorer. The completion of both the Contract Listing and Contract Detail modules brings us closer to full-fledged smart contract tracking and interaction capabilities. In this post, we will delve deeper into the technical details behind our recent updates, explain our plans for Standard Token Contracts, and contrast the architectural differences between the EVM and UTXO models in BlockDAG, highlighting their unique functions and limitations.1. Contract Listing and Detail Modules: Technical Breakdown
The newly developed Contract Listing Module enables users to browse through all deployed contracts on the BlockDAG network. Let’s break down how this module works:

Backend Architecture:

• Indexing Contracts:
• We implemented a block-level contract scanning system that parses each block to detect contract creation transactions (using CREATE and CREATE2 opcodes in EVM). Once a contract is detected, it’s added to the contract index in our database.
• Contracts are identified by their deployment transaction and indexed by address, creation timestamp, and block number.
• The contract's bytecode and ABI (if verified) are stored separately for more efficient retrieval.
• Contract Metadata:
• For each contract, we store metadata, including the contract creator's address, gas used, and logs emitted during the contract creation.
• The explorer's API layer is optimized to serve this metadata dynamically via RESTful API calls, allowing faster contract listing queries.

Contract Detail Module:
The Contract Detail Module provides more granular information about each contract, offering the following:

• Contract ABI and Source Code:
• We allow users to verify contracts by submitting the source code (if they have ownership). Once verified, the ABI is generated using Solidity compiler tools (solc), enabling other users to interact with the contract using this ABI.
• The verified contract’s Solidity code is stored and made publicly accessible, allowing developers to audit contract logic.
• Transaction History:
• Every transaction related to the contract is recorded, from its deployment transaction to subsequent function calls. We use event logs to capture emit statements, which are critical for understanding token transfers and other actions taken by the contract.
• Gas Optimization Insights:
• For each contract, gas statistics are presented, helping developers identify gas-heavy functions. Gas profiling tools are integrated to show detailed breakdowns of gas usage per function.

Next on the development agenda is support for Standard Token Contracts. The BlockDAG Explorer will provide detailed listings for ERC-20 and ERC-721 token contracts, each offering specific insights that go beyond basic contract data.

ERC-20 Token Module:

• Token Details:
• The ERC-20 token page will display token symbol, name, total supply, and the contract's decimals.
• A circular supply model will be presented, showing real-time balances of token holders and token distribution.
• Token Events Parsing:
• Using Transfer() event logs, we parse all transfer activity on ERC-20 tokens. Each token transfer is captured and indexed with the sender, receiver, and the number of tokens transferred.
• Allowance() events will also be captured to show approved token usage across different addresses, important for decentralized finance (DeFi) applications.
• Holder Analytics:
• We will implement a real-time token holder analytics dashboard. This will provide a distribution map of token holders across different addresses, along with details such as whale tracking (large holders) and transaction trends.

ERC-721 Token Module:

• NFT Tracking:
• For ERC-721 tokens, each non-fungible token will have a unique entry displaying ownership history, metadata, and associated events like Transfer and Approval.
• TokenURI is parsed to retrieve associated metadata (images, properties) stored off-chain.

BlockDAG’s unique architecture supports both EVM-based smart contracts and the UTXO model. Here’s a deeper look at the technical differences:

EVM (Ethereum Virtual Machine):

• Smart Contract Execution:
• The EVM in BlockDAG is a stateful system where contracts execute bytecode instructions (via the EVM opcode set). Each account has a state consisting of balances and storage, and each contract can manipulate its own storage during execution.
• The EVM state transition function ensures that the global blockchain state is updated as smart contracts are invoked, ensuring deterministic outcomes.
• Gas Computation:
• Each opcode in the EVM has a predefined gas cost. The EVM computes the gas used by each transaction based on the opcodes executed and the complexity of the contract logic.
• This mechanism helps to prevent infinite loops and denial of service attacks, ensuring computational resource limits are respected on-chain.

UTXO Model:

• Transaction Structure:
• The UTXO model used in BlockDAG is a stateless model where transactions consume previous UTXOs and generate new ones. Each UTXO is a discrete unit, and the system operates on the basis of inputs and outputs.
• Unlike EVM accounts, there’s no concept of “balance” attached to an address. Instead, an address can have multiple UTXOs representing its claim to certain values.
• No Smart Contract Support:
• The UTXO model in BlockDAG is designed for high-efficiency, high-throughput value transfers but does not support Turing-complete contracts like the EVM. As such, it is used primarily for simple transaction processing (spends and receives), with no internal state beyond the validation of spent outputs.
• This makes it optimal for transaction verification but unsuitable for decentralized application logic.
• Scalability:
• The UTXO model offers a higher degree of parallelism because each UTXO is independent, allowing transactions to be processed in parallel. This architecture can scale more efficiently in terms of transaction throughput compared to the account-based model of EVM.

Our team is start actively developing the Internal Transactions Module, which will give users detailed insights into internal contract calls. Here's a look at what’s under the hood:

• Internal Call Trace:
• During the execution of smart contracts, one contract can call another contract. These internal calls, while not visible on the surface, are crucial for understanding the full flow of operations during a transaction.
• We will trace all internal transactions , logging the stack of contract calls and the gas used per internal call.
• State Changes and Variable Tracing:
• Our explorer will offer the ability to track state variable changes during internal transactions. For instance, if a contract updates balances or storage variables internally, users will be able to see exactly when and how these changes occurred.
• We’ll also introduce gas profiling for internal transactions, allowing developers to optimize contracts by identifying costly internal calls.
• Event Emission in Internal Transactions:
• Any events emitted during internal calls (such as transfers between smart contracts) will be fully logged, giving users complete visibility into the operations within a contract call stack.

As we finalize these critical features, our focus will shift to scaling and optimizing these modules for performance and reliability. The team is working diligently on improving the caching and API throughput to ensure that even as the network grows, users experience fast and seamless interaction with the explorer.
Stay tuned for our next update, where we’ll unveil the internal transactions module and continue enhancing smart contract support!