# **📌 Trinity: Current State & Research Outlook** ### Overview Trinity is a two-party computation (2PC) protocol that combines **Garbled Circuits (GC)** with **Extractable Witness Encryption (EWE)** instantiated via **KZG commitments** and **PLONK-based SNARKs**. The design allows: * Fewer interaction rounds compared to traditional 2PC schemes * **Re-usable inputs** through commitment-based encoding * **Batched OT** via a Laconic OT construction based on KZG A core innovation is enabling the **evaluator to post a public KZG commitment to their inputs**, which the **garbler can directly use** to prepare a compatible garbled circuit. We're currently using authenticated garbling techniques from the `mpz` library. - [Implementation](https://github.com/privacy-scaling-explorations/Trinity) - [Documentation](https://privacy-scaling-explorations.github.io/Trinity/) --- ### Strengths * **Commitment-based input registration**: Enables a persistent, verifiable input setup from the evaluator. * **Evaluator-side ZK input proof**: Evaluator can prove statements about their committed input off- or on-chain. * **Round minimization**: Thanks to the EWE + GC hybrid, fewer rounds are required compared to traditional OT-based schemes. * **Batched OT via KZG**: Efficient and compact communication in input transfer phase. --- ### Limitations The protocol is currently **asymmetric**: * The **garbler’s inputs are opaque**: There is no ZK or auditability of the garbled circuit from the evaluator’s side. * The evaluator can verify the final output, but **cannot verify whether the garbled circuit was correctly constructed** (i.e., no SNARKed garbling). * The authenticated garbling construction does not enforce **input validity** or **well-formedness** for the garbler side. --- ### Use Cases (Current Scope) Despite this asymmetry, Trinity already supports valuable privacy-preserving use cases: * **Private Listings**: e.g., private job or item listings on-chain, where candidates/proposers interact privately via Garbling a circuit from the commitment (raw KZG or Halo2 proof) listed. * **zk-email-like marketplace**: Proving claims about off-chain data (email contents, credentials, attestations) and post commitment on-chain. --- ### Research Directions #### 1. **Symmetrizing Trinity** We want a model where **both parties can post proofs** about their roles, allowing **mutual trust and on-chain verifiability**: ##### a. SNARKifying the Garbling Process * A natural route is to produce a SNARK proving that the garbled circuit was honestly constructed from committed garbler inputs. * Challenges: * GC construction involves bit-level operations (e.g., `XOR`, `AND`, label selection), which are **costly in arithmetic circuits**. * We found related efforts in Interactive ZK (IZK), but no known efficient SNARK-based garbling proofs. ([Lightweight Authentication of Web Data via Garble-Then-Prove](https://eprint.iacr.org/2023/964.pdf)) ##### b. Public Auditability of Garbler Inputs * The [Publicly Auditable Garbled Circuit (PAGC)](https://eprint.iacr.org/2025/772.pdf) paper introduces an approach to enable circuit verification. * However, it relies on a specific **OT scheme** (`VOLEitH`) with authentication mechanisms that might **not be directly compatible with KZG-based Laconic OT**. * A research question is whether **garbler-side IT-MACs or commitments** can be made **verifiable or re-usable** under our current setup. --- #### 2. **ZKP-PSI over Dictionaries** Based on the same EWE commitment model, we can explore a **ZKP-based Private Set Intersection (PSI)**: * A party posts a **ZK commitment to a dictionary** (e.g., user preferences, credentials). * Another party can generate a **ZK proof of intersection** with their own local dictionary. * Enables a public “offer matching” layer — e.g., verifying overlap in profiles or listings **without revealing content**. --- ### Closing Thoughts Trinity already enables efficient, low-interaction 2PC by combining Extractable Witness Encryption with Garbled Circuits. The primary research objective now is to symmetrize the protocol — enabling both parties to prove and verify their respective roles in the computation. If achieved, this could unlock on-chain 2PC over ZKPs, a major step toward trustless, verifiable private computation. It also gives an new set of use cases for data provenance protocols.