Reclaim Protocol unlocks unlimited possibilities by making HTTPS verifiable in zero knowledge. If you want to prove to me that you have more than a million dollars in your bank account, how would you do it? One option is you send me a screenshot. However, I cannot be sure that you didn’t morph the screenshot. The other option is for you to send me your username password and let me login and check your balance myself. This option obviously assumes that you trust me to not drain your bank account. How can you send some information to a stranger on the internet where trust assumptions fail? That’s what Reclaim Procotol solves for.
Reclaim Protocol generates a zk proof for a TLS session data exchange. When you open an HTTPS website, your browser conducts a ceremony with the server called the TLS Handshake. This handshake involves the passing around of public keys and certificates. These certificates are linked to domain names using a Certificate Authority. All of this tech already exists and works. Reclaim Protocol uses this ceremony to generate zk proofs.
Preserving Privacy If you are trying to prove to me your bank balance and you send me a screenshot of your webpage, I know not only your bank balance, but also your name, address, phone number, or any other personally identifiable information available on that webpage. That isn’t desirable. Reclaim Protocol lets you prove that certain text (or more accurately an html element) exists on a webpage that was rendered on your browser.
How does it work There are multiple approaches to this. There’s a solution proposed by Deco using MPC for the session keys. TLSNotary uses Garbled Circuits to genereate TLS session keys. Reclaim protocol introduces an HTTP Proxy to witness the handshake and data transfer. Any webpage you open, goes through a randomly selected HTTP Proxy Witness. HTTP Proxies are a common infrastructure on the internet. The HTTP Proxy Witness checks that (1) The handshake was done with the correct domain name, (2) The correct webpage was opened in the request, (3) An encrypted response was received. Please note, the HTTP Proxy Witness can see only the encrypted response - and it cannot view the contents of the response. This encrypted response is then fed to a zk circuit that runs completely on client side. The AES/ChaCha20 decryption happens inside the zk circuit, and a search is performed on the decrypted html page.
Trust Assumptions The HTTP Proxy Witness is not a man-in-the-middle attack. HTTP Proxies are a common, secure internet infrastructure. However there are a few trust assumptions, albeit weak. To be able to generate these proofs using the HTTP Proxy Witness, you need to install a mobile app. If you download it from Google Playstore or Apple Appstore, you will have to trust that we did not publish a malicious verion of the app. However, if you don’t trust us, you can always download the sourcecode and manually install the app on the phone. Outside of that there are no trust assumptions, because all of the zk circuit proof generation happens on client side. To know more about how the protocol works check out our docs and whitepaper
Unlimited possibilities Reclaim protocol enables unlimited possibilities. Before this, web2 and web3 were seen as isolated islands. There is no reason for it to be. With Reclaim protocol, developers can build apps that harness the best of both worlds. Websites are great at transferring information, smart contracts are great at trustless execution of logic. Now developers have access to userdata upon which trustless computation can be executed. If you’re building something that utilizes user data to execute a program, hit us up here. Or follow this blog or twitter for new usecases that are being built everyday. Onwards!