Ethereum provides decentralized, permissionless and censorship-resistant state settlement and dApps make extensive use of that. However most dApps also need counter-party discovery and solving capabilities in order to provide users with interactivity to discover others with whom to trade/settle transactions. This talk proposes an intent-solver pattern and explains how dApps from OpenSea to CowSwap and L2s such as Optimism or Starknet can use it to become truly decentralized.

You And I'm going to hand it over to Adrian.

I'm Adrian, and I'm 1 of the co-founders of Anoma.

And today, I am briefly going to introduce Anoma to you, which is it's an architecture for a unified architecture for full stack decentralized applications.

And to begin with, I'll start with a historic context of how we got to today's state, what the first steps were, and I think what the next generation is going to look like.

So when I think about how blockchains have evolved, it obviously started with Bitcoin.

And Bitcoin really was the first generation and gave us scriptable settlement.

Like before then, we didn't have decentralized applications.

But Bitcoin was very good at giving us scriptable settlement Which allowed us to do things like we all of a sudden had cryptocurrencies and we had the first attempts to build things like colored coins or name name coin and Interesting enough Vitalik talks about this in the Ethereum white paper, that 1 of the reasons why Ethereum came was in order to overcome the limitations of scriptable settlement on Bitcoin.

To me, Bitcoin is always this thing where we try to build applications, but they were sort of clunky.

For Namecoin, for example, you had to run a forked Bitcoin client.

And in order to overcome some of these limitations that scriptable settlement presented, we got programmable settlement.

And to me, this is really the second generation of blockchain architectures and blockchain protocols, because all of a sudden we went from this very limited scriptable settlement environment into this very comprehensive programmable settlement environment.

So instead of having colored coins, we could now have ERC-20s.

But the big thing was that all of a sudden, applications were possible that weren't possible beforehand, right?

Like there were some things that you couldn't build on Bitcoin that now all of a sudden you could be building on a theorem and interesting enough like in the early days of really It wasn't clear what kind of applications would be built on programmable settlement.

It was a general architecture to overcome some of the limitations of Bitcoin that over time we explored a ton more.

And so we got like cool NFTs, soulbound tokens, AMMs, Things we didn't think about when we thought of, can we build this on Bitcoin?

Yeah, because fundamentally, the thing that programmable settlement allowed us to do, it added a ton more expressivity into the base layer settlement.

And as a result, we now have modern applications like DEXs, AMMs, NFT marketplaces.

But I think the important realization to me in the last 2 years or so is that there are similar trade-offs here in the space where generally speaking when you Nowadays have a dex on a mm you or like an NFT marketplace actually open C is a great example here Which is you often have this problem that there are a lot of, at least 1 web 2.0 centralized component in the entire stack, right?

When you think of what OpenSea actually does, users sign a message.

They send it to a centralized web 2.0 server because OpenSea needs counterparty discovery and solving.

And so the centralized server run by the OpenSea team now does receive all these signed messages, does some compute, and then ends up submitting this to a settlement system.

And I have to say, since 2015, we really haven't evolved the underlying architectures We have gotten let's say programmable settlement plus plus We've made advances in civil resistance.

We've come a long way in terms of proof of stake.

We've got privacy advances, advances in privacy tech.

We made bounds and leaps in terms of consensus and with like Tendermint and Avalanche and eventually we'll also get there with ETH2 and single slot finality.

But fundamentally all existing architectures are still this idea of it's just programmable settlement.

And it has the same fundamental limitations that we had in 2015, and we still have them nowadays.

But when you look at the applications, the current dApps that are being built, they don't just need programmable settlement, just like Namecoin and Colorcoins didn't just need scriptable settlement.

Because fundamentally, settlement is not sufficient.

Settlement works if the parties already know who they are, already know with whom they want to settle, and already know what they want to settle.

But many applications actually infrastructure for counterparty discovery, which is generally speaking, users don't have fully formed state transitions.

They have the idea that they currently have Bitcoin, and they'd rather hold some ETH.

So they have the intent of selling a Bitcoin for some ETH.

This is not something that they can settle on chain.

They need to discover some counterparty that either holds the exact inverse or a number of counterparties with whom they can settle.

And sometimes they also need help to agree with counterparties on what to actually settle.

You see this with quadratic public goods funding.

Like, when you think of what a rollup does, a user takes a transaction.

They send this to a single server, generally called a sequencer or a prover.

That prover aggregates a bunch of these things, does some compute, and this compute then gets settled on some base layer, on some programmable settlement layer.

So this is this general, like I want to say, design pattern, which is people have intents.

Solvers look at a bunch of these intents.

They do some compute over an arbitrary number of intents.

And then they end up settling the net state transitions So what have been some attempts at solving counterparty discovery in recent years Well, sort of the trivial way to do this is to do this on a blockchain.

It treats Ethereum, the contract on Ethereum, as the single counterparty discovery and solving mechanism.

Of course, this is expensive, because you're doing a bunch of compute over messages that honestly don't need global ordering and that don't need a total order.

You could do this also for on-chain order books.

But those are even more expensive than a mm's it's like mm's are sort of the cheap answer to how do you do counterpart discovery?

Using the current generation of blockchains The other answer is you centralize the entire thing and you run a single operator database Where you open C does this they run a single web to server that does this the 0x relayers do this flashbots does this too?

Where everyone signs the thing, they send it to Flashbot, Flashbot sends it to Ethereum.

All the rollup sequences, whether it's Arbitrum, Optimism, or StackNet do this.

And generally speaking, we've tried to make sure that at least they can't steal funds.

But they can, of course, always censor transactions and exclude people.

And honestly, they are by far the biggest weak points that we currently have.

Not anyone can run a stocknet solver, which means that if you're worried about actually having censorship-resistant tech, you need to start worrying about how do you decentralize the sequencers, the provers.

Because if I was a regulator, I would target the single Web 2 server that a private company called OpenSea is running in New York if I wanted to disrupt the NFT trading experience.

Some other examples were, I mean, DYDX is doing this now, so you can start building app-specific sovereign chains.

The other important thing is, between all these single operator databases, the signed messages aren't composable.

As in, I can't build an application that generalizes over the signed messages being sent to OpenC, 0x, and, I don't know, Arbitrum at the same time, because we don't have a standardized counterpart discovery and solving protocol that I can hook in to build my application.

So I want to talk a little bit here now about what I would consider sort of the third generation, which is a unified architecture for full stack decentralized applications, where it's not just programmable settlement, but also decentralized counterpart discovery and distributed solving.

So in a nutshell, Anoma is an architecture.

It is a thing that you can deploy into many different security models.

You can deploy this as an L1 and 1 half to decentralize some DAP or some roll up.

You can deploy this as an L2 to fully settle this on Ethereum.

This is an architecture for how you build truly full stack decentralized applications.

And in a nutshell, it's an intent-centric privacy preserving protocol for decentralized counterpart discovery, solving an atomic multi-chain settlement.

The 2 key design principles are intense centricity, which I've already spoken a little bit about, and homogeneous architecture and heterogeneous security models.

The second 1 talks more about the idea of being able to deploy this kind of architecture as an L2.

So generally speaking, users have intents.

They express what they want, not how to get it.

The problem is with current virtual machines, effectively, on whether this is Solana, Nia, the EVM, it doesn't matter.

In those models, users always express how the compute should happen.

No 1 writes, I'm willing to hold 0 Bitcoin if I get 100 ETH in exchange, people write, I'm trusting this execution trace and all opcodes that are being called can change the state.

Which results in interesting bugs where if you have a broken proxy contract, they can steal funds.

Because as a user, you never authorize what kind of state change you care about.

You authorize what execution flow you're OK with.

And so intents are just binding programmatic commitments to state preferences.

1 of the nice things is, once you have intents, you can build an intent gossip network where you can have hundreds of millions of these things.

Because they're not settled necessarily all in consensus.

So you can have 100 million of these intents just floating around, And then you have solvers that look at 100 million intents and go, which ones are compatible with each other?

Which ones can I take, put into a transaction, and have settled on some programmable settlement layer?

And the important thing here is intents are composable, As in the intents for OpenSea and 0x can be solved together at the same time.

This kind of intent-centric design is necessary to enable decentralized counterpart discovery and leads to this declarative paradigm for applications, where instead of authorizing some specific execution trace or execution flow of your program to achieve what you want, you authorize the fundamental state change that you care about.

As a result, you can do on-demand roll-ups where you net out all the state changes because you look at 110s and go, oh, this only results in 2 state updates on the underlying system, because they all net out and everyone gets what they want.

This allows users to treat things as a black box architecture, where users author and submit intents.

Then some magic happens, where the system figures out what other intents are there, how do I combine them, and then they're settled.

In the end, users just need to check the updated state OK.

So what does this architecture look like overall?

I saw a run through this at a high level.

The first component on the left is counterparty discovery.

So users write intents that can be transparent, shielded, or private.

You also get massive privacy benefits with this kind of architecture, which is quite nice.

The clients then create the intents, sign them.

Maybe they generate some associated zero-knowledge proofs.

Maybe you even use FHE if you want fully private intents.

Then clients submit this to intent gossip notes.

And there can be 100 million of these intents floating around.

Solvers most likely specialize in specific subsets of intents.

So it's very unlikely that someone can build a generalized solver because Intents are just code, as in they're at runtime, evaluated code.

So once a solver has found a set of intents, they can take it and create a transaction.

The important thing is transactions are generally front-runnable.

This is relatively easy to solve nowadays by having a DKG protocol like Fairview, where transactions are encrypted against a shared public key first.

Then those encrypted transactions are put into blocks.

The ordering of those transactions is established.

And on the next block, those transactions are then decrypted and executed.

This has the really nice benefit that no 1 can change the ordering anymore, and hence no 1 can front run or back run or sandwich.

You have a bunch of decrypted transactions.

Now you go to the execution verification phase.

This depends very specifically on what your underlying programmable settlement layer offers.

But generally, you will have some sort of unified execution environment where you can treat transparent shield in private state and have some validity predicates to enforce some invariants that users care about.

Now I'd like to go through homogeneous architecture, heterogeneous security.

Let's start with this protocols can generally bent be benevolent monopolies as in we all benefit from having agreed upon protocols like TCP IP or the cellular backbone because it allows us to Use a unified infrastructure effectively like my phone not only works in Europe.

It also works with the North American cellular backbone it works with the Asian cellular backbone, right?

But importantly security domains aren't monopolies because they can extract rent they can confiscate assets and Here the choice is really user should have a choice on what security domain they want to be in.

Maybe the security, maybe that choice from a user here is They want to be in global aetherium and that's a very valid choice Some other people may care about being in a local security zone where like them and their 500 people in their small village Run their own local commerce and they want to have most of the assets secured by their local security zone But importantly here it's not about saying which security zones people should opt into, but rather, we should give people choices in what security zones they can pick from.

And this leads to this very neat separation of protocols and architectures from security models, where we get the benefit of composability and of unified architectures, as well as the benefit from users being able to independently pick their own security models.

So the Anoma architecture can be deployed in several ways.

You can deploy this as a sovereign global L1.

You can deploy this as the city of Berlin can take this architecture and deploy it to settle all commerce in Berlin.

You can deploy this as an L1 and 1, 5, which is to decentralized L2s, like to run decentralized sequences and decentralized provers, or even to decentralized specific DAP constructions.

Or you can deploy this as an L2, where everything gets settled in the end to Ethereum.

So the first case is sort of where you only do intent gossip, but sequence and settle elsewhere.

Or the second 1 is where you use it to decentralize solvers and sequences.

And the third 1 really is where you use it to decentralize solvers and sequences.

And the third 1 really is where you use it to decentralize specific applications without losing composability.

I think this is a really underestimated challenge nowadays that every time a user sends a signed message to a Web2 server, we're losing composability across the ecosystem.

Because all of a sudden, I can't build a new kind of application on top of this that takes advantage of the signed messages from OpenSea and the signed messages from 0x.

Or you can deploy it as a local instance.

OK, so what do dApps look like on Anonyma?

Well, they have an intent format that says how to structure these intents so that everyone can do generalized compute over them.

You have solver algorithms that take in a set of intents and figure out which ones are composable and settle and combinable.

And you have validity predicates which do some settlement invariance, like we shouldn't be able to mint extra Bitcoin unless you're Bitcoin, or you shouldn't be able to put my account into a negative state.

And this kind of vertically integrated architecture means that you get end-to-end security for lifes and privacy guarantees.

And the really cool thing is you get no vendor lock-in, because your applications can be portable over multiple security zones, just like your phone is portable to most countries in the world.

You can build existing dApps with full stack decentralization.

Something like a fungible token swap, 0x, cow swap works really well.

The really nice thing is Anoma's architecture, it comes with programmable batching as well.

So you can temporarily encrypt these signed messages, store them on chain, and then after 10 blocks go, we now have a batch of these signed messages.

And use that to, and then at the same time, decrypt them, and then run the cowswap solver algorithms over this.

You can use this to build things like open C and D centers open C I've spoken a bunch about the roll ups and how to decentralize things like optimism and arbitrum you can also do this for quadratic funding where instead of having a Sort of semi trusted multi sick that everyone sends money to in the Gitcoin case, and then Gitcoin redistributes this.

And then you can combine all these intents at the same time and then Settle them as a complete batch on chain where all the right projects get the money that people intended to give them Yeah Yeah, but just like when we went from Bitcoin to aetherium we So over time discovered a ton of new applications that we didn't realize we could be building using these systems I expect that there are a bunch of cool things we can do in the future using this kind of generalized intent centric architecture for example private DAOs private second-price auctions where This is actually this example where you've used programmable threshold decryption where you keep all bits private Until you want to reveal them and then no 1 has to worry about an economic game with a commit reveal scheme You can build private games And I think what I'm most excited about is you can build multi-party, multivariate, private bartering protocols, where you can think of this as on-demand order books, where I may want to trade a CryptoPunk against a CryptoKitty and some ETH, only if the weather in Paris is nice and I get some concert tickets in Barcelona.

Because in the end, you're just trading arbitrary state transitions and code for each other.

And you can build on-demand run time roll ups, at least, where you net out the state changes.

There's a lot more than the 3 of us to this.

If you have questions at some point, we also have a booth upstairs.

There are physical white paper copies that you can check out that explains this probably way more coherently than I could do in these 20 minutes.

Anoma is a unified architecture for full stack decentralization.

So what do you think is the timeline before we can use Anoma to deploy an optimistic rollup?

I think timeline wise This is probably something where the intent centric architecture has become available early next year So, yeah, it's it's soon let's say this way Any other questions Yeah, I think people are just taking a bunch of pictures not questions, thank you very much Thank you.

See all Grand Amphi Théatre transcripts on Youtube

Adrian Brink - Intent-centric (intent-solver pattern) architectures for fully decentralized dApps