Imperative Pitfalls Pt. 1 (Sub-Optimal Outcomes)

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.”

Consequences of Imperative Architectures

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.