v0.2.8-testnet

[0.2.8-testnet] - 2026-10-21

Throughput release. Not consensus-breaking (consensus_breaking: false): blocks, hashes and state roots are identical to v0.2.7, and v0.2.7 and v0.2.8 validators run side by side. The automatic upgrade timer installs it, or run:

sudo vera-join --upgrade

Every change below was found by measuring the public testnet under load, fixed, and measured again there.

Compact block propagation

• Compact proposals. Between v0.2.8 nodes, a Tendermint proposal carries the block header, the commit certificates and the transaction hashes instead of the full transactions and receipts. The receiver rebuilds the block from its own mempool, checks it against the header's tx_root, and computes the receipts when it executes the block. A 3 MB proposal becomes about 200 KB.
• Missing transactions. If the receiver lacks some of the transactions, it asks the proposer for those only, or for the full proposal when most of the block is missing.
• No redundant block broadcast. v0.2.8 nodes no longer send each other the whole block again after every commit. Validators decide the block through consensus, and a node that falls behind catches up through sync.
• Compatibility. These messages are only exchanged with peers that advertise the new FEATURE_COMPACT_BLOCKS capability. Older peers keep receiving full proposals and block commits.

Consensus never waits behind transactions

• Priority queue. Proposals and votes have their own queue on every connection and are sent before transaction gossip.
• Separate transaction queue. Transactions gossiped by peers have their own queue and are admitted in batches, with signatures verified in parallel.
• Before: under load, a validator could wait 1 to 1.5 s for a vote stuck behind thousands of transactions.

Block building and validation without holding the node lock

• Off-lock execution. A proposal is built, or a received one re-executed, on an O(1) copy of the state on a separate thread. The node lock is only taken to store the result.
• Effect: RPC transaction submissions no longer stall while a block executes. A batch of 100 transactions under load went from 720–877 ms to typically 100–350 ms (up to about 850 ms on the busier server).
• Batch submissions: signatures in JSON-RPC batches are verified in parallel before admission.

Mempool

• Cheap prune after each block. After each block the mempool drops used nonces without re-executing anything (160–525 ms → under 1 ms per block).
• Full prune off the lock. The full prune, which re-executes pending transactions, runs in the background on a copy of the state. It drops a transaction only if its sender's account is unchanged since the copy.
• Capacity: 5,000 → 20,000 pending transactions.

Fast start-up

• Persisted index. The transaction index is persisted in blocks/tx_index.log, and the latest-transactions list is built without re-reading the whole chain.
• Measured: a copy of a testnet validator's data (497 blocks) started in 30.8 s before, in 1.4 s on the first start (one-time index migration), and in 0.25 s after.

Timing logs

• Each height logs where its time went (⏱️ [TM]): build, proposal received, validation, precommit, decision and apply.
• Large blocks also log their apply stages (⏱️ [apply]), and block-sized network frames their encode and decode times.

Measured on the public testnet

Two validators in different data centers (one with 1 vCPU, about 118 ms round trip between them), signed transfers sent in JSON-RPC batches to both RPC endpoints, counted when final:

Batch	v0.2.7	v0.2.8
6,400 transfers	~700 TPS	721–892 TPS
12,800 transfers	rejected at 5,000 pending	869–1,092 TPS (median 1,055), all included

Median time to finality of a single transfer on an idle network: about 0.3–0.6 s.

Verified

• Test suite green, including new tests for compact proposals, the persisted transaction index (intact, missing and torn file), and both mempool prunes.
• Devnets with random pauses and repeated kill -9, mixing v0.2.8 with the published v0.2.7 and with each intermediate build: 0 forks, 100% of transactions included.
• Each change was deployed to both testnet validators one node at a time and measured before the next.

Upgrade and rollback

• On the first start, the transaction index is built once from the stored blocks; this takes seconds.
• Rolling back to v0.2.7 needs no conversion. The index file is simply ignored.

Release Artifacts

Signed offline with the official VERA Core release key:

• Fingerprint: 37F3 9BD8 9ADE E9EE E554 9C38 8974 19EF F806 BE51
• Key Identity: Vera Core <dev@verachain.cloud>