在上一篇文章中，我們介紹了新推出的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 支持以下交易類型：

  1. 創建程序（用戶上傳新程序——智能合約）
  2. 發送消息（程序填充消息隊列）
  3. 退出消息隊列（驗證者（或塊生產者）退出多條消息，運行相關程序）
  4. 餘額轉移（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 ，了解最新資訊！