TLS2n (TLS Notary with Noir)

[deryakarl]

Summary:

An MVP of TLS2N would start by delivering a forked implementation of TLSNotary with an integration that allows for selective disclosure of attested TLS data that is evaluated within a noir circuit.

Using the very handy properties of recursive ZK proofs - this TLS2N proof could then be used in an Aztec smart contract that would greatly improve Aztec smart contract capabilities. Meaning that any web 2 data, public or private, would be readily available to be evaluated on the Aztec Network.

The deliverable would ideally look and function exactly the same as the TLS Notary extension, but a separate web application or SDK would be created to help developers craft and integrate their TLS2n proofs to existing circuits and contracts.

Methodology:

1. Reuse as much of the TLS Notary codebase as is possible at first - write noir circuit boilerplate which allows for ease of crafting selective disclosure circuits based on TLS Notary Attestations
2. Get multiple base cases functioning
3. Identify commonly re-used components and try and build a front end that lets users pick and choose what fields they want to hide/reveal as part of their TLS2n integration in their Aztec Smart Contract
4. In this front end, try sell a better developer experience by offering developers commissioned dedicated TEEs to generate more expensive proof generations to utilise instead of potentially infeasible client-side proofs.

Assumptions:

• TEEs/MPCs doing all the heavy lifting
• TLS Notary Code Base being somewhat easily readable and forkable
• Possible explorations SGX /SUAVE/Gramine and TEE Coprocessor codebase from Flashbot ecosystem

Timelines and Deliverables:

For the items described in the above methodology, for MVPs we’d estimate the following timelines:

Deliverable	Timeline
TLS Notary with Noir circuit evaluations	2 - 3 weeks
Front End/SDK for easier TLS2n proof integrations for Aztec Contracts	3 - 4 weeks
Offering offloading of proofs to rented TEEs	Unknown at time of writing.

Team:

• Derya Karli: Derya is a Computer Scientist with 8 years experience of in R&D in Security and Privacy. She will lead the execution of the grant proposal. She will also develop proof of concept applications alongside the team with her applied cryptography researcher background in ZKP, Randomness, and Computational Verification. Founder of Own Protocol, Prev AI/ML, Privacy, Compliance at Apple. Check her LinkedIn profile here.

• Ben Hooper: X - Senior Blockchain Engineer at Labrys for 3 years. Previously part of the Noir Grants program (start of 2023), have a lot of Noir repo’s on my Github. Recently wrote a TLS Notary TLDR and specifically wrote a Noir Circuit as part of this that could evaluate TLS Notary data - but this article simplifies (and probably gets a few things incorrect) about the detailed inner workings of expectations vs reality in regards to implementation.

• Oleh Misarosh: Oleh is one of the Alpha builder/Full stack developers in the EVM/Aztec ecosystem. Previously, working on wallets and applied SaaS cryptography solutions for enterprises (MPC, AA, ZKP). Oleh built tons of cool stuff mastering Noir, shieldswap.org and won the Alpha build round one with Shieldswap Wallet. Check Noir repos here

Start Date:

November 1st

We are happy to collaborate with teams which are exploring MPC/TEE as a shared goal in this space. Feel free to DM us from Own Protocol, TG or X.

[Savio-Sou]

Hi @deryakarl, thanks for submitting the proposal!

Could you elaborate on how TLS2n enables private shared states between multiple users, and by extension what applications does that entail?

Separately minor note on:

Start Date: November 1st

We will strive to announce selected proposals as soon as possible, by November 8th, 2024 latest.

[deryakarl]

Hey Savio,

Yes sure. The main motivation for building this lib lies in ownership of data, compliance and confidential computing.

Sharing private data on blockchain and staying compliant is a huge bottleneck.

One of the important aspects of this is streamlining KYC/AML policies onchain, which we have not achieved yet. We see a private shared state as an opportunity to share private data within dApps and institutions via using remote attestations(TLS2n). See Taceo

Let’s say that a bank wants to share blacklisted accounts/users with other correspondents privately and streamline the AML within the bank ecosystem. This is normally centralised and siloed. See SWIFT/KYC . With a private shared state and remote attestation, they can share this information using a secure encrypted network and solve the fragmentation issue.

In another use case, with the same shared private attestation service, institutions report their compliance status to regulators in real-time monitoring see Bank of England . This also applies to Dapps they can share their compliance within their blockchain ecosystem.

Last but not least, we also wanted to build this library to improve the security of TEEs with Noir. Normally, they use Gramine Intel SGX attestation service Rave for proof of the cloud. They attest data on the cloud via TLS, but again, this is centralised. We can use blind notaries with TLSN for cloud attestation to minimise trust and unlock confidential computing features of TEEs for future private cloud computing. See Vana . Vana also uses Gramine.

Flashbots request: Adopting TEEs is crucial for our vision of enabling anyone worldwide to permissionlessly participate as a SUAVE Kettle operator while still ensuring strong privacy. Additionally, TEE integrity means that the computations performed within the TEE are reliable and can be trusted by other offchain apps, enabling composability between TEE-based offchain apps. When combined with cryptographic proofs of data integrity and authenticity for HTTPS sessions, such as those provided by TLSNotary 3, entirely new app design spaces are opened including securely interacting with web2 data from onchain

We can iterate with many other use cases of private share state in different setups such as Darkpools trading, AMMs intent matching, trade secret contracts (LegalTech) and training data AI models privately. We want this library to serve as a public good to the privacy-preserving tech ecosystem by using Noir as one of the well-designed DSL in the market.

Let me know if you have any further questions or clarification, DMs are open!

Cheers,
Derya

[Savio-Sou]

Hi Derya, thanks for the clarification!

Would you be able to add a diagram depicting how an E2E workflow for an example application would look like? That would be very helpful visualizing how MPC/TEE will be used in this project 🙌

[Savio-Sou]

Deadline to update proposals is now extended to October 28th, 2024 if it helps buy a bit of extra time to supplement details. Good luck!
https://github.com/orgs/noir-lang/discussions/6289#discussioncomment-11052718

[deryakarl]

Hi Savio,

Here is what E2E flow looks like in action for banks streamlining the shared private blacklist attestations.

To be frank, the grant proposal was building TLSN with noir not specific to the shared private state. However, I see the value of using MPC for private shared registry apps and also attempting to build direct TEE to TEE private attestation using Noir-TLS is very cool and a game-changer for the privacy community.

Mostly I inspired by the RA-TLS model here

Cheers