A Typhon That Hides in the Taiga | Vasily Sidorov, Anoma | ETHTaipei 2023

of Dr vasili sidorah from a normal projects to talk about typhoon a flexible engine for ordering and concurrent sterilizable Extrusion of transitions based on heterologists consensus welcome as positive [Applause] this thank you hello my name is vasili I'm with helix and today I will tell you about our project called anoma this will be a slightly higher level talk slightly more conceptual less less less formulas Maybe and you're looking at the slide you're probably wondering what's a Typhon and why does it hide in the Tiger but before we go to that question let's answer a different question that is slightly more fitting for for the conference and the question is what's a blockchain and there are many different ways to answer this question my personal favorite is that blockchain is a database and it has a very specific database of that with very specific properties it is append only it is highly distributed and highly replicated meaning that the distributed nodes for a store full replica it is ordered and serialized and it stores records and we call this records transactions and these transactions they are they uh they contain State transitions so the database as a whole can stay in the global State and these transactions contain uh State transitions so we go from one state to a different state typically the state is often it's exchange of resources size and tokens to you you send tokens to me but it could be anything else it could be games it could be ens basically any application that Stores um State on the chain stores their data on the chain is part of this Global state important characteristic of State transitions that we store in the blockchain is that they often affect multiple parties and then we when we have multiple parties we have settlement what settlement it's a multi-party state transition that everybody agrees on when settlement happens parties already know what they settle on and who they settle with to reach the phase of settlement they need to figure this out they need to find the counterparty so who they settle with and they need to decide on the terms of their settlement so what they are settling on this space that happens before settlement is referred to as the phase of counterparty discovery marketplaces do this uh they match sellers with buyers for example and help them agree on the price but even without the counterparty discovery phase settlement phase itself is not trivial a simplest form of settlement of settlement is manual settlement let's say I want to buy some coffee for Bitcoin I can send Bitcoin use my phone show that the transaction is confirmed to the Barista they would pour a coffee for me and we're done so this is manual settlement we can call that generation zero Generation 1 scriptable settlement was represented by Bitcoin and Bitcoin script and Bitcoin script was very limited very hard to write hard to use but even that gave way to a lot of very interesting projects for example colored coin which was a predecessor to tokens as we know them today or name coin which was a predecessor to ens uh generation 2 of course led by ethereum was programmable settlement and this opened The Floodgate of possibilities we have multiple assets fungible non-fungible we have Dows dexes games lots and lots and lots of different things and for all of this application applications settlement happens on ethereum but all of these applications also need counterparty Discovery so how do they do counter Discovery counterparty Discovery now there are several General ways to do counterparty Discovery today we can do it on the blockchain and this is what algorithmic market makers and on-chain Order books do we can have a centralized off-chain database such as openc zero extra layers flashbuster good examples of that or we can have app specific Sovereign chains dydx is a great example of that these approaches have their problems if we do this on blockchain it's kind of expensive and also unnecessary we don't really need to store the data related to counterparty Discovery on chain uh centralized database is the problem with them is well they are centralized and our specific Sovereign chains this is a great idea and everything is great about it except for it's really hard to do it requires a lot of development work a lot of time and effort and not everybody can pull this off but if somehow we could generalize this use case somehow we can make it possible that we have some kind of app specific chain on demand that would be great and this is something that a Noma tries to do a normal is a framework for programmable settlement and counterparty discovery and in our view this is what a third generation of blockchain should look like it only is built on several key design principles three of which are privacy intensentricity meaning that applications written on a Noma only need to Define their particular State transition rules and everything else is taken care of and something we call homogeneous architecture heterogeneous security we'll talk about this uh in this in the next slide so let's start with privacy privacy in public ledgers what's the state of the art there well in general there is no privacy in public ledgers no no privacy in blockchains uh and but contrary to popular top to popular belief this is not an intrinsic property of a blockchain they don't have to store everything in the open they don't have to be transparent uh just when we were when we started building blockchains and we wanted certain properties namely them being highly replicated and publicly verifiable we just didn't know how to do this without having everything in the open but over the time there was many attempts at achieving privacy on blockchain and very different approaches to do that I think the first attempts to do that were Bitcoin mixers and initial Bitcoin mixers were pretty simple I'm pretty sure it was just a dude somewhere you can send your Bitcoin to and he would just send it to some other address but then if you add zero knowledge proofs to that and we can have something like tornado cash on ethereum there are cryptographic approaches such as new Cipher which I think now is called threshold they try to use a lot of different cryptography uh proxy re-encryption homomorphic encryption threshold encryption uh bundle all this together to achieve uh privacy um secret Network tried to use a trusted execution environments such as Intel sgx and AMD Sav to achieve privacy and then zero knowledge post entered our lives and a big breakthrough was zcash which combined the latest research in zero knowledge proofs and cryptography great engineering and they were able to create an actual private blockchain which was great it was a great breakthrough but it was also and still is also very limited in its capabilities it only supports one asset type which is zcash it does not have any programmability there is no Bridges to or from Z cache but still a great a great breakthrough nope sorry slide got mixed up and Noma is in many ways inspired by Z cash but it does have programmability and it supports multiple assets by using utxo and a lot of zero knowledge proofs we can achieve not only data privacy but also function privacy when we say data privacy we mean that we don't know amounts owners what happens to assets assets are stored off chain in the form of node it's utxo and given a note which is not stored on chain we can use on-chain data to validate that the node is legit and it was not yet spent function privacy mean we mean that we don't know which contracts are executed we don't even know which contracts generally exist we just know that there is some contract and it was executed properly using zero knowledge proof but we don't know what country that was and when we say we don't know we mean that have user users consent to sharing the data with whoever they choose to share it with so they have a choice a second design principle is intense intensentricity so um we mentioned that settlement is when is when a multi-party state transition happens that everybody agrees on so what does this word agrees here actually mean on ethereum for example we don't sign off on the desired State change instead we signed off on execution of kilobytes of evm byte code hoping that it would lead to a state change that we want but we accept whatever state change actually happens we accept whatever results it produces even if we are unhappy a good example of that is slippage when we do swaps with a Noma we forget the imperative because we are now in the declarative land using intense we express what we want not how to get it we do this using uh binding programmatic commitments to our preferences those are sent to appears-to-peer intent gossip Network and then special type of agents in the network called solvers they look at the mempool of intents and they try to find compatible intents and create transactions that fulfill this intents and these transactions are then settled on a settlement layer uh the third design principle is homogeneous architecture heterogeneous security this should be on my t-shirts here under the word Noma and this idea behind this principle um is that not all monopolies are bad uh protocol monopolies are actually good we use the same protocols TCP HTTP email and we all win from that we all win from these protocols being ubiquitous because we get interoperability we get diversity of vendors and so on however some monopolies are bad and security domain monopolies are bad in particular because they are controlled whoever controls them can cut you off completely a good example is usdc with their black list of users who use tornado cash for example they can extract rent and so on and usually architectures and security domains they come in a bundle but they don't have to be so actually they don't have to be coupled and in fact in a Noma they are decoupled because anoma is not a blockchain anoma is an architecture for multiple different but highly compatible chains we call them fractals so normally is a set of components for counterparty Discovery and settlement and you can mix and match these components you can use different setups including different security setups you can use intent gossip Network on top of ethereum and settle on ethereum instead of a Noma and all these fractals are highly compatible you think Cosmos to the power of 10. you can use assets from one a normal fractal on another a normal fractal you can start your own fractals that are fully managed by you or by agents that you trust and you can even create temporary fractals for a specific occasion transact there and then only settle the final result to the main chain a normal consists of many components there are many projects in anoma but today I want to focus on three of them vampire tiger and Typhon so let's start with vampire what's vampire it's an intermediate representation language for arithmetic circuits you can think about it as llvm for zero knowledge proofs higher level languages can compile to vampire representation and vampire compiles to different proof systems here you can see a piece of code written in Vampire this piece of code checks if it if three numbers form a Pythagorean triplet and we can come out and run this code we can uh compile this circuit into Halo 2 circuit we can then try to prove it and when it we prove it it asks for Witnesses we Supply 5 4 and 3 which indeed do form a Pythagorean triplet 3 squared plus 4 squared equals 5 squared and we produce a proof and then we can put this proof into a verifier in vampire and it would say that the proof is valid if we put different triplet which is not a Pythagorean triplet then it would say that the proof is not valid this is available on GitHub you can download it from a Noma GitHub try it run it we would be happy to hear any feedback a second component is Tiger tiger is something like an operating system for distributed applications that enables private we call them shielded State transitions it is utxo based uh it relies on validity predicates which are declarative smart contracts and it can make Atomic State transitions of arbitrary complexity and to operate the only thing that tiger needs as an operating system for this application not only needs a data storage to run on top of so being utxo based tiger stores its state in the form of nodes which are immutable structures with multiple fields we would take a look at three of them which are value how many or how much of something is there governing app which is what kind of node this is is it usdc ether Bitcoin and ownership app notes nodes are not stored on chain they are stored off chain you can store your own nodes finally we can store our crypto on a thumb drive and on chain we only store data to validate the nodes to make sure that it's legit and it was not yet spent every transaction as it is in utxo and nodes come in and then the same amount of notes come out um okay just a second one of the slides got mixed up to different place here it is uh well it is predicates in Tiger are declarative smart contracts that tiger uses uh for programming the apps they do they do not describe how to get the result they describe what this result should look like they describe intents it's a very different programming Paradigm because uh well it's declarative and not imperative and as a mental exercise we can try to think what in erc20 for example would look like in um declarative form because there is no balances where in utxo now there is no re-entracy or things like that to think about which has defined what is allowed as a state transition so for example owner of a node can burn it and produce a new note of the same value with a different owner this is equivalent to token transfer and so on you can just list all the allowed State Transitions and basically you are done validity practicals are of course arithmetic circuits so that we can produce your knowledge proofs and today we're using Halo 2 for that and we rely heavily on vampire to do that so how does tiger Works in general how do we do this intense and how these intents are expressed and how do they turn into transactions let's say we have uh Alice and Bob as usual and Alice has a note of one Bitcoin in her name and Bob has a note of 10 ether in his name and this is our existing state this is where we are right now but it happens that both Alice and Bob want to change their state Alice wants to exchange her Bitcoin for ether and Bob wants the opposite and they're both okay with the 1 to 10 exchange ratio so here is what Alice wants Alice wants to have 10 ether note in her name this is this doesn't exist yet this is just what she wants and Bob wants this he wants a note of one Bitcoin in his name Alice is okay to burn to destroy her name sorry her note uh if she wants if she can get this she cannot just give this to Bob because notes are immutable so she cannot change the owner there she needs to destroy this and Bob Bob is okay to destroy his note if he can get here so here is the desired State and both Alice and Bob are okay to destroy the existing state if they can get a desired state and this is it this are intense this is Alice's intent she wants to destroy this to get this this is Bob's intention he wants to destroy this to get this intense destroy existing notes or existing state and create desired nodes or desired state but this this is not yet committed to blockchain this knows don't exist yet they only exist in the form of intent and these intents are floating in the intent mempo so now solvers they would look at the mempo and they would see these two intense and they would see that these two intents are indeed compatible meaning that they produce a balanced transaction one Bitcoin is destroyed one Bitcoin is created 10 ether is destroyed and ether is created nothing is lost nothing is minted out of thin air so we are balanced this means that this transaction this would be a valid transaction uh so they will create the solver would create a transaction out of this to intent and submit it to the data storage as I mentioned before tiger can run on any data storage uh and in the case of anoma it runs on Typhon so what is Typhon Typhon is an engine for ordering and concurrent civilizable execution of transactions what do these words mean as we mentioned before blockchain is a database of State and what do we typically want from a database we want to have high availability we have that we want to have high integrity we definitely have that and we want to have high throughput unfortunately we don't have that usually because most consensus algorithms in particular ethereum consensus algorithm tender means for example um they use serialized execution so to overcome this instead of serialized execution we will we should do serializable execution so what's the difference between serialized and civilizable execution serialized execution is non-concurrent it is by definition one by one and this means that there is a practical upper bound on performance of any network that uses serialized execution whatever is the performance of one CPU core whatever however fast we can do transactions single threadedly this is how fast we can go as a whole network serializable execution is concurrent but there is a condition on this concurrency that the result of concurrent execution must be equivalent to some serialized execution how can we achieve serializable execution of transactions on blockchain well we can try to compute unrelated transactions concurrently because this is safe if transactions are unrelated we don't have to worry about uh concurrency so to determine the transactions are unrelated this means that they have to work on clearly separated parts of State in Typhon state is stored in the form of key value store so transactions declare key subspaces that they read and write and it's easy and fast to determine non-overlapping key subspaces and group transactions for concurrent execution there's a lot more I could tell you about but we're Limited in time so this is an overview of a Noma architecture user indicates their preferences through a wallet for your wallet using user interface the wallet transforms this preferences into intents in the form of validity predicates and uh and intents and they are sent to uh the they are sent to the solvers solvers combine those into transactions and then the rest of this is very typical for very similar to other blockchains so the biggest differences are located in this in this area uh unfortunately that's that's the time we have I would be happy to answer any questions I hope I sparked your interests in this project follow me on Twitter check us out at nome.net or on our GitHub there's lots of different very cool projects that we're working on thank you [Applause] any questions thanks for the talk is there an equivalent of Mev in this system like are those intents uh openly visible to everyone in the pool or are they encrypted maybe right um question so I'm personally not a an expert on Mev I know that a lot of conventional Mev that we see for example in ethereum or in other chains this some of it is no longer a problem in this architecture there is still some areas some possibilities for Mev and I know that a lot of my colleagues they work on this issue and they do research in this but me personally I very very far away from that unfortunately I can maybe contact you with somebody who is doing this in the team yeah thank you for the insightful talk um vampire specifically seemed very interesting so we'd love to learn more about in the slide that you talked about vampire it showed that we can compile from say Socrates or Socom to vampire then we can actually prove that in Halo 2 or yeah song cup things like that is that actually possible today like if I am a circum developer can I actually prove circuits in Halo 2 through vampire some of these paths are possible today but not all so Alucard and juviks are two languages that are developed in Helix so these are developed by us uh this compilation is under heavy development right now this does work from here you can go you can go to Halo 2 and plan cap right now there is definitely work happening on supporting other languages but I don't know the current exact state of this how far along the team is so right now for example what I do I write straight in vampire and then I I go here so it's a shortened path but yeah there is a lot of development happening there and I'm sure one of the languages one of these two is the support is being worked on it's at some stage of Readiness but I'm not sure exactly what stage of redness it is okay any other question thank you very much for the talk um so these intents are they written are they essential are they essentially zero knowledge proofs and are they written in in vampir or I don't yeah okay so intense um we have intense in the form of uh so this is a simplified schema of how this works apart from when we what we indicate as notes and how this nodes should uh what nodes should be destroyed and what nodes should be created everything is also in addition to that we also have believe these predicates that are written as arithmetic circuits so every node has a validity predicate and then we also have a validity predicate the user's supplied validity predicate for their intent and all together uh this every individual validity predicate must be proved to be correct and then all of this together is sent to a different circuit which is like a tiger circuit that verifies that all the proofs were valid and produces a proof of verifying the proofs and then this final proof this is what gets submitted to to the chain so that's that's how it works okay so there are two rounds of proof generation there's there's validity proofs constructed for each of the uh for each of those and for each intent and then the whole transaction gets wrapped up in another proof yes as well okay I see okay cool um and then on the vampire question uh so there's this project open ZL that I think was created by Manta that it seems like it does a similar thing I'm just wondering if you're aware of that project and if you can talk about some of the differences between opencl and vampire if you're not aware of it that's that's okay too but I'm not familiar with opencl but I will look it up okay cool thank you open ZL right that's right yeah okay one last question uh great talk so I was wondering how to verify different states from the different tab because each step maybe has its own proof generation so how do you make a verifier work just cause different depth uh you mean sorry you mean here so how do you verify different apps have different states a different depth has different states since the proof is uh very uh the uh since the dev is has its own proof so how do you make the proof can work across different depth okay so the apps are all the apps in Tiger are validity predicates and all the apps are stored in notes and the nodes themselves are the states so the nodes have a reference to an app that governs them to evaluate to a circuit that governs a particular type of node so this ethereum node and this ethereum node they are different nodes but they have reference to the change to the state that happens for ethereum app somewhere else there might be a different transaction that changes the different parts of the state but in this transaction we don't care about that and they all have the same uh proof system they all work on they all produce hello to proofs and this happens at the time of execution of transactions I hope I answered your question okay once again thanks basically for the great talk thank you so we will have like 30 minutes break um the next talk will start at 4 pm