[EN/CN] SSRI Executor on WASM: Implementing SSRI Protocol in Browsers - 在浏览器中实现SSRI协议

English CKB Development & Technical Discussion
1

SSRI Executor on WASM：在浏览器中实现 SSRI 协议

引言

SSRI (Script-Sourced Rich Information)协议是 CKB 生态系统中的一项重要创新，旨在扩展智能合约的表达能力，提升开发体验。本文将详细介绍我们为什么需要将 SSRI 执行环境实现为 WASM 版本，实现过程中遇到的挑战，以及这一技术突破对 CKB 开发生态的深远影响。

1. SSRI 协议的背景与目的

phroi

Dec 2024

This tech is a game changer, I really appreciate the direction where this is going. I can’t wait to see the audit of Pausable UDT completed and the revolution that it’ll brings, especially when coupled with Fiber!

Phroi

1.1 当前 CKB Script 的局限性

在 CKB 生态系统中，Script 主要作为验证器(Verifier)使用，仅允许满足特定规则的交易通过，以控制 Cell 的状态转移。这种模式下，Script 本身几乎不对外暴露任何逻辑，Script 的更多信息只能在链下或通过链上弱绑定的方式约定。

随着 CKB 应用的增多，这种模式逐渐显露出局限性：

  • UDT 类资产难以有效声明代币信息
  • NFT 类资产缺乏统一的数据结构定义方式
  • 不同语言需要重复实现交易组装逻辑
  • 开发者需要投入大量精力理解 Script 的内部要求

这些问题本质上都是互操作性和开发体验的挑战，亟需一种标准化的解决方案。

1.2 SSRI 协议的诞生

SSRI 协议正是为解决上述问题而设计的。它扩展了 Script 的能力，使其不仅能在链上验证交易，还能在链下执行并返回结果，允许开发者将任意信息和逻辑嵌入到 Script 中，向链下应用描述自己的行为和管理的数据。

SSRI 协议由两个核心部分组成：

  1. 链上行为标准：类似于编程语言中的接口或特性(trait)，SSRI 定义了一套 Script 的行为标准，将行为抽象为一系列方法约束。满足约束的 Script 被认为具有特定行为，调用方可通过指定方法与 Script 交互。

  2. 链下执行标准：定义了 Script 在链下执行的规范，使 Script 能通过特定 syscall 获取更多链上信息。这一部分是本文重点讨论的内容。

通过 SSRI 协议，Script 能够实现：

  • 统一业务逻辑：将业务数据计算与验证整合到链上 Script 中
  • 丰富接口能力：提供多样化的查询和执行接口
  • 标准化交互：通过统一的方法调用方式与合约交互
  • 链式交易支持：简化复杂交易的构建流程

2. SSRI 的组成与当前实现

2.1 SSRI 的两个核心组件

SSRI 协议的完整实现依赖两个主要组件：

  1. 链上验证逻辑：在 CKB 链上执行的 Script 代码，负责验证交易是否合规
  2. 链下执行环境：即 SSRI Executor，负责在链下执行 Script 中定义的 SSRI 方法，获取结果

本文主要关注第二个组件——SSRI Executor 的 WASM 实现。

2.2 初始实现方式及其局限

在 SSRI 协议的初始实现中，我们通过以下组件支持了完整的功能：

  • ckb-ssri-std：提供在合约中编写 SSRI 接口的标准库
  • ssri-server：提供独立的 SSRI-VM 服务
  • ccc：提供与支持 SSRI 的合约交互的前端接口

然而，这种实现方式存在显著的限制：开发者需要部署和维护独立的 SSRI-VM 服务器。这不仅增加了基础设施成本，还提高了使用门槛，不利于 SSRI 协议的广泛采用。

3. 为什么选择 WASM 实现 SSRI Executor

面对上述问题，我们需要一个能够在用户浏览器中直接运行的 SSRI 执行环境，而 WebAssembly(WASM)技术正是理想的解决方案。

3.1 WASM 的优势

WebAssembly 是一种可在现代浏览器中运行的二进制指令格式，具有以下关键优势：

  1. 高性能：接近原生代码的执行效率，能够胜任复杂的 SSRI 方法执行
  2. 跨平台：一次编译，可在任何支持 WASM 的环境中运行
  3. 安全沙箱：提供隔离的执行环境，保障用户浏览器安全
  4. 与 Web 生态集成：可与 JavaScript 无缝交互，便于与现有 dApp 集成

3.2 WASM 相比纯 JavaScript 的优势

虽然我们也可以考虑使用纯 JavaScript 实现 SSRI Executor，但 WASM 具有以下独特优势：

  1. 复用现有代码：SSRI-VM 的核心逻辑已用 Rust 实现，通过 WASM 可以直接复用这些代码，避免从零重写
  2. 性能优势：对于 SSRI 方法的执行，尤其是涉及密码学计算时，WASM 提供更高的性能
  3. 类型安全：保持与 Rust 版本相同的类型系统和安全保证
  4. 一致性：确保与服务器版本 SSRI-VM 的行为完全一致，避免不同实现间的差异

通过 WASM，我们能够将原本需要在服务器端运行的 SSRI 执行环境直接引入浏览器，实现真正的客户端计算，降低对服务器的依赖，提升应用的响应速度和可靠性。

4. WASM 实现过程中的挑战与解决方案

4.1 初步评估与挑战

为了实现 MVP（最小可行产品）版本，我们面临四个主要技术挑战：

  1. 环境兼容性问题：原本 SSRI-VM 依赖于Asm Machine，但该组件在 WASM 环境中无法直接使用
  2. 同步与异步冲突：SSRI-VM 执行 Script 需要Context为Sync和Send，但向链上请求状态又需要异步操作
  3. 通信机制受限：原实现依赖channel进行通信，而 channel 在target=web的 WASM 环境中不可用
  4. CCC 接口兼容性：我们希望使用 CCC 获取链上状态，但 CCC 仅提供异步接口

4.2 MVP 版本实现

在 MVP 版本中，我们实现了第一阶段的突破：

  1. 执行引擎替换：将AsmMachine替换成DefaultMachine，并以与原本独立运行时类似的方式注入自定义 syscall
  2. Web Worker 解决方案：使用 Web Worker 执行 SSRI Executor 的实际业务逻辑，利用 XHR 允许在 Web Worker 中以同步模式发起网络请求
  3. 模块封装：将 SSRI Executor 的逻辑包装成易于使用的 TypeScript Package 并与 CCC 深度适配

然而，这个版本依然存在限制：

  1. 依赖 SharedArrayBuffer：需要网站实施Cross-Origin Isolation策略，这会导致许多需要弹窗通信的服务（如钱包连接）失效
  2. CCC 功能受限：无法充分利用 CCC 的缓存等高级特性

4.3 突破性解决方案

经过进一步研究和实验，我们最终实现了更优的解决方案：

  1. 通信机制革新：移除对 SharedArrayBuffer 的依赖，使用BroadcastChannel实现多个 Worker 及 WASM 模块间的自由通信
  2. RPC Worker 分离：添加专门的 RPC Worker 处理 CCC 的链上状态请求，使用BroadcastChannel监听请求和返回数据
  3. 迭代执行模式：采用迭代执行范式，使 Script 能够在请求链上数据时暂停执行，待数据获取后再恢复执行

这种方案成功实现了 SSRI 协议定义的所有链下syscall，包括：

  • find_out_point_by_type - 以 Type Script 在链上搜索 Live cell
  • find_cell_by_out_point - 以 OutPoint 在链上搜索 Live cell 并返回 CellOutput
  • find_cell_data_by_out_point - 以 OutPoint 在链上搜索 Live cell 并返回 CellData

5. 最终成果与意义

5.1 SSRI Executor on WASM 的实现成果

通过 WASM 实现，我们成功将 SSRI Executor 从独立服务转移到浏览器环境，实现了以下目标：

  1. 零依赖部署：开发者不再需要部署独立的 SSRI-VM 服务
  2. 无 Cross-Origin 限制：移除了对 Cross-Origin Isolation 的依赖，兼容各类 Web 服务
  3. CCC 深度集成：可直接使用 CCC 的全部功能，包括状态缓存
  4. 一致的执行环境：确保与服务器版本相同的执行结果

5.2 对 CKB 开发范式的革新

SSRI 协议结合 WASM 执行环境，正在深刻改变 CKB 智能合约的开发方式：

  • 开发思维转变：Script 从"被动验证"转向"主动指导"，更接近传统智能合约的直观理解
  • 降低开发门槛：dApp 开发者可以专注于业务需求，而非复杂的交易构建细节
  • 统一的交互标准：所有支持 SSRI 的合约都可通过一致的方式交互，提高代码复用性
  • 客户端自主计算：用户可以在浏览器中完成大部分交互计算，减少对中心化服务的依赖

5.3 未来展望

当前的 WASM 实现仍有改进空间：迭代执行方式不可避免带来一定性能开销，对于复杂的 SSRI 方法可能产生性能瓶颈。随着 WASI 标准的发展和浏览器 WASM 能力的增强，未来我们有望实现更高效的执行模式。

尽管如此，现有的 SSRI Executor on WASM 已足够支持大多数应用场景，为 CKB 生态带来革命性的开发体验提升。

总结

SSRI Executor on WASM 的实现是 CKB 智能合约开发的重要里程碑。通过将 SSRI 执行环境带入浏览器，我们不仅解决了部署和维护的技术难题，更为重要的是，我们开创了一种新的智能合约交互范式，使 CKB 的 UTXO 模型在不牺牲安全性的前提下，获得了更强的表达能力和更优的开发体验。

这一技术突破将推动 CKB 智能合约生态走向更加成熟和繁荣的未来，让开发者能够更轻松地构建复杂应用，最终实现"Game Changer"级别的开发体验提升。


SSRI Executor on WASM: Implementing SSRI Protocol in Browsers

Introduction

The SSRI (Script-Sourced Rich Information) protocol is a significant innovation in the CKB ecosystem, designed to extend smart contract expressiveness and improve the development experience. This article explains why we needed to implement the SSRI execution environment as a WASM version, the challenges encountered during implementation, and the profound impact of this technology breakthrough on the CKB development ecosystem.

1. Background and Purpose of the SSRI Protocol

phroi

Dec 2024

This tech is a game changer, I really appreciate the direction where this is going. I can’t wait to see the audit of Pausable UDT completed and the revolution that it’ll brings, especially when coupled with Fiber!

Phroi

1.1 Limitations of Current CKB Scripts

In the CKB ecosystem, Scripts primarily function as verifiers, only allowing transactions that meet specific rules to control Cell state transitions. In this model, Scripts barely expose any logic externally, with most Script information existing only off-chain or through loosely-bound on-chain conventions.

As CKB applications increase, this model has revealed limitations:

  • UDT assets struggle to effectively declare token information
  • NFT assets lack unified data structure definition methods
  • Different languages require repetitive implementation of transaction assembly logic
  • Developers must invest significant effort to understand internal Script requirements

These issues are fundamentally challenges of interoperability and development experience, requiring a standardised solution.

1.2 The Creation of the SSRI Protocol

The SSRI protocol was designed to address these problems by extending Script capabilities, allowing them to execute and return results off-chain while enabling developers to embed arbitrary information and logic into Scripts that describe their behaviour and managed data to off-chain applications.

The SSRI protocol consists of two core components:

  1. On-chain behaviour standards: Similar to programming language interfaces or traits, SSRI defines a set of Script behaviour standards that abstract behaviours into a series of method constraints.
  2. Off-chain execution standards: Defines how Scripts execute off-chain, allowing them to access more on-chain information through specific syscalls.

Through the SSRI protocol, Scripts can achieve:

  • Unified business logic: Integrating logics for calculations and validations into the on-chain Script.
  • Rich interface capabilities: Provide both interfaces for query and execution.
  • Standardised interactions: Unified pattern to call methods and interact with scripts.
  • Support for chained transactions: Simplify constructions of complicated transactions.

2. SSRI Components and Current Implementation

2.1 Two Core SSRI Components

The complete SSRI protocol implementation relies on two main components:

  1. On-chain verification logic: Script code executed on the CKB chain, responsible for verifying transaction compliance
  2. Off-chain execution environment: The SSRI Executor, responsible for executing SSRI methods defined in Scripts off-chain

This article focuses on the second component—the WASM implementation of the SSRI Executor.

2.2 Initial Implementation and Limitations

The initial SSRI protocol implementation supported complete functionality through:

  • ckb-ssri-std: Standard library for writing SSRI interfaces in contracts
  • ssri-server: Standalone SSRI-VM service
  • ccc: Frontend interface for interacting with SSRI-supporting contracts

However, this implementation had significant limitations: developers needed to deploy and maintain separate SSRI-VM servers, increasing infrastructure costs and usage barriers.

3. Why Choose WASM for SSRI Executor Implementation

To address these issues, we needed an SSRI execution environment that could run directly in users’ browsers, making WebAssembly (WASM) the ideal solution.

3.1 Advantages of WASM

WebAssembly offers key advantages:

  1. High performance: Near-native execution efficiency
  2. Cross-platform capability: Run in any WASM-supporting environment
  3. Secure sandbox: Isolated execution environment
  4. Web ecosystem integration: Seamless JavaScript interaction

3.2 WASM Advantages Over Pure JavaScript

WASM provides unique benefits compared to pure JavaScript:

  1. Code reuse: Leverage existing Rust implementation
  2. Performance: Superior for cryptographic calculations
  3. Type safety: Maintain the same type system and security guarantees
  4. Consistency: Ensure identical behavior with server-side SSRI-VM

With WASM, we could bring the SSRI execution environment directly into browsers, enabling true client-side computation.

4. Challenges and Solutions in WASM Implementation

4.1 Initial Assessment and Challenges

For our MVP, we faced four technical challenges:

  1. Environment compatibility: SSRI-VM’s dependence on Asm Machine wasn’t directly usable in WASM
  2. Synchronous/asynchronous conflicts: SSRI-VM required Sync and Send context while on-chain state requests needed asynchronous operations
  3. Communication limitations: Original implementation relied on channel, unavailable in WASM with target=web
  4. CCC interface compatibility: CCC only provided asynchronous interfaces

4.2 MVP Implementation

In our MVP, we achieved initial breakthroughs:

  1. Execution engine replacement: Replaced AsmMachine with DefaultMachine
  2. Web Worker solution: Used Web Workers with XHR for synchronous network requests
  3. Module encapsulation: Packaged SSRI Executor logic as a TypeScript module with CCC integration

However, limitations remained:

  1. SharedArrayBuffer dependency: Required Cross-Origin Isolation, breaking many popup-based services
  2. Limited CCC functionality: Couldn’t fully utilize CCC’s advanced features

4.3 Breakthrough Solution

After further research, we implemented a superior solution:

  1. Communication mechanism innovation: Removed SharedArrayBuffer dependency, using BroadcastChannel for communication
  2. RPC Worker separation: Added dedicated RPC Workers for CCC on-chain state requests
  3. Iterative execution model: Enabled Scripts to pause execution while requesting on-chain data

This solution successfully implemented all SSRI protocol off-chain syscalls, including:

  • find_out_point_by_type
  • find_cell_by_out_point
  • find_cell_data_by_out_point

5. Final Results and Significance

5.1 SSRI Executor on WASM Implementation Results

Our WASM implementation successfully transitioned SSRI Executor from a standalone service to browsers, achieving:

  1. Zero-dependency deployment: No separate SSRI-VM service required
  2. No Cross-Origin restrictions: Compatible with various Web services
  3. Deep CCC integration: Full access to CCC features including state caching
  4. Consistent execution environment: Same results as server versions

5.2 Revolution in CKB Development Paradigm

The SSRI protocol with WASM execution environment is profoundly changing CKB smart contract development:

  • Development mindset shift: From “passive verification” to “active guidance”
  • Lower development barriers: Focus on business requirements rather than transaction details
  • Unified interaction standards: Consistent interaction with all SSRI-supporting contracts
  • Client-side computation: Reduced dependency on centralised services

5.3 Future Outlook

The current WASM implementation has room for improvement: iterative execution inevitably introduces performance overhead. As WASI standards evolve and browser WASM capabilities strengthen, more efficient execution models may emerge.

Nevertheless, the existing SSRI Executor on WASM already supports most application scenarios, bringing revolutionary development experience improvements to the CKB ecosystem.

Conclusion

The SSRI Executor on WASM implementation represents a significant milestone for CKB smart contract development. By bringing the SSRI execution environment into browsers, we’ve not only solved technical deployment challenges but also created a new smart contract interaction paradigm, giving CKB’s UTXO model stronger expressiveness and better development experience without compromising security.

This technological breakthrough will drive the CKB smart contract ecosystem toward a more mature and prosperous future, enabling developers to build complex applications more easily and ultimately achieving a “Game Changer” level improvement in development experience.

2 Likes