A (Slightly More) Formal Definition of Intents

Editor's Note (21 Feb 2024): Since publishing this article, we have updated how we conceive of and define intents. Rather than a constraint on the state transition function, an intent within our system represents a constraint on state itself.

Previously, we stated that solutions take the form of a transaction, and that state is updated when the transaction is executed within the execution environment. Our new approach is that solutions take the form of a state mutation, and state is updated simply by inclusion of that solution in a block.

This distinction has important consequences: most notably, it removes the need for on-chain execution, a change which has massive implications for scalability and cost.

Stay tuned for our announcement of the Essential chain in the near future.

As an emerging field within web3, intents have become a hot topic.

The concept of "intents" has only recently entered the domain of crypto discourse, and as a result, it is not concretely defined. Adding to this ambiguity is the fact that various projects and pundits have used the term to describe a range of different ideas and functionalities, ranging from "intents are just limit orders" to "an intent is a signed set of declarative constraints which allow a user to outsource transaction creation to a third party without relinquishing full control to the transacting party."

At Essential, we have been using a more formal working definition of intents:

An intent is a constraint on the state transition function.

An intent does not constitute a transaction. Rather, an intent is solved when a transaction to satisfy it is discovered by a solver. An intent being solvable merely means that a transaction, or series of transactions (i.e. state transitions), exist that produce an end state that satisfies that intent.

Under our conception of "intents", multiple intents may be solved for at one time. This results in a list of transactions that satisfy many intents to varying degrees. This resultant list is an execution trace. This execution trace is then executed within the execution environment, updating and progressing the state of the blockchain.

Note that intents are never executed, they are solved; transactions are executed. Some refer to this process as settlement; an intent is settled when its solution has been committed via an execution trace being executed.

With that general outline in mind, let's focus on intents in finer detail.

Intents in Finer Detail

The big question: what is an intent? Below are a few (isomorphic) definitions — feel free to pick one that clicks for you:

1. An intent is a constraint on the state transition function.
2. An intent expresses an end state, whereas a transaction expresses a delta.
3. An intent is a specification for some off-chain work to be done (in exchange for compensation).

Some other blog posts you may have seen out in the wild might have you believe that an intent can be literally anything — arbitrary text codified on-chain to represent any arbitrary user desire. This is not true for us at Essential. Very concretely, an intent applies constraints to the set of transactions that could possibly be in the next execution trace.

1. An intent is a constraint on the state transition function?

Let's take a little detour into the world of Computer Science theory. If the following is mumbo-jumbo to you, don't worry — it is not necessary for understanding the nature of intents. It's merely one of a few definitions that may work for you.

I've included a pronunciation guide to help your inner monologue:

• $\sigma$ - lower case sigma
• $\Sigma$ - upper case Sigma
• $\times$ - cross product
• $\delta$ - delta
• $\in$ - "is in the set of", or "is in", or even more tersely, "in"

The term "state transition function" comes from the notion of state machines, which are closely associated with automata theory and Turing machines. In automata theory, there is a lookup table that maps the current state ($s_n \in S$) and input ($\sigma \in \Sigma$) to a destination state ($s_{n2}$). The state transition function is commonly represented as the Greek letter $\delta$, and is therefore more formally described as as $\delta: S \times \Sigma \to S$. In Turing machines, there exists an analogous concept.

So, $S$ here is the totality of all possible blockchain states, including the one where you have 1,000,000 Eth, and the one where you have 0. This $S$ is doing a lot of work, so make sure you understand it. In our context, $S$ is the set produced by the cross product of all state domains on an entire blockchain. This is a large set.

Recall combinatorics. Each state element in Ethereum has $2^{256}$ potential values. A smart contract can have $2^{256}$ of these values. That's $2^{512}$ potential states for a single smart contract. In Q1 of 2022 alone, 1.45 million smart contracts were deployed to Ethereum. So, conservatively, the cardinality (size) of $S$ is... really, really big.

$\Sigma$ is what is being calculated by solvers. The job of an intent is to constrain this function to a tractable search space, and provide an objective function for evaluating its own satisfaction of elements (potential states) within $S$. We call elements of $S$ that are being proposed as solution candidates end states.

This is precisely the novelty of Yurt, our upcoming intent expression DSL. Yurt provides a way to construct intents that are naturally gradable — that is, they can be evaluated along with an end state to produce a satisfaction score. Yurt accomplishes this by allowing the programmer to introduce individual constraints, or build abstractions of constraints, powerfully cutting down the search space.

2. An intent expresses an end state, whereas a transaction expresses a delta?

Yes! Another way to think about this is in terms of what we are expressing. A transaction, in traditional blockchain technology, is a delta. If you're unfamiliar with the word delta in this context, it just means a "change". The delta between 2 and 5 is +3, for example.

This inherently has issues. With the transaction-based model, you are signing a blank check for your underlying preference to be applied to any start and end state. If you read the above section on state transition functions, a transaction is an element of $\Sigma$, while an intent is an ordered subset of $S$.

An intent expresses a set of desirable end states, ordered by preference. As a user, you are incentivizing the protocol to maximally satisfy your goals, not maximally leverage your blank check.

3. An intent is a specification for some off-chain work to be done (in exchange for compensation)?

An intent describes where you want to be, and it is the job of the solvers to figure out how to get you there. Don't feel bad for them; they're compensated by your fees. They construct transactions, as a service to you, off-chain. In this way, intents can be thought of as a specification for off-chain work to be done. It is like proof-of-work, but the work is actually being used to push forward the system.

TL;DR

Intents are a new and useful abstraction for interactions with a ledger system. Intents are solved for, and then those solutions are executed, or settled (n.b. intents themselves are never executed).

An execution trace is a sequence of ordered transactions that, after execution on some start state, produce an end state. There exists an objective function that takes an intent and an end state as input and produces a score as output. This score is how we know the optimality of an execution trace, and it is how intent-based protocols may select the most optimal solution to include in the block.

About Essential

Essential is building intent-based infrastructure & tooling to accelerate the transition from value extraction to intent satisfaction. With a growing team of global contributors building several core pieces of intent-centric infrastructure, Essential is committed to supporting ecosystem-wide composability to ensure the intent paradigm reaches its full potential to minimize extractive behavior and maximize user satisfaction.

To join us on this journey and contribute to the intent-centric future, follow us on Twitter and stay tuned for future updates.