Modular Thesis Part 1: Blockchain Trilemma in a Monolithic Setting

📌

Read the Original Article on Substack:

Modular Thesis Part 1: Blockchain Trilemma in a Monolithic Setting

Blockchain Trilemma in a Monolithic Setting

When designing blockchains, there are three dimensions to consider - security, decentralization and scalability, which constitute the infamous Blockchain Trilemma. Security refers to the system’s ability to prevent taking over by malicious parties. Decentralization refers to control distribution to as many nodes as possible to be central failure resistant. Scalability refers to the network’s ability to process a large amount of transactions without increasing cost and time. A blockchain can usually achieve two of these listed properties with the third as a trade off.

Figure 1. Blockchain Stack

A traditional blockchain such as Ethereum has 4 layers (Figure 1), respectively Execution, Settlement, Consensus and Data Availability, each performs crucial functions in the transaction lifecycle. As illustrated in Figure 2, transactions are submitted to the Execution Layer for ingestion, processing and inclusion in a block by a block producer (usually a validator). Then the new block is propagated to other full nodes (validators) at the Consensus Layer with these nodes downloading transaction data to independently reproduce and verify new state at the Data Availability Layer. Subsequently, these full nodes reach majority agreement that the new state is valid at the Consensus Layer. Finally, the new state is updated and finalized at the Settlement Layer.

Figure 2. High Level Transaction Lifecycle

It is important to note that many of the functions described above are performed by very few node types with limited computation and data storage resources, and hence creating either scaling bottlenecks, centralization problems or just imply not secure (Trilemma trade offs). Imagine you have a kitchen with workers responsible for cutting vegetables, cooking them and washing dishes (full cycle). With such “generalization of labor” (Figure 3), what you’d end up with is either you have a very slow kitchen because of limited individual bandwidth and too many workers that have to “gossip”, or the system relies on a smaller set of highly specialized workers to handle all functions at high speed—though under extreme load, it may require coordination adjustments (as seen in Solana’s early network challenges).