Releases: Revertron/Alfis
Release list
v0.10.0
ALFIS 0.10.0 — Dead signer keys are now excluded from consensus (RFC-0003)
This is a mandatory upgrade for all nodes. It changes consensus rules, and the minimum peer version is raised to 0.10.0 — nodes running 0.9.x and older will be disconnected from the network.
Why
Release 0.9.0 (RFC-0002) taught the chain to heal: when a full block could not collect its four signatures because the drawn signer keys were dead, a standby pool completed the lock after a timeout. Healing works — but it treated the symptom. The signer draw is weighted by all-time activity, so keys whose operators disappeared years ago kept being drawn for every new block, and the chain kept falling into the 3–5 day healing wait on nearly every domain registration.
Measured before this release: of the 16 keys eligible for the signer draw, about 7 are dead, carrying ~30% of the draw weight. Roughly every second block stalled.
What changes
Every healed lock window is now treated as on-chain proof of absence. The drawn signers that produced nothing during the entire stall — at least five publicly visible days, while the whole standby pool watched — are considered dead and are permanently banned:
- they are never drawn as signers again;
- they are skipped in the standby (healing) pool rankings, so living keys move up.
The ban list is computed by every node from chain data alone — there are no new messages, block fields, or configuration, and no one can ban a key by any means other than that key's own silence. Two safety valves bound the mechanism: bans stop while fewer than 10 eligible keys would remain (BAN_POOL_FLOOR), and a draw always sees at least 8 candidate keys (BAN_DRAW_MIN), so signer selection can never deadlock.
A key that signed even once during a stalled window — however late — is credited as alive. Banned keys keep all domain rights: registration, renewal, and transfer are untouched. Full details, rationale, and security analysis: RFC-0003 (Russian version).
Effect on the current chain
The rules activate at block 22529. The July 2026 stall already crystallized the first ban batch — the four long-dead keys that caused it (4116…, 1502…, 9A46…, B7FB…, silent since June 2026 or longer) are excluded from the very first draw after activation. Dead weight in the draw drops from ~30% to under 6%, and domain registrations should again lock in minutes instead of days.
For node operators with signer keys
Nothing new is required of you — except what was always expected: keep your node running. A drawn signer that stays silent through an entire healed window (5 days, or 3 in the degraded regime) is banned permanently. Your node logs a warning and shows a UI notification whenever a ban crystallizes. You can audit the ban state of your local database at any time:
cargo run --example ban_check
Other changes in this release
KeysBannedevent: ban crystallizations are reported in the log and the GUI — they never happen silently.- Fixed release packaging: Linux/deb artifacts no longer drop a zero patch component from the version (
v0.10.0is no longer shortened tov0.10). - Minimum peer version raised to 0.10.0.
v0.9.0
Alfis 0.9.0
⚠️ This is a breaking release. The consensus rules changed, so 0.9.0 nodes
are not compatible with 0.8.x and older. Every node operator must upgrade —
the minimum accepted peer version is now0.9.0, and older nodes are disconnected
from the swarm. Please update as soon as you can.
Two big things landed in this release: a brand-new native GUI that replaces the
old resource-hungry web interface, and self-healing — a consensus change that
lets the network recover on its own when too few of a block's signers are online.
🖥️ A new native GUI (goodbye, web view)
Until now the desktop interface was a WebView: Alfis embedded a full HTML/JS UI and
handed it to the operating system's browser engine to render. It worked, but it was
heavy — it dragged an entire web stack into the process just to show a list of domains.
0.9.0 replaces it with a native GUI built on Lumio,
a lightweight retained-mode toolkit that renders directly with OpenGL. The result is
a leaner, faster, snappier app with a much smaller footprint.
What's new on the surface:
- Native rendering — no embedded browser, dramatically lower memory and CPU use.
- System tray icon — Alfis can sit quietly in the tray and keep serving DNS.
- Reworked domain and record dialogs for creating and managing names.
Everything you could do before — create domains, manage records, watch sync and
mining progress — is here, just without the browser engine underneath it. Also fixed
along the way: several UI glitches during sync, including the interface flickering
when peers advertised an incorrect chain height.
🩹 Self-healing: the network can recover from missing signers (RFC-0002)
This is the headline consensus change. The full design lives in
docs/rfc/0002-healing-signatures.md; here's the
short version.
The problem. Every full block (a domain registration or renewal) must be locked by
4 signatures from a set of 7 signer keys chosen pseudorandomly and fixed forever
the moment the block is mined. If fewer than four of those specific keys ever come
online, the block stays unlocked forever — there was no timeout, no re-draw, and no
alternative path. The chain simply stalls, permanently. With signing power concentrated
in a handful of veteran keys, this went from theoretical to real.
The fix: healing signatures. After a full block has been stuck for 5 days, the
missing signatures may be supplied by a standby pool of up to 12 keys derived
entirely from chain history:
- 7 anchors — the most productive keys of all time. Practically impossible to grind
your way into (it takes years of block production to overtake them). - 5 recent keys — the most active keys of the recent window, an open on-ramp that
even pure domain-mining keys can enter through genuine activity.
At least one of the counted signatures must come from an anchor key. That anchor
rule, combined with the 5-day wait, is what keeps healing from being abused to fork the
chain across a network partition.
Why this design:
- Fully automatic. No key ceremony, no configuration, no operator action, no new
message types. Healing signatures are ordinary empty signing blocks — a node holding a
standby key just starts offering them once the timeout passes. - Conservative. It completes the existing 4-signature lock rather than inventing a
new quorum. A healthy network locks blocks in minutes and never touches this path. - Adaptive. If a chain is clearly operating in the healed regime, the timeout drops
from 5 days to 3 so throughput isn't throttled unnecessarily. - Loud on failure. If a genuine irreconcilable fork ever forms, it's now surfaced as
an error and a UI event instead of being silently swallowed.
The change also tightens three long-standing gaps in the lock machinery (enforcing the
lock on incoming full blocks, capping empty blocks over a locked window, and checking key
strength for empty blocks).
Activation. These rules only apply above HEALING_ACTIVATION_HEIGHT — set to the
currently stuck full block — so no historical block is re-judged. This is exactly why old
nodes are incompatible: they'd reject healing blocks (and everything built on them), so
0.9.0 raises the minimum peer version to keep the network together.
Also included as groundwork: RFC-0001, the design for human-gated emergency recovery
in the catastrophic case where nearly the entire key population is lost — a backstop
behind the automatic healing shipped here.
🔧 Other changes
- Updated a large number of dependencies.
- Updated CI and the
guifeature wiring for the new toolkit. - Various small fixes and stability improvements.
Upgrading
Just install 0.9.0 and restart. Your keys and blockchain database carry over unchanged.
Because 0.8.x nodes can no longer participate, please upgrade promptly — a stalled
chain quietly costs real domains as their renewal grace windows expire.
v0.8.11
Important release!
Someone was attacking the blockchain through one old sync protocol weakness. After I've released the 0.8.10 they've wrote me about the attack and complained that I've fixed it too fast.
This release presents more fixes for sync protocol.
- Important fixes of sync protocol.
- More defence against blockchain attacks.
- Updated dependencies.
v0.8.10
Very important fix of sync protocol!
If you have a wrong blockchain, you need to delete it and update ALFIS.
v0.8.9
New Features
- System tray icon — ALFIS can now run with a hidden UI and be shown/restored via tray icon actions (Windows, Linux) (#397)
- Dark theme — Updated UI styles with dark theme support
- Adaptive DNS server selection — NS servers are now selected based on RTT (round-trip time) banding, automatically preferring faster servers
- Adaptive forwarder selection — RTT-based server selection extended to configured DNS forwarders as well
- DNS cache memory limit — Cache now enforces a configurable memory limit instead of growing unbounded
- Bare IP forwarders — Config now accepts plain IP addresses for DNS forwarders (without requiring a full URL)
Bug Fixes & Improvements
- Fixed large DNS responses over DoH — Resolved issue where very large DNS results failed over DNS-over-HTTPS (#411)
- Fixed 0x20 encoding in DNS cache — Cache now correctly handles case-randomized query names
- Disabled 0x20 encoding for NS queries — Prevents issues with authoritative servers that don't preserve query name casing
- Fixed TXT record parsing — Corrected a bug in DNS TXT record deserialization
- Faster initial sync — Blockchain initial synchronization is significantly faster
- Fixed sync regression — Resolved a bug in the new sync logic
- DNS server starts earlier — DNS server now initializes before blockchain sync completes, reducing startup latency
- Windows service improvements — Made the Windows service handler more robust
- Tuned DoH HTTP client — Improved HTTPS client settings for DNS-over-HTTPS requests
- Disabled DevTools & context menu in release builds
Internal / CI
- Updated dependencies
- Updated CI workflows for parallel release builds
- Reduced noisy ureq trace logging
Important notice
The GPG key for the Debian repo has expired. The recommended solution is in #412
v0.8.8
DNS Improvements and Bug Fixes
New Features
- HTTPS DNS Record Support (Type 65): Full RFC 9460 compliant implementation for HTTPS records
Bug Fixes
- Fixed DNS domain name case preservation issues affecting DNS 0x20 encoding
- Fixed primary monitor detection on Linux systems where display detection could fail
Maintenance
- Updated CI for release building
- Updated README documentation
v0.8.7
Key Changes
GUI & Cross-Platform
- Migrated UI from unsupported
webviewtowrycrate for improved Linux compatibility and future stability.
DNS Security Enhancements
- Implemented ephemeral ports for DNS queries.
- Added DNS 0x20 encoding for enhanced security.
Bug Fixes & Improvements
- Automatic config migration for incorrect test port (42440 → 4244).
- Fixed test warnings.
- Updated all dependencies.
This version focuses on improving cross-platform stability and enhancing DNS security features while maintaining compatibility with existing configurations.
v0.8.5
New
- Added Windows service mode.
Bug Fixes & Improvements
- Fixed resolution of TLSA records.
- Improved P2P connectivity.
- Added logging system to know where deadlocks can occur.
- Updated a lot of dependencies.
- Fixed UI for TXT records.
- Possibly fixed the nastiest bug of CPU hogging.
Changes
- There is no MIPS builds, as this architecture was moved to Tier 3. Will find the way to build for them later.
v0.8.4
Bug Fixes & Improvements
- Various fixes and stability improvements.
v0.8.3
Bug Fixes & Improvements
- Some people had complaint about DNS resolver in ALFIS, that it is overwhelmed with requests, and at some point it just stops to handle DNS requests at all. For some reason I didn't see the problem in that code of DNS resolver, but today it hit me - the work handling by all that threads is wrong.
So, the bug of DNS resolver is resolved ;)
Now, if you have threads set to some high number, like 100 or 200, you can lower that significantly. I recommend the number around your CPU core count. It will suffice.