Blockchain Layer

The blockchain layer describes how client nodes are discovered and how P2P network connects these nodes to form peer pools. The decentralization criteria in this layer includes:

• Boot Nodes. Does the P2P discovery protocol rely on boot nodes? If yes, then who controls the boot nodes? If boot nodes get compromised, who has the authorization to re-establish the bootnode? Who owns the static IP address of the bootnode?
• Distribution of Nodes. Are peer to peer connections random and free of control by internet service providers or large scale firewalls? If the nodes are restricted to a region or a service provider, then this makes the network more centralized. A criteria for a decentralized blockchain network is that its nodes are well-distributed globally.

Consensus layer

Is the consensus layer permissionless and trustless? In Proof-of-Authority (PoA) and permissioned Byzantine fault-tolerant (BFT) protocols, only whitelisted nodes are allowed to mine blocks. So the validator group is permissioned and the network is governed by a group of trusted nodes. Whereas Proof-of-Work (PoW) and Proof-of-Stake (PoS) consensus algorithms allow anybody to participate in the blockchain as a miner/validator and do not require strong trust assumptions from users of the network. For PoW, the hashing power and network bandwidth are key factors for mining nodes to compete with each other for mining the blocks. Therefore, whether a PoW blockchain is decentralized or not depends to a large extent on whether there is a monopoly of mining power in the blockchain network. For PoS, the stake of the network asset decides on the mining and governance of the network, therefore looking at the distribution of stake, as well as the concentration of validators across the blockchain, can help check whether its consensus is decentralized or not. The more that mining power (in both PoW and PoS) or stake (in PoS) is concentrated, the more trust is required that the powerful miners/stakeholders will not misuse this power to attack the network.

Crosschain Relayers

In the crosschain bridge layer, multiple relayers and bridge nodes are working to bring data, assets, and commands from the source blockchain to the target blockchain. The relayer operations are partially onchain and partially offchain. For onchain operations, the relayer needs to have a connector for the source chain and another one for the target chain. For multiple bridges, a relayer needs to connect to multiple blockchains simultaneously. A relayer also needs to transfer assets from its connected node with source chain to a connected node to target chain. This porting is done by the relayer itself and hence the administrator of the relayer may have the permission to decide the behavior of this porting. Since a relayer works standalone, there needs to be a method to ensure that a relayer will not do damage to the crosschain functions and that multiple relayers will not collude to steal assets through crosschain operations.

There are multiple methods for ensuring relayer decentralization. One way is to implement multiple signature mechanisms so that a crosschain transaction is not considered valid until a set of independent relayers first sign a message to ensure that a transaction on a particular blockchain is complete, and then log the signed transaction to the target blockchain. The owner can then provide a proof of the transaction to the target chain to verify the completion of the transaction in the source chain, and then trigger an atomic transaction on the target chain. This use of multiple signatures is normally implemented as a smart contract or as a script on the target chain. Each relayer has its own full private key to sign a message or transaction, and the threshold of valid signatures are determined by the smart contract administrator or through a voting mechanism of multiple administrators.

Another method for achieving relayer node decentralization is through multi-party computing (MPC). For this method, a group of relayers jointly create a private key and an EOA (externally owned account). The private key is generated using a multi-signature scheme such as a Threshold Signature Scheme (TSS) mechanism, which ensures that it is not owned by any single party. Instead, the private key is co-owned by the relayer nodes, with each node owning just a segment of the private key. When signing a message or transaction, each relayer signs its own transaction and sends it to the relayer group for verification and acceptance. Once the number of the relayers that signed the transaction exceeds the threshold set for MPC, the transaction is considered valid and sent for further processing. As the MPC account of a group of relayers is similar to an EOA, the validation of a crosschain transaction is simpler and can be supported for heterogeneous crosschain operations. Similar to multisign, a threshold can be set for a group of relayers that form a MPC group. A threshold of an MPC group determines how many nodes are needed to sign a MPC transaction. The higher the threshold, the lower the risk for MPC group members to collude.

Smart Contract Layer

Smart contracts are deployed to a target blockchain or a crosschain hub to ensure atomic transactions between a source and target blockchain. The smart contract can perform multiple operations such as registering relayers, assigning administrators, voting on operations, verifying crosschain transactions with provided proofs. For decentralization considerations, it is important to check whether the smart contract is owned by a single EOA, or owned by multiple parties in an MPC scheme, or whether the actual owner has renounced ownership so there is no longer any centralized ownership of the governing smart contract.

Although a smart contract without an owner is better from a decentralization point of view, the drawback is that if there is a smart contract error, or there needs to be an emergency update of the smart contract, there is no way to do this and the smart contract has to be abandoned and relayers would have to reach a consensus to connect to a new smart contract. Whether a smart contract is owned by a single EOA, or a group of accounts, or owned by no one is an important factor in checking the degree of decentralization for a crosschain system.

In the latest smart contract deployment tools such as Truffle or Remix, a smart contract can only be deployed through an EOA. So if a project wants to designate smart contract ownership to an MPC account, they can call a function to transfer the ownership to the new account. Once an MPC account owns the smart contract, they can update or perform emergency operations on the smart contract with the consent and signing messages from MPC group members.

Oracle Layer Decentralization

Blockchain itself does not have a direct connection to legacy IT systems such as web servers, database systems, or file storage systems. Therefore, accessing information from blockchain is normally provided by oracle services that bridge non-blockchain digital content to blockchain. An oracle layer can be formally centralized, or even proprietary, and hence it is necessary to evaluate whether an oracle system is decentralized in the crosschain architecture. A decentralized oracle system is considered an oracle service provided by multiple nodes that can join and provide services without a centralized permission system. Running a decentralized oracle system is a challenge and currently Chainlink and Bend protocols have been working in that direction.

Decentralized Applications (Dapp)

Most Dapp projects provide a user interface through client applications such as mobile wallets, desktop wallets, or web applications. These applications normally will need to go through a centralized web service, such as a proxy, to connect to the blockchain and smart contract. Hence it is important to know whether the web services are acting as just a passthrough proxy or whether have the capability to generate, store, or sign transactions on behalf of the clients, which is a point of centralization. There are decentralized alternatives to web servers that are available to Dapps. Browser plug-ins such as MetaMask are a good examples of how it is possible to support decentralized applications from web browsers. A table showing various layers for the decentralization consideration. A checklist of decentralization.

Summary Table