Layer 1 blockchain protocols are the rules and mechanisms that govern a blockchain’s base network. They coordinate agreement on blocks or the continuing chain, while distinct protocol functions concern execution and the data participants need to verify state changes. Protocol design can shape capacity, but a design description alone does not establish measured network performance.

What layer 1 blockchain protocols are responsible for

A Layer 1 protocol defines how participants coordinate around a blockchain’s base network. For example, Ethereum nodes use a consensus mechanism to agree on new blocks and the continuing chain. source The specific rules and terminology are network-dependent, so a description of one protocol should not be treated as a universal account of all Layer 1 systems.

It is also useful to distinguish protocol responsibilities from application behavior. An application may use a blockchain, but application-specific behavior should not be assumed to describe the protocol itself. When evaluating a claim, ask whether it concerns network rules or a particular application, service, or software implementation. The evidence available here supports discussion of selected protocol functions, not a comprehensive account of every network’s application interface or transaction lifecycle.

Three questions help organize the technical picture: how participants agree on the accepted history, how transaction instructions are applied, and what data participants need to check state changes. These functions are related, but they are not interchangeable. A statement about agreement does not, by itself, specify execution requirements or establish what data is available for verification.

How transactions move through a protocol

A transaction is a request for a change to network state. The exact path from a user’s submission to an accepted update depends on the protocol and implementation. The allowed evidence does not specify a general process for transaction propagation, ordering, or selection, so those details should not be presented as identical across networks.

Execution is the function that applies transaction instructions and produces a state change. Consensus addresses a different question: how participants agree on blocks or the continuing chain. Ethereum’s documentation identifies consensus as the process its nodes use to agree on new blocks and the chain. source Keeping the terms separate helps prevent a claim about block agreement from being mistaken for a description of all transaction processing.

For a particular network, a careful review should follow the terminology in its own primary documentation. Identify what the document means by a transaction, an accepted update, and execution; then check whether its description covers the protocol itself or a specific implementation. The evidence here does not establish a universal sequence of transaction-handling stages, so claims about that sequence require protocol-specific support.

This distinction also helps when reading a capacity claim. A statement about how participants agree on updates is not automatically a statement about how much computation each update requires, how much data is involved, or how many transactions were processed in a measurement period. Those are separate questions, and each needs evidence appropriate to the claim.

Consensus, execution, and data handling

Consensus is the coordination function for agreement on network history. The label should not be used as shorthand for every component involved in network operation. In Ethereum’s explanation, proof of work is a Sybil-resistance and block-author-selection component used alongside validation, networking, incentives, and a fork-choice rule. source That example demonstrates a terminology distinction; it does not describe every consensus design or imply that proof of work is used by every Layer 1.

Execution is distinct from consensus because it concerns applying transaction instructions and deriving a state change. Data handling is distinct again. Data availability refers to the ability of network participants to obtain transaction data needed to verify summarized state changes independently, even if participants do not all process the data in the same way. source This requirement should not be confused with long-term archival retrieval: availability assurance and archival retrieval are related but separate requirements. source

These distinctions matter because a protocol may describe one function in detail while leaving another to a different specification or implementation. A reviewer should avoid inferring execution behavior from consensus terminology, or inferring archival guarantees from a statement about data availability. The available evidence supports these conceptual separations, but does not specify a complete data-storage design or execution model for all Layer 1 networks.

Client diversity is another implementation consideration, not a synonym for consensus or capacity. Ethereum documentation states that multiple independently maintained clients can reduce dependence on one codebase and reduce the network-wide impact of a bug or attack against a dominant implementation. source This point is specific to the stated client-diversity concern; it does not establish the degree of diversity in a particular network, nor does it measure transaction processing capacity.

How protocol design relates to network capacity

Capacity is not a single figure that can be inferred from a protocol’s name or from a high-level description. A design may define constraints relevant to processing activity, but a theoretical limit and an observed result are different kinds of evidence. The allowed claims here do not provide current block or update limits, transaction-rate figures, or a methodology for measuring network performance. Accordingly, no throughput number or ranking follows from this evidence.

To interpret a stated limit, first identify exactly what it measures and which protocol rules or implementation it applies to. To interpret an observed result, determine how it was measured and under what conditions. Without those details, the figure cannot be treated as a comparable result across protocols or as a reliable account of routine network performance. This is a verification standard, not a claim that any particular network has achieved a given capacity.

It is also important not to turn a component-level observation into a system-wide conclusion. For instance, client diversity can reduce dependence on one codebase, but that does not establish overall network capacity or overall security. Likewise, the data-availability requirement describes what participants need to verify state changes; it does not specify how many transactions a network can process. Keeping the scope of each statement intact helps builders and infrastructure decision-makers avoid comparing unlike measures.

The available evidence does not establish a universal relationship between a particular capacity choice and participation requirements. Any such claim would need evidence tied to the network, protocol rules, implementation, and measurement being discussed. Without that evidence, readers should treat capacity and participation as questions to investigate, not as outcomes that can be deduced from a general protocol label.

What to verify before drawing conclusions

Start by identifying the exact network, specification, and implementation named in a technical claim. Then classify the claim: does it concern consensus, execution, data needed for verification, client diversity, or an application? This simple separation makes it less likely that a statement about one part of the system will be repeated as a conclusion about the entire protocol.

For performance figures, check whether the source describes a theoretical limit or an observed result. For an observed result, look for the measurement method, the period covered, and the network conditions. If those elements are not stated, do not treat the figure as a like-for-like comparison. The evidence used for this explainer supplies no such benchmark, so it cannot substantiate a specific network-capacity figure.

For operational and security statements, check that the evidence concerns the same protocol and implementation as the claim, and retain the limits expressed in the documentation. A client-diversity observation is not a full security assessment; a statement about data availability is not a promise of archival retrieval; and a description of consensus does not, on its own, document execution or measured capacity. These boundaries keep a technical explanation useful without turning protocol descriptions into unsupported performance or security guarantees.

Sources and references