What happens inside
a 1.5-second block?
Start with the time we can account for. Then compare the costs a different consensus design might change.
Captured October 17 to 19, 2026 · Voting validator and two observers · Normal operation plus two upgrade histories
The headline uses the voting validator. This is a low-load observation, not a throughput-capacity benchmark. Each node observes the same chain; their counts do not add together.
A block needs agreement, execution, and delivery.
The proposer supplies a candidate block. Validators vote twice before committing it. The application then exposes results through RPC or an indexer. Those are different confirmation boundaries.
Swipe the diagram horizontally to read every label.
The arrows explain state order. Their lengths do not represent measured durations. Conditional waits and failed-round retries can add work.
The largest phase is the wait for the next height.
NewHeight contributes about 61% of the validator's interval. The two voting phases together contribute about 21%. A phase includes local work and waiting; it does not isolate networking.
Swipe the figure horizontally. Values are also listed below.
Read the full phase table and measurement boundaries
Contribution = phase-duration counter change ÷ block observations. Mean visit = phase-duration change ÷ phase visits. Repeated rounds and skipped states make these different. Values below are milliseconds.
The 96 half-hour bins are partitions of this capture, not individual-block latency samples. Histogram buckets cannot establish precise subsecond p95 or p99.
Commit processing uses part of the next-height schedule.
CometBFT schedules the next height when it enters Commit. Application execution and persistence consume some of that interval. NewHeight contains the remaining wait.
Swipe the figure horizontally to compare the three nodes.
The validator has a shorter Commit and a longer NewHeight than the observers. Their combined means are similar. This supports examining the schedule as a whole; it does not prove a live one-second setting, which was not retrieved.
Blocks resume before the phase budget settles.
The initial gap lasts seconds. Elevated Propose and Precommit contributions continue after the restart. Measure the initial interruption and the recovery tail separately.
Swipe the phase comparison horizontally. Read the totals below.
Read the upgrade table, including the incomplete transition
The recovery test needs six consecutive complete five-minute bins within 10% of the pre-upgrade block mean, plus a complete combined window. Confirmation at the end of that sequence does not prove permanent recovery or identify the cause.
Upgrade journal and local lifecycle timeline · Detailed timeline figure
Deleting two phases gives a question to test.
The zero-voting scenario subtracts the observed Prevote and Precommit contributions. Everything else stays fixed in this calculation. A real replacement changes scheduling, communication, and failure behavior too.
Swipe the comparison horizontally. The calculation is repeated below.
A sequencer is the service that chooses transaction order.
A single operator can choose that order without the Tendermint voting exchange. Replicas still need data and execution, and the system needs an explicit rule for accepting an order as canonical.
Schematic only. Replication, data publication, failover, and finality depend on the chosen design. An early acknowledgment is not automatically a durable, executed confirmation.
Change who agrees
A small BFT committee reduces the voting set while retaining Byzantine fault assumptions. It can still run CometBFT. Whether it lowers latency depends on quorum connectivity and the measured bottleneck.
Change how order is established
A different BFT protocol or a sequencer changes the agreement path. The application interface alone does not preserve header proofs, RPC behavior, upgrade handling, or finality guarantees.
Architecture research, Evolve adapter notes, and open questions · Source-level phase definitions
Each clock answers a different question.
Use counters for phase averages, logs for local lifecycle events, and headers for canonical block cadence. Combining these sources gives a useful baseline without pretending their clocks are interchangeable.
Swipe the evidence map horizontally to read all three sources.
Profiling method and reproduction commands · Normal-operation journal · Generated source tables · Metric manifest · Log and header manifest