What the heck is CatVM?

Taproot Wizards launched a cartoon yesterday known as CatVM. I can’t consult with it as a whitepaper, these are actual educational paperwork for adults. Within the cartoon, interspersed amongst the absurd infantile narratives, have been a number of priceless technical insights relating to completely different scaling proposals within the Bitcoin ecosystem. In fact, in true cartoon vogue, buried between wild exaggeration and embellishment.

The top aim of the cartoon was to suggest a brand new mechanism for transferring out and in of scaling layers constructed on high of Bitcoin. To disentangle that precise proposal from the cartoon, we’ll have to interrupt down the 2 items concerned.

The Constructing Blocks

Rijndael’s first OP_CAT experiment was establishing a vault, a scheme that enables a person to create an intermediate “staging” transaction to withdraw their funds from the vault. This kicks off a timelock, throughout which they’ll at any time ship their funds again to the vault or a safe chilly storage pockets, and after the timelock the person can freely withdraw the funds to the vacation spot they selected when starting the withdrawal course of. These are the solely two methods bitcoin despatched to the vault script will be spent.

Explaining the complete mechanics of how that is achieved is actually an article in itself, so I’m going to do one thing I normally don’t and hand waive this away as “magic.” (Defined right here by Andrew Poelstra) What this “magic” permits you to do, by creating non-standard Schnorr signatures and with the assistance of OP_CAT, is to construct the transaction the signature test is in opposition to on the script stack. This allows you to implement that sure elements of the transaction are precisely as outlined forward of time. It additionally permits you to put the output from a earlier transaction on the stack within the means of constructing the transaction spending it, which means you may examine outputs from the spending transaction in opposition to outputs from the earlier transaction. This lets you assure by evaluating them that sure elements of the earlier transaction’s outputs match sure elements of the brand new outputs. I.e. the script, or an quantity. So you may “carry ahead” elements of the previous outputs into the brand new ones, and implement that.

One thing else you are able to do with OP_CAT, which didn’t want Rijndael tinkering and experimenting with to show, is confirm merkle tree branches. As a result of you may CAT stack gadgets collectively, and Bitcoin already helps hashing information on the stack, you may slowly construct up a merkle tree root from a leaf node with the inside nodes. Hash two items collectively to get one hash, hash that with the pair hash, and so forth. Ultimately you get the foundation hash on the stack. You may then examine it with OP_EQUAL in opposition to a predefined root hash within the locking script.

Unilateral Withdrawal

These two constructing blocks are sufficient to facilitate a unilateral withdrawal mechanism from a gaggle shared UTXO. A merkle root will be embedded in a transaction utilizing OP_RETURN or one other mechanism that commits to a leaf node for every person. The UTXO script will be structured in order that any person with a steadiness can try and withdraw it. To take action they would offer the merkle department committing to the quantity they’re entitled to, the authorization proof corresponding to a public key to test a signature in opposition to, and assemble the transaction on the stack to confirm the suitable circumstances are met.

Much like Rijndael’s OP_CAT vault, this withdrawal transaction would perform as a staging level. Person funds could be restricted by a timelock, and they might not be able to finishing the withdrawal till it expires. At any time earlier than the timelock expires, every other person can create a fraud proof to cease the withdrawal and shove funds again into the group UTXO script. They will do that due to OP_CAT’s skill to confirm merkle timber. If somebody has used a particular merkle department to withdraw funds from the UTXO earlier than, then that was included in a block someplace. By establishing a transaction containing the SPV proof of that transaction inside an precise block, which may use OP_LESSTHANOREQUAL to confirm the blockheader meets some minimal issue, they’ll show on the stack that the merkle department was used earlier than. This enables duplicate withdrawals to be prevented.

Along with this, as a result of you need to use the “CAT on the stack” trick to make sure particular items of a earlier transaction have to be included within the subsequent, you may assure that the present merkle root is carried ahead into the following transaction after a profitable withdrawal. You can too assure that change from the withdrawal goes again into the group sharing script. This ensures that after one person withdraws their funds, the change UTXO is locked with a script that enables any remaining person to withdraw, and so forth. Any person can unilaterally withdraw their funds at any time in any order, with the assure that the rest of funds are nonetheless accessible to the remainder of the customers.

The VM Half

Readers ought to be conversant in the fundamental thought of BitVM. You may take an arbitrary computation and break it up into every of its constituent items and embed them in a big taproot tree, turning that computation right into a forwards and backwards problem/response sport. This lets you lock bitcoin with extra sophisticated circumstances than is straight supported by bitcoin script itself. The one actual shortcoming is the necessity to craft an enormous quantity of pre-signed transactions to facilitate this.

The requirement to make use of pre-signed transactions is in order that within the problem/response dynamic, you may assure that cash are spent again into the big taproot tree encoding it except an exit situation by hook or by crook is reached. OP_CAT and the power to “carry ahead” information from earlier transactions permits you to assure that without having pre-signed transactions.

So not solely does this scheme enable any person to unilaterally exit on their very own, it additionally permits locking circumstances supported by a second layer that aren’t supported by Bitcoin script to really be enforced within the withdrawal course of. I.e. if some cash have been encumbered by a wise contract the bottom layer doesn’t perceive, after which withdrawn from the second layer, these extra sophisticated circumstances may nonetheless be settled accurately on the bottom layer because the cash are withdrawn.

The Lacking Piece

One factor that OP_CAT doesn’t allow is updating a merkle tree root representing person balances off-chain verifiably. It might allow an already dedicated state to facilitate unilateral withdrawals, however that’s as a result of an entire part of the tree is definitely put on-chain and verified. To replace that root off-chain by definition means you aren’t placing the information on-chain. This represents an issue. There isn’t a method with simply CAT to effectively confirm that every one adjustments to the merkle tree have been licensed correctly by the related customers.

Somebody(s) needs to be trusted, and by the character of issues able to spending the UTXO nonetheless and wherever they need, to effectively substitute an previous state root with a brand new one to signify all off-chain steadiness adjustments. A brand new opcode along with OP_CAT, corresponding to OP_ZKVERIFY, could be wanted to do that in a trustless method.

This wouldn’t be the tip of the world with out OP_ZKVERIFY although. The entity updating the merkle root for off-chain transfers might be an n-of-n multisig, with 100% of the contributors required to log off on any root adjustments. This boils right down to the identical belief mannequin as BitVM primarily based pegs, the place so long as a single trustworthy participant exists, nobody’s funds will be stolen. It’s a stark enchancment over current BitVM designs nonetheless with regards to the withdrawal course of.

In BitVM pegs, customers should not have a unilateral withdrawal mechanism. Peg operators have to be trusted to satisfy person withdrawals, realizing that they’ll declare again funds they’ve spent doing so comparatively trustlessly from the BitVM peg. Whereas the incentives of this are very strong, it nonetheless does require customers primarily getting permission from another person to exit the system, they can not do it on their very own. With CatVM, customers can declare again their funds unilaterally, and an operator will not be required to entrance their very own liquidity to course of withdrawals.

Wrapping Up

Total, the design is incomplete by way of development. This isn’t one thing I might name a Layer 2 in and of itself. It’s the core of 1, the mechanism and construction for a way funds are locked right into a Layer 2, and the method for a way customers can withdraw their funds. It undoubtedly has plenty of flexibility and usefulness to it.

Within the worst case situation, customers don’t want anybody’s permission to soundly declare their funds again on-chain. It additionally permits extra versatile programmability of funds, whereas nonetheless carrying the enforcement of these circumstances to the bottom layer within the occasion of worst case unilateral exits. If at some point we do ultimately get one thing like OP_ZKVERIFY, the off-chain state development can change into an truly trustless course of.

I don’t anticipate any concrete demos within the close to future, but it surely undoubtedly is a sound thought in my view, and one thing price contemplating. It additionally reveals that the wizards are doing a little bit extra than simply pumping silly jpegs.