https://anoma.net/blog/zexe-vs-verizexe-vs-taiga

This article discusses the architectural differences between the privacy-preserving execution environments Taiga, Zexe, and VeriZexe in the context of smart contract systems. (VeriZexe is not conceptually different to Zexe).

Taiga focuses on intent-centric execution for privacy-preserving applications using zero-knowledge proofs. It allows users to express their interests with uncertainty about final state transitions. It introduces the concept of intents, which are conditional programs, and solvers that can incrementally solve them in a non-interactive manner.

Key points covered include:

Privacy Achievements: Both Zexe and Taiga achieve data and function privacy using commitments and zero-knowledge proofs. Taiga introduces a new execution environment with notes, each having an "Application Validity Predicate." Unlike Zexe, Taiga's notes don't contain an address public key (apk), and spending is determined by the application using predicates instead of proving ownership of a secret key.

Authorisation Method: Taiga extends the authorisation method to a predicate, providing flexibility for applications like automatic transactions without user intervention.

Architecture: Taiga and Zexe follow the UTXO model, but Taiga is designed for non-interactive matching, allowing for composable privacy and transparent execution. Taiga introduces the concepts of intents, solvers, and partial transactions, enabling non-interactive matching and composable privacy.

Proving Systems: Zexe uses Groth16 with a trusted setup per circuit, VeriZexe uses UltraPlonk/Turboplonk with a universal setup, while Taiga employs Halo2 without a trusted setup. Taiga's choice of Halo2 supports recursive proof composition efficiently.

The structure of Taiga is thought to be more flexible than Zexe. They defined what this design provides as "Information flow control", not directly as "privacy". It is said that the reason for this is that privacy-only systems will not work. The important thing is that which information should be published and which information should remain secret should be left to the user.

Action Circuit:

• The action circuit, checks that Taiga rules are followed by a partial transaction. It verifies specific properties related to the action being performed, such as ensuring the integrity of input and output notes, nullifier integrity, application integrity, and value commitment integrity.
• This circuit is focused on validating the correctness of an individual action within a transaction. It ensures that the action adheres to the rules and constraints defined by the Taiga protocol.
• The action circuit performs checks over one input and one output note. Therefore, for each action within a transaction, a separate action circuit needs to be executed.

Validity Predicate Circuit:

• The validity predicate circuit contains the application logic specific to each application. It takes a set of input and output notes and verifies custom constraints defined by the application.
• Unlike the action circuit, which focuses on generic rules applicable to all actions, the VP circuit encapsulates application-specific validation logic. It checks constraints related to the application's business logic, such as ownership, transaction rules, or any other custom requirements.
• The VP circuit provides to define and enforce application-specific rules within a Taiga transaction.
• Each application may have its own validity predicate circuit tailored to its requirements.