// the find
near/nearcore
Reference client for NEAR Protocol
nearcore is the canonical Rust implementation of NEAR Protocol, a sharded proof-of-stake blockchain where smart contracts compile to WebAssembly. It targets developers who want Ethereum-level programmability without Ethereum's gas economics and sequential execution bottlenecks. Active mainnet software, not a research prototype.
- Stateless validation design lets chunk validators verify execution without re-running it — validators only need witnesses, not full state. This is architecturally cleaner than most L1 designs and is what makes horizontal validator scaling tractable.
- Flat storage layer avoids repeated trie traversals for state reads during block execution. The flatStorageInit and GC modules suggest this was a deliberate, hard-won optimization rather than an afterthought.
- Dynamic resharding is implemented and tested across 4, 20, and 70 shard configurations in the benchmarks directory. Most sharded chains ship with a hardcoded shard count; NEAR actually exercises reconfiguration.
- Benchmark infrastructure is unusually structured: separate DB-level, synthetic transaction, sharded-network, and RPC probe suites rather than one script somebody ran once.
- The 'Spice' parallel execution engine lives in its own chain/chain/src/spice and chain/client/src/spice subtrees alongside the existing stateless_validation path. Two execution architectures coexist in production code with no obvious indication which one mainnet runs — real adoption risk for anyone trying to understand the system.
- NayDuck is their internal distributed test runner referenced in two separate CI workflows. Failures there aren't reproducible outside NEAR's infrastructure, which quietly walls off external contributors from debugging CI issues.
- The README is thin marketing copy. The actual architecture — actor model, storage layout, consensus details — lives scattered across GC_ARCHITECTURE.md, chain/chain/AGENTS.md, and individual module READMEs. No single document explains how the pieces connect.
- Python tooling (devcontainer init-pyvenv.sh, .python-version, .style.yapf) is scattered alongside Rust, meaning the dev environment isn't pure cargo. This adds friction for contributors who just want to build and run the node.