How does zkPass work? 3P-TLS + Hybrid ZK create a zero-knowledge Oracle Machine.

zkPass is an oracle protocol that enables private internet data to be verified on-chain. zkPass is built on zkTLS, which consists of 3P-TLS and hybrid ZK technology, providing tools and applications for secure, verifiable data sharing, ensuring privacy and integrity from any HTTPS website without the need for OAuth API.

How zkPass Works? Overall Architecture and Core Concepts

How does zkPass work? Understanding its architecture requires recognizing three core roles: P (Prover/Individual), V (Verifier/Business/zkPass Node), S (TLS Server/Data Source). In the traditional data verification process, the prover submits information to the verifier, who retrieves this data and collaborates with the DataSource to perform verification checks. This model has three major issues: the prover faces the risk of leaking too much personal information; the data source, while trustworthy, cannot provide personalized verification services; and the verifier holds all customers' private data, posing a significant potential risk of data leakage.

zkPass has proposed a revolutionary solution that positions the prover between the validator and the data source. Unlike traditional methods, the prover uses their access token to directly locate and retrieve data from the data source, subsequently generating zero-knowledge proofs (ZKP) for the validator to verify. This process ensures that the validator still does not know the prover's personal information. This architecture integrates 3P-TLS, MPC (multi-party computation), and hybrid ZK (zero-knowledge) technologies.

Core Technology Components:

3P-TLS: Three-party transport layer security based on the elliptic curve DH protocol, combined with MPC and Oblivious Transfer (OT) to prevent cheating.

Hybrid ZK: A dual-layer proof system combining interactive ZK (VOLE-ZK 23) and non-interactive ZK (SNARK/Circom)

zkSBT: Soulbound tokens based on the ERC998 composable NFT standard, storing main claims and query claims.

3P-TLS and MPC: Technical Breakthrough in Three-Party Handshake

The first key to how zkPass works lies in the 3P-TLS protocol. Transport Layer Security (TLS) is the secure communication protocol of HTTPS, supported by almost all data sources. zkPass builds the 3P-TLS protocol based on the Elliptic Curve DH protocol and combines it with MPC and Oblivious Transfer to achieve secure communication among three parties.

Phase One: The three-party handshake where P, V, and S jointly generate a session key, with P and V each receiving shares of these keys. This is implemented using the Paillier encryption algorithm, which provides additive homomorphism. The pre-master key is divided into two parts, with P and V each receiving half, while S retains the full pre-master key. To prevent clients from spoofing fake websites, the client will request the server to return the certificate, ensuring trust in the data source.

Phase Two: Key exchange and MPC computation with P and V to encrypt the encryption key (enc_key) and message authentication code key (mac_key). The key design is that V only possesses a part of the mac_key and does not have the enc_key, ensuring that V cannot access the user's private information. Conversely, P holds a part of the mac_key, can access specific identity information but cannot tamper with it; any tampering can be detected by verifying the authenticity of the message through the mac_key.

Stage Three: Standard TLS and ZKP Preparation The application data follows the standard TLS communication protocol procedures, where P and V exchange keys in preparation for the upcoming phase involving zero-knowledge proofs. The MPC algorithm of zkPass has undergone significant optimizations in communication time, hash functions, and memory operations, achieving over three times the efficiency. By adopting a new AES128 proof method, the number of blocks has been reduced by 300 times, and the execution time of Garbler/Evaluator has increased tenfold. Specifically, zkPass utilizes Silent OT for OT operations, leveraging stack GC to reduce the size of the garbled circuit, greatly shortening the runtime of the entire MPC process.

Hybrid ZK: The Perfect Combination of Interactive and Non-Interactive

The second key to how zkPass works lies in the hybrid zero-knowledge approach. The final step of the zkPass protocol involves the client generating a zero-knowledge proof, which is then verified by a smart contract on the blockchain. This hybrid method combines the advantages of both interactive and non-interactive ZK protocols.

Interactive Zero-Knowledge (IZK): VOLE-ZK 23 zkPass utilizes a VOLE-based interactive ZK protocol for authentication, ensuring that data comes from accurate sources and protecting it from client-side tampering. The VOLE-ZK 23 protocol is a “commit and prove” framework where the prover (P) and verifier (V) jointly generate a large number of VOLE instances, each satisfying the linear formula “m = k + w * delta”. P commits some components of this formula while V contains the remaining components.

This level of linearity is the key reason why the solution is cost-effective, differentiating it from other higher-degree polynomial solutions like SNARKs. P only needs to transmit two field elements to the verifier, and then V uses its VOLE parameters to verify relevance. This stage has five main constraints: ensuring requests are encrypted using cryptographic keys, requests must be generated using the user's access token, users must possess the cryptographic key to decrypt the response, users cannot alter the response, and the response data must comply with specific conditions outlined in the template.

The optimization technology zkPass has undergone multiple enhancements to improve the practicality of the protocol. The introduction of SoftSpoken reduces network overhead by approximately 50% and accelerates VOLE generation. By leveraging the additive homomorphic properties of VOLE, the commitments of XOR and INV gates are reduced to zero. For specific use cases involving the same operations, VOLE parameters can be reused, converting multiplication operations into addition operations, which is referred to as “multi-data signal input,” similar to SIMD in CPU architecture.

Non-interactive Zero-Knowledge (NIZK) subsequently transitions from Interactive Zero-Knowledge (IZK) proofs to NIZK proofs with the aim of hiding the actual template pattern, allowing users to selectively disclose proofs for public verification by any party. The SNARK framework is adopted, specifically Circom. Once the client successfully passes the IZK verification, the node will provide a signature for the result, and the client will insert the result along with its associated signature into the Merkle tree and update the root in the SBT contract. When the client needs to prove the result, it only needs to provide a zero-knowledge proof, demonstrating that the result is a leaf in the Merkle tree and has already been signed by the node.

zkSBT: Composable Soul-Bound Token System

The third key to how zkPass works lies in the zkSBT architecture. zkPass adheres to the ERC998 standard, a composable NFT standard. tSBT represents categories such as legal identity, social networks, and financial information, while dSBT contains the actual credentials claimed by the user. There are two types of declarations: primary declarations and query declarations.

The main claims involve users obtaining their private data from data sources after executing MPC, such as country/region, age, gender, and other information from government websites. Based on this data, a claims tree is constructed, where each node represents the hash value of its child nodes. A random number is added using babyjub signatures to prevent detailed attacks, and the root hash of the main claims tree is stored in dSBT, which must be generated by a smart contract along with a zero-knowledge proof to verify the correctness of the tree.

In terms of query declarations, for example, determining whether a user is over the age of 18, the user only needs to provide proof, which is represented by a leaf that contains the user's age in a tree structure, and the value of this leaf is greater than 18. The user can directly transmit this proof to the verifier, who can execute an on-chain function to verify the proof. This ensures that the user's actual private data remains hidden from all relevant parties, with only the declarative statement of the data query being selectively revealed to specific verifiers.