Framework Visualization

The complete process of SatoshiVM operation is illustrated in the diagram below. Here, there is a mention of third-party verifiers. These verifiers do not directly participate in the validation process but determine whether the Prover is acting maliciously based on the execution on-chain. The majority of regular users belong to the third-party verifiers.

The diagram below outlines the overall process of block validation in SatoshiVM:

Step 1: The Prover obtains the L2 block to be verified from the sequencer and generates a ZK proof for it, which is then validated. Due to the potential collusion between the Prover and the sequencer, even if the Prover successfully validates the ZK proof, other participants will not accept this result. Therefore, the Prover needs to further validate this ZK proof within the public network.

Step 2: During the public ZK proof verification process, the Prover needs to send the hash values of all wires in the circuit of the ZK proof verification to the Verifier.

Step 3: The Verifier constructs bit commitments Taproot and verification Taproot based on the hash values sent by the Prover. The former is used to determine whether the Prover's commitment to ZK proof verification is complete, while the latter is used to determine whether the Prover has executed correctly.

Step 4: The Prover reveals the preimage of the hash values and uses it to spend the bit commitments Taproot, which means the Prover publicly discloses the process of verifying the ZK proof.

Step 5: The Verifier judges whether the execution given by the Prover is correct based on the publicly disclosed execution trace. If incorrect, the verification Taproot is spent.

Step 6: Time lock is unlocked, and the unspent bit commitments Taproot or verification Taproot are unlocked and spent.

Step 7: Third-party verifiers determine whether the Prover is acting maliciously based on the spending status of the bit commitments Taproot and verification Taproot. The rules for third-party verifier judgment will be provided in the next section.

In the preceding text, we mentioned the use of time locks. The diagram below illustrates the sequential execution process of the Prover and Verifier based on time:

The entire proof process is divided into two parts. The first part involves the Prover proving that the execution flow they have published is complete and consistent with the Preimage Commitment, primarily relying on bit commitments Taproot. The Prover spends bit commitments Taproot to prove that the execution flow they have published is complete. However, the Prover may intentionally delay the release of raw data, leading to inefficient system execution. To prevent this scenario, we embed time locks within the bit commitments Taproot. If the Prover fails to provide the raw data on time, they are directly considered malicious. Once the time lock expires, the Verifier can spend the bit commitments Taproot.

The second part involves the Verifier verifying that there are no issues with the execution flow published by the Prover. The Verifier can spend verification Taproot to prove that there are issues with the Prover's execution process. However, if the Prover executes correctly, the verification Taproot will not be spent by the Verifier. To prevent verification Taproot from being permanently locked within the BTC network, we also embed time locks within verification Taproot. Once the time lock expires, we assume that the execution flow published by the Prover is correct. At this point, the Prover can spend the verification Taproot.