Gnot Quite

A reproducible “~99% identical to Go” result requires a named corpus, weighting rule, Gno release, and procedure. The public documentation supplies no such calculation. The figure works as an orientation to familiar syntax and package structure rather than as a measured compatibility result.

Compatibility reaches across accepted programs, runtime semantics, failure modes, standard-library coverage, tools, execution cost, and authority. Each dimension produces a different denominator. Familiarity lowers the cost of reading Gno code while leaving those deeper boundaries to be tested separately.

Gno’s documentation names Go 1.17 as the target language specification. The implementation crosses later boundaries for specific reasons. During parser regeneration, the parser Makefile source copies GOROOT/src/go/parser, applies gno.patch, and commits the generated code for ordinary validator builds. The TypeCheckMemPackage source configures Go’s go/types for Go 1.18 because Gno’s injected built-ins use any and type parameters. The interpreter separately adopts Go 1.22’s per-iteration loop-variable rule. A source comment supplies the compact description: Gno “matches no single Go version.”

These Go-version numbers describe different layers of a deliberately constrained consensus language. The declared surface excludes generics, goroutines, channels, and select; the chain adds concepts that Go lacks, including realms, explicit crossings, persistent object identity, gas, and storage authority. The project’s compatibility reference is correspondingly granular. It classifies standard-library packages as full, partial, test-only, future, undecided, non-deterministic, Go-specific, or dependent on generics.

The source supports a simpler description: Gno is a Go-derived smart-contract language, readable to Go developers and governed at runtime by Gno-specific semantics. The 99% figure remains irreproducible without that calculation.

An import such as gno.land/p/demo/avl names a source package stored in consensus state: the data every validator commits to and must reproduce. Another application can import that package by path, and the chain can serve its implementation directly.

A deployment begins with MsgAddPackage, which accepts a MemPackage containing .gno source and package metadata. The package-admission source validates that material and charges gas for its source. TypeCheckMemPackage Go-parses and type-checks the files while resolving imports. The RunMemPackage source parses them into Gno nodes, preprocesses declarations, executes package initialization, persists package values, types, nodes, and surviving objects, and stores the source package.

Type checking and package loading use the production MemPackage blob. Query paths can reconstruct the full package by adding any #allbutprod sibling that contains test or file-test material. The MemPackage store source shows both blobs written through IAVL, the immutable AVL-tree key-value store backing committed state.

An ordinary MsgCall later loads persisted package, node, and value structures and parses only a synthesized call expression. Earlier package parse and type-check results remain in persisted Gno structures, and the exact .gno files are part of the chain-committed program record. The package path supplies the addressable identity, while behavior also depends on the persisted Gno structures, state, and evaluator version.

Stateful /r/ packages, called realms, extend the idea from readable code to durable objects. A realm has persistent state and an authority identity. At the end of a transaction, GnoVM follows changed object references, assigns persistent identities, saves reachable state, removes objects with no remaining references, and attributes the byte difference to a realm. Imports remain familiar while persistence adds realm ownership to the object graph.

The design yields inspectable programs, readable dependency paths, and typed persistent state. Each property depends on a wider execution boundary. Peer systems usually bind execution after source has been transformed.

Every smart-contract system needs a smaller execution contract than the host environment used to author code. Files, clocks, networks, concurrency, native libraries, and allocation without protocol gas are useful in ordinary programs and hazardous in replicated execution. The design question is where to constrain them and which artifact every validator agrees to execute.

Ethereum uses Solidity and Vyper for authoring and EVM bytecode for execution. Contract accounts hold the compiled bytes, and validators implement the EVM instruction set. Ethereum’s EVM documentation defines the deployed artifact; its verification guide explains the tradeoff. Readable source, compiler version, optimizer settings, and deployed bytecode must be matched after deployment.

CosmWasm’s officially supported contract stack uses Rust for authoring and WebAssembly for execution. Developers compile for wasm32-unknown-unknown, optimize the module, and upload the resulting binary. Rust parsing and type checking stay outside consensus; bytecode-level validation stays in the chain path. The build guide treats optimized Wasm as the deployable artifact, and the VM compatibility source constrains its structure, imports, exports, memory, limits, and capabilities.

Move carries more of its safety model into typed bytecode. Current Aptos builds place .mv modules beside separate .mvsm source maps and .move source files. The foundational Move design checks submitted bytecode for structural, type, reference, resource, semantic, and linking safety before interpretation. Move as deployed keeps verification inside consensus while the source compiler stays outside the trusted computing base and transaction critical path. The Aptos compilation guide and foundational Move paper describe that division.

Starknet preserves provability at its intermediate boundary. Cairo source compiles into Sierra, the declared contract representation. The declaring party obtains a CASM compilation and supplies its compiled-class hash, and once the declaration enters a block, the class trie maps the Sierra class hash to that lower-level hash. The current state documentation describes proving Sierra-to-CASM compilation inside the Starknet OS as future work. Starknet’s Sierra documentation explains how failed transactions remain provable and gas requirements become explicit before lower-level execution.

These systems still perform consensus-time analysis over an artifact below the full source language. The EVM executes an untyped instruction stream. CosmWasm validates a restricted Wasm module. Move verifies typed bytecode. Starknet commits the association between a Sierra class hash and a supplied compiled-class hash, then executes the CASM form. Current documentation assigns proof of Sierra-to-CASM compilation inside the Starknet OS to future work. The human-language parser and source compiler remain outside consensus; artifact decoding, validation, linking, and protocol binding remain inside.

A stable executable format keeps high-level source parsing, source-package resolution, compiler diagnostics, and optimizer evolution outside the consensus critical path. A smaller instruction vocabulary narrows what the protocol must hash, meter, specify, and test. Nodes may interpret, cache, JIT, or AOT-compile the committed artifact only when those strategies preserve consensus results and metering. Bytecode and IR guarantee none of those properties by themselves.

Execution identity in these systems is bound to the lower-level artifact. Human source can be published alongside it. Establishing correspondence requires reproducible compilation, metadata, or a verification service.

Gno chooses a wider boundary. Its language overview treats direct interpretation of the parsed syntax tree as a defining feature. Exact .gno files enter the chain-committed program record, and front-end admission work runs inside the state transition. Human-readable imports and direct source retrieval become consensus-visible features.

That wider boundary carries a structural cost. A source-language front end evolves across releases, processes adversarial input before contract initialization, and must preserve old semantics once persistent state depends on them. Parser behavior, host-checker configuration, preprocessing limits, dependency caches, gas prices, object persistence, and migration rules all enter the protocol surface. Gno accepts that larger surface to gain source-native composition.

The architectural tradeoff became visible at block 352,922, when validators processed the same package source with divergent evaluator cache states.

A Gno-specific security boundary appears in an ordinary method call.

Every persistent byte becomes work the network must carry into future blocks. Gno prices part of that obligation with a refundable storage bond.

The VMKeeper.processStorageDeposit source gathers realm-state byte changes, sorts realm paths for deterministic application, and locks the configured amount in ugnot, the base denomination of GNOT, when measured state grows. When state shrinks, value is released according to the realm’s historical deposit-to-storage ratio, so later price changes preserve the valuation attached to old bytes.

The refund recipient depends on token restrictions. Unrestricted ugnot goes to the caller who triggers the cleanup. Restricted ugnot goes to StorageFeeCollector, and the event records RefundWithheld. Realm design therefore determines who may allocate persistent bytes, who supplies the bond, and who can cause its release.

Gno’s source-native applications turn every runtime release into a question about history. A package remains useful only while later parsers, type checkers, realm rules, storage encodings, and libraries can still give its state an executable meaning or supply a deliberate migration.

The Topaz testnet release reports a direct experiment. The initial plan called for replaying gnoland1 and roughly 1.26 million Test13 transactions into a new genesis. That prototype approached three gigabytes and took about two hours on a fast machine. Language and API drift mattered more: a newer package-path rule rejected GnoSwap deployments, and the missing dependencies cascaded into roughly 1.2 million failed calls. Changes to AVL and runtime APIs broke further packages.

The team launched Topaz with curated packages and fresh state, leaving Test13 balances, realms, and names in the prior lineage. For a testnet, that was a documented engineering choice: a new state lineage replaced a replay full of compatibility patches.

The episode separates readable history from executable continuity. The archive preserves source and transaction attempts, while execution outcomes and distinct user identities remain unresolved, and reproducing their effects requires the old evaluator or a verified transformation into the new one. Because persistent state must remain meaningful under later evaluators, language compatibility directly governs state continuity.

The Topaz release links source and artifacts. It names a source revision, publishes binaries and checksums, and supplies a genesis-file digest. The inspected Darwin arm64 and Linux amd64 binaries embed the same revision. Establishing build reproducibility would require a bit-for-bit rebuild.

The release uses a lightweight, unsigned tag. Its checksums identify the downloaded bytes, while producer identity and the running process remain unresolved.

One build claim conflicts with the inspected artifacts. The release page says CGO_ENABLED=0. Both binaries report CGO_ENABLED=1 in their embedded metadata, and the Linux artifact is dynamically linked. CGO is the Go build mode that permits native C linkage, so the discrepancy concerns the build recipe rather than the named source revision.

Genesis introduces a related trust boundary. Startup instructions in the validator-guide source require --skip-genesis-sig-verification. The release README source explains that some transactions contain placeholder or intentionally invalidated signatures and that the names.Enable caller was patched after signing. The published digest lets validators check that they share the final genesis bytes. That startup flag makes the file the trusted input for initial state.

The public Topaz testnet endpoint self-reported a direct child of the release revision that adds a remote procedure call (RPC) idle-timeout setting. Artifact custody for that child build remains unresolved, as does the identity of the installed binary. The queried Gno Betanet status endpoint, a separate public network surface, left its application and software build fields empty.

Binding a public process to reviewed source requires specified build inputs, reproducible artifact identity, and evidence of the operator’s deployed binary. The Topaz record reaches identifiable release artifacts, while the observed process sits beyond that binding. Gno’s package-source model begins another identity chain inside the process. End-to-end verification requires both.

The Go comparison holds at the source layer: familiarity lowers the cost of reading and organizing Gno code. The execution contract then extends through the custom evaluator, realm rules, persistent objects, gas schedule, and migration policy. A reproducible 99% figure requires a declared corpus, weighting rule, version, and procedure.

Determinism depends on cache discipline, stable errors, metering, ordered state transitions, migration policy, and regression tests. The block 352,922 halt and its repair make that maintenance burden concrete. A supportable public claim should name the release, test boundary, and remaining type-check or preprocessing work.

On-chain source makes a deployed package directly inspectable without a voluntary address-to-source verification service. The parser, interpreter, compiled node, operator deployment, and interface still determine what that package becomes in use. Source-to-build evidence and deployed artifact identity would make the boundary traceable.

Storage deposits carry the clearest implemented GNOT utility in the examined source: measured realm-state growth locks ugnot, and eligible state release unlocks it according to the historical bond. Network-level attribution requires a named deployment and identified binary.

Block 352,922 joins the argument’s layers. Visible source made the failure legible, while cache history changed consensus-metered work. Realm authority, storage accounting, and runtime migration show the same dependency: inspection begins from readable source, while execution remains a property of evaluator and state. Gno is best understood as a source-native execution model whose credibility depends on evaluator discipline, release provenance, and state continuity.

Source findings use one immutable gnolang/gno snapshot. The parser and GnoVM package suites passed. Fixtures covered authority laundering, preprocessing allocation, mixed-history storage deposits, and CLI programs in supported, goroutine, channel, and generic forms. Code citations open records containing the exact revision, path, lines, and content identity. Documentation, releases, and endpoints are dated separately. These tests establish behaviour on the examined paths, while live exploitation and deployed-binary identity require deployment evidence.

Go resemblance holds at the source layer while a Gno-specific evaluator governs execution, admits .gno source as protocol input, and runs front-end work inside consensus. The observations below would defeat that claim or a supporting finding.