How Blockchain Works | Benchmarks, Throughput and Finality

A fictional workshop says its record service processes one hundred requests in ten seconds. Another says each request takes one second.

These statements describe different properties. The first concerns a count over time; the second concerns the waiting time of a request under some definition.

Neither is meaningful enough to compare systems until we know what the requests do and where completion is measured.

A blockchain benchmark is a defined experiment, not a universal speed rating printed inside a network.

Our guide uses invented numbers only. None are measurements of a live blockchain.

The beginner’s first question is “fast at doing what?” A simple balance read, a complex state update and an externally completed delivery are different tasks. Comparing them as identical transactions can produce a precise-looking number with an imprecise meaning.

Contents · Next chapter

The fictional workshop prepares requests that read stock, open loans and close loans. It records how many of each type the test sends.

That mix is the workload.

A test using only simple independent updates can behave differently from one whose requests compete over the same last item. A read-only test answers another question again.

The workload also has data sizes and starting-state conditions.

A useful benchmark report names these features rather than calling every request one generic transaction.

This does not require a beginner to operate a test network. On paper, write the task performed by each invented request and identify whether it changes shared state.

The exercise makes the unit visible. A rate becomes interpretable when readers know what each counted item represents and how the tasks relate to the application they actually care about.

Contents · Previous chapter · Next chapter

The fictional load generator sends one hundred requests during a ten-second window. The service completes eighty according to the test’s defined success condition.

The offered submission rate is ten requests per second. Successful completions during that window amount to eight per second under that particular counting rule.

These are different measurements.

A benchmark should not label the number of attempted submissions as if it necessarily represented successfully completed application work.

The exact measurement window and completion definition must be stated. Requests left in progress at the end need explicit treatment.

Our invented arithmetic illustrates the distinction; it is not a performance result.

The useful habit is to ask which counter supplied the headline. Was it a sender, an intake service, an execution result, a commit observation or an application-level completion record? Each can report a different stage of the same workflow.

Contents · Previous chapter · Next chapter

The fictional service acknowledges a request immediately, includes it later and updates the user’s history display after another delay.

Which moment counts as completion?

Different experiments can legitimately measure different stages, but their labels must identify those stages.

A response from an intake service is not automatically evidence that a state change is included or finalised.

This connects performance to the confirmations-and-finality guide. The word confirmed can be used inconsistently across tools and contexts.

Our paper report writes “completed at accepted application-state update” rather than simply “fast.”

A meaningful comparison uses the same finish line or explains why the lines differ.

The goal is not to insist that only one metric may ever be used. It is to prevent an early acknowledgement rate from being presented as if it measured a later, stronger guarantee.

Contents · Previous chapter · Next chapter

For one fictional request, the workshop records time of submission and time of the defined completion observation. The difference is that request’s latency for this experiment.

Changing either endpoint changes what is measured.

A network round-trip, a transaction’s inclusion wait and an end-to-end application response are different latencies.

The reader should therefore ask where the clock starts and stops.

Our invented example might take two seconds to reach the application’s completion condition, even though the first acknowledgement arrives sooner.

Both observations can be correct.

This is why a benchmark report needs a clear timeline. The number is not self-explanatory just because it is measured in milliseconds or seconds.

A useful statement includes the task, observation endpoints and relevant load conditions, allowing another reader to understand which part of the user’s waiting experience the result actually covers.

Contents · Previous chapter · Next chapter

The fictional workshop groups requests into larger batches. It can complete more work over a long interval while an individual request waits longer for a batch to form.

This is one way throughput and latency can trade off.

The result depends on the architecture and workload. It is not a universal claim that every throughput improvement increases delay.

Hyperledger Fabric’s documentation discusses configuration and workflow effects on performance, illustrating why the setup matters.

Our paper model collects four requests before processing a group. Compare that with handling each request immediately.

The group may reduce repeated overhead in the imagined process, but the first arrival waits for the others.

The beginner lesson is to keep the metrics separate. A headline showing one improved rate does not establish that every request finishes sooner or that every aspect of user experience improved.

Contents · Previous chapter · Next chapter

The fictional test submits one hundred requests. Eighty meet its success condition, ten are rejected and ten remain unresolved when the measurement window closes.

The report should not hide the rejected or unresolved cases merely because the successful ones have attractive latency figures.

Success rate concerns the chosen request cohort and outcome definition. Pending cases also need explicit handling.

Our numbers are invented to make the categories clear.

A careful report distinguishes expected application rejections from infrastructure failures where the task requires that distinction.

This connects to the testing guide: an intentionally invalid request may correctly be rejected, while a capacity test focused on successful valid work needs to account for it differently.

The point is to define categories before interpreting them. “One hundred processed” can conceal a very different useful outcome from “one hundred valid requested updates completed successfully.”

Contents · Previous chapter · Next chapter

Four fictional requests take one second each and one takes eleven seconds. Their average latency is three seconds.

No individual request in this example took three seconds.

The mean is useful, but it does not describe the full distribution. Some users waited much longer than the average suggests.

A benchmark can report additional summaries such as minimum, maximum and percentiles, using a defined calculation method and adequate sample.

Our five-request example is deliberately too small to support impressive statistical claims. It only illustrates how a single average can conceal variation.

The beginner should ask how many observations were made and what the spread looked like.

A performance explanation becomes more honest when it recognises the slower experiences rather than presenting one central number as if every request received exactly that service.

Contents · Previous chapter · Next chapter

A report might say that a specified proportion of requests completed within a certain latency threshold. That can be more informative than the mean alone.

The calculation still depends on the sample, percentile convention and treatment of incomplete requests.

A tiny or selectively filtered sample can produce misleading confidence.

Our fictional workshop therefore records its full observation set and states how it calculated summaries. It does not invent a ninety-ninth-percentile guarantee from five convenient requests.

A percentile measured in one experiment is not automatically a promise for every future user.

The lesson is statistical scope. The report describes an observed cohort under stated conditions.

A useful reader asks whether the measurement period, sample size and failure handling support the claim. The decimal places on a number cannot compensate for an unclear experiment.

Contents · Previous chapter · Next chapter

The fictional interface first reports that a request appears in a currently selected block. A later observation establishes the applicable settlement condition.

The elapsed time to those milestones can differ.

A benchmark comparing networks must say which milestone it uses. Different consensus designs can provide different forms of settlement evidence.

This guide does not rank current chains or prescribe a fixed waiting policy.

Its point is that useful speed includes the guarantee the application needs, not only the earliest visible response.

The confirmations and forks guides provide the background.

A transaction-per-second figure measured at one stage should not be silently paired with a finality claim from another stage as if the same experiment established both. State the rate, endpoint and guarantee together so the reader can see exactly what was measured.

Contents · Previous chapter · Next chapter

The fictional workshop tests on powerful machines in one room with a simple connection. Another test uses modest machines spread across several locations.

Those setups can produce different results even when the nominal application is similar.

CPU, memory, storage, networking and the number and roles of participants can affect performance.

A report should identify the relevant environment instead of attributing every difference to the blockchain brand.

This chapter is not a hardware recommendation. It introduces experimental context.

Our paper comparison places the two setups beside the workload and software-version labels.

The number becomes more useful when readers can judge how closely the test resembles their actual task.

A laboratory result can be valid within its scope while still being insufficient evidence of the same performance in a more distributed, contested or resource-constrained deployment.

Contents · Previous chapter · Next chapter

In one fictional test, every request updates a different borrower record. In another, all requests compete for the same last camera reservation.

The second workload has a different relationship between actions. Conflicts and shared-state dependencies can affect outcomes and processing.

This is why a simple transaction count does not describe all computational demand.

The transaction-order and atomicity guides show how shared state makes requests interact.

A useful benchmark report identifies whether operations are independent, conflicting or otherwise coupled.

Our paper model does not claim a particular implementation will handle either case at a specified rate. It asks the reader to recognise that they are different experiments.

Comparing headline throughput without that distinction can reward an easy workload while concealing the difficulty of the application’s real coordination problem.

Contents · Previous chapter · Next chapter

The fictional workshop accepts a sudden burst quickly by placing requests in a queue. The workers need much longer to complete them all.

A brief high intake rate does not establish a sustainable completion rate.

The observation period and queue behaviour matter. A system can accumulate unresolved work while appearing busy and responsive at the front door.

Our paper model uses an incoming tray. Count what enters, what finishes and what remains after the interval.

A benchmark should also explain whether the run includes startup, warm-up or drain periods when those affect its interpretation.

This is an experimental-design question, not a claim that every queue is bad.

The useful distinction is between absorbing a burst and maintaining service over time with the required outcome and acceptable waiting distribution. Those are related capabilities that need different evidence.

Contents · Previous chapter · Next chapter

The fictional test sender cannot produce requests faster than a certain rate. The record service remains partly idle.

The observed rate now reflects the sender’s limitation as well as the system under test.

A benchmark framework helps organise an experiment, but using a recognised tool does not automatically establish that the test exercised the intended capacity.

Caliper’s documentation treats benchmarking through defined workloads and reported indicators, not a magic universal score.

Our paper report identifies the sender, its request schedule and its own resource observations.

The beginner lesson is to include the measurement apparatus in the system map.

A disappointing number does not automatically reveal the chain’s maximum capacity, just as an impressive number does not establish every future workload’s performance. The test has to support the interpretation being made.

Contents · Previous chapter · Next chapter

The fictional workshop changes its program, database configuration and network layout between two runs. The second run is faster.

Which change caused the difference?

The result alone cannot identify a single cause when several conditions changed together.

A useful comparison records software versions, parameters, workload and environment, and explains the limits of attribution.

This is the same evidence discipline used in client diversity and incident diagnosis.

Our classroom experiment changes one clearly defined condition at a time when the question requires isolating its effect. A real study may use more elaborate methods, but it must still describe them.

The point is not to reject every multi-change result. It is to avoid claiming a causal explanation the experiment did not establish.

A benchmark is evidence produced by a method; the interpretation must fit that method.

Contents · Previous chapter · Next chapter

The fictional reservation request reaches the ledger quickly, but the user waits for an index update and a separate equipment handover.

The complete workflow takes longer than the chain’s execution step.

An application can legitimately optimise its interface or data service without changing the base protocol. Conversely, a protocol improvement may leave another bottleneck untouched.

This connects benchmarks to the whole series: logs, indexes, outside data and human actions each have their own roles.

A useful report names the segment it measures and avoids presenting that segment as the entire experience.

Our paper timeline marks submission, execution, settlement, display and physical completion separately.

The final practical question is which milestone the reader actually needs. Useful performance is not just a large count; it is the required result arriving under stated conditions with the relevant assurance.

Contents · Previous chapter · Next chapter

Create a card with workload, software version, environment, request cohort, timing endpoints and success definition.

Use the invented one-hundred-request example and report eighty successes, ten rejections and ten unresolved cases within a ten-second observation window.

State the submission and successful-completion rates under that window. Do not invent latency observations from the counts alone.

Add a separate small latency list and calculate its mean, clearly marking it as another teaching dataset.

Finally identify whether completion means acknowledgement, inclusion or a stronger specified milestone.

No live traffic is sent.

The exercise succeeds when the reader can see which numbers follow from which observations and which claims remain unsupported. The benchmark card should make comparison easier by revealing the experiment, not by hiding it behind a single flattering score.

Contents · Previous chapter · Next chapter

Blockchain performance has several dimensions: offered load, useful completed throughput, latency, success rate, resource demand and settlement context.

The numbers depend on the workload, environment, versions and measurement method.

Carry four questions into the technical companion: what work, which finish line, under what conditions and with how many failures or unresolved requests?

Our fictional workshop shows why a fast acknowledgement is not finality, why an average can hide long waits and why a submission burst is not sustained completed throughput.

The aim is not to dismiss benchmarks. Good benchmarks answer useful questions precisely.

A credible explanation keeps the experiment attached to the number so a reader can understand both the demonstrated performance and the limits of applying it to another system or task.

Contents · Previous chapter · Worked situations