Bitcoin Covenants Part 5: MATT and OP_CCV Explained

That is Part 5 within the technical article sequence about Bitcoin covenants by Cointelegraph Analysis. To learn the earlier article click here. 

MATT (Merkleize All The Things) is a great contract framework for Bitcoin that permits stateful contracts and scalable fraud proofs. A stateful contract carries data ahead throughout a number of transactions and can replace this data because the contract evolves. Commonplace Bitcoin scripts don’t present this functionality, as a result of every transaction is evaluated independently with no reminiscence of earlier executions.

Each covenant proposal permits state-carrying UTXOs to an extent, as illustrated by scripting languages akin to Sapio, which builds on OP_CTV. This works by utilizing addresses to characterize a finite state automaton, the place transactions perform because the state transitions. Nonetheless, there isn’t a solution to elegantly implement numerical logic on this paradigm, a niche crammed by MATT, and particularly its proposed implementation by way of OP_CCV. As a result of MATT permits dedicated knowledge to be computed at spend time and re-embedded into the subsequent output, every spend can derive a brand new state dynamically, as an alternative of selecting from a predetermined set of states. 

How OP_CCV commits state right into a Taproot key

To know the MATT proposal, it’s helpful to first overview how Taproot commits knowledge by way of public keys. Each Taproot output accommodates a base public key, referred to as the inner key, which could be cryptographically modified or “tweaked” to decide to additional data. Formally, the tweaked public secret is Q = P + t·G, the place P is the inner key, G is the generator of the secp256k1 elliptic curve, and t is a tagged hash of P and the dedicated knowledge. 

In an everyday Taproot output, this dedication sometimes encodes the Merkle root of a taptree, which accommodates hidden spending paths. MATT builds on this mechanism to additionally embed contract state into the important thing. As an alternative of embedding advanced logic immediately in Bitcoin’s scripting language, MATT encodes computation as a sequence of state commitments, and the chain verifies solely that every state transition is legitimate.

MATT could be realized by way of totally different opcode mixtures. Probably the most direct and well-specified implementation depends on OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV offers the primitive that makes state-carrying UTXOs possible inside Taproot.  OP_CCV permits a script to confirm {that a} Taproot enter or output key has been tweaked to decide to a particular piece of state knowledge. The interior secret is first tweaked with a hash of the contract’s present state, and then Taproot’s customary taptree tweak is utilized on prime. The ensuing output key due to this fact commits to each the tapscript  (the set of spending circumstances) and the present state of the contract.

OP_CCV can then implement what state is carried ahead into the subsequent output. It permits the script to examine the state knowledge offered on the witness stack, carry out computations on it, and require that the ensuing up to date state is appropriately re-committed in a specified output. That is how state transitions are enforced on-chain. The stack format is:

<knowledge> <index> <pk> <taptree> <mode> OP_CHECKCONTRACTVERIFY

The opcode helps three modes for checking an output in addition to a separate enter mode. In default mode, your entire BTC worth of the enter UTXO is allotted to the desired output; in deduct mode, solely a portion equal to the output’s quantity is assigned, leaving the rest obtainable for additional outputs; and in ignore mode, the script and knowledge dedication are verified with out constraining the quantity.  As a result of default and deduct modes are designed to protect worth throughout checked outputs, transaction charges have to be paid by way of separate fee-paying inputs. A devoted charge enter and change output could be added to the transaction with out conflicting with the covenant’s constraints. This prevents the unintended burning of funds that may happen in additional primitive covenant implementations, akin to OP_CTV or SIGHASH_ANYPREVOUT. It additionally addresses a serious limitation of presigned-transaction-style covenants, which usually outline quantities upfront and due to this fact can not accommodate dynamic charge changes or partial unvaults.

OP_CCV + OP_CAT: Merkle Proofs and Fraud Proofs

When OP_CCV is mixed with OP_CAT, the total MATT framework turns into much more expressive. OP_CAT permits byte concatenation in Script, which makes it attainable to assemble and confirm Merkle proofs immediately on-chain. Two distinct Merkle bushes are related to a Taproot output in such an association. The primary is the acquainted Taproot script tree (the taptree), whose leaves are the contract’s spending scripts. The second is a separate state tree, whose leaves are the contract’s knowledge, such because the intermediate steps of a computation.  The OP_CCV + OP_CAT script can confirm a Merkle proof in opposition to the present state tree root, compute the up to date root after a transition, and use OP_CCV to pressure the subsequent output to decide to it. 

This building permits fraud-proof systems with a slashing situation during which an extended computation is dedicated off-chain, and solely the precise disputed step (with its path within the binary tree) must be revealed and verified on-chain. Comparable programs exist as optimistic rollups on different blockchain programs: the total computation runs off-chain, and the on-chain contract solely intervenes when somebody raises a problem. Fraud proofs require that the computation be compiled all the way down to a binary circuit or equal step-by-step illustration that may be dedicated to in a Merkle tree. OP_CCV + OP_CAT would keep away from the necessity for the Lamport one-time signatures and pre-signed transaction graphs that BitVM depends on to implement state consistency.

Past fraud proofs, the OP_CCV and OP_CAT mixture additionally has implications for vaults. OP_CCV alone can implement vaults, however when mixed with OP_CAT, it permits totally featured vaults which might be primarily equal to the performance proposed by OP_VAULT. As James O’Beirne, the writer of OP_VAULT, has noted, OP_CCV represents a extra normal and sturdy design that successfully supersedes his earlier proposal.

Within the subsequent article on this sequence, we are going to transfer on from normal covenant proposals to overview application-specific opcodes akin to OP_VAULT, OP_UNVAULT, and OP_EVICT. Every of the opcodes are designed to unravel a particular downside moderately than present broad programmability.

Journal: Bitcoin holders have received eCash — What can you do with it?