Where and when do “execution,” “settlement,” and “finality” happen on Ethereum: technical understandings

17 Jul 2023 9 min read Crypto regulation

By Mikołaj Barczentewicz (0xMikolaj)

Thanks to Barnabé Monnot, Caspar Schwarz-Shilling (EF RIG), and Quintus Kilbourn (Flashbots) for their comments and discussion.

This work is supported by a grant from the Ethereum Foundation (more information about the larger research project).

The concepts of (transaction) “execution” and (block, transaction) “finality” have technical meanings in the Ethereum protocol. (For “execution,” see, e.g., the Yellow paper; for “finality,” see, e.g., the Ethereum 2.0 annotated spec). However, we often need to discuss “execution” or “finality” in other contexts. For example, when we want to understand the economic nature of what happens with Ethereum transactions. Or when we want to paint a legal picture of who and when executes a transaction. The technical understandings may be helpful in those other contexts, but they are not definitive, and we should avoid falling into the trap of unreflective word usage. Moreover, as I show here, the established technical understandings do not include clear answers to questions important from non-technical perspectives (economic, legal). Especially, there is no clear answer to where and when execution happens.

Lawyers want to know where and when technical/operational execution and settlement/finality happen. It’s essential to have a thoughtful answer to those questions. Otherwise, we may end up stuck with suboptimal responses that don’t correctly consider the characteristics of networks like Ethereum.

One of the reasons why we may need to know where and when execution happens is that EU MiCA regulates providers of “crypto-asset services,” including “execution of orders for crypto-assets on behalf of clients.” Could it be that any RPCs, nodes, or validators individually provide “execution” services (leaving aside the question of whether they have “clients”)? Or maybe we should say that, if anyone, it is Ethereum, a decentralized network/protocol that executes transactions in any meaningful sense. (The latter could mean that EU MiCA does not regulate this “service,” as MiCA excludes the “fully decentralised” provision of services).

My purpose is twofold: (1) to attempt to summarise and clarify the technical understandings (especially in how they relate to when and where transaction execution and settlement/finality happen) and (2) to outline how the technical understandings may relate to economic and legal ones. This short text only covers the first question, and I intend to tackle the second question in a follow-up.

The ghost of the Ethereum machine: the Ethereum Virtual Machine as an abstraction

The paradigmatic technical understanding of transaction execution (e.g., in the Yellow paper) is as state transition within the Ethereum Virtual Machine (EVM). But the EVM is, in a sense, an abstraction. Execution clients run concrete, local “EVMs” (or, should we say, EVM simulations?), but there is no single, global, canonical EVM that someone is running on some concrete machine (or group of machines) in the sense that we could say what its current state is and what it’s doing right now. There is, however, a global, canonical blockchain and its global, canonical state. 

“The blockchain’s canonical state” may be understood in two ways: by reference to the fork choice rule (LMD GHOST) or to the finality system (Casper FFG). Or, in different words, as Patrick McCorry might put it, by reference to two different kinds of finality — “weight-based” and “absolute” (see also this from Georgios Konstantopoulos and Vitalik Buterin):

The separation of liveness and safety has led to a two-tier system for considering whether a block is final and irreversible:

  • Weight-based finality. All Validators continuously apply the fork-choice rule to decide which blockchain fork should be considered the canonical chain. The likelihood of the blockchain fork being replaced decreases as votes accumulate for it.
  • Absolute finality. All Validators collectively agree to a checkpoint and all blocks prior to it are considered irreversible.

We only know what the (global) EVM “did,” but not really what the EVM “is doing right now.” We know what the EVM “did” once the network achieves finality (of either kind). But because the canonical state depends on consensus, we cannot say what the EVM “is doing right now.”

We can tell ex-post stories about what the global EVM did at any given time (or during any given past Ethereum slot). Once the network reaches finality, we can say—concerning the finalized blocks—that the global EVM “went through” specific state transitions that led to the finalized state. But we should remember that we are speaking about an abstraction: a construct of the “ghost of the Ethereum machine.”

There is an additional nuance to the question of the choice of perspective from which to define the EVM and what the EVM has done in the past. The rules that determine the canonical history of the blockchain and its canonical current state may change over time. This happened multiple times in Ethereum’s history, e.g., due to the DAO fork in 2016 and the Merge in 2022. If we were to define the EVM only by referencing a set of rules constituting its technical specification, we’d say that such protocol changes kill the old EVM and create a new one; there is no continuity.

But we can give a unified narrative of the canonical EVM throughout time, allowing us to say that today’s EVM is the same entity as the pre-DAO fork EVM but changed (like humans change over time). To do that, we need first to choose what we see as the canonical history of the blockchain. Then, we can say that “the EVM” is co-constituted by all and only the rules (rulesets) accompanying this particular history. So if we see the current mainnet Ethereum as canonical, we could say that the current post-Merge EVM is continuous with the EVM both before and after the DAO fork. We’ll get a different answer (a different EVM) if we choose the “Ethereum Classic” history.

“Local execution” and “global execution” of transactions

Any execution client (a machine running execution client software like Geth) can simulate the execution of any transaction. Here, I will use “simulation of execution” and “local execution” interchangeably. 

“Local execution” of a transaction is not, or at least not necessarily, “global execution” (execution “by Ethereum”). 

Should we consider local execution by the validator selected as the proposer to also count as global execution?

True, the proposer is in a privileged position in the lifecycle of a transaction. The proposer locally executes (or not, see below) transactions to decide whether to include them in a block and thus not only include them in the proposers’ local view of the blockchain state but also broadcast the block to the network for all participants to include the block in their views. The proposers’ local execution is necessary for a transaction to be included on the blockchain. 

However, it seems a bit strained to say that “the global EVM” keeps jumping from the execution client of one proposer to that of the next proposer. This is strongly supported by the fact that, even if necessary, the proposer’s actions are insufficient for a transaction to be included in the (finalized) blockchain state. A proposed block could fail to become part of the canonical blockchain (according to weight-based or absolute finality mechanisms). Consider this example by Caspar Schwarz-Shilling: 

A block proposer locally builds a block (involving local execution) but releases the block too late for it to end up being part of the canonical chain. (The slot of this late block will globally look empty.) Clearly, this execution has local but no global meaning.

Proposers who accept blocks from external block builders, like in the MEV-Boost scheme, don’t even perform any local execution. Under MEV-Boost, block builders and relays simulate the execution of transactions while proposers blindly sign blocks. From the perspective of the local-global distinction, what the builders and relays do is not categorically different from what the proposers do when they build blocks themselves.

Global network-level execution of a transaction (execution “by Ethereum”) is an abstraction, like the EVM. Since Ethereum has a canonical (finalized) state, speaking of globally executed transactions is arguably only meaningful in the abstract ex-post sense, analogously to the account of the EVM presented earlier.

Execution by users

A different approach to transaction execution focuses on who submits (or signs) a transaction, i.e., on the user. (The situation may become more complicated if more general, pre-transaction (proto-transaction?) commitments like “intents” will become widely adopted.) Given the usually automatic, permissionless way in which transactions are included on Ethereum, it could be said that the agency in execution lies with the user.

Where and when is a transaction executed from this perspective? One possibility is that it is executed where and when the user submits the transaction to the network (e.g., by using wallet software). However, transaction inclusion is not always automatic. It is possible for a transaction not to be included immediately or at all (e.g., because it offers to pay too little in gas or because it is being censored by validators or other network participants).

Five understandings of transaction execution

We could attempt to categorize understandings of transaction execution like this:

  1. Execution by a user who signed the transaction.

Local execution by some node (execution client):

  1. Concrete local execution (or simulation) by an execution client (which is not 3).

Global execution “by Ethereum”:

  1. Concrete local execution by an execution client of a block producer (either the proposer or an external block builder in a proposer-builder separation scheme).
  2. Abstract execution defined by weight-based finality (fork-choice).
  3. Abstract execution defined by absolute finality.

In “concrete” cases, we can say when and where (on which computer) the execution happens. In “abstract” cases, execution is understood differently, as something Ethereum “has done,” but without an answer to “where” and with some ambiguity as to “when.” In cases (4) and (5), we could try to answer “when” in three ways:

  1. There is no meaningful sense of “when” a transaction is executed.
  2. Execution occurs at the time related to the proposer’s actions (e.g., time of local execution, time of broadcasting the signed block to the network).
  3. Execution occurs when the block is finalized (for either of the finality mechanisms).

Sidenote: strictly speaking, no single discrete (4) (weight-based finality) event exists before (5) (absolute finality). Blocks accumulate votes over time, making it less likely that a block will not ultimately be part of the canonical chain.

“Protocol execution”

Barnabé Monnot suggested a complementary way of thinking about execution, not of transactions, but of the protocol. On this view, “[t]he Ethereum protocol delegates its execution to a network of validators.” The protocol uses rewards and penalties to incentivise validators to “ultimately produce a blockchain, which hopefully matches what the protocol attempts to induce, e.g., a re-org-free, censorship-free, maximally welfare-achieving chain of blocks.”

What kind of activities constitute protocol execution? This, of course, depends on how broadly we define “the protocol.” If, following Barnabé’s distinction, the protocol is only defined by what it “sees” (i.e., what it can directly reward or punish), then the activities in question will chiefly include the validator duties. On a broader understanding of what the protocol may “care about” without “seeing,” other aspects of network participant behaviour may also be included (e.g., the speed with which they perform their validator duties).

To be continued in a second part outlining how the technical understandings may relate to economic and legal ones.


If you’d like to be notified about my future crypto work, you can subscribe to the CryptoFinReg.org newsletter.