Nethermind Quarterly Update - Q4 - 2025

Aztec
1

Summary

The Nethermind team has focused on a number of workstreams over the last quarter, including engineering with the Aztec Labs Alpha team, protocol analysis and research, devrel and product efforts.

Our major focuses for Aztec:

  • Protocol Research and Development
  • Enable developer engagement
  • Support external protocol integrations

We see these initiatives as a critical part of enabling Aztec’s adoption and overall success as a privacy layer for blockchain.

Our approach is to lead with research, and identify ways that we can directly contribute to the protocol, and translate that into engineering efforts that support and enable Aztec.

In service of bringing awareness to different work streams we’ve opted to share more, which is hopefully informative and helpful as people and projects get involved.

This is the first of many reports to come!

As always, if anyone has any questions please let me know, or reach out. Dm’s open :slightly_smiling_face:.

Workstreams

Engineering :hammer_and_wrench:

  • Protocol work
    • The Nethermind Protocol team completed 29 issues over the past month across:
      • P2P networking
        • A new BatchTxRequester replaces the old serial req/resp with three parallel worker loops (pinned peer, dumb, and smart) that concurrently fetch missing transactions from multiple peers. Peers start “dumb” and are queried with full tx hashes; once they respond with a bitvector of which proposal txs they hold, they’re promoted to “smart” and queried using only compact indices. A new BlockTxRequest/Response wire protocol includes an archive root for anti-spam plus the responder’s bitvector of all proposal txs it has, enabling informed follow-up queries.
          • The system uses batches of 8 txs, 10 parallel workers per phase, a bad-peer threshold of 2, and yields fetched txs incrementally. The legacy collector is kept as a pluggable fallback behind configuration.
        • Additional fixes addressed block-by-hash lookups, sequencer retry loops, L2 multi-checkpoint sync, and JSON-RPC compression for proving agents.
      • Security hardening
        • Multiple Cyfrin audit findings were resolved, including BitVector deserialization validation, validation ordering to run cheap checks first. Wall-clock time usage issues in the sequencer were investigated. The team also introduced MAXIMUM_GOSSIP_CLOCK_DISPARITY for slot boundary tolerance and patched blob field overflow during block building.
      • Transaction pool resilience
        • Strict transaction size and count limits were enforced alongside a reworked eviction strategy and per-fee-payer limits to prevent DoS attacks on the mempool. Nullifier-based transaction replacement logic was implemented to swap lower-fee transactions for higher-fee alternatives when duplicate nullifiers are detected.
      • Infrastructure Testing
        • The full nightly scenario test suite was brought online - covering validator nuke/suppression, reorgs, governance upgrades, and proving with chaos engineering tests that suppress and restart validators across epoch boundaries. Reliability improvements included replacing port-forwards with load balancers, parallelizing test runs, optimizing teardown, and discovering a critical prover broker cache poisoning bug.
      • Network observability
        • A full TPS benchmark suite was deployed covering attestation latency, success ratio, request/response stats, gossip latency, and peer statistics, alongside per-node mempool latency tracking visualized as Grafana heatmaps. Telemetry counters are now initialized to zero on startup for correct Prometheus calculations, and a dedicated JSON-RPC API benchmarking suite was created.
      • Blob filestores implementation
        • The team designed a blob storage solution for Aztec that addresses the challenge of fetching Ethereum blobs post-Fusaka, where running a consensus layer supernode becomes impractical for many node operators due to high bandwidth and storage demands.
        • The solution leverages Aztec’s existing filestore infrastructure (supporting S3, GCS, and Cloudflare R2) as an additional blob source, allowing nodes to download blobs from cloud storage instead of requiring direct access to an Ethereum consensus client.
        • Blob fetching uses smart ordering - historical syncs check the filestore first, while near-tip syncs try consensus clients first and fall back to the filestore with exponential backoff to account for upload latency.
        • The filestore is kept populated through a self-healing design: sequencers publish blobs during block proposals, and any archiver or validator that fetches blobs from L1 automatically uploads them, filling gaps if other publishers fail. Configuration works at both the per-node and network level, so Aztec can ship default blob source URLs for testnet and mainnet with no extra infrastructure required from operators.
      • Minor bug fixes and improvements in the Aztec node
    • Next Focus:
      • Peer scoring:
        • GossipSub scoring thresholds are being reworked as the current values are too lax, and application-level scoring is being merged with GossipSub scoring following patterns from Ethereum’s Lodestar client. This will enable more accurate identification and penalization of misbehaving peers across the network as well as should improve network stability and lead to fewer peer mesh pruning and peer disconnects.
      • Transaction request/response improvements
        • The BatchTxRequester is being enhanced to stream transactions as they arrive rather than batch-returning after completion, improving responsiveness during block building. Upcoming work includes keeping the peer list in sync with actual libp2p connections and optimizing expensive .toString() calls in HashMap/Set operations within the batch requester.
      • Mempool ingress controls
        • Nodes will be prevented from propagating transactions that were not accepted into their local mempool, reducing spam amplification across the network. Additionally, a minimum fee bump requirement (PriceBump) is being introduced for transactions with clashing nullifiers to prevent infinitesimal-increment replacement spam, alongside RPC-level feedback for senders submitting transactions with insufficient priority fees.
  • Sedge
    • Sedge v1.11.0 released! - Aztec nodes now available :+1:
      • A devrel review on docs, ux, etc is in progress.
  • Wormhole Bridge
    • Aztec contract migration to devnet 3.0.0
    • Quality of life updates
      • Synced with major Wormhole changes.
  • AztecNodes.xyz
    • We are nearing completion!
    • Doing a few additional product reviews to increase value of product.
    • We would love feedback, suggestions or otherwise that could support the product.
      • All thoughts welcome!

Research :light_bulb:

  • Research Focus
    • Protocol Research
    • Based Fallback
    • Forced Inclusion
  • Posts
  • Ongoing Research
    • Co-processing for Aztec
      • Exploration of co-processing capabilities to enhance Aztec’s computational efficiency and scalability.
    • State Protection for Aztec
      • Research focused on protecting state on Aztec, including attack scenario analysis and motivating defense mechanisms to ensure security of private state.
    • Bottleneck analysis
      • Investigation into performance bottlenecks within the Aztec protocol to identify optimization opportunities and improve throughput.
  • Completed research
    • Security of Optimistic Verification
      • Analysis of security properties and vulnerabilities in optimistic verification schemes used by Aztec.
    • Escape Hatch Mechanisms
      • Multiple approaches explored for escape hatch designs.
    • Consensus Exploration
      • Research into L2 consensus mechanisms and alternatives for Aztec.

Product work :bento_box:

  • Protocol integration Template
    • We are working on an aztec protocol integration template, to enable quick and easy protocol integration for protocols.
    • Aave test integration is in progress :+1:
  • Exploring additional ideas
    • Private Trust networks - For AI, or contributions to projects
    • Agentic Privacy - What would x402, 8004, or other integrations would look like.
    • Solver network integration - OIF routing through aztec?

Devrel :technologist:

  • Engineering
    • Zed Editor extension for Aztec-nr - LINK
      • Syntax highlighting for .nr files with Aztec-specific constructs.
      • LSP support via aztec lsp for code completion, go to definition, hover, and diagnostics.
      • Manual formatting via aztec fmt command (see Configuration section).
  • Documentation
    • Efforts underway to examine Aztec documentation and identify challenges, inconsistencies.
  • Content
    • Video incoming on Sedge :slightly_smiling_face:

Opportunities/Challenges

As part of this reporting efforts we wanted to highlight some of the challenges we’ve ran into as we have been operating. This is in no way a critique! Only sharing for transparency. :slightly_smiling_face:

Details:

  • Closed source → Open source Development
    • Naturally working with a team that has been deeply embedded and the sole owner of a project as they migrate from closed source to open source will have some speed bumps as workstreams are shared, and made public.
    • Efforts to support this are already underway (meeting in the coming week)!
      • We are excited to be a part of it, and take on ownership of different components of protocol development as organization around this develops!

Excited to continue working with you all, and build Aztec! :flexed_biceps:

4 Likes