Multi-Dimensional Blockchain Overview

The Wormholes Blockchain is a multi-dimensional blockchain, in which parallel chains are coupled together to form the network, supporting parallelism as a way to linearly increase throughput with each additional chain added to the system. There is no upper bound on network size, and the network size is theoretically constrained only by the existing global IP infrastructure.

The Wormholes Blockchain network consists of multiple independent peer blockchains. Each parallel blockchain is coupled with the previous blocks of other chains at the same or different block height. In a general blockchain data structure, ordered blocks are linked “back”, each referring to the previous block on the chain. Each block contains the hash of its parent inside its own header. The sequence of hashes linking each block to its parent creates a chain going back all the way to the first block ever created, known as the genesis block.

In a multi-dimensional blockchain, however, each parallel blockchain must couple with the headers of the previous blocks of other chains at the same or different block height. Each chain contains a subset of other chains’ Merkle roots in the block hashes.

Merkle trees, which are binary trees containing cryptographic hashes, can be used as a data structure applied to efficiently summarize and verify the integrity of a set of data. A Merkle root is constructed by recursively hashing pairs of nodes until there is only one hash.

In a multi-dimensional blockchain, the chain interaction in the topology can be structured as an undirected base graph, which can be viewed as the orders for coupling the chains together. To make the multi-dimensional blockchain more efficient, increase the blockchain network throughput, and keep the computation power constant, many graphs from graph theory can be considered.

Some examples are shown in Figures 1, 2, and 3, in which the graphs can be easily configured and extended. Each vertex in the graphs reprompts a chain. The number of vertices defines the total chain number, which prompts the overall throughput of the blockchain network. The degree of the graph defines the other chains that must couple. The edges of a vertex indicate the specific peers with which a given chain must couple. The chain topology can be expressed through the following equations:

where Nt is the total number of chains, Np is the number of the peer ring in the graph, and Nr is the number of chains per ring, which could be:

The structure of Nr = 4 is shown in Figure 1, Nr = 6 is shown in Figure 2, and Nr = 16 is shown in Figure 3.

Ha= Hash(a) (15)

Hb= Hash(b) (16)

Hc= Hash(c) (17)

Hd= Hash(d) (18)

From Eq. 1, consecutive pairs of leaf nodes are then summarized by concatenating the two hashes and hashing them together in a parent node. For instance, to construct the parent node Hab, the two hashes of the children are concatenated to create a string. The parent node’s hash is then proposed by hashing that string:

Hab= Hash (Ha + Hb) (19)

Hcd= Hash (Hc + Hd) (20)

The process continues until there is only one node (the Merkle root) at the top.

Habcd= Hash (Hab + Hcd) (21)

For instance, taking the block at chain 19 and height h as a viewpoint for a structure of Nr = 16 referred to in Equation 5 and Figure 3, the formed chain couples for previous heights are seen in Figure 5 for a logical view and in Figure 6 for a view of the multiple chains.

This mechanism increases security assurance exponentially. If an attacker wants to replace a given block, every block that directly or indirectly couples with this block must be replaced. Because such an attack would require enormous computation, the existence of the multiple chains of blocks makes the blockchain’s deep history immutable, which is one of the key features of a multi-dimensional blockchain’s security.

The multi-dimensional blockchain mechanism supports many kinds of blockchain structures, including single layer, multiple layers, parallel independent chains, core chaining chains, homogenous chains, heterogeneous chains, and mixed heterogenous-homogenous chains. It can create a blockchain system with multiple chains and multiple layers.

Multi-Dimensional Blockchain Compatibility

Scalable and Flexible Architecture for Multiple Chains and Multiple Layers

The multi-dimensional blockchain mechanism, being inherently flexibile and scalable, supports many kinds of blockchain structures, including single layer, multiple layers, parallel independent chains, core chaining chains, homogenous chains, heterogeneous chains, mixed heterogenoushomogenous chains, or any combination of the above.

The multi-dimensional blockchain architecture may consist of an index chain and several core chains and subchains. The index chain may contain general information about the protocol and the current values of its parameters, the set of validators and their stakes, the set of currently active core chains, and, most importantly, the set of hashes relating to all core chains and subchains. The core chains may contain the value-transfer and smart-contract transactions. The multiple core chains can be homogeneous or heterogeneous.

Example of Homogeneous Multiple Chain System

One example of homogeneous systems is shown in Figure 11, in which all core chains may use the same format for transactions, the same virtual machine for executing smart-contract code, share the same cryptocurrency, and so on, and this similarity is explicitly exploited but with different data in each core chain.

Example of Heterogeneous Multiple Chain System

Example of heterogeneous systems is shown in Figure 12, in which different core chains may have different rules, meaning different formats of account addresses, different formats of transactions, different virtual machines (VMs) for smart contracts, different basic cryptocurrencies, and so on. However, they all must satisfy certain basic interoperability criteria to make the interaction between different core chains possible and relatively simple.

Example of Multiple Subchains

The subchains are subdivided by each core chain, have the same rules and block format as the core chain itself, but are responsible only for a subset of data, such as accounts which depend on several first (most significant) bits of the account address. Because all these subchains share a common block format and rules, the multi-dimensional blockchain is homogeneous in this respect.

A multi-dimensional blockchain system contains one index chain and can potentially accommodate up to 232 or more core chains; each core chain can be divided into up to 232 or more subchains.

Figure shows one example of the multi-dimensional blockchain system, in which the mainchain uses a single block structure that contains all the transactions from all the core chains. Because the main blockchain is divided into core chains, the existence of the blockchain is “virtual”, meaning that it is a collection of core chains. The blockchain has only a purely virtual or logical existence inside the core chains. It is a coincidence that the potentially huge number of core chains can be grouped into one blockchain.

In this multi-dimensional blockchain architecture, accounts or smart contracts are grouped into core chains. Then there are several core chains, each describing the state and state transitions of only a group of accounts, sending messages to each other to transfer value and information.

Practically, there is only one index chain but core chains may be up to 214, with each responsible only for a set of accounts depending on the several first (most significant) bits of the account address, as shown in Figure

In this case, all the transactions in the block are divided into physical core chains, and each block contains either one or zero specific core chain block, as shown in Figure.

In this system, no node of the blockchain network needs to download the full state or the full block. Each node only maintains the state that corresponds to the core chains that they validate transactions for, and the whole state of the system is changed in all the core chains.

Example of Homogeneous Multiple Chain and Multiple Layer System

Example of Heterogeneous Multiple Chain and Multiple Layer System

Wormholes Network

The Wormholes Blockchain Network is composed of multiple levels, consisting of the Transport Level, Blockchain Level, API Level, and Application Level. The Transport Level is for making efficient use of network connectivity. The Blockchain Level makes decentralization a reality and lays the foundation for the token economics that are inherent in most real blockchain-related projects. The Blockchain Level provides the token economics and provides the mechanism for and keeps track of the messages passing between nodes. The API Level is a programming abstraction separate from the lower levels and the Application Level. The Application Level is a placeholder for all applications.

DRE Consensus Protocol

In a consensus protocol, all participant nodes distributed in a blockchain network share transactions and agree on the integrity of the shared transactions. For instance, Proof of Work (PoW) requires exhaustive computational power from participants for block generation, and Proof of Stake (PoS) uses participants’ stakes for generating blocks. With extensive research, many consensus algorithms have been developed to improve the consensus confirmation time and power consumption of blockchain-powered distributed ledgers. Our DRE protocol describes a general model of asynchronous BFT (aBFT) consensus protocols.

Dynamic Random Election

Dynamic Random Election (DRE) consensus is a set of practical Byzantine fault-tolerant (BFT) protocols for completely asynchronous environments. A synchronous BFT system utilizes broadcast voting and asks all nodes to vote on the validity of each block while an asynchronous BFT system achieves a local view with a high probability of being a consistent global view according to the concepts of distributed common knowledge. The definitions of the DRE protocol are given below:

Node: a machine participating in the DRE protocol. Each node has a local state consisting of local histories, messages, proposal blocks, and peer information.

Related-to: the relationship between nodes which have proposal blocks. If there is a path from a proposal block x to y, then x related-to y. “x related-to y” means that the node creating y knows proposal block x.

Lamport timestamp: for topological ordering, a Lamport timestamp algorithm uses the relatedto relation to determine a partial order of the whole proposal block based on logical clocks.

Subgraph: for a vertex v in a DAG G, let G[v] = (Vv, Ev) denote an induced-subgraph of G such that Vv consists of all ancestors of v including v, and Ev is the induced edges of Vv in G.

Proposal block: a tuple s, a, s’ consisting of a state, an action, and a state. The j-th proposal block in history hi of process i is si j-1, a, sij denoted by vij. Nodes can create proposal blocks. A proposal block includes the generation time, signature, transaction history, and reference to parent proposal blocks. Frame: contains a disjoint set of trunk blocks and proposal blocks, in which the history of proposal blocks is divided into frames.

State: a (local) state of node i is denoted by sij consisting of a sequence of proposal blocks sij=vi0, vi1, …, vij. In a DAG-based protocol, each proposal block vij is valid only if the reference blocks exist before it. A local state sij is corresponding to a unique DAG. In a DAG, we simply denote the j-th local state of a node i by the DAG gij. Let Gi denote the current local DAG of a process i.

Local history: a sequence of local states starting with an initial state, denoted by hi. A set Hi of possible local histories for each process i. A process’s state can be obtained from its initial state and the sequence of actions or proposal blocks that have occurred up to the current state. The DRE protocol uses append-only semantics. In DRE, a local history is equivalently expressed as: hi = gi0, gi1, gi2, gi 3 … where gij is the j-th local DAG (local state) of the process i.

Discharge: each asynchronous discharge is a vector of local histories, denoted by d = h1, h2, h3, …hN. Let D denote the set of asynchronous discharges. A global state of discharge d is an nvector of prefixes of local histories of d, one prefix per process. The related-to relation can be used to define a consistent global state, often termed a consistent cut.

Trunk block: a proposal block if either it is the first proposal block of a node, or it can reach more than 2/3 of the blockchain network’s validating power from other trunk blocks.

Pilot block: a trunk block at layer i that is known by a trunk block of higher frames (i + j), j {(i + 1), (i +2), ….}

Avowal block: a pilot block assigned with a consensus time.

Groupuscule: a list of avowal blocks and the subgraphs reachable from those avowal blocks.

The core idea of DRE is the DAG and dynamic randomness for an election. In the DRE protocol, a node can create a new proposal block, which has a set of 2 to k parents. Nodes generate and propagate proposal blocks asynchronously, and the DRE algorithm achieves consensus by confirming how many nodes verify the proposal blocks.

The DAG is used to compute special proposal blocks, such as trunk block, prepared blocks, and verified blocks. The Groupuscule consists of ordered verified block proposal blocks, which can maintain reliable information between proposal blocks. The DAG and Groupuscule are updated with newly generated proposal blocks frequently and can quickly and forcefully respond to attacks.

In the DRE protocol, each node can create messages and send messages to and receive messages from other nodes. The communication between nodes is asynchronous. Each node stores a DAG, which is the DAG of proposal blocks. A block has some edges to its parent proposal blocks. A node can create a proposal block after the node communicates the current status of its DAG with its peers.

The DAG is a graph structure stored on each node. The DAG consists of proposal blocks and references between them as edges.

The local DAG is updated quickly as each node creates and synchronizes proposal blocks with each other. For high-speed transaction processing, proposal blocks are assumed to arrive at very high speeds asynchronously. Let G = (V, E) be the current DAG and G’ = (V’, E’) denote the diff graph, which consists of the changes to G at a time, either at proposal block creation or arrival. The vertex sets V and V’ are disjoint, similar to the edge sets E and E’. At each graph update, the updated DAG becomes

Gnew = (V ∪ V’, E ∪ E’).

Each node uses a local view of the DAG to identify the trunk block, prepared block, and verified block vertices and to determine the topological ordering of the proposal blocks.

Figure shows a general framework of the DRE consensus protocol.

Based on the DRE consensus protocol, each node contains a DAG consisting of proposal blocks and stores the information of accounts and their stakes.

The key steps in the DRE consensus protocol include the following:

1. Proposal block creation

2. Computing validation score

3. Selecting trunk blocks and updating the trunk block sets

4. Assigning weights to new trunk blocks

5. Deciding frames

6. Deciding prepared/verified blocks

7. Ordering the final blocks

The DRE protocol supports dynamic participation so that all participants can join the blockchain network.

PoS + DRE Protocol Fairness and Security

The fairness and security benefits of the Wormholes Blockchain PoS + DRE protocol (hereinafter referred to as the “Wormholes Consensus Protocol”) are highlighted here.

Fairness

PoW protocol is fair because a miner with pi fraction of the total computational power can create a block with the probability pi. PoS protocol is fair too because an individual node with si fraction of the total stake or tokens can create a new block with si probability. However, initial holders of tokens in PoS systems tend to keep their tokens in order to gain more rewards.

The Wormholes Consensus Protocol is fair because every node has a chance to create a proposal block equally. Like other PoS protocols, any node in the Wormholes Consensus protocol can create a new proposal block with a stake-based probability. Unlike PoW protocols, nodes in the Wormholes Consensus Protocol do not require expensive hardware.

Like a PoS blockchain system, it is a possible concern that the initial holders of tokens will not have an incentive to release their tokens to third parties, as the token balance directly contributes to their wealth. Unlike existing PoS protocols, each node in the Wormholes Consensus Protocol is required to validate parent proposal blocks before it can create a new block. Thus, the economic rewards a node earns through proposal block creation is, in fact, to compensate for their contribution to the onchain validation of past proposal blocks and its new proposal block. Remarkably, the Wormholes Consensus Protocol is more intuitive because our reward model used in stake-based validation can lead to a more reliable and sustainable network.

The table above provides a comparison of PoW, PoS, and the Wormholes Consensus Protocols, where pi is the computation power of a node and P is the total computation power of the blockchain network, si is the stake of a node, S is the total stake of the whole network, and n is the number of nodes.

Security

The table below shows a comparison between existing PoW, PoS, DPoS, and the Wormholes Consensus Protocols, corresponding to the effects of common types of attacks. Note that, existing PoS and DPos protocols have addressed some of the known vulnerabilities in one way or another. Obviously, the Wormholes Consensus Protocol is more secure than PoW, PoS, and DPoS.

PoW-based systems are facing selfish mining attack, where an attacker reveals mined blocks selectively in order to waste computational resources of honest miners.

Both PoW and PoS share some common vulnerabilities, such as Sybil attack and DoS attack. In a Sybil attack, the attacker creates multiple fake nodes to disrupt the blockchain network. In a DoS attack, the attacker disrupts the blockchain network by flooding the nodes. In a Bribe attack, which is another shared vulnerability, the attacker obtains the majority of computational power or stake through bribing for a limited duration. PoS is more vulnerable because a PoS Bribe attack costs much less than a PoW Bribe attack.

Furthermore, PoS has more weaknesses that are not relevant in PoW, including the following:

Sabotage: an attacker owning W/3 + smin of the stakes can appear offline by not voting and hence checkpoints and transactions cannot be finalized, where smin is minimum number of tokens that can be staked by an account. Users are expected to coordinate outside of the blockchain network to censor the malicious validators.

Grinding Attack: in the blockchain validation process, if validators are able to manipulate the random election process of a consensus algorithm, grinding attacks happen. For example, when the election process depends on the block hash, the node elected as a leader for adding a block can manipulate the block-hash by adding or removing certain transactions or trying many parameters to form different block hashes. This node, hence, can grind through many different combinations and choose the one that reelects itself with a high likelihood for the next block.

This is a serious potential source of threat to a blockchain consensus protocol based on ‘proof-ofstake’ coins. Nothing at Stake Attack: a malicious node can mine on an alternative chain in PoS at no cost, whereas it would lose CPU time if working on an alternative chain in PoW.

Double-Spending: this is the first and the most common attack introduced in the field of cryptocurrencies. In such a scenario, an attacker may spend a given set of coins in more than one transaction. There are several ways to perform a double-spending attack, including the following:

Pre-mine one transaction into a block and spend the same coins before releasing the block to invalidate that transaction (called a Finney attack).

Send two conflicting transactions in rapid succession into the blockchain network (called a Race attack).

Response to Attacks

Like other decentralized blockchain technologies, the Wormholes Blockchain network may also face potential attacks by attackers. Here, we describe several possible attack scenarios and show how the Wormholes Consensus Protocol can be used to avoid such attacks.

Attack cost: due to the scarcity of native tokens on a PoS blockchain relative to a PoW blockchain, it will cost more for an attack on the Wormholes Consensus Protocol since it is based on PoS mechanism. In order to gain more stake for an attack in the Wormholes Consensus Protocol, it will be very costly for an outside attacker. The Wormholes Consensus Protocol can effectively avoid potential attacks as attackers will need to gather 2W/3 (or W/3 for certain attacks) tokens to control the validation process, where W is the total number of all tokens staked on the blockchain, regardless of the token price. Acquiring more tokens will increase the price of tokens, leading to a massive cost. Another risk to an attacker is that all its tokens will be burned following any detected attempt.

Denial of Service: the Wormholes Consensus Protocol is leaderless, requiring 2n/3 participation. An attacker would have to attack more than n/3 (or more than W/3) validators to be able to successfully mount a DDoS attack.

Bribery Attack: since 2n/3 participating nodes (or nodes with a total of at least 2W/3) are required to validate in the Wormholes Consensus Protocol, this would make it necessary for an attacker to bribe more than n/3 of all nodes (or more than W/3) to launch a bribery attack, which is extremely expensive.

Sybil: Each participating node must stake a minimum amount of ERB tokens to take part in the Wormholes Consensus Protocol. However, staking 2/3 of the total stake would be prohibitively expensive.

Transaction Flooding: An attacker may discharge a large number of valid transactions from their accounts with the purpose of overloading the blockchain network. To avoid such attempts, the Wormholes Blockchain network requires a minimal transaction fee that is reasonable for normal users, but will cost the attackers a significant amount if they send a large number of transactions.

Parasite Chain Attack: A malicious node can make a parasite chain and attempt to make a malicious proposal block. In the Wormholes Consensus Protocol, when consensus is reached on a finalised proposal block, it will be verified before it is added into the Groupuscule.

The Wormholes Consensus Protocol is based on the BFT mechanism, which is secure unless 1/3 or more of the nodes are dishonest or malicious. The malicious nodes may create a parasite chain. As trunk blocks are known by nodes with more than 2W/3 validating power, a parasite chain can only be shared between malicious nodes, which account for less than one-third of participating nodes. Nodes with a parasite chain are unable to generate trunk blocks, and they will be detected by the avowal blocks.

Double spending: a double spending attack is when malicious attackers attempt to spend their funds twice. A blockchain fork opens the door to double spending attacks. With the Wormholes Consensus Protocol, any honest node can structurally detect the fork. Because honest validators are incentivized to detect and avoid such misbehavior, attackers will be caught and their stakes will be burned.

Sabotage Attack: consider a Sabotage Attack, when attackers may refuse to vote for a period of time. In the Wormholes Consensus Protocol, the absence of validators for a period will be discovered by honest validators. The absent validators will be pruned from the blockchain network and will not be counted further, allowing the blockchain network to continue normal operation with the rest of the nodes.

Grinding Attack: a grinding attack happens when a validator is able to manipulate the random election process of a consensus algorithm. The Wormholes Consensus Protocol ensures that the randomness of its random election process is unpredictable and unbias-able at commitment time; therefore, a stake grinding attack becomes unfeasible.

Long-Range Attack: in some blockchains, if the fork chain is longer than the original, the longer chain will be accepted as the main chain since the longer chain will have done more work (or have a large stake) since its creation; then in these circumstances, an attacker may take the chance to create a separate fork chain. This kind of attack is not possible in the Wormholes Blockchain network because the Wormholes Consensus Protocol is fork-free, and adding a new block into the block chain requires an agreement of 2W/3. To accomplish a long-range attack, attackers will have to gain validating power of 2W/3 to create the new chain.

Dynamic randomness

Many blockchain consensus protocols have to allocate the creation of block creators, whose selection procedure requires a method for distributed randomness. However, computers are based on a Turing machine that is a deterministic device, and the same input seed always produces the same output sequence. Thus, computers are bad at the generation of randomness, and their outputs are pseudo-random.

Many blockchains rely on a source of randomness for selecting participants that carry out certain actions in the blockchain process, such as consensus, shuffling, voting, and cryptographic algorithm. Distributed randomness is also crucial for many distributed applications built on the blockchain, such as building blockchain games, NFTs, and DeFI and Metaverse applications. If malicious participants are able to influence the source of randomness, they can increase their chances of being selected and getting the payout and possibly compromise the security of the blockchain and related applications.

Finding randomness on the blockchain is difficult, as the underlying system is both open and deterministic. There are quite a few examples where randomness extracted from existing data sources have been considered, such as the blockchain variables (block difficulty, block number, block timestamp, or block gaslimit, etc.), a blockhash that expects a numeric argument that specifies the number of the block or a private seed, or published financial data, but all these variables can be manipulated by participants, so they cannot be used as a source of randomness because of the participants’ incentives. More importantly, the block variables are obviously shared within the same block. If a malicious participant calls the victim contract via an internal message, the same randomness in both contracts will yield the same outcome. Therefore, these schemes all suffer from the unavoidable problem that it is easy for malicious participants to determine how choices they make will affect the randomness generated on-chain and are thus vulnerable to manipulation by malicious participants.

In all of the above scenarios, it is easy for participants to affect the result of randomness by seeing different inputs. To address this issue, various techniques have been developed, such as publicly-verifiable secret sharing (PVSS) and threshold signature schemes, as well as verifiable random functions (VRFs) such as Algorand and Ouroboros, etc., but they all suffer from requiring a non-colluding honest majority.

Besides VRFs, there are some other popular approaches to produce randomness in the blockchain space. One of them is the commit–reveal scheme, such as RANDAO, in which each of the participants first privately chooses a pseudo-random number, submits a commitment to the chosen number, and all agree on a set of commitments using consensus algorithm; they then all reveal their chosen numbers, reach a consensus on the revealed numbers, and have the XOR of the revealed numbers to be the output of the protocol. It is unpredictable, but biased-able. For instance, a malicious participant can observe the network once others start to reveal their numbers and choose to reveal or not to reveal its number based on XOR of the numbers observed so far. This allows a single malicious participant to have one bit of influence on the output, and a malicious participant controlling multiple participants can have as many bits of influence as the number of participants they are controlling. Therefore, being able to influence or predict randomness allows a malicious participant to affect when they will be chosen to mine a block.

During the randomness sampling, a malicious participant may re-create a block multiple times with adversarially-biased hashes (such as randomness-biasing or randomness-grinding attacks) until it is likely that the participant can create a second block shortly afterwards, which means that the malicious participant is able to bias the nonce that is used to seed the hash since the malicious participant can place arbitrary seeds in the blocks it contributes.

To overcome this randomness-biasing, verifiable delay function (VDF), which takes a long time to generate the randomness but can quickly verify the randomness without redoing the expensive computation, provides a time delay imposed on the output of randomness. This delay prevents malicious participants from influencing the output of the randomness, since all inputs will be finalized before anyone can finish computing the VDF. VDF requires a moderate amount of sequential computation to evaluate; once a solution is found, it is easy for anyone to verify that it is correct. When used for leader selection, VDF only requires the presence of any honest participant. This added robustness is due to the fact that no amount of parallelism will speed up the VDF, and any non-malicious participant can easily verify the accuracy of anyone else’s claimed VDF output.

The biggest problem with VDF, however, is that an attacker with very expensive specialized hardware can compute the VDF before the solution is found. This means that an attacker who has a specialized ASIC that runs the VDF faster than the time allocated to reveal commitments can still compute the final output with and without the shared information of the other parties and choose to reveal or not to reveal based on those outputs. For instance, Ethereum uses RANDAO supported by the VDF approach as their randomness beacon, but this technology is not as viable for other protocols that cannot invest in designing their own very fast ASICs that have to be much faster than any potential attacker’s specialized hardware.

To address these scenarios, for instance, randomness from trusted third parties, such as the random beacon may be used. However, the additional trust assumptions and reliance on a central randomness provider, which may know the beacon values well in advance of publishing or could even manipulate the produced values without being detected, is undesirable.

Besides common security threats, some potential risks can be foreseen. One of the most severe is the advent of quantum computing, as a functional quantum computer could easily undermine the security of the most distributed ledgers, making them practically useless.

An unpredictable, verifiable, reliable, and fast source of randomness, therefore, is what many blockchain applications are looking for; it means the randomness must have the following properties:

1. Unpredictable: no one should be able to predict the randomness before it is generated.

2. Unbiased-able: the process of generating the randomness should not be biased-able by any participant.

3. Verifiable: the validity of the generated randomness should be verifiable by any observer.

4. Fast: generating randomness should be fast and require low computational resources.

5. Scalable: the protocol of randomness generation should scale to a large number of participants and should tolerate some percentage of participants going offline or trying intentionally to stall the protocol.

The multi-dimensional blockchain mechanism realizes an unpredictable, verifiable, reliable, scalable, and fast source of randomness, which is what many blockchain functions, including consensus, voting, and cryptographic algorithm, are looking for.

In the multi-dimensional blockchain mechanism, a randomness for the i-th chain at h height can be obtained by:

The RN is unpredictable, verifiable, reliable, and fast. Or, it can be obtained by:

The dynamic randomness supports not only multi-dimensional blockchains but also other kinds of blockchains, such as sharded chains and single chain.

Verification and Transaction

In the PoS + DRE protocol, every node ni has a stake value of si, can submit new transactions batched in a new proposal block, and can communicate the new proposal blocks with peers. The stake value is used to determine the node’s validating power to validate proposal blocks. Blocks are then validated by other nodes, which have the same level of validating power.

The user level contains only nodes of the same weights; hence, it is equivalent to say that all nodes have a unit weight (si = 1). In contrast, the validator level is more general in that nodes can have different validating power si.

To reach asynchronous BFT consensus, validators are each required to create a proposal block to indicate which block it (and all of its ancestors) has validated.

In the POS + DRE protocol, a node must validate its current block and the received blocks before it attempts to create (or add) a new proposal block into its local DAG. A node must validate its new proposal block before it communicates the new block to other nodes.

A trunk block is an important block that is used to compute the final consensus of the proposal blocks of the DAG. The PoS + DRE protocol takes the stakes of participants into account to compute the consensus of blocks. The weight of a block is the sum of the validating power of the nodes whose trunk blocks can be reached from the block.

Token Staking and Delegation

Validators can stake their ERBs and users can choose to stake or delegate their ERBs. When staking or delegating, the validating power of a node is based on the number of ERBs held. There are three possible ways to stake.

Transaction Staking

Participants can gain more stakes or tokens via transaction staking. The transaction submitter can gain rewards from the transaction fees of submitted transactions. This type of staking helps to incentivize transaction volume. The more liquidity, the more transaction staking can be gained.

Validation Staking

By successfully validating blocks, validation rewards can be gained by honest participants.

Participants can obtain block rewards for blocks that they co-validated and gain transaction fees from transaction submitters for the successfully finalized transactions. The more stake they gain,the more validating power they will accumulate and thus the more rewards they can obtain as rewards are proportional to their validating power.

Validation Delegation

Validation delegation allows a participant to delegate all or part of their ERB tokens to other participants. Delegating participants can gain a share of block rewards and transaction fees, based on the amount of delegated stake. Delegators can delegate their stake to a validator or to multiple validators. Participants with large amounts of stake can delegate their stakes to multiple validators. Delegators earn rewards from their delegations. Validators will not be able to spend delegated tokens, which will remain secured in the stakeholder’s own address. Validators will receive a fixed proportion of the validator fees attributable to delegators.

Validation Parameters

Participants are rewarded for their staked or delegated amount. Delegators will be incentivized to choose validator nodes that have a high self-stake, i.e., are honest and high performing. Delegators can delegate their tokens for a maximum period of days, after which they need to redelegate.

The requirements to delegate are:

Minimum number of tokens per delegation: 1

Maximum number of delegated tokens per validator: 20 times the validator’s tokens.

Weighted DAG Model

The PoS + DRE protocol uses a DAG-based structure, which is a weighted DAG G = (V, E, w), where V is the set of proposal blocks, E is the set of edges between the proposal blocks, and w is a weight mapping to associates a vertex vi with its weight w(vi). Each vertex (or proposal block) is associated with a weight (validation score). Proposal blocks have a validating score, which is the total weight of the trunk blocks reachable from it. A trunk block vertex has a weight equal to the validating power of the trunk block’s creator node.

In the PoS + DRE protocol, a wDAG is a weighted DAG stored on each node. Let W be the total validating power of all nodes.

For consensus, the algorithm examines whether a proposal block has a validation score of at least a quorum of 2W/3, which means the proposal block has been validated by more than two-thirds of the total validating power in the wDAG. To become a trunk block, a proposal block requires more than 2/3 of validating power (i.e., 2W/3). For simplicity, we denote quorum Q to be 2W/3+1 for weighted DAG. In the original unweighted version, quorum Q is 2n/3 + 1 for the unweighted DAG.

Proposal Block Creation

Each proposal block has at most k references to other proposal blocks using their hash values. One of the references must be a self-ref (or self-parent) that references to a proposal block of the same node. The other references, which are also known as other-parent or other-ref references, are the top proposal blocks of other nodes.

Prior to creating a new proposal block, the node will first validate its current block and the selected top proposal block(s) from other node(s). With cryptographic hashing, a proposal block can only be created or added if the self-ref and other-ref proposal blocks exist.

Nodes with a higher stake value si have a higher chance to create a new proposal block than other nodes with a lower stake.

A proposal block is a vertex in the DAG, which stores the structure of consensus messages. Each proposal has several links to past proposal blocks (parents). The links are the graph edges. Sometimes, proposal blocks can be used interchangeably.

Each proposal block is a signed consensus message by a validator sent to the blockchain network, which guarantees the following:

The creator of this proposal block has observed and validated the past proposal blocks (and their parents), including the parents of this proposal block. The proposal block creator has already validated the transaction list contained in this proposal block.

The structure of a proposal block in the PoS + DRE protocol is as follows:

• Epoch number

• Sequence number

• Frame number

• ID of validator which created the proposal

• Hash of finalized state of the previous epoch

• List of parents (graph edges)

• Amount of unspent validator’s gas power

• Amount of spent validator’s gas power

• Lamport timestamp

• Creation Time

• Median Time, which is a weighted median of the highest observed proposal blocks from each validator; proposal blocks from the cheater validators are not counted

• Merkle root of proposal block transactions

• List of original transactions

• Validator’s signature

Each proposal block has two timestamps. The Creation Time is the created timestamp assigned by the creator of the proposal block. The Median Time is a weighted median of the highest observed proposal blocks (their Creation Time) from each validator. Proposals from the cheater validators aren’t counted.

Trunk Block Selection

A trunk block is generated once proposal blocks reach consensus when 2/3 validating power is reached. When a new trunk block is found, the ‘Assign weight’ step will assign a weight to the trunk block. The trunk block’s weight is set to be equal to the validating power si of its creator.

The validation score of a trunk block is unchanged. A node can create a new proposal block or receive a new block from other nodes.

To guarantee that trunk block can be selected correctly even in the case that a fork exists in the DAG, it requires, in the subgraph of proposal x, that x does not observe any forks from y’s creator and at least a quorum of non-cheater validators have observed proposaly.

A proposal block is called a trunk block if it is forkless. The trunk block starts a new frame. For every proposal block, its frame number is no smaller than the self-parent’s frame number. The lowest possible frame number is 1.

Prepared Block Selection

A prepared block is a trunk block that is known by more than a quorum Q of the nodes, and there is another trunk block that knows this information. For a trunk block ti in frame fi to become a prepared block, ti must be reached by some trunk block ti+3 in frame fi+3.

A prepared block is a verified block candidate that has not been assigned a timestamp.

Verified Block Selection

From the array of trunk blocks that are decided as verified block candidates, there are several ways to sort their priority. Verified block candidates can be sorted based on the Lamport timestamp, layering information, validator’s stake, validator’s id, and the verified block’s ID.

The verified block selection sorts the decided trunk blocks based on their validator’s information. Validators are sorted based on their stake amount first and then by their ID. The algorithms require a sorted list of validators.

Nodes in the PoS + DRE protocol reach consensus about verified block selection and verified block timestamp without additional communication with each other. Through the PoS + DRE protocol, the DAGs of all nodes are “consistent”. This allows each node to know the candidate time of other nodes based on its DAG and reach a consensus agreement. The proof is shown in the Appendix.

A verified block is generated once the proposal block is decided and is final and non-modifiable. All proposal blocks can be in the subgraph of a verified block to guarantee finality.

Validators are sorted by their stake amount and then by their ID. For trunk blocks from different validators, they are sorted based on the ordering of their validators. A verified block is chosen as a first candidate trunk block in the sorted order. Notice that a verified block may be decided even though not all the trunk blocks on a frame are decided. The PoS + DRE protocol allows frames to be decided much earlier when there are a lot of validators, hence reducing TTF (time to finality).

Groupuscule

The Groupuscule is an append-only list of blocks that caches the final consensus ordering of the finalized verified blocks. The local hashing chain is used to path search to quickly determine the closest trunk block to a proposal block. Each participant has their own copy of the Groupuscule and can search the consensus position of their own proposal blocks from the nearest verified block. The chain provides quick access to the previous transaction history to efficiently process new coming proposal blocks. After a new verified block is determined, a topological ordering is computed over all proposal blocks which are not yet ordered. After the topological ordering is computed over all proposal blocks, verified blocks are determined and form the Groupuscule.

Topological Ordering of Proposal Blocks

Every node has a physical clock, and each proposal block is assigned a physical time (creation time) and a logical time (Lamport timestamp). For consensus, the DRE protocol relies on a logical time for each node.

A Lamport timestamp is used to determine the time ordering between proposal blocks in an asynchronous distributed system. The Lamport timestamp algorithm is as follows:

Each node updates its count value before creating a proposal block;

When sending a message, the sender includes its count value. The recipient should consider the count sent in the sender’s message upon receipt and updates its own count value;

If the current counter is less than or equal to the count value received from another node, then the count value of the recipient is updated to the count value received; and If the current counter is greater than the count value received from another node, then the current count value is updated to the count value of the recipient.

Committed Blocks

Once a new verified block is decided, a committed block will be created. The committed block contains all the proposal blocks in the verified block’s subgraph; it only includes proposal blocks that have not yet been included in the subgraphs of any previous verified blocks. The proposal blocks in the committed block are ordered by Lamport time and proposal block hash. Parents are ordered before their children, which is ensured by Lamport time.

Then the verified block is assigned a timestamp from the Median Timestamp, which is computed as the median of the proposal block timestamps sent by all the nodes. The median time is used to guarantee aBFT for the consensus time of the verified block to avoid incorrect time from malicious nodes. Once the consensus time of the verified block is assigned, the prepared block becomes a verified block, and each node stores the hash value of the verified block and verified block consensus time in Groupuscule. The Groupuscule is used for time order between proposal blocks.

In the PoS + DRE protocol, block timestamp is assigned using the verified block’s median time.

Peer Selection

In the protocol, each node only stores a subset of n peers. To create a new proposal block, a node synchronizes the latest blocks from other peers first and then selects the top blocks of at most k peers. The PoS + DRE protocol does not depend on how peer nodes are selected.

In the PoS + DRE protocol, the ways to select k peers from the set of n nodes is based on a cost model, which corresponds to low network latency, high bandwidth, high successful transaction throughput, available gas, and origination power.

Peer synchronization synchronizes proposal blocks between the nodes, which assumes that a node always needs the proposal blocks in topological ordering; an alternative would be to use an inverse bloom lookup table for completely potential randomized proposal blocks.

In the PoS + DRE protocol, when a node receives a new proposal block from a peer, it will perform several checks to make sure the proposal block has been signed by an authorized peer, conforms to data integrity, and has all parent blocks already added in the node’s local DAG.

Transaction Finality

There are several steps for a transaction to reach finality:

A successful submission receipt will be issued to the user as a confirmation when a user submits the transaction into a node;

The node will batch the submitted transaction(s) into a new proposal block and add it into its DRE DAG. Then the proposal block will be broadcasted to all other nodes of the Groupuscule. Peer nodes will update their own record confirming that the proposal block identifier is being processed;

When the proposal block is known by a majority of the nodes, the new status of the proposal block is updated;

The system will determine the condition under which a trunk block becomes a prepared block awaiting acknowledgement by a majority of the nodes. A confirmation is then sent to the user to indicate that the proposal block has come to the semi-final stage as a prepared block or is being confirmed by a prepared block. After the prepared block stage, it will determine the consensus timestamp for the prepared block and its dependent proposal blocks; and

Once a proposal block receives the final consensus timestamp, it is finalized, and a final confirmation will be issued to the user that the transaction has been successfully finalized.

In the above five steps, steps 2, 3, and 4 are internal steps, and steps 1 and 5 are visible to the end-users. Once a block is confirmed, it will be assigned with a block ID in the blockchain, and the confirmation is final.

In unsuccessful cases, the proposal block’s status is updated accordingly. Users can always query the latest transaction status regardless of its success or failure.

Epochs

In the PoS + DRE protocol, there are two layers of epochs.

The procedure for the first layer epoch in the Wormholes Blockchain network is as follows:

The first layer epoch is divided into several epoch points, each will take every Z1 frame, where Z1 is a configurable number;

Stakeholders can choose to make more deposits at each first layer epoch point if they want to become validators and earn more rewards. Validators can choose to exit but cannot withdraw their deposits until a period of time has lapsed, such as 12 months A first layer epoch point is selected based on a consistent global history that is finalized with more than 2W/3 of the validating power for the first layer epoch point. Once a first-layer epoch point is finalized, the transactions cannot be reverted; and

With the asynchronous system model, validators are incentivized to coordinate with each other upon which first layer epoch points the history should be updated. Nodes gossip their latest local views to synchronize frames and accounts. Attackers may attempt double voting to realize double-spending attacks. Honest validators are incentivized to report such behavior and burn the deposits of the attackers.

The procedure for the second layer epoch is as follows:

It is divided into several second-layer epoch points within Z1 period; each will take every Z2 frame, where Z2 ≤ Z1, and Z2 is a configurable number;

A node shuffle is taken at the second layer epoch point; and Validators are incentivized to coordinate with each other upon which second layer epoch points the history should be updated. Nodes gossip their latest local views to synchronize frames and accounts.

Smart Contracts & EVM

Smart contracts are computer programs that run on a blockchain network that transfer encrypted assets according to specified rules and conditions automatically. One of the most common examples is the code program, ERC20smart contract on Ethereum. This contract can issue a digital asset in five minutes and can be directly hatched to the birth of the blossoming digital asset market. Many project tokens in the market initially existed as ERC20 tokens.

Smart contracts are more efficient and convenient. But there is a fatal “security bug” that a smart contract is written in the protocol layer of the immobilized program, which means it may face security problems when a bug is in the code. Also, smart contracts are executable, and it is unmodifiable code run stored on blocks of the blockchain. It can be accepted across the network and run in a virtual machine environment.

A contract typically consists of reading transaction data, reading or writing to the contract’s storage, reading environment variables, and sending a transaction to the blockchain. The resulting smart contract and the transactions originating in the contract are stored on the main chain of the blockchain network in the same way that blockchain bookkeeping.

The Wormholes Blockchain Network is fully EVM compatible, and smart contracts can be deployed and discharged on the Wormholes Blockchain Network. Decentralized Applications (DApps) can query and send transactions into the blockchain network for execution. API calls are supported through the API Level.