# Alberto Centelles - Zexe vs. VeriZexe vs. Taiga (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/33135793) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Alberto Centelles]] **Full Title**:: Zexe vs. VeriZexe vs. Taiga **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [anoma.net](https://anoma.net/blog/zexe-vs-verizexe-vs-taiga) **Host**:: [[anoma.net]] **Highlighted**:: [[2023-10-13]] **Created**:: [[2023-10-14]] ## Highlights - [Zexe](https://eprint.iacr.org/2018/962.pdf?ref=blog.anoma.net) was the first ledger-based system that enabled private, programmable applications. [VeriZexe](https://eprint.iacr.org/2022/802.pdf?ref=blog.anoma.net) built upon Zexe to introduce a universal setup using Plonk, with remarkable efficiency gains in proving, but without other significant architectural changes. ([View Highlight](https://read.readwise.io/read/01hcm7ggw7bzzp6fzt3a808akp)) ^609779012 - Taiga also chooses a different proving system, this time to remove the trusted setup completely, allowing for efficient recursion via Halo2 accumulation. ([View Highlight](https://read.readwise.io/read/01hcm7gq3kq7y4wnqjfk7tz2qj)) ^609779028 - Taiga also introduces programmable authorisation, in which predicates control spending (instead of public keys). ([View Highlight](https://read.readwise.io/read/01hcm7gtp1wkgmdyn9h1wgb0b7)) ^609779029 ACL - In particular, to hide functions, the Zexe architecture provides a minimalist execution environment called "Record Nano-Kernel" (RKN) that accepts records with two boolean functions, the so called "birth" and "death" predicates. Birth predicates are transition rules that need to be satisfied when a record is created, while death predicates need to be satisfied when a record is consumed. ([View Highlight](https://read.readwise.io/read/01hcm6sgmzhxep6qxbyfv46vn1)) ^609774879 - In particular, to hide functions, the Zexe architecture provides a minimalist execution environment called "Record Nano-Kernel" (RKN) that accepts records with two boolean functions, the so called "birth" and "death" predicates. Birth predicates are transition rules that need to be satisfied when a record is created, while death predicates need to be satisfied when a record is consumed. ([View Highlight](https://read.readwise.io/read/01hcm7h9ez5pydb8fqhc2bwcrj)) ^609779037 - Taiga is designed for *non-interactive matching*, in contrast to Zexe (which is at least not explicitly designed for it). Taiga is only partially agnostic to the communication layer in the sense that it needs enough structure for non-interactive matching, but it's still agnostic to what the patterns of gossip and solving actually look like. Taiga allows the creation of partial transactions which can be independently checked and later combined in a final transaction regardless of the execution order. ([View Highlight](https://read.readwise.io/read/01hcm6wqg4sgc0t5kqwt4jmbm3)) ^609774974 - Taiga allows the creation of partial transactions which can be independently checked and later combined in a final transaction regardless of the execution order. ([View Highlight](https://read.readwise.io/read/01hcm7k2jng4gr26187q8p2x1v)) ^609779544 - For a partial transaction to become a (balanced) transaction, for intents to be satisfied, Taiga introduces the notion of a **solver**. A solver is an entity that receives partial transactions and attempts to construct valid balanced transactions out of them. ([View Highlight](https://read.readwise.io/read/01hcm7hwxvtn1595a8hjcr1b18)) ^609779465