Verifiable snapshots, a double-sign guard and reliable cross-shard transfers

We run a four-validator network in our test harness (tools/quorum-net). Every run keeps its parameters, the logs of every node and a summary. This round of runs surfaced five defects, and all five are fixed.

Every state change goes through consensus

Some operations (multisig vaults, certificates, the bytecode whitelist, node profiles) were applied directly by the node that took the request, and the other nodes never saw them. As in the Cosmos SDK, a node now only validates a request on arrival; its effect is written to the state only when a block is applied.

A snapshot you don't have to take on trust

A new node can start from a state snapshot instead of replaying the whole history. The snapshot is accepted only if the block after it is signed by more than 2/3 of the validators and the restored state reproduces exactly the same state root — the rule CometBFT state sync uses. In the test we handed a node a forged snapshot with one balance changed and its checksums recomputed; the node refused to start.

Double-sign guard

A validator that was wiped and restored from an older snapshot signed a height it had already signed and was slashed by the network. Now, as in CometBFT, the last signature is kept in a file next to the validator key: a repeat is refused, and a restore never starts below the last signed height. The same scenario now passes with no slashing.

Cross-shard transfers

The destination shard credited a transfer at the moment the message arrived, so two of its nodes could credit it in different blocks; the network caught the divergence and stopped the shard. Now, as in IBC, the transfer is credited by a transaction in a block, and the destination checks that the debit is in a block of the source shard signed by its validators. Credit takes 1–2 seconds instead of up to 30.

Extra blocks

In a two-shard network, system transactions kept coming back into blocks, and an idle network made 120 blocks a minute. It now makes 2, as designed.

Connection flooding

The dos test plays an attacker opening about 480,000 connections to the nodes. On the release build the network kept producing blocks at the same pace as without the attack, thanks to the per-IP limit of 20 connections a second, persistent peer connections with an ML-DSA-signed handshake, and separate validator and guest admission with bans by key rather than by IP. Log warnings fell from 16,000 lines to 39. The slowdown we first blamed on the attack turned out to come from the debug build, so load tests now run on release builds only.

Result

333 node tests and 63 consensus tests pass, and so do the network scenarios — node crashes, restarts, load, connection flooding and two shards — with no state divergence and no slashing.