# 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** {% hint style="info" %} `codeHash` is the one of Clique Official TEE Executor by default. {% endhint %} ``` 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** {% hint style="info" %} The signature is on the k256 curve. {% endhint %} ``` 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** ```toml 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. {% hint style="info" %} The code hash of this attestation is equal to clique kernel. Retrive it from [here](https://example.com). {% endhint %} ### On-Chain Verification Users can create on-chain queries and await the execution results by using the [Smart Contract SDK](/build-with-clique/smart-contract-sdk.md). 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 `CliqueTaskManager`contract, 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. {% hint style="info" %} 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. {% endhint %} #### 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)` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.clique.tech/references/verification.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.