Original Author: Vice President of Jump Crypto

introduction

introduction

In the previous article (One article to understand "the key part of Web3 infrastructure"), we introduce some L1-related components in the blockchain infrastructure. Let's take a closer look at these L1s, where we define a concise but powerful framework for:

• Effectively analyze the performance of L1

• secondary title

clear concept

The discourse around evaluating and comparing the performance of L1 layer and standalone blockchain ecosystems is often ambiguous. Questions like the following often dominate the discussion:

• What does the ecosystem look like?

• How is this network expanded?

• Does this chain support composability?

While these questions are related, they don't address the key to why a particular L1 performs better than the competition. Let's try to make our approach to analyzing L1 performance more specific and structured by going through a concise framework.

Let's start with a basic definition!

*Note: Our metrics refer to hard, measurable statistics, while attributes refer to"emerging"condition.

technical indicators

Node Processing Requirements: The minimum CPU/computing resources required to efficiently run 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 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 is allowed to contain.

technical attributes

Security - the ability of nodes in the network to communicate and verify transactions through cryptographic and/or game-theoretic difficulty.

Liveness - the ability of nodes in the network to exchange information/reach consensus.

Scalability - the speed and ability with which the network can verify or process transactions.

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

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

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

Ecosystem Growth Indicators

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

Daily transaction volume - the number of transactions processed per 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 - how easy it is for ordinary users to understand and participate in the application on the chain.

Community Engagement - The degree to which the project's stakeholders interact with the application itself, other users, and developers.

Let's see how these properties come together to advance our understanding of how to evaluate a network. For example, underlying technical metrics such as chain growth and chain quality can be used to determine properties such as security, liveness, and decentralization, which in turn help determine which infrastructure components are necessary to launch the network . These required infrastructures are also key to the success of the Dapps built on top of them.

We can track ecosystem growth in a number of ways, all of which also relate to speed, efficiency, and activity. These include metrics of 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 an ecosystem and its potential for future growth.

L1 layer performance stack

Ecosystem Attributes: Community Participation｜User Experience/User Interface｜Convenience of Integration/Portability of DApp

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

Emerging technical features: fault tolerance|security|efficiency|scalability|decentralization|upgradeability

secondary title

Summarize key points

There are a lot of terms in the above framework. in tradition,"The Blockchain Trilemma"scalability

scalability

horizontal scalabilityimage description

image description

(sublinear)

Low overhead - The additional computational cost of achieving consensus, security, and all the other properties on this list should be minimized relative to the cost of processing each transaction. To achieve sublinear scaling, we need the amount of resources (q) used to validate state updates to be sublinear to the amount of computing resources (p) used to compute state transitions.

Shorten time to finality - The time from submitting a transaction to finalizing a state update should be minimized.

decentralization

Composability/Atomicity - All applications running on L1 should be able to interoperate. For example, users should be able to send atomic transactions to combine the functionality of any two applications. The state of the system should work as a unified object without making the user"stranded"in a fragmented state. This issue is especially important when dealing with shard chains.

safety

safety

security/soundness- A malicious party or parties should not be able to convince the network to execute an invalid transaction with high probability. Blockchains should specify a strong set of guarantees to disincentivize bad behavior through game-theoretic incentives, or build cryptographic primitives (algorithms) that make such attacks computationally infeasible.

anti-censorship- Everyone should have equal access to the system. Computers participating in the protocol should not deny access to any participant. The barrier to participation in consensus/validation should be small (i.e. minimum compute/storage requirements to run a node).

fault tolerance- It should be very difficult for any attacker to disrupt the operation of the protocol. For example, the state of the system must be backed up so that a powerful attacker cannot erase it.

effectivenesssecondary title

Tradeoffs to Consider

The above properties provide a taxonomy 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 trade-offs to discuss the relationship between these different terms. Analysis in terms of tradeoffs provides a clear way to understand which chains can best serve a particular use case.

Consensus Overhead VS Security VS Scalability —- The more nodes/computers that "participate in consensus" or "verify state transition process", the more secure the network will be. This is evident, for example, in the PoW model, where the longest chain becomes the typical chain or network's"real state". However, if a large subset of these nodes exhaust their computing resources instead of using them for computing state transitions, then throughput will be limited and the network will slow down.

Final result time VS TPS VS security- The faster a block is finalized, the less time validators have to agree on the state. Faster block times can allow for higher TPS, but if there is not enough time to reach consensus efficiently, rollbacks can become more prevalent, compromising the security of the system.

Node Requirements VS Scalability- In order for the blockchain to be truly decentralized, everyone should be able to access/participate in the network easily. In order for the system to be 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. More nodes may join the network as a result, but the increased number of nodes must compensate for the loss of computational bandwidth from less powerful machines—striking the right balance remains a key challenge.

Data Availability vs Indexability——As the amount of data on the chain increases, it becomes more difficult to effectively parse or filter this data. DApps need to have the ability to query data on the chain in real time in order to serve large or fast requests from their users.

Horizontal scalability vs atomicitysecondary title

Application layer impact

The infrastructure parameters we have discussed can greatly affect the types of applications that may or are actually built on a particular chain. Consider the following example:

- Bandwidth limitations affect support for high-throughput applications. On the contrary, higher TPS enables higher frequency transactions and real-time updates.

- Long final result times may not be suitable for payments or other applications that require fast settlement.

- High on-chain resource costs (i.e. gas costs) will hinder the development of applications. (For example, traditional central limit order books (CLOBs) are not feasible on Ethereum due to high gas costs, so automated market makers (AMMs) prevail, such as Uniswap. On L1 with lower fees such as Solana, And on L2 on chains such as Ethereum, CLOBs may be quite practical).

Above, we showed a framework for analyzing the performance of L1s. Here, we provide a deeper analysis of how L1 can be better evaluated from their ecosystem and or projects built on-chain.

We divide these projects into four main parts:

Whether the public chain has the ability to include and integrate these elements is crucial to its short-term growth and long-term sustainability.

We believe that, beyond supporting individual projects, there are 5 main steps to high-growth ecosystem development:

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

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

3) Incentivize user/retailer adoption through the growth of this DApp.

4) Focus on bringing high-fidelity data on-chain, either through oracles or a dedicated data availability layer.

Summarize:

Summarize:

There is no denying that cryptocurrencies have experienced rapid growth since the birth of Bitcoin in 2009. This growth is mainly formed by the emergence of new L1 public chains. In 2015, Ethereum introduced a Turing-complete architecture through the Ethereum Virtual Machine (EVM), so that the function of the blockchain is not only a static ledger, but also a global state machine that can run and execute arbitrary expression programs. This opens the door for DApp development more generally, bringing ordinary retail users into the blockchain ecosystem, as evidenced by movements such as “DeFi Summer”. However, as adoption increases, new challenges arise in terms of scalability, forcing builders to find new ways to help alleviate capacity constraints. This manifests itself in chains like Solana and other L1/L2 developments that attempt to increase throughput by off-chaining computation.

Now, as new L1s explore new architectures around scalability, leveraging better consensus mechanisms and cryptographic primitives; effectively assessing their value remains a daunting task. We hope this post gives you a more structured approach to more holistically evaluating these L1s by showing how core, measurable technical metrics relate to the growth of the ecosystem and ultimately help determine the market value of a particular network .