Notes on the Lasso presentation and further conversations Overall idea using an OR operation as an example: Represent the operands as bit-vectors Split them into eight 4-bit chunks Join each column into an 8-bit lookup table

Introduction Smart contract systems such as Ethereum and Solana are fully programmable but they are not private, that is, both the program and the data of a transaction are stored in plaintext and any observer of the blockchain can see the current state and history of all state changes. Zexe[^Zexe] was the first ledger-based system that enabled private, programmable applications. VeriZexe[^VeriZexe] built upon Zexe to introduce a universal setup using Plonk, with remarkable efficiency gains in proving, but without other significant architectural changes. Until Taiga[^Taiga], Zexe (and VeriZexe) remained the only concrete constructions to achieve function privacy. Like VeriZexe, Taiga also chooses a different proving system, this time to remove the trusted setup completely, allowing for efficient recursion via Halo2 accumulation. Furthermore, Taiga brings an entirely new architecture of intents and solvers, where intents can be solved incrementally or partially in an asynchronous, non-interactive, composable manner. Taiga also introduces programmable authorisation, in which validity predicates[^validity_predicates] control spending (instead of public keys). In short, Taiga extends the authorisation method to a validity predicate, instead of the more restrictive signature check of Zexe. The consequences of these changes are vast, enabling the surge of new applications which are not possible in the Zexe model such as subscriptions or automatic transactions in which the user doesn't have to be online. Since VeriZexe is not conceptually different to Zexe, we'll focus on the differences between Taiga and Zexe. Privacy Both Zexe and Taiga achieve both data and function privacy, that is, they hide user's data and applications are indistinguishable from one another. Data privacy is achieved via commitments and zero-knowledge proofs. The idea behind achieving function privacy consists on fixing a single universal function that takes user-defined functions as inputs.

Halo2 designed a cycle of elliptic curves, Pallas and Vesta (referred as the "Pasta" curves), which form a circle with one another. That is, the base field of the Pallas curve is the scalar field of the Vesta curve and viceversa. When we say that a curve $E$ is over a particular field, this is the base field of the curve. Validity predicates are instantiated over the Pallas curve. We'll notate this curve as $E_{pallas}$ and we'll refer to this curve as the "inner" curve. We'll also notate its base field as $\mathbb{F}p$ and its scalar field as $\mathbb{F}q$. That is, given a point $P = (x, y) \in E{pallas}$, $x, y \in \mathbb{F}p$ and for any scalar multiplication $a \cdot P, a \in \mathbb{F}q$. The "outer" curve in our case is the Vesta curve $E{vesta}$. In broad terms, the prover's circuit is based on the inner curve $E{pasta}$ and the verifier circuit is based on the outer curve $E{vesta}$. The arithmetic of the $E_{pallas}$ curve is over $\mathbb{F}q$, whereas the arithmetic of the $E{vesta}$ curve is over $\mathbb{F}p$. To understand the reason behind this as well as the need to introduce $E{vesta}$ in the first place, we need to review a bit about these proving systems. A validity predicate is a particular type of circuit which returns a boolean value. A a circuit can be arithmetised using its trace: Using interpolation from these trace values, we'll be able to create a polynomial $f(X)$ which encodes the circuit. Without loss of generality, this will be of the form $f(x) := a_n \cdot x^n + ... + a_1 \cdot x + a_0$. A commitment to $f$ consists of the multiplication of the polynomial by a generator point of the Pallas curve. That is, $Com(f) := f \cdot G = [ a_n \cdot G, ..., a_1 \cdot G, a_0 \cdot G]$. Since these are scalar multiplications on a point $G \in E_{pallas}$, this implies that $a_i \in \mathbb{F}_q, \forall i\in {0, ..., n}$. Thus, having a circuit over $E_{pallas}$ allows us to prove statements about $\mathbb{F}_q$-arithmetic circuit satisfiability, that is, we do arithmetic over its scalar field.

Personal Taiga notes: 12-01-2023 Notes in a transaction are either input or output notes. Whatever I want - It's an output note Whatever I have - It's an existing unspent note commitment. Somehow, we need to decrypt the commitment to construct this note and include it as a spend note in the transaction. If both Dealer and Player knew about each other and wanted to interact with each other (i.e. not needing Taiga intent-gossip architecture), a transaction would look like: Note that in this case, a transaction has 2 inputs and 2 outputs. The X set in the value field of the sudoku_vp notes indicates that any value is valid.

This is in the context of Sudoku We assume the puzzle is given and available to all parties. The dealer can construct a spend note. let spend_note = Note( application_vp = xan_token_vk, value=1, user=?, note_data=(),

Simon Talked with Pratyush Mishra about the construction of this paper. Working on PCDs in Rust: KZG using ark-poly-commit, and IPA using Halo 2. The implementation is here. Accumulation principle works for one polynomial: we compute a proof $π1$ and the corresponding $g(X)$ polynomial together with a proof $π2$ for it. Using $π2$, we can check the linear step of the verification of $π1$ (which is also linear). Hence, we can accumulate proofs and check only one linear time step. Next steps Continue with linear combinations of $g(X)$s polynomials. It should work almost the same as with one polynomial. Write the circuit for the accumulation. It corresponds to recomputing $g(X)$, but also involves the transcripts (so also hash function circuits).

Joe & Yulia We're very confused now What are we confused about? We have multiple versions of the design. Multiple ways of doing the same thing Yulia I realised that earlier we talked about how to switch from one partial transaction to another and there was the idea that every time we created intermediate notes from one transaction to another. With this new design, it seems unnecessary

Questions "For "ordinary" tokens, there is an understanding that spent notes "produce" the state (value) that is "consumed" by creating notes." Although I came to understand the idea later with the example given, it is counterintuitive for me. The reason is that, in a simple instance of a UTXO model like ZCash, if Bob wants to receive 3 NAM from Alice, he creates a commitment using Alice's public key. Then Alice consumes that note by publishing its nullifier with her private key. So in my mental model, creating notes comes always before consuming/spending (for me they are indistinguishable) notes. Is my understading correct? In the example given for bartering: Let's try to implement bartering. Alice has 1 of token A and wants 1 of token B; Bob has 1 of token B and wants 1 of token C. Charlie has 1 of token C and wants 1 of token A. Alice constructs a partial tx which looks like:

The game At the beginning of the day, a new sudoku puzzle is published. There is a prize for the first person/team able to solve it. When a team wins, the prize is divided equally among its participants. Each player can share their progress of their sudoku puzzle at any given time with their teammates. Once a team has found a solution to the puzzle, they can submit their answer and create a proof of their solution, without revealing their solution. The participants in the game remain anonymous and their game will be stored in the Taiga blockchain encrypted. Furthermore, the blockchain will not reveal which application (a sudoku game in this case) was run. Motivation The game highlights the intent-centric architecture of Taiga, which enables counter-party discovery and settlement in a private manner.