yudizou

[zkSecurity @zksecurityXYZ]

The first two known exploits against live ZK circuits just happened, and they weren't subtle underconstrained bugs.

They were Groth16 verifiers deployed without completing the trusted setup ceremony. One was white-hat rescued for ~$1.5M, the other drained for 5 ETH.

🧵

[Blockstream Research @blksresearch]

Full write-up and discussion:
https://t.co/CAOOdO4RCQ

Reproducible benchmarking code:
https://t.co/l2XBG3ef0S

[Blockstream Research @blksresearch]

What happens to unmigrated coins if signatures break under quantum attacks?
Freezing may not be necessary.

Instead, coins could be spent by proving knowledge of something an attacker doesn't have (seed or public key).

Is this practical?

@olkurbatov benchmarks current provers.

[Justin Drake @drakefjustin]

Introducing strawmap, a strawman roadmap by EF Protocol.

Believe in something. Believe in an Ethereum strawmap.

Who is this for?

The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™.

What is the strawmap?

The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks.

What are some of the highlights?

The strawmap features five simple north stars, presented as black boxes on the right:

→ fast L1: fast UX, via short slots and finality in seconds
→ gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving
→ teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling
→ post quantum L1: durable cryptography, via hash-based schemes
→ private L1: first-class privacy, via shielded ETH transfers

What is the origin story?

The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism.

Why the "strawmap" name?

"Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons:

1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process.
2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views.

The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes.

What is the strawmap time frame?

The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules.

What do the letters on top represent?

The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star").

What do the colors and arrows represent?

Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom.

Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups.

What are headliners?

Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively.

(L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.)

Will the strawmap evolve?

Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document.

Can I share feedback?

Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.

[Georg Wiese @georgwiese]

I recently went through the exercise of applying logup* (Soukhanov) to implement Twist and Shout (Setty & Thaler). As a result, we can have memory checking arguments with very cheap commitment costs using hash-based commitment schemes! ↓

[quintus (sovs arc) @0xQuintus]

post here : https://t.co/rx2xHedUgU

tl;dr:
* Modern TEEs are not physically secure and this attacks serves as a reminder.

* The attacks do not require an update to our systems or plans. All our current systems have checks to make sure infra is running in vetted clouds. Azure, GCP etc. are part of the trust model

* We have been aware of this limitation for a while so we are doing a bunch of work to get to a permissionless system through a system of slowly relaxing the trust model

* In the short run, we are working on ways to allow nodes in the cloud to prove that they are in the cloud - this makes it easier to be permissionless within the cloud

* There are a bunch of different folks working on dealing with physical (and supply chain) attacks. This includes the Trustless TEE Initiative which was born in FB and is working towards open source silicon that is secure against attacks like these (and many more).

* Outside of Trustless TEE, there are a bunch of people working on physically secure hardware. There are a lot smarter robots and AI models going out into the world and people need to secure them (and the data they hold/process).

* Vitalik also recently announced Vensa which is working on open source and secure silicon

Still bullish TEEs. There isn't and won't be a complete replacement for many years if ever, and we are very excited about the work we and the rest of the community are doing and bullish TEEs.

[a16z crypto @a16zcrypto]

Our latest State of Crypto report is here.

The main theme for the year is the maturation of the crypto industry:

• Traditional financial institutions and fintechs launched crypto products
• DeFi and stablecoins went mainstream
• Blockchains got faster and cheaper
• The regulatory shift in the U.S. revived builder confidence

Find the full 2025 State of Crypto report here: https://t.co/SHky91Gpml

See below for a few highlights.

[Oleksandr Kurbatov 🇺🇦 @olkurbatov]

Post-quantum provers for P2PKH output (signature verification + address formation correctness)

[Jacob @jacobeverly]

Reminder if you haven't already to read this, POVW is the first mechanism to incentivize ZK proving.

This will play a critical part of ZK's global adoption plan

[Artem Chystiakov @Arvolear]

Introducing ZEX v0.1, a confidential peer-to-peer DEX that requires no protocol-level modifications or co-processors to operate.

Privacy assumptions impose very tight constraints, making DeFi use cases almost impossible to implement. Confidential tokens are usually very limited in functionality, enabling only encryption of balances and push-only transfers.

The ZEX v0.1 protocol aims to defy the odds. It extends the cWETH-like confidential tokens with confidential approvals and transferFrom operations, allowing confidential peer-to-peer swaps (and other protocols) to be implemented.

Although very heavy on the UX side (and gas-wise), requiring multiple ZK proofs to be verified within the same transaction, and potentially leaking confidentiality in some edge cases, ZEX shows that native confidential DeFi on Ethereum is not a dream anymore.

*ZEX is still a draft and there are security issues to consider. We will try to properly address them in the future revisions of the protocol.

[Thomas Coratger @tcoratger]

1/18
Ethereum L1 scaling isn’t one project: it’s a stack of parallel workstreams. Here’s a developer-focused map of what’s shipping, why it matters, and how the pieces fit together.

From @adietrichs talk at Frontiers 2025:

https://t.co/yz2QqdXHs8

[RareSkills @RareSkills_io]

New blog post is up:

How Ethereum Address Derivation Works (Wallets, CREATE, and CREATE2).

The formulas for address derivation are simple, yet this article clocks in at over 4,000 words.

It's not just about the formulas to derive addresses -- it's about what goes into the formula that requires some depth of understanding.

Among other things, we cover:

- a brief tutorial on RLP encoding (needed for understanding EOA addresses and CREATE)

- how EIP-161 affects address prediction in EOAs vs contracts deployed with CREATE

- how EIP-2681 informs our understanding of why EIP-1014 (Create2) injects a 0xff into the address derivation

- how to deploy two mutually dependent contracts without a factory or setter function

Get ready to learn a lot!

Link in the reply.

[ziskvm @ziskvm]

🚀 ZisK v0.10.0 is out!

✅ Lots of small fixes
⚙️ Performance improvements
💥 Now runs with < 48 GB RAM!
A big step forward in efficiency—give it a try!
🔗 https://t.co/NU9YrYxJy3
#ZK #ZKProofs #ZisK #Ethereum

[Miden @0xMiden]

𝗠𝗶𝗱𝗲𝗻 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲𝘀 #𝟭
What’s something you can build on Miden that isn’t possible in the EVM?
Let’s look at a central limit order book (CLOB) – built entirely with notes.
Fast, non-custodial, privacy-focused trading.

[Kostas Kryptos @kostascrypto]

🚨 BREAKING: Sui Research just dropped a major breakthrough in quantum transition of "some" blockchains. Unfortunately it works for Sui, Solana, Near, Cosmos and other EdDSA-based chains, but not for Bitcoin and Ethereum 😢

Here is the paper: https://t.co/UixfsQz7wz

*Afaik this is the first backward compatible quantum-safe upgrade path for blockchain wallets to avoid future forks or freezing accounts.

...and why that’s huge 🧵👇

💀 There’s a non-zero chance that today’s wallets could become vulnerable to quantum adversaries in the coming decades.

While I personally doubt we’re anywhere near quantum supremacy that can break cryptography soon, the growing concerns, and new guidance from security agencies recommending algorithm upgrades by 2035, should serve as a wake-up call. Even if much of this is perception-driven, our community must be prepared to eventually transition.

Once quantum computers arrive, millions of wallets, including Satoshi’s, could be drained instantly. If your public key is visible, it will eventually be cracked.

Lost keys, deceased owners, cold storage... all at risk (these will be the first victims).
Billions in crypto sit in “sleeping” wallets that may never be updated or transfer their assets out.

💡 Our solution:
We found a way for wallets using EdDSA (e.g., Sui, Solana, Near and co) to prove ownership securely after quantum, without revealing secrets or touching the wallet to quickly transfer their coins. Surprisingly a small detail on how EdDSA private keys are derived compared to ECDSA makes a huge difference on quantum readiness. TL;DR a simple hash invocation over a seed and not directly picking elliptic curve scalars as private keys saved the game!

🔐 No re-signing. No address change. Zero downtime.
Just a zero knowledge proof that says: “I still control this wallet, but now signing protected against quantum hackers"

🚀 Built on Ed25519 key derivation (SLIP-0010) and zk-STARKs / Ligero

🛡️ Works for sleeping and lost accounts, multisigs, treasuries, and cold storage

📈 Protects real users & institutions, not just future chains, but your today’s mnemonic based wallets too

👨‍🔬 Developed by @SuiNetwork, @Mysten_Labs and @GeorgeMasonU applied and theoretical cryptographers, congrats to Foteini and Arnab whose help was paramount!

*We’re already in contact with the teams behind @ligero_inc and @SoundnessLabs, but we’ll also approach governments and major organizations like Google (which has already begun exploring Ligero ZK proofs) to pursue an implementation, and if possible, make it a global standard.

Maybe those who chose Ed25519 over ECDSA were lucky or just smart. Personally, I want to thank one of my first crypto instructors, Daniel Bernstein (@hashbreaker) the inventor of EdDSA, who taught at the EU ECRYPT summer school in Samos back in 2007. He planted a spark that made me obsess over every detail of the algorithm and maybe without that, I wouldn't be here today as a scientist.

[Muthu Venkitasubramaniam @mvenkita]

1) On my M4, running the Ligetron speed test in Chrome, I get ~10K Poseidon hash calls and ~250 EdDSA verifications per second. Try it here: https://t.co/cvVF8bhuvQ

This translates to proving a transaction block in under a minute on an M4 browser if Ethereum used EdDSA and Poseidon.
Here's how we plan to achieve real-time proving for ECDSA (over secp256k1) and KECCAK:
👇

[Zac @Zac_Aztec]

Aztec and the EF are teaming up to embed privacy as a core value of our ecosystem. Without privacy, blockchain is a shadow of what it could be. What it needs to be.

https://t.co/J1eKVtgnat

[Thomas Coratger @tcoratger]

Foundations of High-Speed Cryptography course by @Ingo_zk

https://t.co/fh9rtEHTZs

[Giacomo Fenzi @GiacomoFenzi]

Excited to share that I've been awarded a research grant from the @ethereumfndn under the 2025 Academic Grants Round to explore how Ethereum can be made secure against quantum adversaries using hash-based arguments: a critical step for the long-term resilience of the network
🧵👇

[PSE @PrivacyEthereum]

Public Announcement:

🚨 A bug was found in the BinaryMerkleRoot circuit in ZK-Kit. It allowed invalid Merkle tree leaves to generate valid ZK proofs.

This has been fixed in v2.0.0 of BinaryMerkleRoot.

@SemaphoreDevs v4, which relies on this circuit, is being updated accordingly.

All downstream projects using this ZK-Kit circuit and Semaphore v4 were notified in advance.

A new Trusted Setup Ceremony is coming soon. Stay tuned!

Details: https://t.co/FvNRP9bLta