Joined December 2024
26 Photos and videos
Pinned Tweet
May 29
๐Ÿ“ข๐Ÿ“ข๐Ÿ“ข we are now devnet5 interop!!! ๐Ÿš€๐Ÿš€๐Ÿš€ which is the culmination of the PQ consensus stack that we have been building and iterating on for @ethereum mainnet. PQ signatures are different from BLS signatures, the current signature machinery of ethereum. But BLS signatures are not Post Quantum secure because breaking elliptic curve cryptography is not an exponential problem for Quantum Computers. But ethereum is being build to last centuries not just decades. To that end @leanEthereum has been working on PQ signature cryptography using hash based signatures which are one time signatures (OTS), and not plainly aggregatable. Not only that they are huge (~1.5kb). So this entire challenge started the "devnets" initiatives of leanEthereum. Herein come's the "leanVM" the ZK rail which can aggregate such signatures and makes the entire PQ strategy possible. We have already been through devnet0 to devnet4, and now devnet5!!! Devnet5 is monumental in that regard, entire block will carry just 1 signature, all aggregated across packed attestations, block signatures (and anything else that will comeup when we backport the spec to mainnet ethereum) However this is one side of the puzzle, to maintain a stable node, one should be able to repack the attestations from a side branch especially if it moves justification and finalization. and Voila again with leanVM magic, we are able to split the attestations that we need to repack from the combined block signature and repack/re-aggregate them into a new block proposer wants to propose. This places leanVM as the centrepiece in the entire ethereum post quantum strategy. and the current aim of all the devnets we have been running is to bring a production level performance and demonstration of the capabilities. There are 8 clients that participate in these devnets each bringing value to the table to add stability and robustness (and chaos lol). Because we know: "There's many a slip between the cup and the lip" Goal of all leanEthereum clients is to remove them, one "slip" at a time (or multiple slips at a time lol). Spec isn't good enough, we need production performance, Spec and production design/performance are unequivocally tied. this isn't just a POC network, this is a proposal for ethereum mainnet! Thats why we have been rigorously running devents, slowly scaling the validators and subnets and discovering and alleviating the issues so that we end up with a production grade PQ signature scheme that ethereum deserves and needs. And this focus is now gonna magnify 1000X now that we believe we are on a spec that can deliver PQ for mainnet. And mind you, the time of need is gonna strike soon. We not only intend to solve this conundrum for ethereum but propose to even upstream to bitcoin so that we have a PQ standard this entire space deserves. And all that based on a humble but extremely powerful leanVM that makes the hashbased cryptography workable for the production grade systems like ethereum and bitcoin. PS: we are currently heavily focused on debugging and scaling devnet4 spec devnets while we have already started to run sims and preliminary interops for devnet5. So stay tuned for further progress that we leanEthereum teams have been cranking out with a steady but heavy dose โ˜•๏ธ. May be all matrix is just โ˜•๏ธโ˜•๏ธโ˜•๏ธ
May 20
๐ŸŽ‰๐ŸŽ‰๐ŸŽ‰ devnet5 spec merged ๐Ÿš€๐Ÿš€๐Ÿš€: block with just a single aggregated signature proof github.com/leanEthereum/leanโ€ฆ this brings @leanEthereum full circle on the "PQ stack" for consensus to upstream it to mainnet PQ centric L* hardfork It includes a very neat feature for splitting the block signature proof for re-bundling it on a side branch even without requiring the constituent signatures that were aggregated! all thanks to awesome EF researchers working on leanVM ๐Ÿฆพ๐Ÿฆพ๐Ÿฆพ now time to build devnet5! comeon lean teams time to harden and show production stability and scale fyi: devnet4 runs are already on for scaling the validators to harden subnets & aggregators lets grind on!
70
43
271
143,366
Jun 12
running SHADOW SIMULATION of zeam devnet5 multi node network 100% 28 core loading 200% 96GB mem DDR5 7200MT/s loading Disk IO engaged on nvme gen5 samsung disk beautiful
1
3
54
PQ registry proposal๐Ÿ‘‡๐Ÿ‘‡๐Ÿ‘‡ Ethereum Quantum Hardness is already incoming
Ethereum is preparing for a post-quantum future. The transition away from BLS signatures starts with a dedicated Post-Quantum (PQ) Public Key Registry. ethresear.ch/t/exploring-theโ€ฆ Here is a deep dive into the design space, XMSS, and how Ethereum will secure its validators. ๐Ÿงต๐Ÿ‘‡
159
zeamETH retweeted
Ethereum is preparing for a post-quantum future. The transition away from BLS signatures starts with a dedicated Post-Quantum (PQ) Public Key Registry. ethresear.ch/t/exploring-theโ€ฆ Here is a deep dive into the design space, XMSS, and how Ethereum will secure its validators. ๐Ÿงต๐Ÿ‘‡
12
52
302
30,726
zeamETH retweeted
Today a crazy quantum story just got wilder. On March 31, the Google Quantum AI team published a landmark result on Shor's algorithm for elliptic curve cryptography. Technically, the paper was a bombshell: a dramatic 10x improvement over the state-of-the-art. As a stunt and wakeup call to the blockchain space, those optimisations were illustrated on secp256k1, the elliptic curve underlying Bitcoin and Ethereum signatures. But perhaps the most striking part of the paper was sociological, not technical. Instead of following standard academic process, the optimisations were kept secret, hidden behind a zero-knowledge (ZK) proof. Google's accompanying blog post mentions they "engaged with the U.S. government". The ZK proof demonstrates the existence of algorithmic improvements without leaking details. Academic censorship with ZK, a historic first! As a co-author of the Google paper I witnessed some of the context surrounding this censorship. To be honest, multiple aspects of that context don't sit well with me. As much as I believe the general public ought to know more, I am limited in my ability to whistleblow. Though let me be clear about one thing: the Google team's professionalism has been absolutely exemplary, and they deserve nothing but praise. Censorship has a way of backfiring. The Streisand effect, where an attempt to bury something only draws more attention to it, is exactly what's unfolding today. First, Google's key optimisation has been rediscovered by the French. And in a thrilling turn of events, a collaborative Shor-at-home challenge just launched. The initiative, available at ecdsa[.]fail, breached a new Shor world record in a matter of hours. Let's start with the rediscovery. Just two months after Google's paper, French quantum expert Andrรฉ Schrottenloher cracks the main secret optimisation. His paper, titled "Optimized Point Addition Circuits for Elliptic Curve Discrete Logarithms", landed on the arXiv today. Big congrats to Andrรฉ, who beat several other nerdsnipped experts to it. In a blog post also published today, Craig Gidney, the world expert on Shor optimisations, revealed that he'd been sitting on this very optimisation for a whole year under censorship pressure. Interestingly, Andrรฉ missed a handful of minor optimisations, both from Google's original publication and from improvements found since. It's plausible there's still plenty of juice left to squeeze out of Shor, and this is exactly what the ecdsa[.]fail challenge is about. The verifier program developed for the ZK proof does double duty, automatically filtering for valid submissions. Dozens of compounding small and micro improvements are rolling in. As of the time of writing there's an 8.4% improvement to Google's circuit, as measured by the product of logical qubit count and Toffoli gate count. Nice! The nerdsnipping ran deeper than anyone expected. Over the last few weeks it became clear it extended well beyond Andrรฉ and other quantum experts. Behind the scenes, a small army of amateurs quietly got to work. Inspired by Karpathy-style autoresearch, they turned AI on Shor. Ironically, the verifier program for the ZK proof makes an ideal reward function for AIs. The barrier to entry for this modern style of research is refreshingly low, with several non-experts, even a teenager, finding nice optimisations. Get in touch if you'd like to join a Telegram group with fellow autoresearchers :) Part 2: neutral atoms and qday The story doesn't end with Google. On the same day Google went public, a stealthy startup called Oratomic published its own Shor paper in a coordinated release. It made a splash, ultimately becoming the most upvoted paper on scirate[.]com, a website ranking arXiv papers. Oratomic's claim was wild. By building on Google's logical optimisations and applying custom physical optimisations for neutral atoms, they claimed just 10K physical qubits were sufficient to run Shor's algorithm on secp256k1. That number is mind-bogglingly low. Knowing essentially nothing about neutral atoms when Oratomic's paper landed, I was intrigued and decided to learn more about the tech. I fell straight down the rabbit hole and spent a couple hundred hours on the topic. I got a little obsessed and watched every YouTube video I could find and spoke to a bunch of experts. My conclusion? The tech is real, very real. Even Google recently decided to start a neutral atom lab, a notable pivot from their sole focus on superconducting qubits. If you care about qday, i.e. the day a quantum computer will break the first piece of cryptography in production, neutral atoms demand your attention. I shared some of my learnings on Shor and neutral atoms in a 30min talk at the ZKProof cryptography conference. You can find it on YouTube by searching "zkproof neutral atom". Here's an interesting observation about this duo of breakthrough papers: neither Google nor Oratomic say a word about what their results mean for qday. No timelines. Zero. Nada. That is especially baffling given that the whole point of whitehat quantum cryptanalysis is to inform qday estimations and help the general public make good decisions. So let me attempt to partially fill the silence, similarly to what Scott Aaronson did in his April 29 post. Given everything I know, including scary non-public information, I now put the odds of qday by 2032 at 50%. 10% by 2030. Anecdotally, the US government has its own date: 2035. Originating at the NSA and later adopted by NIST, it's when branches of the US government will be disallowed from using quantum-vulnerable cryptography. In plain language: with hindsight, that date is a joke and should be discounted entirely. I don't see how NIST avoids being forced to pull it forward by years. Part 3: post-quantum cryptography There are good reasons to sound the alarm today, but please do not panic. Rushing carelessly towards immature post-quantum cryptography is a recipe for disaster. IMO a good target date for migration is 2029, roughly 3.5 years out. 2029 happens to be the date selected by Google, Cloudflare, and the Ethereum Foundation. These days most of my time goes to safely migrating Ethereum towards post-quantum cryptography as part of the broader lean Ethereum effort. There's a lot to do. We need to rip out and replace BLS signatures at the consensus layer, KZG commitments at the data layer, and ECDSA signatures at the execution layer. The plan to get there is compelling, and is based on hash-based cryptography. Within the Ethereum Foundation we've developed a Swiss army knife called leanVM (github[.]com/leanEthereum/leanVM) powered by the magic of hash-based SNARKs. Thanks to truly exceptional work by Emile, Thomas, and others, its performance is derisked. Regarding security, leanVM is a jewel, a minimal zkVM crafted for end-to-end formal verification and maximum security. Want to help? There are two $1M initiatives. First, the Proximity Prize (proximityprize[.]org). Solve a long-standing mathematical conjecture in coding theory, improve hash-based SNARKs, and go home a millionaire. Second, the Poseidon Initiative (poseidon-initiative[.]info), offers $1M for breaking Poseidon, the SNARK-friendly hash function.
408
1,126
6,240
3,698,629
zeamETH retweeted
A year of backtesting for the Fast Confirmation Rule confirms (!) that: - 96% of past blocks would have been fast-confirmed in a single slot. This could mean deposits from Ethereum to L2s or CEXes available in about 12 seconds! - The remaining 4% are usually confirmed fast too, usually much faster than other, less secure confirmation rules such as k-deep confirmations - No false confirmation is ever issued Client implementations continue ๐Ÿซก
We built a simulator for the fast confirmation rule, and replayed a years worth of blocks and attestations on Mainnet. Across 800,000 mainnet slots, roughly 96 out of every 100 slots would have been fast-confirmed within 12 seconds. Zero false confirmations. Read more below!
6
19
179
9,603
May 29
๐Ÿ“ข๐Ÿ“ข๐Ÿ“ข we are now devnet5 interop!!! ๐Ÿš€๐Ÿš€๐Ÿš€ which is the culmination of the PQ consensus stack that we have been building and iterating on for @ethereum mainnet. PQ signatures are different from BLS signatures, the current signature machinery of ethereum. But BLS signatures are not Post Quantum secure because breaking elliptic curve cryptography is not an exponential problem for Quantum Computers. But ethereum is being build to last centuries not just decades. To that end @leanEthereum has been working on PQ signature cryptography using hash based signatures which are one time signatures (OTS), and not plainly aggregatable. Not only that they are huge (~1.5kb). So this entire challenge started the "devnets" initiatives of leanEthereum. Herein come's the "leanVM" the ZK rail which can aggregate such signatures and makes the entire PQ strategy possible. We have already been through devnet0 to devnet4, and now devnet5!!! Devnet5 is monumental in that regard, entire block will carry just 1 signature, all aggregated across packed attestations, block signatures (and anything else that will comeup when we backport the spec to mainnet ethereum) However this is one side of the puzzle, to maintain a stable node, one should be able to repack the attestations from a side branch especially if it moves justification and finalization. and Voila again with leanVM magic, we are able to split the attestations that we need to repack from the combined block signature and repack/re-aggregate them into a new block proposer wants to propose. This places leanVM as the centrepiece in the entire ethereum post quantum strategy. and the current aim of all the devnets we have been running is to bring a production level performance and demonstration of the capabilities. There are 8 clients that participate in these devnets each bringing value to the table to add stability and robustness (and chaos lol). Because we know: "There's many a slip between the cup and the lip" Goal of all leanEthereum clients is to remove them, one "slip" at a time (or multiple slips at a time lol). Spec isn't good enough, we need production performance, Spec and production design/performance are unequivocally tied. this isn't just a POC network, this is a proposal for ethereum mainnet! Thats why we have been rigorously running devents, slowly scaling the validators and subnets and discovering and alleviating the issues so that we end up with a production grade PQ signature scheme that ethereum deserves and needs. And this focus is now gonna magnify 1000X now that we believe we are on a spec that can deliver PQ for mainnet. And mind you, the time of need is gonna strike soon. We not only intend to solve this conundrum for ethereum but propose to even upstream to bitcoin so that we have a PQ standard this entire space deserves. And all that based on a humble but extremely powerful leanVM that makes the hashbased cryptography workable for the production grade systems like ethereum and bitcoin. PS: we are currently heavily focused on debugging and scaling devnet4 spec devnets while we have already started to run sims and preliminary interops for devnet5. So stay tuned for further progress that we leanEthereum teams have been cranking out with a steady but heavy dose โ˜•๏ธ. May be all matrix is just โ˜•๏ธโ˜•๏ธโ˜•๏ธ
May 20
๐ŸŽ‰๐ŸŽ‰๐ŸŽ‰ devnet5 spec merged ๐Ÿš€๐Ÿš€๐Ÿš€: block with just a single aggregated signature proof github.com/leanEthereum/leanโ€ฆ this brings @leanEthereum full circle on the "PQ stack" for consensus to upstream it to mainnet PQ centric L* hardfork It includes a very neat feature for splitting the block signature proof for re-bundling it on a side branch even without requiring the constituent signatures that were aggregated! all thanks to awesome EF researchers working on leanVM ๐Ÿฆพ๐Ÿฆพ๐Ÿฆพ now time to build devnet5! comeon lean teams time to harden and show production stability and scale fyi: devnet4 runs are already on for scaling the validators to harden subnets & aggregators lets grind on!
70
43
271
143,366
May 29
fyi: this post isn't some AI slop ๐Ÿ’ฏ% handcrafted with real passion and belief in our work ๐Ÿฆพ
2
13
661
zeamETH retweeted
One day, quantum computers will be able to crack the cryptography that secures almost every blockchain. Most of crypto is ignoring that. Ethereum isn't, where devs are constantly cooking on the fix. @leanEthereum's devnet5 is a big step. A whole block's worth of the new quantum-proof signatures, now squeezed into one.
May 29
๐Ÿ“ข๐Ÿ“ข๐Ÿ“ข we are now devnet5 interop!!! ๐Ÿš€๐Ÿš€๐Ÿš€ which is the culmination of the PQ consensus stack that we have been building and iterating on for @ethereum mainnet. PQ signatures are different from BLS signatures, the current signature machinery of ethereum. But BLS signatures are not Post Quantum secure because breaking elliptic curve cryptography is not an exponential problem for Quantum Computers. But ethereum is being build to last centuries not just decades. To that end @leanEthereum has been working on PQ signature cryptography using hash based signatures which are one time signatures (OTS), and not plainly aggregatable. Not only that they are huge (~1.5kb). So this entire challenge started the "devnets" initiatives of leanEthereum. Herein come's the "leanVM" the ZK rail which can aggregate such signatures and makes the entire PQ strategy possible. We have already been through devnet0 to devnet4, and now devnet5!!! Devnet5 is monumental in that regard, entire block will carry just 1 signature, all aggregated across packed attestations, block signatures (and anything else that will comeup when we backport the spec to mainnet ethereum) However this is one side of the puzzle, to maintain a stable node, one should be able to repack the attestations from a side branch especially if it moves justification and finalization. and Voila again with leanVM magic, we are able to split the attestations that we need to repack from the combined block signature and repack/re-aggregate them into a new block proposer wants to propose. This places leanVM as the centrepiece in the entire ethereum post quantum strategy. and the current aim of all the devnets we have been running is to bring a production level performance and demonstration of the capabilities. There are 8 clients that participate in these devnets each bringing value to the table to add stability and robustness (and chaos lol). Because we know: "There's many a slip between the cup and the lip" Goal of all leanEthereum clients is to remove them, one "slip" at a time (or multiple slips at a time lol). Spec isn't good enough, we need production performance, Spec and production design/performance are unequivocally tied. this isn't just a POC network, this is a proposal for ethereum mainnet! Thats why we have been rigorously running devents, slowly scaling the validators and subnets and discovering and alleviating the issues so that we end up with a production grade PQ signature scheme that ethereum deserves and needs. And this focus is now gonna magnify 1000X now that we believe we are on a spec that can deliver PQ for mainnet. And mind you, the time of need is gonna strike soon. We not only intend to solve this conundrum for ethereum but propose to even upstream to bitcoin so that we have a PQ standard this entire space deserves. And all that based on a humble but extremely powerful leanVM that makes the hashbased cryptography workable for the production grade systems like ethereum and bitcoin. PS: we are currently heavily focused on debugging and scaling devnet4 spec devnets while we have already started to run sims and preliminary interops for devnet5. So stay tuned for further progress that we leanEthereum teams have been cranking out with a steady but heavy dose โ˜•๏ธ. May be all matrix is just โ˜•๏ธโ˜•๏ธโ˜•๏ธ
3
13
75
3,124
zeamETH retweeted
Finality has finally been achieved on devnet-4 after three weeks of testing on a multi-subnet devnet. The challenges posed by post-quantum cryptography are very real.
1
1
12
661
Devcon 8 tickets are live! The first global ticket wave is open for Ethereumโ€™s next major gathering, rooted in open source, privacy, security, censorship resistance, and capture resistance. Early Bird: $349. ETH only. Limited quantity! Get yours: devcon.org/tickets
55
77
269
251,645
May 20
๐ŸŽ‰๐ŸŽ‰๐ŸŽ‰ devnet5 spec merged ๐Ÿš€๐Ÿš€๐Ÿš€: block with just a single aggregated signature proof github.com/leanEthereum/leanโ€ฆ this brings @leanEthereum full circle on the "PQ stack" for consensus to upstream it to mainnet PQ centric L* hardfork It includes a very neat feature for splitting the block signature proof for re-bundling it on a side branch even without requiring the constituent signatures that were aggregated! all thanks to awesome EF researchers working on leanVM ๐Ÿฆพ๐Ÿฆพ๐Ÿฆพ now time to build devnet5! comeon lean teams time to harden and show production stability and scale fyi: devnet4 runs are already on for scaling the validators to harden subnets & aggregators lets grind on!
3
5
24
134,820
May 13
Zeam May 8 weekly call update: This week focused on DevNet 4 aggregator stability, threading/mutex fixes, DevNet 5 prep, Zig 0.16 migration, SSZ Merkle caching, BlocksByRange RPC, and improving OpenClaw workflows for faster development. Individual updates ๐Ÿ‘‡
1
73
May 13
@noopursingh23 has been working on Openclaw configuration and experiments focusing on rising AI token costs and the need to explore cheaper/self-hosted models that can retain project context over time.
1
55
Apr 22
April 17 Zeam call updates : DevNet 4 is being stress-tested hardโ€”threading bugs hunted, multi-subnet configs spinning up, and stability is leveling up fast. individual updates ๐Ÿ‘‡
1
2
86
Apr 22
@Gajpower Running local DevNet 4, chasing segfaults, reviewing threading PRs. Pushing for multi-subnet testing with each client as subnet aggregator to surface cross-client bugs fast. Eyes on robustness & production readiness
1
1
82