ChainFeeds Research’s PRO #157 collects recent updates across Bitcoin protocol development, Ethereum governance, research, and new papers. The issue centers on enshrined proposer-builder separation in Ethereum, mnemonic entropy verification, authenticated UTXO discovery, and the gap between deterministic instruction counts and real execution time in a RISC-V interpreter.
ePBS may reduce relay dependence, but not MEV concentration
Ethereum Foundation member mikeneuder.eth outlined Ethereum’s plan to introduce enshrined proposer-builder separation, or ePBS, through EIP-7732 in the Glamsterdam upgrade, and described how that change could alter block production and the MEV market.
Today, roughly 90% of Ethereum blocks rely on MEV-Boost, where relays sit between builders and proposers and supply a trust layer. Under ePBS, part of that structure moves into the protocol. A proposer first publishes a Beacon Block, the builder then releases the Execution Payload that contains transactions, and PTC confirms that the Payload and Blob were made available on time. The setup formally separates block proposal from delivery of execution content.
That change does not mean the MEV market becomes trustless in practice. Mike argues that existing relays are likely to remain in the system as in-protocol builders, while builders and proposers will probably continue to lean on reputation and direct connections rather than fully trustless payment flows. Because P2P quoting comes with latency and throughput constraints, direct links remain more competitive. Auctions could also drift from open bidding toward more private quoting.
If that happens, existing relationships among large builders, relays, and proposers may become even stronger, while smaller builders face a higher barrier to entry.
ePBS also opens room for delayed execution and pipelined execution. By pushing execution work into the next slot, the design could create more time for raising the gas limit and supporting broader scaling. But it also introduces new strategic risks. A builder could decide whether to publish a payload after seeing support for the Beacon Block, creating a free option problem, while operating under tighter timing constraints for both decision-making and propagation.
The broad conclusion in the issue is that ePBS can cut protocol reliance on relays and improve Ethereum’s execution architecture, but it does not automatically fix MEV centralization. It may leave builder competition and market structure even more complicated.
Bitcoin protocol updates
Physically generating mnemonic entropy
Mi Zeng starts with the core question behind wallet mnemonics: whether the random number source is actually reliable. The 12 or 24 words users see when creating a wallet are derived from entropy produced by a wallet’s random number generator. If the underlying randomness is weak, the mnemonic can look perfectly normal while the private key remains vulnerable to brute-force attacks.
Coldcard and Milk Sad are cited as reminders that both hardware and software random number generators can degrade because of implementation bugs. The security requirement is not that the output looks chaotic, but that an attacker cannot predict it.
BIP39 converts raw entropy into mnemonic phrases. A 12-word phrase is built from 128 bits of entropy plus a 4-bit checksum, while a 24-word phrase uses 256 bits of entropy plus an 8-bit checksum. The bits are then mapped in 11-bit chunks to one of 2,048 standard words.
To reduce reliance on an opaque wallet RNG, the piece describes two methods for creating physical entropy directly.
- The first is a mapping method. Coin flips or dice outcomes are converted into 0s and 1s to manually produce 128 or 256 bits of randomness, then matched against the BIP39 word list, with the last word’s checksum computed by an offline tool. The main advantage is transparency, since nearly every step can be checked by the user.
- The second is an entropy extraction method. Full six-sided dice results are recorded, with about 50 rolls for a 12-word phrase and about 99 rolls for a 24-word phrase, then checked across two separate offline tools that implement the same algorithm. This is more efficient, but it relies more heavily on software.
The article’s final recommendation is to stay offline throughout the process, avoid photos and any digital storage, and restore the wallet and run a small-value test before depositing larger assets. The main idea is to turn the deepest layer of mnemonic randomness from an invisible software black box into a physical process the user can generate and verify directly.
Bitcoin Optech Newsletter #420
The issue also summarizes several items from Bitcoin Optech Newsletter #420.
- Core Lightning is preparing a security release. The project plans to publish v26.06.7 as a security patch release. There is currently no indication that the related vulnerability is being actively exploited. Binary files are expected first within about 24 hours, while source code disclosure will be delayed by 14 days to reduce the risk that attackers reverse-engineer the patch and quickly identify the flaw. Once the source is released, users can check that the binaries match the code through reproducible builds.
- Moonsettler proposed general opt-in replay protection for future possible Bitcoin forks. The goal is to give users a way to stop the same signed transaction from being replayed on another forked chain without forcing all users to change transaction formats.
- Ava Chow said Hardware Wallet Interface, or HWI, will gradually stop adding new features, move into maintenance-only status, and eventually be archived. HWI is used by software such as Bitcoin Core to communicate with hardware wallets, but it has long been maintained almost entirely by one person, activity has been limited in recent years, and its Python stack makes reproducible builds and direct packaging into Bitcoin Core harder.
Ethereum research and development
EIP-8304 plus UTXO Proof Tables for authenticated discovery
In “An Evaluation of Authenticated UTXO Discovery with EIP-8304 and UTXO Proof Tables,” researcher Ishika Choudhury examines how wallets could accurately discover their own UTXOs if Ethereum ever adopts a native UTXO design, without fully trusting RPC providers.
The standard eth_getLogs path is simple and fast, but the RPC only returns results and cannot prove that some matching record was not intentionally omitted. To address that, Ishika combines two proof systems.
The first uses EIP-8304’s ordered index and range proofs to show which UTXO events appeared for a given address within a block range, and that the result set is complete. The second uses a per-block UTXO Proof Table, or UPT, to provide the amount, source, recipient, and other fields for each specific UTXO together with a Merkle proof, allowing a wallet to verify the data against the native openings root.
In the shorthand used in the article, EIP-8304 proves that “Bob’s records were all found,” while UPT proves that “the contents of each record are true.”
The study compares three approaches: using eth_getLogs directly, extending EIP-8304 with custom full log entries, and combining EIP-8304 with UPT. In first-time scans of historical data, the traditional receipt/log route is still the fastest because generating and checking proofs carries visible overhead.
UPT’s advantage appears later. Verified UTXO records can be cached locally, so repeated scans need only a small amount of remote data. That makes the approach a better fit for wallet architectures built around verifiability, caching, and selective download.
Same instruction count, very different wall-clock time
Cristian Diaz looks at a practical resource-pricing question in “Same instruction count, 23x the wall clock: working-set effects in a deterministic RISC-V interpreter”: can a fixed number of RISC-V instruction steps provide a stable bound on real execution time across different hardware?
Tests in a deterministic RISC-V interpreter suggest the answer is no, or at least not tightly enough. Two programs can execute exactly the same number of steps and still take dramatically different amounts of time. On the reference phone, 7 million steps took about 26 ms for ML-DSA-44 signature verification, while large-scale pointer-chasing lw memory access reached 619 ms, a gap of about 23x.
The difference is not only about the opcode itself. It also depends on access patterns, working-set size, and the host machine’s cache structure. That means fixed opcode weights alone cannot fully describe true execution cost.
The paper also argues that the weakest hardware is not always the slowest hardware. As the working set grows, the ranking between machines can change. The phone is slower on small working sets, but with a 2 MiB working set, a desktop i5 becomes slower instead. The same machine also shows noticeable run-to-run variation.
Those results point to cache hierarchies, CPU scheduling, frequency, temperature, and background load as additional sources of variance. Diaz does not argue that RISC-V, static charging, or opcode metering is unusable. The point is narrower: deterministic instruction counts guarantee deterministic execution semantics, but they do not automatically provide a tight, hardware-independent upper bound on physical execution cost. A safer resource-limiting model may need to account for runtime properties such as the number of memory pages touched and memory locality.
A post-quantum emergency path for ecrecover
Community member Mira Belenkiy proposed a post-quantum emergency upgrade path for ecrecover. The target is not EOAs directly. Instead, the proposal is meant to give a smoother migration route to a large set of already deployed, non-upgradeable contracts that rely on ecrecover to validate ECDSA signatures.
The core mechanism keeps existing ECDSA behavior, but reserves a special sentinel combination inside (v, r, s), for example v=27 and s=0. Once that combination is detected, the function no longer performs standard public-key recovery. Instead, it interprets r as an index and looks up the corresponding post-quantum signature and verification function inside the signature array of an EIP-8141 frame transaction. This preserves compatibility with legacy OpenZeppelin checks on v and s and avoids misclassifying normal ECDSA signatures. If verification succeeds, ecrecover returns the claimed address. If it fails, it returns the zero address.
The hard part, according to the summary, is not the post-quantum signature itself. It is how to prove that the claimed address actually authorized the post-quantum public key without breaking the established semantics of ecrecover as a pure function. Candidate approaches include storing the public key in account code, deriving the address directly from a public-key hash, or using a dedicated keystore mechanism.
Alternative paths are also listed. Using v=29 is cleaner, but breaks compatibility with older contracts. ERC-1271 offers more flexibility, but may introduce view or state dependencies and could unintentionally widen delegated authority under EIP-7702. Deriving the address directly from a post-quantum public-key hash is the purest route, but it may create irrecoverable mis-send risks. The proposal is framed as a transition design that prioritizes compatibility with existing contracts while changing semantics as little as possible.
MEV research notes
Flashbots has launched a newsletter focused on MEV research. The issue highlights several items from The MEV Letter #151.
- “Pre-FRP: Topological MEV Detection During Block Construction” explores whether topological data analysis on early transaction patterns can identify sandwich attacks before block construction is finished.
- “AMM Yield Maximization: Convergence of the Liquidity Provider and Arbitrageur Roles” studies how AMM Hooks can rebalance pools atomically after each swap, reducing value extracted by searchers or builders and returning more of it to LPs.
- “Greed is good, with one exception” reverse-engineers an onchain arbitrage bot on Arbitrum and shows how it combines golden-section search with a custom simulator to find the optimal trade size while controlling gas costs.
- “Glamsterdam Gas” examines how gas repricing after activation of EIP-8037 and EIP-8038 in Glamsterdam could affect existing Ethereum L1 smart contracts.
- “The new AA debate — 8130 vs Frame Transactions” breaks down the trade-offs between EIP-8130 and Frame Transactions, or EIP-8141, and argues that the two designs are moving closer together, leaving a core choice between a simpler, more structured, less fragmented validation model and a more extensible framework with more account forms.
- “When Multiple Pools Behave Like One: Impact-Constrained Capacity Concentration in Uniswap v3” asks whether multiple Uniswap v3 pools for the same trading pair can materially raise total executable capacity under a fixed price-impact limit when most liquidity is concentrated in one dominant pool.
- The video “All Core Devs - Consensus (ACDC) #185” covers progress on Platåberget and the plan for non-Headliner proposals in Hegotá to move into the CFI / DFI decision stage.
Paper: migration paths in the quantum age
The paper “Cryptocurrencies in the Quantum Age: Migration Paths to PQC,” by Terra Quantum AG, looks at the security threat that quantum computing poses to blockchain cryptography, with a focus on Bitcoin, Ethereum, and Solana.
The authors distinguish among static asset attacks, attacks at spend time, and attacks during initialization. They also review which onchain components are most exposed to quantum attacks and the potential economic losses involved. The paper then discusses migration paths toward post-quantum security, including the use of NIST-standardized post-quantum digital signatures and upgrade paths being explored by Solana, Algorand, and Ethereum.
