Frequently asked questions list
What are the key advantages of the zkPass Protocol?

1. Privacy-preserving

Prove your private data without uploading any personal privacy details.

2. Verifiable

Re-designed the standard TLS protocol into a three-party TLS to ensure provenance of private data.

3. Compatible

Seamless compatible with any HTTPS websites, no API or license required.

4. Verifiability

The zkPass protocol guarantees private data's verifiability, authenticity, and validity by utilizing decentralized MPC nodes that verify a user's data integrity before generating a zero-knowledge proof (ZKP). As a result, it becomes impossible for anyone to manipulate or tamper with the data while generating zkSBT.

5. Anti-Cheating

The decentralized network of MPC nodes divides the Session Key to verify the authenticity, integrity, and validity of the data, prevent malicious activities like identity theft and data tampering.

6. Memory-efficiency

VOLE-based IZK that realizes millisecond-level ZKP generation locally in the browser environment.
How is the credibility of data sources ensured?
To ensure the credibility of data sources, the Prover and Node work together as a client to communicate with the server. Once the Client and Server have completed the SayHello process, the Client will request the server return the certificate. The Node inside the Client can also retrieve the certificate and verify its authenticity to ensure the trustworthiness of the data source.
Will zkPass TransGate handle or store private data obtained from trusted data sources?
The zkPass TransGate operates on the client side and does not retain any private data of the Prover. To access the Server, the Prover utilizes their username and password to log in and acquire an access token. This access token enables the Prover to retrieve information from the server via a public interface. The Prover then employs this information to generate Zero-Knowledge Proofs (ZKP) and submits them for on-chain verification.
Throughout the entire process, the encrypted key remains inaccessible to the Verifier, thereby ensuring the security and confidentiality of the user's private data.
How can tampering with private data by the Prover be prevented locally?
The zkPass protocol employs Multi-Party Computation (MPC) to split the mac_key, which is the key used for data integrity, into two separate shares during a three-party handshake. Each party holds its own share of the mac_key, without any knowledge of the other party's share.
In the event that the Prover attempts to alter the private data received from the Server, the data integrity check conducted during verification will detect the tampering. This check is carried out using an Hmac algorithm that incorporates the hash of the mac_key. Consequently, any modifications made by the Prover to the private data would lead to the Hmac check failing during verification, effectively preventing local tampering with the private data.
How can the issue of duplicate accounts with different addresses be addressed?
zkPass addresses the issue of duplicate accounts with different addresses by selecting a unique and private identification field returned by the server. For instance, for Twitter, the "id" field (displayed as the "reset_id" field in the URL) can be used, and it is hashed before being sent to the blockchain.
To handle different addresses with the same verification account, zkPass employs the overlay mode. For instance, if the hash value is detected to be the same, the current address verification will be marked as "pass," while the previously passed address will be marked as "invalid." This mode can also address the scenario where a user has lost their address.
Is the zkPass network considered to be Layer 1? Is consensus necessary?
The zkPass network can be considered a Layer 2 network and does not require consensus. Since the MPC mode utilized is malicious, any attempts to tamper with the verification process will fail. If an adversary is detected, the Task Manager assigns a new node and performs the verification process.
How is the zkPass network distributed?
During the Pre-alpha TestNet, the test Nodes are operated by the zkPass team. As the network expands, there is an incentive for the community to participate and join the network until a dynamic equilibrium is attained.
If the demand for verification rises, the revenue generated by the protocol and the individual nodes, as well as the number of nodes, will increase accordingly. However, as the number of nodes reaches a certain threshold, the income for each node will decrease, leading to a subsequent decrease in the number of nodes.
Ultimately, the network will stabilize and reach a state of equilibrium where the scale of the network is balanced and sustainable.
Feel free to join our Discord to ask more questions.
Feel free to contact us if you have any ideas