E. Technology
The DMDv4 is based on an Open Ethereum node client software with EVM abilities customized by the DMD team. The team has added the ability to support the implementation of the Honey Badger Byzantine Fault Tolerant consensus protocol combined with the implementation of a POSDAO, a dPOS-like mechanic to choose the active validator nodes that create a higher level of decentralization than fixed consensus node protocols. The repository for DMD can be found on GitHub.
Diamond DMDv4 uses the latest suite of proven technologies, allowing for fast transaction times, full smart contract support, and on-chain governance. In this version of DMD, coin holders can take part in the governance and staking mechanisms without running a full node as described in the Network Participants section.
The components of the DMD blockchain include:
● Ethereum Virtual Machine (EVM) based on Open Ethereum is responsible for executing the smart contracts.
● A smart contract language code used by programmers is used to create smart contracts. DMDv4 is a Turing-complete solution that allows the development of any kind of dApp that can be supported on the blockchain. The DMDv4 supports Solidity and the other languages that are supported by the Ethereum blockchain.
● Node selection, in this case, is based on POSDAO for the selection of nodes for validation in HBBFT. The core code is a set of smart contracts that determines the default functionality of the DMDv4 blockchain. The POSDAO is what makes the blockchain work true decentral by random rotation of power, staking upon different validators and distributing rewards between the active participants, both stakers and validators.
● When the DAO Governance structure is implemented, POSDAO supports it via providing the voters’ weight (total staked coins on a validator candidate) which allows the coin holders to vote for (and potentially have automated implementation of) changes such as block gas limit and minimum gas fees and similar changes in the network.
● The consensus mechanism, in this case, the Honey Badger Byzantine Fault Tolerant (HBBFT) protocol, determines the transaction validation rules. HBBFT is used in combination with a POSDAO election of nodes for distributed and secure transaction validation.
The Proof-of-Stake Decentralized Autonomous Organization (POSDAO) algorithm is designed to create a decentralized consensus for public blockchains, based on a voting mechanism to elect the active nodes (validators) that participate in block creation. POSDAO provides a leaderless structure that incentivizes validators to act in the best interests of the network. The following picture shows the leaderless block authoring architecture, with POSDAO selecting the validators, and then the validators approving the transactions and receiving the Epoch rewards.
DMD uses HBBFT as a cooperative consensus algorithm to overcome the issues of slow transaction time and limitations of competitive consensus protocols, but HBBFT requires a low maximum of 25 validator nodes (in the DMD implementation) to take advantage of these improvements. However, the permanent distribution of power in a network of 25 static nodes is not adequate. To solve this, DMD uses a POSDAO implementation in order to select the nodes that will act as active validators every Epoch that runs 12 hours. By electing a new subset from the candidate nodes every Epoch, POSDAO allows for the distribution over any number of validator candidates, both maintaining the speed of the network and creating a fairly distributed mechanism of securing the system and earning rewards. Note that chances of being selected are increased for nodes that are most trusted, represented by the number of coins staked on top of them.
In DMD, a cap of 438 validator candidates possible because of the scarcity of the DMD coins. These caps contribute to the fairness and the speed of the network. Based on the current network activity, Diamond DMD expects approximately 50 – 75 active validator сandidates competing for the active Epoch set. A maximum staking ceiling of 50,000 DMD ensures that there is no possibility to buy one’s way in or collude to become more powerful than other validators on the network. The maximum staking amount also makes sure that even candidates with a minimum stake of 10,000 DMD have a chance to get into the active set and POSDAO dPOS stakers can increase that chance by supporting smaller candidates via staking on them.
POSDAO is a highly secure mechanism with protections against breaches, outlined in detail in the POSDAO whitepaper. Participants stake coins to protect the network via electing reliable and stable nodes to take part in the active HBBFT consensus Epoch. Staking tokens allows the participants to earn rewards and take part in on-chain governance.
The move from Proof-of-Work to a lightweight consensus mechanism is an essential improvement in blockchains and is being undertaken in the Ethereum network as well as in newer blockchains. Proof-of-Work is reliable but it has proven inappropriate for the long-term health of blockchains for three reasons:
● high carbon footprint;
● potentially limited throughput;
● and high transaction costs.
For all these reasons, DMDv4 adopts a PoS protocol. To learn more about the energy efficiency of PoS versus PoW blockchains, read the Artis blog article that shows the numbers that are relevant for DMDv4 as well. PoW protocols require specialized hardware requirements for running a hardware node, particularly because of the competition to make an income from mining. Without specific mining equipment expertise and very cheap electricity, it’s impossible to become profitable.
Staying profitable in the PoW mining world means rapid hardware upgrades, increasing waste, and environmental damage. Blockchains developed today no longer consider PoW to be a viable solution. Proof-of-Work blockchains are notorious for their wasteful and unsustainable energy consumption. For further reading see Bitcoin’s Growing Energy Problem and Decarbonizing Bitcoin Another disadvantage of PoW protocols, such as Nakamoto consensus, is that they do not produce block finality. In other words, blocks may be mined at the same time by several miners, resulting in a temporary dual-chain state. This can result in long waits before a transaction is verified, high and static block times, and transactions can be removed altogether if they only exist on the short chain. As a result, these blockchains are notorious for the high incidence of forking due to this competitive consensus algorithm.
DMDv4 prevents forking by completely eliminating this problem by utilizing a cooperative consensus which allows dynamic extreme low block times if there is a demand on the network and long times without blocks if there is no demand. Instant transaction finality is a particularly critical feature for high-value financial systems, such as exchanges and other DeFi applications. For developers of any type of finance application, this feature makes DMDv4 superior to other blockchains.
In Proof-of-Stake, anyone in the network can participate in the network security and governance, and PoS is being used in more recent blockchains, but PoS is still a competitive algorithm and it doesn’t guarantee the performance that the Diamond DMD team was seeking. Therefore, DMDv4 uses the Honey Badger BFT protocol which achieves consensus without competition, sharing rewards among validators, again making this a more distributed and democratized network. The combination of HBBFT with the validator selection mentioned above is the key to achieving high performance and highly distributed governance without any trade-offs or compromises.
DMDv4 includes the adoption of the best-proven consensus algorithms to date, the Honey Badger Byzantine Fault Tolerant (HBBFT) protocol. DMD Diamond v4 is implementing the HBBFT protocol for faster throughput, higher security, dynamic block times, robustness, and elimination of orphan blocks and forking potential. HBBFT allows nodes in a distributed environment to use an asynchronous methodology to reach consensus on transactions. As stated in the Honey Badger BFT whitepaper “In fact, Bitcoin provides terrible performance by distributed systems standards: a transaction takes on average 10 minutes to be committed, and the system as a whole achieves throughput on the order of 10 transactions per second. … the demand for robustness is often closely related to the demand for decentralization— since decentralization would typically require the participation of a large number of diverse participants in a wide-area network.”
With Honey Badger BFT, block finality is immediate, and transactions can be confirmed within seconds. No mining is necessary to run HBBFT, and the protocol requires a small pool of validators. DMDv4 uses a subset of 25 active validators that are selected from the pool of all valid validator candidates every 12 hours (Epoch). The +1 validator threshold encryption (this means a stable over two-thirds majority of the active validator set is needed (to wait on the last contributing (slowest) node is not required) allows for very fast validation and low transaction fees. Rotating the validators as described in the Node Selection through POSDAO section ensures that there is no centralization and that many full nodes in the network have the opportunity to serve as validators.
The HBBFT Main Features:
● Asynchronous, which is appropriate for a wide-scale global network.
● Leaderless, meaning that no one node has to declare a transaction. Instead, the validating nodes each propose a fraction of the transactions, and all nodes author the transactions simultaneously and share the block rewards.
● Instant finality, based on the asynchronous nature and the assumption that validator nodes have reliable and secure direct connections.
● Censorship-resistant based on the consensus of all validators.
● Random number generation built-in. Because some of the functionality of the consensus mechanism for the validation requires random number generation, the HBBFT includes an easy way to generate random numbers, making the chain particularly useful for applications that require random numbers.
● No empty blocks are produced. HBBFT approves blocks as quickly or slowly as needed for the blockchain. In the DMDv4 implementation, we will include a heartbeat if there is a long period (10 minutes) with no block production on the chain, but it will be a very small transaction so as not to impact the size of the blockchain.
Even when there is heavy traffic, messages can be delivered asynchronously, so information is not lost. Even if a malicious actor is trying to overload the network, or a particular dApp is experiencing a spike for some reason, the network will continue to function, delivering messages as it can. Validators must reach an agreement on transactions while they are encrypted so that no validator can censor particular messages. The contents of the transaction are decrypted only after consensus is confirmed, preventing malicious nodes from selectively approving messages, because the validators can’t know what is in a transaction before they approve it. Malicious nodes can be identified and are reported through a fault log. Networks can then decide the best methods to remove them.
The HBBFT protocol provides instant block finality. A block is only produced after the transactions have been finalized by the validating nodes in the network. If a block is signed by the validators, it is finalized, even if it is the latest block. This prevents transitory forking and creates an immutable, immediate ledger of transactions.
HBBFT relies on the following assumptions:
● A secure connection between every agent performing a transaction.
● Trusted nodes as reference points, so that agents can always refer to trusted validators and full nodes as reference points.
● Agreement of 2/3 of the nodes for consensus, rather than 51%.
● Unbounded buffers for nodes.
● Approval of transactions does not have to follow a strict synchronous timing, as long as the consensus threshold is reached.
● Triggers for the consensus finding process are set with the blockchain implementation.
Implementation of HBBFT requires a small number of validator nodes with persistent and reliable secure connections between them. DMDv4 uses 25 validator nodes in an active set, which rotate every 12 hours (Epoch). More details about validators can be found in the Node Selection through POSDAO section.
Triggers that are set in DMDv4 for block validation are:
● Block agreement process: HBBFT consensus is based on a list of transactions proposed by the acting validators. The validators collaboratively sign the block using threshold signatures.
● RNG (Random Number) Generation: HBBFT includes a mechanism for choosing the validators using a secure random selection mechanism. This ensures that validators are selected from the validator candidate pool in a fair and secure manner. A nice side effect such RNG numbers can be used by other blockchain applications that need true randomness without the need to have an own RNG engine.
● Block validation: Blocks sealed with a threshold signature need to be accepted, so the current validator set needs to match the threshold signature with the validator set master key.
● Block creation: New blocks are created as soon as the transactions for the previous block are initiated, even if the full block was not approved yet by all validators. This asynchronous immediate block creation mechanism translates into faster transaction times.
● Governance contract interaction: OpenEthereum uses POSDAO to change the validator set between Epochs, and reports malicious validator behavior if detected.
● Validator set changes/key generation: For the transition of the validator set, threshold keys are generated on-chain for the new validators through a smart contract.
● Networking: HBBFT requires direct contact between all validators in the active validator set.
● Network startup: Items must be added to the chain specification so they are included in the genesis block. This includes compiled governance contracts and the public master key. In addition, corresponding key shares must be distributed to initial network validators (this may be accomplished outside of the network) prior to network start.
The one-second minimum block time is in fact a one second waiting time after a block is finished before starting the creation of another block to minimize the delay between the broadcast of a transaction and inclusion in the chain. When there is a heavy network load, it’s possible that the block could take longer than 1 second, so there is no guarantee of immediate processing of the block. In other words, the minimum threshold for starting a block is 1 second. The maximum is 10 minutes because the chain creates a heartbeat block if there are no transactions for 10 minutes.
