# Notes on Taiga

***All content herein is sourced from this awesome [video](https://www.youtube.com/watch?v=72VsJj_c99M&pp=ygULVGFpZ2EgYW5vbWE%3D) by Yulia and follow-up conversation with her on the topic.***

* Users of taiga can build applications on top of taiga
* Taiga makes sure they work as they should
* Taiga is shielded provides both data and function privacy

Taiga uses a notion of VPs which are declarative smart contracts. In more well known SCs you write down what you want to do and execute. In VPs you describe the final State or the properties it should have and Taiga makes sure its satisfied and doesn't care how its done. For example when you go to a restaurant you don't necessarily (though you may) care about how food was made. Instead you order off the menu and let the kitchen staff worry about the making the meal. Conversely when you prepare food at home you have to take an interest in how the food is made.

## Taiga Overview


* Taiga provides atomic state transitions of arbitrary complexity
* Intents are user preferences, users describe what they want and Taiga tries to make sure their intents are satisfied with the help of a c/d layer, so matching intents is taken care of
* Application contains 2 main parts, application state and application logic
* Application state is built from all of the notes that the application owns
* Application logic is expressed as a validity predicate
* VP Of the application defines the application
* Atomic state transitions (of arbitrary complexity)
* Many systems when they want to provide transactions of arbitrary complexity can't really achieve it with one transaction
* They require a sequence of transactions to achieve a certain state
* This is not good because the system can end up in an intermediate state if something goes bad
* Taiga makes sure there is one transaction that takes state to desired one and if something goes bad it stays in the initial state

## The recipe for atomic state transitions

What is a valid taiga transaction? It has to satisfy 2 properties:

1) VPs of all involved apps are satisfied. What makes an application to be involved? If transaction tries to change the note that belongs to an application, an app needs to approve it, all changes are authorized by VP of apps.
2) Tx needs to be balanced. All notes carry some numeric value. A balance transaction is a tx for each application type the total value of input notes = the total value of output notes.

* We want to combine partial transacions together until their total value is balanced
* Valid transaction = validity predicates are satisfied and its balanced, such transactions can be published on a blockchain
* The intent application is just an application that works in a certain way
* The user who wants the intent to be satisfied sends the intent to the intent gossip network and they add an intent application note to their intent
* While this intent note exists the transaction cannot be balanced. The amount of input notes of this applciations does not match the amount of output notes. We create this note but don't destroy it.
* Once all of the users in this tx destroy their intent notes the transaction is balanced and can be published on the blockchain
* The intent application makes sure the transaction is not balanced until the intent is satisfied

## Solvers

* Solvers are the actors that make everything possible
* They build transactions, receive intents , and match them together
* Solvers when they receive partial transactions and partial transaction sets, they combine them together and update set of partial transactions until its all balanced, and once balanced can publish it
* Partial tx cannot be published on blockchain
* Intent application makes sure transactions are partial as long as transaction is not satisfied
* Solvers try to update there transactions until satsified
* Allows to create atomic state transitions of arbitrary complexity

## 3 Party Barter Example


3 party barter. 3 users who want to get something and they have something but they can satisfy one of the others but need to be combined in a cycle.

Every user alice bob and charlie they create their first partial transactions, they also create intent notes.

* These partial transactions go to the first solver
* First solver receives 2 and naturally decides to give bobs dolphin to alice. Because alice's intent is satisfied they can spend alice's intent note. The total balance of this partial transaction set is not 0 so it needs to be solved further
* Partial tx goes to next solver who also receives charlies partial tx. Sees that charlie wants a star and alice had a star so solver sends star to charlie. The solver sends tree to bob.
* Now because everyone is satisfied here all intent notes are spent or destroyed everyone is satisfied and the tx can be spent on the blockchain.
* these are atomic state transitions

## Privacy

| Privacy | What | How |
|-----------------------|-------------------------|------------------------------------|
| Data | Notes | Verifiable encryption, note commitment |
| Transaction | (notes, participants, quantities, etc) | ZKP, hashes, blinding
| Function | Validity predicates | Recursion |

We achieve both data and function privacy. Notes into transaction data and note content. Note content is the value the application type. we keep notes encrypted. We use verifiable encryption to make the notes decryptable. To establish the existence of the notes we use note commitments. We publish note commitments and people know some note just started to exist. For transaction data what notes are being transferred, created or destroyed, who participates, value of notes and applications for that we use ZKPs to prove that the state transition was correct without revealing the state transition, and also hashes and blinding to keep everything private.

For function privacy which refers to VPs because VPs represent application function. We use ZKP recursion for that, the proof of a VP is hidden inside another proof so the outer verifier cant really know whats inside the VP

The proving system is Halo 2 built by ZEC we considered Plonk based and many polynomial commitment schemes but Halo 2 supports recursion and accumulation, has some helpful gadgets; eg. EC operations & Hashes. No trusted setup, when you have a lot of circuits its helpful
* The initial partial transaction is generated locally, next partial transactions are generated by the solver
* In principle anything that provides proper at least two-layer recursion can be used instead of Halo2.
* Blake2s hash for field-independent commitments
* Poseidon is used for many things
* Sinsemilla commitment scheme for note commitments (same as Orchard)
* Pedersen commitment (or something very similar) for value commitments.
* Currently, use zcash Pasta curves

## Future

Current stage of taiga is many details still to be confirmed, the design is solid.

The Future of Taiga is bright. Eventually we are planning to unify all of the execution environments into a single one which is long term plans.

FHE is complicated and probably want to have a closer integration with Ferveo, so we can prove correspondence b/w private state and the data encrypted to Ferveo using ZKPs. Ferveo is for encrypting txs, so you couldn't order them in a sneaky way so if we could prove correspondence b/w private state (FHE) and data encrypted to Ferveo.