🖥️Notary and Proxy
Last updated
Last updated
The Notary runs the 2PC-TLS protocol with the Buyer and attests the transcript to make the data portable. The buyer submits that attestation as the proof of payment to the verifier contract on-chain. Currently, ZKP2P provides a hosted Notary to its users via the ZKP2P extension.
Since a web browser can't make TCP connection, we need to use a WebSocket proxy server. ZKP2P provides a hosted WebSocket proxy to all its users via the ZKP2P extension. The proxy only forwards encrypted data from the Prover to the server and returns the encrypted response returned from the server back to the Prover. If the proxy fails the user can always run their proxy to forward the request to the server.
Note that, the seller is trusting the Notary to not collude with the Buyer and generate fake proof of payment. The buyer is also trusting the Notary to not censor it. Currently ZKP2P runs both the Notary and websocket proxy. But we are commited to the decentralization roadmap and are coming up with solutions to solve both the collusion and censorship problem in a decentralized way. One solution that we are working on currently is the Optimistic Notarization flow.
Optimistic notarization works because seller is incentivized to initiate arbitration if they find a discrepancy
Arbitration involves getting majority stake to disagree with initial notarization
For on/off-ramping, proving that seller didn’t receive off-chain payment
If found guilty, the malicious notary is slashed
Slashed amount is used to compensate seller and the network
Arbitration is still inefficient
But slashing deters the notary from acting maliciously
Similar to optimistic rollups, don’t expect arbitration to happen in 99% of the cases
Privacy of data is maintained from notaries due to 2PC-TLS protocol
To understand why we are building with TLSN and the Optimistic Notarization flow please watch our ZK11 talk
To understand TLSNotary, please go through their docs
