# **📌 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.