SatoshiVM Scripts and Taproot
In the preceding text, we mentioned the following two scripts:
The script for verifying the Preimage Commitment published by the Proposer, referred to hereafter as the bit commitments Taproot.
The script for verifying whether the execution trace publicly disclosed by the Proposer is correct, referred to hereafter as the verification Taproot.
Additionally, both of the aforementioned transactions include an important time-locked leaf. Within Bitcoin scripts, there exists the OP_CHECKLOCKTIMEVERIFY opcode, which provides support for time locks. The specific function of a time lock is to determine whether a UTXO needs to be unlocked based on the current block time.
For the bit commitments Taproot, the time-locked leaf will restrict the time for the Proposer to submit proofs, thereby preventing the Proposer from delaying the release of data. If the Proposer delays the submission of proofs, the time lock will automatically activate, allowing the Verifier to spend the bit commitments Taproot. For third-party validators, observing the Verifier spending the bit commitments Taproot implies that the Proposer did not submit proofs on time.
As for the verification Taproot, the time-locked leaf is used to unlock the UTXO upon expiration, ensuring that funds are not permanently locked in the absence of malfeasance by the Proposer.
Unlike proof systems such as bitVM that require interaction between Prover and Verifier, SatoshiVM can determine the trustworthiness of final execution solely based on the spending conditions and spending time of bit commitments Taproot and verification Taproot. The use of time locks is an important tool for introducing time factors into the verify process. When the bit commitments Taproot fail to unlock within the specified time, it implies malicious behavior by the Prover in earlier commitment stages, rendering the final execution result untrustworthy. Conversely, when the verification Taproot unlocks upon expiration, it signifies that the Verifier did not find any execution errors by the Prover, and the final execution result is deemed trustworthy.
Bit commitments Taproot
Firstly, let's introduce the bit commitments Taproot. The input to this script consists of the values of each wire in the circuit, denoted by variables such as input_0 in the following script, with each input corresponding to a verification script, such as script_0.
OP_CHECKSIG within the above script is used to verify that the signature entered is the signature of the current transaction. Returns 1 if the signature is correct, otherwise returns 0.
The specific code for each input input_n corresponding to script_n in the above scripts is as follows:
The function of the above script is to perform a hash calculation on the input and then test for equality with the hash value previously provided by the Proposer within the script. This equality test relies primarily on the OP_EQUALVERIFY opcode, which returns 1 if the inputs are equal and invalidates the transaction otherwise. The reason for conducting this equality test is to prevent the Proposer from providing an execution flow that contradicts the pre-committed one.
The above bit commitments Taproot are generated and submitted to the BTC network by the Verifier based on the hash values provided by the Proposer. The Proposer needs to provide the original values for all hash values to spend the UTXO.
It is worth noting that, in addition to the leaf for hash equality checks mentioned above, the bit commitments Taproot also include a time-locked leaf, allowing the Verifier to spend the UTXO corresponding to the bit commitments Taproot after a set block interval. If, within the set block interval, the Prover does not provide inputs that meet the unlocking conditions, we consider that the Prover has acted maliciously when previously disclosing the hash values, and the results of its execution are not trustworthy.
Verification Taproot
Verification Taproot is used to verify the execution process of a Proposer after they disclose the specific execution trace. It is utilized to confirm whether the Proposer's execution is correct. Taking the NOT logic gate C as an example provided in the previous text, the Proposer's execution is considered correct only if the disclosed execution process meets the following conditions:
Input = 1, output = 0
Input = 0, output = 1
Additionally, if the Proposer provides the following conditions, it indicates incorrect execution:
Input = 0, Output = 0
Input = 1, Output = 1
We translate the two cases of incorrect execution, where Input = 0 and Output = 0, into corresponding scripts:
The above scripts first utilize OP_SHA256 and OP_EQUALVERIFY to check whether the input original and the hash value publicly implemented by the Prover are the same, then use OP_NUMNOTEQUAL to examine whether both input and output are 0.
Of course, there also exists a script to check if both input and output are 1. When the value of wire_4 provided by the Prover is 0 while the value of wire_5 is 0, the Verifier can spend the verification Taproot based on the above script. For all logic gates and their inputs and outputs, the above script can be constructed. Since anyone can run a BTC node to trustlessly obtain BTC block data, besides the Verifier and Prover, third-party protocol participants can monitor block data to obtain spending information of the verification Taproot and determine whether the Prover is malicious based on the spending information.
Last updated
