Gnot Quite

The initial commit (January 29, 2021) included 754 test files in tests/files/. A tests/README.md accompanied them:

Yaegi is a mature Go interpreter maintained by Traefik Labs under the Apache 2.0 license.

A file-by-file comparison bears this out. Of the 754 test files, 724 (96%) share identical filenames with Yaegi’s _test/ directory. The content is byte-for-byte identical across files like a1.go, struct1.go, closure1.go, issue-784.go, and hundreds more. All nine issue-*.go files reference Yaegi’s GitHub issue tracker, not Gno’s.

During a 2023 repo reorganization, tests/README.md was replaced with a new version that contains no reference to Yaegi. The borrowed test files remain in the codebase, many converted to .gno format, without attribution.

Gno’s parser (gnovm/pkg/parser/) is constructed by copying Go’s standard library parser and patching it. The Makefile is explicit:

The build process: copy go/parser wholesale, apply gno.patch, ship it.

Gno ships roughly two dozen standard library packages, compared to Go’s 150+. Many are direct ports with provenance noted in headers:

Floating-point arithmetic is handled by software emulation generated from Go’s own runtime:

The tm2/ directory contains Tendermint2, a fork of Tendermint Core. The Amino serialization library carries the header: "Original: Copyright © 2015 All in Bits, Inc; dba Tendermint Inc; Apache2.0."

The GnoVM interpreter itself, spanning tens of thousands of lines across nodes.go, values.go, types.go, preprocess.go, machine.go, ownership.go, and realm.go, is the original engineering. It defines a custom AST, a stack-based opcode dispatch loop, a bespoke type system, an ownership model for persistent objects, and realm-based state management. This design is architecturally distinct from Yaegi, which uses go/ast directly and compiles to a control flow graph.

The novel ideas live here: on-chain package imports, persistent object ownership, source-level deployment. Having worked with this code daily, I can confirm it is real and substantive work. But it sits on a foundation that is largely assembled from existing open-source components, and that assembly is not always clearly attributed in the current codebase.

Language runtimes fall along a well-understood performance spectrum:

GnoVM sits at the bottom of the performance hierarchy. Source code is parsed into a custom AST, and the interpreter walks that tree node by node at execution time. There is no compilation to bytecode. Every operation, whether addition, comparison, or function call, is dispatched through Go function calls, interface type assertions, and slice operations on six internal stacks.

The main loop in machine.go dispatches through a large switch statement covering roughly a hundred opcode cases. A straightforward operation like a + b traverses the following path:

One integer addition: approximately 20 Go function calls, multiple interface type assertions, several slice operations, and two gas metering passes. In compiled Go, a + b is a single CPU instruction. Working on Playground and Studio, we felt this overhead in every realm deployment and test cycle.

Gas metering is the mechanism that prevents denial-of-service on a public network. In GnoVM, several gas constants are explicitly marked as unvalidated:

These are not placeholders in dead code. They are the values that validators depend on to bound resource consumption per transaction. Mispriced gas creates an attack surface: transactions that consume disproportionate compute relative to their fee.

Every state-modifying transaction triggers FinalizeRealmTransaction (realm.go), which performs:

A simple token transfer modifies at least two balance objects. Each goes through the full serialize-hash-persist pipeline. This cost is structural. It is inherent to the ownership model and runs on every transaction that touches state.

Even setting VM performance aside, Tendermint2’s three-phase BFT commit (propose, prevote, precommit) imposes its own throughput limit. Production Cosmos chains on the same consensus architecture typically achieve 20-100 TPS. VM execution time stacks on top of consensus time.

The rest of the industry is heading in the opposite direction, toward compiled execution. Solana's BPF, Sui's Move VM, Monad's parallel EVM, and Ethereum’s EOF proposals all prioritize raw execution throughput. GnoVM’s interpreted architecture has no clear path to compete on this axis.

Deterministic execution across all nodes is a hard requirement for any blockchain VM. Go was not built for this. Several of its defining features are non-deterministic by nature, and GnoVM removes them:

Go has over 150 standard library packages. Gno has roughly two dozen. Goroutines, the signature feature and often the primary reason developers choose Go, are gone entirely.

What remains is a language that uses Go’s syntax and a fraction of its semantics. That is a meaningful distinction.

The VM source contains dozens of panic("not yet implemented") calls scattered across core files including machine.go, uverse.go, gonative.go, op_expressions.go, values_conversions.go, and values_fill.go. A developer writes code that is valid Go, the code passes parsing and preprocessing, and then it panics during execution when it hits an unimplemented path. Building realm contracts for Boards and CommonDAO surfaces this issue: patterns that feel natural in Go produce panics deep in the VM.

For a smart contract platform handling real value, runtime panics on syntactically valid input are a serious concern.

Effective Gno development requires understanding constructs that do not exist in Go:

The resulting learning curve is comparable to picking up a purpose-built smart contract language, but without the tooling maturity that comes with established platforms like Solidity or Move. Building the developer experience tools around Gno, we spent as much time explaining what Gno is not as what it is.

Ethereum’s design rationale describes a "sandwich complexity model": simple at the bottom (VM), simple at the top (language), complex in the middle (compilers). This separation delivers three concrete advantages:

GnoVM collapses this separation. The VM is the language. It cannot be reimplemented in Rust without reimplementing Go’s runtime semantics. The language cannot evolve independently of the interpreter. And formal verification must reason about the full surface of Go minus an incompletely documented set of exclusions.

Solidity’s type system is intentionally minimal: roughly 30 keywords, a constrained type system, no pointer arithmetic, no dynamic dispatch beyond interfaces. This makes contracts auditable and formal verification practical.

GnoVM exposes Go’s full type surface (structs, interfaces, closures, defer, panic/recover, type assertions, slices, maps, pointers, methods, embedding) bounded by a type checker and preprocessor that lives in a single, sprawling file: preprocess.go. This monolith handles name resolution, type inference, constant evaluation, static analysis, heap escape analysis, and AST transformation, all in thousands of lines of deeply nested logic.

Any bug in this file is a potential consensus vulnerability. If two nodes type-check the same contract differently, the chain forks. Auditing a monolith of this scale for correctness is qualitatively harder than auditing a compact bytecode specification. This is not a theoretical concern; it is the central security challenge of the architecture.

Solidity has eight years of production deployment, roughly 9,000 monthly active developers, and a deep tooling ecosystem: Hardhat, Foundry, Slither, Mythril, Certora, and multiple formal verification frameworks. Move has linear types with built-in safety guarantees. Rust on Solana inherits cargo and the broader Rust ecosystem.

Gno has none of these. No production-grade static analyzer. No fuzzer. No formal verification framework. No battle-tested deployment pipeline. Having built Gno Studio and Playground to try to bridge this gap, I can say the tooling challenge is not for lack of effort. The architecture itself makes it difficult. The VM’s surface area is large, the behavior is underspecified in places, and the absence of a bytecode layer means tooling must reason about the full interpreter. For a platform intended to secure real value, this is not simply a matter of maturity. It is a matter of readiness.