Given the nature of the decentralised domain, building such an economic system has come with many unique challenges which generally are not prevalent in the domains of centrally-planned and mixed economies that we are more familiar with today. Given the unique setting, we find that many of the proposed solutions and mechanism design approaches adopted by Ethereum consider aspects of both neoclassical and complexity economics. This demonstrates the sort of “uncharted waters” we are dealing with here, therefore it will be a goal of ours with this article series to help describe Ethereum’s economic system and highlight some of the key features that characterise it in the novel, decentralised setting. While we will not go over the economic system in its entirety, a higher level overview of what it entails will be covered later in this introductory section.

What is this article series about?

This article series is intended to describe the subsystem of Ethereum responsible for allocating and distributing resources - a task that is universally important in all economic systems. While this topic may seem highly-specific, you may find that it answers a lot of different questions about Ethereum and how it actually works beyond the basic picture of “its a blockchain”.

To understand how Ethereum manages this task we first need to understand the nature of the resources being distributed in the system, how costs are allocated to them, and finally how they are paid for. This series is therefore structured into three parts:

1. Blockchain Resources: The nature of the resources utilised by Ethereum are identified along with useful abstractions.

2. Resource Pricing: How costs are assigned to different resources and patterns of resource usage are described.

3. Transaction Fee Mechanism: How transaction fees are determined and to whom payments are directed are described.

Defining an economic system

Before starting with this article series, lets go over a basic definition of an economic system:

An economic system is a system of production, resource allocation and distribution of goods and services within a society.It includes the combination of various actors, decision-making processes, and patterns of consumption that comprise the economic structure of a given community.

With this context, there are a few details we can identify that characterise an economic system:

• System of production <1, 2>: How and how many resources are produced for usage.

• Resource allocation <2>: How is a resource type assigned across different use cases.

• Distribution of goods and services <3>: How are deliverables produced from resources made available to consumers, how are these deliverables paid and who gets paid for them.

• Various actors <3>: Who are the actors involved and what roles do they play in the system.

• Decision-making processes <1,2,3>: How and what are the decisions that were made around system of production, resource allocation, and distribution of goods and services.

• Patterns of consumption <2>: In what manner are resources utilised (directly related to distribution of goods and services).

While the above is by no means a comprehensive blueprint for an economic system, it gives us a starting point to reason about Ethereum.

Ethereum as an economic system

As mentioned earlier, this series is split into three sections: blockchain resources, resource pricing, and the transaction fee mechanism. The diagram below illustrates where the above-mentioned economic system characteristics will be discussed in the relevant sections, contributing towards giving a full picture of how two sub-components (resource pricing component, transaction fee mechanism) help manage the distribution of blockchain resources in Ethereum.

Identifying system components

While there are three sections to this article, the first section is different from the two that follow because it is purely describing the blockchain resources which drive the economic system. The following two sections (resource pricing, transaction fee mechanism) describe crucial system components that help realise the characteristics of the economic system, each also consisting of their own design goals which will be discussed later on. We will refer to these two system components collectively as the resource allocation system. The rationale for this shall be made apparent shortly as it allows us to group specific functionality under one label within a more complex global system model.

Defining the resource allocation system of Ethereum

So far our understanding of the resource allocation system introduced above is limited to knowing that it consists of two components, therefore we will now explicitly describe it:

The resource allocation system is a subsystem that integrates two different components, each serving unique purposes. It effectively links the resource pricing component together with the transaction fee mechanism.The interaction of these two components with each other aims to produce specific outcomes in service of economic efficiency as a result of more careful management of available blockchain resources.

Lets briefly go over these two components that are a part of the resource allocation system:

Resource Pricing: Determines resource costs of transactions

This component can be understood as a system responsible for metering resource usage imposed by transaction processing, therefore determining the total resource costs associated with each transaction. We use the term “metering” because transactions can be broken down into chains of lower-level operations, each with its own individual resource costs. The cost of lower-level operations are defined by a specification known as the resource pricing policy. With this framework, the resource pricing component utilises the policy, along with a systematic approach, to accurately assess and aggregate individual costs and determine the total resource costs of a transaction. A key design goal of the resource pricing component is to accurately price the impact of all transactions by reflecting the cost overhead that users incur on the rest of the network. To achieve this goal, the component must assign costs to transactions that closely align with the true social costs generated by their activities.

Transaction Fee Mechanism: A market mechanism for transactions which decides which transactions get included and how much users pay for them

The transaction fee mechanism is a system that users and block producers interact with where the resulting outcome is a block being produced consisting of a list of executed transactions. In Ethereum, the TFM guides how the finite amount of blockchain resources made available for distribution in a block get allocated and involves interactions between a block producer and users within every block period (every 12 seconds). It is also where transaction fee payments are made by users where such payments are a function of the total resource cost of their transactions (produced by the resource pricing component) and a bid (incentivising for sale of resources which translate to transaction inclusion). Because block producers are the actors who ultimately perform the task of creating a block and hence choosing which transactions get included (in anticipation of revenue), we characterise this interaction between users and block producers as a principal-agent problem where block producers perform actions on behalf of users. The transaction fee mechanism therefore serves to align the interests of principals (users) and the agent (the block producer) in such a way that honest interaction with the mechanism leads to the optimal outcome for both these groups of self-interested actors. The result therefore is that a higher level of economic efficiency is achieved through mechanism design.

Other factors that impact Ethereum’s economic model

To better understand where the resource allocation system defined above fits in, consider the following conceptual model that is a more detailed representation of Ethereum’s economic system which considers other factors that influence its inner workings:

Along with the resource allocation system, we have other areas of influence that impact the economic balance of Ethereum as illustrated in the conceptual model such as the monetary policy, cryptoeconomic security, and macroeconomic influence. These influences on Ethereum’s economic system will not be covered in this blog post, but here is what they roughly describe:

• Monetary Policy: Aspects that affect Ethereum’s circulating supply on the native asset ETH, such as validator rewards and burning (the burning of ETH is mechanism design decision related to the implementation of the transaction fee mechanism but an effect of this feature is experienced within monetary policy - more on this later).

• Cryptoeconomic Security: The consensus protocol influences validator rewards and network security which impacts the economic dynamics of Ethereum.

• Macroeconomic Influence: Describes the effect that external market factors may have on Ethereum’s economic system, such as demand for ETH, price volatility, regulatory risk and much more.

Its worth mentioning that all these mentioned areas within Ethereum’s economic model do interact with one another, however we will be focussing more on the interactions between the subcomponents of the resource allocation system in helping Ethereum achieve its economic efficiency goals as well as its decentralisation properties.

So now that the tone has been set for this article series, I hope you are ready to start diving into what I hope will be an informative read. The goal will be to convince you of how all these interconnected parts come together to produce some incredible outcomes - it is testament to how interdisciplinary innovation has the potential to change the way we do things. While this will be fairly technical, I hope to leave you with a lot of food in a similar way to how these topics continue to impact me and my perspective.Anyways, lets get started 🫡.

Prologue: The Tragedy of the Blockchain Commons

“Therein is the tragedy. Each man is locked into a system that compels him to increase his herd without limit – in a world that is limited. Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons”

— Garrett Hardin, The Tragedy of the Commons

Ethereum, by nature of its design, is a decentralised economic system. There are strong reasons to emphasise this detail repeatedly because this characteristic of being “decentralised” is only made possible by ensuring the ability to permissionlessly join the network and perform crucial roles that maintain its operation, remains accessible.

An important requirement for having such a property is to ensure the resource requirements to perform such duties remains modest and predictable. Without careful planning that considers this goal, we risk Ethereum losing its valuable properties afforded by decentralisation.

However at the same time, an economic system must be able to operate efficiently to serve those who participate in it, and must demonstrate elements of sustainability and reliability as a medium of commerce. Given this understanding, the ideal outcome is that we maintain the decentralised properties of the system (by bounding resource consumption) but try to make use of the available resources as efficiently as possible and maximise social surplus. Given the permissionless nature of how Ethereum works, there are various agents whose strategic behaviour will ultimately influence how well these resources are put to work.

Therefore designing and implementing the mechanisms of Ethereum which coordinate how these resources get utilised is of great importance. If the mechanisms in place tasked with doing this are not well designed, we risk Ethereum experiencing a “tragedy of the commons” problem.

The tragedy of the commons describes a scenario in which access to a common pool of resources (a public good) is not regulated efficiently by a mechanism.

The consequence of this lack of planning can result in excessive resource consumption, poor incentives to motivate public participation in maintenance or improvement of the system, and encouragement of participation that favours short term gain over long term sustainability (myopic behaviour).

The “Tragedy of the Commons” risk can be directly applicable to the resource allocation system of Ethereum because it demonstrates that if we implement parts of this system poorly, we risk upsetting the incentive balance between various types of participants in the network which can undermine Ethereum’s security, efficiency and accessibility. In addition to this, inadequate pricing of resource usage can contribute to abuse of shared resources.

For us to prevent the tragedy of the commons, we must design the resource allocation system in such a way that the manner through which resource access is managed in Ethereum is fair, long-term sustainable, and economically productive.

To achieve this, we identify some core principles that guide the design and operation of the resource allocation system that seek to prevent the risk of falling into the “tragedy of the commons” problem:

• Accurate resource pricing: Ethereum must have a system that is capable of charging users as close as possible to the social costs associated with their transactions. In order to do so, we must internalise as much of the external costs associated with transactions as possible to ensure that users bear the full cost of the burdens that having their transaction included on Ethereum has on the rest of the network and hence the shared blockchain resources.

• Economically efficient TFM: Ethereum’s transaction fee mechanism should drive optimal market outcomes by providing both principals (users) and the assigned agent (block producer) with useful economic signals and tools to express preferences. The TFM should provide transparent and timely information about the current market-clearing price so that users can decisively express bids for their transactions. On the other side, the TFM should be effective at informing the block producer about how best to maximise their revenue when building a block.

• Incentive-compatible TFM: Ethereum’s transaction fee mechanism should be incentive-compatible in such a way that principals (users) and the assigned agent (block producer) are incentivised to act honestly and according to the prescribed rules of the mechanism. An incentive-compatible TFM should align the incentives of both users and block producers in such a way that their dominant strategies to strictly increase their respective utilities is to act truthfully with the mechanism, demonstrating a social-welfare maximising equilibrium. This equilibrium reflects an achievement of a socially optimal outcome where no other strategic deviation will strictly benefit either of these participants more than interacting in truthful manner, therefore making the economic system of Ethereum as efficient but fair as possible.

There are, of course, much more considerations that contribute towards the prevention of the tragedy of the commons (e.g. governance mechanisms, scalability solutions, consensus protocol upgrades), but these are somewhat external to the scope of the resource allocation system and what job it has within Ethereum.

The core principles above therefore describe some of the key goals we wish to satisfy with the design of the components of the resource allocation system. Some of these goals are even dependent on the effectiveness of others, for example, accurate resource pricing guarantees that transactions costs are assigned fairly and reflect the impact they have on the network. The implementation of resource pricing, which aims to capture all dimensions of costs around transaction processing, therefore impacts how well the economic allocation outcomes guided by a transaction fee mechanism actually are. This demonstrates how accurate resource pricing is a pre-requisite to ensuring a more economically-efficient and fair transaction fee mechanism.

Having described how important these core principles are, we will observe how many of the engineering design decisions within Ethereum reflect this strong desire to be in line with these principles. In a future article, we will also see what future upgrades are actively being researched and proposed to further improve Ethereum’s resource allocation system.

Part 1: Blockchain Resources

In this section, we will familiarise ourselves with the concepts of nodes and what part they play in the blockchain. We do so in order to get a good understanding of what what sort of tasks they actually carry out and the underlying computational resources required to do so. These are important details to understand because they lay the groundwork for later introductions to matters of resource pricing.

By understanding the tasks that nodes perform and the computational resources they consume in the process, we gain valuable insight into the costs involved in running Ethereum. This knowledge, in turn, helps us comprehend why and how certain decisions around the pricing of these resources are made.

Nodes (from first principles)

Lets start off by defining what we mean by the term "node":

A node describes a computer that participates in a blockchain network.

In decentralised blockchains, nodes operate independently, maintaining and updating their own current view of the blockchain with help of the protocol specification (being enforced by node software) and P2P network communication. Nodes receive and broadcast messages engaging in “information gossip” upon which the blockchain protocol is capable of making these independent nodes converge on a canonical view of the network.

From this above description, we can describe Ethereum nodes in greater detail.

An Ethereum node describes a computer that participates in its blockchain. It runs Ethereum client software which implements the required functionality (which follows the protocol specification) to participate and interact with other reliable nodes in the network.

To keep this blog post as simple as possible, we consider an Ethereum node as a combination of its consensus and execution client and will not be referring to these parts individually unless specified.

An Ethereum node performs various tasks to maintain the operation of the blockchain, including participating in distributed consensus as well as engaging in information gossip, among many other crucial jobs.

From our earlier description about blockchain nodes, we were made aware that nodes are in fact independent and are responsible for maintaining their own local copy of the blockchain and participating in network communication with other nodes for the discovery of new information. Therefore, Ethereum can be thought of as a decentralised network of its nodes**.**

Ethereum also possesses the characteristics of being both a permissionless and trustless network. By this we mean:

• Permissionless: Anyone is able to run a node and participate in the network.

• Trustless: A consensus protocol ensures all nodes can trustlessly agree on the current the view of the blockchain history, sequence of valid transactions to execute next, as well as the result of such execution. Nodes assert correctness by performing local computation and comparing their results to what was provided over the network (e.g. Merkle root assertions).

We will not be going through how the consensus protocol works in Ethereum. All that is relevant to know going forward in this blog post is that it is responsible for ensuring nodes come to agreement about the global ordering of transactions from network inception as well as the result of executing them in that order.

Now that we have covered all the above information around node functionality in Ethereum, we can start to practically think about how resources are expended by nodes.

Computational Resources

A node depends on a variety of hardware resources, including CPU, RAM, disk, and network bandwidth, to perform its functions:

These resources are heterogeneous, each differing in their characteristics and serving unique roles within the operation of the node at a low-level. They are also orthogonal in nature, meaning that changes in one resource do not directly impact the others.

These resources being heterogeneous in nature basically describes that each of these resources serves a distinct purpose and has its own specific properties and limitations. We can point out these different purposes in very brief manner below:

• CPU: Responsible for processing instructions. Typically measured by percentage of utilisation.

• RAM: Stores data that needs to be readily accessible. Typically measured by capacity utilisation (GB).

• Disk: Serves as long-term storage. We consider overall capacity utilisation (GB) as well as read/write disk I/O interactions (MB/second).

• Network bandwidth: Determines the maximum rate of data transfer that a node can handle. Typically measured by data transfer rates (MB/second).

As mentioned above, we also described these resources as orthogonal in nature. This essentially means that the resources are independent of each other and therefore an increase or decrease of one does not directly influence the others. For example:

• Increasing RAM does not directly enhance CPU processing power.

• Expanding disk storage does not directly increase network bandwidth.

This orthogonality allows each resource to be considered and optimised independently. This detail plays an important role in some future mechanisms that are being proposed around fee markets and resource allocation.

Properties of Computational Resources

In understanding the roles and interplay of the various computational resources within an Ethereum node, two critical aspects demand our attention: their finite nature and the varying externalities they impose on the blockchain:

1. Finite nature of resources: Each computational resource is intrinsically limited. The capability of a node to process transactions, maintain the state of the blockchain, and communicate with other nodes is bound by these constraints.

2. Varying externalities: Beyond the intrinsic limitations, the use of these resources also carry different externalities which impact the broader network in particular ways. An example of this is how the growth of blockchain state and history imposes increasing burden on disk space and can lead to greater computational effort being required to access increasingly nested state data that needs to be fetched, modified, or appended to. Another example could be CPU utilisation for transaction processing which, in contrast, poses a more temporary burden.

It is important that we acknowledge that nodes have a finite amount of computational resources because this, in turn, emphasises the importance of efficiently provisioning resources to maintain the network’s functionality and robustness.

The second property of varying externalities is equally as important. Let us briefly describe what externalities are:

Externalities describe outcomes that affect parties who did not choose to be involved in a transaction or operation.These outcomes are not accounted for in the cost of the transaction/operation, which means they represent a form of market failure (remember this term, it will be an important one in Part 2).

Externalities can be either positive or negative. Positive externalities occur when actions have beneficial effects on third parties. You can imagine an example of this being if a transaction leads to increased network security or value for all network participants. Negative externalities describe outcomes associated with actions that impose costs on third parties. One of the most popular examples of this in Ethereum is that of transactions contributing to “state bloat” which describes an increase to the size of Ethereum’s state of which is a permanent effect. The consequence of this is that it leads to increased costs for all nodes in the network as they are required to maintain copies of state and apply updates to it that modify it further. Another negative externality that is often discussed is that of increased network congestion where the high volume of transactions lead to higher fees and therefore slower transaction inclusion for users.

An understanding of the externalities present in Ethereum is extremely important because it directly informs the design of the resource pricing component of the resource allocation system, a topic we dive into in Part 2 of this article. But before we dive into the mechanics of resource pricing, it is crucial that we shed light on the actual operations that nodes undertake.

Expenditure Classes

We are now going to take a closer look at some of the actual tasks/operations performed by nodes. These tasks, each with their own unique resource requirements, form the backbone of Ethereum’s functionality. They can be categorised into three main expenditure classes - networking costs, computation costs, and storage costs.

An expenditure class can be described as the categorisation of certain operations or tasks by the type of computational activity they engage in.

Understanding these expenditure classes not only deepens our understanding of a node’s role but also lays the groundwork for the discussions to follow on how these tasks, and their associated costs, influence the way we approach resource pricing.

As previously mentioned, our primary categories of operations/tasks fall into three key expenditure classes. Let’s look at each of these classes to get a better understanding of the specific activities they encompass:

1) Networking Costs

These are tasks related to the transmission and reception of data across the network, this includes:

• Initial blockchain sync: This is a once-off cost incurred when a node first joins the Ethereum network. The node is required to download all blocks and transactions from genesis to the current block, which requires significant bandwidth.

• Download: Nodes need to continuously download new blocks and transactions from the gossip network to stay in sync with the latest state of Ethereum.

• Broadcast: Nodes need to broadcast new transactions and new valid blocks it learns about.

2) Computational Costs

These are tasks that require computational processing, this includes.

• Transaction execution: This process, in its most basic form, entails updating the account balances during an ETH transfer from one account to another. Beyond this simple case, transaction execution commonly involves interactions with smart contracts (or deployments of them). Such interactions require access to memory and disk (to copy state to the EVM execution context) in preparation of execution. The execution of these smart contract invocation utilises both CPU processing power and RAM.

• Cryptographic operations: Task that requires the use of cryptographic operations to perform signature verification or generation of cryptographic hashes.

• Data serialisation: Tasks that require the use of encoding/decoding operations like Recursive Length Prefix (RLP) and Simple Serialise (SSZ).

3) Storage Costs

These are tasks involved with updating storage (history, state), this includes:

• Persisting state updates: After the execution engine of Ethereum (EVM) has executed a block’s transaction, the resulting updated state is written to disk.

• Block appending: Task that appends a new block to the blockchain. Whenever a new block is verified and added to the blockchain, it increases the history of the network. Blockchain history is “prunable” because you do not necessarily require parts of it (such as transaction bodies of previous blocks) once you have executed them to reach blockchain sync. Pruning is an important feature that makes the costs of running a full node feasible by reducing storage requirements and discarding of data that is no longer essential to the operation of the node.

Now that we have a better understanding of these expenditure classes and the kind of tasks that are conducted by nodes, it is clear to see how these tasks are diverse in nature and intrinsically connected to different types of computational resources. With the groundwork established, lets dive deeper into these specific tasks associated with each expenditure class and identify the particular computational resources that they consume.

The illustration above shows how we identified the computational resources that are utilised with the tasks belonging to each expenditure class. We can therefore make the following statements regarding the computational resource utilisation of each of these classes.

• Networking costs consumes bandwidth resources.

• Computational costs consumes RAM, CPU, disk resources.

• Storage costs consumes disk resources.

There are many more tasks that are actually performed by nodes in Ethereum to contribute towards continued operation of the network, however the tasks mentioned above represent the subset of activities that extrinsically depend on information produced by the resource allocation system. These tasks represent a collection of deterministic processes (described together as the block processing procedure) which carry out the underlying blockchain execution through which the invocation of these tasks with payloads are guided by the decisions made within the resource allocation system which itself is guided by its goal to adhere to its core principles.

The execution of these tasks therefore describe the realisation of the goals of the resource allocation system by virtue of nodes performing execution based on optimal inputs:

• Resource pricing component: Transactions are thoughtfully assigned computational costs, therefore users pay for the burden they have introduced to nodes to perform the tasks mentioned above.

• Transaction fee mechanism component: The transaction fee mechanism ensures that the transactions of a block were chosen in such a way that the execution of the block led to an economically-efficient outcome demonstrating that the utilisation of blockchain resources was done in the most optimal manner. The incentive-compatible properties of the mechanism also help ensure that the execution resulted in a socially-optimal outcome.

This therefore motivates why we have mentioned the various tasks above, these tasks each play a role in a specific procedure that uses the results of the resource allocation system (determination of the contents of a block) to perform execution and updates on Ethereum. The procedure being referred to here is called the block processing procedure and is performed by every single node part of the network to update the current view of the blockchain. In the next section we describe the steps taken in the block processing procedure made up of the tasks described above. Thereafter, we will walk through a computational complexity analysis of this procedure, assessing the computational resource requirements and unique resource consumption dynamics of each step involved. The goal in doing so is to get a good understanding of what factors may influence the implementation of the resource pricing component of the resource allocation system.

Computational Complexity of Block Processing Procedure

The block processing procedure describes a process involving a series of steps in which nodes in Ethereum process computational tasks to update the current view of the blockchain. This procedure is performed when a node receives a block over the network, therefore we can describe the carrying out of this procedure as an activity performed by nodes regularly as part of Ethereum’s operation.

The block processing procedure describes a procedure involving the carrying out of multiple steps in order to process a new block shared across the network. If the block is valid, the result is that the node executes the transactions and applies the results to update their current view of the blockchain.

At the end of the previous section we highlighted why the block processing procedure is relevant to the resource allocation system, this being that this procedure is extrinsically linked to it due to the fact that a block’s contents are determined by outcomes produced by the features of the system. Given the nature of this relationship, we seek to get a better understanding of how the computational resource demands of the block processing procedure can vary given the contents of a block.

In preparation of doing this, we will first get familiar with all the steps involved in this procedure which describe the sequence of tasks required to be carried out.

The block processing procedure starts when a node first receives a block. It then follows the steps below:

1. Block Format Verification: This step involves checking that the incoming block adheres to the expected format and meets the necessary field requirements, along with general validity checks (e.g. checking block timestamp is greater than its parent).

2. Transaction List Processing: During this step, the node fetches the relevant state from disk storage and loads it into memory. Transactions are the executed sequentially corresponding to the order specified by the block. A record of state modifications is kept in memory throughout the process.

3. State Root Validation: This step involves comparing the computed state root, resulting from the execution of transactions, with the state root specified in the block header. If the state roots do not match, the block is deemed invalid.

4. Local View Update: This step involves:

   1. Appending the newly verified block to the blockchain.

   2. Applying the state changes resulting from the transaction execution to disk.

   3. Generating receipts for transactions.

5. Block Propagation: The final step involves broadcasting the newly processed block to other nodes in the network, contributing to the overall synchronisation of the blockchain. The node will then listen for future blocks that other nodes broadcast that build upon its latest view of the blockchain.

Now that we have described the steps of the block processing procedure, let’s look at each of them and identify the expenditure classes they fall under as well as the computational resources that they need for their execution:

In the table above, we can observe how the five primary steps of the block processing procedure were listed along with the expenditure class they belong to, and the computational resources they require. We also can observe that step 4 is broken down into three parts - appending block, applying state updates to disk, receipts generation. The reason for doing so is to show that step 4 involves performing certain tasks that fall under different expenditure classes, but together they describe what is required in step 4 to update the blockchain once a block has been deemed valid.

Having identified the different computational resources required by each of these steps, we have a better understanding of the unique resource requirements corresponding to these steps. While this is certainly useful, we still don’t know how what sort of quantities of resources these steps require nor if there are dynamics at play which affect how much the resource requirements to perform these tasks may grow or whether they remain constant regardless of the block’s contents.

In order, to understand the resource consumption characteristics of these steps, we need more information. We can gain this desired insight, by means of assessing the computational complexity involved with carrying out each step.

Computational complexity analysis of the block processing procedure will help us find out what sort of tasks involved with steps are more resource-intensive than others as well as help us better understand how usage patterns of certain computational resources can contribute towards execution bottlenecks given that these resources have unique properties and limitations.

Computational complexity describes the quantification, characterisation, and measurement of computational resources required to execute a specific process or task.Analysing computational complexity can help us observe any behavioural phenomena that emerges during the execution of a process, providing useful insights in the form of bottleneck identification, patterns of resource use, and much more.

There are two aspects of computational complexity that will tell us useful things about the resources that each of these steps consume:

• Time complexity: Time required to execute a given task. Time complexity is proportional to the quantity of computational resources consumed by computational processing.

• Space complexity: Computer memory required in executing a given task. We typically use space complexity to describe the consumption of memory or disk resources in executing a task.

With these two aspects, we can learn a lot about the resource consumption characteristics of each step in the procedure. The table below describes the time and space complexity associated with each step:

With regards to the table results above, you don’t have to necessarily understand how we arrived at the specific complexity figures. Instead, consider them as broadly accepted assumptions that describe the resource consumption characteristics of each step.

What does the computational complexity analysis reveal?

The computational complexity analysis shows us that there are a combination of fixed and variable costs involved with the block processing procedure. Let us define what we mean by both fixed and variable costs below:

Fixed costs describe costs that do not change in relation to the volume of activity within a system. These costs are remain constant regardless of how the input to a process varies.

Variable costs describe costs that fluctuate based on the level of activity within a system. These costs typically change depending on the size, complexity, or quantity of inputs provided to a process.

These definitions help us understand what we mean by these two types of costs. Let us get a bit of a more intuitive understand of what it means for either of the two aspects of computational complexity to have these costs.

Time complexity:

• Fixed costs: The amount of computational steps required in processing remains constant.

• Variable costs: The amount of computational steps can grow depending on the contents of information fed into the process.

Space complexity:

• Fixed costs: The amount of memory or disk space required in computation remains constant.

• Variable costs: The amount of memory or disk space required in computation can grow depending on the contents of information fed into the process.

Now that we have explained what fixed and variable costs mean for both time and space complexity, let us walk through the block processing procedure step-by-step and explain the nature of computational complexity brought about by the execution of the various tasks involved:

1) Block Format Verification

This step has a time complexity of O(1) and a space complexity of O(1).

• This operation has only a fixed cost.

• The resources consumed during this step remains constant, irrespective of the contents of a block.

2) Transaction List Processing

This step has a time complexity of O(n) and a space complexity of O(n*m).

• This operation has variable costs.

• As the number of transactions (n) increase, so too does the amount of required computational processing steps.

• As the number of transactions (n) and the number of unique account storage entries (m) increase, so too does the amount of required memory and disk computational resources.

3) State Root Validation

This step has a time complexity of O(1) and a space complexity of O(1).

• This operation has only a fixed cost.

• The resources consumed during this step remains constant, irrespective of the contents of a block.

4a) Local View Update: Appending Block

This step has a time complexity of O(1) and a space complexity of O(1).

• This operation has fixed costs.

• The resources required to append a new block to the blockchain remain constant.

4b) Local View Update: Applying State Updates to Disk

This step has a time complexity of O(m) and a space complexity of O(m).

• This operation has variable costs.

• As the number of state changes accrued during transaction execution increase, so too does the amount of computational steps and memory/disk space resources required to service the state update.

4c) Local View Update: Receipts Generation

This step has a time complexity of O(n) and a space complexity O(n).

• This operation has variable costs.

• Each executed transaction has a receipt generated alongside it which includes useful information such as log events and filters.

• As the number of transactions (n) in a block increase, so too does the amount of required computational processing steps.

• As the number of transactions (n) in a block increase, so too does the amount of required memory/disk resources to generate and store the receipts in Ethereum’s receipts trie.

5) Block Propagation

This step has a time complexity of O(p) and a space complexity of O(1).

• This operation has both a fixed and variable costs.

• The required computational processing steps increases with the number of connected peers a node has (p).

• The required memory/disk resources remains constant because broadcasting a block does not require additional space per peer.

We have once again walked through the block processing procedure, but this time we did so in order to understand the computational complexity involved with carrying out each step. In doing so, this revealed to us that there are several fixed and variable costs that describe the manner in which various computational resources are consumed in each step, highlighting that some tasks require different resource types and varying quantities to fulfil their computational objectives.

In the next section, we will use all our findings related to the block processing procedure to motivate a need to constrain the resource consumption involved in this procedure. In doing so, we will also get an understanding of why this is important to do for a decentralised system like Ethereum.

Constraining Resource Consumption

In the previous section we found out that there are several fixed and variable costs involved in the block processing procedure. We summarise our findings in the table below:

Our analysis shows us that there are several variable costs that exist within the block processing procedure. These identified variable costs are explicitly pointed out below:

Transaction List Processing:

• Variable Cost: Computational processing steps required increases as the number of transactions increase.

• Variable Cost: Memory/disk resources required increases as the number of transactions and unique accounts involved in transactions increase.

Applying State Updates to Disk:

• Variable Cost: Computational processing steps required increases as the number of required account state changes increase.

• Variable Cost: Memory/disk resources required increases as the number of required account state changes increase.

Receipts Generation:

• Variable Cost: Computational processing steps required increases as the number of transactions increase.

• Variable Cost: Memory/disk resources required increases as the number of transactions increase.

Block Propagation:

• Variable Cost: Computational processing steps required increases as the number of connected peers a node has increase.

Looking at the variable costs described above, we notice a common source that drives most of these costs, this being the amount of transactions involved as well as the complexity of the interactions described by them. Given this understanding, we can reason that if we do not limit the resource consumption involved with processing a list of transactions that these costs could continue to increase significantly. We can also observe that a variable cost exists in the block propagation step, however this variable cost is not relevant because the number of connected peers is not part of the protocol specification and is left up to the agency of the participant running the node, we can therefore consider this variable cost as negligible.

Consequence of Unconstrained Resource Consumption

In earlier sections we introduced the key properties of computational resources, one of which was being finite in nature:

In a decentralised system like Ethereum, it is vital that we keep the resource requirement to run nodes reasonably low and accessible. Given that we identified how transactions have a significant influence on how costly the resource consumption of the block processing procedure is, we can reason that it may be one of the greatest variable factors that determine how demanding the resource requirements to run a node are.

Therefore if we do not impose reasonable limitations on the amount of computational resources that can be expended in executing transactions and updating the blockchain accordingly, we risk many nodes part of the decentralised set running into problem like resource exhaustion due to their modest capacities of computational resources.

Resource exhaustion describes a scenario in which all available resources of a node have been fully consumed and are now depleted, resulting in the node no longer being able to function efficiently or at all.This can happen due to hardware limitations, badly-optimised software, or network-related factors.

Given that a diverse set of nodes is crucial for ensuring changes to the blockchain are trustlessly computed and verified and are thus vital to serving the network, the implication of not constraining resources will likely result in many nodes experiencing resource exhaustion and therefore dropping out the network. Participants with modest computer systems will therefore no longer be able to participate in the network by running nodes, leaving the duty of trustlessly computing the changing state of the blockchain in the hands of participants in the form of a small minority of sophisticated actors with high-performance computer systems.

In this scenario we undermine the permissionless property of being able to participate in Ethereum and trustlessly compute the state of the blockchain, and the consequence of this is that users who interact with Ethereum by sending transactions have no other option but to trust this minority set of sophisticated actors to honestly receive and broadcast their transactions as well as report the state of the blockchain. While Ethereum still possesses the characteristics of being trustless, the barrier to entry to run a full node means this is only possible given you have extraordinary computational resources at your disposal. Given this high barrier to entry, Ethereum still technically remains permissionless and trustless, but these properties are significantly undermined - the penultimate consequence of this is that decentralisation of the entire system is undermined.

Protecting Permissionless and Trustless Properties

By now it is quite clear how severe the consequences of not constraining resource consumption of key activities like the block processing procedure can be for Ethereum. We put the diverse set of nodes at risk of running into problems like resource exhaustion, thus undermining who gets to trustlessly compute the current state of the blockchain and interact directly with it. If we do not address this resource exhaustion concern, we essentially render running a node on modest, consumer-grade hardware unmanageable. We thus regard the failure to constrain resource usage as making the ability to run a node severely unaccessible to the average person.

From all of the reasoning above, you will now understand by bounding resource consumption of critical blockchain tasks like the block processing procedure is vital to maintaining the decentralisation of Ethereum. We seek to preserve the strong guarantees of permissionless and trustless properties that have always been core principles of the network:

• Permissionless: By keeping the resource requirements sufficiently modest, it remains possible for a broad range of participants with varying levels of computational resources at their disposal to run a node and interact with the network without an intermediary.

• Trustless: By keeping the resource requirements sufficiently modest, we ensure that running a node is accessible therefore allowing participants to trustlessly compute the current state of the blockchain without the need an intermediary.

Keeping the costs associated with running an Ethereum node is a crucial requirement for maintaining a resilient, censorship-resistant, decentralised network. If we cannot maintain a sufficiently decentralised network, we lose all the valuable properties of a blockchain that justifies its value proposition.

Its worth mentioning that while constraining resource consumption is important in preserving the decentralisation properties of Ethereum, it is only one of many factors that influence this property. There are various other concerns such as the barrier to entry to become a block producer and more that play an important role, but such matters are out of the scope of this article.

Practical Solutions to Constrain Resource Consumption

In order to address the risks posed by resource exhaustion, we thoughtfully place constraints on the maximum amount of computational resources that are allowed to be expended while processing a block of transactions. You can thus imagine this taking the form of some sort of computational resource provisioning, in which the impact of transaction set execution can be measured and thus have a cumulative amount of resource usage that must fall within some maximum limit specified by Ethereum through the protocol specification:

We mentioned earlier on in this section that the amount of variable costs involved with carrying out the block processing procedure depends on the amount of computational resources utilised while executing the transactions of a block and updating the blockchain accordingly. While the amount of transactions present in a block did demonstrate that if you increase the amount, so too does the resource costs of the entire procedure; but we also found out that the complexity of transactions is a decisive factor as well. So with this information, what sort of solutions can we propose that both sets a maximum limit on resource consumption and is able to meter resource consumption?

Solution 1: Set maximum limit of transactions allowed in a block?

What if we decided to constrain the resource consumption of the block processing procedure by setting a hard limit on the amount of transactions that are allowed within a single block?

From a naive point of view, this would indeed set some constraint on resource consumption if we imagined all the transactions involved executed in timely manner. However, setting such a limit would likely encourage users to send more complex transactions ,which are very resource-intensive, to make the most of the opportunity of getting their transaction included in a block. This demonstrates one example of how such a design decision could lead to resource abuse by users. Unfortunately, this isn’t even the biggest problem, it only gets worse from here.

While the above shows that this method is inefficient, the following point of failure we are about to describe shows that Ethereum would simply stop working. Because the EVM (Ethereum’s execution environment) is capable of performing generalised computation, we can describe it as having the characteristic of being Turing-complete. The implications of this are that transactions are capable of triggering very complex execution and can potentially cause infinite loops. Therefore if Ethereum were to limit resource consumption by means of restricting the number of transactions allowed within a block, any one of these transactions could potentially exhaust a node’s computational resources thus demonstrating a resource exhaustion vector. Given the undecidable nature of the **halting problem **and the EVM being Turing-complete, it would be impossible for Ethereum to determine whether such invocation of transaction execution would ever terminate. This therefore demonstrates why attempting to constrain the resource consumption of the block processing procedure by means of restricting the number of transactions will not work.

This clearly is not a viable option for managing resource consumption. Given the nature of how Ethereum’s execution model works and what sort of generalised computation that transactions may invoke. We need a more nuanced solution that more closely meters the computational burdens imposed by transaction execution.

Practical Solution: Measurement System of Transaction Execution Work

By nature of design, Ethereum is a programmable blockchain. It has features that support the deployment of smart contracts, which enable participants to deploy executable programs on the blockchain. As with many computer programs, these contracts typically contain callable functions through which transactions on Ethereum are capable of calling them with or without external arguments depending on the function description. This functionality demonstrates the wide variety of blockchain execution that can be performed on Ethereum. Given this context, we can understand that transaction execution could demand resources ranging from minimal to theoretically infinite amount given the Turing-complete properties of the EVM.

Having a better understanding of the environment and dynamics at play, we need a more precise method that considers the complexity of transaction execution in order to produce a solution that can effectively constrain the resource consumption involved with the block processing procedure.

Ethereum therefore introduced the gas model to help achieve this goal.

The gas model is a solution designed to constrain resource consumption during the block processing procedure. It introduces a measure called "gas" which assigns computational costs to every operation in the EVM. It is with this same measure that the maximum limit of a block is expressed.

The measure of gas is introduced to Ethereum and is used to measure the computational effort involved with executing transactions and updating the blockchain. Ethereum establishes this unit of measure to assign costs to primitive computational operations used by the EVM, effectively enabling nodes to meter the computational effort involved with executing the transaction. Because the EVM is a stack based machine, the method of metering computational steps is fairly trivial and requires summing up the total amount of computational work described by the execution trace of the transaction. Ethereum therefore sets a max amount of computational effort (described as a max quantity of gas) that a block is allowed to use, therefore if the execution of transactions in a block exceed this amount - the block will be deemed invalid.

The diagram below illustrates the intuition around the use of the gas model to constrain and meter the resource consumption caused by transaction execution:

While the gas model does not explicitly constrain every aspect of the block processing procedure, it has helped us bound the main cause of the variable cost which we identified as being caused by transaction processing-related tasks. We can therefore think of the finite amount of gas allowed to be used in a block as achieving the same effect as constraining the heterogenous computational resources of a node, thus the introduction and use of the new measurement system has helped us tangibly achieve a desired goal:

In summary, the gas model can be considered Ethereum’s solution to bounding the resource consumption imposed by the block processing procedure. Given this procedure is carried out by all Ethereum nodes in the network every 12 seconds, the importance of trying to keep the resource footprint of this procedure sufficiently modest in terms of computational resource requirements cannot be emphasised enough.

We are not yet familiar with how exactly the gas model is implemented nor what challenges are faced in implementing such a system utilising this, but we will find out soon enough how the resource pricing component of the resource allocation system explicitly deals with this.

Reflections Leading into Part 2

It was important that we went through Part 1 in this article to get a strong understanding of the underlying computational resources that drive Ethereum’s operation.

In doing so we were introduced to a crucial activity carried out by all nodes on the network, this being the block processing procedure. As mentioned earlier, this activity essentially describes the execution of upon information provided by the resource allocation system, of which we have yet to even start exploring!

By walking through the block processing procedure and getting a good understanding of the resource consumption dynamics, we discovered that the execution of transactions are a significant variable cost in this activity. Given the goals around preserving the permissionless and trustless properties of Ethereum that contribute to the emergent decentralisation characteristic of the network, we understood the importance of targeting the bottlenecks around transaction execution and therefore providing a reasonable solution to enforcing constraints on the amount of execution that can be done in each block.

In the upcoming Part 2 of this article series, we will explore how the resource pricing component of the resource allocation system makes use of the introduced gas model to assign costs to transaction execution steps as well as showing how execution is metered. We will also understand the factors that influence the design of the gas system of measure.

With the foundations of our computational resource deep-dive along with our upcoming exploration of the resource pricing component, we will therefore have a strong understanding of the entire block processing procedure by the end of Part 2. Thereafter, Part 3 will show how transaction fee mechanisms deal with the principal-agent problem at hand and drive the creation of welfare-maximising block payloads which get executed in the block processing procedure.

So what all that out of the way, lets get started on Part 2: Resource Pricing (soon™️) 🫡.