Exploring Intents in Modular Architectures

Highlights

  1. I like how intents were first motivated, and then a firmer definition was introduced by @cwgoes.

In general, intents are credible commitments to preferences over the state space of a system. And there are different state spaces which define the system**.**

  1. Uma’s framing of 4337 (Account Abstraction) helped me understand it better.

4337 is long and winding and complicated. Authors took 5 main intents and stuffed them into this ERC protocol. It’s not a general system, it’s very brittle. They worked backwards from how can I enforce these specific intents in a way that compliments Ethereum. AA does not help you solve the problem of I have ETH on Ethereum, I want the best price on PEPE. AA is a single domain protocol.

  1. Henry on users overpaying for txs

Suppose I’m executing a tx on Ethereum, in some sense I am paying too much. I am halting the entire world to get the property I want out of my tx, I’m paying for way too much synchronization there. I don’t care if someone minted an Ape NFT at the same time someone did my swap. As a user, I can’t express this unless I pay everyone else to stop the world.

  1. @cwgoes on weakness in literature wrt p2p designs and why better designs are important

If you zoom out of blockchain literature, I think the weakness is p2p designs. Its clear how to do many things like cryptography, but I think p2p networks have been neglected.

The reason I think it’s important to have a general p2p protocol, is that it will allow these systems to compose more generally. There are many different separate unstructured mempools. There are specific lines in between like relayers, bridges, or nodes, and that is really just a Venn diagram. You have all of these mempools where people send messages to one mempool that don’t impact another and vice versa, leading to partial overlap. If we design p2p well, we can get a protocol that solves for this. Everyone can configure that the way they want, an intent (criteria rules). We aim to work with Flashbots on SUAVE and anyone else who wants to standardize on this layer.

  1. @cwgoes breaking down Solvers

In our lexicon, solvers are the entities doing the search, they have some choice over execution paths. If you define your fairness criteria clearly, then solvers are entities who you are paying specifically for doing the search. Solvers are basically fungible, you are creating a market for compute with some resiliency properties. Because you can verify the results of the computation, you don’t need to trust the solvers at all. Solvers are just doing the search problem in the purest definition.

  1. Zaki on the value of the modular stack

I think one of the things that has become an increasing part of my framing of blockchains; there are probably only 2 layers of blockchains which accrue value. We sell basic commodities for example DA, execution in shared state with things that are valuable, and artisanal organic non-toxic order flow. Celestia is canonically a vendor of a base commodity and potentially a shelling point for shared state or execution that might be valuable.

  1. Discourse on intents and the modular stack

Nick: So you are saying there could be an intent layer for each service, including DA? You set your preference for a security threshold?

Christopher: The interface pattern holds generally. Designing things correctly means Anoma and Celestia will be compatible without even trying.

  1. Uma closing thoughts on coordination

Not too much more to say other than the most interesting thing to say is research and community meets UX and I think that is one of the biggest problems in crypto. People who normally don’t talk have started engaging. At a meta-level, I hope that continues.