{"id":835236,"date":"2026-02-18T10:24:26","date_gmt":"2026-02-18T10:24:26","guid":{"rendered":"https:\/\/gridnet.org\/wpp\/?p=835236"},"modified":"2026-04-05T16:41:18","modified_gmt":"2026-04-05T16:41:18","slug":"gridscript-the-language-of-the-decentralized-state-machine-a-comprehensive-guide","status":"publish","type":"post","link":"https:\/\/mag.gridnet.org\/index.php\/2026\/02\/18\/gridscript-the-language-of-the-decentralized-state-machine-a-comprehensive-guide\/","title":{"rendered":"GridScript: The Language of the Decentralized State Machine \u2014 A Comprehensive Guide"},"content":{"rendered":"

Preface \u2014 The Language That Became an Operating System<\/h2>\n

In 1970, Charles H. Moore created Forth \u2014 a programming language so minimal, so close to the metal, that it could run on hardware with 8 kilobytes of memory. Forth was not elegant in the way that Lisp was elegant, nor structured in the way Pascal was structured. It was something else entirely: a language where the programmer thought in terms of a stack, where every operation consumed values and produced values, where the boundary between the language and the machine dissolved into nothing. NASA used Forth to control spacecraft. Telescope operators used it to point instruments at distant galaxies. It was the language of people who needed absolute control over every byte.<\/p>\n

Half a century later, a different kind of machine needed a language with those same properties \u2014 not a spacecraft, but a decentralized state machine. A machine that does not exist in any single location, that is maintained by independent operators across the globe, that must execute every instruction identically on every node, and that must do so with mathematical certainty. This machine is GRIDNET OS<\/strong> \u2014 the world’s first decentralized operating system. And its language is GridScript<\/strong>.<\/p>\n

GridScript is derived from Forth, but it is not Forth. Where Forth was designed to control hardware, GridScript was designed to control consensus. Where Forth communicated with serial ports and memory-mapped I\/O, GridScript communicates with a Merkle Patricia Trie holding the global state of a decentralized network. Where Forth programs ran on a single processor, GridScript programs are replicated and executed across every node in the network \u2014 deterministically, verifiably, and irreversibly. And where Forth execution is essentially free \u2014 instructions run as fast as the processor allows with no accounting \u2014 every single GridScript instruction consumes ERG<\/strong> (Execution Resource Gas), making it a metered computation model where unbounded execution is impossible by design. This single difference transforms GridScript from a language into an economic mechanism: computation has a price, and that price prevents denial-of-service attacks against the network.<\/p>\n

GridScript serves simultaneously as:<\/p>\n

\n
The transaction language<\/strong> \u2014 every blockchain transaction is a GridScript program compiled to bytecode<\/li>\n
The smart contract language<\/strong> \u2014 decentralized applications are written, deployed, and invoked in GridScript<\/li>\n
The system shell<\/strong> \u2014 operators manage GRIDNET Core nodes through an interactive GridScript terminal<\/li>\n
The consensus language<\/strong> \u2014 all nodes execute the same GridScript deterministically to reach agreement on state<\/li>\n
The query language<\/strong> \u2014 all data retrieval from the decentralized state machine is performed through GridScript execution<\/li>\n<\/ul>\n
This article is a comprehensive guide to GridScript \u2014 its architecture, its execution model, its role as the backbone of a decentralized service-oriented architecture, and its practical use in building applications that run without servers, without central authorities, and without trust in any single entity.<\/p>\n
I. Decentralized Processing Threads \u2014 The Cornerstone of Everything<\/h2>\n
If you understand only one concept in GridScript, let it be this: Decentralized Processing Threads (DPTs)<\/strong>. They are the mechanism through which every interaction with GRIDNET OS occurs \u2014 every value transfer, every smart contract call, every data query, every file operation. DPTs are to GRIDNET OS what HTTP requests are to the web, except they execute Turing-complete code inside a metered virtual machine on a decentralized network.<\/p>\n
BT and CT \u2014 Begin Thread, Commit Thread<\/h3>\n
The two most important commands in GridScript are BT<\/code> (Begin Thread) and CT<\/code> (Commit Thread). Together, they define the lifecycle of a transaction:<\/p>\n
BT\ncd \/YourDomainAddress\nsend RecipientAddress 1000000000000000000\nCT<\/pre>\nWhen BT<\/code> executes, it creates a new sub-thread \u2014 a sandbox where subsequent GridScript commands are accumulated but not executed<\/strong>. The commands are recorded into a code buffer. Inline commands like send<\/code> are automatically converted to their explicit stack-based forms (sendEx<\/code>) for serialization. The thread tracks its own ERG (Execution Resource Gas) consumption.<\/p>\n When CT<\/code> executes, it collects code from all ready threads, compiles the accumulated GridScript into bytecode, signs the transaction with the user’s private key, and submits it to the network. The transaction then propagates to all nodes, where it is re-executed in kernel mode \u2014 deterministically, identically, on every machine \u2014 and the resulting state changes are committed to the global Merkle Patricia Trie.<\/p>\n Ephemeral vs. Committed \u2014 The Two Modes of DPTs<\/h3>\nNot all DPTs result in blockchain transactions. This distinction is fundamental:<\/p>\n Committed DPTs<\/strong> follow the full BT \u2192 accumulate \u2192 CT<\/code> cycle. They produce signed transactions that modify the global state. A value transfer, a smart contract deployment, an identity registration \u2014 these are committed DPTs.<\/p>\n Ephemeral DPTs<\/strong> execute GridScript on a remote GRIDNET Core node without committing anything to the blockchain<\/em>. They are read-only queries against the current state of the decentralized state machine. When the Blockchain Explorer displays a list of recent transactions, it is using ephemeral DPTs. When the Wallet dApp retrieves an account balance, it is using an ephemeral DPT. The GridScript executes, reads from the state trie, produces a BER-encoded result, and the thread is discarded. No transaction is signed. No bytecode is stored. No ERG is charged to the user’s account.<\/p>\n This dual nature \u2014 the same mechanism serving both state-modifying transactions and read-only queries \u2014 is what makes DPTs the cornerstone of the entire GRIDNET OS architecture. Every UI dApp, every data retrieval operation, every interaction that a user has with the decentralized state machine flows through a DPT.<\/p>\n Multi-Thread Transactions<\/h3>\nGridScript supports formulating up to five threads simultaneously (MAX_THREADS_COUNT = 5<\/code>), enabling atomic multi-operation transactions:<\/p>\n BT\ncd \/DomainA\nsend Recipient1 1000000000000000000\nBT\ncd \/DomainB\nsend Recipient2 2000000000000000000\nCT \\ Commits all ready threads as one atomic transaction<\/pre>\nThread management commands provide fine-grained control: RT<\/code> (Resume Thread), ST<\/code> (Suspend Thread), PT<\/code> (Print Thread \u2014 show accumulated code), FT<\/code> (Focus Thread \u2014 switch between threads), and AT<\/code> (Abort Thread \u2014 discard accumulated code).<\/p>\n II. GridScript as a Decentralized Service-Oriented Architecture<\/h2>\nStop and consider what is actually happening when a user opens the Wallet UI dApp or the Blockchain Explorer in their browser. Every balance displayed. Every transaction listed. Every block detail rendered. Every identity resolved. None of it comes from a traditional server. There is no PHP backend. There is no .NET API. There is no REST endpoint hosted in a data center. Every single piece of data the user sees on screen is retrieved through GridScript code executing on remote GRIDNET Core nodes<\/strong> \u2014 decentralized machines operated independently across the network.<\/p>\n This is the GridScript Service-Oriented Architecture (SOA)<\/strong>, and it is what makes the entire GRIDNET OS dApp ecosystem work.<\/p>\n The Data Flow Pipeline<\/h3>\nThe SOA pipeline operates in six stages:<\/p>\n \nJavaScript formulates the request<\/strong> \u2014 Browser-side code in VMContext.js<\/code> (which exports the CVMContext<\/code> singleton) constructs a GridScript data request. This might be a balance query, a transaction search, a block listing, or a domain lookup.<\/li>\n BER encoding<\/strong> \u2014 The request is serialized using BER (Basic Encoding Rules) \u2014 an efficient binary encoding format derived from ASN.1. BER is not JSON. It is not Protocol Buffers. It is a compact, self-describing binary format that can represent complex nested data structures with minimal overhead. Web Workers perform the encoding off the main thread to keep the UI responsive.<\/li>\n Double-encrypted transport<\/strong> \u2014 The BER-encoded request is wrapped in ECC (Elliptic Curve Cryptography) encryption at the application level, then transmitted through a TLS-secured WebSocket. Two independent encryption layers. An attacker who compromised TLS would still face a second cryptographic barrier.<\/li>\n GridScript VM execution<\/strong> \u2014 The remote GRIDNET Core node receives the request, decodes it, and executes the corresponding GridScript handler. The VM traverses the Merkle Patricia Trie \u2014 the global state database \u2014 reading account data, transaction histories, block headers, identity tokens, or whatever the request demands.<\/li>\n BER-encoded response<\/strong> \u2014 The results are packaged into structured BER metadata \u2014 organized into typed sections (directoryListing<\/code>, searchResults<\/code>, notifications<\/code>, transactionInfo<\/code>, blockInfo<\/code>, domainInfo<\/code>) containing typed entries. This structured format enables rich data exchange between the VM and the browser.<\/li>\n CVMContext receives and dispatches<\/strong> \u2014 The BER-encoded response arrives back through the same double-encrypted, onion-routed channel. The in-browser GRIDNET OS subsystem \u2014 the CVMContext singleton<\/strong> \u2014 receives the raw data, decodes it using CVMMetaParser<\/code>, and dispatches it through two distinct mechanisms:\n\nActive waiting (request-response)<\/strong> \u2014 A UI dApp that initiated a specific data request is actively awaiting<\/em> the response. It holds a pending Promise or async callback keyed to the request ID it generated. When CVMContext<\/code> encounters that request ID in the incoming BER data, it resolves the waiting call directly \u2014 the dApp receives exactly the data it asked for. This is the primary pattern for queries: the Wallet asks for a balance, the Explorer asks for a block list, and each await<\/code>s the specific response.<\/li>\n Passive notification (event-driven)<\/strong> \u2014 UI dApps may also register general-purpose event listeners for broad categories of data \u2014 new block announcements, VM state changes, commit status transitions, DFS updates, incoming network messages. These listeners fire whenever CVMContext<\/code> receives matching data, regardless of whether the dApp initiated the request. A new block notification may reach both the Explorer and the Wallet simultaneously; a commit confirmation may notify multiple dApps that share a transaction context. The dApp does not ask for this data \u2014 it arrives because the dApp has expressed interest in a category of events.<\/li>\n<\/ul>\nThis dual dispatch model \u2014 active request-response correlation and<\/em> passive event subscription \u2014 operating simultaneously through the same CVMContext<\/code> singleton is what gives GRIDNET OS UI dApps both the responsiveness of traditional client-server applications and the real-time reactivity of event-driven systems.<\/li>\n UI dApp renders<\/strong> \u2014 Whether actively awaiting a response or passively notified of an event, the UI dApp instance receives the decoded data, processes it according to its own logic, and updates its Shadow DOM. The user sees data on screen and has no idea that what just happened bears no resemblance to a conventional HTTP request-response cycle.<\/li>\n<\/ol>\nThe GridScript SOA pipeline \u2014 from browser-side JavaScript through double-encrypted transport to remote GridScript VM execution, with BER-encoded responses flowing back through CVMContext to individual UI dApp instances.<\/figcaption><\/figure>\nPerformance That Defies Expectations<\/h3>\nThe measured balance update latency \u2014 the round-trip time from browser request to rendered result through this entire double-encrypted, BER-encoded pipeline \u2014 is 20\u201345 milliseconds on a local network<\/strong> (WAN latency varies with node proximity and network hops). This is on par with, and in many cases faster than, conventional centralized web frameworks querying a local database.<\/p>\n This performance is possible because BER encoding is remarkably efficient for the structured data GRIDNET OS works with. Unlike JSON, which carries field names as human-readable strings in every message, BER uses numeric tags and length prefixes, producing payloads that are significantly smaller. Unlike Protocol Buffers, BER requires no schema compilation step \u2014 the encoding is self-describing. The VM Meta-Data Protocol builds on BER with a Sections \u2192 Entries structure, where each section has a typed purpose and each entry carries a request ID for correlation \u2014 enabling multiple concurrent asynchronous requests to be in flight simultaneously.<\/p>\n How dApps Use This Architecture<\/h3>\nThe Blockchain Explorer UI dApp provides a vivid example. When a user navigates to the Blocks view, the Explorer’s JavaScript constructs a GridScript request to fetch recent blocks with sorting and filtering parameters. The request is BER-encoded, dispatched through the encrypted WebSocket, and routed to a GRIDNET Core node. On that node, the GridScript VM executes a stateful iterator \u2014 a cursor that traverses the block chain with pagination support, filter matching, and sort optimization. The VM enhanced this capability with stateful iterators that remember position between calls, eliminating the need to re-traverse from the beginning for each page of results. The results \u2014 block headers with height, timestamp, transaction count, miner ID, difficulty, reward \u2014 are BER-encoded into a searchResults<\/code> section and returned. The browser decodes and renders a Tabulator data grid with cyberpunk aesthetics.<\/p>\n The BER Meta-Data Protocol<\/h3>\nCommunication between browser and GRIDNET Core follows a structured protocol built on BER encoding:<\/p>\n \/\/ JavaScript side \u2014 constructing a request\nconst generator = new CVMMetaGenerator();\ngenerator.addRAWGridScriptCmd(gridScriptCode, requestID, processID, vmID);\nconst berData = generator.finalize();\n\/\/ Send through encrypted WebSocket...<\/pre>\nArchitecture reference (GRIDNET Core internal):<\/strong><\/p>\n \/\/ On the GRIDNET Core side \u2014 C++ processing\nCVMMetaGenerator gen;\ngen.beginSection(eVMMetaSectionType::searchResults);\ngen.addTransactionInfo(txDesc, reqID, appID, vmID);\ngen.endSection();\ngen.finalize();\nvector<uint8_t> data = gen.getData();<\/pre>\nThe protocol supports dozens of entry types: GridScriptCode<\/code>, terminalData<\/code>, transactionInfo<\/code>, blockInfo<\/code>, domainInfo<\/code>, searchResults<\/code>, fileContent<\/code>, stateLessChannelElement<\/code>, and many more. Each entry carries metadata for request-response correlation, enabling the browser to match responses to the specific UI component that initiated the request.<\/p>\n The three-tier data hierarchy \u2014 Level 1 (raw transaction\/receipt on-chain data), Level 2 (core info containers), Level 3 (BER-compatible description objects for transactions, blocks, and domains) \u2014 ensures that the same data structures are serialized identically in C++ and JavaScript, achieving full parity between the native Core implementation and the browser-side ECMA6 objects.<\/p>\n III. Where GridScript Runs \u2014 The Six Execution Contexts<\/h2>\nGridScript is not confined to a single execution environment. It runs in six distinct contexts, each with different capabilities and security restrictions:<\/p>\n 1. SSH \u2014 Direct Connection to GRIDNET Core<\/h3>\nThe most direct way to interact with GridScript. Connect via SSH to a running GRIDNET Core node and you have a full interactive terminal \u2014 the Forth heritage made tangible. Type commands, watch the stack, formulate transactions, manage the node. Every command in the GridScript vocabulary is available, subject only to authentication level.<\/p>\n \\ SSH session example\n10 20 + . \\ prints 30\n.\" Hello, GRIDNET!\" cr\nbalance 'MyDomain'\n. \\ prints balance in attoGNC<\/pre>\n2. Local Instance \u2014 Ctrl+E in GRIDNET Core<\/h3>\nWhen running GRIDNET Core directly, pressing Ctrl+E switches from the Events View to the Terminal View \u2014 an embedded GridScript console. This provides the same capabilities as SSH but with physical access to the machine. Certain administrative commands (like shutdown<\/code> or firewall<\/code>) may require this local context.<\/p>\n 3. Terminal UI dApp \u2014 Browser-Based Terminal<\/h3>\nThe Terminal dApp brings GridScript to the browser. Built on xterm.js, it provides a full terminal experience within the GRIDNET OS desktop environment. The Terminal registers for VM metadata callbacks, DFS message events, and GridScript result notifications through CVMContext<\/code> \u2014 the same SOA pipeline used by all dApps. Commands entered in the browser terminal are transmitted to a GRIDNET Core node for execution, with results streamed back in real-time.<\/p>\n 4. Smart Contract Execution \u2014 On-Chain Bytecode<\/h3>\nWhen a transaction is committed, its GridScript is compiled to bytecode and executed in kernel mode<\/strong> across all network nodes. Kernel mode is the consensus context \u2014 fully deterministic, no terminal I\/O, no file system access, no user interaction. The VM checks REG_KERNEL_THREAD<\/code> to enforce these restrictions. Smart contracts deployed via BC<\/code>\/EC<\/code> (Begin Code \/ End Code) are stored as bytecode in the state trie:<\/p>\n BT\ncd \/YourDomain\/contracts\nBC\ncd \/YourDomain\ngetVar 'counter'\n1 +\n0 \"counter\" setVarEx\nEC\nCT<\/pre>\nThe bytecode format uses sequential opcode assignment starting from BASE_OPCODE_ID = 9<\/code>. Single-byte encoding for opcodes \u2264 127, two-byte encoding for higher values. The order of codewords is immutable<\/strong> \u2014 new commands are always appended at the end. Reordering would break every compiled contract on the blockchain.<\/p>\n 5. Implicit via JavaScript APIs \u2014 VMContext.js<\/h3>\nThis is the SOA context described in the previous section. JavaScript code in the browser generates GridScript automatically \u2014 the developer may not even realize GridScript is being executed. When a dApp calls a balance query or transaction search through CVMContext<\/code>, the JavaScript constructs GridScript data requests, BER-encodes them, and dispatches them to remote nodes.<\/p>\n 6. User Interactions with UI dApps<\/h3>\nDrag a file in the File Manager. Send GNC in the Wallet. Deploy an identity token. Every user action in a UI dApp is ultimately formulated as GridScript \u2014 making it reproducible across the entire decentralized system once committed. The Wallet dApp pioneered this architecture: JavaScript ECMA6 formulates GridScript instruction sequences, Web Workers perform BER encoding and GridScript compilation and ECC signing off the main thread, and compiled bytecode is dispatched through onion-routed encrypted WebSocket channels.<\/p>\n The Security Model \u2014 Permission Layers in Depth<\/h3>\nEvery one of GridScript’s 312+ codewords carries 18 security properties<\/strong> that are checked at runtime before the instruction executes. This is not a coarse-grained permission system \u2014 it is per-instruction, per-context security enforcement.<\/p>\n Permission Levels<\/h4>\nFrom least restrictive to most restrictive:<\/p>\n Level 1: Public Commands<\/strong> \u2014 Arithmetic (+<\/code>, -<\/code>, *<\/code>, \/<\/code>), stack operations (dup<\/code>, drop<\/code>, swap<\/code>), comparison, and logic. These execute in any context \u2014 kernel mode, terminal, GUI, smart contract. No restrictions.<\/p>\n Level 2: Terminal-Only Commands<\/strong> (onlyFromTerminal = true<\/code>) \u2014 BT<\/code>, CT<\/code>, keygen<\/code>, BC<\/code>\/EC<\/code>, setKey<\/code>, node configuration. These cannot<\/strong> be called from kernel mode during consensus execution. If a smart contract attempted to call BT<\/code>, the VM would reject it \u2014 you cannot formulate a transaction from within a transaction.<\/p>\n Level 3: Local Admin Commands<\/strong> (requiresLocalAdminCredentials = true<\/code>) \u2014 shutdown<\/code>, firewall<\/code>. These require physical or local access to the machine and administrator authentication via sudo<\/code>.<\/p>\n Level 4: Overwatch Commands<\/strong> (allowedOnlyByAnOverwatch = true<\/code>) \u2014 Critical system modifications that only the network’s highest-privilege entities (overwatches) can perform. The VM checks REG_EXECUTING_BY_OVERWATCH<\/code> (register 16).<\/p>\n Level 5: Kernel-Restricted Commands<\/strong> (allowedInKernelMode = false<\/code>) \u2014 File I\/O, erg<\/code> management, network operations, blockchain queries like getChain<\/code>, stepBack<\/code>. These are forbidden during consensus execution<\/strong> because they would break determinism.<\/p>\n Security Registers \u2014 Identity and Privilege<\/h4>\nGridScript maintains 54 special-purpose registers (indices 0\u201453). Several are critical for security:<\/p>\n REG_CALLERS_ID<\/code> (register 11) vs REG_AUTHENTICATED_SD<\/code> (register 12)<\/strong> \u2014 REG_CALLERS_ID<\/code> identifies who signed and paid<\/strong> for the transaction. REG_AUTHENTICATED_SD<\/code> identifies who has permission<\/strong> to execute the current operation. These can differ during delegation, proxy execution, or sponsored transactions.<\/p>\n \\ Inside a smart contract \u2014 check both:\n11 getReg \\ Read REG_CALLERS_ID \u2014 who SIGNED the transaction\n12 getReg \\ Read REG_AUTHENTICATED_SD \u2014 who HAS PERMISSION\nfcomp \\ Compare them\n\\ If different: delegation or proxy execution is occurring<\/pre>\n\u26a0 REG_AUTHENTICATED_SD<\/code> must be cleared after a dApp exits<\/strong> \u2014 failure to do so causes privilege leakage.<\/p>\n REG_KERNEL_THREAD<\/code> (register 34)<\/strong> \u2014 The kernel mode flag. When set, execution is occurring as part of consensus. Only kernel threads can modify decentralized state. This register is read-only<\/strong> and set internally by the VM.<\/p>\n Complete Register Reference \u2014 All 54 Registers (0\u201453)<\/h4>\nGridScript maintains 54 special-purpose registers accessible via the getReg<\/code> codeword. Each register stores state critical to the operation of the Decentralized State Machine.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n#<\/th>\n Name<\/th>\n Description<\/th>\n Category<\/th>\n<\/tr>\n 0<\/td>\n REG_EXEC_SD<\/code><\/td>\n Executing State Domain \u2013 current domain context affecting data access scope<\/td>\n Critical<\/td>\n<\/tr>\n 1<\/td>\n REG_DATA_TYPE<\/code><\/td>\n Data Type Indicator for the most recent operation result<\/td>\n Context<\/td>\n<\/tr>\n 2<\/td>\n REG_SIGN<\/code><\/td>\n Sign flag from the most recent arithmetic operation<\/td>\n Context<\/td>\n<\/tr>\n 3<\/td>\n REG_CURRENT_SD<\/code><\/td>\n Current state domain \u2013 active domain for state operations (set by cd<\/code>)<\/td>\n Context<\/td>\n<\/tr>\n 4<\/td>\n REG_CURRENT_DIR<\/code><\/td>\n Current directory path within the state domain (DFS navigation)<\/td>\n Context<\/td>\n<\/tr>\n 5<\/td>\n REG_THROW_ON_FAILURE<\/code><\/td>\n When set, operations throw runtime errors on failure instead of returning error codes<\/td>\n Error<\/td>\n<\/tr>\n 6<\/td>\n REG_PRIV_KEY<\/code><\/td>\n Active private key for signing operations (terminal session)<\/td>\n Crypto<\/td>\n<\/tr>\n 7<\/td>\n REG_RECEIPT_ID<\/code><\/td>\n Receipt ID of the current transaction (set after commit)<\/td>\n Crypto<\/td>\n<\/tr>\n 8<\/td>\n REG_BASE58_DEBUG_VIEW<\/code><\/td>\n When set, .s<\/code> and .m<\/code> display pointer values in base58 encoding<\/td>\n Debug<\/td>\n<\/tr>\n 9<\/td>\n REG_MAKING_SACRIFICE<\/code><\/td>\n Flag: a sacrifice (staking) operation is in progress<\/td>\n State<\/td>\n<\/tr>\n 10<\/td>\n REG_EXECUTING_CODE_ID<\/code><\/td>\n Identifier of the currently executing code bundle (smart contract path)<\/td>\n System<\/td>\n<\/tr>\n 11<\/td>\n REG_CALLERS_ID<\/code><\/td>\n Critical:<\/strong> Identity of the entity that signed<\/em> and paid for the transaction.<\/td>\n Critical<\/td>\n<\/tr>\n 12<\/td>\n REG_AUTHENTICATED_SD<\/code><\/td>\n Critical:<\/strong> Identity of the entity with permission<\/em> to execute the current operation.<\/td>\n Critical<\/td>\n<\/tr>\n 13<\/td>\n REG_DAPP_INC_BALANCE_CHANGE<\/code><\/td>\n Incremental balance change caused by the current dApp execution<\/td>\n State<\/td>\n<\/tr>\n 14<\/td>\n REG_DOING_COLON<\/code><\/td>\n Flag: currently inside a colon definition (: name ... ;<\/code>)<\/td>\n Exec State<\/td>\n<\/tr>\n 15<\/td>\n REG_SACRIFICED_VALUE<\/code><\/td>\n The GNC amount sacrificed (staked) in the current transaction<\/td>\n State<\/td>\n<\/tr>\n 16<\/td>\n REG_EXECUTING_BY_OVERWATCH<\/code><\/td>\n Security:<\/strong> When set, grants highest privilege level (Overwatch restricted).<\/td>\n Critical<\/td>\n<\/tr>\n 17<\/td>\n REG_TALKING_TO<\/code><\/td>\n Target entity for messaging operations<\/td>\n System<\/td>\n<\/tr>\n 18<\/td>\n REG_APP_RUNNING<\/code><\/td>\n Flag: a dApp (smart contract) is currently executing<\/td>\n System<\/td>\n<\/tr>\n 19<\/td>\n REG_EXTERNAL_DATA<\/code><\/td>\n External data attached to the current execution context<\/td>\n System<\/td>\n<\/tr>\n 20<\/td>\n REG_REQ_APP_ABORT<\/code><\/td>\n Request abort of the currently running dApp from external source<\/td>\n System<\/td>\n<\/tr>\n 21<\/td>\n REG_SUPPRESS_THROW<\/code><\/td>\n Suppresses throw on the very next instruction. Auto-clears after one instruction.<\/td>\n Error<\/td>\n<\/tr>\n 22<\/td>\n REG_SUPPRESS_DFS_THROW<\/code><\/td>\n Suppresses throw on the next DFS operation. Auto-clears after next DFS call.<\/td>\n Error<\/td>\n<\/tr>\n 23<\/td>\n REG_COMMIT_PENDING<\/code><\/td>\n Flag: a transaction commit is pending network confirmation<\/td>\n Control<\/td>\n<\/tr>\n 24<\/td>\n REG_THREAD_READY<\/code><\/td>\n Flag: thread\/transaction formulation is finished and ready for commitment<\/td>\n Control<\/td>\n<\/tr>\n 25<\/td>\n REG_THREAD_PAUSED<\/code><\/td>\n Flag: the current thread is paused (via ST<\/code>)<\/td>\n Control<\/td>\n<\/tr>\n 26<\/td>\n REG_EXECUTING_INSTRUCTION<\/code><\/td>\n Currently executing instruction identifier<\/td>\n Exec State<\/td>\n<\/tr>\n 27<\/td>\n REG_EXECUTING_PROGRAM<\/code><\/td>\n Currently executing program\/word identifier<\/td>\n Exec State<\/td>\n<\/tr>\n 28<\/td>\n REG_HIGH_PRECISION<\/code><\/td>\n Enables high-precision arithmetic mode and display formatting.<\/td>\n Output<\/td>\n<\/tr>\n 29<\/td>\n REG_LOGGED_IN_AS<\/code><\/td>\n Identity of the currently logged-in user (set by logmein<\/code>)<\/td>\n Critical<\/td>\n<\/tr>\n 30<\/td>\n REG_WAS_SANDBOX_PRE_AUTHED<\/code><\/td>\n Per-command sandbox pre-authorization flag<\/td>\n Security<\/td>\n<\/tr>\n 31<\/td>\n REG_IS_THREAD_UI_AWARE<\/code><\/td>\n Security:<\/strong> Indicates if thread can perform UI operations (Read-Only).<\/td>\n Critical<\/td>\n<\/tr>\n 32<\/td>\n REG_IS_TEXT_OUTPUT_ENABLED<\/code><\/td>\n Controls whether text output operations produce visible output<\/td>\n Threading<\/td>\n<\/tr>\n 33<\/td>\n REG_HAS_DETACHED_THREAD<\/code><\/td>\n Indicates whether a detached native thread is attached to VM thread<\/td>\n Threading<\/td>\n<\/tr>\n 34<\/td>\n REG_KERNEL_THREAD<\/code><\/td>\n Critical:<\/strong> Kernel mode flag (Read-Only). Execution is part of consensus.<\/td>\n Critical<\/td>\n<\/tr>\n 35<\/td>\n REG_DO_NOT_COMPILE_READS<\/code><\/td>\n When set, data-read operations are excluded from bytecode compilation<\/td>\n Compilation<\/td>\n<\/tr>\n 36<\/td>\n REG_NEW_LINE<\/code><\/td>\n Internal newline tracking for output formatting<\/td>\n Threading<\/td>\n<\/tr>\n 37<\/td>\n REG_PP_MODE<\/code><\/td>\n Flag: executing within a GridScript++ (evalGPP<\/code>) context<\/td>\n Exec State<\/td>\n<\/tr>\n 38<\/td>\n REG_ABORT<\/code><\/td>\n Abort signal from GridScript++ context<\/td>\n Control<\/td>\n<\/tr>\n 39<\/td>\n REG_LAST_ERROR<\/code><\/td>\n Contains the error message from the most recent failure<\/td>\n Error<\/td>\n<\/tr>\n 40<\/td>\n REG_CURRENT_CODE_PATH<\/code><\/td>\n File path of the currently executing code<\/td>\n Context<\/td>\n<\/tr>\n 41<\/td>\n REG_ASSETS_RECEIVED_FROM<\/code><\/td>\n Identity of the entity that sent assets (GNC) to the current context<\/td>\n State<\/td>\n<\/tr>\n 42<\/td>\n REG_PRESERVE_RECENT_CALL<\/code><\/td>\n Instructions leading to current dApp invocation remain in compiled source<\/td>\n Compilation<\/td>\n<\/tr>\n 43<\/td>\n REG_IMPLICIT_CALL_THREAD_BEGAN<\/code><\/td>\n Internal: implicit contract call has been initiated<\/td>\n Control<\/td>\n<\/tr>\n 44<\/td>\n REG_CALLERS_ID_BEFORE_DAPP_CALLED<\/code><\/td>\n Saved identity before dApp invocation. Restored on exit.<\/td>\n Security<\/td>\n<\/tr>\n 45<\/td>\n REG_EXCUSE_ERG_USAGE<\/code><\/td>\n Bypasses ERG checks during block replay (Trusted Internal Only).<\/td>\n ERG<\/td>\n<\/tr>\n 46<\/td>\n REG_KERNEL_ERG_BID<\/code><\/td>\n ERG bid (price per ERG unit). Set via erg -setbid<\/code>.<\/td>\n ERG<\/td>\n<\/tr>\n 47<\/td>\n REG_KERNEL_ERG_LIMIT<\/code><\/td>\n Max ERG allowed for transaction. Set via erg -setlimit<\/code>.<\/td>\n ERG<\/td>\n<\/tr>\n 48<\/td>\n REG_KERNEL_NONCE<\/code><\/td>\n Manual nonce override. Allows enqueueing transactions.<\/td>\n Threading<\/td>\n<\/tr>\n 49<\/td>\n (Reserved)<\/em><\/td>\n Internal structural reserve<\/td>\n –<\/td>\n<\/tr>\n 50<\/td>\n REG_CUMULATIVE_TRANSFER_GNC<\/code><\/td>\n Running total of GNC transferred in current transaction bundle.<\/td>\n State<\/td>\n<\/tr>\n 51<\/td>\n REG_CUMULATIVE_TT_CASHOUT_GNC<\/code><\/td>\n Running total of TT cashout value in this transaction.<\/td>\n State<\/td>\n<\/tr>\n 52<\/td>\n REG_ALL_GNC_RECIPIENTS<\/code><\/td>\n Array of recipient-value pairs for current transaction.<\/td>\n State<\/td>\n<\/tr>\n 53<\/td>\n REG_ALL_TT_POOL_IDS<\/code><\/td>\n Set of unique Token Pool IDs involved in current transaction.<\/td>\n State<\/td>\n<\/tr>\n<\/table>\nContract Debugging with REG_PRESERVE_RECENT_CALL<\/h3>\nDebugging decentralized code is notoriously difficult. GridScript addresses this via Register 42 (REG_PRESERVE_RECENT_CALL)<\/strong>. When this register is enabled (set to 1), the VM includes the instructions that preceded<\/em> the call<\/code> or callEx<\/code> codeword in the final compiled bytecode. This allows for full stack-trace reconstruction in the event of a contract failure, as the parameters passed to the contract remain part of the signed transaction record rather than being discarded after execution. This is a critical tool for developers during the “Magic Button” (\u27ea\u27ea\u27ea) debugging phase, ensuring that opaque contract errors can be traced back to their specific input state.<\/p>\n IV. Stack-Based Fundamentals \u2014 The Forth Heritage<\/h2>\nIf you have never used a stack-based language, the mental model is simple:<\/p>\n \nEverything is a word<\/strong> \u2014 commands, numbers, operators are all “words”<\/li>\n Numbers push themselves<\/strong> onto the stack<\/li>\n Words consume and produce<\/strong> stack values<\/li>\n No parentheses needed<\/strong> \u2014 execution order is left-to-right, stack-driven<\/li>\n<\/ol>\n10 20 + \\ Push 10, push 20, add \u2192 stack contains 30\n5 * \\ Push 5, multiply \u2192 stack contains 150\n. \\ Print top of stack \u2192 outputs \"150\"<\/pre>\nThe Three Stacks<\/h3>\nGridScript maintains three stacks:<\/p>\n Data Stack (dStack)<\/strong> \u2014 The primary operand stack. Maximum depth: 256. This is where you push numbers, pointers, addresses, and where operations consume and produce results.<\/p>\n Return Stack (rStack)<\/strong> \u2014 Used for temporary storage and loop control. Loop constructs (DO...LOOP<\/code>) use the return stack to track loop indices.<\/p>\n Meta Stack<\/strong> \u2014 Parallel to the data stack, tracking type information (integer, pointer, string, BigInt) for runtime type checking and debugging. Each value on the data stack has a corresponding type descriptor on the meta stack.<\/p>\n Stack Manipulation<\/h3>\ndup \\ ( a -- a a ) Duplicate top\nswap \\ ( a b -- b a ) Swap top two\nover \\ ( a b -- a b a ) Copy second to top\nrot \\ ( a b c -- b c a ) Rotate top three\ndrop \\ ( a -- ) Remove top\npick \\ ( ... u -- ... xu ) Copy item at depth u\nroll \\ ( ... u -- ... ) Move item at depth u to top\ndepth \\ ( -- n ) Current stack depth<\/pre>\nControl Flow \u2014 Conditionals, Loops, and Word Definitions<\/h3>\nGridScript inherits Forth’s complete control flow vocabulary. All branching constructs compile to (zbranch)<\/code> and (branch)<\/code> opcodes at compile time.<\/p>\n Conditionals \u2014 IF…THEN…ELSE<\/h4>\n\\ IF...THEN (basic conditional)\n: is-positive ( n -- )\n 0 > IF\n .\" Positive!\" cr\n THEN\n;\n5 is-positive \\ prints: Positive!\n\n\\ IF...ELSE...THEN\n: abs ( n -- |n| )\n dup 0 < IF\n -1 *\n ELSE\n \\ already positive, do nothing\n THEN\n;\n-7 abs . \\ prints: 7<\/pre>\nCounted Loops \u2014 DO...LOOP and DO...+LOOP<\/h4>\n\\ DO...LOOP \u2014 iterates from start to limit-1\n: count-to ( n -- )\n 0 DO\n i . \\ 'i' pushes current loop index\n LOOP cr\n;\n5 count-to \\ prints: 0 1 2 3 4<\/pre>\nIndefinite Loops \u2014 BEGIN...UNTIL and BEGIN...WHILE...REPEAT<\/h4>\n\\ BEGIN...UNTIL (post-test \u2014 always executes at least once)\n: countdown ( n -- )\n BEGIN\n dup . 1 -\n dup 0 =\n UNTIL drop cr\n;<\/pre>\nV. Command Reference \u2014 The GridScript Vocabulary<\/h3>\nGridScript’s vocabulary encompasses 312 codewords. Each entry shows the command name, its stack effect notation ( before -- after )<\/code>, and its purpose.<\/p>\n Data Input<\/h3>\n\ndata64<\/code> ( -- ptr )<\/code> \u2014 Push base64Check-decoded binary data onto the stack<\/li>\n data<\/code> ( -- ptr )<\/code> \u2014 Push UTF-8 string data onto the stack<\/li>\n data58<\/code> ( -- ptr )<\/code> \u2014 Push base58Check-decoded binary data (e.g. addresses)<\/li>\n<\/ul>\nAssertions<\/h3>\n\nassert<\/code> ( flag -- )<\/code> \u2014 Abort execution if flag is false (0)<\/li>\n assert0<\/code> ( flag -- )<\/code> \u2014 Abort execution if flag is true (nonzero)<\/li>\n anz<\/code> ( n -- n )<\/code> \u2014 Assert non-zero: aborts execution if n<\/code> is zero<\/li>\n<\/ul>\nMemory Access<\/h3>\n\n!<\/code> ( value addr -- )<\/code> \u2014 Store cell value at address<\/li>\n @<\/code> ( addr -- value )<\/code> \u2014 Fetch cell value from address<\/li>\n alloc<\/code> ( size -- addr ior )<\/code> \u2014 Allocate memory block (1 ERG per byte)<\/li>\n free<\/code> ( addr -- )<\/code> \u2014 Free previously allocated memory<\/li>\n<\/ul>\nArithmetic & Logic<\/h3>\n\n+<\/code>, -<\/code>, *<\/code>, \/<\/code>, mod<\/code> \u2014 Standard arithmetic operations<\/li>\n <<\/code>, =<\/code>, ><\/code> \u2014 Basic comparison (returns 1 for true, 0 for false)<\/li>\n and<\/code>, or<\/code>, xor<\/code> \u2014 Bitwise logic<\/li>\n fcomp<\/code> ( ptr1 ptr2 -- flag )<\/code> \u2014 Compare two binary pointers<\/li>\n<\/ul>\nState & Persistence<\/h3>\n\ncd<\/code> ( -- )<\/code> \u2014 Change directory \/ State Domain (inline param: \/path<\/code>)<\/li>\n getVar<\/code> ( -- ptr )<\/code> \u2014 Read variable state (inline param: name<\/code>)<\/li>\n setVarEx<\/code> ( value isHidden name -- )<\/code> \u2014 Write persistent state variable<\/li>\n ls<\/code> ( -- )<\/code> \u2014 List directory\/domain contents<\/li>\n write<\/code> ( -- )<\/code> \u2014 Write data to DFS file (inline param: filename<\/code>)<\/li>\n cat<\/code> ( -- ptr )<\/code> \u2014 Read data from DFS file (inline param: filename<\/code>)<\/li>\n<\/ul>\nValue Transfer (GNC)<\/h3>\n\nsend<\/code> ( -- )<\/code> \u2014 Send GNC (inline params: address amount<\/code>)<\/li>\n sendEx<\/code> ( flags target amount -- )<\/code> \u2014 Explicit value transfer<\/li>\n balance<\/code> ( -- ptr )<\/code> \u2014 Query GNC balance (inline param: address<\/code>)<\/li>\n xvalue<\/code> ( -- value )<\/code> \u2014 Get GNC amount attached to transaction<\/li>\n gotGNC<\/code> ( -- flag )<\/code> \u2014 Returns 1 if GNC was received in this context<\/li>\n<\/ul>\nTransaction & Code<\/h3>\n\nBT<\/code> \u2014 Begin transaction formulation (Accumulation mode)<\/li>\n CT<\/code> \u2014 Commit threads (Sign and submit transaction)<\/li>\n BC<\/code> \/ EC<\/code> \u2014 Begin\/End Code accumulation (Smart contract deployment)<\/li>\n call<\/code> ( -- )<\/code> \u2014 Invoke smart contract (inline param: path<\/code>)<\/li>\n callEx<\/code> ( pathPtr -- )<\/code> \u2014 Invoke contract from pointer<\/li>\n evalGPP<\/code> ( -- )<\/code> \u2014 Invoke GridScript++ JavaScript engine<\/li>\n txconfig<\/code> \u2014 Unified ERG and Nonce configuration utility<\/li>\n<\/ul>\nOperating System (DFS Management)<\/h3>\n\nmkdir<\/code> ( -- )<\/code> \u2014 Create a new directory in the current State Domain (inline param: \/path<\/code>)<\/li>\n touch<\/code> ( -- )<\/code> \u2014 Create an empty file if it does not exist (inline param: filename<\/code>)<\/li>\n rm<\/code> ( -- )<\/code> \u2014 Remove a file or directory from the DFS (inline param: path<\/code>)<\/li>\n setfacl<\/code> ( -- )<\/code> \u2014 Set Access Control List permissions for a path (inline param: path permissions<\/code>)<\/li>\n chown<\/code> ( -- )<\/code> \u2014 Change the owner identity of a specific path (inline param: path owner<\/code>)<\/li>\n poll<\/code> ( -- )<\/code> \u2014 Block execution until a state change or network event occurs (EPHEMERAL ONLY)<\/li>\n<\/ul>\nThe context<\/code> Codeword (Remote API Gateway)<\/h3>\nThe context<\/code> codeword is the primary interface used by dApps to perform high-level queries against the decentralized state machine. It provides structured results packaged for the CVMContext<\/code> JavaScript API.<\/p>\n Syntax:<\/strong> context -c [subcommand] [options]<\/code><\/p>\n \n-c searchBlockchain<\/code> \u2014 Perform a global search using mkfilter<\/code> objects.<\/li>\n -c getBlocks<\/code> \u2014 Fetch paginated block headers.<\/li>\n -c getTransactionDetails<\/code> \u2014 Fetch metadata for a transaction ID.<\/li>\n -c getDomainDetails<\/code> \u2014 Fetch metadata for a State Domain.<\/li>\n<\/ul>\nSection V-E. Advanced dApp Integration Patterns<\/h3>\nProfessional dApp development on GRIDNET OS leverages the seamless bridge between JavaScript (Control context) and GridScript (Consensus context). Patterns in VMContext.js<\/code> facilitate 'Transaction Chaining,' where multiple BT\/CT<\/code> sequences are formulated based on the results of previous ephemeral calls, all managed by the CVMContext<\/code> singleton for a seamless user experience.<\/p>\n 1. Automated Transaction Formulation<\/h4>\nModern dApps automate transaction creation using CVMContext<\/code>. The Magic Button<\/code> (\u27ea\u27ea\u27ea) mechanism provides the standard user confirmation flow, ensuring that even complex transaction sequences are presented clearly to the user for final approval.<\/p>\n \/\/ Programmatic transfer via CVMContext\nasync function commitPayment(to, amountGNC) {\n const vm = CVMContext.getInstance();\n const atto = CTools.getInstance().GNCToAtto(amountGNC);\n \n \/\/ Formulate the DPT\n let code = `BT\ntxconfig -setbid 100 -setlimit 50000\nsend ${to} ${atto}\nRT`;\n\n \/\/ Send to remote node. CVMContext handles Magic Button trigger.\n return await vm.processGridScriptA(code, vm.getSystemThreadID());\n}<\/pre>\n2. Identity Proxy Patterns<\/h4>\nUsing REG_AUTHENTICATED_SD<\/code> (12), a dApp can execute operations on behalf of a user. The VM ensures that REG_CALLERS_ID<\/code> (signer) remains the authoritative record of who originated the transaction.<\/p>\n 3. Transmission Token Security<\/h4>\nGridScript VM supports two levels for off-chain settlement via Transmission Tokens:<\/p>\n \nBearer Mode<\/strong>: Unsigned tokens. Used for faucets.<\/li>\n ECC-Locked Mode<\/strong>: Signed by the pool owner. The XTTEX<\/code> command verifies the signature against the pool owner's registered Identity Token<\/code>.<\/li>\n<\/ul>\nV-F. Memory Safety & Pointer Internal Logic<\/h2>\nGridScript enforces strict memory safety through internal registration. When alloc<\/code> or internal operators are called, the VM records the memory boundaries. If code attempts to access an invalid pointer or performs an out-of-bounds offset, the VM throws Prohibited memory access<\/code> and rolls back the transaction state immediately.<\/p>\n V-G. Metadata, Flagging, and Advanced Persistence<\/h2>\nGridScript extends traditional state persistence with a rich metadata layer. This allows developers to attach auxiliary information to state entries without polluting the primary data payload, facilitating a separation between content and categorization.<\/p>\n Metadata and Flags<\/h3>\n\nsetMeta<\/code> ( -- )<\/code> \u2014 Attach metadata to the current context (inline params: key value<\/code>)<\/li>\n setMetaEx<\/code> ( key value isHidden -- )<\/code> \u2014 Explicit metadata assignment with visibility control<\/li>\n flag<\/code> ( -- )<\/code> \u2014 Set a boolean flag on the current State Domain or object (inline params: name value<\/code>)<\/li>\n flagEx<\/code> ( flagName value -- )<\/code> \u2014 Explicit flag management<\/li>\n<\/ul>\nThis \"ghost state\" is critical for decentralized indexing and UI hints. For example, a file can be flagged as system-critical<\/code> or deprecated<\/code> without changing its binary content. Metadata is indexed by remote nodes, making it searchable via context -c searchBlockchain<\/code> without heavy trie traversal. In VMContext.js<\/code>, these flags are often used to trigger specific UI rendering modes or security warnings before a transaction is finalized by the user.<\/p>\n VI. Practical Examples \u2014 GridScript in Action<\/h2>\nExample 1: Full Smart Contract Lifecycle<\/h3>\nThis example demonstrates how to initialize state, deploy a contract, and invoke it.<\/p>\n \\ 1. Initialize State\nBT\ncd \/MyDomain\nsetvar 'counter' '0'\nCT\n\n\\ 2. Deploy Contract\nBT\ncd \/MyDomain\/contracts\nBC\ncd \/MyDomain\ngetVar 'counter' 1 +\n0 \"counter\" setVarEx\nEC\nCT\n\n\\ 3. Invoke Contract\nBT\ncall \/MyDomain\/contracts\nCT<\/pre>\nA Note on Value Transfer Safety<\/h3>\nAs of late 2025, the sendEx<\/code> codeword incorporates a mandatory Treasury Balance Check (enforcing network stability). Any attempt to transfer value that results in a sub-zero State Domain balance (accounting for pending sacrifices) will be rejected by the VM before consensus propagation, saving developer and user ERG.<\/p>\n Example 2: Payable Smart Contract<\/h3>\n\\ Inside smart contract code:\ngotGNC IF\n xvalue \\ Pushes BigInt amount\n 11 getReg \\ Caller address\n .\" Received payment from: \" .s\nELSE\n abort-message \"Payment required\"\nTHEN<\/pre>\nVII. GridScript in the JavaScript Ecosystem \u2014 The Browser Bridge<\/h2>\nEvery GRIDNET UI dApp running in the browser uses Shadow DOM<\/strong> for isolation. Your application logic lives in an ES6 class extending CWindow<\/code>. Interaction with the blockchain occurs through the CVMContext<\/code> singleton.<\/p>\n export default class HelloDApp extends CWindow {\n getPackageID() { return \"org.gridnetproject.UIdApps.Hello\"; }\n onReady() {\n const body = this.getBodyElement();\n body.innerHTML = \"<button id='btn'>Query<\/button>\";\n body.querySelector(\"#btn\").onclick = async () => {\n const bal = await this.vmContext.getBalanceA(\"MyAddr\");\n alert(\"Balance: \" + bal);\n };\n }\n}<\/pre>\nVIII. The ERG System \u2014 Real-time Metering<\/h2>\nComputation in GRIDNET OS is an economic event. Every instruction consumes ERG. The cost per RAM byte (ERG_COST_PER_RAM_BYTE<\/code>) is currently 1 ERG<\/strong>.<\/p>\n\n\n\n\n\n\n\nInstruction<\/th>\n Cost (ERG)<\/th>\n<\/tr>\n Pure Stack Ops (+, dup, drop)<\/td>\n 1<\/td>\n<\/tr>\n State Trie Write (setVarEx)<\/td>\n 1 + (data_size \/ 256)<\/td>\n<\/tr>\n Signature Verification (versig)<\/td>\n 80<\/td>\n<\/tr>\n ECC Key Generation (keygen)<\/td>\n 10<\/td>\n<\/tr>\n Memory Allocation (alloc)<\/td>\n 1 per byte<\/td>\n<\/tr>\n<\/table>\nIX. GridScript++ \u2014 The Extended Language<\/h2>\nGridScript++ brings JavaScript syntax to the blockchain VM using evalGPP<\/code>. It provides access to the system<\/code>, Assets<\/code>, Filesystem<\/code>, DAO<\/code>, and crypto<\/code> objects for high-level logic. GridScript V2 bytecode introduces a cryptographic Hash Chain<\/strong> for opcode integrity. Every V2 codeword is verified against a sequence of SHA256 hashes derived from keywords starting with the prefix GRIDSCRIPT_V2_KEYWORD_IMAGE<\/code>. This ensures that the execution engine and the bytecode remain synchronized with mathematical rigor, preventing mid-flight opcode redefinition or injection.<\/p>\n evalGPP \"\n var bal = system.assets.balance();\n if (bal > 1.0) {\n system.assets.sendGNCFloat('Recipient', 1.5);\n }\n\"<\/pre>\nXI. The Power of Reproducible, Verifiable Code<\/h2>\nEvery action in GRIDNET OS is a GridScript program. It is compiled to bit-identical V2 bytecode whether on a C++ node or a browser. This ensures that every developer action is reproducible, committable, and mathematically verifiable<\/strong>.<\/p>\n \nGridScript and GRIDNET OS are created by Rafa\u0142 Skowro\u0144ski. For more information, visit gridnet.org<\/a> or join the community at talk.gridnet.org<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Preface \u2014 The Language That Became an Operating System In 1970, Charles H. Moore created Forth \u2014 a programming language so minimal,…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[162,125,10,17],"tags":[139,145,150,211,147,144,142,143,148,146,210,149],"class_list":["post-835236","post","type-post","status-publish","format-standard","hentry","category-development","category-documentation","category-os-news","category-tutorial","tag-blockchain","tag-decentralized","tag-decentralized-processing-threads","tag-developer-tools","tag-dpt","tag-forth","tag-gridnet-os","tag-gridscript","tag-programming","tag-smart-contracts","tag-state-machine","tag-terminal"],"_links":{"self":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts\/835236","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/comments?post=835236"}],"version-history":[{"count":54,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts\/835236\/revisions"}],"predecessor-version":[{"id":849015,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts\/835236\/revisions\/849015"}],"wp:attachment":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/media?parent=835236"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/categories?post=835236"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/tags?post=835236"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

Control Flow \u2014 Conditionals, Loops, and Word Definitions<\/h3>\n
GridScript inherits Forth’s complete control flow vocabulary. All branching constructs compile to `(zbranch)<\/code> and (branch)<\/code> opcodes at compile time.<\/p>\n`

V. Command Reference \u2014 The GridScript Vocabulary<\/h3>\n
GridScript’s vocabulary encompasses 312 codewords. Each entry shows the command name, its stack effect notation `( before -- after )<\/code>, and its purpose.<\/p>\n`

2. Identity Proxy Patterns<\/h4>\n
Using `REG_AUTHENTICATED_SD<\/code> (12), a dApp can execute operations on behalf of a user. The VM ensures that REG_CALLERS_ID<\/code> (signer) remains the authoritative record of who originated the transaction.<\/p>\n`