Gear Protocol 的另一个突出特点是持久性内存方法。它使开发更容易，消除了很多复杂性，并使协议内存管理与实际硬件和操作系统相匹配。

在 Gear 网络中运行的程序不使用存储，而是将全部状态持久化，这确保了区块链上下文的 API 面要小得多。它避免了特定领域的语言特征，也允许使用更复杂的语言结构--持久化的闭包、合成器等。

Gear Protocol 使用了巧妙的内存虚拟化技术 (尽管普通的 Wasm 没有)，内存分配和回收是该协议的第一等系统调用，还会跟踪内存访问，只加载/存储所需的内存页。这使得存储在区块链状态中的智能合约的堆栈框架（通常在期货及其合成器中发现）能够被无缝持久化，并在需要时被调用，在请求时保留其状态。

程序代码存储为一个不可变的 Wasm blob。每个程序都有固定数量的内存，在消息处理之间存在 (所谓的静态区域)。

Gear 实例持有每个程序的单独内存空间，并保证持久性。一个程序只能在它自己的内存空间内进行读写，不能访问其他程序的内存空间。单独的内存空间在程序初始化期间为其保留，不需要额外的费用（它包含在程序的初始化的费用中）。

程序可以按 64KB 的块分配所需的内存量。每个内存块分配都需要 gas 费。每个页面 (64KB) 单独存储在分布式数据库后端，但在运行时，Gear 节点构造连续运行时内存，并允许程序在其上运行而无需重新加载。

内存并行

每个程序单独的独立内存空间允许 Gear 节点上的消息处理并行化。并行处理流的数量等于 CPU 核数。每个流处理用于一组已定义程序的消息。它涉及从其他程序或外部发送的消息 (用户事务)。

例如，给定一个消息队列，其中包含针对 100 个不同程序的消息，Gear 节点运行在一个配置了 2 个处理线程的网络上。Gear 引擎使用运行时定义的流数量 (等于一个典型的验证机上的 CPU 核的数量)，将目标程序的总数除以流的数量，并为每个流创建一个消息池 (每个流 50 个程序)。

程序被分发到不同的流中，每个消息出现在定义了目标程序的流中。因此，所有发给特定程序的消息都出现在一个处理流中。

在每个周期中，目标程序可以有多个消息，一个流处理大量程序的消息。消息处理的结果是来自每个流的一组新消息被添加到消息队列中，然后循环往复。在消息处理过程中生成的结果消息通常被发送到另一个地址 (返回原点或下一个程序)。