A Framework for Analyzing L1s

Introduction

In the previous article, we went over a few components of blockchain infrastructure related to layer-1s (L1s). Let's take a closer examination of these L1s. Here, we define a succinct but powerful framework for:

• effectively analyzing the performance of L1s.
• determining the commercial viability of their ecosystems based on well-defined properties and measurable metrics.

Don’t Be Vague

The language around evaluating and comparing the performance of layer-1s and independent blockchain ecosystems is often vague. Questions like these often dominate discussions:

• What does the ecosystem look like?
• How does this network scale?
• Does this chain support composability?

While these questions are relevant, they don’t target the crux of why a particular L1 might perform better than a close competitor. Let’s try and make this more concrete by developing a succinct framework that allows us to be more specific and structured in our approach to analyzing L1 performance.

Let’s start with some basic definitions.

*note that we refer to metrics as hard, measurable statistics and properties as "emergent" conditions that arise from these statistics.

Technical Metrics

Node Processing Requirements: minimum cpu/computational resources necessary to effectively operate a node.

Transactions per Second (TPS): transactions processed and verified on-chain per second.

Chain Growth: average growth rate of the longest chain.

Chain Quality: fraction of honest blocks in the longest chain.

Time to Finality: time from transaction submission to confirmation on-chain.

Node Volume: number of nodes participating in consensus, execution, or both.

Block Size: the maximum amount of data a block is allowed to contain.

Technical Properties

Safety - ability of nodes in the network to relay and validate transactions, either through cryptographic and/or game-theoretic hardness.

Liveness - ability for nodes in the network to exchange messages / reach consensus.

Scalability - speed and ability with which a network can validate or process transactions.

Node Requirements - barrier to entry for users to run nodes and participate in governance decisions.

Nakomoto Coefficient - one metric to measure decentralization. The number of validators / entities needed to compromise at least one subsystem in the network. (i.e. resources required to successfully mount a 51% attack)

Upgradeability - ability for a network / community to propose, evaluate, and implement changes to the protocol.

Ecosystem Growth Metrics

Total Value Locked (TVL) - total value of assets on-chain.

Daily Transaction Volume - number of transactions processed per day.

Ecosystem Properties

Ease of Integration / Composability - ability for applications to interact with, build on , and integrate with other applications on the network.

User Experience - ease with which an average user can understand and engage with applications on-chain.

Community Engagement - the degree to which stakeholders of a project interact with the application itself, other users, and developers.

Let’s see how these properties can fit together to drive our understanding of how to value a network. Base technical metrics like chain growth and chain quality can be used to determine properties like safety, liveness, and decentralization. In turn, these properties help determine which and what components of infrastructure are necessary to kickstart the network. This infrastructure is key to the success of applications building on top.

There are a few ways we can track ecosystem growth, all of which are related in some manner to speed, efficiency, and activity. This includes metrics around community engagement through social media and financial metrics like protocol revenue and total value locked (TVL). Using these metrics, we can derive a better understanding of the success of an ecosystem and its potential for future growth.

Layer 1 Performance Stack

Ecosystem Properties: Community Engagement |  UX / UI | Ease of Integrations / DApp Portability

Ecosystem Growth Metrics: Total Value Locked (TVL) | Daily transaction volume | Social Media Growth (Discord / Telegram / Twitter) | Developer Count | Protocol Revenue

Infrastructure Requirements: Data Availability | Cross-chain interoperability | Searchability / Indexing | Developer Tooling

Emergent Technical Properties: Fault Tolerance | Safety | Liveness | Scalability | Decentralization | Upgradeability

Base Technical Metrics: Node Processing requirements | Node volume | Transactions Per Second (TPS) | Chain Growth | Chain Quality | Block Size | Latency | Downtime Duration | Propagation Time | Nakamoto Coefficient

Boiling It Down

There are a lot of terms in the framework above. Traditionally, the blockchain trilemma has provided a nice back-of-the envelope way of quickly evaluating blockchains. So how can we frame these properties in terms of decentralization, scalability, and security?

Scalability

• Horizontal scalability — The processing power of the network (measured as, e.g. transactions per second) should increase with the number of participating nodes. An ideal L1 would have its TPS scale linearly in the number of nodes (n). However, slightly sub-linear scaling it acceptable. (we acknowledge that linear scaling is more of an ideal property - most L1s have sub-linear scaling).

• Low overhead — The added computational cost of achieving consensus, security, and all the other properties on this list should be minimal relative to the cost of processing each transaction. To get sub-linear scaling, we need the amount of resources dedicated to verifying state updates (q) to be sub-linear in the computational resources used for computing state transitions (p).  

• Short time to finality — Minimal duration between submitting a transaction and the state update being finalized.

Decentralization

• Composability / Atomicity — All applications running on the L1 should be able to interoperate. For example, users should be able to send atomic transactions that combine functionality from any two applications. The state of the system should work as a single unified object without leaving users “stranded” on fragmented state. This is particularly a problem when dealing with sharded chains.
• Finality — The state must become immutable after some point. Finality allows users to use the L1 to perform transactions that have an off-chain component. Finality may be achieved cryptographically or economically (i.e., it becomes infeasible to execute a double spending attack).

Security

• Safety / Soundness — a malicious party or set of malicious parties should not be able to convince the network of invalid transactions with high probability. A blockchain should specify a set of strong guarantees, either through disincentivizing bad behavior through game-theoretic incentives or establish cryptographic primitives that make it computationally infeasible for such attacks to take place.
• Censorship resistance — Everyone should have equal access to the system. The computers participating in the protocol should not be able to deny access to any participant. The barrier to entry to participate in consensus / verification should be small (i.e. minimum computational / storage requirements to run a node).
• Fault Tolerance — it should be difficult for any attacker to disrupt the operation of the protocol. For example, the state of the system must be replicated such that a powerful attacker cannot erase it.
• Liveness — ensures that honest messages are included / available to block producers. The security conditions that consensus protocols aim to achieve are fundamentally based on the liveness of the chain - validators cannot verify messages they do not have access to. For some consensus architectures (e.g. PoW), metrics like Chain Quality and Chain Growth can be useful indicators of liveness.

Tradeoffs to consider

The properties outlined above provide a taxonomy for evaluating L1s but do not really offer a way to effectively assess the relative merits of different networks. We introduce a set of key tradeoffs that discuss the relationships between these various terms. Framing this analysis in terms of tradeoffs provides a clear approach to understanding which chains could best serve a particular use case.

1. Consensus Overhead vs. Safety vs. Scalability - the more nodes / computers that participate in consensus or the process of verifying state transitions, the better the security of the network. For example, this is evident in a PoW model, in which the longest chain becomes the canonical chain or “true state” of the network. However, if a large subset of these nodes use up their computational resources instead of dedicating them to computing state transitions, throughput is limited and the network slows down.
2. Time-to-Finality vs. TPS vs. Safety - the faster blocks are finalized, the less time validators have to agree on the state. Faster block times could allow for higher TPS, but without enough time to effectively reach consensus, rollbacks could be more prevalent, compromising the security of the system.
3. Node Requirements vs. Scalability - for a blockchain to be truly decentralized, everyone should have easy access / ability to participate in the network. To make the system as permission-less as possible, the minimum requirements for running a node should be relatively low. However, as the node requirements are lowered, the aggregate computational power available to the network decreases. More nodes may join the network as a result, but the increase in the number of nodes must make up for the loss in computational bandwidth from less capable machines — striking the right balance remains a key challenge.
4. Data Availability vs. Indexability - As the amount of data on a chain grows, it becomes harder to parse or filter that data efficiently. DApps needs the ability to query on-chain data in real-time to service a high volume or fast set of requests for their users.
5. Horizontal scalability vs. Atomicity - sharding requires maintaining different parts of the state of the chain across multiple subnets. While this allows transactions to be processed in parallel, it this increases the risk that users may be stranded. There are various approaches to preserving atomicity across shards but all of them require some additional overhead.

Application-Level Effects

The infrastructure parameters we discussed can significantly affect the types of applications that are possible or practical to build on a particular chain. Consider the following examples:

• Bandwidth constraints can limit support for high throughput applications. Conversely, higher TPS limits enable higher-frequency trading and real-time updates.
• Longer time-to-finality may be less useful for payments or other applications that require fast settlement.
• High on-chain resource costs (i.e. gas costs) can stymie application development. (Ex. Traditional central limit order books (CLOBs) are infeasible on Ethereum due to high gas costs, hence the prevalence of Automated Market Makers (AMMs) such as Uniswap. On lower-fee L1s such as Solana, as well as L2s on chains like Ethereum, CLOBs can be quite practical).  

Above, we showcased a framework for analyzing the performance of L1s. Here, we provide a more in-depth analysis on how to better approach the process of evaluating an L1 from their ecosystems and or set of projects building on the chain.

We classify these projects into four main buckets:

The ability for chains to onboard and integrate these primitives is critical to their short-term growth and long-term sustainability.

We believe there are 5 main steps to high-growth ecosystem development aside from supporting individual projects:

1. Enabling cross-chain communication through asset or general-purpose bridges.
2. Bringing liquidity to the platform by integrating DeFi primitives. (e.g. money markets and exchanges). This incentivizes the core developer community to build better tools and abstractions, thereby allowing less sophisticated ones to build more consumer-facing products.
3. Incentivize user / retail adoption through this DApp growth.
4. Focus on bringing high-fidelity data on chain, either through oracles or a specialized data availability layer.
5. Index this data and display it in an easy-to-understand format (e.g. on an explorer).

Conclusion

Crypto has undeniably experienced rapid growth since the inception of Bitcoin in 2009. This growth has been shaped largely by the emergence of new L1s. In 2015, Ethereum introduced a Turing-complete architecture with the Ethereum Virtual Machine (EVM), allowing blockchains to function not just as static ledgers but as global state machines that could run and execute arbitrarily expressive programs. This opened the doors to more general DApp development, bringing average retail users into the blockchain ecosystem, as evidenced by movements like DeFi Summer. With this increase in adoption, however, new challenges in scalability also emerged, forcing builders to find novel approaches to help relieve capacity constraints. This has manifested in the development of chains like Solana and other L1/L2s that attempt to increase throughput by moving computation off-chain.

Now, as new L1s explore novel architectures around scalability that leverage better consensus mechanisms and cryptographic primitives, effectively assessing their value remains a difficult task. We hope that this article gave you a more structured approach to evaluating such L1s more holistically by demonstrating how core, measurable technical metrics connect to ecosystem growth and can ultimately help to determine the market value of a particular network.

Please reach out to Rahul Maganti (@rahulmaganti_) for questions, comments, or thoughts. Thanks again to Jayant Krishnamurthy (@jayantkrish), Lucas Baker (@sansgravitas), Nikhil Suri (@nsuri_) for their feedback! Stay tuned for the next article, where we discuss the various approaches to blockchain scaling!