Dev Update #2: The Largest Release Since Mainnet

What changed over the last six months, and why it matters if you build on Irys.

TL;DR: Uploads are faster and no longer back up under heavy traffic, block validation is about 20% faster, and the release process is rebuilt.

This is the largest release since mainnet. It covers three areas: performance, reliability, stability, and the release process itself.

Here is what changed.

Faster

Uploads are quicker. A node used to slow down while it saved incoming data to storage. It now saves incoming data to storage in the background and keeps accepting new uploads at the same time, so a burst of uploads no longer creates a backlog.

Blocks clear validation sooner. Every node re-checks every block for itself, and part of that check was repeating a calculation the node had already done earlier in the process. We removed the repeat, and validation now runs about 20% faster. The fast first-pass check that screens out bad blocks before full validation runs is quicker too, so blocks spend less time in the queue. And on blocks full of transactions, the signature checks that used to run one at a time now run at the same time across every CPU core the machine has, so a full block finishes sooner.

Verifiable Delay Function cycles are shorter. The VDF is the cryptographic component that sets the pace of the whole network, and it runs without stopping, so the cost of each cycle adds up. We tightened its innermost loop and brought one cycle down from roughly 1,200ms to 970ms, about 20% per cycle.

Nodes also recover faster. When a node falls behind, it has to work back up to the current state of the chain, and we found its internal timer was slowing that down. With that fixed, a node on testnet caught back up about 2x faster, so the network returns to full capacity sooner after any interruption.

Mining is leaner. The sampling miners run to prove they are storing their data no longer makes memory allocations it does not need, giving that time back to mining throughput.

It holds up under load

A large part of this release went into how a node behaves under stress. Load testing on testnet showed that a single slow or unresponsive peer could tie up memory the node needed for everything else.

A node now detects a peer that has gone slow or unresponsive and stops sending it requests automatically, so those requests no longer build up and consume memory. Fetching block data from a lagging peer no longer retries in a way that compounds. Duplicate work in the block pool is gone. One slow peer no longer affects a whole node, and the apps built on Irys keep working while the node handles the problem on its own.

The VDF now monitors itself as well. It logs each step as it lands, so you can watch its progress on a live node, and it alerts if it stops advancing for a configurable timeout. Before, a stalled VDF gave no signal, and you would only discover it later from the chain height, after the node had already fallen behind. Separately, a new 25ms minimum step duration keeps the VDF from spinning uselessly fast in low-difficulty test environments; this is local and client-side and has no effect on production.

Observability

Observability was an important focus for us on this update. We want an operator to see what the node is doing, when it slows down, and where it slows down, without standing up external tooling. MDBX database metrics are now exposed on the same /metrics endpoint Reth already serves: read and write throughput, page cache hit rates, database size, all visible. Cross-node request lifecycle tracing is in. If a block takes longer than expected to propagate, the trace shows where the time went. Logs and traces ship to a self-hosted Tempo and Loki stack, with no external SaaS in the loop. Detailed chain sync diagnostics are in too: which blocks are pending, which peers are contributing, where the bottleneck is. The sync state is where most "why is this slow" questions land, and now there is a place to look.

The observability stack is also a good surface for agents. Logs and traces from mainnet nodes can be parsed by an agent in real time. From there, an agent can catch a problem and act on it as it happens.

Snapshots

Bringing up a new node used to mean a long wait. To join the network, a node has to reach the current chain state, and the only path to it was replaying the chain from genesis. On a tall chain, that is hours, sometimes days. That was too long, so to solve it, we added snapshot tooling to the CLI.

Here is how it works: irys-cli snapshot export writes a node's full chain state to a portable archive, and irys-cli snapshot import brings up a fresh node from that archive. The new node loads the snapshot and starts validating in minutes, with no genesis replay. It is useful for fleet scaling, disaster recovery, and migrating between hardware.

Easier to build with

A single command now starts a complete multi-node Irys network on your own machine, and a new tool generates a fresh network's starting state from a simple configuration file. Setting up a local or private network now takes a few minutes, giving you a realistic network to build and test against whenever you need one.

How upgrades work now

We rebuilt the release process so you can always tell exactly which version a node is running, and so the act of publishing a new version is all-or-nothing: either the full release goes out, or nothing does.

The downloadable version of the node is now produced before that version is published, so if the packaging process fails partway through, it cannot leave a broken, half-published version behind. Each published version is frozen on its own branch that cannot be altered after release, so a given version is always the same thing every time. Rolling back to an earlier version is a single, deliberate step.

We also strengthened how upgrades are tested. Before one goes out, we run the old and new versions together in automated tests to confirm they agree on the state of the chain and that stored data is unaffected. A node also checks that its database is compatible before it starts, and will not run against one that is not.

Deployment

Beyond the release process, a few smaller changes make a fresh deployment less likely to go wrong:

• Genesis nodes now set expected_genesis_hash automatically.
• NodeConfig ships with sensible defaults for most fields, so operators only override what is specific to their deployment.
• Release Docker images are smaller, and the cluster tooling for multi-node deployments is self-contained.
• Builds embed git metadata, so you can verify exactly which build is running.

Staking and network upgrades

Irys went through two coordinated network upgrades this cycle, both part of a broader overhaul of how staking and commitments work. The first updated the format of staking-related transactions and removed the old format. The second gave stakers control over where their rewards are paid: you set or change your reward address directly, and the network honors it.

Correctness and internals

The most important change here is sealed blocks. Once a block is signed, its contents are fixed, and the code is written so that a signed block's fields cannot be changed afterward. The compiler itself rejects any code that would try. The error this prevents is a signed block being altered after the fact. Catching it in review is good. Making it impossible to write at all is better.

Block headers and bodies are now stored and sent separately, so a node can check a block's header without downloading the full body. The block index moved off the filesystem and into a database, which lets the number of ledgers change as ledgers are added and removed. That flexibility is the groundwork term ledgers will need.

Nodes also gained stable identities and now confirm they are running compatible consensus rules before they connect, so a misconfigured node is turned away at connection time before it can cause problems. Behind all of that, we simplified several large internal systems.

Lastly, we closed three correctness gaps in how ingress proofs are handled. Ingress proofs are the cryptographic receipts a node produces to attest that it received and stored a piece of data. Now, only staked nodes can produce them, duplicate signers are detected, and the valid anchor range is inclusive where it should be.

Dependencies

A few dependency updates round out the release:

• Reth 1.11.1, the latest upstream EVM execution engine.
• Rust edition 2024, unified across the workspace.
• num-bigfloat replaces the rug and gmp-mpfr-sys C library for bigfloat arithmetic. It is a pure-Rust implementation, so there is one fewer native dependency to install and cross-compilation is simpler.

What is coming next

The largest piece of work ahead is term ledgers. Storage on Irys today is permanent: you pay once, and the data is kept for good. That is the right default for a lot of data, and it is the wrong shape for some. Not everything needs to live forever, and paying a permanent price for data with a natural shelf life is a poor trade.

A term ledger is storage with a defined lifespan. You choose how long the data should live, you pay for that term, and when it expires the network reclaims the space. It gives builders a second storage tier to reach for, sitting alongside permanent storage, so the cost of keeping data can match how long the data is worth keeping.

The database change in this release is the prerequisite for term ledgers. We are not putting a date on it yet, as we would rather ship it right than ship it on a schedule.

Closing

If you build on Irys, there is nothing for you to do. The network keeps producing blocks and your apps keep running while we keep improving it. The new thing you can use today is the local-network tooling for development and testing. Term ledgers come next.

If you are still deciding whether to build on Irys, a network becomes dependable one change at a time, in response to how it performs in use, and this release is six months of that work. We will keep publishing these as we go.

More to come.