Web Proofs for Web3 Applications

Web Proofs are signed attestations of TLS transcripts that enable secure integration of Web2 data into blockchain applications. To learn more about them in a high-level context, check out our Verifiable Data report: Web Proofs.

Web Proofs can be implemented using two main architectures: MPC-TLS and Proxy. In both cases, the architecture guarantees the correctness of the TLS transcript to a trusted party - either a Notary or a Proxy Attester. In the MPC-TLS architecture, the Notary gains this guarantee by participating in the TLS connection via Multi-Party Computation. In the Proxy architecture, the Proxy Attester observes the encrypted traffic as an intermediary, ensuring the transcript's integrity. 

The core challenge lies in maintaining this guarantee of transcript correctness when transferring it to the blockchain. Both architectures introduce trust considerations, as external, app-specific, Verifiers must trust either the Notary or the Proxy Attester to faithfully represent the guaranteed transcript on-chain. This problem is even more pronounced in Web3 applications with on-chain Verifiers, where the verification process must be trust minimized to maintain the decentralized nature of the blockchain ecosystem.

This post explores three approaches to addressing these trust issues in blockchain use cases, as proposed by the zkP2P, Opacity, and Reclaim teams with special emphasis on the security assumptions of each approach.

zkP2P – 2PC is for P2P, Optimistic TLSNotaries for Markets

This is an analysis of ideas by @0xSachinK from zkP2P - originally presented at zkSummit 11 - on how to leverage TLSNotary for specific Web3 use cases with reasonable security assumptions. 

Security Assumptions

The following required assumptions:

• Incentivized counterparty - For every notarization of private data, there is another user in the system, incentivized to prove malicious notarization, with access to the same data, however in a different format (e.g. a list of sent transactions by the buyer on the zkP2P market and a list of received transactions for the seller).
• Immutability of data - The data won’t differ across the multiple requests (e.g. the list of transactions might differ, but the sent/received transactions, once registered, will not disappear).
• Trusted majority of notaries - There is a trusted majority of notaries with reputation that can be leveraged to settle disputes, with tokens and reputation at stake.

And the additional optional assumption that

• Transaction value clarity - Each notarization has a clear value that can be assigned to it. We assume the value will not change significantly over a relatively short period of time. This value will be used to insure the transaction.

Protocol

zkP2P proposes the following TLSNotary extension.

Protocol for Notaries Joining the Committee:

• Before joining the system, each Notary needs to introduce themselves (e.g. state a person or a company). Notaries can also be voted by the community or the DAO into a position.
• The Notary also needs to stake a significant amount of tokens that will be used to insure trades facilitated by the Notary.

User Flow:

1. A user can pick a Notary (or one can be picked at random), to notarize their transaction.
2. The Notary signs the transaction using TLSN, which can be settled on-chain instantly (we optimistically assume notarization is not malicious).
3. The Notary’s tokens (equivalent in amount to  the value of transaction) are locked for the duration of the dispute period. 
4. During the dispute period (e.g. 1 week) the counterparty can provide proof (notarized by the majority of Notaries) of malicious notarization.
5. If proven malicious, the Notary is slashed for the value of malicious notarization and the amount is transferred to the user.

In such a system, given the security assumptions mentioned above, a user can finalize their transaction instantly (or successfully dispute it) within a reasonable period of time. While this framework was originally proposed by zkP2P for onramp payments the use cases for such extension can be generalized to any marketplace for transferring digital assets. 

Opacity Network – Minimizing Collusion Risk in MPC-TLS

This is an analysis of the ideas presented by Opacity Network, which proposes an extension to the TLSNotary protocol aimed at solving the collusion problem in decentralized zkTLS implementations. The ideas are described in more detail in the blog post “Opacity Network: Trust but Verify” by EV3 Research and Hersh Patel’s talk at an Archetype workshop.

Security Assumptions

Building upon TLSNotary, Opacity adds the following key assumptions:

• Valuable Web2 account – Must be unique to the person, and a publicly known account (e.g. Twitter, Instagram, Bank Account) as it is needed for on-chain mapping of the wallet address to a Web2 account ID to mitigate Sybil attacks. In order for this Web2-Web3 mapping to work a Web2 account data has to be committed on-chain.
• Verifiable timestamping – Witness Protocol for tamper-proof action logging.
• Honest / trusted majority – Majority of MPC nodes (Notaries) behave honestly. It’s needed to assure the integrity of the random MPC node selection process.
• Immutability of data – The data being notarized won't significantly change over short periods. This is important for ensuring validity of the commit-and-reveal scheme. Changing values can be handled by loosening precision of commitment.
• Obligatory TEE – Mandatory use of Intel SGX for Notaries as a slashing condition.

Protocol

Opacity extends TLSNotary with:

1. Commit-and-Reveal Scheme, where Users commit to their claim before MPC node selection.
2. Dual AVS System:
   • Notaries (primary) for general Web Proofs.
   • zkTLS Oracles (secondary) for public data feeds.
3. Verifiable Attempt Logging:
   • Creates a trail of proof generation attempts.
   • Helps identify suspicious patterns.
4. Web2 Identity Binding:
   • Links wallet addresses to Web2 accounts.
   • Mitigates Sybil attacks.
5. Notary Network with Slashing Conditions:
   • SGX signature requirements.
   • Penalties for key share leakage or malicious behavior.
   • Slashing for consistent failures or offline status.

User Prerequisite: Prove Ownership of Web2 Account

Before a client can use the Opacity protocol, they must first prove ownership of their Web2 account. This step is crucial for mapping wallet addresses to Web2 accounts, which helps prevent Sybil attacks and enhances accountability. Here's how it works:

1. Web Proof Generation:
   • The client generates a simple Web Proof using the TLSNotary protocol.
   • This proof demonstrates the client's control over a specific, unique to the  person, web2 account.
2. Proof by Community:
   • To protect against potential collusion between a single client and notary, Opacity implements a "proof by community" approach.
   • This method requires multiple independent verifications of the same claim.
3. Multiple Proof Verification:
   • The verifier may require N proofs, each signed by a different Notary (MPC Node).
   • For example, a verifier might require 5 separate proofs from 5 different notaries to accept the claim.
   • The number of required proofs (N) is determined by the verifier based on their security requirements.
   • A higher N increases security but may also increase the time and cost of verification.
4. Limitations and Security:
   • This setup is particularly effective for proving ownership of unchanging identifiers, such as social media user IDs or UUIDs.
   • It may not protect against collusion for all types of Web Proofs, especially those involving dynamic data.

Requirements for Notaries Joining Network:  

• Operators identify themselves and bind to an Intel SGX.
• Significant token stake is required, proportional to transaction values processed.

User Flow:

1. Using a commitment scheme, User commits to the claim which is to be proven. The claim is locked inside a cryptographic “black box”. For this step, we need to assume data immutability, as the Web Proof will be verified against claimed data.
2. MPC node, a Notary, is randomly selected from the network
3. Using Notary selected in step (2) User runs TLSN protocol to generate Web Proof
4. Prove the generated Web Proof matches the committed claim
5. Save the result in the verifiable log of attempts 
6. Prove the correct wallet address is presenting the Web Proof using a Web2 identity link contract (see User prerequisite above)

Slashable Offenses and Non-attributable Faults:

• Failure to provide valid SGX signatures for jobs.
• Proven key share leakage before session finalization.
• Malicious TLSNotary protocol execution.
• Consistent job failures or offline status.

Regarding non-attributable faults, Opacity acknowledges that perfect attribution isn't always possible in cases like connection losses. The protocol addresses this through Web2 identity contracts and verifiable logs to track failure patterns. Governance can analyze these patterns, considering the types of Web2 identities involved, to make informed decisions on potential slashing, with a focus on preventing coordinated attacks that could unfairly generate many failures.

Reclaim Protocol – Decentralized Proxy Attestations

This is an analysis of the decentralized extension of the Reclaim protocol, which aims to provide a decentralized system for proving statements about online data with selective disclosure (without revealing unnecessary information).

Unlike the other two cases in question, the decentralized extension of the Reclaim protocol is not based on TLSN. As a core cryptographic protocol it uses Reclaim Proxy mode protocol which is an orthogonal approach to MPC-TLS. Such an approach was introduced in the original DECO paper and successfully implemented (and open-sourced) by Reclaim. While we won’t analyze the core protocol in detail, we need to consider its security assumptions while analyzing the decentralized extension of the Reclaim protocol. 

The analysis is based on the protocol description in the Reclaim whitepaper.

Security Assumptions

1. Network assumption – The core Reclaim protocol running in proxy mode for security purposes needs an assumption of direct Server connection.The proxy mode protocol has to assume that the proxy Attestor establishes a direct connection to the legitimate Server, and not to any fraudulent intermediary.
2. Honest majority of attestors - The protocol assumes that a majority of attestors will behave honestly, incentivized by economic stakes and reputation.
3. Short time data immutability - The data being attested to remains consistent across multiple attestations within a short time frame.The time frame will be shorter than for protocols using MPC-TLS as a core protocol, since Proxy mode is more performant.
4. Economic rationality - Attestors will act in their economic best interest, making honest behavior more profitable than dishonest behavior. This is assumed by the Mixed Quantile Auction mechanism of Attestor selection.

Protocol

1. Attestor selection:
   • Attestors stake tokens to participate in the network.
   • A Mixed Quantile Auction (MQA) is used to select attestors for each claim, balancing between low prices and randomness.
2. Claim verification:
   • A user submits a claim request to the blockchain.
   • Multiple attestors independently verify the claim using a core protocol running in proxy mode. As per specifications of core protocol, Attestors observe encrypted TLS traffic between the user and the website.
3. Selective Disclosure using zk proofs:
   • Users generate zero-knowledge proofs to selectively reveal parts of their data.
   • These proofs allow verification of claims without exposing unnecessary information.
4. Blockchain integration:
   • Claims, attestations, and proofs are recorded on a custom blockchain.
5. Dispute resolution:
   • In the case of discrepancies, an escalation process involves high-trust nodes.
   • Economic penalties are applied for dishonest behavior.

Summary

Each of the three protocols - zkP2P, Opacity, and Reclaim - offers a unique approach to implementing Web Proofs in Web3 applications, but each comes with its own set of challenges and  security assumptions. All three rely on the tricky assumption of an honest majority, which is vulnerable to Sybil attacks. zkP2P's focus on P2P transactions and markets limits its use cases, while Opacity's requirement of a public-facing account reduces Sybil attack risks but necessitates on-chain commitment of Web2 identity, also constraining its applications. Reclaim, while more use-case agnostic, is based on a different architecture that introduces network assumptions related to secure proxy setup. The table below effectively illustrates these varied assumptions.

While these protocols represent significant strides in bridging Web2 and Web3, the landscape is far from settled. It would be premature to crown a winner or make definitive judgments about which approach will ultimately prevail. The market needs time to mature, and we've yet to see which use cases will truly take off. The race is on, and the finish line is still far on the horizon.

Legend:

● – Required security assumption
○ – Not required security assumption

* Due to the verifiable trace mechanism
** While Reclaim assumes Economic Rationality (ER) directly, using statistical measures demonstrating MQA is strategy proof, both Opacity and zkP2P assume ER indirectly, requiring Notaries to stake tokens proportionally to transaction value which induces ER. 
*** The Opacity Network assumes that Notaries have to use SGX as a slashing condition. zkP2P and Reclaim do not require Trusted Execution Enclaves directly however in these protocols use of TEEs is an optional way to harden security.

Acknowledgments

Special thanks to Sachin from zkP2P and Hersh from Opacity Network for their insightful reviews and valuable comments that contributed to the accuracy of this article.