v1.2.2

Changelog - v1.2.2 (2025-10-28)

Code Changes
• Force upgrade to validators

📜 Technical Context
This release fixes an invalid amount on a transaction that had its error upgraded but not deployed on some minority of the network.

The TX Receipt carries error invalid_amount but on nodes not upgraded it was error unknown.

v1.2.1 - testnet

Changelog - v1.2.1 (2025-10-25)

Code Changes
• Added local testnet

📜 Technical Context
This release addresses utility and cleanup.

v1.2.0 - meet the grahams

Changelog - v1.2.0 (2025-10-14)

Bug Fixes

• WASMERVM compiles now with rust 1.89+
• Dont connect to unrouted peers (ips who dropped off BGP) paranoid DataCenters dont like this
• RocksDB long startup sync time off clean start

Code Changes

• Wasmer upgrade v5.0.4->v6.1.0
• A BGP route checker added that uses TCP WHOIS, if whois is blocked you can disable it via CHECK_ROUTED_PEER=n
• RocksDB version upgraded from v7->v10.5.0, compression of longterm data added. Reduces chainsize by 50%~.

📜 Technical Context

This release addresses foundational changes that set the groundwork for further improvement.

v1.1.9

Changelog - v1.1.9 (2025-09-19)

Code Changes

• Added priority broadcasting to seed nodes to improve performance of RPC APIs
• Added more HTTP API for RPC nodes
• Added RPC.API for OFFLINE CLI calls into HTTP RPC ojdes

📜 Technical Context

This release addresses minor performance improvements.

v1.1.8

Changelog - v1.1.8 (2025-09-15)

Fixed

• Fixed a MEV/ChainGrowth attack. Now exec fees burn a portion similar to ETH2, Solana, etc.
• Easy difficulty leading to high fees
• Reporting false chains or other shenanigans

Code Changes

• Reduced exec costs significantly base 3x and storage 3x
• Added dyndiff which adjusts the difficulty based on net solve rate.
• Added new incentivization

📜 Technical Context

This release addresses a large protocol fix improvement from input of our early adopters and users.

v1.1.7

Changelog - v1.1.7 (2025-09-11)

Fixed

• Various exploits related to over-flooding nodes at the network level
• Knocking out online peers
• Reporting false chains or other shenanigans

Code Changes

• Entire Netcode rewrite

📜 Technical Context

This release addresses a large netcode fix that should hopefully set a good core model going forward.

v1.1.6

Changelog - v1.1.6 (2025-08-29)

Fixed

• Prepare peddlebike for epoch 282

Code Changes

• Misc bug fixes
• Epoch contract with peddlebike

📜 Technical Context

This release addresses preparation for epoch 282.

v1.1.5 - sequel

Changelog - v1.1.5 (2025-08-28)

Fixed

• Orphan entries not checking roots

Code Changes

• Orphan entries where not checking roots and were candidates but couldn't be applied to chain
• More RPC APIs added
• Epoch 282 preparation for security updates with (v)erifiable(r)andom_segment being enabled

📜 Technical Context

This release addresses some log spam and chain considering orphans for candidates but being unable to apply.

v1.1.4 - agent smith

Changelog - v1.1.4 (2025-08-21)

Fixed

• Peering flood that causes your node to go offline

Code Changes

• Implemented STUN functionality with a workaround for The Great Firewall (fallback to HTTP IP check)
• Above is skippable by manually setting your public facing IP4 via env PUBLIC_UDP_IPV4=
• Implemented ANR (Amadeus Node Records)
• All new peering requests are met with a challenge

📜 Technical Context

This release addresses a DDOS attack where a malicious agent can force a node to interact with non-existent peers, taxing resources from the node that it goes offline.

Thanks

@xdd3384 for help debugging and rp_filter setting which should prevent spoofed UDP src addr

net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.default.rp_filter=1

v1.1.3

Changelog: v1.1.3

🔧 Core Changes

1. Enhanced Freivalds Verification for Epoch 260+ (Major Enhancement)
   • Files: lib/bic/sol.ex, lib/bic/base.ex, lib/node/node_state.ex
   • What Changed: Introduced new verification method Blake3.freivalds_e260() that uses VRF-based randomness instead of purely random values
   • Technical Details:
   • Solutions for epochs ≥260 now use Blake3.freivalds_e260(sol, vr_b3) where vr_b3 is Blake3 hash of the entry's VR (Verifiable Random value)
   • Legacy solutions (epochs <260) continue using original Blake3.freivalds(sol) method
   • Added epoch-aware verification logic with proper fallback handling
   • Impact: This strengthens the cryptographic security of solution verification by using deterministic VRF-derived randomness instead of potentially predictable random values

2. Consensus Environment Enhancement
   • File: lib/consensus/consensus.ex
   • What Changed: Added entry_vr_b3 field to consensus environment mapping
   • Technical Details:
   • New field: :entry_vr_b3 => Blake3.hash(next_entry.header_unpacked.vr)
   • Provides pre-computed Blake3 hash of VR for efficient access during verification
   • Impact: Optimizes performance by pre-computing VR hash rather than calculating it repeatedly during solution verification

3. Helper Function Addition
   • File: lib/consensus/consensus.ex
   • What Changed: Added new chain_muts/1 helper function
   • Technical Details:
   elixir
   • Impact: Provides direct access to mutation data by hash, complementing existing chain_muts_rev/1 function

4. Blake3 Dependency Update
   • File: mix.lock
   • What Changed: Updated Blake3 library from commit 13b02ab to 396c613
   • Technical Details: This update likely includes the new freivalds_e260/2 function implementation
   • Impact: Enables the new epoch-260+ verification functionality

5. Version Bump
   • File: mix.exs
   • What Changed: Version updated from "1.1.2" to "1.1.3"

🛡️ Security Improvements

• Enhanced Solution Verification: The new VRF-based approach in epoch 260+ prevents potential attacks where malicious actors might try to predict or manipulate the randomness used in Freivalds verification
• Backward Compatibility: Maintains full compatibility with existing solutions from earlier epochs while strengthening future ones

🔍 What This Fixes/Improves

1. Cryptographic Security: Addresses potential vulnerabilities in solution verification by replacing pseudo-random values with cryptographically secure VRF-derived randomness
2. Performance: Pre-computing VR hashes reduces computational overhead during verification
3. Code Organization: The new helper function improves code maintainability and provides consistent database access patterns

⚠️ Breaking Changes

• None - all changes are backward compatible and use epoch-based feature gating

📋 Migration Notes

• No action required for existing deployments
• Solutions submitted in epoch 260+ will automatically use the enhanced verification
• Legacy solutions continue to work unchanged

Summary: This release primarily focuses on enhancing the cryptographic security of solution verification for future epochs while maintaining full backward compatibility. The changes represent a significant security improvement in the consensus mechanism without disrupting existing functionality.