ChainFeeds Research’s PRO issue #160 rounds up recent developments across Bitcoin protocol work, Ethereum governance discussions, new research and recently published papers. The issue is anchored by three Ethereum topics: variable slot timing, lower-bandwidth gossip and a peer protection design for execution-layer nodes.
EIP-8198 discussion focuses on making slot time adjustable before cutting it
Ethlabs compiled recent community discussion around EIP-8198, or Quick Slots, as part of a broader push to move Ethereum beyond its current 12-second slot cadence.
The proposal is not framed as a direct change from 12 seconds to a single new value. The first step is to turn SLOT_DURATION_MS from a fixed constant inside clients into a runtime parameter that can be updated in a hard fork, while also removing client-side logic that assumes a 12-second slot. After that, devnets and performance testing would be used to determine how short Ethereum can safely go. The current draft uses 8 seconds as a target, but that value may still change depending on test results.
The immediate upside is a shorter wait for users. Transactions would land onchain faster, exchange deposit crediting and onchain payments would take less time, and finality would speed up because epoch time would also shrink.
For DeFi, shorter block intervals would make onchain pricing more timely, reducing the gap between automated market makers and external markets. The issue also notes that this would shorten the time builders hold blocks, lowering the value of the builder “free option” in proposer-builder separation. For Layer 2 networks, based rollups would inherit faster Layer 1 block production directly, and designs that rely on L1 for cross-rollup communication would see lower interoperability latency. In Ethlabs’ view, a shorter slot is not only a user experience upgrade; it would also affect market efficiency, cross-L2 composability and some censorship-resistance properties.
The main constraint remains whether the network and clients can operate inside a tighter time window. Block propagation, verification, attestation aggregation and local block building would all need to finish sooner. Because of that, the EIP also assumes that gas limits, blob counts, issuance and validator churn would need to be adjusted alongside slot time so that per-second throughput and core security properties stay broadly unchanged.
Ethlabs argues that the practical route is to build the variable-slot infrastructure first, then shorten slots gradually based on observed performance, much as Ethereum has approached gas-limit increases. That could mean moving from 12 seconds to 10 or 8 seconds first, then testing whether the network can support even shorter slots later.
Bitcoin protocol updates include Utreexo IBD optimization and new BIPs
Implicit deletion for Utreexo initial block download
In the Bitcoin section, Davidson describes a new way to optimize Utreexo initial block download, or IBD.
Utreexo allows a node to keep only a small set of Merkle roots instead of the full UTXO set. The trade-off is that sync requires extra downloads of UTXO inclusion proofs, which in theory can push IBD bandwidth close to double. The proposed method combines future-spend information from Swift Sync so that outputs known to be spent later can be identified at creation time. That makes it possible to use “implicit deletion” and skip later explicit deletion steps, sharply reducing proof data requirements.
The approach also makes much of IBD parallelizable. Tests cited in the issue show that even on low-cost hardware such as Raspberry Pi devices, synchronization is constrained mainly by network bandwidth rather than CPU resources. The method is aimed at historical sync, however. Once IBD is complete, nodes would still return to the standard Utreexo proof and deletion flow.
Post-quantum Lightning Network
Bitcoin Optech Newsletter #424 is also cited for work by Ahmet Kurt and others on a post-quantum Lightning Network, or PQLN. The proposal upgrades offchain Lightning protocols so that gossip, the transport layer, invoices, offers and onion routing can support post-quantum cryptography.
The main cost is bandwidth and storage. A PQLN node would need to download roughly 10x as much data and store roughly 9x as much, while the compute burden stays relatively small. Onchain funding and other components still depend on Bitcoin’s consensus layer, so those parts cannot be addressed through a Lightning-only upgrade.
BIP138 and BIP461
BIP138 defines a compact encryption format for non-seed wallet data such as wallet descriptors and BIP388 wallet policy data. It also allows multisig participants to recover the relevant descriptor using only their own seed.
BIP461 defines a deterministic ECDSA signing algorithm so that the same private key signing the same message always produces the same signature. That can be used to compare outputs from two independent signers and detect malicious hardware that leaks private-key information through nonce manipulation.
Ethereum client formal verification viewed through the TCB lens
Ethereum Foundation researchers George and Kev examine how Ethereum clients could be formally verified by looking at the problem through the Trusted Computing Base, or TCB.
TCB refers to the part of a system that still has to be trusted by humans rather than proved correct mathematically. That includes client code, compilers, verification tools and even the specification itself. The paper’s framing is that formal verification does not remove trust outright. It tries to shrink the TCB so that fewer components require manual review.
For Ethereum clients, the system can be split into modules. Relatively self-contained components such as cryptography, SSZ and fork choice are easier to verify. Network and I/O modules, which interact with a large amount of external state, are much harder and are described as “dirty modules.”
One approach is to treat those hard-to-verify modules as untrusted by default. Any data coming from the network layer, for example, can be handled as malicious input and checked by verified modules such as signature validation and parsing. In that model, a bug in the network module behaves more like receiving bad input from a malicious peer and does not immediately break the security of already verified components.
The longer-term direction is to keep pushing the verified boundary outward, covering parsers, gossip rules and sync logic so that malicious messages cannot crash a client or force unbounded resource consumption.
The harder question is how to extend those proofs all the way to the binary users actually run. The issue compares several paths: automatically translating Rust into Lean4, writing key modules or even a full client directly in Lean4, implementing critical components in RISC-V assembly so a conventional compiler can be removed from the TCB, or using languages paired with verified compilers.
Each route brings the proof closer to machine code and reduces the number of trusted components, but each also moves further away from how Ethereum clients are built today. The more realistic outcome, the issue suggests, may be a hybrid model: stronger formal methods for core modules such as cryptography, and traditional languages for more complex networking logic, with cleaner interfaces used to contain risk.
Snappy with memory cuts gossip traffic in mainnet testing
Community member Nashatyrev explored a way to reduce Ethereum P2P gossip bandwidth in a piece titled “Snappy with a memory: ~40% less gossip traffic.”
Right now, each gossip message is compressed independently with Snappy. That means the compressor cannot take advantage of repeated content across adjacent messages. The same topic string appears again and again, and in a single slot many attestations and aggregates carry the same attestation data.
The proposal is to give Snappy a memory layer. Each peer stream would keep a small amount of historical data, allowing new messages to reference bytes that were already sent earlier instead of transmitting the same content in full every time.
Mainnet data tests cited in the issue show that with only a 64 KiB history window, a normal node could cut received gossip traffic to about 73% of current levels. A node subscribed to all attestation subnets could reduce that to about 63%. Attestation data itself fell to roughly 42%. The reason is that repeated attestation data often needs to be transmitted in full only once per stream, after which it can be referenced. What remains is mostly signatures and validator indices.
The proposal was also tested on three Teku mainnet nodes. In an environment where attestations represented the large majority of traffic, compressed network data dropped to about 44% of the original level, while the nodes still tracked the chain head normally.
The change is presented as relatively small in scope. The existing ssz_snappy message format and current gossip validation flow can stay in place, with an extra compression layer added around the stream itself. CPU costs were described as low: decompression was close to negligible in testing, compression used less than 1% of a single core, and each peer needed only a few dozen kilobytes of extra history cache.
That makes the idea relevant for an environment with Fast Finality, more attestation traffic and shorter slots, where bandwidth pressure on the P2P network could be reduced without modifying the consensus protocol.
CHAMP adds a protection layer on top of random churn
Csaba Kiraly proposed CHAMP, short for Chain-Anchored, Multi-dimensional Peer Protection, as a way to improve how Ethereum execution-layer nodes select and retain peers.
Today, Geth periodically disconnects some peers at random and connects to new ones. That random churn helps keep the network open to new entrants and lowers eclipse-attack risk. The drawback is that it does not distinguish between peer quality. A peer that consistently delivers valid transactions first can be dropped with roughly the same probability as a peer that contributes very little.
CHAMP does not remove random churn. It adds a protection layer above it. It also avoids collapsing all peer behavior into one composite score, because different kinds of performance are hard to weight against one another. Some peers are best at first-seen transaction propagation, some excel at delivering transactions that later make it onchain, and some answer requests quickly.
Instead, CHAMP ranks peers separately by dimension and protects roughly the top 10% in each one. A peer that stands out in any single category can temporarily avoid random disconnection.
- Peers that first sent a transaction to the node and that transaction later reached the chain head
- Peers tied to transactions that were eventually finalized
- Peers that respond quickly to Get Pooled Transactions requests
The first two signals are the most important because they are checked against onchain outcomes. A node records which peer first relayed a given transaction, and credit is only assigned if that transaction later enters a block, or even reaches finality. That design avoids overreliance on self-reported or easily manipulated offchain reputation systems.
Protection is not permanent. All signals decay under an exponential moving average, or EMA. A recently active peer can gain protection quickly, but if it stops contributing, its ranking drops and it returns to the random churn pool over time.
Even if the three protection dimensions had no overlap, only about 30% of peers would be protected at most. That leaves at least about 70% of connections available for ongoing random rotation. The structure is simple: churn keeps searching for new peers, while protection keeps useful peers from being discarded too easily.
According to the issue, protection based on transaction inclusion has already landed in go-ethereum v1.17.5, while request-latency protection is still under development. More dimensions, such as blob data service quality, could be added later. The 10% protection ratio, the EMA parameters and the long-run effect on network topology and Sybil resistance still need more mainnet validation.
MEV research roundup and paper highlights
The issue also points to The MEV Letter #154, a Flashbots newsletter focused on MEV research, and lists several highlights.
- “When AI Agents Meet MEV: Cross-Chain Arbitrage in the Agentic Economy” studies how autonomous AI agents execute cross-chain arbitrage and how trade size, adaptive routing and randomization affect profitability and front-running risk.
- “ETH-TraceBench: A Large-Scale Event-Stream Benchmark for Ethereum DeFi” introduces a benchmark built on Ethereum event logs to test DEX trade classification and liquidation-detection models across changes in time, protocols and contracts.
- “When Data Binds Execution: Dynamic Simulation of EIP-7999’s Multidimensional Fee Market” simulates how BAL data costs, data limits and propagation time affect throughput under EIP-7999’s multidimensional fee market.
- “Post-Glamsterdam One-dimensional Fee Market and Comparison with EIP-7999” compares a one-dimensional fee market after Glamsterdam with EIP-7999, looking at differences in execution and state growth.
- “Quick blocks without quick slots” proposes generating multiple execution payloads inside one slot without shortening the slot itself, and examines implications for confirmation guarantees and multi-block MEV.
- “Things That Help Shorter Slots” reviews several techniques that could help Ethereum shorten slots, including faster data propagation, pipelined execution and lower validator workload.
- “Towards Encrypted Mempools from Threshold IBE without Batching” proposes a Threshold IBE encrypted mempool design that does not require batch decryption, fixing inclusion and ordering before key release while also identifying unresolved cryptographic requirements.
- The video “Ethereum’s Next Upgrade Could be The Most Bullish One Ever” features Julian Ma, Derek Chiang and binji discussing Quick Slots, account abstraction, privacy and Ethlabs’ research agenda.
- The video “Private DeFi Is Coming: Why Privacy Is Ethereum’s Next Frontier” features Thomas Thiery discussing current onchain privacy work, the Ethereum Privacy Roadmap and potential applications for privacy infrastructure in DeFi.
Paper tracks AI-agent cross-chain arbitrage across Ethereum, Arbitrum and Base
The issue closes with a paper from Fordham University on the returns and MEV risks faced by autonomous AI agents conducting cross-chain arbitrage.
Based on roughly 23,000 Uniswap V3 transactions across Ethereum, Arbitrum and Base, the paper finds that L2-to-L2 arbitrage is generally more likely than L1-to-L2 arbitrage to cover cross-chain costs. Its dynamic path-selection algorithm improved performance by about 11% on average relative to a baseline strategy. Adding moderate randomization cut the agent’s exposure to MEV risk by more than 50% while sacrificing only a small amount of profit.
