(CCS '23) TrustBoost-Boosting Trust among Interoperable Blockchains

This post is based on the paper review I presented at the SNU Blockchain Academy, Decipher. I have abstracted the preliminaries in this post, so if you want to know more about them, you can refer to my (korean) presentation video. The video will be uploaded soon on the Decipher YouTube channel.

Personal

The basic idea of this paper is to deploy multiple mirror smart contracts on various Byzantine blockchains and achieve consensus between them through Cross-Chain Communication (CCC). Although the proposed scheme is neither efficient nor economical, it was notable as the first attempt to “boost” trust rather than merely “borrow” it. The analogy between traditional distributed systems and the proposed system was particularly interesting, adding significance to this new scheme.

Motivation

A common solution to enhance the security of blockchains with weaker security is through the lending/borrowing of trust. A standard method for this is checkpointing, where block headers are periodically submitted to and verified by a chain with stronger security. However, this approach supports only a one-way transfer of trust (from a stronger blockchain to a weaker one) and involves consensus-level changes in the weaker blockchain. For example, the fork choice rules of the weaker blockchain should comply with the checkpoint submissions.

Contribution

This paper proposes a way to boost security by creating a combined ledger secured by multiple blockchains. Through this suggested scheme, multiple chains can contribute to the security of the ledger. This system is implemented via smart contracts, making it lightweight and not requiring changes to the consensus layer. Additionally, the use of smart contracts allows for flexible adaptation of this system.

Preliminaries

Ledger interface

In this paper, we assume that there are three ledger interface. This can be regarded as abstraction of various interfaces that most blockchains provide.

1. Read : Access the latest ledger states
2. Submit : Submit transactions to change the states
3. Check : Check whether the transaction is committed
   • This may return a commitment certificate (e.g. quorum certificate in BFT-SMR) These three interfaces are provided by both local ledgers and the combined ledger.

System model

Active mode

In active mode, the ledgers communicate via Cross-Chain Communication (CCC), which introduces two interfaces, “Send” and “Deliver”. “Send” refers to transmitting messages to another blockchain, and “Deliver” means receiving messages from another blockchain. Various CCC protocols such as Cosmos IBC, Chainlink CCIP, and others can be used in this system. Consensus among the ledgers can be achieved through these CCC mechanisms.

Passive mode

In passive mode, there is no communication between the ledgers. Therefore, blockchain clients have read-only access to other ledgers, which means consensus is impossible in the presence of more than one faulty node. Because there is no consensus on the current ledger status, the combined ledger cannot provide the read interface.

(Note: The paper includes proof that a weaker version of consensus is possible even in this mode. However, I think this differs somewhat from the usual or informal concept we have of the word “consensus” in blockchain. I excluded it from the presentation, but I recommend checking the paper as it actually provides academically valuable insights.)

Comparison to the Traditional Distributed System

In comparison to traditional distributed systems, each process can be thought of as a blockchain client, and objects can be regarded as blockchain ledgers.

The passive mode is akin to a simplified version of the classic memory-sharing model, where processes have read-only access to the object. This simulates how each blockchain client has read-only access to the ledger, effectively forming a single ledger.

Conversely, the active mode is described as a hybrid model that combines the shared memory model with the message passing model. This is because, unlike in passive mode, objects can change states by sending messages to other objects.

The TrustBoost Protocol

Active mode: TrustBoost

The active mode, referred to as the TrustBoost system, uses the ledger interface and Cross-Chain Communication (CCC) described earlier. The TrustBoost contract is deployed as a smart contract on each blockchain. For simplicity, we will assume that this contract implements a simple 2/3 majority vote consensus algorithm. There are three message types: propose, vote, and commit. Let’s examine how the TrustBoost smart contract provides three ledger interfaces: submit, check, and read.

Submit

The submit function accepts requests from clients and processes the transaction as follows:

1. Prompt CCC to broadcast a proposal.
2. Once the proposal is received, vote on the transaction via CCC.
3. Once the commitment condition is met (e.g., gathering at least 2/3 of the votes), commit the transaction to the local blockchain.

(Note: “dst” in line 4 is likely a typo for “k”, where “k” represents the ledger identifier on which the contract is deployed.)

Check

This function checks if the transaction is committed on at least 1/3 of the blockchains and returns the result.

(Note: “m/3” mentioned in line 6 seems to be a typo of “2m/3”.)

Read

Similarly, the read function returns the current state if the majority of the chains agree on that state.

Passive mode: TrustBoost-Lite

The passive mode, called TrustBoost-Lite, does not have the support of CCC, hence the combined ledger interface cannot provide a read interface. Additionally, TrustBoost-Lite uses a UTXO model, where the transaction can be represented as <input, output>.

Submit

The submit function in TrustBoost-Lite is straightforward, involving the submission of transactions on “m” blockchains.

(Note: The small “k” mentioned in line 3 seems to be a typo for “dst”.)

Check

The check function verifies two conditions and returns the result:

1. At least 2/3 of the local blockchains have committed the transaction.
2. All inputs are outputs from globally committed transactions.

(Note: The notation is somewhat confusing here. Previously, “k” represented the local ledger identifier, but it is used as a non-constant variable from line 3 onwards.)

Implementation

TrustBoost is implemented on Cosmos chains using CosmWasm. You can find the actual code on the GitHub repository of TrustBoost. TrustBoost adopts Informational Theoretic Hotstuff (IT-HS) due to the absence of signatures in the IBC protocol.

In the Cosmos IBC process, after a block and its certificate are submitted by the source chain, the destination chain’s light client verifies the certificate and delivers the block to the destination chain. Since the certificate is removed by the light client after verification, the smart contract on the destination chain cannot check the certificate. Therefore, the authors opted for IT-HS, which does not require a threshold signature or Public Key Infrastructure(PKI).

Workflow

The TrustBoost contract serves as the entry point for application contracts, specifically the NameServiceX contract in this implementation. Additionally, a mirrored version of the application contract must exist on each chain, as TrustBoost simulates the transaction (without changing the state) through it. The overall workflow is as follows:

1. A client initiates a transaction by calling the TrustBoost contract, targeting the NameServiceX.
   • Here, the transaction submitted to the TrustBoost contract is likely a function call, with the parameter being another transaction directed at NameServiceX, to the best of my knowledge.
   • So it is like ransaction-within-a-transaction. I will refer to the inner transaction as txNameService and the outer as txTrustboost.

2. The txTrustboost initiated in step 1 is logged on the local blockchain.
3. The consensus protocol via Cross-Chain Communication (CCC) is triggered to decide whether to commit the txNameService.
4. Once the txNameService is committed by TrustBoost, it calls NameServiceX to execute the request.
5. Clients can check the global states from the contracts.

Evaluation

The evaluation environment utilized an AWS m5.4xlarge instance featuring 16 vCPUs and 64GB of memory. In this setup, “m” denotes the number of blockchains participating in the TrustBoost protocol. The assessment focused on gas usage and latency from the submission to the execution (possibly referring to the commitment) of transactions.

As depicted in Table 1, with 10 blockchains involved, the gas usage reached 600 million gas (costing between $2 and $10), and the latency was notably high at 138.2 seconds. This latency is significantly influenced by the number of Inter-Blockchain Communication (IBC) messages. Notably, both the number of IBC messages and the gas usage scale quadratically with the number of chains, despite efforts to reduce expenses by batching requests to amortize the gas cost.

The authors also measured latency under four different attack types, each simulated with four blockchains(m=4). In the Informational Theoretic Hotstuff (IT-HS) protocol, a view change sub-protocol ensures liveness. This sub-protocol mandates entering the next view by broadcasting abort messages if no progress is made in the current view. Based on this setup, the authors outline the following four attack scenarios:

1. Primary blockchain crashes: The primary blockchain crashes at the beginning.
2. Primary blockchain equivocates: The primary blockchain sends different proposals.
3. Non-primary blockchain equivocates: A non-primary blockchain sends different votes.
4. Non-primary blockchain aborts: A non-primary blockchain sends an abort message.

The evaluation, as described in Table 2, is quite intuitive, because the first two attacks significantly threaten the security of the consensus (necessitating a view restart), while the latter two have minimal impact. The confirmation latency doubles under the first two attacks, as it takes two views to terminate; the other attacks hardly affect the latency.