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.
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?