Anchors are the client-side validated structures that summarize all the data needed to validate contract commitments, which were described in the previous section. They are composed of the following ordered fields:
Txid
MPC Proof
Extra Transaction Proof ETP
Where:
Txid
is the 32-byte ID of the transaction containing the Opret / Tapret commitment. Note that TxId
could theoretically be reconstructed from the off-chain data of state transitions pointing to each witness transaction and thus following the chain of single-use seals. However, to simplify the validation task, they are included in the anchor.
The MPC Proof
of the contract c_i
consists of pos_i
,cofactor
andMerkle Proof
which were described previouslyso-called.
If an Opret commitment is used, no additional proof is provided in this field, since, as described in the previous section, the verifier inspects the first OP_RETURN
output finding the correct mpc::Commitement
.
If a Tapret commitment is used, a so called Extra Transaction Proof - ETP must be provided, which consists of:
- Internal Public Key
P
of the Taproot output used. - Partner node(s) of the Taproot
Script Path Spend
which is either:- The top left branch (in the example:
tHABC
) if theTapret
commitment is on the right side of the tree. - The left and right nodes of the upper right branch (in the same example they are:
tHAB
andtHC
) if theTapret
commitment is on the left side of the tree.
- The top left branch (in the example:
- The nonce, if used, to optimize the Partner node part of the proof.
In the next section, we will introduce concepts purely concerning the off-chain part of RGB, i.e. contracts, giving an abstract view of the partially replicated finite state machine that gives RGB a much greater expressiveness than can be achieved through Bitcoin Script without sacrificing confidentiality.