All content herein is sourced from this awesome video by Yulia and follow-up conversations 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 and both data and function privacy
Taiga uses a notion of VPs which are declarative smart contracts. In more well known smart contract architectures, you write down what you want to do and execute. With VPs you describe the final State or the properties it should have and Taiga makes sure it’s satisfied and doesn’t care how it’s 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 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 the resources (formerly 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 the desired one and if something goes bad it stays in the initial state
What is a valid Taiga
Tx ? It has to satisfy 2 properties:
- VPs of all involved apps are satisfied. What makes an application to be involved? If a transaction tries to change the
resourcethat belongs to an application, an app needs to approve it, all changes are authorized by VP of apps.
Txneeds to be balanced. All
resourcescarry some numeric value. A balance transaction is a
Txfor each application type, the total value of the input
resources= the total value of output
- We want to combine partial transactions 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 application
resourceto their intent
- While this
resourceexists, the transaction cannot be balanced. The amount of input
resourcesof these applications does not match the amount of output
resources. We create this
resource, but don’t destroy it.
- Once all the users in this
resource, the transaction is balanced and can be published on the blockchain
- The application makes sure the transaction is not balanced until the resource constraints are satisfied
- Solvers are the actors that make everything possible
- They build transactions, receive intents, and match them together
- Solvers when they receive
PartialTxsets, they combine them together and update the set of
PartialTxsuntil it’s all balanced, and once balanced can publish it
PartialTxcannot be published on blockchain
- Intent application makes sure transactions are partial as long as transaction is not satisfied
- Solvers try to update their transactions until satisfied
- Allows to create atomic state transitions of arbitrary complexity
The above is a three party barter example. Three 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 create their first
PartialTx, they also create a
- These partial transactions go to the first solver
- First solver receives 2 and naturally decides to give Bob’s dolphin to Alice. Because Alice’s intent is satisfied, they can spend Alice’s
resource. The total balance of this partial transaction set is not 0, so it needs to be solved further
PartialTxgoes to next solver, who also receives Charlies
PartialTx. Sees that Charlie wants a star and Alice had a star, so a solver sends star to Charlie. The solver sends the tree to Bob.
- Now because everyone is satisfied here all
resourcesare spent or destroyed, everyone is satisfied and the
Txcan be spent on the blockchain.
|Data||Resources||Verifiable encryption, Resource commitment|
|Transaction||(resources, participants, quantities, etc.)||ZKP, hashes, blinding|
We achieve both data and function privacy. Resource content is the value of the application type. We keep
resources encrypted. We use verifiable encryption to make the
resources decrypt-able. To establish the existence of the
resources, we use resource commitments. We publish resource commitments and people know some
resource just started to exist. For transaction data what
resources are being transferred, created or destroyed, who participates, value of
resources 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 can’t really know what’s 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; e.g. elliptic curve operations & Hashes. Halo 2 does not require a trusted setup, which when you have a lot of circuits it’s helpful.
- The initial
PartialTxis 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.
- Blake2 is used to hash for field-independent commitments
- Poseidon is used for many things
- Sinsemilla commitment scheme for resource commitments (same as Orchard)
- Pedersen commitment (or something very similar) for value commitments.
- Currently, use Zcash’s Pasta Curves
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 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 between private state (FHE) and data encrypted to Ferveo.