Learn / Runtime Lab

Runtime Lab

Parallel / Concurrent / Composable

ALUX supports replayable long transactions: independent tasks run together and transactions coordinate through messages. The booking scenario illustrates the target model for settling related cross-system effects as one atomic result.

PositioningDecentralized concurrent runtime

ExecutionRun, interact, wait, settle

BoundaryCapability-scoped workflows

A premium technical illustration of the ALUX runtime connecting nodes, cloud services, devices, agents, capability tokens, and commit rails.

The simple difference

Three words, three very different runtime jobs

Parallel runs independent transactions at the same time. Concurrency lets transactions interact through channels: one transaction can wait for a matching message from another, then continue. Composability binds state transitions from different systems into one auditable atomic transition.

In the current ALUX runtime, independent work can run in parallel, transactions coordinate through messages, and execution can resume across blocks. Atomic composition across independent systems remains an architecture target.

Multiple isolated execution rails moving forward at the same time. — ParallelFour travel searches finish independently

Two transactions interact through a tuple-space channel: one waits for a matching message, the other sends it, and the waiting continuation resumes while unrelated work keeps moving. — ConcurrentThe booking waits; a hotel agent replies; the next step begins

A room reservation and payment authorization arrive from different systems. Only after both are ready does one booking confirmation leave the atomic boundary. — ComposableThe booking confirms only when reservation and payment both succeed

Parallel

Flight, hotel, transfer, and insurance
search at the same time

What it means: Parallel execution means independent jobs run at the same time. A travel agent can search flights, rooms, transfers, and insurance without making one search wait behind another.
How ALUX does it: Parallel execution is native to ALUX's process calculus: transactions share no memory, and any interaction is confined to tuple-space channels. Independent transactions therefore advance in separate TVM lanes, while Block Merge resolves state overlap at commit time.
What it enables: More independent work finishes in the same amount of time. But parallelism alone cannot make those jobs exchange messages or let a long transaction wait and continue.

Parallelism finds several answers at once. It does not make those jobs interact.

Concurrent

A booking waits for availability
and continues when the reply arrives

What it means: Concurrency begins when jobs interact. A booking can leave a waiting condition in a channel, and a hotel service can satisfy it later by sending the matching availability message.
How ALUX does it: The waiting consume is stored as a resource in tuple space. A produce from another transaction matches it, triggering a COMM event that spawns the continuation and moves the Execution Context from Inactive back to Running. If more than one match is possible, ReplayTrie records the chosen COMM for deterministic replay.
What it enables: A travel agent can keep one long transaction alive across blocks: it waits for room availability, an API response, or a user decision, then continues without blocking unrelated work.

Concurrency turns a reply into the next step: the match creates a new continuation instead of merely restarting a stopped lane.

Composable

The room and payment
confirm together

What it means: Composition is not ordinary bundling. The target in this example is to commit the room hold and payment authorization together, or commit neither one.
How ALUX does it: The current runtime provides tuple-space coordination, scoped OCAP references, cross-block continuation, ReplayTrie, and Block Merge. End-to-end atomic composition across independent external systems remains a design target built from those primitives.
What it enables: The intended result is to avoid a half-finished booking such as money charged without a room, or a room held without payment.

The target composition model gives different systems one all-or-nothing result; concurrency carries the messages that lead up to that shared commit.

Try the whole runtime

Model one atomic booking

Use four actions to explore the target composition model: start reservation and payment checks, leave a room-availability wait, deliver the hotel's matching message, then model a joint confirmation.

01Start both checks

Reservation and payment checks advance independently.

02Wait for a room

The reservation leaves an availability condition in the channel.

03Hotel replies

The matching message activates the booking continuation.

04Confirm together

Room hold and payment authorization commit as one result.

State 0 / 4

Play it in order

Start with step 1. Reservation and payment are managed separately inside the same runtime.

ParallelTwo checks run together

Independent work does not wait behind one global queue.

ConcurrentThe booking waits for the hotel

The dependency lives in a channel instead of blocking the runtime.

Message matchThe reply creates the next step

The COMM creates the continuation; ReplayTrie records the choice only when the match is non-deterministic.

ComposableRoom and payment confirm together

The target is one all-or-nothing result with reproducible settlement evidence.

Runtime path

What keeps a service alive

A long-running service stays coherent because every step can run, interact, carry explicit authority, replay deterministically, and settle along one verifiable atomic path.

Run

TVM process lifecycle

A process can fork, wait in one block, and resume in a later block without restarting its local execution context.

Interact

Tuple space + COMM

A waiting consume meets another transaction's produce. The match activates the continuation while unrelated work keeps moving.

Authorize

OCAP boundaries

Unforgeable capability references are passed explicitly, so each step receives only the authority it needs; identity does not automatically bring unrelated authority into scope.

Replay

ReplayTrie

Only the non-deterministic COMM choices that matter are recorded, so validators can reproduce the same execution.

Settle

BlockGit + Block Merge

Concurrent work enters verified fringes, where overlaps are classified as accepted, rejected, or undecided before finality.

Next layer

One logical runtime across many environments

Runtime Lab shows current parallel and message-driven execution, then illustrates the target atomic composition model. GLVM describes the broader architecture for extending that logical model across blockchain nodes, cloud services, and personal devices.

Explore GLVM

Why it matters

Not faster blocks. Long-running services.

Parallelism handles independent execution. Concurrency handles message-driven interaction and wait/resume. ALUX implements those runtime foundations today and is building toward atomic composition across system boundaries.

Only parallel

More throughput, but no transaction dependency or message matching.

Only concurrent

Transactions can interact and wait, but cross-system effects may still settle separately.

Only composable

An atomic boundary exists, but without interaction and waiting it cannot carry long-running dependencies.

Back to ALUX VS Others For AI Agents