#DappCon22 : Day 2 - Intent-Centric Architectures For Fully Decentralized dApps, Adrian Brink

Transcript

and next up we're gonna welcome someone who goes overboard with aligning his colors to the theme of the conference Adrian brain co-founder of Anima yeah and Adrian thank you he's going to talk about intern Centric architectures for fully decentralized apps cool this works does it yes hello uh thing roll I think all for coming um I'm Adrian I'm one of the co-founders of anoma and today I'm here to very briefly talk to you about unified architectures for full stack decentralized applications or what we are trying to build with your normal architecture so let me start off by sort of a brief

historic uh recap on sort of where we started and how we got to where we are today which is really that in my mind the the first evolution of protocols really was uh it started with Bitcoin which was the first generation and it gave us scriptable settlement so when you think of um the first Generations it's not only Bitcoin it's also Litecoin Monero Z cash they all kind of fall into this category and they all just gave a scriptable setup it was a limited form of programmability that developers had access to and really the start with Bitcoin it allowed us to do cool things like build cryptocurrencies but even in the early days it became apparent that one of the very nice

things is that people want to build things on top of it so we started having things like colored coins like name coin um I don't know maybe anyone in the audience remember the global Bitcoin Stock Exchange like we tried to have the first kind of not I I don't call it decks but um so the first attempt at building trading systems on top of Bitcoin does actually anyone remember the global Bitcoin Stock Exchange or used it in the audience okay no this was a very early unregistered Securities Market run out of the states that allowed you to trade real world stock it was interesting like the first couple of colored coins were traded there but there are obvious were obvious problems with scriptable settlement

um and a lot of the applications that were being built at the time were incredibly clunky to use for example actually here to use namecoin you needed to run a fork client of the Bitcoin cork line in order to run name coin right so there were a lot of uh drawbacks to using just scriptable settlement and as a result we got the second generation of protocols really which was programmable settlement and this all started with ethereum and interesting enough vitalik actually talks about this in the white paper that one of the reasons for ethereum was the limitations of scriptable settlement and all of a sudden we managed to move away from colored coins and we went to esc20s we could move away from namecoin and

went to the ens but the nice thing is there were also a bunch of applications that we didn't think about when ethereum was designed right like there were a bunch of new things like solvent tokens nfts Dows no one really thought about nfts back when ethereum was being originally developed because everyone was still in the model of like what's buildable on bitcoin and how can you make this better so in the same way that you could build color content Bitcoin you can build modern applications um modern uc20s on ethereum right now but again there are trade-offs right we have a lot of cool things like modern dexas and amms and nft marketplaces but they are also clunky in a lot of ways

generally speaking the application specific as in you don't have composability between the different applications except for the settlement layer and they generally require at least one Web Two or centralized component and actually a good example here was the previous talk infuro right so we're always in this model how do we fully decentralize modern application modern apps so when you I mean we have a ton of cool things but all of them if you think about it like open C right open C is just a settlement on ethereum a lot of all of the counterpart Discovery as well as solving component is fully centralized Xerox is the same problem all the Roll-Ups have exactly the same problem it's like optimism right it's you interact with a centralized web 2

server that does the solving and I think especially in the world of increased regulatory scrutiny having these very centralized failure points is not going to be a long-term sustainable model because they're the most obvious places for people to attack um I also don't want to forget that there were a bunch of other Innovations since 2040 or 2015 with ethereum but in my mind really it's the programmable settlement plus plus model because alright we had advances in civil resistance right we moved away from proof of work and moved towards proof of stake we had advances in scaling we now have Roll-Ups we have advances in privacy with zcash and zcash-like things and we definitely had a lot of advances in consensus like tenement Avalanche and

eventually single east two single slot finality all of these systems are still programmable settlement fundamentally like I think everyone sort of since 2015 has claimed that um like for a bunch of the sort of newer blockchains are fundamentally different but really it's just an imperatively executed VM it's a slightly different color but whether this is ethereum Avalanche really doesn't change the fundamental underlying model that application develops have access to um nope there okay so one of the big insights is that when you look at modern dabs that

settlement is not sufficient settlement happens when parties already know who they are what they want to settle and with whom they want to settle but practically speaking a lot of applications actually need infrastructure for Quantified Discovery they need help discovering each other parties with whom to trade for example this is the case of what the synvis open C server does at the moment right like I want to trade some cryptic Kitty against some eth I send this to a centralized server that centralized server receives a bunch of these messages and then figures out which ones are combinable and settled on chain and in some cases you also need infrastructure to help counterbilities agree on exactly what they want to be settling we have lots of examples here I mean there are marketplaces where you've buyers and

sellers quadratic paper goods funding is the same thing where you need to sort of have counterparty Discovery for project donors and funders there are dials where you want to not do the calculation of the votes on chain but rather you want to be able to aggregate all these votes first and then you have roll-ups right so what are contemporary approaches to kind of party Discovery Well in my mind there are roughly three approaches that we're currently using one you do on a blockchain uh this is what unisoft does this is what every amm does and I have to say uniswap is sort of the single best case that you can do if you want to do counterpillar discovery on chain it's the single most gas efficient way to do counterparty

discovery on the Chain you could theoretically also do an on-chain audiobook but that's incredibly expensive and as a result no one does this but when you really think about this why are we doing this using a globally ordered settlement layer is incredibly expensive and it's kind of silly because you don't really need a global total order over all these different messages that go into an amm for example so doing counterfeit discovery on a blockchain yes you can optimize for this but it really limits the kind of applications that you can build in a fully decent first manner the second option is you do sort of uh the single operator database you do the openc model you run one single web 2 server that acts as the shelling point that everyone sends then tends to that

then figures out who should coordinate with each other Xerox does this the flashbot relays do this uh every roll up sequence sequencer or roll-up prover does this too um obviously here the big downside is that these are now trusted parties um that I mean we've gotten pretty good at this where at least they probably can't steal your money but at the very least in most cases right now they can completely Center you and refuse and not actually only censor you to enter the system and transact in it but in most cases they can certainly also prevent you from leaving the system so they can indefinitely censor you which I would say is roughly the same as being able to steal your money so that's the second approach single operator database and the third approach right now is sort of

app specific Sovereign chains um a bunch of people like dydx are trying this there are other trade-offs here which is you have tons of depth work in order to make this work and you lose all composability between the different applications because now a user doesn't can't just interact with many different applications on the same chain but rather they have to go to a unique change for every single application they want um so in the last 10 minutes I'd quickly like to talk to you through sort of what in my mind is the third generation uh of protocols which is a unified architecture of a full stack decentralized applications that not only takes into account how we design programmable settlement systems but also takes into account how we design decentralized counterparty Discovery and

distributed solving so a normal in a nutshell and here it's important to remember a normal architecture you can deploy anoma in many different ways and hopefully people do you can deploy a normal as a sovereign L1 you can deploy a Noma as a city of Berlin settlement system to like facilitate Financial transactions in Berlin you can deploy a Noma as an L1 and a half to decentralize a specific dap on ethereum or you can deploy known as an L2 where all the settlement fundamentally happens on ethereum so enormous intent-centric privacy preserving protocol for decent price counterparty Discovery distributed solving and atomic multi-chain settlement so the two key design principles here are intense centricity and homogeneous architecture and heterogeneous security

and I'll go through both of them in order so intense centricity what does this mean actually um in the current model people don't have intents like in every existing blockchain uh the fundamental unit is a transaction but a transaction is a finalized State transition that we can settle on some underlying system right it's like um I want to send money from A to B but it's not a transaction that I want to sell a cryptocurity for some eth and this is generally what users have users have partial transactions or partial State Transitions and we're calling them intense which because users fundamentally express what they want and they don't have access to all the existing state because like you have

this if you're in a supermarket because the con the supermarket acts as you kind of apply discovering Point um so users express what they want not how to get it and intents are binding programmatic commitments to State preferences um one of the other nice things is that this is aligns much closer to with how ordinary people think about signing messages right because in the current model when I as a user sign a transaction I don't authorize a specific State change I authorize some execution Trace that involves a bunch of up codes and these op codes can do arbitrary things this means that as a user I really honestly should be auditing every single up code that I sign over because they may do arbitrary things so like I'm

authorizing not a specific thing that someone else has some money or that I'm trading some asset I'm authorizing very specific up codes to be executed in the context of global ethereum yeah so and really really like my parents think about this as like my parents think about this in the sense that they are willing to spend some money or move some funds around they aren't thinking about am I authorizing the right server calls behind the Visa Network right um once you have intents you can build a P2P intent gossip Network and here the cool thing is you can have 100 million of these intents floating around the same point in the same network no one needs to have a globally consistent view of this uh not all these this intents are going to be end up settled on some

underlying settlement layer and as an intent gossip node I can decide which intents I care about maybe I only care about the Bitcoin to Ethan tense and some nft trading intents but not about all the other things and in the sort of global intent Network you can do this then you have solvers where solvers find compatible intents and you have the soup of intense lying around and you go and solvers can look at this and go which ones of these are combinable which ones actually satisfy each other and which ones are as a result settleable on some online settlement system here the really cool thing is that that this also means that intents are not composable so the open scene tens and the Xerox intents can be composed into a single transaction I am not tied into a fundamental dap where I can only trade

on openc but the open C trades can share the liquidity together with the Xerox traits um yes this kind of intent-centric design is necessary to enable decentralized counterparty to Discovery and once you since intents only state what kind of future State transition you're willing to accept it leads to this very declarative Paradigm for decentralized applications um this also means that users don't have to care what happens in the middle uh users author and submit intents that say what future state they're willing to accept and then magic happens right this means like I may want to trade some bit let's say one Bitcoin for 100 eth um this could mean that there is one

other kind of party that filters trade or that there is a hundred and as a user I never have to care about this exactly how many counterparties there are to me because the system can just figure out what sort of the best settlement route for me and in the end users only need to check whether um their intent was correctly settled or not so uh since I only have six and a half minutes I won't go through the entire diagram but this is sort of a high level overview of what a normal looks like and what this kind of architecture looks like on the left here you have intents and you have users and users author intents they these could be transparent shielded or private the clients then sign them and this may also involve the generation of a bunch of their knowledge

proofs if you want to associate privacy guarantees for this they then get submitted to the intent gossip Network and in 10 gossip notes gossip the one the intense around that they care about solve us look at this pool of intents and go which ones are combinable and this is not a permissioned role anyone can run a solver and anyone can specialize on a specific subset of intents that they care about once solvers have found effectively solutions that maybe combine 15 different intents together they submit this as a transaction in consensus here the question becomes why would anyone run a solver if someone else can just front run them and the answer really is that front running is relatively straightforward yourself if you're willing to incorporate like re-architect

your base layer which means that for example like in nanoma we're using something called fevio which just means that there's a distributed key generation protocol that has a single shared public key transactions are encrypted against this shared public key then encrypted byte strings are put into blocks validated validators finalize those blocks and then on block n plus one those transactions are decrypted and then executed at that point they aren't front runnable anymore you can't front-end background or sandwich them anymore you also can't submit them with a slightly higher gasket Because by the time they're revealed they will you cannot change the ordering anymore in which they appear and yeah and then once you now have a block with finalized a finalized block with a bunch of decrypted transactions

it comes into this execution verification phase where uh there's a unified execution environment which can handle uh transparent Shield as well as private state okay the last bit I want to talk about is homogeneous architectures and heterogeneous security models uh protocols can very easily be benevolent monopolies because everyone pretty much wins by agreeing on the same protocols like we all win from agreeing on the same cell your backbone or the same protocol for TCP um because the kind of factual losses are marginal and like this is a very nice design criteria in the real world because it allows things like I can take my phone that I bought in Switzerland and use it on the cellular Backbone in

the states or in South America and I don't have to if we didn't agree on the same protocols they'd have to buy new phones for every single sort of security model I went into effectively but crucially security domains shouldn't be monopolies because security domains can steal your money they are non-local they can extend rent extract rent um and it's very hard to abstract the kind of security guarantees that actually security domains give you so really what you want to do is you want to be able to separate the protocols and architectures from the underlying security model and ideally deploy the same kind of architectures in many different security models because different people have different preferences for what is there the

preferred security model right like I think my parents don't really want to trust Global eth because they don't understand it but they may very well trust some of their local Village of 500 people to secure their assets because and the important thing is we shouldn't force people into specific security models we should allow people to pick the security models that they're comfortable with um so this kind of thing means that you can deploy anoma in many different ways you can deploy a Noma as a sovereign chain as a sovereign Global L1 you can deploy it as a community operated chain maybe the city of Berlin can run this kind of architecture to facilitate Financial transactions within Berlin you can deploy it as an L1 and a half to decentralize the specific L2 or specific

dap construction or you can deploy this as an L2 where all the settlement still happens on ethereum or some other underlying settlement system by the way like we are not that opinionated about where our Noma gets deployed yeah right what do these deployment patterns look like so the first one is you only use the intent Gospel Network and you sequence and settle elsewhere the second one is you also use automotive decentralize your solvers or roll up sequences or approvers um or the sort of the L1 and a half case is you use this to decentralize specifically ZRX or cow swap or the third model is you deploy this as a local instance okay two minutes all right so what do dapps look like on

anoma well dabs have roughly three components you have intent formats which just describe what kind of like what's the structure if you intend because an intent can just be arbitrary wasn't that's executed runtime you have solve algorithms at least basic ones that can figure out out of these 15 and 10s which ones are settleable and combinable and you have validity predicates and for settlement variants like if I'm transacting in Bitcoin I cannot be creating new Bitcoins out of thin air like my uh I need to be making a zero State change here this kind of vertical integrated architecture means that you get very nice end-to-end security liveness and privacy guarantees and importantly you don't get vendor login as in your applications are portable across security domains as in if I'm

flying from Berlin to New York my application can now work in a different security domain if I change my mind that or maybe you don't trust this valid I said anymore my I don't have have to change all the applications I'm using I can just change my underlying security model right so what can you build with anoma and similar to sort of back in the day when we thought about what could be building on ethereum when ethereum was being developed after sort of we discovered the limitations of scriptable settlement these are sort of examples of existing daps but with full stack decentralization I spoke a bunch about decentralized exchanges um as well as whether for fungible tokens or non-fungible tokens and amms Roll-Ups as well that you you can

definitely use and I want to decentralize a specific roll-up you can also build cool things like public goods funding in a fully decentralized way where instead of trusting or semi-trusting a semi-decentralized semi-centralized multi-sig run by the git coin team donors can rather have intents and once you have reached enough intense you can settle them on chain to fund the right projects um but I expect that there's also a category of things that we aren't thinking about yet um but that eventually you'll be able to build with anoma as we explore this kind of generalized intense Centric architecture more and more so if these are some examples that I keep thinking about private dials isn't one example I'm pretty excited about private auctions because with this kind of

programmable threshold decryption system you can actually build decentralized second price auctions uh where all the bits are kept private two minutes great um all private games the other thing I'm also very excited about is multi-party multivariate private bartering it is the idea that you can have an sort of user-defined marketplaces because there's no not a single order book anymore but rather every intent creates its own order book and you can settle across 15 different order books at the same time or an Autobox really um yeah so thank you very much this is sort of anoma is not only Built by me our and Chris it's an entire team behind us you can check out the team um and yeah thank you very much this is anoma Unified architecture for full

stack decentralization thanks Adrian thank you so much do we have time for questions exactly we have a couple of minutes for questions if you have one just raise your hand and we'll bring a mic to you yes sir hi could you speak more to the uh intent gossip network is it fast and scalable enough for the purpose uh yes so this is um importantly uh intents aren't consensus critical so you as an intent node you can have a completely different view of what intents exists than a node next to you as an intent node you can

also specify which intents you actually care about so for example maybe you only care about a specific pair for the intent and so you don't have to process all the global intents if you want to build a solver that's probably an argument that you should be listening to as much as many intents as possible so intent notes are sort of very configurable in terms of performance needs that they have cool thank you very much another question yeah up there right if you since you don't have to see the intents um as in you can sync any underlying chain even if you didn't see the intent

anyone that doses you can just ban yours appear similar to like how you solve existing dust this is um the same problem all right thanks it's time for one last question over there how do fees work exactly um right maybe I actually didn't go through this enough in enough depth here intents aren't specific as in intense I just wasn't um so there could be standards around this where so you're not sending around pass right like I use the example of BTC eth a lot but the intent doesn't actually know what a pairs or the prices of what an asset is so just code which

means that that code can just contain a user-defined fee field for the fee and this gives you a nice property that maybe you have a very complicated intent that requires someone to drive to a remote location to pick up a physical item for you at that point in order to convince someone to do this for you you may want to attach a hundred dollar fee with this if you're just willing to trade in a super liquid or if you just want to trade in a super liquid market like PTC eth you may don't you may not have to pay a fee at all um completely user defined cool thank you very much Adrian [Applause]