Postern Labs / Updates / Technical specification
05 / Updates / Technical specification
Node release and network upgrades — technical specification.
What has shipped, what remains in testing and the parameters of each feature. Signed node release 1708953d includes validator hardening and the finality-certificate RPC. It schedules no new hard fork: all new HF1/HF2/HF3 activation gates remain disabled.
Current node release.
RELEASED1708953d / signed Linux x86-64 / 21 October 2026
The Genesis-4 upgrade includes durable signing-history protection, host-level signer locking and a strict signer anchor, duplicate-validator detection, improved attestation retries, stricter node-local ML-DSA relay verification and the finality-certificate RPC.
All 61 managed fleet validators were upgraded and verified on 22 October 2026. Frozen-set finality, own-target votes, canonical-signature activation, the ML-DSA consensus pin, growth cap, the new post-quantum suite and KES remain disabled. Existing mainnet activation epochs are unchanged.
Signed release, checksums and notes ↗ · Verification and upgrade guide ↗
Status labels.
| Label | Meaning |
|---|---|
| Implemented — in testing; activation disabled | Consensus change awaiting qualification and a separately announced activation. The released binary does not activate these features. |
| Released — node 1708953d | Node feature included in the signed release. Operators enable the relevant protections through the documented node configuration; no new hard fork is scheduled. |
1. Signature suites.
STATUSImplemented — in testing; activation disabled
Bloch authorizes spending with hybrid post-quantum signatures: two independent schemes combined with AND, so a signature is valid only if both parts verify. Suite 0x0001 stays the default and does not change. The upgrade adds an optional suite 0x0003 that pairs a stateless hash-based scheme with Falcon-1024.
| Parameter | Suite 0x0001 — default, unchanged | Suite 0x0003 — new, optional |
|---|---|---|
| Construction | ML-DSA-65 AND Falcon-1024 | SLH-DSA-SHAKE-128s AND Falcon-1024 |
| First scheme | ML-DSA-65 — FIPS 204, module lattices, NIST security category 3 | SLH-DSA-SHAKE-128s — FIPS 205, stateless hash-based, category 1 |
| Second scheme | Falcon-1024 — FN-DSA, draft FIPS 206, category 5 | Falcon-1024 — FN-DSA, draft FIPS 206, category 5 |
| Security statement | Both lattice signatures must verify | Category 3-level assurance while lattice schemes hold, and a hash-based floor (category 1) if lattice cryptography is weakened |
| Public key | 3,749 B | 1,829 B |
| Signature | 4,587 B (ML-DSA part 3,309 B fixed; Falcon part variable) | ≈9,132 B (maximum 9,322 B) |
| Key generation | — | 334 ms |
| Sign | 10.9 ms | ≈2.5 s |
| Verify | ≈0.2–0.3 ms | ≈2.2 ms |
| Intended use | Everything; the default for all accounts and validator votes | Cold storage, treasury, long-term holdings and validator withdrawal credentials. Not for validator votes. |
Suite 0x0003 uses the SHA-3/SHAKE hash family, consistent with Bloch’s SHA3-256 hashing.
Rules
- AND combination. Both signatures in a suite must verify; an attacker must break both schemes.
- Addresses commit to their suite. An address is the SHA3-256 hash of the suite-tagged public key, which prevents downgrade and cross-suite key reuse.
- Verification cost is charged per suite. A 0x0003 signature is priced from its measured verification time; a typical 0x0003 transfer costs about 6× today’s fee.
- Nothing to do for suite 0x0001 users. Existing keys and addresses keep working unchanged.
Implementation notes
- ML-DSA verification is deterministic and platform-independent: one portable implementation runs on every CPU.
- Canonical signature encoding is enforced, and the suite identifier is bound into the signed context.
- The SLH-DSA implementation passes the NIST ACVP test vectors.
- An independent external audit is planned before activation.
2. Finality under partitions.
STATUSImplemented — in testing; activation disabled
The proposed upgrade counts finality over a frozen validator set C instead of the live active set. The set changes only through a finalized checkpoint, so both sides of a network partition measure their votes against the same total — and two disjoint sides can never both reach the quorum.
| Parameter | Value |
|---|---|
| Quorum | 3·w ≥ 2·total, where w is the weight of included votes and total is the weight of C |
| Validator set C | Frozen; changes only through a finalized checkpoint |
| Leaving C | No included vote for 90 epochs (24 h) |
| Rejoining C | Automatic when the validator votes again |
| Inactivity leak | Still reduces rewards and balances; does not change the finality denominator |
| Vote eligibility | A vote counts only when its source and target are checkpoints of the voter’s own chain; foreign votes count as absent |
Activation remains subject to further qualification. This mechanism remains disabled in release 1708953d.
The intended quorum property
Each side needs at least two thirds of the weight of the same frozen set C. Two disjoint groups of validators cannot each hold two thirds of one total, so conflicting checkpoints cannot both reach the quorum.
3. Finality certificates.
STATUSReleased — node 1708953d
A finality certificate carries proof data for independent verification of a checkpoint. Verification starts from a trusted earlier finalized checkpoint and checks signed votes, validator-set proofs and ancestry; it does not remove that trust-anchor requirement.
| Parameter | Value |
|---|---|
| RPC method | getfinalitycertificate |
| Format | BLOCHFC1 |
| Votes | The justifying and finalizing vote sets, with full hybrid signatures |
| Validator set | Merkle inclusion and absence proofs |
| Ancestry | Included |
| Verifier | Standalone bloch-finality-verify |
| Size, 106 validators | ≈1.4 MB |
| Size, minimal 2/3 vote set | ≈1.1 MB |
4. Validator signer protection.
STATUSReleased — node 1708953d
With a persistent strict signer anchor configured, the validator keeps signing history outside its data directory and checks for local duplicate signers or restored stale data. Network observation also detects unexpected signatures from the same validator identity.
- Record before release. The signing record is persisted before any signature is released.
- Per-key lock. A host-level lock per key, held outside the data directory: a second local signer using that anchor refuses to start.
- Rollback detection. The strict signer anchor detects data-directory signing records that fall behind the preserved anchor. Preserve both during recovery.
- Host migration. Preserve identity, signing records and the signer anchor; retire the old signer before moving to a new host. Follow the published operator guide.
5. Key-evolving signatures (KES).
STATUSImplemented — in testing; activation disabled
Each validator signs with a key-evolving signature key. The key moves forward one period at a time and the keys of past periods are erased, so a key compromised today cannot sign for earlier periods (forward security).
| Parameter | Value |
|---|---|
| Scope | Per validator |
| Period | 90 epochs (24 h) |
| Tree depth | 12 (≈11 years of periods) |
| Rotation | Automatic before expiry; no recurring manual signing |
| Domain binding | Signed messages are bound to the network domain, validator index, key root, depth and period |
| Forward security | Keys of past periods are erased |
| Vote size | ≈8.7 KB |
6. Bloch L2 mainnet.
STATUSActivated on mainnet at epoch 5850; operations launching
Bloch L2 is an EVM network settled on Bloch L1 with zero-knowledge validity proofs.
| Parameter | Value |
|---|---|
| Execution | EVM |
| Chain ID | 700770 (0xab162) |
| Native coin | BLCH, 18 decimals on L2 |
| Settlement | Bloch L1, SP1 zero-knowledge proofs (Groth16) |
| Proof cadence | One L2 block per proof (≈13–15 min) |
| Withdrawals under 100 BLCH | After 64 L1 blocks |
| Larger withdrawals | 3-of-5 post-quantum attestor signatures and 2,880 L1 blocks |
| Public RPC and explorer | Coming |