了解 / Runtime Lab
Runtime Lab
并行、并发、组合
ALUX 支持可重放的长交易：独立任务可以同时推进，交易则通过消息协作。预订场景演示的是目标模型——让相关的跨系统状态变化作为一个原子结果结算。
ALUX 运行时连接节点、云服务、个人设备、智能体、能力令牌和提交轨道的高级技术插画。
先分清三件事
三个词很像，
但它们解决的问题不同
并行让互不依赖的交易同时执行。并发让交易通过通道交互：一笔交易可以等待另一笔交易发来匹配消息，再继续执行。组合把不同执行系统中的状态转移放进同一个结算边界，使它们作为一次可审计的原子状态转移完成结算。
在当前 ALUX 运行时中，独立任务可以并行推进，交易通过消息协作，执行也能跨区块恢复。独立系统之间的原子组合仍属于架构目标。
多条相互隔离的执行轨道同时向前推进。
同样时间里能完成更多独立工作，但单靠并行，既不能让这些工作交换消息，也不能让一笔长交易等待后继续。
并行可以同时得到多项结果，但不会让这些任务彼此交互。
并行
航班、酒店、接送和保险
同时查询
- 它是什么意思
- 并行指多项互不依赖的工作同时执行。旅行智能体可以同时查询航班、房间、接送和保险，不必让一项查询排在另一项后面。
- ALUX 如何做到
- 并行执行是 ALUX 进程演算的原生能力：交易不共享内存，任何交互都只能通过元组空间通道发生。互不依赖的交易因此可以在不同 TVM 执行轨道上推进，提交时若出现状态重叠，再由 Block Merge 裁决。
- 它能做什么
- 同样时间里能完成更多独立工作，但单靠并行，既不能让这些工作交换消息，也不能让一笔长交易等待后继续。
并行可以同时得到多项结果，但不会让这些任务彼此交互。
体验完整运行时
模拟一次原子预订
按四个步骤探索目标组合模型：启动预订与付款检查，留下房态等待条件，传入酒店的匹配消息，最后模拟两边共同确认。
预订和支付检查各自推进。
预订在通道中留下房态条件。
匹配消息唤醒预订的后续执行。
房间锁定与付款授权作为一个结果提交。
按顺序操作
从第 1 步开始：预订和支付由同一个运行时管理，但状态彼此独立。
独立工作不必排在同一条全局队列里。
依赖关系留在通道中，不会阻塞整个运行时。
COMM 生成后续执行；只有匹配存在非确定性时，ReplayTrie 才记录这次选择。
目标是得到全有或全无的结果，并保留可复现的结算证据。
运行路径
是什么让一项服务持续运行
长时间运行的服务之所以保持一致，是因为每一步都能执行、交互、携带显式权限、进行确定性重放，并沿一条可验证的原子路径完成结算。
TVM 进程生命周期
进程可以分叉，在一个区块中等待，并在后续区块恢复，而不必重新启动本地执行上下文。
元组空间 + COMM
等待中的取用（Consume）与另一笔交易的写入（Produce）相匹配；匹配会唤醒后续执行，而无关工作继续推进。
OCAP 权限边界
不可伪造的能力引用被显式传递，让每一步只获得所需权限；身份不会自动把无关权限带入当前环境。
ReplayTrie
只记录真正影响结果的非确定性 COMM 选择，使验证者能够复现同一段执行。
BlockGit + Block Merge
并发工作进入经过验证的 Fringe；相互重叠的结果会在最终确认前被判定为接受、拒绝或待定。
下一层
同一个逻辑运行时，连接不同执行环境
Runtime Lab 展示当前的并行执行与消息驱动并发，并说明目标中的原子组合模型。GLVM 则描述更广泛的架构：如何将这套逻辑模型扩展到区块链节点、云服务和个人设备。
为什么重要
不是更快的区块，而是持续运行的服务
并行负责推进彼此独立的任务，并发负责消息驱动的交互以及等待与恢复。ALUX 当前已实现这些运行时基础，并正在面向跨系统原子组合继续建设。
吞吐更高，但没有交易依赖与消息匹配。
交易可以交互和等待，但跨系统结果仍可能分别结算。
存在原子边界，但没有交互与等待，就承载不了持续运行的依赖关系。