This is Part 5 within the technical article collection about Bitcoin covenants by Cointelegraph Research. To learn the earlier article click on right here.
MATT (Merkleize All The Things) is a brilliant contract framework for Bitcoin that permits stateful contracts and scalable fraud proofs. A stateful contract carries data ahead throughout a number of transactions and might replace this data because the contract evolves. Standard Bitcoin scripts don’t present this functionality, as a result of every transaction is evaluated independently with no reminiscence of earlier executions.
Every covenant proposal permits state-carrying UTXOs to an extent, as illustrated by scripting languages reminiscent of Sapio, which builds on OP_CTV. This works by utilizing addresses to signify a finite state automaton, the place transactions operate because the state transitions. However, there isn’t a technique to elegantly implement numerical logic on this paradigm, a spot crammed by MATT, and particularly its proposed implementation by way of OP_CCV. Because MATT permits dedicated knowledge to be computed at spend time and re-embedded into the following 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 perceive the MATT proposal, it’s helpful to first assessment how Taproot commits knowledge by way of public keys. Every Taproot output comprises a base public key, referred to as the inner key, which might be cryptographically modified or “tweaked” to decide to additional data. Formally, the tweaked public key’s 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 usually encodes the Merkle root of a taptree, which comprises hidden spending paths. MATT builds on this mechanism to additionally embed contract state into the important thing. Instead of embedding advanced logic instantly 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 might be realized by way of totally different opcode mixtures. The most direct and well-specified implementation depends on OP_CHECKCONTRACTVERIFY (OP_CCV). OP_CCV supplies 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 inside key’s first tweaked with a hash of the contract’s present state, after which Taproot’s customary taptree tweak is utilized on high. The ensuing output key due to this fact commits to each the tapscript (the set of spending situations) and the present state of the contract.
OP_CCV can then implement what state is carried ahead into the following 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 accurately re-committed in a specified output. This is how state transitions are enforced on-chain. The stack format is:
The opcode helps three modes for checking an output in addition to a separate enter mode. In default mode, the complete BTC worth of the enter UTXO is allotted to the required 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. Because 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 alter output might 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, reminiscent of OP_CTV or SIGHASH_ANYPREVOUT. It additionally addresses a significant limitation of presigned-transaction-style covenants, which usually outline quantities upfront and due to this fact can’t 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 complete MATT framework turns into much more expressive. OP_CAT permits byte concatenation in Script, which makes it attainable to assemble and confirm Merkle proofs instantly on-chain. Two distinct Merkle bushes are related to a Taproot output in such an association. The first 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 following output to decide to it.
This building permits fraud-proof methods with a slashing situation through which an extended computation is dedicated off-chain, and solely the particular disputed step (with its path within the binary tree) must be revealed and verified on-chain. Similar methods exist as optimistic rollups on different blockchain methods: the complete computation runs off-chain, and the on-chain contract solely intervenes when somebody raises a problem. Fraud proofs require that the computation be compiled right 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.
Beyond 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 absolutely featured vaults which might be basically equal to the performance proposed by OP_VAULT. As James O’Beirne, the writer of OP_VAULT, has famous, OP_CCV represents a extra common and sturdy design that successfully supersedes his earlier proposal.
In the following article on this collection, we’ll transfer on from common covenant proposals to assessment application-specific opcodes reminiscent of OP_VAULT, OP_UNVAULT, and OP_EVICT. Each of the opcodes are designed to resolve a particular drawback somewhat than present broad programmability.
Magazine: Bitcoin holders have acquired eCash — What are you able to do with it?
Content Source: cointelegraph.com
