ethrex retweeted
The strawmap set a goal of Lean Ethereum by 2029—we now have a fork-by-fork plan to get there.
H* will be the last fork without lean features. I* will ship the leanVM and lean transactions. J* will add lean attestations, DA sampling and PCS. By L*, Lean Ethereum will be complete
1
3
17
1,443
ethrex retweeted
ethlambda @ethlambda_lean, our consensus client for @ethereum, is with silver from @gattacahq the fastest consensus client.
we're very proud of the work we're doing in @ethrex_client and @ethlambda_lean. in the upcoming months we're gonna focus more and more in performance. most n doing was around testing new EIPs, implementing new features and making everything stable.
we're in talks with multiple big validators that want to adopt ethrex and ethlambda.
we're very proud of the work we're doing in @ethrex_client and @ethlambda_lean. in the upcoming months we're gonna focus more and more in performance. most n doing was around testing new EIPs, implementing new features and making everything stable.
we're in talks with multiple big validators that want to adopt ethrex and ethlambda.
4
5
45
2,172
ethrex retweeted
The @class_lambda @ethrex_client and @alignedlayer team is in the house for the last day at @EFDevcon . AI and LLMs feature extensibly this day
0
2
16
293
ethrex retweeted
We're at @EFDevcon this week with the teams behind @ethrex_client and @ethlambda_lean, alongside our friends from @alignedlayer.
@lean_knack and @ivanlitteri gave a talk on "Getting to Lean Ethereum", and the team has been catching up with people working across the ecosystem.
ore days. Send us a DM if you're around.
@lean_knack and @ivanlitteri gave a talk on "Getting to Lean Ethereum", and the team has been catching up with people working across the ecosystem.
ore days. Send us a DM if you're around.
1
8
25
1,212
We are at @EFDevcon!
We’d love to meet stakers looking to diversify their stack with ethrex, one of Ethereum’s fastest execution clients, built in Rust.
Come chat about running ethrex in your setup. DM us to meet up!
We’d love to meet stakers looking to diversify their stack with ethrex, one of Ethereum’s fastest execution clients, built in Rust.
Come chat about running ethrex in your setup. DM us to meet up!
0
3
6
627
ethrex retweeted
ethlambda v1.0.0 is here! We now support the beacon chain through Gloas and run on mainnet and testnets, with a smooth Glamsterdam transition on Sepolia behind us.
Proud to bring more client diversity to Ethereum as we keep building toward its post-quantum future.
Proud to bring more client diversity to Ethereum as we keep building toward its post-quantum future.
ethlambda v1.0.0 is here!
Our Lean Ethereum consensus client now has full beacon chain support, including Gloas.
We're running it on mainnet, Sepolia, Hoodi, and Platåberget. Our Sepolia validators successfully transitioned to Glamsterdam without a single issue.
Built in Rust, ethlambda brings together what we've learned from Lean Ethereum devnets and years of developing ethrex. With @ethrex_client on execution and @ethlambda_lean on consensus, we're contributing to client diversity across both layers of Ethereum.
Next, we're pushing performance further, participating in Hegotá interoperability devnets, and working to bring post-quantum cryptography to the beacon chain.
Explore ethlambda and what we're building next in the full announcement: blog.lambdaclass.com/ethlambda-a-be…
2
2
15
502
Congratulations to @ethlambda_lean on v1.0.0!
We're proud to see lessons from building ethrex help shape another Ethereum client. With ethlambda supporting the beacon chain, we can work together on improvements across Ethereum's execution and consensus layers.
We're proud to see lessons from building ethrex help shape another Ethereum client. With ethlambda supporting the beacon chain, we can work together on improvements across Ethereum's execution and consensus layers.
ethlambda v1.0.0 is here!
Our Lean Ethereum consensus client now has full beacon chain support, including Gloas.
We're running it on mainnet, Sepolia, Hoodi, and Platåberget. Our Sepolia validators successfully transitioned to Glamsterdam without a single issue.
Built in Rust, ethlambda brings together what we've learned from Lean Ethereum devnets and years of developing ethrex. With @ethrex_client on execution and @ethlambda_lean on consensus, we're contributing to client diversity across both layers of Ethereum.
Next, we're pushing performance further, participating in Hegotá interoperability devnets, and working to bring post-quantum cryptography to the beacon chain.
Explore ethlambda and what we're building next in the full announcement: blog.lambdaclass.com/ethlambda-a-be…
1
6
24
860
ethrex retweeted
Great meeting with @serenita_luca! @SerenitaIO was one of ethrex's early adopters, and we enjoyed hearing more about the team's work on Vero.
Excited to keep working together to bring more client diversity to Ethereum with @ethrex_client and @ethlambda_lean.
Excited to keep working together to bring more client diversity to Ethereum with @ethrex_client and @ethlambda_lean.
1
5
14
1,912
We’re bringing ethrex to @EFDevcon.
We’d like to exchange ideas with other teams, hear what you’re working on, and connect with people using ethrex or interested in trying it.
DM us to coordinate a meetup.
We’d like to exchange ideas with other teams, hear what you’re working on, and connect with people using ethrex or interested in trying it.
DM us to coordinate a meetup.
We’re heading to @EFDevcon.
@lean_knack and @ivanlitteri will be speaking about Lean Ethereum:
cfp.devcon.org/devcon8/talk/D…
We’re working across Ethereum execution, consensus, and proving, and want to hear what other teams are building in these areas.
If you’re attending and want inate.
0
3
7
410
No ethrex Community Call tomorrow.
We’ll share the date for our next call soon. In the meantime, we have some updates coming your way.
We’ll share the date for our next call soon. In the meantime, we have some updates coming your way.
0
1
3
273
Great to see ethrex proving Sepolia blocks side by side with @openvm_org.
Ethereum’s move toward execution proofs should preserve client diversity from day one.
Thanks @ignaciohagopia, @TauLepton_, and everyone bringing EIP-8025 to life!
Ethereum’s move toward execution proofs should preserve client diversity from day one.
Thanks @ignaciohagopia, @TauLepton_, and everyone bringing EIP-8025 to life!
Let there be proofs! 🎉
Running an EIP-8025 execution-proof prover on Sepolia: blocks proven in ~6–7s on 16× RTX 5090 with OpenVM, for two guests, ethrex + reth (8 GPUs each).
36k+ proofs and counting.
Big shoutout to the prover teams, guest program teams and everyone who his a reality!
We'll be rotating provers and guests over the coming days and weeks. Which prover + guest should we spin up next?
⚠️ Experimental: validators MUST NOT rely on execution proofs for fork choice or attestations. Keep running an execution client. (Yes, Sepolia validators are permissioned, but still 🙂)
2
6
25
986
ethrex v30.0.1 unschedules Glamsterdam on Hoodi, after the ACDE call unscheduled it yesterday. If you run a Hoodi node on v30.0.0, or on one of its release candidates, you need this release before 26 October at 17:42:48 UTC. That is the time v30.0.0 still has the fork set for, es it alone splits off from the rest of Hoodi.
L2 operators running a sequencer or a follower should upgrade too. Mainnet and Sepolia are unchanged, so operators there who do not run an L2 or the stateless validator can stay on v30.0.0.
⚠️ The stateless-validator guests move to ERE v0.19.5 (SP1 v6.9.0, ZisK v1.3.2-alpha), and the ZisK guest's verification key changes. Anyone who verifies ethrex's stateless-validator proofs, such as zkEVM integrations, has to move to this release's keys together. Node operators who do not use the stateless validator are unaffected.
The rest of the release is mostly L2 reliability. A follower whose head was past the last sealed batch used to stop importing blocks when the sequencer or the follower restarted, and only wiping its data brought it back; it now resumes from its own head. A node holding more than one connection to the sequencer could stall mid-sync with RPC and logging frozen, so blocks are now imported in order by a single importer per node. Catch-up is faster as well: the sequencer sends a reconnecting peer only the blocks it is missing and up to 16 batches at a time, and followers no longer commit trie layers to disk after every imported block.
Also in v30.0.1:
- Stateless validation: witnesses with trie paths that do not end at the hashed key length are rejected, and zero-amount withdrawals read their recipient, as the specification requires. The check runs while the witness tries are rebuilt, so it adds little proving cost.
- Block building: withdrawals are applied before the request system calls, the order the specification and block import already use. Only chains with custom request predeploy code were affected, not mainnet or the public testnets.
- Networking: node records are encoded without base64 padding, so clients with strict parsers can bootstrap from an ethrex node.
If you run ethrex on Hoodi, upgrade before 26 October. No resync is needed.
L2 operators running a sequencer or a follower should upgrade too. Mainnet and Sepolia are unchanged, so operators there who do not run an L2 or the stateless validator can stay on v30.0.0.
⚠️ The stateless-validator guests move to ERE v0.19.5 (SP1 v6.9.0, ZisK v1.3.2-alpha), and the ZisK guest's verification key changes. Anyone who verifies ethrex's stateless-validator proofs, such as zkEVM integrations, has to move to this release's keys together. Node operators who do not use the stateless validator are unaffected.
The rest of the release is mostly L2 reliability. A follower whose head was past the last sealed batch used to stop importing blocks when the sequencer or the follower restarted, and only wiping its data brought it back; it now resumes from its own head. A node holding more than one connection to the sequencer could stall mid-sync with RPC and logging frozen, so blocks are now imported in order by a single importer per node. Catch-up is faster as well: the sequencer sends a reconnecting peer only the blocks it is missing and up to 16 batches at a time, and followers no longer commit trie layers to disk after every imported block.
Also in v30.0.1:
- Stateless validation: witnesses with trie paths that do not end at the hashed key length are rejected, and zero-amount withdrawals read their recipient, as the specification requires. The check runs while the witness tries are rebuilt, so it adds little proving cost.
- Block building: withdrawals are applied before the request system calls, the order the specification and block import already use. Only chains with custom request predeploy code were affected, not mainnet or the public testnets.
- Networking: node records are encoded without base64 padding, so clients with strict parsers can bootstrap from an ethrex node.
If you run ethrex on Hoodi, upgrade before 26 October. No resync is needed.
Core developers decided to delay the upcoming Hoodi hard fork on today's ACDE call.
Refer to this blog post for further details and be sure to watch for any client releases pertaining to your infrastructure on Hoodi.
blog.ethereum.org/2026/10/22/gla…
1
2
6
283
Our Community Call just wrapped, and the recording is out. Everything we covered today is on demand.
Ethrex Community Call x.com/i/broadcasts/1…
0
0
3
148
Don't forget, our Community Call is tomorrow at 2:30 PM UTC on X. We'll cover what we've been shipping and where we're headed next.
0
1
5
230
We loved chibi, so we added partial stateful node support to ethrex.
A node for your wallet that keeps only the accounts and storage you use, verifies the values it serves, and follows the chain without executing blocks. Your wallet gets local JSON-RPC, with no RPC provider to run: 29–34 MB of memory, about 3% of one core, and negligible disk usage beyond the binary. Anchoring took a couple of minutes while waiting for a peer that answered headers. Experimental and Sepolia-only for now, since it needs Glamsterdam’s block access lists.
We’ve also added experimental EIP-8440 execution chain proof support, with off (default), observe, and require modes. Require serves state only at blocks covered by a verified proof.
github.com/lambdaclass/et…
Let’s walk through what the node actually does 👇
A node for your wallet that keeps only the accounts and storage you use, verifies the values it serves, and follows the chain without executing blocks. Your wallet gets local JSON-RPC, with no RPC provider to run: 29–34 MB of memory, about 3% of one core, and negligible disk usage beyond the binary. Anchoring took a couple of minutes while waiting for a peer that answered headers. Experimental and Sepolia-only for now, since it needs Glamsterdam’s block access lists.
We’ve also added experimental EIP-8440 execution chain proof support, with off (default), observe, and require modes. Require serves state only at blocks covered by a verified proof.
github.com/lambdaclass/et…
Let’s walk through what the node actually does 👇
Partial stateful node is here!
Happy to announce chibi: a node that syncs in minutes and lets you transact through your own local RPC. Trust no one because every value is proven.
It runs on practically any hardware. Need to send a transaction? Don't need to rely on RPC chibi and send it right away. Live on Sepolia today and Hoodi next.
👇 demo below
2
4
11
1,167
There’s a distinction between authenticating state and proving execution.
A Merkle proof establishes that a value matches a header. A sync committee signature authenticates that header. Neither independently establishes that the block executed correctly.
A full node checks execution itself. EIP-8440 would let psn check it through an execution chain proof.
EIP-8025 covers individual payloads. EIP-8440 proposes recursive proofs covering execution from an origin block to a head. With an origin at or before your checkpoint, one recent proof could establish that every payload along that stretch executed validly.
That fits a wallet node: it wouldn’t need to collect every intermediate block and proof.
The three proof modes control how that integration affects the node.
off follows the light client’s head. observe follows that head while checking proofs and reporting coverage. require starts at the checkpoint and advances only to payloads covered by verified chain proofs whose origin is at or before it.
A Merkle proof establishes that a value matches a header. A sync committee signature authenticates that header. Neither independently establishes that the block executed correctly.
A full node checks execution itself. EIP-8440 would let psn check it through an execution chain proof.
EIP-8025 covers individual payloads. EIP-8440 proposes recursive proofs covering execution from an origin block to a head. With an origin at or before your checkpoint, one recent proof could establish that every payload along that stretch executed validly.
That fits a wallet node: it wouldn’t need to collect every intermediate block and proof.
The three proof modes control how that integration affects the node.
off follows the light client’s head. observe follows that head while checking proofs and reporting coverage. require starts at the checkpoint and advances only to payloads covered by verified chain proofs whose origin is at or before it.
1
0
0
54
With psn, your wallet can use a local node that holds the state it needs and checks the answers it serves. EIP-8440 support adds a path toward verifying the execution behind those answers, too.
The mode is experimental, Sepolia-only for now, and behind a Cargo feature. Existing ethrex nodes are unaffected, and no resync is needed.
We’d love wallet builders and node operators to try it and share their feedback. We want more wallet users to have a small node of their own.
The mode is experimental, Sepolia-only for now, and behind a Cargo feature. Existing ethrex nodes are unaffected, and no resync is needed.
We’d love wallet builders and node operators to try it and share their feedback. We want more wallet users to have a small node of their own.
0
0
0
94