charlessismore

kinda ironic, devs are using super closed MacOS, paying for black-box frontier AI models, and pushing code to the world’s greatest decentralized open-source ecosystem for... what?

(4/4) That way, if I see “PIE-9999” on my timeline, I instantly know someone’s just pitching an idea, easy ignore. But if I see “EIP-9999”, I might actually pay attention, since it could be real Ethereum ecosystem work.

(3/4) But on crypto Twitter, this spammy vibe makes me spend extra cycles just to sort it out again. Small suggestion: any EIP/ERC that hasn’t been officially accepted shouldn’t be called EIP/ERC. Call it something else, like PIE/CRE.

(1/4) Ethereum devs might be the least dev-y devs I’ve ever seen. With decentralization, when they want to push protocol changes, they don’t go to GitHub or mailing lists.

arewefastyet.report/?timerange=Las… In our EVM tests, reth, nethermind, and ethrex (added this week!) are the three fastest clients. But i do think ethrex can actually do better than reth. Rust-style no-VM languages have more precise control over memory allocation, which makes it easier for ethrex to beat reth on memory usage compared to nethermind.(and yeah, memory counts as performance too)

I submitted a PR to @tempo to correct an inaccurate technical statement in their description. It currently asserts that Reth is the fastest execution client, a claim that is not supported by available benchmark data. We have already published measurements that contradict this assertion. Based on the most recent and publicly available benchmarks, Nethermind (@Nethermind) currently demonstrates the highest execution throughput. Their methodology and results were published earlier today. We expect to publish quantitative performance results for @ethrex_client in the coming weeks. Also from an engineering perspective, I strongly recommend that Tempo and @stripe operate multiple execution and consensus clients. Client diversity improves fault tolerance.

After reading zkevm.ethereum.foundation/blog/benchmark… I feel that, for the next hardfork, all EL teams (Reth excluded) could drop all new EIPs and first **rewrite the EVM-related parts of their clients in Rust**. This way, within roughly half a year, they could complete a thorough refactor and avoid long-term tech debt. My reasoning chain: * Assume that, going forward, zkVMs will likely exist on some niche ISAs such as **RISC-V/MIPS** (the current competitors are basically these). * And every zkVM requires the **guest program** to be an ELF targeting its own ISA. * Therefore, current EL clients need to compile their **EVM code** for those ISAs. * As is well known, these niche ISAs are not yet maturely supported by all mainstream languages. **Only Rust’s ecosystem** consistently treats them as tier-2 **with future tier-1 support**. * So, if non-Rust EL teams (Geth/Erigon/Besu/Nethermind) don’t want to spend the coming years filing PRs to their language compilers’ GitHub repos—and eventually get their engineers poached by those compiler teams—the once-and-for-all solution is to **rewrite the EVM + some related code in Rust**, while keeping other non-EVM parts such as database and networking in their original languages. Benefits: * The **N ELs × M zkVMs** combinations become easy to compose. * Client diversity is preserved. Open issues: * The **Reth** team might not have much additional workload—need to find a way to keep them busy. * It’s unclear how much needs to be rewritten. If **EVM plus surrounding code** is less than ~50% of the whole client, that’s a strong motivation to rewrite; if it’s much more, it approaches a full rewrite and the workload may be too large.

as a naive programmer, there's something i just can’t wrap my head around: if zkproof tech ever evolves to the point where you can prove an ethereum block in 12s with decent economic efficiency (which, based on current progress, still needs a 100~1000x improvement), does that mean all the cl and el teams could also push harder and eventually optimize clients to the point they can run on an apple watch?🤔🤔

Hard to believe crypto payments long shunned by the gamedev community finally become an option. reddit.com/r/gamedev/comm… stopcollectiveshout.com/payment-guides Freedom of expression for game creators isn’t something you get automatically; you have to keep defending and fighting for it. Ironically, that’s why decentralized crypto (the good part) exists, we’re only just discovering its value now.

@peter_szilagyi @mhswende @hwwonx @0xstark EF？Funded？Nethermind？Fork？Geth？ Too bad to be true

@mhswende @hwwonx Did you all know EF started (and funded) a second Geth team *inside* #Nethermind? One "100% independent fork from us, with no intended collaboration" according to @0xstark . Ah, and they totally didn't tell either me, Felix or Martin until I found out in November 2025. Yeah.

I DARE you and the entire #Ethereum foundation to say that you didn't offer $5M for us to spin out. Or that EF didn't ask at least 3 times if we wanted to make a company instead and go off, just me and Felix and @mhswende pushed back. I dare @hwwonx to deny our Feb talk.

splitting up the client teams and turning them into separate companies could actually work — if you also move folks from other EF teams into those groups, each built around one client. EF itself could just be a small core team, barely a handful of people on payroll, while the real work happens in those spin-off companies. but if you're only spinning out one client team and leaving the rest of EF untouched, that's just setting them up to fail. sure, 5 million might last a few years, but for a dev team with no real way to make money, it's gonna feel heavy. the morale will be stuck in the mud. huge respect to Peter for saying it out loud. not many would.

Back in 2010, ECS was already a thing among Flash devs. The first ones I ran into were Ember: github.com/tdavies/Ember and later Ash: github.com/richardlord/Ash At the time, ECS wasn’t about performance. That was just a nice bonus. Due to the AS3 VM, stuff like cache friendliness was only vaguely helpful, not strictly effective. What really drew people to ECS back then was how it could help speed up gameplay development. ECS was a fresh idea then. It hadn’t been validated by any big commercial games yet. No studios or influencers pushing agendas, so we could actually talk about it honestly, from all angles. I was lucky enough to fully develop an ARPG using my own modified version of Ash during that era (and I wasn’t a newbie, I had already been the lead gameplay dev on a few games before that). What impressed me the most about ECS was how, across 1–2 years of adding new features to that ARPG, I could just: 1. blindly create a `XXSystem.as` 2. declare the components I cared about, handle their logic, fire off some events. The beauty was that ECS physically stopped me from making a mess. Without ECS, I’d have tons of Managers. Sure, they’re clean at first, but over time each one ends up spawning sub-managers, and eventually you get lazy and everything ends up jammed in one file. What ECS gave me was the mental freedom to spin up new Systems without any friction. Later I tried a bunch of ECS frameworks in Unity. Even Unity’s own ECS, which they patented and made a selling point. But everything just got way more complex. Some ECS setups are a nightmare, language syntax-wise, feature-wise, and API-wise. And the usual excuse is either "ultimate performance" or "staying pure to the ECS spirit." Like firing events from within Systems, it’s a super common need. But many ECS frameworks treat it like an afterthought. They say it hurts cache locality, or that it makes ECS impure. If you insist on doing it, it’s "at your own risk," etc. So honestly, I don’t think ECS is inherently bad, it’s just that the modern takes on ECS have totally lost the plot.

ECS is useless for most games. Actually worse than useless because it makes things harder.

damn, it finally clicked while i was having lunch why Vitalik’s pushing RISC-V. it’s not just about some random zk company’s plan — it had to be RISC-V. Vitalik’s tired of all the EVM bullshit — EVM 2.0, 3.0, whatever version people come up with. the only thing he still likes is Solidity’s syntax. the rest of it? he’s over it, completely. but every time he checks twitter, it’s just endless arguments about how to patch or tweak the EVM. it’s like putting lipstick on a pig — totally hopeless, and it’s driving him nuts. so he figured out the cleanest way to end this once and for all: no EVM, no fixing EVM. now imagine — if we can AOT compile Solidity straight to a RISC-V target, then the only thing web3 folks need to work on is building a Solidity-to-LLVM frontend. even if the current Solidity team doesn’t know anything about LLVM, if they start grinding now, they could totally get it done by the end of the year. after that, LLVM IR to RISC-V? that’s handled by the massive open-source risc community — not our problem. RISC-V to x86 or arm? again, the risc community’s got it covered. web3 doesn’t have to touch any of that low-level crap ever again. yeah, it’s a huge breaking change, no doubt. but once it’s done, Ethereum devs won’t ever have to worry about EVM again. as long as the risc people are alive and kicking, they’re basically doing free work for us. but obviously you can’t just come out and say “hey let’s kill EVM” — it’d freak everyone out. you need a good excuse, a story people can buy into. so Vitalik framed it as "making L1 more zk-friendly" and quietly slipped RISC-V into the convo. and honestly, it makes perfect sense — in the zk world, RISC-V has a massive performance edge over arm and x86. if you wanna push the zk narrative, you gotta pick an ISA that the zk crowd already loves — and that’s RISC-V, no debate. and that loops right back to what i said at the start — it had to be RISC-V. none of those other zk ISA proposals were ever gonna cut it. because if web3 still had to maintain those, it’d just be the same old pain all over again.

I feel like ethereum EF keeps changing its mind. they used to want to be this behind-the-scenes hero, like “the best EF is the one that’s everywhere but no one remembers it's there.” the whole idea was throwing money around and stepping back from control. that path led to all kinds of L2s popping up, which actually followed the ethereum storyline—pouring money into the L2 ecosystem and reducing their own influence. but that only works if those orgs feel grateful (like… did y’all even say thanks to EF?) right now, it looks like these L2 orgs have zero motivation to give back to ethereum, and no reason to play nice with each other either. especially when one of them gets a near-monopoly—they just become another profit-driven company doing what's best for them. EF probably isn’t short on money, but they def feel played. and that sucks. so now ethereum’s trying to make L1 fast again—like with beam chain or risc-v replacing evm. on the surface it’s “ethereum is getting faster,” which sounds good for L2s too. but low-key, it’s a power move—if L1 gets fast and cheap enough, L2s lose their edge. but here’s the thing: 1. how many of EF’s core teams haven’t already been influenced or infiltrated by L2 companies? 2. and can the new teams EF brings in actually promise not to launch their own token later and go down the same path as today’s L2s?

Working on another instance of Conquest with game-changing new features! The concept of Faction is something I have been thinking for a while and can't wait to see how it plays out. Should help new players. Plus adding some new open-source tech again, all towards an upcoming v2

I do question EOF’s "priority," but I don’t really mind it eventually getting merged into main. The biggest issue people have with it right now is that merging it would permanently add a hefty chunk of maintenance work to the EVM. I have a feeling this comes from the fact that Ethereum devs might already be working with limited resources, but it’s not something people talk about much. But honestly, making sure old executable code still runs on the latest VM isn’t some special burden unique to Ethereum. Java and C# handle this just fine. And if you look at OS-level compatibility, Windows is famous for letting you run ancient .exe files on its newest versions.

But I can see the other side of maintenance of old code and putting this fairly big change in production as a risk of new bugs. I wish someone would come up with classic bytecode->EOF translation, but this is not doable in general case due to dynamic jumps.

To EOF or not to EOF that is the question. I think the question could be simplified to following options: - I am good with current EVM limitations forever vs - I am fine with bigger changes to transcend those limitations

Compared to checking Twitter, Bluesky, and Mastodon every day just to see if anything interesting is happening in gamedev, my only favorite thing about crypto people is: I never have to wonder where to find them—just open X. Where there is a will, there is an X handle.

> Consequently, this post focuses on measuring how well a SNARK performs absent specialized hardware and pre-compiles. It’s a departure from current benchmarking approaches, which often lump all three factors into a single “headline number.” This is akin to judging diamonds by how many hours they’ve been polished rather than by their innate clarity. Amazing read—one line, and the entire zkVM scene just lost a year of progress. Bravo. 👏😆

6/ So yes, zkVMs and SNARKs hold enormous potential, but we flirt with disaster if we pretend they’re ready for prime time. I’ll be using these stages to track zkVM progress in the coming years—and hope others will too. Check out my post here: a16zcrypto.com/posts/article/…

1/ Beware the hype: while SNARKs and zkVMs show immense promise, they’re not ready for complex, high-stakes deployments. Bugs are everywhere, formal verification is nascent, and proofs can be hundreds of thousands of times slower than native execution.

@lightclients @URozmej @GiulioRebuffo @ben_a_adams @frangio_ @shemnon @pcaversaccio @donnoh_eth I looked up a few keywords and found this in my browser history: @ipsilon/solidity_eof_poc" target="_blank" rel="nofollow noopener">notes.ethereum.org/@ipsilon/solid… This benchmark might be a bit more practical.

@URozmej @GiulioRebuffo @ben_a_adams @frangio_ @shemnon @pcaversaccio @donnoh_eth The benchmark is on a program that computes fibonacci numbers, so the workload isn’t really representative of what’s on-chain. I’m sure there are some gains to be had with EOF, but I think we should get more info.

Look guys, the Pectra fork upgrade issues on Holesky and Sepolia are a stark reminder that even seemingly 'trivial' changes can unravel into major disruptions (check how many days Holesky was down). Complexity isn't always obvious—it lurks beneath the surface, waiting to break things (and it will happen ultimately). And while not the root cause here, adding 19 opcodes while removing 16 in one upgrade is simply reckless, IMHO. The PoS transition was a necessity—EOF is not! We can and should evolve _incrementally_, strengthening Ethereum without inviting chaos.