Repository navigation
E. Technical Architecture
This section explains how DMD Diamond’s software components, validator-selection mechanism, and consensus protocol work together. It covers the network architecture, POSDAO-based selection, and HoneyBadgerBFT block creation, including security assumptions, finality, and block validation.
On this page
DMD Diamond v4 combines an EVM-compatible execution environment, HoneyBadgerBFT (HBBFT) consensus, POSDAO-based validator selection, and on-chain governance. The DMD client is derived from OpenEthereum and adapted to support these mechanisms.
The main components have distinct roles:
- DMD node client. The client maintains a synchronized copy of the blockchain, communicates with peers, and verifies blocks and transactions under the network's protocol rules. Nodes in the active validator set also participate in cooperative block creation.
- Ethereum Virtual Machine (EVM). The EVM executes smart contracts and updates blockchain state. Developers can use Solidity and familiar Ethereum development tools, subject to the EVM features supported by the DMD client.
- Staking and validator-selection contracts. DMD's POSDAO-based system manages validator pools and delegation, selects the active validator set, and supports epoch reward allocation. Validator selection combines stake, Bonus Score, and randomness, as described in Node Selection Through POSDAO.
- HoneyBadgerBFT consensus. Active validators agree on a shared set of contributions and construct the same block under common protocol rules. HBBFT provides the agreement mechanism; the client and execution environment apply the transaction and state-transition rules.
- DAO governance contracts. The DAO supports proposals, voting, and approved changes to network parameters and upgradeable contracts. Validator pool owners vote with weight that includes their own stake and delegated DMD. Delegators participate indirectly through their choice of pool.
Coin holders can delegate stake and participate indirectly in governance without operating a node. The roles of coin holders, validator pool owners, and node operators are described in Network Participants. Governance procedures are covered in the DAO Governance.
Figure: The node software, system contracts, and application interfaces form the main layers of the DMD architecture.
DMD uses a POSDAO-based staking and selection mechanism to determine which eligible validator pools participate in each epoch. POSDAO manages participation in the active set, while HBBFT enables the selected validators to create blocks cooperatively. Delegation contributes stake to a pool; it does not constitute a direct vote that guarantees the pool's selection.
The active set normally contains 25 validators, and the standard epoch duration is 12 hours. These are parameters of the DMD implementation, rather than inherent limits of HBBFT. Network conditions can trigger an early epoch end, and the active set can be adjusted under the network's security rules. See Connectivity Monitoring and Epoch Transitions.
Selection combines three factors:
- Stake: the DMD committed by the pool owner and delegators contributes to the pool's selection weight.
- Bonus Score: the pool's score reflects availability and participation in required network processes, as described in the Bonus Score System.
- Randomness: random selection determines the active set using the applicable weights and eligibility rules.
These factors work together. A candidate's selection probability is not determined by stake alone, and eligibility does not guarantee selection in a particular epoch. The preparation of the next validator set includes threshold key generation before the new set becomes active; see Validator Key Generation.
A validator pool requires a minimum owner stake of 10,000 DMD. The 50,000 DMD pool staking cap limits new stake deposits; accrued rewards can raise the pool balance above that amount. Delegation can increase a pool's selection weight within the applicable staking limits. The cap limits stake accepted by an individual pool, but does not by itself guarantee that influence cannot be concentrated across multiple pools.
Dividing the maximum supply of 4,380,000 DMD by the minimum owner stake of 10,000 DMD gives a theoretical upper bound of 438 validator pools. This is not a limit on non-validating full nodes or a measure of the current candidate set. The earlier estimate of 50–75 candidates was a planning projection, not a protocol parameter or a current network count.
Once selected, active validators participate in HBBFT consensus. Pools that meet the reward conditions receive epoch rewards, which are allocated among the pool owner, delegators, and any configured node operator according to the reward rules. Selection and reward allocation are separate mechanisms: stake, Bonus Score, and randomness determine selection, while the stake-based portion of a pool's reward is distributed in proportion to stake. See Validator Reward and Node Operator Share.
Figure: Overview of staking, validator selection, cooperative block creation, and epoch reward allocation. Selection combines stake, Bonus Score, and randomness; the parameter qualifications and reward allocation rules are explained in the accompanying text and linked sections.
DMD Diamond separates validator selection from block consensus. POSDAO-based contracts determine the active validator set; HoneyBadgerBFT (HBBFT) enables that set to agree on contributions and construct blocks cooperatively. This section explains the consensus model, its security assumptions, and its integration into the DMD client.
DMD uses staking and cooperative consensus without computational mining. This avoids the mining competition and associated energy expenditure of Proof-of-Work. Validators instead perform the computation and communication required to process transactions and reach agreement.
In Nakamoto-style Proof-of-Work, competing blocks can temporarily form different branches, and additional confirmations increase confidence that a transaction will remain in the accepted chain. HBBFT reaches agreement among validators before a block is finalized, providing a different finality model under its fault-tolerance assumptions.
Proof-of-Stake describes how economic stake supports participation and security; it does not, by itself, prescribe whether block production is leader-based or cooperative. DMD combines stake-based validator selection with HBBFT cooperative block creation. Rotating the active set allows eligible pools to participate across epochs, while consensus operates among the validators selected for the current epoch.
The practical benefits are the absence of computational mining, finality without waiting for competing branches to resolve, and block production that responds to transaction demand. Performance still depends on network communication, validator resources, and transaction execution costs.
HoneyBadgerBFT is an asynchronous Byzantine fault-tolerant consensus protocol. It allows participating validators to agree without assuming a fixed upper bound on message-delivery time. Its guarantees depend on the fault bound, the required cryptographic assumptions, and eventual delivery of messages between honest participants.
DMD integrates HBBFT into its node client alongside validator-set management and EVM execution. The active set normally contains 25 validators, with a standard epoch duration of 12 hours, subject to the transition and early-epoch-end rules described in Node Selection Through POSDAO.
Figure: Validators contribute encrypted transaction batches that are combined and processed under shared rules to construct a block.
Cooperative block creation proceeds through the following stages:
- Transaction propagation. Users broadcast transactions to the network. Transactions are visible in the public mempool before validators assemble their contributions.
- Encrypted contributions. Validators prepare transaction batches and threshold-encrypt their contributions before sharing them in the consensus process.
- Agreement and decryption. Validators agree on the set of encrypted contributions. The agreed contributions are then decrypted using the required decryption shares.
- Common transaction processing. Validators apply the same rules to process the agreed contributions. DMD's random shuffling determines the final sender order, while transaction processing follows the shared protocol rules.
- Block construction and certification. Validators execute the ordered transactions, construct the same block, and contribute to its threshold signature. Nodes verify the resulting block and its consensus seal.
Agreement, threshold decryption, and threshold signing are separate operations. Each uses the rules and thresholds defined for that operation; they should not be interpreted as requiring a response from every active validator.
Figure: Validator contributions are encrypted, agreed, decrypted, and checked before the transaction set is finalized. This diagram focuses on contribution processing; the sender-order shuffling stage is described above.
DMD combines this process with protocol randomness for sender-order shuffling and validator selection. See Protocol-Level Front-Running Mitigation.
HBBFT is designed to tolerate Byzantine participants: validators that fail or behave maliciously. In the standard model, the number of faulty participants must remain below one third of the participating set. Asynchrony allows the protocol to accommodate variable message delays without relying on a fixed delivery deadline; it does not imply unlimited processing capacity or progress during permanent loss of communication. See the HBBFT implementation documentation for the underlying model.
Transactions are visible in the public mempool. Validators’ contributions are threshold-encrypted before being shared and decrypted after agreement on the contribution set. The final sender order is determined by random shuffling under shared protocol rules. Together, these mechanisms limit discretionary transaction ordering and prevent transaction fees alone from guaranteeing priority in the final order.
Availability monitoring and participation requirements complement consensus. DMD's network security mechanisms track connectivity and required validator actions, affect Bonus Score, and can trigger validator-set changes or an early epoch end. These mechanisms are described in the Network Security System. They are distinct from the cryptographic guarantees of HBBFT itself.
Validators construct blocks cooperatively under shared protocol rules. Once finalized by consensus, a block is treated as irreversible under the protocol's fault-tolerance assumptions. Cooperative block creation avoids competing block proposals and the orphan blocks that can result from them.
A node verifies the block's consensus seal and validity under the applicable protocol rules. Finalized blocks do not require additional confirmations to resolve competing branches. Instant finality describes the status of a finalized block; it does not mean that every submitted transaction is included immediately. Inclusion still depends on propagation, available capacity, transaction validity, and completion of consensus.
Consensus assumptions and verification. The protocol relies on authenticated validator messages, the required cryptographic assumptions, the Byzantine fault bound, and eventual message delivery between honest participants. The participating validators are identified by the active-set rules. Nodes verify blocks using the applicable validator-set public key and the client's block and transaction rules, rather than accepting a block solely because it came from a trusted peer.
Validator-set transitions. Before a new set becomes active, its validators participate in distributed threshold key generation. The transition is coordinated through system contracts and key-generation messages submitted as transactions. The contracts coordinate the process; private key shares remain with the participating validators. See Validator Key Generation.
Protocol randomness. DMD uses protocol randomness in validator selection and sender-order shuffling. These are distinct uses: selection determines who participates in consensus, while shuffling determines the order of senders during block processing. Applications that use network randomness must account for when the random value becomes available and how their own inputs are committed.
Networking and resources. Active validators exchange consensus messages with one another. Reliable connectivity, adequate processing capacity, and sufficient memory support timely operation. Asynchronous consensus does not remove these operational requirements.
Block timing. DMD is designed to produce blocks in response to transaction demand. The described one-second minimum interval is a block-production timing parameter, not a guarantee of one-second transaction confirmation. Under load or delayed communication, block completion can take longer. The heartbeat mechanism is intended to trigger block production after approximately 10 minutes without a block during normal operation; this is not an unconditional upper bound during network disruption.
Network initialization. The chain specification and genesis configuration establish the initial state, including system contracts and the initial consensus configuration. Subsequent validator changes follow the network's epoch-transition and key-generation rules.
