Jump Crypto: How to Build a Layer 1 Analysis Framework

Author: Rahul Maganti, Partner at Jump Crypto

Original Title: "A Framework for Analyzing L1s"

Compiled by: Ze Yi, Chain Catcher

Introduction

In the previous article, we introduced some components related to Layer 1 (L1) in blockchain infrastructure. Let’s take a closer look at these L1s. In this article, we define a concise yet powerful framework for:

• Effectively analyzing the performance of L1s.
• Determining the commercial viability of their ecosystems based on clearly defined attributes and measurable metrics.

The language surrounding the evaluation and comparison of the performance of Layer 1 and independent blockchain ecosystems is often vague, with questions like these frequently dominating discussions:

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

However, these questions do not specifically target the key aspects where a particular L1 outperforms its closest competitors. Let’s establish a concise framework that allows us to be more specific and structured when analyzing L1 performance.

Let’s start with some basic definitions.

Please note that we refer to metrics as measurable statistics and attributes as the conditions derived from these statistics.

Technical Metrics

Node Processing Requirements: The minimum CPU/computational resources required to operate a node effectively.

Transactions Per Second (TPS): The number of transactions processed and validated on-chain per second.

Chain Growth: The average growth rate of the longest chain.

Chain Quality: The proportion of honest blocks in the longest chain.

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

Number of Nodes: The number of nodes participating in consensus, execution, or both.

Block Size: The maximum amount of data that a block can contain.

Technical Attributes

Security - The ability of nodes in the network to relay and validate transactions through cryptographic/game-theoretic hardness.

Effectiveness - The ability of nodes in the network to exchange messages/reach consensus.

Scalability - The speed and capacity of the network to validate or process transactions.

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

Satoshi Coefficient - A measure of decentralization. The number of validators/entities required to disrupt at least one subsystem in the network (i.e., the resources needed to successfully initiate a 51% attack).

Upgradability - The ability of the network/community to propose, evaluate, and implement protocol changes.

Ecosystem Growth Metrics

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

Daily Transaction Volume - The number of transactions processed daily.

Ecosystem Attributes

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

User Experience - The ease with which ordinary users can understand and participate in on-chain applications.

Community Engagement - The degree to which stakeholders in the project interact with applications, other users, and developers.

Let’s see how these attributes combine to enhance our understanding of network evaluations. We can better understand an ecosystem's success and its future growth potential through various metrics, including those surrounding community engagement and financial metrics such as protocol revenue and total value locked (TVL).

Layer 1 Performance Stack

Ecosystem Attributes: Community Engagement | User Experience/User Interface | Ease of Integration/DApp Portability

Ecosystem Growth Metrics: Total Value Locked (TVL) | Daily Transaction Volume | Social Media Growth (Discord / Telegram / Twitter) | Number of Developers | Protocol Revenue

Infrastructure Requirements: Data Availability | Cross-Chain Interoperability | Searchability/Indexing | Developer Tools

Technical Attributes: Fault Tolerance | Security | Effectiveness | Scalability | Decentralization | Upgradability

Technical Metrics: Node Processing Requirements | Number of Nodes | Transactions Per Second (TPS) | Chain Growth | Chain Quality | Block Size | Latency | Downtime | Propagation Time | Satoshi Coefficient

Inductive Summary

The framework above contains many terms. Traditionally, the blockchain trilemma is a quick way to assess a blockchain. So how do we build these attributes around decentralization, scalability, and security?

Scalability

• Horizontal Scalability - The network's processing capacity (e.g., transactions per second) should increase with the number of participating nodes. An ideal L1 would allow its TPS to scale linearly with the number of nodes (n). However, slight sub-linear scaling is acceptable. (We acknowledge that linear scaling is more of an ideal attribute, and most L1s scale sub-linearly.)

• Low Overhead - The computational costs incurred to achieve consensus, security, and all other attributes on this list should be minimal relative to the cost of processing each transaction. To achieve sub-linear scaling, the amount of resources (q) dedicated to verifying state updates should be sub-linear compared to the computational resources used for calculating state transitions (p).

• Short Completion Time - The shortest time between submitting a transaction and completing a state update.

Decentralization

• Composability/Atomicity - All applications running on L1 should be able to interoperate. For example, users should be able to send atomic transactions that combine the functionalities of any two applications. The system's state should operate as a single unified object without leaving users "stranded" in fragmented states. This is especially problematic when dealing with sharded chains.
• Finality - The state must become immutable after a certain point in time. Finality allows users to execute transactions with off-chain components on L1, which can be achieved through cryptographic or economic means (i.e., executing a "double spend" attack becomes infeasible).

Security

• Security/Robustness - Malicious actors or a group of malicious actors should not be able to persuade the network to execute invalid transactions with high probability. The blockchain should specify a set of strong assurance mechanisms, either by deterring bad behavior through game-theoretic incentives or by establishing cryptographic primitives that make such attacks computationally infeasible.
• Censorship Resistance - Everyone should have equal access to the system, and computers participating in the protocol should not deny access to any participant. The threshold for participating in consensus/validation should be low (i.e., the minimum computational/storage requirements for running 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 to the extent that a powerful attacker cannot erase it.
• Effectiveness - Ensuring that honest messages are included/available for block producers. The security of consensus protocols is fundamentally based on the effectiveness of the chain—validators cannot verify messages they do not have access to. For certain consensus mechanisms (e.g., PoW), metrics such as chain quality and chain growth may be useful indicators of this attribute.

Trade-offs to Consider

The overview above provides a taxonomy for evaluating L1s but does not offer a truly effective way to assess the relative merits of different networks. Below, we will introduce a set of key trade-offs, discussing the relationships between these different terms and providing a clear method to understand which chains can best serve specific use cases.

1. Consensus Overhead vs. Security vs. Scalability - The more nodes/computers involved in the consensus or state transition process, the better the network's security. For example, this is evident in the PoW model, where the longest chain becomes the normative chain or "true state" of the network. However, if a large subset of these nodes exhausts their computational resources instead of being dedicated to state transition calculations, throughput will be limited, and the network will slow down.

2. Time to Finality vs. TPS vs. Security - The faster blocks are completed, the less time validators have to reach consensus on the state. Faster block times can lead to higher TPS, but if there is not enough time to effectively reach consensus, rollbacks may become more common, thereby compromising the system's security.

3. Node Requirements vs. Scalability - For a blockchain to be truly decentralized, everyone should be able to easily access/participate in the network. To keep the system as permissionless as possible, the minimum requirements for running a node should be relatively low. However, as node requirements decrease, the total computational power available to the network also decreases. The result may be more nodes joining the network, but the increase in node count must compensate for the computational bandwidth loss caused by weaker machines. Therefore, achieving the right balance remains a key challenge.

4. Data Availability vs. Indexability - As the amount of on-chain data grows, effectively parsing or filtering data becomes more challenging. DApps need to be able to query on-chain data in real-time to provide a large or rapid set of requests for their users.

5. Horizontal Scalability vs. Atomicity - Sharding requires maintaining different parts of the on-chain state across multiple subnets. While this allows for parallel processing of transactions, it increases the risk of users becoming stranded. There are some methods to maintain atomicity across shards, but all of these methods require some additional overhead.

Implications at the Application Layer

The infrastructure parameters we discussed can greatly influence the types of applications built on a specific chain. Consider the following examples:

• Bandwidth will limit support for high-throughput applications; conversely, higher TPS limits can enable higher frequency transactions and real-time updates.
• Longer finality times may be less useful for applications requiring rapid settlement, such as payments.
• High on-chain resource costs (i.e., gas costs) may hinder application development. (For example, traditional centralized limit order books (CLOBs) are unfeasible on Ethereum due to high gas costs, leading to the popularity of automated market makers (AMMs) like Uniswap. On lower-fee L1s like Solana, as well as L2s on chains like Ethereum, CLOBs can be very practical.)

Above, we presented a framework for analyzing L1 performance. Below, we provide a deeper analysis of how to better evaluate L1s based on the projects built within their ecosystems/chains.

We categorize these projects into four main buckets:

The blockchain's ability to integrate these fundamental elements is crucial for its short-term growth and long-term sustainability.

We believe that the development of high-growth ecosystems involves five main steps:

1. Achieving cross-chain communication through asset or universal bridges.

2. Bringing liquidity to the platform by integrating DeFi primitives (e.g., money market lending platforms and exchanges). This incentivizes the core developer community to build better tools and abstract assumptions, allowing less complex developers to create more consumer-facing products.

3. Incentivizing user adoption through DApp growth.

4. Focusing on bringing high-fidelity data on-chain through oracles or dedicated data availability layers.

5. Indexing this data and presenting it in an easily understandable format (e.g., on explorers).

Conclusion

There is no denying that the crypto space has experienced rapid growth since the advent of Bitcoin in 2009. This growth has largely been shaped by the emergence of new L1s. In 2011, Ethereum introduced a Turing-complete architecture through the Ethereum Virtual Machine (EVM), allowing blockchains to function not just as static distributed ledgers but as global state machines capable of running and executing any expressible program. This opened the door to more generalized DApp development, bringing ordinary retail users into the blockchain ecosystem, as evidenced by movements like DeFi Summer.

However, as adoption rates increase, new challenges around scalability have emerged, forcing builders to seek new ways to help alleviate capacity constraints. This has been reflected in the development of chains like Solana and others, which attempt to increase throughput by moving computation off-chain.

Now, as new L1s explore new architectures around "scalability through better consensus mechanisms and cryptographic primitives," effectively assessing their value remains a daunting task. We hope this article provides you with a more structured approach to comprehensively evaluate such L1s by demonstrating how core, measurable technical metrics relate to ecosystem growth and ultimately help determine the market value of specific networks.