We will be hosting our first AMA featuring the following PSE Projects (https://pse.dev/en/projects). Send in your questions as a reply to this case and the teams will try to answer them on Wednesday Feb 21st.

A list of the projects attending can be found below 👇

Working on building zkTLS infra/products. A ruthless empiricist and meme connoisseur.

http://opacity.network

how do you folks make proving system decisions?

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.

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).

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.

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