This is exactly what I was looking for, the diff of it with BitVM. It boils down to the OP_CAT upgrade enabling unilateral withdrawals though some cryptographic magic and verifying merkle tree branches by conCATenating the branch's nodes and hashing them.
Someone(s) has to be trusted, and by the nature of things capable of spending the UTXO however and wherever they want, to efficiently replace an old state root with a new one to represent all off-chain balance changes. A new opcode in addition to OP_CAT, such as OP_ZKVERIFY, would be needed to do this in a trustless manner.
This wouldn’t be the end of the world without OP_ZKVERIFY though. The entity updating the merkle root for off-chain transfers could be an n-of-n multisig, with 100% of the participants required to sign off on any root changes. This boils down to the same trust model as BitVM based pegs, where as long as a single honest participant exists, no one's funds can be stolen. It is a stark improvement over existing BitVM designs however when it comes to the withdrawal process.
In BitVM pegs, users do not have a unilateral withdrawal mechanism. Peg operators must be trusted to fulfill user withdrawals, knowing that they can claim back funds they have spent doing so relatively trustlessly from the BitVM peg. While the incentives of this are very solid, it still does require users essentially getting permission from someone else to exit the system, they cannot do it on their own. With CatVM, users can claim back their funds unilaterally, and an operator is not required to front their own liquidity to process withdrawals.
I don’t expect any concrete demos in the near future, but it definitely is a sound idea in my opinion, and something worth considering. It also shows that the wizards are doing a little more than just pumping stupid jpegs.
....
reply
Good explanation, thank you.
reply
In BitVM pegs, users do not have a unilateral withdrawal mechanism
In the unisob model of bitvm pegs, they do
reply
jhjh
reply
Thanks for the information. However couldn't quite understand but it seems some upgrade/enhancement to BitVM.
reply
Bitvm doesn't outsource ZK into some opcode. Also catvm requires soft work while bitvm merely benefit from it.
reply