v0.2.7-testnet

[0.2.7-testnet] - 2026-10-21

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

sudo vera-join --upgrade

A validator that is still on v0.2.5 (stopped at block #151) also upgrades directly to this version. If it was jailed for downtime, unjail it first:

sudo VERA_RPC_URL=https://testnet-rpc.verachain.cloud vera_cli unjail --key-file /etc/vera/validator_key.hex
sudo vera-join --upgrade --yes-consensus-upgrade

Faster block pipeline

• Each block is executed once. The result computed while building or validating a proposal is reused when the block is applied, instead of executing the block again.
• Signature cache and parallel verification. A transaction signature is checked once, when it enters the mempool, and remembered. Signatures not yet seen are verified in parallel across the available cores.
• O(1) mempool admission. Admission no longer scans the whole mempool, and the mempool is persisted in the background instead of on every transaction.
• Persistent state tree. The state tree (CSMT) is copy-on-write, so building and validating a block no longer clones the whole state.
• Incremental state on disk. Instead of rewriting the full state on every block, the node appends a checksummed per-block delta (state/state_deltas.log, written before the block) and writes a full snapshot every 100 blocks. A torn record at the end of the log, from a crash in the middle of a write, is ignored on restart.
• Concurrent RPC reads. Read-only RPC calls share a read lock and no longer wait for each other, and EVM address lookups use an index instead of scanning the state.
• Mempool re-gossip. Pending transactions are re-sent to peers when they connect and periodically, so a transaction is not lost when its first broadcast misses a peer.

Elastic hardware profile

The node detects at start-up what the machine (or its container / systemd slice) gives it: CPU threads (honouring affinity and cgroup quotas), memory and SIMD level. It sizes its parallel work and caches from that, so the same binary fits a 1-vCPU VPS and a 32-core server. The profile is printed in the start-up log. Set VERA_THREADS to override the thread count.

Measured

• Mempool admission with 100,000 accounts in the state: from about 10 to about 3,600 transactions per second.
• Applying a block of 1,500 transfers with 100,000 accounts in the state: from 0.47 s to 0.046 s.
• 3-validator devnet with simulated WAN latency (4-core VPS, all three validators on the same machine): up to about 530 transactions per second sustained, from about 10–20 with v0.2.6.
• Public testnet after the upgrade: median time from submission to a finalized block about 0.5 s.

Verified

• Full test suite green (93 tests), including a golden test that pins the state root of a fixed state, so the new tree computes exactly the same roots as v0.2.6.
• Devnets with random pauses and repeated kill -9, and with v0.2.6 and v0.2.7 validators mixed: 0 forks, 100% of transactions included.
• A copy of a production validator's data opened by v0.2.7 at the same height and with the same state root.

Upgrade and rollback

• Existing data is converted automatically on first start.
• vera-join --upgrade rolls back to the previous binary when the post-upgrade health check fails. Because releases before v0.2.7 only read the full state snapshot, the rollback now first folds the delta log back into the snapshot (it needs python3, and keeps a copy of the state folder as state.pre-rollback.<time>).
• A jailed validator no longer triggers a rollback. Jailing is not caused by the new binary, so the upgrade reports it with the unjail command instead.

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>