New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
Faster transactions are among the benefits promoted in the recovered Blockchains Manager introduction to blockchain. Speed matters, but a single number rarely tells an application team what its users will experience. A network can accept many simple transfers while a complex application remains expensive. A service can display a quick acknowledgement while the consequential settlement step happens later. This guide develops a measurement plan using hypothetical workloads and timings. None of its sample figures describe a live network benchmark. The aim is to make a performance claim reproducible, comparable and connected to the task a reader actually wants to complete.
Define the operation before counting it
A transaction is a container for work, not a universal unit of business output. Sending a basic transfer, creating a record and running a complicated contract interaction can impose different demands. Ethereum's gas documentation describes a mechanism for measuring computational work rather than treating every transaction as equally expensive. For a benchmark, the corresponding management question is straightforward: what exactly does each counted operation do? Without that definition, two impressive throughput figures may be measuring workloads that have almost nothing in common beyond their use of the word transaction.
Write down a representative operation from the application's perspective. A hypothetical inventory system might require a signed submission, a state update, a receipt and a later query that confirms the new state. Decide whether the benchmark counts the initial submission alone or the completed sequence. Then specify the data size, the distribution of users and the frequency of complex cases. A test made entirely of the cheapest operation can be useful as a capacity experiment, but it should not be presented as a measurement of a richer production workflow.
Put a clock on every consequential stage
Consider a hypothetical interface that acknowledges a request after one second, observes inclusion after six seconds and applies its settlement policy after a further interval. Which timestamp appears in the advertisement? Which timestamp matters to the recipient? These questions can have different answers without either being a measurement error. The problem is an unlabeled number. A reader needs to know whether the clock stops at receipt by a service, acceptance by a node, block inclusion, a specified confirmation condition or completion of an application-specific action.
A useful test records several timestamps for the same operation and retains a correlation identifier linking them. It should also define where the clock runs and how clocks are synchronised. If the client and server use unrelated time sources, an apparent delay can partly be a measurement artefact. The report does not need to publish every internal detail to be readable, but it must state the start and finish conditions. Otherwise, another team cannot reproduce the claim or identify which stage caused a slower result under a different workload.
Look beyond the average
An average completion time can conceal an experience that is unpleasant for many users. Suppose a hypothetical test has ninety operations finishing in one second and ten finishing in thirty seconds. The mean is 3.9 seconds, but that single figure hides a large difference between the two groups. The calculation is illustrative rather than a claim about any network. Its lesson is that a summary should preserve the shape of the result, including slow cases, failures and operations that never reached the test's definition of completion.
Report sample size, measurement duration and the proportion of unsuccessful operations alongside latency percentiles. Distinguish rejected requests from accepted operations that later fail. If a benchmark silently drops every timeout, its remaining sample can make an unreliable service appear remarkably fast. Keep a record of retries as well. A workflow that eventually succeeds after several attempts may have a good final success rate while imposing significant delay and extra cost on the person trying to complete it. Users experience the attempts, not only the final successful transaction.
Test the busy period, not only the empty road
A lightly loaded system can behave very differently when demand rises. The relevant experiment is not simply to increase the submitted request count until the chart looks impressive. It is to observe how queues, fees, rejection rates and completion times change across a declared range of demand. The application may reach an operational limit before the underlying network does. A gateway, signing service, database index or external data provider can become the bottleneck even when the ledger itself continues to process its own workload normally.
Use a workload that contains both normal traffic and a defined burst. State how long the burst lasts, whether requests remain constant during congestion and how clients behave after a timeout. Then observe recovery. A system that processes a burst but spends the next hour clearing its backlog has a different operating profile from one that returns promptly to normal. Both profiles might be acceptable for different applications. The benchmark becomes useful when it explains that difference instead of compressing the entire experiment into its highest observed submission rate.
Include the boundaries introduced by scaling
Ethereum's scaling overview distinguishes approaches that change where and how work is processed. That distinction matters to measurement: an application should identify the environment in which its operation executes and the environment in which it expects settlement. A result observed inside one execution system may not describe the full path to another. The benchmark should say which boundary it covers rather than imply that a quick local acknowledgement demonstrates equally quick completion of every subsequent step, including exits or interactions with another network.
Map the complete journey for the particular task. If the hypothetical user must move an asset into an execution environment, interact with an application and later move it elsewhere, measure those stages separately before producing a total. Do not add a transfer stage that the actual task does not require, but do not omit one that it does. This keeps the comparison aligned with user intent. It also makes clear why one architecture can be excellent for repeated activity inside an environment while offering a different experience for occasional entry and exit.
Publish enough context to challenge the result
A useful performance report names the software version, test configuration, workload, network conditions and completion policy. It explains whether the environment was a controlled test network or a public production system. It records the observation period and the main limitations. These details do not weaken a good result. They make the result portable: another person can determine which assumptions apply to a different application and which do not. A bare throughput number offers no comparable way to understand an unexpected result after deployment.
The best question is therefore not which blockchain has the biggest speed claim. It is which measured workflow meets the application's requirements at an acceptable cost and with understood dependencies. Read throughput together with latency, failure behaviour, workload complexity and settlement boundaries. Then retain the test as something that can be rerun when software, demand or architecture changes. That approach turns the historical promise of faster transactions into a practical engineering discipline: define the work, measure its whole path and make the limits of the measurement visible to the people relying on it.
Technical references
From the recovered archive
- Blockchain is changing the world! · captured 6 October 2024