sinu.eth

@sinu

26 Following

148 Followers

sinu.eth pfp

TLSNotary only really makes sense for cases where there is some privacy requirement, such as hiding an access token in a request. There may be some usecases where an Attestor doesn't have access to some offchain data but some other party does. TLSN could facilitate proving that data to an Attestor so they can sign it.

0 reply

0 recast

1 reaction

sinu.eth pfp

TLSNotary: ## 🥺 We help data move around the internet in a private and verifiable way ## 😎 We help data move around the internet in a private and verifiable way using MPC, and optionally using signatures.

1 reply

1 recast

4 reactions

sinu.eth pfp

I'm firmly on the zkVM implementing existing ISAs like RISC-V bandwagon. I feel DSLs have their place, but in order to bring ZK/verifiable computation to the broader developer ecosystem we need to leverage general purpose languages

1 reply

0 recast

3 reactions

sinu.eth pfp

Mass scale polling with participation filters based on private identity information. I want people to be able to signal preferences privately while being robust to sybil shenanigans.

1 reply

0 recast

5 reactions

sinu.eth pfp

Go interact with GenericArray a couple times and report back how it makes you feel

0 reply

0 recast

5 reactions

sinu.eth pfp

I mentioned elsewhere already: Quicksilver, or more generally the recent VOLE-based proving systems. Highly underrated for reasons I'm not entirely sure. Perhaps because they aren't suitable for onchain apps which rely on succinctness. But offchain these protocols rock! Check out https://eprint.iacr.org/2023/857

0 reply

0 recast

5 reactions

sinu.eth pfp

I think the main roadblock would be the incentives. For public data, there is nothing in the way of doing this right now (Internet Archive!). For data gated behind access control, TLSNotary could be part of that picture. The main limitation there is scaling, but somewhat approachable near-term for at least text content

0 reply

1 recast

4 reactions

sinu.eth pfp

Fundamentally, it relies on some information remaining hidden from the Prover until after they are committed to the messages. This is an inherently interactive process which can't be done in a publicly verifiable manner.

0 reply

0 recast

2 reactions

sinu.eth pfp

TLSNotary works by secret sharing the TLS keys such that the Prover is not able to compute valid MACs for messages without co-operation with the Verifier (Notary).

1 reply

0 recast

3 reactions

sinu.eth pfp

Unfortunately, this will never be possible. Unless a successor protocol to TLS supports non-repudiation, but then we wouldn't need TLSNotary as the data server would be signing the data itself (which is the best case scenario for the future). Data monopolies have a pretty clear disincentive to moving in that direction.

2 replies

0 recast

2 reactions

sinu.eth pfp

None of the above applies to selective disclosure onchain. For that, we intend to stay unopinionated about what proving system is used. Instead we will focus on adding flexibility for the kind of commitments output by our protocol. Users can choose whatever proving system suits them best.

0 reply

0 recast

2 reactions

sinu.eth pfp

Having such proving systems available to us is a godsend, as most of the stuff we are proving are evaluations of AES128 and SHA256 which are prohibitively expensive otherwise. On top of that, the Prover is assumed to be very resource constrained (mobile or browser).

1 reply

0 recast

3 reactions

sinu.eth pfp

Right now we use garbled circuits for our in-protocol ZKPs ala JKO13. We have plans to switch to using Quicksilver this year. Protocols like QS provide impressive proving and verification performance (comparable to evaluating a statement in the clear). They can work over any field, and recently I learned over Z_2^k too

1 reply

0 recast

5 reactions

sinu.eth pfp

TLSNotary is an interactive "designated verifier" protocol, so we are operating under a different set of constraints than what is common in other apps of ZK in this space. Namely, we do not require sub-linear proof sizes or sub-linear verification costs. In other words: SNARKs are overkill for us in many cases.

1 reply

0 recast

5 reactions

sinu.eth pfp

On that note, if anyone knows of any tooling which can help quantify leakage of private inputs to a program let me know. Being able to prove arbitrary code is amazing, but how do I know a execution trace is not leaky?

0 reply

0 recast

1 reaction

sinu.eth pfp

On the tooling side, projects targeting machine architectures such as RISC-V are exciting! Eg. RISC0, Powdr, SP1. Being able to compile and prove programs written in general purpose languages like Rust is a massive unlock for the development of privacy preserving applications and verifiable computation generally.

1 reply

0 recast

1 reaction

sinu.eth pfp

Addressing the sybil problem while preserving peoples' privacy is one of the highest impact things ZK tech can bring. It makes me more optimistic about what the future internet could look like in the presence of mass scale AI bots. Certainly in contrast to knee-jerk state solutions.

1 reply

0 recast

2 reactions

sinu.eth pfp

I find myself not having the bandwidth to be able to follow as many individual projects closely as I would like. But broadly speaking on the application side I find anything moving the needle on identity very exciting. Onchain or offchain.

1 reply

0 recast

4 reactions

sinu.eth pfp

Yes! I was just talking to @andyguzmaneth about exploring ZK + FC. A lot of opportunity there

1 reply

0 recast

1 reaction