Abstract

The Crosschain Interoperability Specification is a set of documents that define the implementation requirements for Enterprise Ethereum clients that do cross-blockchain communications. It defines the architectures, protocols and interfaces that facilitate discovery and enable scaleable crosschain communications.

This document provides an overview of how crosschain decentralization and security is addressed in the Crosschain Interoperability Specification.

This is the Enterprise Ethereum Alliance Crosschain Decentralization Guidelines Version 1.0.
This document has been reviewed by the Enterprise Ethereum Alliance (EEA) Crosschain Interoperability Working Group (CIW), and the EEA Board.
This document is available under the terms of the Apache License 2.0.

When referencing this document, the following citation format should be used:

[eeaciw-crosschaindecentralization-v1.0] EEA CIW - Crosschain Decentralization Guidelines Version 1.0. Edited by Weijia Zhang, Peter Robinson and Aiman Baharna. September 2022. EEA CIW. https://entethalliance.github.io/crosschain-interoperability/crosschaindecentralizationguidelines.html . Latest stage: https://entethalliance.github.io/crosschain-interoperability/crosschaindecentralizationguidelines.html .

Introduction

Decentralization is an important criteria for a blockchain or crosschain platform. When the EEA Crosschain Interoperability Workgroup is working on crosschain use cases and the specification of crosschain interoperability, the question of whether the incoming specification supports a high degree of decentralization has been asked many times. Hence, we prepared this article to provide an overview of how crosschain decentralization is addressed. We use the EEA blockchain architecture to break down the crosschain components to multiple layers, and then describe the decentralization consideration for each layer.

Crosschain Decentralization Considerations

To better explain crosschain decentralization factors, we use the Ethereum architecture diagram that was developed by Enterprise Ethereum Alliance as shown in Figure 1.

Figure 1: Ethereum architecture with crosschain interoperability components

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:

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

Crosschain layer/component Decentralization Consideration Centralized Decentralized
Blockchain layer Does the P2P connection depend on bootnodes? Are bootnodes static and stable enough? Are they endorsed by a large scale community? Bootnodes are controlled by a single entity and it has a low cost of changing it. Bootnodes become de facto community properties.
Consensus layer Is consensus protocol permissionless and trustless? PoA or permissioned BFT with very small number of nodes. PoW or PoS with open participation.
Crosschain bridge layer Who administers adding and deleting relayer nodes? Is there a penalty for relayer nodes sending invalid transactions? Single administrator manages relayer group. No slashing mechanism for bad relayers. A decentralized governance system for multiple administrators managing a group of relayers. There is a slashing mechanism for non-performing relayers if they fail their duties.
Smart contract ownership Who deployed a smart contract? Who effectively owns the smart contract for asset handling, role setting, and smart contract update? Is the smart contract owner denounced? Smart contract is owned by a single EOA account. Smart contracts do not have ownership or are owned by other smart contracts that do not have EOA ownership.
Oracle decentralization Does the crosschain operation use a decentralized oracle? Proprietary oracle that does not rely on sources that can be verified. An open oracle system administered by the community.
Web services Central web server or not? Centralized Decentralized web

Appendix

Related work

[eeaciw-crosschainidentification-v1.0] EEA CIW - Crosschain Identification Specification Version 1.0. Edited by Weijia Zhang and Peter Robinson. 14 December 2020. EEA CIW. https://entethalliance.github.io/crosschain-interoperability/crosschainid.html . Latest stage: https://entethalliance.github.io/crosschain-interoperability/crosschainid.html .

[eeaciw-crosschainsecurity-v1.0] EEA CIW - Crosschain Security Guidelines Version 1.0. Edited by Weijia Zhang, Peter Robinson and Aiman Baharna. 24 September 2021. EEA CIW. https://entethalliance.github.io/crosschain-interoperability/crosschainsecurityguidelines.html . Latest stage: https://entethalliance.github.io/crosschain-interoperability/crosschainsecurityguidelines.html .

Acknowledgments

Tas Dienes (Ethereum Foundation), Coenie Beyers (Adhara), Anais Ofranc (EEA), Chaals Nevile (EEA).