Contact Us

Learn / GLVM

GLVM

Global Logical Virtual Machine

One logical execution layer, coordinated across many machines.

GLVM is the developer-facing execution abstraction ALUX is building from its concurrent runtime. A TVM provides the concrete engine on each participating machine; the GLVM model brings execution state, processes, replay, replication, and consensus into one logical layer.

Physical modelOne TVM per machine
Logical modelOne GLVM above them
DirectionChain to cloud to device

The core definition

One TVM per machine, coordinated through one logical execution model

TVM is the bytecode execution engine on one machine. GLVM defines the system-level execution abstraction across participating TVMs. It is not another bytecode VM; developers target one logical model while deterministic replay, execution continuity, replication, finalization, and consensus are coordinated beneath the abstraction.

TVM

Tuple-space Virtual Machine

The concrete ALUX execution engine. It runs Tolang bytecode, coordinates independent processes through channels and COMM events, and records the non-deterministic choices required for deterministic replay.

One concrete engine inside a machine
GLVM

Global Logical Virtual Machine

GLVM defines the developer-facing logical model across participating TVMs. It provides one boundary for execution state and processes while replay, replication, finalization, and consensus remain beneath the abstraction.

One logical system above many machines
VM abstractionExpanding
Vertical atomicityCore runtime
Horizontal atomicityRoadmap
Composable securityCore runtime

Three-layer architecture

Three layers, one developer-facing execution model

Physical machines run TVMs; in the GLVM architecture, those engines participate in one shared logical execution model. A future World OS will organize that layer into discoverable, orchestrated services governed by explicit capabilities.

Select any layer to update the detail panel.

Execution and atomicity

A transaction can wait across blocks, then settle as one

Execution evolves from sequential and parallel work to concurrent processes that communicate, wait, and resume. Composite execution extends the model so multiple concurrent transactions can share a higher-level settlement boundary; cross-block continuity provides the vertical foundation for that direction.

Core runtime

Concurrent

Processes communicate, wait, and resume through channels.

Vertical atomicity · core runtimeCross-block execution preserves one transaction context.
  1. 01 · Start Begin once

    Start one transaction with one scoped set of capabilities.

  2. 02 · Suspend Wait without partial settlement

    If an answer or channel match is missing, preserve the continuation instead of finalizing early.

  3. 03 · Record Capture the choice

    ReplayTrie records the non-deterministic choice or authenticated response required to reproduce the path.

  4. 04 · Resume Continue the same transaction

    A matching COMM event or recorded response wakes the preserved continuation in a later block.

  5. 05 · Finalize Commit or discard

    At the finalization boundary, eligible state is committed; rejected tentative state is discarded.

Core execution path

Concurrent TVM execution · COMM wait and resume · ReplayTrie · cross-block continuation and finalization

Atomicity model

Tentative intermediate state does not become confirmed state until finalization; a failed path is discarded instead of repaired later through compensating transactions.

Native off-chain read

An authenticated HTTPS GET can suspend, record the response, replay, and resume. The data source still determines truth, and irreversible off-chain side effects remain outside rollback.

Horizontal atomicity

Cross-shard atomic execution and composition with independent external systems define the next expansion of the model.

Object-capability security

Give the task one key—not the user’s badge

In the CEO–Bob example, identity-based access can carry the ambient authority represented by the CEO’s badge into the task. With object capabilities, the task receives only one key that names Bob’s record. The TVM enforces the reachable boundary at runtime. Without a capability reference to another pre-existing object, the task cannot name or reach it.

Broad identity authority

The badge carries unrelated access into the task

Even when the task concerns Bob alone, the identity authority represented by the CEO’s badge can still cover Financials and the records of Alice, Carol, and Bob.

Explicit object capability

The task receives one key that names Bob’s record

This key represents an unforgeable name that identifies Bob’s record. Without a capability reference to another pre-existing object, the task cannot name or reach it. The TVM checks that boundary at runtime.

Terminology

Here, “key” visually represents an OCAP unforgeable name—a capability reference. It is not a cryptographic key. This guarantee applies to TVM-native, capability-mediated interactions; hosted EVM permissions and external services need their own controls.

Workflow explorer

Choose the execution surface by trust, response time, and data locality

Consider a cross-company device repair: escrow needs independent verification, diagnostics need elastic compute, and the device owner should approve local access. In the GLVM model, each task maps to the execution surface that matches its trust, latency, and data boundary while authority remains explicit.

Choose a requirement
Core runtime

Public-chain TVM + EVM host

Hold the warranty escrow and record its approval path where independent validators can verify the transition.

Follow the target flow0 / 6

Ready. Start the simulation to see the target logical flow.

01

Scoped capability

The repair agent receives only the rights required for this job.

02

Plan the dispatch

The workflow maps bounded subtasks to chain, private or cloud, and client-device TVMs.

03

Wait / suspend

On the chain runtime, a missing reply preserves the continuation instead of finalizing the transaction early.

04

COMM match

A produced result meets the waiting continuation on a channel; the workflow resumes.

05

Replay proof

ReplayTrie records the choices needed for another validator to reproduce the run.

06

Finalization boundary

BlockGit and Block Merge converge verifiable chain-side results. Extending one atomic commit across every execution surface is the GLVM horizon.

Runtime anatomy

Nine capability areas behind the GLVM abstraction

GLVM is not a second bytecode VM. These nine architecture views—from TVM execution, object capabilities, and replay to BlockGit, guest VMs, and developer tooling—show the capability system behind its logical execution model.

  1. 01
    Bytecode VMCore runtime

    TVM · tuple space · COMM

    The concrete concurrent engine runs bytecode and lets independent processes exchange data and continuations through channels.

  2. 02
    SecurityCore runtime

    Native object capabilities

    Unforgeable references make reachable authority explicit and let the runtime enforce least-authority boundaries.

  3. 03
    AtomicityCore runtime

    Cross-block atomic execution

    Execution contexts can suspend across blocks, resume from preserved continuations, and reach a deferred finalization boundary.

  4. 04
    FinalityCore runtime

    BlockGit · fringe · merge

    A block DAG, deterministic leader rotation, and merge rules converge concurrent chain-side work without a permanent leader.

  5. 05
    ReplayCore runtime

    ReplayTrie · trace

    Recorded non-deterministic choices and execution traces let validators reproduce the accepted path.

  6. 06
    NetworkCore runtime

    Peer and validator network

    The node layer carries proposals, blocks, state evidence, and validator coordination beneath the execution abstraction.

  7. 07
    LanguageCore runtime

    Tolang → tolangc → .tox

    Tolang describes concurrent processes; the compiler lowers source into TVM-executable bytecode.

  8. 08
    Guest VMsEVM core · WASM roadmap

    EVM host · WASM roadmap

    The EVM runs as a stateful guest through TSAC-style coordination. WASM extends the heterogeneous-VM direction.

  9. 09
    ToolingDeveloper surface

    Compiler · LSP · playground

    The compiler, LSP, playground, test suite, and diagnostics bring the execution model into developer workflows.

Build horizon

The core runtime is taking shape as GLVM expands across environments

GLVM grows outward from ALUX’s concurrent chain runtime. Private cloud is the next integration surface; client-device and cross-shard execution remain on the roadmap. The map below separates the core runtime, the surfaces now being extended, and the next architectural horizon.

Core runtime

  • Concurrent TVM and COMM
  • ReplayTrie and execution traces
  • Cross-block suspend / resume paths
  • Native OCAP foundations
  • EVM host path
  • BlockGit DAG, fringe, and merge

Expanding the system

  • Private or cloud engine deployment
  • GLVM abstraction across deployment surfaces
  • Production-scale hardening
  • Richer policy and guarded-channel controls
  • Runtime observability and operator tooling

Roadmap

  • Cross-shard horizontal atomicity
  • WASM guest VM
  • Client-device TVM deployment
  • Account abstraction and capability registry
  • Peer resynchronization after failure and dynamic validator-set changes
  • Programmable World OS layer

Continue learning

Explore the runtime, agent workloads, and system comparisons

Runtime Lab explains the execution model. For AI Agents shows the workload pattern. ALUX VS Others compares architecture and capabilities across systems.