Taiga Meeting: 2022-10-06

# Taiga Meeting: 2022-10-06 - 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 - I don't fully understand the purpose of intent notes - Joe - Different purposes for partial transactions at different times - After the first partial transaction executes, there is some state change. But that's not the way that we now think about it, because it's not so clean, it's harder to reason about - When you create an intent note, you create an obligation, but it's not something to pass to the next partial transaction - In the three party bartering example, the intent notes form a cycle - Chris - There are different parties with different interests - The final verifier only cares that the final transaction balances - But in order to create ptx we need to send information through the gossip chain - There is an in-fact order, but this order doesn't need to be encoded in the circuit - Joe - Solver forwards the list of intents that still need to be solved. That list is an unordered set - The next solver can remove or add - Chris - This list contains preimages of unbalanced value commitments - There is an order. A solver does a partial solving reduction and forward the remaining intents. - There is an in-fact order in instantiation - We don't need to code it into the Taiga circuit - That order is encoded in runtime - We can't encode it in the circuit because we don't know it yet - Xuyang - Solvers are collecting partial transactions but not balancing them yet? - Chris - A partial transaction is a transaction that includes some note spends and creation that is unbalanced. - Includes potentially a set of preimages of the value images that are currently unbalanced that is sent to the solver... - Joe - We have two different things - The Taiga architecture - The intent application - We want to ensure that the Taiga architecture supports all the features that are required in the intent-bartering application - The intent-bartering application is going to require that transactions are created in a distributed way. They will originate among two or more unrelated parties that don't know the others exist. - The end user should be able to create a Taiga application and submitted to the network/chain in an efficient way - Hence we have the notion of a partial transaction; different parties at different stages need e.g. to do state updates, a prover, etc. - We have settled with a reasonable architecture that says: "here is what a partial transaction does", how to submit it to the chain. - If users have now token/application data, they need value bounds. Is the value base the hash of the token/app data? - Chris - We try to write down a brief definition of a Taiga partial transaction - Forget intent gossip - e.g. there are some notes, have value imbalance and some other data I'm forgetting about - Alberto - Pointed to the diagram by Yulia - Chris - Partial transactions always satisfy all application validity predicates - They might not have balance - Joe - I think what we want is to enable transactions to be built in a distributed way - We want partial transactions to be created independently - They are the whole context in which VPs are executed (?) - Chris - This should simplify, because now we don't have invalid VPs (as before) - If a transaction has an unsatisfied VP, it is invalid - The pre-images of the value bases are going to contain VPs - There are unsatisfied VPs but they are associated with the unbalanced value commitment - Joe - As far as I understand, in order to create an inbalance in the value commitment, you need (?) - Chris - That note has an application VP but the value commitment may include a token VP that has to be forwarded that someone may check later - Yulia - How can we make sure that all the intent vps of the partial transactions are satisfied? - If one of the intents are not satisfied, the transaction is unbalanced - It seemed to me that satisfaction of all VPs is satisfaction of balance - Joe - If we have a partial transaction and the overall transaction is balanced - Chris - My assumption is that the circuit is going to check the value base calculation and going to require a proof that the VP holds in a particular partial transaction