在上一篇文章中，咱们介绍了新推出的 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