Ethereum Developer Tooling
Ethereum’s developer toolchain is undergoing a generational upgrade in 2026: Hardhat 3 ships multi-chain native testing, Solidity is splitting into a migration-safe two-language architecture, and Noir 1.0 brings ZK programming to production. The theme across all three is avoiding the decade-long fragmentation that crippled Python 2→3 migration. (→ [[devconnect-argentina]])
Hardhat 3
Nomic Foundation’s major release modernizes the most-used Ethereum development framework. (Devconnect Argentina, Solidity Summit — John Kane)
Core architectural changes:
- Rust-based EDR (Ethereum Development Runtime): replaces JavaScript VM; delivers up to 10× test suite speedup in benchmarks
- ESM modules: adopts Node.js standard module system; replaces legacy CommonJS require() imports
- Explicit network connections: v2’s implicit
ethers.providerreplaced by explicit, type-safe chain connections — required for multi-chain support
New capabilities:
- Solidity-native tests: write tests in Solidity itself (on par with Foundry performance); no longer JS-only
- L2 simulation: Optimism stack support built-in; L2-specific RPC calls (
estimate_L1_gas) available; developers target L1 or L2s with type-safe chain-specific APIs - Multiple simultaneous connections: test contracts across several chains in a single test run
- Built-in coverage + gas stats: integrated code coverage reporting and per-function gas profiling
- Ignition declarative deployment: replaces manual migration scripts with idempotent, re-runnable deployment system
Core Solidity (Sale)
A two-language migration strategy that avoids Python 3-style decade-long fragmentation. (Devconnect Argentina, Solidity Summit — Kamil Sliwak)
The problem being solved: Solidity has accumulated legacy decisions (inheritance, try-catch, implicit library imports) that prevent performance optimizations and create common bug patterns. A hard fork risks fragmenting the ecosystem indefinitely — see Python 2→3 adoption taking 10+ years.
Sale: The Minimal Core Language
Sale is a clean, minimal language that underpins “Core Solidity”:
- Generics, type classes, algebraic data types, first-class functions, type inference
- No high-level abstractions; no inheritance at language level
- Core Solidity layers syntactic sugar on top: inheritance, events, errors, operators, loops remain available
Migration Mechanisms (four-path strategy)
| Mechanism | What it enables |
|---|---|
| Syntactic sugar | Core Solidity = Sale + stdlib + extensive sugar; familiar syntax preserved |
| Automatic translation tools | Works for superficial language changes (postfix types, library import syntax) |
| Interoperability | Compile Classic and Core in the same project; function calls across language boundaries; same memory layout guarantees |
| Gradual transition | One contract at a time; no forced cutover |
Intentional breaks: Inheritance, try-catch, and library patterns will not port to Core — they have replacements. These are the patterns identified as causing the most bugs.
What won’t be ported (by design):
inheritance→ replaced by composition patterns in Saletry-catch→ replaced by error-returning patterns- Classic libraries → replaced by Core modules
Long-term: A future RISC-V backend in Core Solidity would enable ZK-provable execution of Solidity contracts natively. See ZK Proving Infrastructure.
Noir 1.0
Aztec’s ZK programming language reaches production stability. (Devconnect Argentina, NoirCon — Savio Sou)
Timeline: Alpha (2021) → Beta → Pre-release → 1.0 (Q2 2026)
1.0 feature completeness:
- Fields, integers, strings, control flow, unconstrained functions
- Generics, traits, algebraic types
- Built-in profiler for constraint optimization
Multi-chain deployment reality:
| Chain | Method |
|---|---|
| Aztec | Native |
| Ethereum | Solidity verifier (groth16) |
| Arbitrum Stylus | Native Noir verification |
| Stellar Soroban | Direct deployment |
| Solana | Graph16 prover |
| World Chain | Identity applications |
Security hardening for 1.0:
- Ongoing fuzzing campaigns
- Formal verification via Lamp (Noir-specific prover)
- GitHub security advisory infrastructure
- 2+ external audits before final release
- Internal audit program
Deployment targets beyond the EVM:
- Browser: BBJS verifier runs Noir proofs client-side
- Mobile: Mopro framework enables iOS/Android ZK proof generation
Production use cases:
- ZKPassport: identity verification (prove citizenship without revealing identity)
- ZK Email: private email proof verification
- Terry Escape: provably fair P2P gaming
- Open Bands: social graph privacy
Noir’s multi-chain reach means ZK verification is no longer Ethereum-exclusive — a Noir-generated proof can settle on Solana or Stellar. See ZK Proving Infrastructure for broader ZK proving ecosystem.
EIP Process Reform
Three talks at Devconnect’s EIP Summit surfaced systemic improvements to how Ethereum protocol changes are developed and shipped. (Devconnect Argentina, EIP Summit)
The feedback loop problem (Jochem Brouwer, EF): Core developers waste time at All Core Devs (ACD) calls addressing concerns that should have been surfaced during proposal review. Feedback channels through private Discord/Telegram instead of the public Ethereum Magicians forum, where EIP editors can respond. Fix: EIP editors must actively route feedback to the public record.
Technical reviewer role (Danceratopz & Raxhvl): A proposed new EIP process role that converts specifications to executable code and test vectors. “Interop will not be solved in research papers.” Coupling spec changes to test suite updates (atomic changes) catches implementation bugs before testnet deployment.
EIP-8007 gas repricing (Maria Inês Silva): A meta-EIP aggregating 18 gas repricing proposals targeting the Glamsterdam fork (post-Fusaka):
- Current operations show 5–15× efficiency loss from mispricing established at Ethereum’s launch
- Goal: harmonize pricing along single resource dimensions (compute, state IO, state growth) — today all three are conflated
- Unlocks: EPBS-based 4-second slots and block-level access lists for parallel execution
- Fusaka caveat: EIP-7825 (gas limit boundaries) would invalidate transactions with 30M gas limits — requires user education that such transactions can be split
See Ethereum Scaling Roadmap for the EPBS and Fusaka context.
ETHPrague 2026: Solidity 0.8.35, Core Solidity Progress, Plank, Wake 5.0
What’s next for the Solidity language? (Jacob, Argo collective)
The Solidity project is now maintained by the Argo collective — a not-for-profit spin-out from the Ethereum Foundation since 2025. Argo also maintains FE, Sourcify, AVM, ACT, S debug. Solidity 0.8.35 (released the week of ETHPrague) ships:
- First compile-time builtin in the language — small, but the first step.
experimentalflag for unstable features.- SSA CFG codegen (experimental) — the underlying redesign that finally fixes the stack-too-deep problem (1000+ devs cited stack-too-deep as biggest pain point in the 2025 Solidity survey).
- Target: SSA CFG codegen end of Q2 2026 as experimental, production timing TBD.
EIP-8024 (confirmed for Glamsterdam) — adds new dupN, swapN, exchange opcodes that allow addressing ~272 stack items. Complements the SSA CFG work — between them, stack-too-deep is eliminated.
Core Solidity (Sale-based) is moving forward
The Core Solidity work (Sale = Solidity Algebraic Intermediate Language) is now compilable:
- Beacon chain deposit contract being ported to Core Solidity by Axi (ex-Solidity core dev).
- First module system shipped in May 2026.
- Pattern matching for sum types — the compiler refuses to compile code with missing cases. Aviation-style “make it hard for humans to make mistakes.”
- First-class functions, generics, removal of inheritance (replaced by traits + composition), comp-time evaluations.
- Same EVM bytecode backend — interop and tooling compatibility preserved.
- Sale (the standard library language) has 8 constructs and one built-in type (Word); targeted for formal verification in Lean.
No Python 2→3 split: explicit project goal. Classic Solidity goes to maintenance-mode once Core ships; surface syntax stays close enough that mass migration is gradual rather than forced. Production-ready compiler “probably not 2026.”
Introduction to Plank, a New EVM Language (Philogy)
A competing path: Plank is an alternative EVM-targeted language with different design philosophy (closer to Yul / typed-Yul; minimal surface). The ETHPrague track now includes multiple language efforts (Solidity, Core Solidity, Vyper, Plank, Yul) — diversity by design, with Jacob explicitly endorsing the multi-language ecosystem.
Wake 5.0 — Python + Rust fuzzing core (Michal Prevratil / Argo)
The flagship of the testing-tools track. Full coverage at Smart Contract Fuzzing. Headlines:
- Rust core via REVM; 10–80× speedup over Python-only Wake 4.x.
- Python testing API preserved — unlimited-precision integers, native dicts/queues/decimals for differential-testing mental models.
- AI-fuzzing-harness generation on the funding roadmap.
- Same Argo collective maintaining Solidity.
Distributed and secure frontend deployment pipelines (Pavel Losev)
The “frontend layer” parallel to ETHPrague’s “Decentralization Stack” panel. Losev’s case: deploying dapp frontends through Vercel/Cloudflare creates a single point of compromise (the October 20, 2025 outage that took down many Ethereum apps was largely a frontend-CDN failure, not a chain failure). The proposed pipeline: IPFS pinning + ENS resolution + reproducible-build attestation. Logos Freedom Browser (Neocypherpunk & CROPS) is the cypherpunk-end consumer; Losev’s pipeline is the engineering middle.
Unfucking the RPC Layer (Lukas)
The most-cited centralization point of ETHPrague’s developer-experience track. RPC providers (Infura, Alchemy, QuickNode) are de facto Ethereum’s user-facing API; the move toward Helios light clients + reverse proxies that enrich RPC responses with proofs (so users don’t have to trust the RPC operator) is the working remediation path.
Open Source & Open Data: Bringing Ethereum’s Values to Source Code Verification (Manuel Wedler / Sourcify)
Sourcify (Argo-maintained) — the canonical decentralized source-code verifier. Wedler’s framing: contract data on-chain is bytecode; without verified source mapping, users cannot inspect contracts they’re approving. CRA’s SBOM requirement extends to smart contracts — every deployed contract must eventually have published source. Sourcify is the production infrastructure for that.
EIP-8141 Frame Transactions — protocol-level developer-experience improvement
Forshtat’s EIP-8141 (Account Abstraction) is the ETHPrague developer-experience headliner at the protocol level: the long-term endgame of no separate transaction types, fully programmable validation, native pass-key support, atomic batching. The frame-transactions track is where developer ergonomics finally collide with the post-quantum migration timeline.
Connections
- Ethereum Scaling Roadmap — EIP-8007 directly feeds Glamsterdam fork; Core Solidity’s RISC-V backend target aligns with native rollup ZK vision
- ZK Proving Infrastructure — Noir 1.0 is a primary ZK programming interface; Jolt and other ZKVMs share the RISC-V target with Core Solidity
- Smart Contract Security (2026 State) — Hardhat 3’s built-in coverage + Core Solidity’s intentional removal of bug-prone patterns (inheritance, try-catch) are security improvements
- On-Chain Agents — AI-generated code (Brevity, Vibehouse) is the adjacent “AI writes contracts” wave; better tooling improves AI compilation success rate
Open Questions
- Will Core Solidity adoption speed exceed Python 3 adoption (>10 years), or does interoperability make the transition faster?
- Does Sale achieve the same level of formal verification amenability as the Yul/Cairo alternatives?
- Can Noir 1.0 displace Circom as the dominant ZK circuit language for Ethereum-adjacent use cases?
- Does the EIP-8007 repricing cause unexpected gas estimation failures in deployed contracts that use hardcoded gas limits?