Taiga Meeting: 2022-10-04

# Taiga Meeting: 2022-10-04 - **Simon** - Talked with Pratyush Mishra about the construction of [this paper](https://eprint.iacr.org/2020/499). - Working on PCDs in Rust: KZG using ark-poly-commit, and IPA using Halo 2. The implementation is [here](https://github.com/heliaxdev/cryptography-pm/tree/master/projects/zk-proofs/rust). - 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** - We don't need true accumulation - Trying to get help from the ZCash team - There are some issues on the Halo2 repo that don't seem to be completed - I figured out all the native vs non-native arithmetic questions - There is one question left - Halo2 paper says - Rescue as the hash function to send the cases of the arithmetic from one side of the curve cycle to the other - That makes sense to me because you can only use a commitment on one side of the cycle - The trickiest part to me is looking at the Halo2 verifier and still not quite understanding the exact order of operations - The actual easiest way is to go to the halo2 codebase and see what operations - **Simon** - Now it's clear how the verification works - Cloned the halo2 repo - Get the G polynomial - It works. It's clear - **Yulia** - Working on the new diagrams - Having the clarity/quality of the previous diagrams will take more time - **Joe** - Implementation - We haven't decided the serialisation format but we have a clear idea - The value base was hash to curve of token VP and data field and that should be all - 256 bits per message - We can extend it but it's not necessary. As long as the first part is based on the token VP and the token VP can decide whatever wants with the data. If you want more stuff in we can use Poseidon - **Chris** - In the diagrams we should be able to explain what is in the message - E.g. Tokens have the particular property that they are fungible - If we explain things in terms of messages, it would be a much cleaner abstraction - Programs having input and output - The underlying machinery is hidden - **Joe** - What is the Taiga state at the moment, i.e. what is in the notes commitment tree? - When we produce notes is a new state that gets committed - Then we have intermediate states that get consumed within a transaction - The nature of the state is irrelevant - We don't care what it looks like as long as it has been balanced among the VPs inside the transaction - Once you lay out the constraints (e.g. the balance should be 0), then we can start looking at the application layer: current state in, next state out. It looks exactly the same and we can ignore what is under the hood. - Hopefully this model should be well abstracted - **Chris** - There should be control from the application perspective - This is not particularly difficult - I want to go over one simplest example to understand the model correctly - e.g. Alice has X and wants asset Y - Alice could create a note spent to herself - Instead she might create a temporary intent VP - I produce a message 1 if... - **Joe** - We might think of some kind of debt - A solver can satisfy by spending the intent VP in the right way - **Chris** - Alice is creating a temporary program - "I send A to this temporary program" - She can just create two notes - We can encode AND for free, but not OR without doing weird things - **Chris** - I'm less actually worried about implementing the cryptography - We should figure out it, though - We should focus on the world of conceptual flux - We are figuring out the model - We should agree on terminology and write it in the docs - App VP, Token VP - This is enough to start writing programs - We can mock this interface and this solves another problem - Taiga is hard - We can make the transparent execution environment exactly the same - **Joe** - What we are doing with the verifier and the function privacy is not blocking any of this - There is a little bit of detail in terms of the message passing - For the most part we understand this - What the VP interface looks like - How the demo examples are going to take advantage of this - **Chris** - There are no shortage of developers that want to make their applications private - Before we have typhon (might take longer), we make want to have Taiga on testnet so that people can have blockchain execution - The real work is writing apps in Taiga - **Joe** - We have the VP interface standardised - Xuyang should have the homomorphic part ready soon - Not feeling comfortable implementing the verifier - **Chris** - We should write a few applications that encapsule multiple parties, non trivial messages,... - Once we have the VP interface defined we can use higher level tooling like VampIR - We shouldn't spend a huge amount of time optimising halo2 chips - **Joe** - We should focus on architecture, not efficiency at the moment - **Yulia** - Message idea. How to do the proposal with messages? - **Joe** - There are a couple of ways to do it - The general idea is - We are going to use this note creation to encode all our message passes - **Chris** - The fundamental object in Taiga is a note - Previously we had notes having VPs, type and a value - The idea of message passing is to encode... - Rather than treating the space of possible values (quite large), we simply encode arbitrary messages into the value base - Instead of values corresponding to assets, they correspond to messages - Messages have similar semantics to tokens - They can be created and consumed - They need to balance - A message goes from one program to another program - We have different value bases for different messages - So we can check each message has been sent and received exactly once - **Joe** - When the note gets spent we can think of the note state being consumed and a message gets passed (created) to some other place where the message is consumed - When the message is consumed, it may mean creating a new note - This message is encoding which token we are talking about - Notes and value bases can be created and consumed in more arbitrary ways than an Anoma token - Because every value base can be created independently, if a token VP say "I'm going to release this message" into this intermediate pool, the same VP is going to be run later in some other place and consume this message. Only the same VP can consume that value base. - This model is a generalisation of what was happening before where message were created out of spent notes - Here you can have a much more complex condition - **Yulia** - On a lower level, messages were carrying the type of token - How is it now? - **Joe** - VPs can decide what's inside these messages --- - **Joe** - We thought that intents could fit in the Send VP - Reasonable, but not sure that in this new message passing framework send VP have the same role - The idea is that we have the intent token, with some pluses and minuses floating around. It's kind of confusing. There is a lot of symmetry - **Chris** - We want to allow for out of order execution - **Joe** - We can think of intents with a particular token type - Universal token type - User VPs have symmetry, Token VP don't - We implicitly assumed that token VP exist in both ends because the privacy model is different