Essential: The First Declarative Blockchain

As the first general-purpose blockchain, Ethereum’s launch in 2015 heralded a new era for web3, advancing blockchain technology from a mere peer-to-peer payment system to a fully distributed state machine capable of supporting complex logic and applications. In the decade since, thousands of general-purpose blockchains have been built on top of these foundations, promising new levels of scalability, customizability, and usability.

Despite the progress and innovation that these projects represent, they remain limited by their adoption of the imperative programming paradigm.

Today, we introduce Essential: the first declarative blockchain.

Blockchains Have an Execution Problem

Programming can broadly be categorized into two paradigms: imperative and declarative.

• Imperative programming expresses how problems should be solved, through the specification of algorithms which contain step-by-step instructions. State is updated by executing these instructions (e.g. fetch this data, then perform this operation, then this one).
• Declarative programming describes what a program should accomplish, rather than how. A declarative program only needs to specify the expected result and core logic, without having to direct the program's control flow.

Every general-purpose blockchain since Ethereum has used the imperative programming model, and it remains the prevailing paradigm for framing problems in the blockchain space. Because they rely on the linear execution of code to achieve state changes, the sole method for interacting with these blockchains is via imperative instructions (e.g. transactions and smart contracts).

Meanwhile declarative programming, while well-understood in the field of computer science, has thus far been neglected as a paradigm for blockchain architecture. However, we are now seeing a wave of interest in declarative approaches due to the many benefits the paradigm offers.

What's Wrong with Imperative Blockchains?

In order to justify a new paradigm, we should explore the status quo and its shortcomings. Consider the differences in how the two main programming paradigms treat instructions vs. outcomes:

• Imperative - Always follow the instructions, regardless of the outcome.
• Declarative - Always output a valid outcome, without the need for instructions.

In imperative systems, there is a tension between the network and its users. From the network’s perspective, the priority is achieving consensus over state. A simple way to achieve this is to agree on a common framework (e.g. a VM) for computing network state. With the imperative approach, given an initial state and a list of transactions, any node can compute the next state according to the rules encoded therein.

However, when it comes to the practicalities of why most people use blockchains, expressing interactions in the form of instructions rather than outcomes is clunky and unintuitive. From a user’s perspective, the important factor is the outcome they get, not how it is achieved—but this isn't how today's blockchains are designed.

This trade-off of adopting an imperative design is summarized succinctly by James Prestwich:

“[Imperative] smart contracts prevent us from knowing the outcome of a transaction before it is confirmed. Its state changes are unknown before the transaction is included in a block. By signing the transaction, the user has consented to whatever state changes the contract defines, without knowledge of the outcome. When users call a contract they entrust their funds to it with no guarantee of good behavior.

"Given that the entire point of a blockchain is to create and update a state securely, smart contracts are intuitively problematic. Users deserve to know exactly what the transaction will do before they sign it. Anything else cedes partial control of user funds to miners or other users. It dilutes the permissions set on the shared state, which diminishes the usefulness of the chain.”

This uncertainty is unambiguously bad for users, resulting in a long list of negative consequences. We've all felt the fear of refreshing an Etherscan page waiting to see if a trade went through, but that's just the surface. At best, you might face a failed transaction and waste some money on gas. At worst, malicious smart contracts may go unidentified until they've drained your funds.

The most common UX complaints about blockchains—uncertain outcomes, failed transactions, MEV, high slippage—are actually criticisms of the underlying imperative architecture.

But it doesn't have to be this way. Blockchains don't need to rely on in-protocol execution to achieve consensus over state.

Blockchains are Approaching Execution Wrong

As well as providing poor UX and sub-optimal outcomes, relying on the imperative execution-based model leads to inevitable market inefficiencies and rent-seeking.

The modular blockchain paradigm promised to improve scalability by decoupling execution from the rest of the blockchain stack and outsourcing it to specialized layers. The promise was that these layers could optimize for fast, scalable execution without having to worry about decentralization. By enabling proofs on the underlying L1, they could outsource security to the parent chain and operate with lower security guarantees on the execution layer itself.

Many believed that L2 fees would become negligible as innovations on the consensus and DA layers opened up cheap blobspace. The idea that execution would become the next bottleneck led to a massive focus on faster models for execution, especially parallelization, as the primary method of scaling throughput.

This narrative has not panned out as expected. In practice, demand for execution is far outstripped by demand for outcomes. The imperative approach conflates the two, when in fact, outcomes are the real bottleneck.

The Outcome Bottleneck

Sequencers on L2s create a form of artificial scarcity when it comes to execution, such that they can convert demand for an asset into demand for priority ordering, extracting value from asset holders. If a given outcome (e.g. buy Asset A at Price P) has limited availability, demand can easily outstrip supply, no matter how much execution an L2 can support.

In an efficient market, when demand outstrips supply, price moves in favor of the supplier. But on imperative execution layers, sequencers wield monopolistic control over how supply and demand are allocated. With the power to decide which transactions get included and in what order, they can extract value that should be accruing to the seller.

Instead of charging fees that reflect the economic reality of their costs (i.e. the cost of blobspace and computation), sequencers can extract arbitrarily high fees due to their position as an intermediary. This not only results in worse outcomes for all users, but it also decreases economic activity.

The imperative approach values demand for execution over demand for the results of that execution—i.e. outcomes. This undermines the promise of modular scalability. Instead, we need a system that optimizes for outcomes.

The Declarative Approach: Igniting Change

If the imperative paradigm imposes so many limitations on users, developers, and networks themselves, why aren’t we using a different approach?

We aren’t the first people to ask this question. As early as 2018, influential members of the web3 community were proposing an alternative: the declarative approach. Despite having been discussed occasionally over the years, the concept only started to gain significant traction in early 2023 with the introduction of the primitive of “intents”.

Although the term has taken on many definitions, the core principle of intents is that they allow users to sign over their intended interaction in terms of outcomes (declarative) instead of instructions (imperative).

Whereas transactions pre-define how and where an on-chain state transition will take place, intents are “journey-agnostic”; as long as the desired outcome is reached according to the rules set by the user, the pathway to that outcome is inconsequential.

By adopting declarative principles, the intent primitive promises to bring major improvements to user experience and outcomes. Although still in its early stages, the concept has already been applied across several different verticals, from swaps to bridging, to much success. This is borne out in the numbers; already, over 25% of Ethereum’s orderflow originates from intent-based projects.

Clearly, a shift toward declarative ideals is a shift in the right direction. But when we look closer, a major flaw emerges in current production applications that leverage intents. Conceptually, these applications leverage declarative principles to enable users to express outcomes instead of instructions. However, in practice, these projects are unable to provide guarantees about outcomes, contrary to their stated declarative approach.

Their approach is to outsource transaction creation to specialized third parties (solvers) who attempt to most closely approximate the user’s preferred outcome. The actual fulfillment of those outcomes occurs via a lossy conversion back to an imperative format (i.e. a transaction), and execution of that transaction on an imperative state machine.

Despite taking steps toward a declarative approach, current intent projects continue to be limited by their reliance on imperative blockchain frameworks (i.e. the need to settle on existing imperative chains) to fulfill users’ intended outcomes. They fail to fully adopt the declarative paradigm, instead reverting to imperative principles when it comes to actually including user outcomes as new state.

A New Approach: The Declarative Blockchain

It is clear that declarative principles hold significant promise for improving the way we build, use, and interact with blockchains. But rather than just applying them to the pre-transaction stage, we should be applying them all the way down at the state machine level.

In order to achieve this, we introduce a new concept: the declarative blockchain.

What is a Declarative Blockchain?

A declarative blockchain is a blockchain that leverages constraints to achieve state updates without the need for execution.

(In contrast, an imperative blockchain is a blockchain that relies on a common execution environment to achieve state transitions.)

The definition of "declarative blockchain" introduces two key axes:

1. Does it leverage constraints?
2. Does it achieve state updates without the need for execution?

1. Constraints On State

Because current intent projects output transactions to be settled via imperative execution, they conceive of intents as constraints on state transitions. In Essential, intents exist not as constraints on the state transition function, but as constraints on state itself. Leveraging constraints on state is a critical property of declarative blockchains, as it allows developers and users to “constrain” the solution space of acceptable (and optimal) outcomes.

To enable this, Essential’s architecture is based on constraint programming, a subset of the declarative programming paradigm. Constraint programming is an extremely ergonomic approach to expressing and enforcing outcomes within state machines, and is especially useful for solving large-scale combinatorial problems—for example, finding a series of optimal state transitions among a complex on-chain solution space.

When a user submits an intent, they are declaratively outlining a set of variables as well as constraints on those variables, narrowing down the space of feasible solutions. Along with constraints, users can specify an objective utility function, which represents their preferences and preference ordering.

Solvers then attempt to solve a constraint optimization problem, which consists of maximizing the user’s utility (as described in the objective function outlined within the user’s intent). Solvers are not just trying to satisfy the user’s intent, but to maximize the user's utility with respect to their objective function. Put more simply, solvers compete to answer the question: Given state X and objective function F, what new state Y maximizes the user’s satisfaction?

Because Essential’s state machine is itself declarative and constraint-based, no state transition may be included if it does not satisfy the user’s intent. Unlike imperative blockchains, there is no risk of state drift causing unintended outcomes or failed transactions.

2. State Updates Without Execution

The second core property of declarative blockchains is that they achieve state updates without execution. This is a nice property of constraints: “Constraints differ from the common primitives of imperative programming languages in that they do not specify a step or sequence of steps to execute, but rather the properties of a solution to be found.”

Achieving state updates without execution is perhaps the holy grail of blockchain protocol design. Above, we established that in-protocol execution (i.e. the processing of step-by-step instructions) is a highly limiting property of imperative blockchains.

The “executionless” property of declarative blockchains enables the most costly part of general-purpose blockchains (execution, and consensus thereover) to be removed without sacrificing functionality or verifiability. In fact, it makes verification of state transitions trivial, due to the nature of constraint-based problems (hard to compute, easy to verify).

The Declarative Landscape

Many blockchains exist that fulfill one of these criteria, but Essential is the only blockchain that:

• ✅ Leverages constraints; and
• ✅ Achieves state updates without the need for execution

This makes Essential the first declarative blockchain.

To bring the benefits of the declarative paradigm to as many users and developers as possible, the first instantiation of Essential will be deployed as an optimistic rollup on top of Ethereum.

The Essential Advantage

Adopting a declarative blockchain design offers countless benefits for users, developers, and the web3 space as a whole.

Essential Tech Stack

In order to achieve these benefits, there are three central pillars to Essential’s technology stack:

1. Executionless blockchain
2. Constraint-based DSL
3. Solver network

Executionless Blockchain

First, Essential delivers a leap forward in bandwidth with our executionless blockchain. Users and applications are able to directly constrain state by submitting intents in the form of constraints, which fall into the class of problem: “hard to compute, easy to verify”. We move the “hard to compute” part off-chain, while the “easy to verify” part remains on-chain. As a result, Essential can deliver significantly more throughput while being optimized for cheap, easy fraud proofs.

Constraint-Based DSL

Second, our “programmable intent” language (”Pint”) provides a seamless developer experience and built-in security and scalability. Pint abstracts away all the usual blockchain idiosyncrasies developers grapple with when interacting with imperative blockchains, allowing them to describe their business logic while leaving the computational logic to a dedicated solver network. This makes it easier for developers to write more complex applications more simply.

Solver Network

Finally, Essential leverages a network of specialized solvers to find and propose optimal state updates. Solvers compete to provide the best solutions to user-submitted intents across the entire on-chain (and off-chain) solution space, and only the best solutions are included, meaning users get the best outcomes, every time.

A New Era of Independence

Since their invention, blockchains have promised to deliver sovereignty, independence, and collective power to their users. As the technology has evolved, we have had to battle many of the same market forces and power dynamics that blockchains were originally designed to circumvent.

Imperative blockchains brought us decentralized, general-purpose computing. But they also brought more extractive intermediaries, advanced types of MEV, convoluted supply chains, competition for orderflow, rent-seeking "benevolent" dictators, malicious scammers, and more.

To bring down extractive intermediaries and return power to the collective, we must design around the centralizing forces that allow these phenomena to emerge in our systems. Declarative blockchains are the next step in building decentralized systems that bring true independence.

Will you join us?

Get Involved

• Follow us on Twitter
• Join our Discord
• Sign up to stay updated 👇