Taiga: a dark forest for composable private applications

Transcript

foreign my name is Julia I work for anoma and I'm gonna present you tiger so thank you so here's the tiger team Alberto Joe shuyang me vasil and Simon

working on bringing tiger to the world yeah everyone will appreciate that so um back to Tiger what problems tiger solves so there are projects that provide counterparty Discovery in atomic matches like open c for example there are projects that provide shielded State transitions like zaxi and maybe there are maybe there are not projects that provide private account obstruction I'm not aware of that about their existence but tiger aims to provide all these features in single product so that's what we're gonna talk about if you're unconfused about the

relationship between tiger and Noma tag is a part of a normal protocol and it takes care of Shield estate transitions but it can also be used as a standalone component provided a data storage here's tiger overview in one slide it looks a little bit too much but we're gonna look through it by a one by one so tiger is an operating system for distributed applications it means that you build applications on top of tiger and tiger takes care of running them right tigers utx are based so each transaction is a list of input and output nodes I'm going to talk about notes a lot maybe here

uh so forgive me so applications built off on Tiger have stays and the state consists of nodes and every note belongs to some application and is a part of the application state tiger provides full programmability we use Valeria Prairie cuts which are declarative smart contracts and they are also used to define authorization logic which is account abstraction right Tiger's shielded it provides data and function privacy I'm gonna talk about that a bit later and everything else to be honest it provides Atomic State transitions of arbitrary complexity

oscillator it's intense Centric it's built around intense which are just user preferences and counterparty Discovery is also taken care of so if you want to perform some action you don't need to look for the parties yourself so now let's dive a little bit deeper and talk about Atomic State Transitions and intents so what is an atomic State transition so imagine we have like a parties Yoshi Bowser and Mario they all want something

and want something in exchange but we can see that one of the parties cannot satisfy any of the other they could like satisfy each other in a three-party bartering cycle but in most of the systems it's not possible to do it in a single transaction which is actually not like good because um Yoshi when he goes into intermediate State might end up in this intermediate stage which is not desirable Yoshi never wanted this mushroom you know what Joshua wanted a star and now it has to deal with the mushroom so what we want to do is to allow only Atomic transactions so Yoshi either gets what

he wanted or stays in the same state and here is how to achieve this it's like a short version so desired State transition is expressed as intent and solvers are the actors who receive intents and merge them together to produce transactions and I'm gonna talk about this details now let's start with partial transactions partial transactions are building blocks of transactions but to understand what a partial transaction is we need to define a valid Target transaction so as we remember transaction is input and

output nodes and it has a satisfy two conditions in order to be valid it has to be approved and balanced what does it mean to be approved it means that all applications involved in a Target transaction approve the transaction if a node is a part of the transaction it means it will the application must approve this transaction right and balanced means that for each application involved in this transaction the value the total value of input nodes equals to the total value of output nodes so that makes a valid Target transaction

it's approved by applications and balanced and such transaction can be published on the blockchain so a partial transaction is also input and output nodes but it's only approved and not balanced such transaction cannot be published on the blockchain but the idea is that we're gonna build transactions from partial transactions so on this diagram you can see that there are two partial transactions and both of them are approved by applications which are expressed as the leader Prairie cut satisfaction but they are not balanced in the gray application type in the bottom but if we combine

them they become balanced and this is a valid transaction so that's how we're going to build it but what about intents how users Express their preferences so as I mentioned intents are a way to do that and before intense users would have to specify what exactly how exactly achieved what they want and it might not always be achievable in a single transaction but transactions were the only thing we had right and now users have intents they just express what they want and then they don't have to think about how to achieve that solvers do that

so to make sure that intents are satisfied we have intent application which is an application on tiger one of the one of the examples so let's talk a little bit about tag applications tag applications have state and logic State as I mentioned is expressed as application nodes and logic is a validated pre-cut so using an application means creating or consuming application nodes but the rules defined in the application logic so back to the intent application so intent application nodes are called intent notes we call them intent nodes and here is how you use it so when you

create your intent you attach it to the intent node and send it to the solvers and while this intent note exists the transaction cannot be balanced because there is input node but no output node and the intent node can only be balanced or they can only be consumed when the intent that is attached to it is satisfied which is insured by the application logic so the algorithm for the solver would be to satisfy the intent consume the intent node and it makes the transaction balanced in this application type then solver have to

repeat this for all application types and transaction can be published on the blockchain because it's balanced in all application types so a little bit about solvers as I mentioned solvers are actors who receive user intents and match them together to produce transactions so the intent goes to the intent gossip Network and solvers receive it there so to create Atomic transaction of arbitrary complexity solvers create partial transactions the share partial transactions with each other and they add new partial transactions to the

received ones until the settings balanced so to summarize the recipe for Atomic State transitions is that intents are used to express desired preferences intent application make sure that intents are satisfied partial transactions are used as building blocks of transactions and solvers update the future transaction with new partial transactions until the intents are satisfied and transaction can be published and as a result we get Atomic transaction of arbitrary complexity so just to understand it better let's apply this to the recipe to the sorry to the example

from before so in this case Yoshi Bowser and Mario would create partial transactions containing their intents in case of Yoshi for example it would be a star they send these partial transactions to the intent gossip Network solvers receive them yeah solvers receive them and match the intents they see that Yoshi has star intent and Bowser has a star so the star can be sent to Yoshi because these are partial transactions there is no violation of logic and these six partial transactions from

the second and the third column are combined into a single transaction that balances the stars goes to Yoshi the mushroom goes to Bowser and the Egg goes to Mario and the intent notes were satisfied and destroyed and all of these gets published on the blockchain foreign privacy so tiger provides data in function privacy but data privacy I mean privacy of notes and transaction data like users amounts and some other data we use verifiable encryption for uh transmitting nodes to the receivers to

the users node commitments are used to establish notes existence without actually revealing the notes and there are knowledge proofs I used to um prove statements about nodes that they exist that they are consumed and other stuff like that so by function privacy I mean hiding what application you use which essentially means hiding Valeria pre-cuts and for that we use Halo 2 recursion yeah we use hello to proven system for basically everything related to zkp um about the current state of tiger some details remain to be confirmed but

the code and specs already available at github.com Tiger check it out and uh in the future tiger will support public shielded and private domains and will be more closely integrated with ferio which is threshold decryption front running protection against front running so you'll be able to prove correspondence between private State and data encrypted to burial using zero knowledge proofs well that's all I had to tell you check out the tiger repository check out the specs the specs of anoma

also have tiger section and you can contact me using this handle on various platforms and yeah thanks for coming and listening [Applause] any questions hi thank you for the presentation maybe this is a silly question but can you have balanced intents from the get-go or do all of the intents need to be matched for a transaction to happen can you send like a basically a full

transaction as a partial transaction um you don't have to have it as a partial transaction you can create a full transaction just publish it it's not prohibited yeah thanks for the talk um is it the case that intense must always be fully revealed to solvers that's a good question they don't have to be fully revealed to solvers however you need to reveal a part of it to the solvers currently for solvers to be able to see it but we're going to work on changing that and having them in a more

private State maybe using NPC yeah we have one just a quick one how are solvers incentivized and how do we know that what they're doing is in the best interest of whoever is submitting the intent that's also a good question um I feel like it's better if I answer it after the it's like not not a quick answer yeah okay maybe yours is quicker go ahead no solvers don't know that they don't

have to know that I mean if you want to reveal you can reveal but by default they don't know yeah it can be like it can be anything but um on a number for example we use our own consensus protocol um called ketogenous paxis I think it's like bft protocol uh yeah but basically whatever supports uh Tiger's Futures can be used yeah sorry you can maybe chat outside of the

room yeah thank you thank you [Applause] [Music] thank you [Music] foreign