update docs

README.md

@@ -1,17 +1,38 @@
-# Phala ZK-DCAP-Verifier
+# zk-sgx-attester
 
-## [Optional] Build Docker image
+The utilities to verify SGX attestation quote on-chain by moving DCAP verification to off-chain zkVM. Check [development guide](./local-development.md) to run whole stuff locally.
 
-```sh
-$ docker build -t phala-zk-dcap-verifier .
-```
+### **Why We Need Trustless Attestation Verification**
 
-## Submit DCAP verification ZK proof to blockchain with docker container
+Remote attestation is the foundational trust mechanism for TEEs. If we cannot make it trustless, we cannot genuinely trust the platform on which we are running our applications. Unlike traditional Web2 cloud providers that run attestation services in a black box, a trustless attestation mechanism ensures transparency and verifiability, which are essential for decentralized and secure applications.
 
-RISC0_DEV_MODE=false docker run -it --rm phala-zk-dcap-verifier \
-          --chain-id=<chainId> \
-          --rpc-url=<rpc endpoint> \
-          --contract=<dcap verfier contract address> \
-          --eth-wallet-private-key=<account key to submit proof>
+![zk-attester](./zk-attester.png)
+
+### **The Barriers to Verifying Quotes On-Chain (Ethereum)**
+
+One way to make attestation trustless is to verify the attestation quote on-chain, enabling smart contracts to directly verify the results. However, this approach faces significant challenges, particularly on Ethereum:
+
+- **High Gas Costs**: Verifying attestation quotes on Ethereum is prohibitively expensive due to high gas costs.
+- **Lack of Cryptographic Primitives**: Solidity, Ethereum's smart contract language, lacks support for some essential cryptographic primitives needed for quote verification.
+    - To verify the [**quote**](https://github.com/tolak/zk-dcap-verifier/blob/main/res/dcap_quote) and the accompanying [**collateral**](https://github.com/tolak/zk-dcap-verifier/blob/main/res/dcap_quote_collateral), we need to handle x.509 certificates.
+    - The P256 curve, required for these certificates, is poorly supported in Solidity. Additionally, verifying the certification chain incurs substantial gas costs.
+
+### **How RiscZero zkVM Plays a Role**
+
+![zk-dcap-verifier](./zk-dcap-verifier.png)
+
+Instead of verifying the quote directly on Ethereum, we can leverage RiscZero's zkVM to handle the quote verification off-chain and only submit the proof on-chain. Here’s how it works:
+
+1. **Off-Chain Quote Verification**:
+    - RiscZero's zkVM can execute the quote verification process using full Rust libraries. This includes accessing JSON, WebPKI certificate libraries, and cryptographic libraries easily.
+    - By running the quote verification with DCAP in RiscZero zkVM, we ensure that the process is secure and efficient. The zkVM acts as part of the guest code, handling the complexities of verification.
+2. **Generating Proof with STARK and SNARK**:
+    - Under the hood, RiscZero zkVM uses a STARK prover to validate the verification program. This is then converted into a SNARK proof, specifically a Groth16 zk proof, which is very cheap to verify on-chain.
+    - This approach significantly reduces the computational burden and gas costs associated with on-chain verification.
+3. **On-Chain Verification by Smart Contracts**:
+    - Once the SNARK proof is generated, it can be submitted to a smart contract on Ethereum for verification.
+    - The smart contract can then verify if a TEE is valid by submitting a remote attestation request.
+    - A relay program is needed to catch requests from the smart contract and write back the proof to Ethereum, ensuring seamless communication between off-chain and on-chain components.
+
+By leveraging RiscZero zkVM, we can make the remote attestation process trustless, efficient, and scalable. This approach not only enhances the security and transparency of TEE-based applications but also opens up new possibilities for integrating TEEs with blockchain technologies.
 
-Head to [deployment-guid](./deployment-guid.md) if you test with local testnet

local-development.md

@@ -0,0 +1,87 @@
+# Deploy on a local network
+
+You can deploy the zk verifier contracts and run an end-to-end test or demo as follows (make sure you have installed [rust](https://www.rust-lang.org/tools/install) and [foundry](https://github.com/foundry-rs/foundry)):
+
+1. Start a local testnet with `anvil` by running:
+
+    ```bash
+    anvil
+    ```
+
+    Once anvil is started, keep it running in the terminal, and switch to a new terminal.
+
+2. Set environment variables:
+    ```bash
+    # Anvil sets up a number of default wallets, and this private key is one of them.
+    export ETH_WALLET_PRIVATE_KEY=0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80
+    ```
+
+3. Build project:
+
+    ```bash
+    cargo build
+    ```
+
+4. Deploy verifiers contract by running:
+
+    ```bash
+    forge script --rpc-url http://localhost:8545 --broadcast script/Deploy.s.sol
+    ```
+
+    This command should output something similar to:
+
+    ```bash
+    ...
+    == Logs ==
+    Deployed RiscZeroGroth16Verifier to 0x5FbDB2315678afecb367f032d93F642f64180aa3
+    Deployed DcapVerifier to 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
+    ...
+    ```
+
+    Save the `DcapVerifier` contract address to an env variable:
+
+    ```bash
+    export DCAP_VERIFIER_ADDRESS=0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512#COPY DCAP VERIFIER ADDRESS FROM DEPLOY LOGS
+    ```
+
+    > You can also use the following command to set the contract address if you have [`jq`][jq] installed:
+    >
+    > ```bash
+    > export DCAP_VERIFIER_ADDRESS=$(jq -re '.transactions[] | select(.contractName == "DcapVerifier") | .contractAddress' ./broadcast/Deploy.s.sol/31337/run-latest.json)
+    > ```
+
+### Interact with local deployment
+
+1. Query the state:
+
+    ```bash
+    cast call --rpc-url http://localhost:8545 ${DCAP_VERIFIER_ADDRESS:?} 'get()(bytes memory)'
+    ```
+
+You will see the outputs like below, because no dcap data been submitted:
+
+    ```bash
+    0x0
+    ```
+
+2. Publish a new state (this will verify the hardcoded DCAP input and submit the proof and **serialized** output to DcapVerifier contract)
+
+    ```bash
+    RISC0_DEV_MODE=false cargo run --bin publisher -- \
+        --chain-id=31337 \
+        --rpc-url=http://localhost:8545 \
+        --contract=${DCAP_VERIFIER_ADDRESS:?}
+    ```
+
+3. Query the state again to see the change:
+
+    ```bash
+    cast call --rpc-url http://localhost:8545 ${DCAP_VERIFIER_ADDRESS:?} 'get()(bytes memory)'
+    ```
+
+You will see the output like below, the submitted DCAP outputs returned:
+
+    ```bash
+    wwf@ubuntu-default:~/zk-dcap-verifier(dcap-guest)$ cast call --rpc-url http://localhost:8545 ${DCAP_VERIFIER_ADDRESS:?} 'get()(bytes memory)'
+    0x400000000000000048656c6c6f2c20776f726c6421000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000033d8736db756ed4997e04ba358d27833188f1932ff7b1d156904d3f560452fbb2000000000000000815f42f11cf64430c30bab7816ba596a1da0130c3b028b673133a66cf9a3e0e6000000002100000000000000436f6e66696775726174696f6e416e64535748617264656e696e674e656564656402000000000000000e00000000000000494e54454c2d53412d30303238390e00000000000000494e54454c2d53412d3030363135
+    ```