The notion of trust plays a central part in blockchain systems. Blockchains are designed to allow multiple parties to come together and transact with each other in trust-less or low-trust ways.

But trust is a complex topic.

How do blockchains minimize the requirements of trust? Are there certain aspects of a blockchain which require more trust than others? And what exactly are we trusting certain actors with. We need to know answer these questions when evaluating whether to use a certain blockchain technology for our use case.

Before proceeding, let’s come up with a working definition of a blockchain so we can analyze the notion of trust in a blockchain system.

A blockchain system consists of a blockchain data structure (which is a list of authenticated transactions strung together in a tamper-proof list data structure) which is updated in a shared and consistent manner by a blockchain network following agreed-upon protocols.

A blockchain system consists of a number of actors, such as:

• Participants which propose transactions to be added to the blockchain data structure
• Node(s) which add new transactions to the blockchain data structure
• Node(s) which observe and validate the blockchain data structure

We’ll study the notion of trust in different blockchain systems.

Before we do however, it’s important to understand the concept of trust domains, collusion and visibility and how they relate to each other.

Trust domains

Nodes within a certain trust domain all trust each other. An example might be participants and nodes all belonging to the same organization, for example. Different trust domains, say participants and nodes from different organizations, may not completely trust each other.

When talking about the notion of trust in blockchains, it is often useful to talk about the number of trust domains in the system instead of the number of raw participants and nodes in the system.

Collusion

Collusion refers to multiple trust domains coordinating to cheat others. The higher the number of trust domains in the system, the more difficult it is coordinate attempts to cheat others.

Visibility

The more visible certain actions are in a blockchain system, the harder it is to cheat others. The less visible the actions, the easier it is to cheat others. While this trade-off isn’t interesting in blockchain systems where all the information is public, this trade-off becomes more important in blockchain systems with privacy features.

Let’s now turn our attention to the public Ethereum network to better understand it’s trust properties.

Public Ethereum Network

The public Ethereum network consists of a large number of nodes and participants belonging to a large number of trust domains, evolving the blockchain data structure in a collaborative way.

Participants propose new transactions to be added the blockchain data structure and they need to trust the rest of the system to ensure their transactions are added to the blockchain data structure and that the blockchain data structure is evolved correctly and shared with the rest of the system.

The Ethereum network chooses a new node every 10–20 seconds to add new transactions to the blockchain network. The chosen node can do one of the following:

• It can withhold adding the transaction to the blockchain
• It can add invalid transactions to the blockchain or extend the chain in an invalid way (say, by creating a fork)

Note that the chosen node can’t change the history of the blockchain as the other nodes in the system all possess a tamper-proof copy of the blockchain up to that point in time.

If the chosen node withholds a given transaction from the blockchain, a new node will be chosen in the next 10–20 seconds so the transaction will eventually be added to the blockchain data structure. Since the Ethereum network consists of a large number of trust domains, it is very difficult for this node to conduct a coordinated censorship attack against a transaction.

If the chosen node adds invalid transactions to the blockchain or creates a fork, that attempt will be caught by the other nodes when it gossips the updated data structure to the rest of the network. Since the Ethereum network is a fully visible environment, attempts to extend the blockchain in invalid ways are easily detected and thwarted.

A high number of trust domains makes collusion difficult and high visibility makes extending the blockchain in invalid ways a very difficult proposition.

Permissioned Ethereum Network

Permissioned Ethereum networks consist of a far fewer number of nodes belonging to a small number of trust domains (but rarely a single trust domain, as that will defeat the purpose of using a blockchain)

Let’s analyze the trust properties of a private Ethereum network.

Participants propose transactions to be added to the blockchain data structure just like in the public Ethereum network. The nodes in a private Ethereum network are typically running a protocol like Paxos, Raft or PBFT to select the node which is responsible to add new transactions to the blockchain data structure and gossip the result out to the rest of the network.

The chosen node can perform the following kinds of attacks:

• It can withhold or delay adding transactions to the blockchain data structure
• It can extend the blockchain data structure in invalid ways

It’s difficult to prevent a node to withhold or delay adding transactions to the blockchain data structure. Even if a different node from a different trust domain is selected after some time, it’s easy for the small number of trust domains to collude with each other and censor the transaction.

This is clearly bad. But it’s important to realize that transaction censorship and delay is the only attack vector over here. This might not be acceptable for certain use cases but it might be acceptable for others.

Extending the blockchain data structure in invalid ways however can easily caught by the rest of the network as the updated blockchain data structure is gossiped out to all the nodes and validated by them all independently. Even if a trust domain doesn’t have a node participating in the process of extending the blockchain, it will be able to detect attempts to extend the blockchain in invalid ways.

Permissioned Ethereum networks also suffer from another interesting weakness. Consider a permissioned Ethereum network consisting of nodes from just two trust domains. Now imagine they decide to add nodes from a third trust domain to the network. It’s possible for the two trust domains to collude and rewrite the blockchain history before adding the third party and the third party will be none-the-wiser. This weakness stems from a low number of trust domains which makes collusion easier, and limited visibility as the blockchain is not visible to new trust domains till they are added to the blockchain network.

One approach to mitigating this weakness can be to periodically anchor the state of the blockchain data structure in a higher visibility and higher trust domain blockchain, such as the public Ethereum network.

Hyperledger Fabric

Hyperledger Fabric consists of multiple blockchains, called ‘channels’ in HLF parlance. Each channel is only visible to a selected set of nodes. We’ll focus our discussion to the trust properties of just a single channel.

Participants propose transactions to be added to the blockchain data structure (channel), signed with their private keys.

The transactions are sent to an orderer node (or set of nodes which collectively operate as a logical node) for inclusion in the blockchain. The orderer node(s) are often operated by a single trust domain.

While this level of centralization might seem alarming on first look, it’s important to realize that the only power the orderer has to censor or delay transactions for inclusion in the blockchain data structure, similar to the nodes in a permissioned Ethereum network. Even if we did distribute the ordering service among multiple trust domains, collusion between a small trust domains is still highly likely and doesn’t completely mitigate the censorship concerns.

The ordering service broadcasts the updated blockchain data structure to all the participating nodes in a channel and thus any attempt by the ordering service to extend the blockchain data structure in invalid ways can easily be detected by the rest of the network.

Similar to private Ethereum networks, it’s possible for the existing participants in a channel to lie about the blockchain data structure by rewriting it before adding a third participant to the channel. This weakness once again stems from a low number of trust domains (which makes collusion possible) and visibility only limited to existing participants — the new participant has to take the word of the existing participants regarding the state of the blockchain.

Corda

On the face of it, a Corda network looks fairly different from the other blockchain systems. But if we look closely, it’s easy to see that Corda consists of many small blockchains, each such chain dealing with the evolution of one or few states. We’ll call them state-chains, for the lack of a better word. Note that Corda doesn’t use this terminology but we’re using it for the sake of discussion in this article.

We’ll focus on the evolution of just a single state-chain and analyze its trust properties.

Nodes propose new transactions to be added to a state-chain, in a manner similar to that in permissioned Ethereum and HLF networks.

The nodes which play the role of extending the state-chain and sharing it with other nodes differs slightly in Corda. In Ethereum and HLF, a set of nodes are collectively responsible for adding transactions to the chain and then disseminating the updated chain to the rest of the network. In Corda however, the node which proposes the new transaction to the state-chain is responsible for requesting the permission of a ‘notary’ to extend the state-chain and then sharing the extended state-chain with other nodes on a need-to-know basis.

Corda requires each node wishing to extend the state-chain to obtain signatures from a notary before extending the state-chain. The notary is the entity responsible for ensuring that a particular link in the state-chain is never forked by refusing to sign an extension request if a link in the state-chain has already been extended. As a slight but important digression, it’s quite interesting to realize that Corda’s design allows each link in the state-chain to potentially nominate a different notary. The only constraint is that the notary responsible for a particular link to a state-chain must give its signature before the link can be extended. This design allows a Corda network to scale horizontally when required.

The notary poses a few interesting challenges. Before we discuss those challenges, it’s useful to know that a notary can either be operated by a single trust domain or be operated as a notary cluster by a few different trust domains. With this context understood, let’s turn to the challenges.

• A notary can refuse to sign the request to extend the state-chain thus leading to a censorship attack. A notary cluster operated by multiple trust domains can also lead to censorship attacks through collusion. Permissioned Ethereum networks and HLF both also suffer from similar censorship problems.
• More seriously, a notary can sign requests to extend the same link in the state-chain multiple times thus leading to state-chain forks

The second problem is more severe as notaries don’t share the internal data structure they use to maintain which states have been consumed with the rest of the network. A notary cluster with multiple trust domains mitigates this problem slightly but doesn’t solve it. Unlike Ethereum and HLF networks where the additions to the blockchain data structure are distributed to all participants and invalid additions and forks can be easily detected, notaries in Corda do not disseminate this information widely due to privacy concerns leading to this risk.

Notaries in a Corda network thus require a higher level of trust compared to orderers in HLF or nodes which add transactions to the blockchain in Ethereum as they can lead to forks in addition to just censorship attacks.

This risk factor can be mitigated by disseminating the information notaries maintain more widely, albeit at a risk to privacy. This is a fruitful area to investigate as creative solutions can be used to preserve privacy while still guaranteeing correctness, such as TEE based execution, zero knowledge proofs or other such techniques.

Finally, similar to permissioned Ethereum networks and HLF, state-chains suffer from another weakness common to all systems where the chain is only known by a few participants but later shared to another participant. The existing set of participants can collude to rewrite the state-chain before including the additional participant. The additional participant has to take on that risk or trust at least one trust-domain involved in the state-chain to know it won’t collude with others.

Note that Corda’s approach to building a privacy-first distributed ledger is quite insightful and we’ll talk about it in further detail in a future article. The point of this section is not to paint any ledger in a negative light but rather to talk about potential weaknesses so readers can carefully assess the strengths and risks when choosing a ledger for their use case.

We analyzed the trust properties of various blockchain systems: the public Ethereum network, private Ethereum networks, HLF as well as Corda networks.

We saw that a high number of trust domains makes collusion less likely, though private networks often don’t have a choice as they consist of nodes belonging to a smaller number of trust domains.

We also saw that the most common attack vector in permissioned networks with a few trust domains is transaction censorship or delay. As long as the updated blockchain data structure is disseminated to all the participants however, it is not possible to extend the blockchain data structure in invalid ways. We also saw that lower visibility of information due to privacy concerns can lead to entities extending the chain in potentially conflicting ways, such as in the case of Corda notaries which thus require a higher level of trust compared to chains where all the information is widely disseminated to all the participants.