Scaling and bridging with sidechains

By: Barnabé Monnot

We've all heard it before:

"Bitcoin only does 7 transactions per second. How can it compete with Visa's thousands?" - Unaware Guardian

The "transactions per second" metric has many, many flaws, but it expresses correctly the idea of throughput: a blockchain can only do so much work in a given amount of time.

When Alice sends 10 tokens to Bob, all full nodes verify the validity of the transaction and update their state, crediting Bob's account with 10 tokens and debiting Alice's with the same amount. While transactions may be simple payments or more complex operations, the throughput sets the limit of how much work a full node does.

Say we are not willing to change the protocol in order to increase the throughput of the chain. Bitcoin's protocol has ossified over the last 10 years, such that new changes are extremely difficult to make, providing a certain robustness to the network.

In this situation, the only way to scale a blockchain *network* further is to spawn new chains. These new chains provide further blockspace for their users, lowering network fees across the board. They are run by their own full nodes and block producers/validators.

The communication between chains is critical to create a network, where users of one chain are able to trade assets securely with users of another. Communication takes place entirely at the level of *bridges* between two chains. Bridges are an essential piece of blockchain networks: their design and properties almost entirely determine the security of the network as a whole.

As an important step to understand how scaling works under the hood, we'll provide a mental model showing how bridges operate. We then discuss the simplest form of scaling, sidechains, emphasizing their security guarantees.

Bridge model

In the following, we consider two chains, Origin and Destination. Origin and Destination run the same protocol, e.g., are both EVM-based chains, but they are operated by separate sets of full nodes. The state of Origin is obtained by executing all transactions published in Origin's chain of blocks, and the same goes for Destination.

Alice is an Origin user. On her Origin account, she owns some fungible and non-fungible tokens. Alice notices that Bob, a Destination user, owns the latest Catatat, a limited edition NFT minted on Destination. Bob has put the NFT for sale, priced at 50 UND, a stablecoin produced by the United Nations. Alice happens to have 100 UND in her Origin account. She wants to bridge 100 UND to Destination to facilite the purchase of the Catatat.

To do so, Alice must find a bridge to Destination. Essentially, a bridge is an account on Origin, which takes custody of assets received from users of Origin. Once the bridge receives the assets, some mechanism creates an equivalent balance on the Destination chain, crediting the user with their assets on the other side. This model is known as a two-way pegged bridge.

Making bank

An analogy helps. What happens when Alice goes to her bank with a $100 note, to deposit the note on her bank account? The bank takes custody of the $100 note and credits her account with one hundred "virtual" dollars, basically an entry in the bank database.

Wow, what happened here!? Did we just create $100 out of thin air, like alchemists? Not quite, of course. Assuming the bank here must back each bank account balance one-to-one with money in their vault, there really is only 100 *usable* dollars here. The bank cannot go around and use the note to purchase assets for itself.

So far so good, Bob receives $50 from Alice, credited to his account at the bank. Now Bob wants to withdraw the money, so Bob goes to an ATM and asks for a $50 note.

It turns out this analogy perfectly encapsulates the structure of bridge interactions. Bridges are essentially concerned with the three steps above: depositing assets, updating balances and eventually processing withdrawals. In our bank model, we trust the (centralized) bank to update balances correctly, but can we extend that trust to the Destination chain?

Where Layer 1 is Origin and Layer 2 is Destination

Parsing the differences between the many scaling solutions out there can be a tall order. The task becomes much simpler once we realize this question, "how do I trust Destination?", is the key. Its answer tells us what each scaling design allows for and the security it provides. We begin our exploration with sidechains, where bridges simply take the word of Destination at face value.

Sidechains: Scaling out with parallel chains

With increasing congestion and increasing transaction fees on "Layer 1" networks, sidechains were introduced to release the pressure. A sidechain is simply a new blockchain, running in parallel to the "parent chain", with a bridge between the two to move assets around. On Ethereum, popular sidechains include Binance Smart Chain (BSC) or the Polygon PoS chain.

How sidechains work

We give here a simplified model of a sidechain, where the parent chain is a smart contract platform such as Ethereum[1]. Block producers on the sidechain come to consensus over the current state, i.e., the value of all accounts for all users of the sidechain. This agreement is summarized by a "commit", a single, short string of characters obtained by "hashing" all account values together. If any of the account values is changed, the new commit will differ entirely from the original commit.

Once an agreement over the commit is obtained, validators of the sidechain publish the commit to the main chain, Origin. Origin now has a concise commitment to the current state of its sidechain, Destination. Bringing back our previous example, a bit of cryptographic magic allows Bob to prove that his ownership of 50 UND on Destination is consistent with the commit published on Origin. Alternatively, there would be no way for Bob to convince anyone that the published commit is consistent with him owning 100 UND on Destination.

So when Bob withdraws the 50 UND he owns on Destination to Origin, he typically does two things:

• Given the commit published on Origin, Bob convinces Origin that he owns 50 UND on Destination.

• Bob convinces Origin that he has initiated a withdrawal from Destination.

The second step is important. Remember that we printed 50 "virtual" UND on Destination to Bob's account. We must ensure that once Bob withdraws, he can't do it again, and that the amount of "virtual" UND match the amount locked in the bridge contract. A common mechanism here is a "Proof-of-Burn", equally verifiable from a published commit. The Proof-of-Burn tells Origin that the withdrawal was processed on Destination, and so virtual tokens and bridge-locked tokens are still balanced.

Security of a sidechain

Sidechains typically boost network parameters to provide more scale, for instance decreasing block times or increasing block sizes. This results in a smaller set of block producers as well as a smaller set of validating full nodes, that must expend greater resources to follow the chain.

The main threat to the security of sidechains is corruption of the state by the set of block producers, e.g., "printing money" on the sidechain and withdrawing it all to the parent chain. The level of decentralization among block producers is critical to gauge the security of the sidechain.

Let's look at a potential attack. We have Origin, a chain suffering from high congestion, and Destination, a sidechain to Origin. Alice has made her 100 UND deposit to the Destination bridge on Origin. She is credited with 100 UND on Destination.

The bridge account custodies 100 UND, backing 100 UND minted on Destination. In our example, given her 100 UND balance on Destination, Alice sends 50 UND to Bob, who withdraws them on Origin.

So far so good. But suppose Destination is controlled by a small set of block producers, who collude to produce an invalid state transition, crediting 50 UND arbitrarily to Carol. Carol is now able to claim to the bridge that she owns 50 UND, and withdraw them to Origin.

Here we assume that the bridge relies on Destination's state to allow withdrawals: Carol ostensibly owns 50 UND after the invalid state transition, so the bridge lets her withdraw this amount on Origin, no questions asked. On the other side of the bridge, Alice owns 50 UND too, yet she won't be able to withdraw them on Origin, as the bridge was emptied.

In other words, this is a scenario where the security of the bridge is fully reliant on the security of the domains it bridges to. The weakest link determines the security of user assets. In the sidechain model with a smaller set of validators, the sidechain itself is often the most insecure component.

Another issue is censorship. Let us make a weaker assumption on the set of block producers: they are not able to corrupt the state (and so, steal funds), but they could refuse to include transactions from a specific user. If Bob is censored, once Bob submits a withdrawal transaction to bridge his 50 UND back to Origin, the transaction is never included on the sidechain. Bob's assets remain "frozen" on the sidechain. Censorship is possible if *all* block producers refuse to include Bob in their block, or if a minority of honest block producers is itself censored by a majority of block producers, who ignore the honest blocks.

Bridge hacks!

There are two more ways in which the bank analogy (unfortunately!) holds. The first has to do with robberies, and the second with bank runs.

Robbers in the real world choose which targets to attack: small businesses, homes, random passersby... But nothing nets them a higher reward than stealing from the source directly, bank vaults. Bridge contracts are similar in this respect. As users deposit more assets to be bridged, the bridge contract holds greater and greater amounts, sometimes totalling billions of dollars. This makes bridges a very attractive target to exploit.

So far, the largest hacks had more to do with loopholes in the bridge code than with the action of malicious sidechain validators corrupting the state and stealing assets. For instance, assets of the Ronin bridge were stolen in March 2022, for a total amount exceeding $600 million at the time of the hack.

The Ronin bridge featured a simpler design than the one we considered in our sidechain model. Anytime a user submits a deposit or a withdrawal request, at least 5 validators out of 9 registered on the bridge must sign a transaction vouching for the deposit or the withdrawal. This "multi-signature" (multisig) bridge design is quite popular, and doesn't require a separate consensus from a decentralized set of validators. The validators registered in the multisig contract are usually well-known entities, or partners to the sidechain project.

In the case of the Ronin hack, 4 keys of the multisig were held by the same entity, which the attacker managed to control. An additional signature was obtained by making use of a previously "open" key held by a DAO, granting the attacker access to enough keys. The attacker authorized two withdrawals, one for ETH assets and another one for USDC, to their own address. The hack was completed within minutes.

The "bank run" may take place as a consequence of a hack. Users of the sidechain, seeing that their assets on the sidechain are no longer backed by an equivalent basket of assets held by the bridge, precipitate to withdraw before the bridge is emptied. The same phenomenon is sometimes observed when doubts are cast over an exchange's solvency, or with asset-backed stablecoins.

Conclusion: Towards safer scaling

The security of a scaling solution is equal to the security of its weakest link. Thinking about sidechains already allowed us to discuss two specific threats, that will reappear throughout:

1. How is the user protected against theft of their assets?

2. Can the user assets be frozen?
   

For a sidechain, the answer to both of these questions depends on the honesty of the sidechain's validator set, and not on the parent chain itself. We will consider more designs which guarantee the same level of security than the parent chain itself. These designs heavily rely on the property of data availability, which allows the parent chain to verify for itself the result of computations on its network.

Notes:

For ease of exposition, the model we describe here is closer to a "commit chain", a specific instantiation of the sidechain design. The security properties of a commit chain are however equivalent to those of a sidechain. ↩️