Anoma <3 Celestia: Intent-centric rollups

Notes from @cwgoes presentation at the modular summit 2023.

Intent-centric rollups

What is a rollup?

“A rollup is a type of blockchain that offloads some work to another layer 1. Rollups host applications and process transactions. Once those transactions get processed, they are then published to layer 1. It’s layer 1s hob to order those transactions and check that they are available, at minimum.”

This is a good definition, but there are three words that we will come back to, Type of blockchain.

Let’s first answer the question of What is an intent?

Anoma has been using this word for a while, and perhaps it remains criminally vague. The term has become popular, which probably has little to do with Anoma. Many people use the word intent to mean different things, not exactly described by Anoma, but they seem to be correlated. For example;

  • Intents for cross-chain bridging UX ala Uma Roy at Research day in NY
  • Intents for user wallets ala Penumbra - intents for users thinking about how to declare what they want a transaction to do or not do.
  • Intents let you have your cake and it too - the radical takes.

Language is the original-decentralized coordination scheme. We don’t get to pick individually what terms mean. However, if we zoom out and consider words, there is often some commonality. There is a reason the word intent became popular so quickly, so fast. People use the word in a way where others roughly understand what the word means.

What is an intent?

“An intent is a commitment to a preference function over the state space of a given system.”

– everyone (approximately)

As opposed to a transaction which specifies a specific imperative execution path to A then B then C. An intent says I want an execution path that satisfies these constraints. I have these preferences that I want executed. The state space of a given system is what varies. For example, when @Uma is talking about cross-chain bridging, the system is like the chains you are interested in bridging between.

When Anoma is talking about who knows what, the system is like the information flow. The bounds of what the system is that the intent refers to can change. But in all cases, intents are these credible commitments to preference functions.

Let’s zoom out. In the modular ecosystem, everything is organized around this concept of rollups. In our world (Anoma) everything is organized around this concept of intents. These are two interesting concepts because they come at the problem from two different approaches.

  • Rollups are bottom up - you start with a modular thesis - start with DA as the base layer, then you build rollups on top, and we see a proliferation of execution environments, different approaches to sharding, etc.
  • Intents come at thing top down or user down - users have intents. They are going to start with intents and the system better figure out how to do something reasonable. As system architects, we don’t get to choose, users will have their intents, and we have to try to build something that can satisfy that as credibly and fairly as possible.

In particular, let’s ask; can intents help out the modular ecosystem?

Mustafa in his talk earlier brought up a bunch of challenges and open problems. We have a slightly different list, but it shares several components

Three challenges for modular

  • Inefficient sharding
  • Application lock-in
  • User-facing complexity

By challenges, we don’t mean flaws. As the ecosystem is moving presently, if we try and foresee what might happen, and we try and avoid a few problems while we still have a chance to steer things, here are a few things to be cognizant of that perhaps intents can help with.

Challenge 1: inefficient sharding

  • Atomicity is expensive
  • Users want cross-rollup
    • Applications
    • Transfers
    • Interactions
  • Rollups implement static sharding
    • No response to “atomicity demand”

Atomicity is the most expensive thing in distributed systems. It requires that you send messages to one place and order them there. That implies N^2 consensus communication. The typical problem of sequential behavior in concurrent systems.

Users want everything. They want cross-rollup applications, transfers, and interactions. Users are not going to think about - I should put all of my state on rollup one to make it most efficient. Users will say I have assets on rollup one and want assets on rollup 2, it’s our job to make it work. In making it work, we want to give as much freedom as possible, when properly constrained, to the operators of the system to make it more efficient.

If we envision a world of rollups and all the rollups have different applications and the applications are bound to rollups and users hope to do lots of cross-application interactions, then we have added this weird constraint. There is a demand for atomicity with shared state. If we tie applications to rollups with separate sequencers, then we get this static sharding system - where we can’t change the topology of which different rollups are settled atomically. If we view the demand for atomicity as varying dynamically over time, this seems inefficient.

Challenge 2: application lock-in

  • Apps could get locked-in to rollups
  • Heterogeneous protocols/VMs make life hard
  • Apps may pay for more atomicity than necessary

One of the great things about the modular stack is that you can build heterogeneous execution layers very cheaply because it doesn’t require deploying a whole layer one. One challenge of heterogeneous protocol execution layers is that they make applications less portable.

The EVM for example, is an interesting VM, but it changes slowly. It would be easy to fork the EVM and launch a rollup with new EVM precompiles. One disadvantage, from the application or ecosystem perspective, is that then if other rollups don’t adopt this new opcode then there is application locked in.

For example, if the Sequencer of the rollup starts charging higher fees and users can’t switch, if there is a bunch of application state that gets tied to this specific execution system then apps get locked in. This means that applications will pay for more atomicity than strictly speaking is necessary.

Challenge 3: user-facing complexity

  • Modular component selection entails complex security assumptions
    • Different parties for solving, execution, DA…
  • How can users reason about what’s safe?
    • Different interactions require different safety levels…
  • How can users switch if something goes wrong?

One modular component selection and modular component construction adds a lot of clarity to the design construction of blockchains and allows teams to work on different parts, which is helpful from a coordination perspective. If these different parts are operated by different sequencers or validator sets, it tends to entail complex security assumptions. Requires that we create good standards

We think about this from the perspective of the user, what they have to reason about to know whether their interaction is safe. If there are different parties for solving, DA, or execution. Every time the user wants to send an intent or transaction, they are not going to reason through the crypto-economic calculus to determine if their interaction is safe.

We would always like to maintain sovereignty - users can switch if something goes wrong. Communities own the system. They bring value by bringing their applications or users to the blockchain. In particular, communities need to be able to credibly threaten to switch if something goes wrong and not actually do it because it’s cheaper.

What if…

… we define applications not on top of rollups, but as intents?

Applications are kind of defined on top of rollups in the modular stack. There is a DA layer, execution, rollups have state formats and instruction sets, VMs and applications are defined on top of the rollups

Intent representation in Anoma

  • Intents specify what parts of state they must modify atomically
  • State referenced can be help on heterogeneous security domains
  • Each piece of state has a party who must sign

If we think about the whole system as having a sharded state where the state is sharded by concurrency domains and security domains, intents specify in an explicitly include fashion which part of the state they must modify. The state can be held in different domains. If you require atomic settlement between two completely validator sets, that is not possible. But you can specify in the intents which things you need to be atomic and the custodians of that state (validators, sequencers) must sign.

We have a concept called partial solving. Solving means matching intents. Solving can be done fully - you take a bunch of intents, you match them completely and form a fully balanced transaction. You can solve intents partially.

In this example, we take Alice’s intent and Bob’s intent. Bob already has something Alice wants. We take Bob’s dolphin and send it to Alice. Now we craft a new intent that requires we get a tree and give a star. We can do this by combining two intents doing some type of simplification and creating a new intent that we then send elsewhere to do more solving later, e.g.,

A⇒ B, B⇒ C, A⇒C

What is partial solving? Partial solving is a rollup. If we think about type of blockchain, what does type of blockchain mean? There is some hash linking, there is some history, and we need to be able to verify this later. Partial solving satisfies all of those properties, its just on demand.

  • We look at the intents,
  • do some type of partial state change,
  • we have some state changes we need to do,
  • we commit to those,
  • we can make them private,
  • roll them up in a ZKP,
  • and send the intents onwards.

Intent-Centric Rollups

  • Partial solving = rollup creation
  • Local liveness, global compositionality
    • This requires standardizing on a state format
    • Luckily, it’s a universal one - no UTXO/account dichotomy
  • Heterogeneous instruction sets are fine
    • But need the ability to verify all of them
    • Not convinced this matters anyways - compilers problem

Perhaps the difference with the current modular stack is that rollups are created on demand. This has some advantages. It allows for this kind of global compositionality and determining the actual topology of sharding at runtime (when you are processing intents), preserves local liveness, and perhaps standardizing on a state format which maybe controversial. We can probably do this without constraining choices.

One nice thing about intents is that they specify verification conditions, not the execution method. Which means you can have different instruction sets - preserve heterogeneity of execution systems - as long as you can verify. For example, If everything is a ZK rollup then intents specify conditions for verifying the other guy’s ZK rollup. If the other guy uses some other opcodes internally, you don’t care as long as the condition is eventually satisfied. It is a standard which allows you to agree on as little as possible,

Dynamic Sharding

  • Shard assignment is chosen at runtime
  • Intents can specify many valid consensus providers
    • if I’m paying for coffee, most anything is fine
  • Enables the network to dynamically sort into independent atomic bundles
  • Cheaper for users!

Intents can specify which consensus providers they are okay with. You don’t need to fix sending your intent to one specific rollup. You can say I want the cheapest settlement subject to these conditions and these are the security assumptions I’m okay with. This enables the network to dynamically sort into independent atomic bundles, so it should be cheaper for users.

Application portability

  • Applications defined by intent formats
  • Applications can move freely across rollups
  • The same application can shard its state
    • according to what users want!
  • Credible threat of forking out extractive operators

Defining applications by intent formats, if done well, should help with application portability because applications then are not tied to a specific rollup, they can move freely across rollups. Maybe heterogeneous instruction sets become specialized solving algorithms for different domains. The same application can shard its state depending on what users want, so you can move code and data across chain. Application portability gives you a credible threat to fork out extractive operators because it’s easy to move your application code and logic somewhere else. Everything is standardized to a sufficient degree. If someone is extracting MEV you have a credible threat to leave.

Information Flow Control

  • Intents in Anoma specify declarative constraints on information flow
    • “C must be revealed to A&B”
    • “Y must be revealed to C at block 123”
  • Enables things like:
  • Cross-rollup private bridging
  • New auction designs
  • Privacy-preserving governance
  • Programmatic disclosure of aggregate data

Specifically in Anoma we’ve been trying to craft a good framework for describing declaratively what information flow users want to allow for intents. This looks like declarative constraints. Intents can say “in conjunction with this atomic settlement, this value x must be revealed to A and B” X could be a note or a key.

These kinds of declarative information flow constraints allow things like cross-rollup private bridging, new auction designs, privacy-preserving governance, programmatic disclosure of aggregate data.

… so wtf is a blockchain?

  • With intent-centric rollups, blockchains are created on-demand
  • They live ephemeral lives
  • L1? L2? L3?
    • Observer-dependent!

A blockchain is a data structure. If you take a piece of data and you hash it with another piece of data and you include it, you’ve just gotten a partial ordering relation. This is the essential thing and everything else can perhaps be separated.

With intent-centric rollups we just create blockchains on demand. They live ephemeral lives where a blockchain exists for a moment when two intents are matched then its rolled up and it can be verified later. You still need somewhere for the data to be stored. The blockchains are quite ephemeral. Weather something is an L1, L2 or L3 is just an observer dependent finality choice.

Memes h/t @jon_charb
Rollups are L2s :skull:
Rollups are L1s :brain:
Rollups aren’t real :brain::boom:
Blockchains aren’t real :brain::globe_with_meridians:

Intent-centric modular economics

  • Service provider DAOs
    • Data availability DAOs (Celestia, Avail, Eigen DA, Ethereum)
    • Execution DAOs (current rollups?)
    • Solver DAOs (SUAVE)
    • … competing on the basis of liquidity + role-specific optimization
  • Assets people want
    • BTC, ETH
    • Ye Almighty American Empire Bucks
    • … competing on the basis of distribution and PGF
  • (h/t @zmanian)

If we conceive of a modular world of intents;

There are two classes of things people will want in an intent-centric modular world. The first class is service provider DAOs. A group of operators who are working together to provide services as a collective, coordinating together to provide that service efficiently and reliably. Users or applications see it as a service provided as a whole.

One kind of DAO in an intent centric world is a data availability DAO, for example. Service DAOs are competing on liquidity and role-specific optimizations.

Then there are assets people want. The assets are competing independently of protocols based on distributions and how good they are at public goods funding.

Three concluding thoughts

  • Intents <3 Modular
    • the last architectural convergence
  • Ethereum meets Cosmos
    • Also maps to the social structures!
  • Make your rollups private now!
    • avoid mistakes you don’t need to make

Intents and modular are like a match made in heaven. They come at the problem from opposite directions, they can kind of help solve each other’s problems. One challenge we’ve had in building Anoma is that we don’t have specialized primitives. We don’t have efficient DA sampling or individually optimized things, so there is a nice synergy here.

One thing to like about the modular blockchain world is that it seems like a sort of fusion between Ethereum and Cosmos. It is a fusion of the polycentric or self-sovereign political ideology with the kind of clear architectural thinking of the Ethereum ecosystem.

Let’s please not remake the mistake of making transparent rollups, this is not going to work.


Modular blockchain basics

For additional context to the former post, here we append additional notes which may assist the reader in forming a stronger understanding of the modular blockchain concepts and values.

Notes form Mustafa Al-Bassam’s presentation Modular State of the Union at the 2023 Modular Summit in Paris. The presentation does a great job of explaining the concepts of modular blockchains, the features of the modular stack, and the values of modularism not maximalism.

The monolithic era (2008-2020)

When Bitcoin whitepaper came out in 2008 it introduced a model of blockchains which stuck around for the next decade.

  • a model where the blockchain couples consensus with execution.
  • a model where every user has to execute every transaction of every other user
  • a model that limits flexibility because you’re enshrining a specific execution environment

In 2019 Mustafa Al-Bassam introduced the Lazy Ledger whitepaper. Lazy ledger was a simple blockchain that only does consensus and data availability. In that model, you have a very rollup centric model where you have a data and consensus layer only responsible for consensus. You have an execution layer which could be a rollup which posts its blocks to the data layer and inherits consensus and security from the data layer. This resulted in a modular blockchain ecosystem where consensus and execution are no longer coupled.

Defining the modular stack

Key Terms

  • Consensus Layer - provides an ordering over arbitrary messages.
  • Data availability layer - a verifiable way to publish the ordered messages.
  • Execution layer - does computation over transactions to output a “state”.
  • Settlement layer - an execution layer that bridges other execution layers together.

Developers input messages or transactions into the system, and the consensus layer simply decides what the order of those messages are. Once those messages have been ordered, users need a way to verify that they have actually been published to the network. Because what can happen is that a validator can execute a data withholding attack where they only publish the metadata of the block header but they don’t actually publish the data. In that attack, no one will know what the actual ordered messages are. No one will know what the state of the chain is and be to generate fraud proofs or progress the chain.

If you go back to the Bitcoin whitepaper, the proposed solution to the double spend problem was the idea of a timestamp server (the word “blockchain” does not appear in the Bitcoin whitepaper).

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. THe timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp reinforcing the ones before it.

The core thing that a blockchain provides is ordered data that is made available and time-stamped. If you have this basic primitive, which is a timestamp server, which is basically a consensus and data layer, then you can almost build anything on top of it using any kind of execution environment.

If you understand DA and consensus are the core primitives of blockchain, we figured out scalable ways to scale that using a primitive called data availability sampling. With DAS you have over a 99% guarantee that almost all the data is available by only downloading a minimal portion of the data, less than 1%. With this primitive, that basically means we don’t have to live in a world anymore where every user must download all transactions. Now you can scale blockchains more directly and in a more practical way.

The Execution Layer sits above the data and consensus layers. What it does is take a bunch of transactions and outputs a state. For example, those transactions could be payments and the state is what people’s account balance is. That is what a rollup does. It provides an execution environment to process transactions and create a state commitment to what people’s balances are.

In the modular blockchain model, the consensus and execution layers are decoupled.

Finally, you have a settlement layer. The settlement layer is a special case of an execution layer, which is used to bridge other rollups or execution layers together. For example, if you look at Ethereum as an execution layer, you have onchain light nodes for rollups on Ethereum which act as bridges between rollups and Ethereum. You can bridge assets between them. The onchain light client accepts block headers from the rollup and verifies validity proofs or fraud proofs.

What is a modular Blockchain?

A modular blockchain is a blockchain which fully outsources at least one of the four components of a blockchain;

  • Consensus,
  • DA,
  • Settlement, or
  • Execution

What are the benefits of modularity?

The first reason is scalability. Users don’t have to execute the transaction of every other user. Rollups have dedicated computation resources. If you spin up a rollup, the rollup has its own computational resources. Even if a rollup gets congested or has high computational requirements, that won’t affect every other rollup in the system. Data availability sampling makes it such that the more light nodes you have, the more secure block space you can have because the more light nodes that are sampling, the more data they can collectively reconstruct. Hence, the bigger the block size you can have. In a system that has DAS, the light nodes are collectively storing and making all data available, instead of one or a few nodes.

It’s important to note that ordering is still done in one logical location - the base layer (Celestia) - and there are physical limits to this.

The second reason is you give develops choice. With Ethereum, you are limited by the EVM. In the past few years, there have been many new developments and advancements in more efficient or practical execution environments for different use cases; for scale or other reasons. It’s not practical to deploy a new layer one to make a modification to an execution environment. With the modular blockchain stack, you can modify the EVM for example, with one new opcode and launch a rollup instead of deploying a new layer one from scratch.

There are different types of rollups for use cases; sovereign rollups, settled rollups, validiums, and celestiums (blobstream). Specifically sovereign rollups are an interesting case of rollups that effectively give the community of that rollup, the freedom to fork that rollup. You basically get the freedom of the layer one without the overhead of the layer one, without needing to create a new consensus network or token from scratch.

The ultimate goal is that deploying your decentralized application, as a rollup, should be easier than deploying a new smart contract.

Open Problems

  • Better UX for bridging - today, users need multiple fee tokens to bridge across chains.
  • Payment systems for resources across layers - how rollups charges users for DA layer resources. For example, you might have a rollup that needs to pay the DA layer or settlement layer. There must be a way to do token exchanges easily for developers without them having to maintain wallet infrastructure.
  • Too many choices - hard for new developers to understand the tradeoffs. Must do a better job at educating developers.
  • Maintaining dependencies across the stack - need common interfaces. These dependencies can be difficult to maintain if there is a breaking change. Is there a way to have better dependency management across the stack, so things are less likely to break when improvements are made.
  • Better proving systems - fraud proving systems are underdeveloped. ZK proving systems are still slow and must be faster.
  • Better Privacy - we should try to enshrine privacy into execution environments.

Anoma shoutout

The Destination

Let’s discuss some of the values of modularism and what we are trying to achieve with the modular blockchain stack. First, users should be first class citizens of the network. This is an ideal in crypto and Web 3 that seems to have been forgotten over the last ten years. The whole point of blockchains is that you don’t have to trust middlemen, and that includes validators and minors. You shouldn’t have to trust centralized RPC endpoints and APIs because that’s just web 2 all over again. One thing to appreciate about Bitcoin is that it has good light client support. You can install a light client on your phone which connects directly to the Bitcoin network and retrieve data without using centralized API endpoints. We need to go back to this ideal. This is why data availability light clients are important, they allow users to get back to the roots of web 3 by not needing to rely on centralized middlemen endpoints which are prone to censorship and corruption.

Modularism and not maximalism is an important ideal. Over the past decade we have been stuck in this endless cycle of new layer one chains every single bull run. We must escape the L1 cycle. This is not sustainable Its just creating an endless cycle of new tribes and ecosystems that are not collaborating with each other. It is a very zero sum mindset that needs to be replaced with a positive sum mindset, where incremental improvements can impact everyone that uses crypto. We can replace the zero sum mindset with a positive sum mindset by adopting a modular ecosystem. Its not sustainable to have a constant grave yard of new layer ones that are sucking up a lot of funding, extract value and fail to get traction. Crypto will never mature with this endless cycle. We must escape this endless cycle asap to have a more positive some crypto ecosystem that develops into worldwide mainstream developer adoption.

Sovereignty: the freedom to fork

Communities have an inalienable right to thrive through self-organization and collective action, unburdened by the status quo.

Communities have the choice to be sovereign if they’d like to. Crypto allows a specific group of people with a specific shared goal to thrive through self-organization and collective action that by creating a contract with each other. For the first time, this contract does not need to be enforced by real-world law, but rather can be enforced by cryptography on the p2p network. Previously, if you wanted to create a shared agreement, you would need to do it in a specific jurisdiction, but with blockchains you can bypass all of that and have a direct top-level social contract. This gives the community the freedom to fork if they decide they want to change the protocol rules.

Values of blockchain modularism

  • Users are first class citizens of the network; by focusing on light nodes and allowing people to run light nodes
  • Modularism, not maximalism; it’s important we escape the L1 monolithic loop or crypto will never mature
  • Communities can choose to be sovereign; they have the right to fork is they want to.