Decryption speed update for Finalis Core. Opening a time-locked transaction now takes about 45 ms on a desktop CPU and about 266 ms on a small 2-vCPU testnet server. In the next release, a node will also hold its consensus lock for only 2.2 ms per settlement, down from 78 ms. On multi-core machines, this means a node can process many encrypted transactions.
But I'm not trying to win a hardware race. My goal is for Finalis to run on minimal hardware, because the cheaper it is to run a validator, the harder the network is to capture.I'm still working on making it faster.
Email:
reikagitakashi@gmail.com
Finalis Core v2.2.13: first flag-day upgrade on testnet-3, the chain paused and resumed cleanlyv2.2.13 changes consensus rules, so old and new nodes can't run together. I released it as a coordinated flag day: everyone updates within one window (8 November, 17:00–19:00 UTC). Nodes with different rules refuse each other at the handshake (consensus-rules fingerprint), so the two versions never mix.
What happened- 17:30:08 UTC: block 4800 finalized, the last block on the old rules.
- Finality needs a 2/3 quorum, so neither the old group nor the new group could finalize alone. The chain paused.
- Every new block carries a threshold time signature for its parent. Block 4801 needed 9 of the 13 validators who finalized block 4800. Once the 9th of them updated, the next round went through.
- 18:31:36 UTC: block 4801 finalized on v2.2.13. Both of my nodes have the same hash, and the confidential supply audit matches.
Total pause: about 61 minutes. No fork, no reorg, no lost blocks, no lost coins, and no manual intervention.
What v2.2.13 fixesEach of the 8 ingress lanes has one certifier at a time. Before this release, that certifier was fixed for a 32-block epoch, so an offline validator could hold up its lane's transactions until the epoch ended. Now:
- Certifiers rotate every 2 blocks.
- A certifier is chosen only from committee members who signed one of the last 2 finalized blocks, so an offline validator stops being chosen.
- Every node computes the same certifier from finalized data alone.
In my chaos tests (crashes, partitions, Byzantine nodes), 0 of 153 time locks were lost, and no forks or stalls occurred.
What I learnedThe upgrade happened right at an epoch boundary. The new committee had enough upgraded members almost immediately, but the parent block's time signature still needed the old committee. Before mainnet, I'll work on signaled activation, so upgrades don't depend on everyone switching in the same hour.
Release (Linux, Docker, Windows):
https://github.com/FinalisCore/finalis-core/releases/tag/v2.2.13
v2.2.14 releasedI've published v2.2.14. It fixes two bugs that blocked new nodes from joining testnet-3:
Fresh sync stalled at block 36. The v2.2.13 ingress certificate rule was applied to pre-upgrade history, so block 37 was rejected. The rule now activates at height 4801, and earlier blocks validate under the previous rule.
Snapshot import replayed from genesis. The exporter omitted some state rows (committee checkpoints, join requests, finalized randomness, validator window counters), so the startup check failed and the node fell back to a full replay. Snapshots are now complete, and an imported node starts directly at the snapshot height.
Upgrade: required for new nodes, recommended for existing ones. No flag day: running nodes are unaffected and mixed versions are fine.
Download and checksums:
https://github.com/FinalisCore/finalis-core/releases/tag/v2.2.14 (the Windows installer follows shortly).
