💎Runera Scripts and Taproot

In the previous discussion, we mentioned two key scripts used in Runera:

1. Bit Commitments Taproot: This script verifies the Preimage Commitment published by the Proposer.

2. Verification Taproot: This script checks the correctness of the execution trace publicly disclosed by the Proposer.

Time-Locked Leaf in Bitcoin Scripts

Both scripts include an essential time-locked leaf, leveraging the OP_CHECKLOCKTIMEVERIFY opcode, which supports time locks. A time lock determines whether a UTXO can be unlocked based on the current block time.

• Bit Commitments Taproot: The time-locked leaf limits the time for the Proposer to submit proofs, preventing delays in data release. If the Proposer fails to submit proofs on time, the time lock activates, allowing the Verifier to spend the bit commitments Taproot. Observing the Verifier spending this Taproot signals to third-party validators that the Proposer did not submit proofs promptly.

• Verification Taproot: The time-locked leaf ensures that UTXO can be unlocked upon expiration, preventing funds from being permanently locked if the Proposer is not malicious.

Unlike systems requiring interaction between Prover and Verifier, Runera determines the trustworthiness of final execution based solely on the spending conditions and timing of the bit commitments and verification Taproot. Time locks introduce temporal elements into the verification process. If the bit commitments Taproot does not unlock within the specified time, it indicates malicious behavior by the Prover, making the final execution result untrustworthy. Conversely, if the verification Taproot unlocks upon expiration without issues, it signifies that the Verifier found no execution errors, deeming the final result trustworthy.

Bit Commitments Taproot

The bit commitments Taproot script is used to verify the values of each wire in the circuit, represented by inputs and corresponding verification scripts. Here’s an example of how the bit commitments Taproot is structured:

Inputs:

pythonCopy codeinput_0
input_1
...
input_n

Scripts:

pythonCopy codescript_0
script_1
...
script_n
<Prover’s Public Key>
OP_CHECKSIG

Specific Code for Each Input (input_n):

phpCopy codeinput_n:
<preimage of a value of wire_n>

script_n:
OP_SHA256
<preimage hash of value 0 of wire_n>
OP_EQUAL
OP_SWAP
OP_SHA256
<preimage hash of value 1 of wire_n>
OP_EQUAL
OP_BOOLOR
OP_VERIFY

This script performs a hash calculation on the input and compares it with the hash value provided by the Proposer. The OP_EQUALVERIFY opcode ensures the inputs are equal, otherwise, the transaction is invalidated. This prevents the Proposer from altering the pre-committed execution path.

The Verifier generates and submits the bit commitments Taproot to the BTC network based on the Proposer's hash values. The Proposer must provide the original values for all hash values to spend the UTXO.

Additionally, the bit commitments Taproot includes a time-locked leaf, allowing the Verifier to spend the UTXO after a set block interval if the Proposer fails to provide inputs meeting the unlocking conditions, indicating potential malicious behavior.

Verification Taproot

The verification Taproot ensures the correctness of the Proposer's disclosed execution trace. Using the NOT logic gate C as an example, the Proposer's execution is correct if:

• Input = 1, Output = 0

• Input = 0, Output = 1

Incorrect executions are:

• Input = 0, Output = 0

• Input = 1, Output = 1

Scripts translate these conditions into corresponding verification logic:

Inputs:

cssCopy code<preimage of a value of wire_4>
<preimage of a value of wire_5>

Scripts:

bashCopy codeOP_TOALTSTACK
OP_SHA256
<preimage hash of value 0 of wire_4>
OP_EQUALVERIFY
OP_0
OP_NOT
OP_FROMALTSTACK
OP_SHA256
<preimage hash of value 1 of wire_5>
OP_EQUALVERIFY
OP_0
OP_NUMNOTEQUAL
OP_VERIFY
<Verifier’s Public Key>
OP_CHECKSIG

These scripts use OP_SHA256 and OP_EQUALVERIFY to check the consistency of the input and the hash value. OP_NUMNOTEQUAL then verifies whether both the input and output are 0. If the values do not match, the Verifier can spend the verification Taproot, indicating an error.

Third-party protocol participants can monitor block data and determine if the Proposer is malicious based on the spending information of the verification Taproot.

This structured approach ensures Runera maintains secure and verifiable execution processes on the Bitcoin blockchain.