探索新的编程范式

显然想要在 DFINITY 保证安全性地实现复杂应用，我们需要探索新的范式。

最终一致性与确定性在传统互联网的分布式架构下有一些解决方案，这是值得我们借鉴的。DFINITY 上的智能合约需要关注的是数据的最终一致性，从写入和读取入手。

首先当我们需要很强安全性保证时，可能把整个所有的逻辑放在一个容器里面。主要在一个容器中，所有的交易都是原子性的，这里确保了事务与数据两个层面的一致性。但这种方式面临着扩容的噩梦，显然是偷懒的做法。

传统互联网其实关注的是数据库中数据的一致性，而在 DFINITY 中其实分为两个部分：一个是业务层面的，这部分是可以通过更新合约变化的，我们其实不太需要保证这里的原子性；而还有一部分是数据层面的，也就是进入正交持久性的数据，落盘的数据，这才是我们需要保证一致性与原子性的地方。

在 DFINITY 中有使用了名为 stable 的变量类型来定义落盘的数据，这其实类似于传统的数据库，目前也有多个团队在做 DFINITY 的数据库引擎，有了这个底层落盘数据的一致性与原子性，上层的业务的安全性就依靠数据来保证一致性。

如果是借鉴原来分布式事务的概念，我们有四种方式实现这个能力：

• tcc 两端事务提交，这是目前银行转账使用的机制，在交易发生时我们先直接更新数据库的 stable 的最终一致数据，等大家都确认清楚后，再去提交。

• saga 的事务处理机制，首先建立一个事务协调程序，当某个容器需要发起一次跨合约的调用时可以向事务协调程序申请一个 ID，并通过这个 ID 向事务的终结程序汇报，最后大家都提交成功后，再进行整体的提交。

• 使用事务观察者模式，对 stable 的状态进行包装，每当发生状态的更新操作时，观察者都去记录更新前后的两个值，如果发现某一个事务失败，观察者会就使用之前的值回滚操作。

关于容器数据扩容

DFINITY 的优势在于大规模高性能的去中心化数据库存取，DFINITY 的程序以容器为单位运行，容器中会存储业务相关的数据库，且容器之间不会共享状态数据。而目前 DFINITY 容器存储上限是 4G，如果一个业务容器的 4G 存满之后，容器就需要面临扩容的问题，该如何解决？

目前 DFINITY 能允许容器在存储与带宽等资源即将耗尽时，自动 Fork 出一个新容器进行扩容。新的容器中只保存了最近的状态数据，会丢弃历史。两个容器间依然通过异步调用来实现交互。

同时，在设计容器时，需要把各种级别的数据分开存放。举个例子，如果直接在 DFINITY 上建立一个钱包容器，交易记录的数据量会比用户地址的数据大很多。如果这时候把这两类数据放入一个容器，就会影响后续的扩容能力。 (责任编辑：admin)