ZK9: Taiga - a dark forest for composable private applications - Yulia Khalniyazova (Anoma)

Transcript

foreign [Music] she's talking today about tiger a dark forest for composable private applications take it away [Applause] thanks so yeah I'm going to talk about tiger and first of all I'm going to introduce you the tiger team it's like all people working on making tiger it's Simon Alberto Joshua Young me and facili in the dark Forest of course so now back to Tiger first of all what problems tiger solves so there are some projects that provide counterparty Discovery and oh God

oh I see yeah so no okay yes yes yes so there are projects that provide Contra party discovered an atomic mattress like Open Sea so like users can find other users to um transact and there are projects that provide shielded State transitions like vexi so you can do arbitrary stage transitions but privately and tiger Canada is not good no okay I'll just continue talking and tag is kind of in the intersection of these

projects but also on top of that tiger provides private account abstraction might sound like complicated but prior with account abstraction basically means that users can choose how to authorize their transactions like signature or whatever they want they can specify it so for people who are familiar with anoma what is their relationship between tiger and anoma well Tech is a privacy preserving part of anoma that takes care of shielded State transitions but it also can be used as a standalone component with uh separate storage and tiger overview this is like the the word is slide of the presentation so but

like it's not going to be like that but if you need like one slide overview what tiger is it's this uh so starting from the first point it's an operating system for distributed applications as the talk description says so it means that users of tiger can build applications on top of tiger and tiger make sure they work correctly as they should just like normal operating system has applications uh tiger is shielded meaning that it provides both data and function privacy uh yeah private account abstraction as I mentioned is that users Define their own

rules and as many other privacy preservant projects it's utxo based so every transaction on tiger is uh list of input and output nodes so notes will be like important thing in this talk and tiger also uses notion of validity predicates which are basically declarative smart contracts so in more like well-known smart contracts you just write down what to do and it just executes right and validate's you describe the final State transition or the properties it should have and tiger make sure that they're satisfied

and doesn't really care how it's done so like on the picture you can see like food style comparison of these paradigms um tiger provides Atomic State transitions of arbitrary complexity sounds complicated but I'm going to talk about that more later and it also has intense centricity so it's built around intents which are user preferences users describe what they want and tiger tries to make sure their intents are satisfied with the help of counterparty Discovery layer so matching intense is taken care of so this big slide is done and now the map of the rest of the talk

so there will be three like main sections first one is what are tiger applications next one is how to achieve Atomic State Transitions and the next is how tiger achieves data and function privacy first one tag applications very short one so there is a shielded pool of nodes like utxo model right and all of these notes like floating around there and applications are basically the things that tell users what is allowed to do with these notes and what is not allowed so an application contains two main parts it's application State and application logic application state is

built from all of the nodes the application owns an application logic is expressed as a validator credit card so basically you can say that Valerie period of the application defines the application so application it's a state and logic right now talking about Atomic State transitions of arbitrary complexity in case you don't know what does it mean to be Atomic so many systems when they want to provide transactions of arbitrary complexity they can't really achieve it in one transaction so there are like many many transactions there is a sequence of transactions to achieve a

certain State and this is not like super good because the system can like end up in the intermediate state if something goes bad and like we don't want that so in Taiga we make sure that there is just one transaction that takes the state to the desired one and if something goes bad it stays in the initial state so like the worst case scenario is that nothing changes so here's the recipe for Atomic State transitions it takes three components partial transactions intent application and solvers but you don't know what it is right now so I'm gonna explain partial transactions

well first of all what is a valid Target transaction like a normal one it has to satisfy two properties first is that the linear periods of all involved applications are satisfied what does it make an application to be involved is that if transaction tries to change the nodes that belongs to an application application needs to approve it so we need to make sure that all changes are authorized by Valeria precuts of these applications and the second one is that transaction needs to be balanced which means that well all nodes they carry some numeric value in some applications and can be more natural like you know

cryptocurrency application uh just value like five ether is like just five ether right but in some applications it can be more abstract but all nodes have value and a balanced transaction is a transaction is when yeah it's a transaction when uh for each application type the total value of input nodes equals the total amount value of output nodes well it's a little bit more complicated than that but I'm just emitting the details here it's not that important and yeah so valid transaction validate has a satisfied and it's balanced and such

transaction can be published on the blockchain so a partial transaction is just a normal transaction but it's not balanced and because it's not balanced it cannot be published on the blockchain but for later credit cards must be satisfied right so the quick idea of what we want to achieve is that we want to combine partial transactions together until their total value is balanced and then we can publish it on the blockchain as a single transaction so you can see on the slide that there are two partial transactions uh both have validity repairs satisfied but they're

not balanced in the gray application type but if we combine them together it's all balanced and everything is nice but we don't know how to do that yet so the next one is the intent application internet application is just an application that works in a certain way right so the user who wants uh they intent to be satisfied they send the intent to the intent gossip Network and they add intent application note to their intent and while this intent note exists the

transaction cannot be balanced because the amount of input nodes of this application doesn't match the amount of output nodes we created this node but not destroyed right so in the next step Alice here it's Alice that receives what she wanted and she can destroy her intent node and her part of the transaction is balanced and once all of the users in this transaction destroy their intent notes the transaction is balanced and can be published on the blockchain so basically intent application makes sure that the transaction is not balanced until the intent is satisfied and the last uh the last thing in the

recipe is solvers and solvers are basically the actors who make everything possible they build transactions receive intents and merge them together so to create Atomic transaction of arbitrary complexity solvers uh when they receive partial transactions and partial transaction sets what I call is like not really official name they combine them together and update these sets of partial transactions until it's all balanced and once it's balanced they can publish it so like to summarize three things partial transactions intent application solvers partial transactions cannot be published on the blockchain

intent application make sure that transactions are partial as long as the intent is not satisfied and solvers try to update this transaction until it's satisfied so all together it allows to create Atomic strand State transitions of arbitrary complexity um yeah here is the example of it it might look a little bit scary but it's not I promise um so it's going to be a three-party barter what I mean by three party barter is like uh when there are three users that want to get something and they have something but they can't really satisfy like one one of the others so they need to kind of be combined in the cycle they

don't know about that yet obviously they just publish their intents and want them to be satisfied so in the first step every user Alice Bob and Charlie they create their first partial transactions and they also create intent notes intent notes are marked like gray notes with a colorful bottom so you can see balances per each partial transaction on this slide because these transactions are not in the same set yet so you can see it's not balanced right then these partial transactions go to the first solver the first solver receives only two of them so far and sees that well Alice wants a dolphin and Bob has a dolphin so the solver

naturally decides to give the Bob's dolphin to Alice and because Alice's intent is satisfied they can spent Alice's intent note this transaction like the the total balance of this partial transaction set is not uh zero so it needs to be uh solved further so this goes to the next solver and next solver also receives the Charlie's partial transaction and the solver sees that Charlie wants a star and Alice had a star so the solver sends this star to uh to Charlie and the same way uh Bob had uh what Bob wanted a tree and uh Charlie had a tree so the solver

sends tree to Bob and because everyone is satisfied here all intent nodes are spent yeah I'm just like note I'm saying spend but like destroy this and spent is kind of the same thing we can't really destroy a node but we kind of Mark it as distraught because it can be used anymore so yeah just to avoid confusion sorry so at this point yeah everyone is satisfied and the transaction can be published on the blockchain so the final transaction contains this like three-party browser and the intent notes are also kind of being created and spent not like non-existent right

so that was the example of what I'm talking about Atomic State transitions and the last part is the privacy in Tiger so I tried to create like a sketchy table of what we do and how we do it so we achieve both data and function privacy and I divided data here into nodes and like transaction data so nodes means basically the node content like the value the application type all of these things we keep notes encrypted we use verifiable encryption to make sure that they're decryptable and to establish the existence of the nodes we use node commitments so like we publish

node commitments and people know that some node just started to exist and for transaction data like what exact nodes are being transferred or like create or destroyed right who participates in a transaction the amount of nodes and the values the applications for that we use their knowledge proofs to to prove that state transition was correct without the revealing the state transition and also hashes and blinding and other stuff like that to kind of keep everything private and for function privacy which uh refers to Valyrian predicates because Valyrian predicates

they represent application function right and we wanted to keep private so we need to hide them somehow so we use zero knowledge proof recursion for that so um basically the proof of a validator predicate is hidden inside another proof so like the outer very far can't really know what's inside the evolution The Proven system we use is Halo 2 the one that is built by zcash and we considered many province systems like Planck base and many uh polynomial commitment schemes but we decided to use

Halo 2 because like it has some nice features it supports recursion and accumulation and for us recursion is like important and has some helpful gadgets available like elliptic curve operations or some hashes that we want to use and the nice feature of it is that it doesn't have trusted setup so like when you have a lot of circuits it's kind of like cool feature for us so the current stage of tiger is that there's still many details to be confirmed so the details might be like not decided on yet but they I would say the design is pretty solid right now so

if you want to check it and check how we use Halo 2 and check how we do everything you can go to the wrapper and check it github.com and the future of tiger is bright uh yeah so uh eventually I think we are planning to unify all of the execution environments uh public environment shielded environment in private into single one um which is like long-term plans right because like fully homomorphic encryption uh complicated and we probably also want to have a

closer integration with Fairview which is another product we're developing um so we could prove correspondence between private State and the data encrypted to Pharaoh using their knowledge proofs so basically forever is for like encrypting transactions so that you couldn't order them like in a sneaky way and just like not be biased right so if we could prove correspondence between private state that is like fully homorphic encryption and data encrypted to ferret could be cool right right so that's basically it uh thanks for listening and if you have questions or

you want to send me an email send me an email or if you want to I don't know talk talk to me so yeah I'm open to discussions thanks foreign right we can take one or two short questions anyone yep oh questions hello um so you mentioned yeah um intent application intent notes you said uh solvers checking whether an intent was satisfied and you said something else again but all this my question is simple what is an intent

in very simple terms intense level it's a validator predicate on less technical level abstract level it's just a way to describe for user its preferences so like you know I want a car this is my intent like you want a Bitcoin it's your intent I write it down in a form of a validator predicate sorry I was not talking into Mike sorry okay thank you okay any other questions yes so you you briefly mentioned that um partial transactions aren't balanced and that you have values attached to inputs

and outputs are those scalars or is that a more complex structure what whatever what is a value in that context Lars okay thank you thank you hi thanks for the talk um our intense uh encrypted and if they are encrypted I'll do the solvers know if its balance is there like some some it's a good question uh but I might like there is a chance I heard it incorrectly so like the question is intense are encrypted or not right yeah so intents are encrypted but because like uh you can't really satisfy intents

of the other person if you don't know what they want you need to reveal this information to solvers so you need but you don't have to reveal it to everyone but you need to give them some information to be able to satisfy your intent so how do you selectively reveal your intent to the solvers well you see if like it's like on a very abstract level if my intent to buy a car and I write it in the validator period I can tell a solver I want to buy a car and uh or just like uh open the Valeria breaker to them it's like up to you how do you do that but they just need to know what exactly to do to satisfy your

intent any other questions so as as far as I understand all this like a lot of a lot of the kind of finality of it lies in the validity predicate but it seems like a lot is kind of open for interpretation as to how you get there and that applies to things like intents but also like the private account abstraction you were talking about um so I guess like a question would be like what type of guide rails are there or limitations on how you can get to a valid validity predicate um I'm not sure I understand the question to be honest yeah they can chat

afterwards as well yeah okay yeah yeah yeah it's a hard I don't know how to ask it yeah anyone else do the Brewers make any like intelligent choices about what intents they're trying to accumulate or do they just accept any of the intents that get out there it's up to the solvers they like we don't specify that solvers can Define like what they want what they don't want it makes sense for solvers to be like uh kind of you know be related to some applications so for example me as a

solver and I accept intents that are related to some I don't know it's a dark application like people who want to solve Sudoku or something you know something like that thank you okay last question thanks for the presentation I mean don't want to get into the loop of encryption of intent and everything we can keep on speaking about it but just I think that's why we're here for but just to understand who would be kind of your competitor or colleagues in the space just to have a better kind of idea of what you guys are doing and how do you mainly differentiate yourself probably have missed it but I think it's a great pleasure to ask it here uh just

to check have Andrew said it correctly who are they competitors of a tiger yeah kind of yeah what you're doing who value proposition yeah how do you differentiate yourself well um hard to say like let me open this slide quickly um ah okay yes so there are projects that uh have private State transitions which we also do but there are also projects that provide counterparty Discovery but as I know there are no projects that combine these features so like in that sense

tiger is like different from them but I would say it's pretty similar to sexy in design and like we also take a lot of inspiration from zcash so it's like you know thank you all right I'd say let's wrap up this session let's thank Julia again foreign