Jump Crypto: A Framework for Analyzing Layer 1 Public Chains

On March 30, 2022, Rahul Maganti, Vice President of Jump Crypto, posted a brief but powerful framework for analyzing the L1 public chain. The compilation of Golden Finance is as follows:


In the previous article, we covered some of the components of a Layer 1 (L1s) blockchain infrastructure. Let’s take a closer look at these L1s. Here we define a concise but powerful framework:

  • Efficiently analyze the performance of L1.
  • Determine the commercial viability of its ecosystem based on well-defined attributes and measurable metrics.


The language surrounding evaluating and comparing the performance of Layer 1 and independent blockchain ecosystems is often vague. Questions like this often dominate the discussion:

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

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

Let’s start with some basic definitions.

*Please note that we refer to metrics as hard, measurable statistics and attributes to “urgent” conditions that arise from those statistics.

Technical indicators

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

Transactions Per Second (TPS): Transactions processed and verified 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 on-chain confirmation.

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

Block size: The maximum amount of data a block is allowed to contain.

Technical characteristics

Security  – The ability of nodes in a network to relay and verify transactions with cryptographic and/or game-theoretic hardness.

Liveness  – The ability of nodes in the network to exchange messages/reach consensus. 

Scalability – The speed and ability of the network to validate or process transactions.

Node Requirements – Barriers to entry for users to run nodes and participate in governance decisions.

Satoshi Nakamoto coefficient – a measure of decentralization. The number of validators/entities required to disrupt at least one subsystem in the network. (i.e. the resources required to successfully launch a 51% attack)

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

Ecosystem Growth Indicators

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

Daily Transaction Volume – The number of transactions processed each day.

Ecosystem properties

Ease of integration/composability – the ability of an application to interact, build and integrate with other applications on the network. 

User Experience – Ordinary users can easily understand and participate in on-chain applications.

Community Engagement – The degree to which project token holders interact with the application itself, other users and developers.

Let’s see how these properties fit together to advance our understanding of how to evaluate networks. Fundamental technical metrics such as chain growth and chain quality can be used to determine attributes such as security, liveness, and decentralization. These properties, in turn, help determine which components of the infrastructure are required to launch the network. This infrastructure is key to the success of the applications built on it.

There are several ways to track ecosystem growth, all related in some way to speed, efficiency, and activity. This includes metrics around community engagement through social media and financial metrics such as protocol revenue and total value locked (TVL). Using these metrics, we can better understand the success of the ecosystem and its potential for future growth.

1-tier performance stack

Ecosystem properties       

Community Engagement | UX/UI | Ease of Integration/DApp Portability

Ecosystem Growth Indicators

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

Emergency technical features

Fault Tolerance | Security | Vitality | Scalability | Decentralization | Upgradability

Basic technical indicators     

Node Processing Requirements | Node Size | Transactions Per Second (TPS) | Chain Growth | Chain Quality | Block Size | Latency | Downtime | Propagation Time |

boil it

There are a lot of terms in the above frame. Traditionally, the blockchain trilemma has provided a good rough way to quickly evaluate blockchains. So how do we frame these properties from a decentralization, scalability, and security perspective?


Horizontal scalability – The processing power of the network (measured in transactions per second) should increase with the number of participating nodes. The TPS size of an ideal L1 is linear with the number of nodes (n). However, it is acceptable to scale it slightly sub-linearly.


Low overhead – The additional computational cost of implementing consensus, security, and all other properties on this list should be minimal relative to the cost of processing each transaction. To obtain sublinear scaling, we need the amount of resources (q) dedicated to verifying state updates to be sublinear in the computational resources used to compute state transitions (p).


Short final confirmation time – the time between committing the transaction and completing the state update is minimized.


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 functionality of any two applications. The state of the system should work as a single, unified object without leaving the user “stuck” into a fragmented state. This is especially a problem when dealing with shard chains.

Finality – The state must become immutable after a certain point in time. Finality allows users to execute transactions with off-chain components using L1. Finality can be achieved either cryptographically or economically (i.e., it becomes infeasible to perform a double-spend attack).


Security/Robustness – A malicious party or group of malicious parties should not convince the network with high probability of invalid transactions. Blockchains should specify a strong set of guarantees, either through game-theoretic incentives to discourage bad behavior, or establish cryptographic primitives that make such attacks computationally infeasible.

Censorship resistance – everyone should have equal access to the system. Computers participating in the protocol should not deny access to any participant. The threshold for participating in consensus/validation should be small (i.e. minimum computation/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 so that a powerful attacker cannot wipe it.

Liveness – ensuring honest messages are included/available to block producers. The security conditions that consensus protocols are designed to achieve are fundamentally based on the liveness of the chain – validators cannot verify messages to which they do not have access. For some consensus architectures (such as PoW), metrics such as chain quality and chain growth can be useful indicators of liveness.

Tradeoffs to Consider

The properties outlined above provide a classification method for evaluating L1, but do not really provide a way to effectively evaluate the relative merits of different networks. We introduce a set of key tradeoffs and discuss the relationship between these different terms. Building this analysis in terms of tradeoffs provides a clear way to understand which chains can best serve a specific use case.

1. Consensus overhead vs. security vs. scalability: The more nodes/computers participating in the consensus or verification state transition process, the better the network security. This is evident in PoW models, for example, where the longest chain becomes the canonical chain or “true state” of the network. However, if a large subset of these nodes exhaust their computing 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 the block is completed, the less time validators have to agree on the state. Faster block times can lead to higher TPS, but if there is not enough time to effectively reach consensus, rollbacks may be more common, compromising the security of the system.

3. Node requirements and scalability: In order for the 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 to run a node should be relatively low. However, as node requirements decrease, so does the total computing power available to the network. As a result, more nodes may join the network, but the increase in the number of nodes must compensate for the loss of computational bandwidth caused by less capable machines – striking the right balance remains a key challenge.

4. Data Availability and Indexability: As the amount of data on-chain grows, it becomes more difficult to parse or filter data efficiently. DApps need to be able to query on-chain data in real-time in order to serve large or fast request sets to their users.

5. Horizontal scalability and atomicity: Sharding requires maintaining different parts of the chain state across multiple subnets. While this allows transactions to be processed in parallel, this increases the risk that users could get stuck. There are various ways to maintain atomicity across shards, but all of them require some additional overhead.

app-level effects

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

  • Bandwidth constraints can limit support for high-throughput applications. Conversely, a higher TPS limit enables higher frequency transactions and real-time updates.
  • Longer finalization times may be less useful for payments or other applications that require fast settlement.
  • High on-chain resource costs (i.e. gas costs) can hinder application development. (For example, traditional central limit order books (CLOBs) are not feasible on Ethereum because of the high gas cost, so automated market makers (AMMs) such as Uniswap prevail. On L1s with lower fees such as Solana, and Like on Ethereum L2, CLOB can be very practical).  

Above, we show a framework for analyzing L1 performance. Here, we provide a more in-depth analysis of the process of how to better evaluate L1 from its ecosystem and/or on-chain-built programs.

We divide these projects into four main categories:

1larJdU3ZN80NJjCZ24sqpBPd74AAFurx9Ul4gNU.pngThe ability to incorporate and integrate these primitives is critical to its short-term growth and long-term sustainability.

We believe there are 5 main steps in the development of a high-growth ecosystem, in addition to supporting individual projects:

1. Realize cross-chain communication through assets or universal bridges.

2. Bring liquidity to the platform by integrating DeFi primitives. (such as money markets and exchanges). This incentivizes the core developer community to build better tools and abstractions, allowing less sophisticated developers to build more consumer-facing products.

3. Incentivize user/retailer adoption through this DApp growth.

4. Focus on putting high-fidelity data on-chain through oracles or dedicated data availability layers.

5. Index this data and display it in an easy-to-understand format (eg on an explorer).

in conclusion

There is no denying that cryptocurrencies have experienced rapid growth since the advent of Bitcoin in 2009. Much of this growth has been shaped by the emergence of new L1s. In 2011, Ethereum introduced a Turing-complete architecture with the Ethereum Virtual Machine (EVM), which enables the blockchain not only as a static distributed ledger, but also as a global state machine that can run and execute arbitrary expressive programs. This opens the door to more general DApp development, bringing ordinary retail users into the blockchain ecosystem, as evidenced by movements such as DeFi Summer. However, as adoption has increased, new challenges in scalability have emerged, forcing builders to find new ways to help alleviate capacity constraints.

Now, as the new L1 explores new architectures leveraging better consensus mechanisms and cryptographic primitives around scalability, effectively assessing its value remains a daunting task. We hope this article provides you with a more structured approach to evaluating L1 more holistically by showing how core, measurable technical metrics correlate with ecosystem growth and ultimately help determine the market value of a particular network.

Stay tuned for the next article where we will discuss various approaches to blockchain scaling!

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/jump-crypto-a-framework-for-analyzing-layer-1-public-chains/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-03-31 09:23
Next 2022-03-31 09:25

Related articles