Verification

Minimal Trust Setup

Clique provides full verifiable process with minimal trust setup. For example, if you want to get twitter information for a user, all you need to trust is Twitter Official API. The rest parts of the whole process are fully secure and verifiable.

Verification Mechanism

An execution DAG will be created when our kernel receives a query. The executor should generate corresponding proof along with the result and then the kernel will migrate to next state if proof validation passed.

Here are the pseudocode of validation process for each kind

TEE Attestation

codeHash is the one of Clique Official TEE Executor by default.

BEGIN
 user_report := keccak(task_cuid, task_result)
 code_hash := codeHash in proof-perference
 RETURN verify_dcap_attestation(proof, user_report, code_hash)
END

Signature

The signature is on the k256 curve.

BEGIN
    msg_hash := keccak(task_cuid, task_result)
    recovered_pk := ecrecover(proof, msg_hash)
    IF use public key THEN
        RETURN IS_EQUAL(recovered_pk, publicKey in proof-perference)
    ELSE IF use address THEN
        RETURN IS_EQUAL(pk_to_addr(recovered_pk), address in proof-perference)
    END
END

Example

Let's take an example:

Example Manifest

name = "clique_example"
spec-version = "1"
type = "Schema"

proof-type = ["TEE"]

[input]
x = { type="u64", description="Example params x" }
y = { type="u64", description="Example params y" }

[output]
outputA = { ref = "$tasks.A.data" }
outputB = { ref = "$tasks.B.data" }

[[tasks]]
name = "A"
proof-perference = { type = "TEE", codeHash="d5a8bba00589dbd01abf7b8b92325fa8a3705c95642ec5b2a20bfed2b88a739d" }
[[tasks.input]]
arg0 = { ref = "$tasks.D.data" }
arg1 = { ref = "$tasks.C.data" }

[[tasks]]
name = "B"
proof-perference = "TEE"
[[tasks.input]]
arg = { ref = "$tasks.C.data" }

[[tasks]]
name = "C"
proof-perference = { type = "ecdsa", address = "0x95222290DD7278Aa3Ddd389Cc1E1d165CC4BAfe5"}
[[tasks.input]]
arg = { ref = "$input.y" }

[[tasks]]
name = "D"
proof-perference = { type = "ecdsa", publicKey = "0x040acac15a20278bd5df8b2332287226d1320d9adffc6b6ad6c8ab24bba6a0428429526cec9efd90dffb3cff64baf49db1c5068d7b6cd00510a82a3a33a74e02d2"}
[[tasks.input]]
arg = { ref = "$input.y" }

The task's execution DAG is depicted in the chart below.

Example Query DAG

Tasks [C, D, A, B, query] will be dispatched and executed in order. When receive D's response, its proof will be validated in time. The validation processes are done as the same when A, B and D are completed. Note that query is a phantom task and it doesn't have proof.

The kernel will finally generate its attestation when all sub-task are validated.

The code hash of this attestation is equal to clique kernel. Retrive it from here.

On-Chain Verification

Users can create on-chain queries and await the execution results by using the Smart Contract SDK. In the Smart Contract SDK, on-chain queries are actually created by the CliqueTaskManager contract. After the Clique Network executes the on-chain query, it submits the execution results and proofs to the CliqueTaskManagercontract, which then verifies them. Upon successful verification, the results are returned to the user.

Next, we will detail how CliqueTaskManager verifies the execution results submitted by the Clique Network.

When the Clique Network submits execution results to CliqueTaskManager, it needs to provide the following information:

• query ID: The ID derived from the query parameters can be considered as a hash value of the query, which corresponds one-to-one with the query and is verifiable.

• response: The execution result of the query.

• proof: The proof used to verify this submission result.

• signature: ECDSA signature over the query ID and the response.

When the Clique Network node first submits execution results to CliqueTaskManager, It will carry a TEE attestation in the proof. This TEE attestation is generated for a public key. CliqueTaskManager will verify this TEE attestation. If the verification is successful, it will extract the public key from it. Additionally, CliqueTaskManager will recover the public key from (query ID, response, signature) and compare it with the public key extracted from the attestation. If they match, the verification is successful, and the public key will be saved as a trusted public key.

CliqueTaskManager maintains a set of trusted public keys. After the public key is registered, subsequent submission of execution results can be verified through the trusted public key and the signature. That is to say, the Clique Network node only needs to carry the attestation during the first submission, and subsequent submissions do not require it. This is to reduce gas costs, as verifying the attestation on-chain is very expensive.

The registered key is a ephemeral key. The ephemeral key must be regenerated each time the Clique Network node restarts. This is done to avoid potential security risks associated with storing keys. That is to say, after a restart, it needs to be registered again.

Verification steps

1. Recover the public key from (query ID, response, signature)

2. If this public key is one of the trusted public keys, use the signature to verify the (query ID, response)

3. If not, verify the attestation and compare the extracted public key. If the verification is successful and the public key matches, use the signature to verify the (query ID, response)