It was great to with @DeFi_Dad and @Nomaticcap about our roadmap for Ethereum protocol privacy on @edge_pod! We discuss Hegota EIPs (7805, 8181, 8250, 8272), PQ privacy, differences with Zcash, etc...

New @Edge_Pod's out! Today, every transaction you make onchain is trackable. But private DeFi on Ethereum is closer than you think. EF researcher @soispoke says it's possible we get native, trustless, censorship-resistant private transactions on Ethereum by next year.

my Hegotá EIP ranking from @etheconomiczone perspective ↳ EIP-7906 (state diff assertions) -> a batch-posting bundle can verify its preconditions on chain and fail fast instead of half landing. best atomicity backstop here ↳ EIP-8025 (optional execution proofs) -> L1 execution proofs feed straight into multi-prover rollup verification ↳ EIP-8250 (keyed nonces) -> parallel nonce lanes end poster-tx livelock. Frames already SFI, so this is gud ↳ EIP-8198 Quick Slots -> sync composability latency is bounded by slot time ↳ EIP-8371 RowDAS -> cheaper blob posting ↳ EIP-8146 BAL sidecars -> cheaper proving ↳ EIP-8304 trustless log/tx index -> trustless derivation ↳ EIP-8272 recent roots for frames everything else: B or below

We reviewed all 60+ EIPs proposed for Hegotá and updated our view on what Ethereum should prioritize. Our rankings follow four themes: 1. Stronger censorship resistance: Ethereum can only become a settlement layer for everyone if it stays neutral toward everyone. We strongly support FOCIL. 2. Faster Ethereum: Shorter slots mean faster confirmations, fresher onchain prices, and faster finality. We strongly recommend Quick Slots to make a first reduction in Hegotá and further reductions easier in subsequent forks. 3. Native account abstraction: Ethereum is long-due for native AA. Frame Transactions bring passkey wallets, sponsored transactions, gas paid in tokens, batching, and better support for privacy and post-quantum security. Adoption will take work across wallets, L2s, and the rest of the stack, and we intend to keep helping with that. 4. Performance engineering: continued L1 scaling & a faster Ethereum. Performance should remain a first-class concern in both client work and protocol design. The gains can go toward more capacity, shorter slots, lower node requirements, or all three. Thanks to everyone who put forward proposals and helped us work through them. We’ll keep updating our view as client and testing teams assess the work involved. PS: find the full view + changelog here: PPS: finally an iPhone that fits all 60+ Hegota EIPs

A note on recursive STARK mempools (EIP-8288) This is an EIP that I am hoping we can get included in I-star (the fork after Hegota) that you can think of as the next step after Frames, that would unlock extreme amounts of power. Particularly: * Ultra-cheap quantum-safe signatures (SPHINCS-). Much of the cost savings comes from the fact that the signature data (~3 kB) does not have to go onchain * Ultra-cheap quantum-safe privacy protocols. Status quo minimum cost for private txs is ~300k if you engineer very well (no one does), status quo quantum-safe is ~10M gas, this could reduce it to low tens of thousands. * Universal support for your favorite new signature or proof scheme without needing EVM changes. Whatever you use (Falcon, ML-DSA, some other lattice-based thing, something code-based or isogeny-based or even more esoteric), you can just wrap it client-side in a STARK, onchain gas cost low tens of thousands just like privacy protocols. Hopefully, Ethereum will never need "please support my favorite cryptographic algo" politics again. * Private account abstraction: keep your account logic private, and in a private location onchain. Then you can make one transaction to change the ownership of all your onchain state - accounts, defi positions, privacy protocol notes, everything - without revealing which objects' ownership you're changing. Here's how it works. Your transaction can include a type of frame that we call a "dependency frame". The frame is a list of statements, asserting claims like "message hash M was signed by SPHINCS- public key P" and "data hash D was proven to satisfy a statement defined by verification key V". When you send your transaction, you send it in an envelope, which includes a signature or a STARK for each statement in a dependency frame. Once the transaction reaches the mempool, nodes aggregate them. Each node runs a loop: wait one tick (eg. 500ms), aggregate all new envelopes (either single-tx or multi-tx) that you've seen, remove any transactions that are expired, generate a STARK recursively proving all dependencies, and send a new multi-tx envelope containing that STARK. Hence, the bandwidth load is bounded: each node's outbound is one STARK (~100-300 kB) per tick, plus each transaction getting broadcasted through the network once (as happens already). The block builder acts as "yet another mempool node", receiving envelopes from the mempool (plus any side channels), generates its own STARK covering the subset of transactions it intends to include in the block, and adds that STARK to the block. Total onchain overhead: one STARK (100-300 kB), plus 96 bytes for each statement being proven. This is what I've called before ( ) "The Proof Singularity". Today, we have all the ingredients to actually implement it. As a developer, this requires a somewhat different workflow than you are used to, but it is conceptually simple. Any signatures or STARKs, you put into a separate frame. Then the main logic that today is verifying a signature or STARK, you replace with checking for the existence of a frame that includes the correct statement as a dependency. Examples of useful statements: * [tx sighash] verifies against [the pubkey at sload(0)] * there exists a secret and a merkle branch such that hashing secret+0 and applying the merkle branch outputs (public) root R, and hashing secret+1 outputs (public) nullifier N * there exists a secret address A, salt S and signature Z such that sload(0) = hash(A, S) and a merkle proof of address A inside a recent ethereum state contains some pubkey D where [tx sighash] was signed by D [this is private account abstraction; all variables except [tx sighash] and sload(0) are private; you can also make D a STARK verification key] * there exists an ML-DSA signature signing [tx sighash], that verifies against an ML-DSA pubkey whose hash is sload(0) At the core, this is moving any compute and data other than bookkeeping "business logic" outside the core path of Ethereum execution, sharding and parallelizing it via the mempool. Notice also that this requires agreeing on a _language_ (aka. an ISA) for the recursive STARKs to define statements in. The current leading candidate is RISC-V. So this would also de-facto be Ethereum adding RISC-V (or something else we decide on) as a canonical ISA - a big decision that should be done carefully, but that I think will be necessary to drive Ethereum forward.

Over the last few months, we've been working with EF researchers and EIP authors on Hegota proposals, implementing them in ethrex and opening our public testnets to users and other client teams. We wanted to share our execution EIP tier list, which follows the EF Protocol team's scoring system and tier definitions. After spending these months building and testing several of these proposals, we're excited to contribute to the discussion of what should come next for Ethereum. We'll also share our consensus EIP tier list soon, as part of a blog post where we'll expand on our thoughts about Hegota.

@trent_vanepps We still have plenty of headroom. When the average blob count reaches 12-13, we should consider bumping the target/max. Keep in mind that we can do BPO forks now, so we do this just-in-time; a month heads up should be sufficient.

The EF Protocol teams are hosting a Reddit AMA on September 16. This is your chance to ask EF Protocol researchers and devs directly. Submit your questions about post-quantum Ethereum, L1-zkEVM, formal verification, the future of state, finality, privacy, and more now! 🔗↓

🍵 New post: Mempool Account Transaction Capacity from Historical Activity (MATCHA) 🍵 tldr: Frame transactions allow apps to define their own validation and gas payment logic. But admitting many pending transactions from one sender creates a DoS risk: a malicious app could invalidate them all with one cheap state change, forcing nodes to repeat the validation work. MATCHA bounds this risk by making each additional admission spend capacity earned through finalized onchain activity. Its goal is to let many users share one sender without having to whitelist applications, paymasters or proof systems.

Frames can be hard to grasp at first because they build on a decade of work to bring native account abstraction to programmable blockchains. But they are the stepping stone we need to build a private, secure, post-quantum future on Ethereum. To me it boils down to focus on shipping a few key EIPs in Hegota: - EIP-8141: Frame Transactions, the core, already scheduled for inclusion - EIP-8250 and EIP-8272: Enable native, trustless private transactions - EIP-7906: Helps protect users against wallet drainers and malicious transactions Frames are also about scaling. It’s often overlooked, but they unlock signature and STARK aggregation (e.g., EIP-8288), reducing the bandwidth and verification costs that make post-quantum transactions so heavy. Security, UX, and scaling in one EIP Hard to beat