在上一篇文章中，我们介绍了新推出的 Polkadot/Kusama 平行链——Gear，它拥有最先进的智能合约引擎，还介绍了 Gear 的使命、主要功能和团队成员。
现在，让我们深入了解 GEAR 突破性技术的关键优势。
摘要
Gear 关键的技术创新在于其新颖的跨合约通信方式。Gear 使用 Actor 通信模型和 WebAssembly VM，支持并行处理，并具有速度快、成本低的优势。
事实证明， WebAssembly VM 比任何其他方案运行速度都要快。使用 WebAssembly 可以让 GEAR 的智能合约直接编译成机器码，运行速度媲美原生。更快的速度意味着更低的交易成本和更高的效率。
背景
我们可以看一看基本原理和组成部件，通过了解背景知识，更好地了解 Gear 的技术。
同其他区块链系统一样，Gear 也维护分布式状态。运行时代码将被编译成 WebAssembly 并成为区块链存储状态的一部分。
存储状态包括以下部分：
- 程序和内存（包括程序代码和私有内存）
- 消息队列（网络的全局消息队列）
- 账户（网络账户及其余额）
程序和内存
程序代码存储为不可变的 Wasm blob，每个程序都有固定数量的独立内存，这些内存在程序初始化时被预留，并在消息处理期间保持不变（所谓的静态区）。程序只能在自己的内存空间内读写，不能访问其他程序的内存空间。
程序可以从 Gear 实例提供的内存池中分配到更多内存。程序以 64KB 为单位分配自身所需的内存。每个分配的内存块分散存储在分布式数据库后端，但在运行时中，Gear 节点构造连续的运行时内存，并允许程序在其上运行而无需重载。
消息队列
Gear 实例持有一个全局消息队列。使用 Gear 节点，用户可以向特定程序发送包含一条或多条消息的交易。这些消息将填充消息队列。在区块构造过程中，消息将被移出队列并被路由到特定程序。
账户
对于公共网络，防御 DoS 攻击常常在交易处理时支付 gas/fee。Gear 提供了一个 Balance 模块，允许存储用户和程序余额，并支付交易费用。
常规余额转移是在 Substrate 的 Balances 模块中进行的。余额在用户、程序和验证者帐户之间转移。
除了常规余额转移外，Gear 网络还定义了 gas balance 转移，用于奖励验证者节点的工作，并保护网络免受 DoS 攻击。
状态转换
每个系统都遵循系统状态演化所依据的规则。当网络处理新的输入数据时，状态将根据状态转移规则前进。这些输入数据被打包在称为交易的原子粒度的信息中。
Gear 节点维护并同步包含所有新交易的交易池。当任何节点（验证者节点或者不是）接收到交易时，该节点将交易传播到所有连接的节点。
当 Gear 验证节点生成新块时，池中的一些（或所有）交易将合并到一个块中，网络将通过该块进行状态转换。上一个区块中未打包的交易将留在池中，直到生成下一个区块。
Gear 支持以下交易类型：
- 创建程序（用户上传新程序——智能合约）
- 发送消息（程序填充消息队列）
- 退出消息队列（验证者（或块生产者）退出多条消息，运行相关程序）
- 余额转移（Gear 引擎执行用户——程序——验证者余额交易）
Actor 通信模型
并发系统的主要挑战之一是并发控制。它定义了不同程序之间正确的通信顺序，并协调共享资源的访问。潜在问题包括竞争条件、死锁和资源匮乏。
并发计算系统可分为两类通信模式：
共享内存通信——并发程序通过更改共享内存位置的内容进行通信。
消息传递通信——通过消息交换进行并发程序通信。消息传递并发比共享内存并发更容易理解。它通常被认为是一种更稳健的并发编程形式。
通常，消息传递并发比共享内存具有更好的性能。在消息传递系统中，每个进程的内存开销和任务切换开销更低。
有很多数学理论可以用来理解消息传递系统，包括 Actor 模型。
对于进程间通信，Gear 使用 Actor 模型。Actor 模型越来越流行，通常作为先进的语言概念，现在许多新的编程语言都在使用它。Actor 模型的原理是程序从不共享任何状态，只是在彼此之间交换信息。
虽然在一个通常的 Actor 模型中，消息顺序没有任何保证，但 Gear 额外保证了两个特定程序之间的消息顺序保持不变。
使用 Actor 模型可以使我们在程序（智能合约）逻辑中实现基于 Actor 的并发性。这样我们就可以利用各种语言结构进行异步编程（例如，Rust 中的 Futures 和 async/await）。
与类不同，actor 一次只允许一个任务访问其可变状态，这使得多个任务中的代码可以安全地与同一个 actor 实例交互。
异步函数大大简化并发管理，但它们无法处理死锁或状态损坏的情况。为了避免死锁或状态损坏，异步函数应该避免调用可能阻塞其线程的函数。为了实现这一点，我们选择使用 await 表达式。
目前，典型的智能合约代码中缺乏对 async/await 模式的支持，这给智能合约开发人员造成了很多问题。实际上，通过添加手工函数（在 Solidity 智能合约中），在智能合约程序流中实现更好的控制是可能的。但是合约中许多函数的问题在于，人们很容易混淆，应该在合约生命周期中的哪个阶段调用哪个函数。
Gear 为程序提供通用的 async/await 语法。这大大简化开发和测试过程，降低智能合约开发中出错的可能性。如果程序逻辑需要，Gear API 还支持同步消息。
内存并行性
每个程序的独立内存空间允许在 Gear 节点上进行并行化消息处理。并行处理流的数量等于 CPU 内核数。每个流将处理用于一组已定义程序的消息。它与从其他程序或外部（用户交易）发送的消息有关。
Gear 引擎使用运行时定义的流的数量，这个数量等于验证者机器上的 CPU 内核数，将目标程序的总量除以流数，并为每个流创建一个消息池。
程序被分配到独立的流中，每条消息都出现在其目标程序的流中。因此，发往特定程序的所有消息都会出现在一个处理流中。
在每个周期中，一个目标程序可以有多条消息，一个流将处理许多程序的消息。消息处理后，每个流的一组新消息将被添加到消息队列中，然后循环重复。消息处理过程中，生成的结果消息通常被发送到另一个地址（返回到原点或下一个程序）。
WebAssembly VM
Gear 在底层使用 WebAssembly（简称 Wasm ）。任何 Gear 程序都采用 WebAssembly 格式。WebAssembly 是用于部署程序的代码格式。在 Gear 上下文中，任何智能合约都是一个 WebAssembly 程序。
WebAssembly 具有以下优点：
- 卓越的原生速度。因为它将程序代码转换为实际的硬件指令。更高的速度意味着更高的效率和更低的交易成本。
- 便携性。它可以在任何硬件上运行。
- 安全性。经过正确验证的 WebAssembly 程序不能离开沙箱(由规范保证)。
WebAssembly 能够成为一项引人注目的全球性行业技术有以下原因：
- 由该领域的所有主要竞争者合作设计和实施
- 设计和发布采用完整的数学和机器形式验证
请及时关注 Gear 的 github，了解最新资讯！
关于 GearFans
Gear 是波卡生态的计算组件，GearFans 是 Gear 爱好者社区。
- 官网：https://gear-tech.io/
- Twitter：https://twitter.com/gear_techs
- GitHub：https://github.com/gear-tech
- Discord：https://discord.com/invite/7B...
- Medium：https://medium.com/@gear_techs
- Telegram 群：https://t.me/gear_tech
- Telegram 中文群：https://t.me/Gear_CN
- Telegram 中文开发群：https://t.me/gear_dev_cn