深入解析DFINITYIC存储技术及其最新进展

近期，DFINITY社区经过广泛讨论，通过了一项旨在提升Canister内存容量的NNS提案。这项提案建议为Canister设计一个新的系统API，使其能够使用更多的内存资源，从而提高其性能和数据处理能力。

Canister内存结构

Canister的内存主要由两部分组成：WASM运行时内存和稳定内存（Stable Memory）。每部分的最大容量为4GB。WASM运行时内存受限于32位指针地址空间，而稳定内存则与WASM运行时内存相匹配，同样为4GB。

然而，此次提案特别针对稳定内存进行了扩展，使得Canister可使用的最大稳定内存从4GB提升至8GB。这一改进将显著提升Canister的数据存储能力。

内存管理机制

DFINITY的Canister使用Motoko语言编写，其垃圾回收（GC）算法采用Copying算法。这种算法将4GB的内存分为两个2GB的区域：from space和to space。数据初始写入from space，在执行dfx canister install命令时，活动对象会被复制到to space，而from space中的垃圾数据将被清除。

Copying算法的优势在于内存利用率高，适合频繁增删数据的场景。然而，它也存在一些缺点，如浪费了一半的堆内存空间，并且在活动对象数量较多时效率较低。为此，Motoko现已支持Compacting GC算法，该算法不会浪费一半的内存，可以充分利用WASM内存。

存储提案详情

提案的核心内容是提供一个新的系统API，使每个Canister都能访问子网的所有内存空间。具体来说，每个Canister将拥有自己的WASM运行时内存和稳定内存空间，所有副本都将维护各自的数据状态。

新增的系统API包括：

• ic0.stable64_write: (offset: i64, src: i64, size: i64) -> ()
• ic0.stable64_read: (dst: i64, offset: i64, size: i64) -> ()
• ic0.stable64_size: () -> (page_count: i64)
• ic0.stable64_grow: (additional_pages: i64) -> (old_page_count: i64)

该提案已于9月3日通过NNS审核，接下来将进入代码更新阶段。未来，社区将继续关注并优化这一功能，逐步提升Canister的内存上限。

潜在挑战与未来方向

尽管该提案带来了显著的内存提升，但也面临一些挑战。例如，当稳定内存超过4GB时，使用了新API的Canister与未使用新API的Canister之间的交互可能会出现问题，导致Canister崩溃。

为了解决这些问题，社区提出了几种可能的解决方案：

• 子网内存共享：将子网的部分内存分配给稳定内存，但这种方法的局限性在于存储内存的最大限制仍受子网内存的限制。
• BigMap：通过多个Canister分片存储数据，但目前尚未达到生产级别的要求。
• WASM 64：将Canister的地址空间升级为64位，最大内存可达16TB，但数据迁移将涉及大量数据，可能引发新的问题。

建议开发者目前暂时不要使用这一实验性的API，等待其成熟后再行采用。

获取Canister存储状态的方法

Motoko

Motoko的运行时系统（RTS）提供了多种方法来获取Canister的内存状态：

• rts_memory_size: () -> Nat：返回当前WASM的总内存分配。
• rts_heap_size: () -> Nat：返回当前实际堆内存大小。
• rts_max_live_size: () -> Nat：返回从上次GC到现在堆的最大大小。

Rust

在Rust中，可以通过IC的“aaaaa-aa”Actor访问IC.status，获取内存数据。此外，Rust还可以在非升级期间通过CDK提供的API操作稳定内存。

DFX & Moc

在Moc中，可以使用--compacting gc标志来替换默认的Copying GC算法，从而使Motoko编译的Canister能够使用4GB的WASM内存。

稳定内存

稳定内存主要用于持久化存储全局变量，仅在Canister升级时写入。每个Canister的副本都有自己独立的稳定内存，而不是共享同一份稳定内存。

数据存储的其他技巧

1. 存储数组时，建议使用Blob类型而非[Nat8]，因为通过[X]或Array.init初始化的数组在内存布局上是相同的。

2. 目前较为成熟的解决方案是将数据直接存储在稳定内存中，而堆内存则用于数据检索。