Skip to content

Commit

Permalink
small improvements
Browse files Browse the repository at this point in the history
  • Loading branch information
bazzilic committed Nov 9, 2023
1 parent b152714 commit 4779c4c
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,21 +4,21 @@ Taiga is a framework for generalized shielded state transitions. This repository

⚠️ Taiga is WIP and cannot be used in production yet ⚠️

![Taiga at the bottom, as a foundation for Taiga applications, and their state is stored in Notes.](./book/src/images/Intro_UTXO.png)

## Taiga in 500 Words

Taiga is a state transition protocol that allows applications built on top of it to enjoy the advantages of fully shielded multi-party state transitions (hiding the application type, the data associated with it, involved parties, etc.) without giving up the application complexity. Although an independent project, Taiga is intended to be at the heart of Anoma. Conceptually, Taiga can be seen as an operating system for execution of Anoma programs. In practice, Taiga is a set of APIs for creating notes, intents, transactions – for both shielded and transparent execution; creating and verifying transaction validity proofs; computing the state changes produced by transactions; de-/serializing all of the above.

A [Note](./book/src/notes.md) represents an Anoma resource in Taiga. Notes are immutable and have a "denomination" and a non-negative value, among other fields. Every note has several executable programs (often referred to as [Validity Predicates](./book/src/validity-predicates.md) or VPs) associated with it. Input for Taiga programs is the notes plus a number of additional public and private inputs to the VPs. Taiga programs result in a state change, which includes a list of destroyed (or "nullified") notes and a list of newly created notes. Any existing note being input into a program gets destroyed. Destroying a note means revealing its nullifier, a secret value bound to the note. Creating a note means computing its commitment (basically, a hash), and adding it to a merkle tree. The state of Anoma is a hashset of note nullifiers and a commitment tree. Note ownership is determined by knowledge of the nullifier plus, optionally, arbitrary logic in a VP associated with the note.
A [Note](./book/src/notes.md) represents an Anoma resource in Taiga. Notes are immutable and have a "denomination" and a non-negative value, among other fields. Every note has several executable programs (often referred to as [Validity Predicates](./book/src/validity-predicates.md) or VPs) associated with it. Input for programs is the notes plus a number of additional public and private inputs to the VPs. Taiga programs result in a state change, which includes a list of destroyed (or "nullified") notes and a list of newly created notes. Any existing note being input into a program gets destroyed. Destroying a note means revealing its nullifier, a secret value bound to the note. Note ownership is determined by knowledge of the nullifier plus arbitrary logic in a VP associated with the note. Creating a note means computing its commitment (a hash), and adding it to a merkle tree. The global state of Anoma is a hashset of note nullifiers and a commitment tree.

Taiga transactions consist of valid partial transactions (sometimes referred to as "intents"). Every partial transaction consists of exactly two input notes and two output notes. Output notes are crafted by the creator of the partial transaction. If a transaction gets executed, its output notes are "created": added to the merkle tree. A Partial transaction is considered valid if all programs (VPs) associated with the notes comprising it are valid (result in `true`). If we don't need all 4 note slots in a partial transaction, we can use "padding" notes: they are same as real notes, but have the `is_merkle_checked` flag set to `false`. Padding notes can also be used to describe the user intent by attaching an intent VP to it. Intent VP can describe arbitrarily complex logic of a valid state change: unless it is satisfied, the whole partial transaction would not be valid and therefore can't be part of a valid transaction.

Taiga transaction is valid if 1) all contained partial transactions are valid; and 2) the transaction is balanced: for every note denomination, the sum of values of all input notes of that denomination is equal to the sum of all output notes of the same denomination. A single partial transaction can be a valid transaction if it is valid.
Taiga transaction is valid if *1)* all contained partial transactions are valid; and *2)* the transaction is balanced: for every note denomination, the sum of values of all input notes of that denomination is equal to the sum of all output notes of the same denomination. A single partial transaction can be a valid transaction if it is valid.

To achieve shielded properties, Taiga uses zero-knowledge proof system Halo2 to hide the sensitive information about the state transitions (application types, parties involved, etc). Transactions of different applications are indistinguishable from one another and all applications benefit from the shared shielded pool of transactions.

![Taiga at the bottom, as a foundation for Taiga applications, and their state is stored in Notes.](./book/src/images/Intro_UTXO.png)
To achieve shielded properties, Taiga uses zero-knowledge proof system [Halo2](https://zcash.github.io/halo2/) to hide the sensitive information about the state transitions (application types, parties involved, etc). Transactions of different applications are indistinguishable from one another and all applications benefit from the shared shielded pool of transactions.

### Some of the nice Taiga features
## Features

* Support for arbitrary *atomic* multi-party state transitions
* *Data* and *function privacy*: to a third-party observer, all transactions look the same, no matter what applications are involved
Expand Down

0 comments on commit 4779c4c

Please sign in to comment.