Zktls #94
Zktls #94
Conversation
blogs/202408/zktls.md
Outdated
|
|
||
| **ZK proofs** enable one party to prove to another that a statement is true without revealing any other information. Prefixing "zk" to a term is fashionable nowadays; however, **zkTLS** as a term is a misnomer. **True zero-knowledge proofs of TLS sessions are not feasible today**—TLS relies on interactive, stateful communication, which is too complex to fit into zk circuits. | ||
|
|
||
| TLSNotary uses ZK technology, but the main driver is MPC. |
There was a problem hiding this comment.
this sentence is a little confusing for me, i think your MPC usage is well described already.
blogs/202408/zktls.md
Outdated
|
|
||
| ## Onchain Attestations | ||
|
|
||
| When dealing with blockchain and onchain attestations, the Verifier cannot run onchain. This means that the attestation put onchain by the Prover (or the Verifier) is not a standalone proof but an attestation. Consumers of this information need to trust that there wasn't any collusion between the Prover and Verifier. TLSNotary can be used to build oracles, but it does not solve the **oracle problem**. |
There was a problem hiding this comment.
would be nice to know if any plan to address this, or alternative thinking..etc.
maybe its a research topic which we don't have answer yet, but could mention it here instead of saying, no solution yet. not 100% confident of what I'm saying.
blogs/202408/zktls.md
Outdated
|
|
||
| ## Conclusion | ||
|
|
||
| In the end, terminology matters because it shapes our understanding and expectations of the technology we use. The term zkTLS might sound appealing, but it is inaccurate. TLS sessions are not proven using zero-knowledge proofs. Instead, TLSNotary favors the term **MPC-TLS attestations**. |
There was a problem hiding this comment.
its inaccurate "and misleading the potential which TLSNotary really unlock to the ....." can add more here, to address the MPC potential, and why matter here.
There was a problem hiding this comment.
I think the premise of this write up is directionally correct but it is also guilty of confounding terms. Firstly, I actually have no issue with the term zkTLS itself and don't consider it a misnomer. I don't mind TLSNotary being referred to as zkTLS with public confusion aside. The issue lies with the industries failure to preserve nuance such as proving systems having different properties, eg public verifiability (which you do touch on).
I agree with sticking to something like mpTLS to avoid the pedagogical baggage that comes with the zk prefix in our own materials, and to distinguish from proxy approaches, but not to go so far as to argue against its use generally. The crux to hammer home is the difference between designated verifier and PV protocols -- and to explain why it's not possible to have PV without modifying TLS (which you do).
Referring to PV systems as "true zk proofs" is the exact kind of confounding we want to avoid.
I've also tried to convey to folks that referring to the lack of PV as "collusion between the prover and verifier" further confuses discourse. A Notary can attest to anything it wishes, this does not need to be framed as collusion. I think we should reject that term entirely.
|
I'd also add that focusing on MPC vs ZK is tangential to the main point which is designated verifier vs publicly verifiable. The MPC vs ZK distinction really only plays a role when comparing to the proxy setup. Also, technically |
blogs/202408/zktls.md
Outdated
|
|
||
| In the case of MPC-TLS, the Verifier knows the TLS session was authentic, so it can attest to it. However, the result is not something that everyone can independently verify without trust in the Verifier. | ||
|
|
||
| **Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. While TLSNotary generates something that is a proof to the Verifier, to anyone else, it is an attestation. |
There was a problem hiding this comment.
I wanted to unpack this sentence. But also my changes are only accurate from a high level pov. In the actual code, the Prover sends commitments to the Notary and the Notary attests to those commitments + adds some additional info to the attestation.
So, I sacrificed a bit of accuracy for the sake of giving a better mental image. It's a trade-off, feel free to not include this if you think this adds more confusion than clarity.
| **Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. While TLSNotary generates something that is a proof to the Verifier, to anyone else, it is an attestation. | |
| **Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. It is useful to have the following mental model. First, a Prover generates a proof to prove statements about the TLS connection data to a Verifier. Then, based on that proof, the Verifier issues an attestation. |
There was a problem hiding this comment.
Some thoughts:
- We should mention that all protocols we're aware of which don't modify TLS are designated-verifier.
- I think we should highlight that being designated-verifier is not an issue for off-chain applications.
- I would avoid using terms like "TLSNotary output" or "the result".
- We can mention that server's signing data themselves is the ideal scenario.
blogs/202408/zktls.md
Outdated
|
|
||
| In the case of MPC-TLS, the Verifier knows the TLS session was authentic, so it can attest to it. However, the result is not something that everyone can independently verify without trust in the Verifier. | ||
|
|
||
| **Remark:** In the TLSNotary source code, the lines between a proof and an attestation can seem confusing. While TLSNotary generates something that is a proof to the Verifier, to anyone else, it is an attestation. |
There was a problem hiding this comment.
I would exclude this remark and instead we just fix this ambiguity
blogs/202408/zktls.md
Outdated
|
|
||
|  | ||
|
|
||
| In the case of MPC-TLS, the Verifier knows the TLS session was authentic, so it can attest to it. However, the result is not something that everyone can independently verify without trust in the Verifier. |
There was a problem hiding this comment.
This is a bit redundant with above
blogs/202408/zktls.md
Outdated
|
|
||
| ## Conclusion | ||
|
|
||
| The term zkTLS is catchy and may sound appealing, but it’s important not to jump to conclusions. The "zk" prefix in zkTLS suggests public verifiability, which is not applicable to TLS. Therefore, it’s crucial to use the term "proof" cautiously in this context; in most cases, "attestation" is the more accurate term, especially when discussing the use of TLSNotary outputs onchain. |
There was a problem hiding this comment.
The term zkTLS is catchy and may sound appealing, but it’s important not to jump to conclusions.
This has a negative vibe. I was a bit snarky in my tweet about it, but we should maintain a matter-of-fact tone in TLSNotary publications.
The "zk" prefix in zkTLS suggests public verifiability
It doesn't. This reads as a normative statement
which is not applicable to TLS
It could be if TLS was modified
In general I think we should avoid taking shots at zkTLS and instead focus on providing clarifying information.
Co-authored-by: dan <[email protected]>
Co-authored-by: sinu.eth <[email protected]>
No description provided.