A forthcoming problem with bitvm

Introduction

In the past few months, several bitvm companies announced preparations for launching on mainnet, and I began to research their plans. Some of their designs are, I think, unnecessarily expensive. I think I can offer some improvements.

What's wrong

I talked to employees of Citrea and Alpen Labs, who told me that both plan to do this: they will have a set of one or more "sequencers" produce blocks on a sidechain. For purposes of this document, I will pretend there is one sequencer. Each sidechain block she produces will create "state differences," namely, things that changed in that block compared to the previous block. For example, perhaps User A had 5 "sidechain btc" in block 67, and User B had 1; but in block 68, User A has 4, and user B has 2. Thus, the "state difference" would be that in block 5, User A's balance fell by 1 and User B's balance rose by 1. Both companies plan to post these state differences on bitcoin, thus adding lots of data to bitcoin each day.

I asked their employees why they plan to post this data on bitcoin, and they said their unilateral exit scheme requires users to have access to the sidechain's block data. Specifically, if the sequencer creates an invalid block N, or refuses to process a withdrawal in block N, she can be challenged on bitcon's blockchain. But to do that, users need the ability to have, or reconstruct, block N. They can reconstruct block N if they have block N-1 and know the state differences created in block N, and to get block N-1, they can reconstruct it from the state differences created in block N-2, etc. This can go back to the sidechain's genesis block, if necessary. Thus users can always recover block N so long as every block's state differences are posted on bitcoin. So that's (supposedly) the minimum amount of data the sequencer needs to post on bitcoin so her users can create a challenge, if necessary.

I think the design outlined above is unnecessarily expensive. I hereby propose the following alternative.

My proposal

Have a set of one or more sequencers produce blocks on a sidechain -- again, I will assume one sequencer. Each block modifies the balance of one or more "sidechain outputs," represented as a sidechain address and its balance. Each block should take every sidechain output of all the sidechain's users and smart contracts, and convert them into an indexed merkle tree, such that each user and each smart contract has an output in their own unique leaf of that tree. If any sidechain transaction changes the balance of an address, post a copy of the transaction in the leaf of the address whose balance was modified. Then, instead of posting all the state differences on bitcoin, only post the root of this merkle tree -- i.e. a single, 32 byte hash.

In every sidechain block, let any user challenge the sequencer to reveal two things: the user's leaf of that tree, and a merkle proof demonstrating its inclusion in the merkle root. If any user issues such a challenge, the user must pay for the transactions by which the sequencer reveals this data; but in the "happy path," the user does not need to do so, because the sequencer sends the user their leaf data out-of-band, e.g. on another blockchain (this "secondary" data availability layer doesn't matter as much -- it could even be an email).

If a user gets their leaf data out-of-band for block N, they can use it to request a withdrawal in block N+1 based on their latest balance, and, if necessary, challenge the sequencer to prove she sent the user the balance in the user's latest leaf. And if any user does *not* get their leaf data out-of-band for block N, that user can challenge the sequencer to reveal their leaf for block N on bitcoin. This approach improves the "data availability problem" with much less burden on bitcoin in the happy path.

How this helps

Why is this an improvement? Because it takes one of the best features of lightning and applies it to bitvm-based sidechains: in lightning, the layer two's data stays off-chain in the happy path. And in the sad path, while it is true that a user who exits has a set of transactions with more data in them than is typical in bitcoin (e.g. HTLCs have an extra preimage/hash pair that is not present in most bitcoin transactions), that user alone pays to put that extra data on the blockchain, and only if they must use the "sad path."

By contrast, the "bad" model of bitvm sidechain that I am critiquing in this document posts lots of sidechain data on bitcoin even in the "happy path." This is unnecessarily expensive, and the costs of posting all this data on bitcoin must be passed on to users of the sidechain, resulting in higher sidechain fees. If, instead, you only post a hash of the data in the happy path, the sidechain's fees can be much lower; moreover, in the sad path, the extra data is paid for by the exiting user, just like in lightning. Thus you emulate best practices.

Conclusion

If you are a bitvm company, please consider using my proposed model instead.