Starcoin, 一个分层智能合约及去中心化金融网络

Posted 2021-10-02 跨链技术践行者

摘要：Starcoin 是一个去中心化分层智能合约网络，它旨在提供一种安全的数字资产及去中心化金融运行平台，让区块链能够更低门槛应用在更多领域。我们提出了一个分层区块链模型的建议，旨在创建一个数字资产安全、并能达到性能及可扩展的目标。安全是区块链立身之本，Starcoin 从设计之初就把安全作为首要目标，从基础层、共识层、协议层、扩展层、应用层等多层面进行深度探索与改进，全力保障主链和数字资产的安全。

为了达到去中心化的目的，Starcoin 选择成熟的中本聪共识算法，并在其基础上进行增强，可以动态适应网络算力状态，达到链上性能及稳定性的平衡。交易是基于智能合约来运行，使用一种名为 Move 的编程语言。我们使用 Move 来定义区块链的核心机制，如数字资产和 DAO 治理规则。这些核心机制能够创建一个独特的去中心化治理机制。

为了验证 Starcoin 整体设计，我们已经构建了一个开源的原型实现。

简介

Starcoin 是新一代的区块链公链基础设施，是一个分层的，去中心化的区块链系统。

Starcoin 一层专注于提供数字资产基本能力，能够安全快速的定义资产，并通过智能合约灵活地实现资产转移交换等能力。

Starcoin 二层专注于解决资产转移交换等过程中的扩展性和性能问题。由于 Starcoin 的特殊设计，Starcoin 二层可以使用一层的数据，一层也可以校验二层的运算结果，一层二层有机结合在一起，资产可以在一二层之间自由流动。

长久以来，区块链系统存在所谓的区块链不可能三角，即无法同时达到可扩展（Scalability）、去中心化（Decentralization）、安全（Security），三者只能得其二。

比特币以及以太坊便是一种追求“去中心化”与“安全”的技术组合，而不追求可扩展。其他区块链项目也都是在这三者之间进行选择。而三者只选择其二的做法，很大程度上难以满足商业使用的需求。

Starcoin 试图通过区块链分层技术，在区块链一层达到去中心化和安全，通过区块链二层达到很大的可扩展性，达到可以供商业使用的程度。因此可以说 Starcoin 试图通过紧密结合的区块链一层二层来打破区块链不可能三角。

设计理念

1. 以价值流转为中心 —— 所有的分层以及周边功能的改进都是以促进价值流转为中心目标。
2. 共识分层治理 —— 不是所有的认知都需要全局共识，共识也需要分层。越底层越侧重于安全和去中心化，越上层越侧重于性能和便利性。
3. 技术创造可能，社区决定取舍 —— 尽量通过技术消弭分歧，创造可能，保持技术中立，价值观层面的的选择和取舍留给社区决定。

接下来从 6 个方面来介绍 Starcoin 的设计。

1. 增强的中本聪共识协议

Starcoin 共识是一种比特币中本聪共识的增强版本。为了加快出块速度和降低交易确认时间，我们引入叔块率等运行期数据，对出块时间，难度，出块奖励进行动态调整，可以最大限度利用网络，减少用户等待时间。此外，我们还提供了区块链的动态调整能力，一些关键参数通过链上治理机制来实现配置修改。

中本聪共识最早由比特币采用，也是区块链早期广泛使用的一种共识方法 [1]。目前为止中本聪共识是容错能力最好的公有链共识机制，其设计简单，通讯开销低，经过了数十年的验证。但是其吞吐能力较低，出块时间过长，用户体验较差。因此，我们选择了对中本聪共识进行加强，使得 Starcoin 具备以下的特性：

1. 动态调整出块速度以及区块大小，在安全，网络吞吐，用户体验之间寻求平衡。
2. 共识相关的参数可通过社区治理，经合约升级。

引入叔块

中本聪共识中，要提高网络吞吐，可以通过 (1) 增加区块大小，或 (2) 缩短出块间隔。这两种办法都会增大网络中竞争块出现的概率。而这些竞争块中，最多只有一个区块能够进入主链，为打包交易提升吞吐作出贡献，而其他块则成为孤块。区块越大，出块时间越短，孤块会越多，而孤块率增加会降低双花攻击的难度，所以我们需要将孤块率限制在一个阈值之内。

我们在孤块基础上，引入叔块概念。首先，定义每 N 个块为一个 Epoch。当满足如下条时，则定义区块 B2 为 B1 的叔块：

1. 在同一个 Epoch 内。
2. B2 的父块属于 B1 的任一祖先。

我们用 Epoch 内的叔块率评估网络的拥塞情况，并以此作为出块时间，出块大小调整的依据，实现充分利用网络，提升吞吐的同时，也可避免区块过大或者出块时间太短导致孤块过多，安全降低。

动态出块时间调整

为了将叔块维持在一个合适的阈值内，在每个 Epoch 末，都会重新调整下一个周期的出块时间。

如果叔块率较高，则说当前的出块时间间隔下，网络中存在较多的分叉和孤块，我们需要调大出块的时间，缓解此问题。反之，则说明全网出块情况良好，还能进一步缩短出块时间，进一步提高全网吞吐。

算法引入以下参数：

名称	描述
epoch_avg_time	上一个周期内的算数平均出块时间
epoch_uncles_rate	上一个周期的叔块率
uncles_rate_target	目标叔块率
next_time_target	下一个周期的出块时间

计算方式:

next_time_target = epoch_avg_time * epoch_uncles_rate / uncles_rate_target

动态调整区块大小

我们希望区块的大小限制能根据网络情况来动态调节，而区块的大小和区块中所有交易使用掉的 Gas 成正比，所以我们通过调整区块的 Gas 限制来调整区块大小。

针对一个 Epoch 内的所有区块 Gas 消耗统计，并结合出块速度，动态的调整区块 Gas 限制。当出块速度达到系统设置的最小值，全网拥塞情况处于良好，因此可以调大区块的 Gas 限制，增加区块大小；反之，当出块速度达到系统设置的最大值时，全网较为拥塞，因此需要降低区块的 Gas 限制，降低区块大小。

动态难度调整机制

Starcoin 改进了中本聪共识的难度调整算法，使得:

1. 反应更快速：当全网算力发生变化时，难度值能够快速做出反应。
2. 出块时间更稳定：在全网算力不变时，有的块偶发性的出快或者出慢，难度不应该剧烈的波动。

通过以下办法进行改进：

1. 根据叔块率调整出块时间从而调整下一个 Epoch 的难度。
2. 难度计算中引入区块高度做为权重，对平均出块时间的计算为高度加权的算术平均。
3. 使用更短的难度周期。

算法引入以下参数：

名称	描述
block_time_target	下一 Epoch 的出块时间
n	难度调整周期内的区块数(小于 Epoch 内的区块数，初始值为 Epoch 区块数的十分之一)
next_target	下一周期的难度目标
block_target_i	高度为 i 的区块难度
block_time_i	高度为 i 的区块出块时间

计算方法：

next_target = avg_target * avg_time / block_time_target

其中：

Arithmetic Mean avg_target
avg_target = (block_target_cur-n+1 + block_target_cur-n +...+ block_target_cur) / n

Weighted Arithmetic Mean avg_time
avg_time = block_time_cur-n+1 * 1 + block_time_cur-n * 2 +...+ block_time_cur * n / ((n) * (n+1) / 2)

动态出块奖励调整

Starcoin 出块奖励的调整遵循如下原则：

1. 奖励为难度 / 时间线性。根据下一个周期的出块时间，来动态调整出块奖励。
2. 分配一定比例的奖励给汇报叔块的区块。

Starcoin 的动态调整的算法依赖叔块率的数据，而叔块信息需要矿工额外的付出成本去收集，为了奖励矿工在区块中汇报叔块信息，会分配一定的奖励给当前汇报叔块的矿工。

叔块奖励计算方式:

reward = next_epoch_block_reward * (1 + reward_per_uncle_percent * uncles)
next_epoch_reward_block = base_reward_per_block * block_next_time_target / base_time_target

2. 所有权明晰的状态存储

区块链的状态存储机制是区块链系统设计中的关键点之一，对链的性能以及安全性都有很大的影响。Starcoin 的状态存储，采用类似以太坊的账户模型，所有用户的状态构成了一个通过地址映射的状态树。 从创世状态开始，随着将交易作为输入信息，将状态推进到下一个新的状态中，生成新的状态树。

以太坊将账号分为合约账号和用户账号。合约账号用于部署合约的代码以及存储合约的状态，用户在某个合约中的状态都保存到该合约账号下，读写权限也由合约自己控制。这样的设计自由度很高，但导致合约状态的所有权不明确，从而容易带来安全上的问题以及很难解决"状态爆炸"问题。

Starcoin 以太坊账户模型基础上做了以下改进：

1. 废弃了合约账号，任意账号都可以部署智能合约，部署的智能合约在当前账号下。
2. 通过对合约编程语言中状态存储机制的改变，让智能合约的开发者很容易的把合约的状态分散保存到该状态所属的用户地址下，从而明确状态的所有权。

通过这样的改造，一方面增强了链对用户状态的安全保护能力，另外一方面也为状态计费提供了可能。

两级状态模型

我们在 Diem 的 Jellyfish-Merkle 树的基础上，增加了可分叉功能作为状态存储的基础组件，封装成两级状态树结构。Jellyfish-Merkle 是一种前缀查询树结构。整个链的状态是一个全局树，叶子节点是每个用户的状态 AccountState，查询路径是账号地址；AccountState 里存的便是用户的 Resource 和 Code 的二级 Merkle 树的根哈希值。如下图所示：

Code 树的叶节点是每个合约 Module 的代码，查询路径是 Module 名称。Resource 树的叶节点是合约中的状态，查询路径是状态类型 StructTag。这样合约中即可通过 borrow_global<T>(address) 方法读取或者通过 move_to(address,resource) 写入状态。

Starcoin 通过两级状态模型，可以便捷的提供状态存在和权益证明。

计费策略

由于区块链网络状态会随着账号增加而增加，而对状态的读写计费都是发生交易的时候一次性通过 Gas 计算，用户并不会为自己长期占用了链上的状态而承担额外成本，从而也没有动机删除和清理无用的老旧状态。所以区块链技术圈一直在探索一种合适的状态计费机制，也有人在以太坊上提出了状态租赁机制，但由于前面提到的以太坊上合约状态的所有权不明确，要实现状态计费非常困难。而 Starcoin 的状态机制明确了状态所有权，从而为状态计费提供了可能。

Starcoin 状态计费策略采用后置抵押方式，用户可以使用的存储空间 STCBytes 根据用户持有的 STC 实时换算，每次执行交易前，检查用户的 STCBytes 余额（计算公式如下），如果余额小于阈值则拒绝该交易执行。

余额的计算方法：

STCBytes = STC  *  置换率 - 用户已经使用的 STCBytes 大小 

STCBytes 余额是每次交易前计算截止到上次用户的交易结束时用户的存储状态，允许用户超额使用一次，这样计算 STCBytes 时不需要考虑当前的交易。这样可以鼓励用户主动释放掉不用的资源，减少 STCBytes 的使用，从而利于系统的良性发展。

3. 新一代智能合约编程语言、虚拟机和标准库

智能合约编程语言，虚拟机，以及合约标准库是去中心化金融基础设施的核心部分，如何安全、便捷的在智能合约中表达资产，是区块链智能合约领域一直在研究的方向。Starcoin 选择面向数字资产的智能编程语言，以及虚拟机，并提供了丰富的合约标准库。

Move 编程语言

Move 编程语言最早出现在 Facebook 的 Diem 区块链项目中 [5]。作为一种面向数字资产的智能合约编程语言，Move 具有 Resource 作为一等公民、灵活、安全、可验证等特性。这些特性和 Starcoin 的智能合约编程语言设计理念极为契合，因此 Starcoin 选择 Move 做为其智能合约的首选编程语言。

Resource 作为一等公民

以太坊中的链上原生资产是 ETH，而用户定义的的资产是符合 ERC20 的 Token，合约中处理原生资产和 Token 需要使用完全不同的规则。同时链本身只对 ETH 有感知，对 Token 无感知，二者的安全级别有差异。而在 Starcoin 中，无论是链上原生的 STC，还是用户自定义的 Token，都是 Resource 类型，对链来说都是一等公民，使用同样的编程接口操作，安全级别一致。

安全性

以太坊里资产是用整型来表示 [2]。资产实际上存放在合约账户中一个用户地址到余额的映射表里，它用来记录每个用户所拥有的资产数量。合约需要非常仔细的实现每个接口，以保证不会发生资产被复制或者丢失的情况。而 Move 不同于 Solidity ，它能够以线性逻辑的语义来定义 Resource 类型，开发者可以用 Resource 来自定义资产，Resource 永远不能复制或隐式丢弃，只能在程序存储位置之间移动。 这种安全保证根植于 Move 的静态类型系统，开发者不仅可以使用 Resource 来创建安全的数字资产，而且更容易编写正确的业务逻辑来操作资产。

保证资源安全、类型安全、内存安全通常有两个选择：使用高级编程语言，编译器检查保证；或者使用低级无类型汇编，运行时检查保证。Move 采用一个折衷方案：使用有类型的字节码，字节码在执行前进行安全校验，类似于 JVM 的字节码校验，然后再解释执行。这样做的好处是源码的编译器不用是可信的。

此外，Move 的 Module 是一种强类型抽象机制，Module 里面可以声明类型和方法，这些方法可以用来创建、销毁和更新 Module 里声明的类型。 在声明类型的 Module 内部，类型是透明的，而在其外部是不透明的。也就是说在 Module 外部无法直接创建、更新和销毁 Module 内声明的数据类型。必须通过 Module 里声明的方法来创建、更新和销毁。

可验证性

理想情况下可以通过链上的字节码运行时校验保证所有的安全属性，可是这样会增加链上计算开销和协议复杂度。静态验证工具包括形式化验证工具可以有效降低链上计算开销、提升安全性。Move 定义了一套规范语言叫做 Move specification language，它通过前提条件、后置条件、不变式等来描述程序怎么样才算正确运行，即所谓的规范。然后通过 Move to boogie compiler 将 Move 程序和规范转换成 boogie 程序（一种具有形式化语义的中间验证语言）。最后通过形式验证领域的自动定理证明求解器来验证程序是否符合规范。

灵活性

Move 的交易由 Module 和 Script 组成。Module 允许开发人员使用和扩展标准库功能来开发其智能合约。Script 可以让用户在交易中使用一个或多个Module，加入更多逻辑。这种 Module 和 Script 相结合的形式使交易更加灵活，同时节省时间和资源。

Move 虚拟机

从抽象的角度看，区块链实际上是一个复制状态机（Replicated State Machine）。世界状态通过在虚拟机上执行交易而更新。Move 虚拟机的输入就是交易的字节码加上当前的世界状态，输出是对世界状态进行更新的变更集。

Move 虚拟机由两部分组成：一个字节码解释器，一个字节码校验器。为了表达 Resource 的语义，基于寄存器的虚拟机实现会导致在方法间移动 Resource 变得复杂，而基于栈的虚拟机实现再加上有类型的局部变量会使这种操作变得自然。所以 Move 的解释器采用了类似于 JVM 的基于栈的字节码解释器。跟 EVM 类似，Move 也是采用 Gas 机制来解决停机问题。

Move 的安全性主要是由字节码校验器来保证的。在解释器执行之前，先要由校验器对安全性进行检查。校验器的核心功能包括：控制流图的生成、栈的越界检查、类型和种类检查、引用检查，还有与世界状态的链接等。其中栈越界检查就是检测每个方法访问操作数栈的范围，保证访问的栈的深度是合法的。具体做法是以基础代码块为单位，查看每条字节码执行之后对操作数栈的影响。接下来是通过类型检查保证操作数的类型是正确的。通过种类检查保证 Resource 不可复制、不可销毁。通过引用检查保证即便没有所有权也可以通过借用机制正确使用某 Resource。最后将字节码里的 Resource 类型同世界状态进行链接。

标准库

作为一个通用、安全的智能合约平台，Starcoin 为开发者提供了经过形式化验证的智能合约标准库。标准库包含了40多个常用的功能模块，其中除了账户、转账、交易、事件、Errors、Math、Vector 等基本功能模块外，还包含了Token、Dao、OnChainConfig 等前瞻性功能模块。

Token

以太坊是通过 ERC20 接口来定义 Token 的。如上中提到的，以太坊的 Token 存放在合约账户中一个映射表里，实际上是一个中央账本，合约需要非常仔细的实现每个 ERC20 接口，以保证不会发生资产被复制或者丢失的情况。Starcoin 没有使用中央账本，而是利用 Resource 和 Capability 实现了去中心化管理的 Token 机制。

DAO

区块链作为一个快速发展、自我更新的组织集合，去中心化治理发挥了至关重要的作用。Starcoin 抽象出一套链上治理机制，包括提议者提议、参与者（投票者）投票、决策、部署、执行等几个步骤，分别封装在不同的智能合约标准模块中，合约开发者可以直接复用标准模块中的治理机制。

形式化验证

Starcoin 标准库里所有的 Module 都经过了形式化验证。Module 中的每个方法都建立了对应的规范，它通过前提条件、后置条件、不变式等来描述程序怎么样才算正确运行。然后通过 Move 的形式化验证工具 Move Prover 来保证 Module 的实现跟规范相符。形式化验证在很大程度上提升了标准库的安全性和可靠性。

4. 自我演进的去中心化链上治理体系

区块链的治理结构包含了决策和沟通的过程，对区块链特别是公链生态具有隐形但长远的作用。链下治理始于上一代公链，新一代的公链则更青睐链上治理。 合约协议的代币治理也将以太坊上去中心化金融浪潮推到了前所未有的高峰，这也是下一代公链应该考虑的严肃议题。 长远来看链上治理符合区块链的开放内涵，Starcoin 在链上治理以及合约治理方面也做出了自己独特的改进。

治理是什么

如果将区块链社区识为一个组织，治理是这个组织就改变区块链特性所做出的决策过程，尤其针对于共识和经济分配，可以说是区块链的“宪法”。在流程上说，治理包含提议者提议、参与者（投票者）投票、决策、部署、执行等几个内容。 治理的作用在于使得区块链系统进入一个更加长久、有序的发展过程，提升整个网络的价值。传统的组织一般局限于一国，治理机制遵循当地法律的规则，治理产生的争议可通过司法系统裁决。而去中心化的区块链治理，其参与者来自全球，无法依赖司法系统裁决，怎样从中抽象出一套合理治理机制，解决争议，构建约束力，仍处于探索阶段。

比特币的 BIP，以太坊的 EIP 等治理模式，基本属于链下治理模式。 一般流程是提出提案，社区讨论，核心开发者开发并发布版本，矿工进行节点升级，代码中约定在某个高度自动激活新特性。大多数情况下，这种治理模式也运作良好，但一旦社区中的开发者和矿工就某个特性之间产生不可调和的分歧，链和社区则会面临硬分叉的风险。

纵观比特币和以太坊面临的几次重大的分歧，可以发现社区治理面临的最大困境有两个：

1. 没有一个明确的指标来判断哪一种主张在社区中达成了多数的共识。
2. 链下协商的协议在链上没有约束力。

因此，我们试图在 Starcoin 中进行链上治理，尝试一定程度解决上面的两个困境。

Starcoin 的治理

我们认为链上治理一定程度能解决前面提到的两个困境。首先无论治理的机制如何设计，投票最终会产生一个明确的结果，给社区传达一个明确的信息。其次，链上治理推迟了决策的时间节点，开发者和矿工可以先履行自己的职业责任，只是从技术角度评估提案的可行性，开发以及升级节点，然后再和社区成员一起决策是否激活以及在什么时候激活新的特性。最后，一旦链上投票产生结果，由于节点实际上已经都升级完成，最终投票结果在链上会自动执行，具有约束力。

所以我们提出了治理机制的设计原则：『技术创造可能，社区决定取舍』。在开发以及升级阶段，开发者和矿工应该对提案保持技术中立态度，等升级完成，需要投票的阶段，再作为社区成员一起来行使价值观选择权，决定取舍。

Starcoin 的链上治理有以下几个流程：

1. 提案者发起提案，当前发起提案没有准入限制，任何系统参与者都可以发起提案。
2. 经过公示后，投票者进行投票，当前的投票机制是 Token 质押投票，票数与质押的 Token 数量成正比。
3. 投票期过后，任何系统参与者都可以调用，决策合约进行提案决策。
4. 决策通过后的提案，再次经过公示后，可由任意系统参与者提交执行。

Starcoin 的链上治理机制有几个重要的设计考量：

治理制度可治理

每个链上治理系统的设计都需要考虑：

1. 提案者和投票者的准入原则。
2. 决策时的投票参与率以及投票通过率。
3. 投票制度的选择。

这几个因素决定了治理系统的去中心化程度以及决策执行效率。但由于治理的复杂性，不可能在一开始就设计一个完美的治理制度，所以治理制度本身的演进机制非常重要。Starcoin 系统的参与者可以通过链上治理策略对该系统本身的治理参数以及投票制度进行去中心化治理升级，不断演进，以适应瞬息万变，不断更新的区块链技术热潮。

治理制度可复用

很多去中心化金融协议构建于代币治理系统之上，通过协议代币的治理来不断迭代协议。 Starcoin 的治理系统原生支持任意的代币协议，代币协议只需要接入 Starcoin 的治理合约即可实现代币治理，从而复用整个治理制度。 合约治理内置在 Starcoin 的合约标准库中，这使得去中心化金融协议能够更好的利用代币治理达到协议的持续升级和发展。

最低准入门槛

治理过程中多种角色，无论是提案者，投票者，执行者，都尽量不设置准入机制，保证最低准入门槛，充分利用社区的群体智慧。

小结

区块链的成功取决于其进化能力。这种演变将带来许多方向性决定，而围绕这些决定的治理最能决定系统的未来。有别于其他拥有治理能力的区块链系统， Starcoin 将链本身的治理和合约协议的治理统一在一起，使得 Starcoin 的治理机制能够服务于更广泛的去中心化应用， 同时可通过自演进，不断升级成更加成熟的治理制度。

5. 安全的区块链

Starcoin 从设计之初就把「安全」作为首要目标之一，从基础层、共识层、协议层、扩展层、应用层等多层面进行深入思考，从数据逻辑、智能合约、操作权等多维度进行深度设计，力争全方位覆盖，全力保障链和数字资产的安全。

基础层安全

Starcoin 使用 Rust 语言开发，保障基础组件的内存安全与高效。众所周知，使用 C/C++ 语言经常有内存安全方面的问题，而其他一些高级语言如 Java/Go/Python 等，受 Runtime 和垃圾回收机制等方面的影响，执行效率通常会比 C/C++ 略逊一筹。Rust 语言集二者长处于一身，在保证了内存安全的同时，又兼顾了极致的执行效率。Starcoin 在选择开发语言的时候充分考虑到了安全性和运行效率等因素，选择 Rust 语言开发，最大程度上保障 Starcoin 的安全与高效。

在 Starcoin 的整体设计中，提供了四个层面的数据校验机制：

1. 交易可校验：BlockHeader 包含一个全局交易累加器的根哈希，任何上链的交易都有对应的全局证明。
2. 状态可校验：BlockHeader 包含一个全局状态状态树的根哈希，保障了状态可验证。
3. 区块可校验：BlockHeader 包含一个 BlockBody 的哈希，用于校验 BlockBody 中的数据。
4. 链可校验：BlockHeader 包含一个全局区块累加器的根哈希。任何一个区块可以提供一个和当前区块的关系证明，不需要遍历区块即可验证某个区块是否是当前区块的祖先区块。参考下图

以上是 Starcoin 安全性的基石。其中，「交易累加器」和「区块累积器」组成了 Starcoin 独特的「双累加器」模型，为数据安全提供坚实的基础。

共识层安全

Starcoin 共识针对中本聪共识做了一些改良，在继承中本聪共识安全、完全去中心化和防篡改等特性的同时，在安全方面的改进体现在：

1. 更加敏锐的感知和适应算力波动
2. 可通过链上治理调整共识参数，降低硬分叉带来的安全风险的可能

协议层安全

Starcoin 协议在数据安全和共识层安全的基础上进行设计，充分保障了链在非可信网络中的安全性。Starcoin 协议本着数据可验证的原则，对接收到的网络数据进行严格的校验，迅速甄别作恶节点，从而起到保护节点安全的作用。

扩展层安全

为了更好地扩展区块链的能力，Starcoin 将智能合约的安全作为重要设计目标。Starcoin 使用 Move 语言作为智能合约语言。Move 语言的设计理念是让针对数字资产的编程更加安全、简单，所以在语言的设计过程中首先考虑了安全性和可靠性。Move 语言的设计者们从以往的智能合约安全事件中充分吸取经验教训，最大可能的降低 Move 合约出现意外漏洞或安全事件的风险，其安全性主要由以下几个方面保证：

1. 自底向上的静态类型系统；
2. 资源不可复制或者隐式丢弃；
3. 资源按用户存储，重新定义链，合约，用户三方的数据操作权限；
4. 引入形式化验证技术，通过数学原理来证明合约的安全性；

应用层安全

Starcoin 主要在以下层面支撑应用层的安全性：

1. 提供多签交易，方便通过多签来管理数字资产。
2. 提供私钥重置功能，在账号地址不变的情况下，可变更私钥。
3. 应用层可通过前面提到的数据校验机制，方便地确定交易是否上链、验证状态以及区块是否合法，从而保证应用的安全与可靠。

6. 分层网络

背景

当前区块链面临的可扩展性问题的解决思路主要有两种，一种是一层（layer1）扩展，另外一种是二层（layer2）扩展。一层的扩展受不可能三角限制，很难平衡安全和可扩展性，所以 Starcoin 的设计中，一层主要负责安全，二层负责扩展，一二层有机结合起来，解决区块链面临的可扩展性问题。这种思路，已经是公链领域在一层扩展遇到困难后，基本达成的共识，比如以太坊的 Rollup 发展路线 [4]，Nervos 的 CKB [7]。

一层在分层网络中的职能：

1. 通过增强的中本聪共识机制来尽可能的在保证安全的基础上在一层扩容，最大化一层网络的利用率（出块时间以及区块大小的动态调整机制，参看共识部分）。
2. 提供资产的定义，发行，以及流转，以及一二层之间的流转能力。
3. 给二层提供仲裁能力，二层可以利用一层的安全机制来保证自己的安全。

二层在分层网络中的职能：

1. 将一层的交易分流到二层，一层不再关心二层交易的细节以状态的变更。
2. 提供一套监督机制，二层的不同角色之间可以互相监督。
3. 提供证据保全能力，用户如果对二层的交易有争议，可以到一层仲裁。

二层方案概览

状态通道

通用的状态通道包含支付通道，只是后者的状态只能是资产，而通用的状态通道试图把状态扩展到应用的任意状态。状态通道的根本思路是通过通道双方的互相监督，让双方之前的状态变化从链上迁移到链下，等通道关闭时再进行链上清算（也可以优化为定时清算），相当于把多次交易的状态变更合并为一次，从而降低交易成本，提升整体的交易容量。通道内的状态变化成本极其低廉，所以可以支持高频交易或者双方交互频繁的互联网应用（比如游戏）。虽然理论上状态通道的参与者可以是多方，但由于状态通道上的任何变更都需要所有参与方共同确认，所以很难扩展到两个以上的参与方，也因此限制了它的应用场景。

侧链

侧链或者子链，业界并没有非常准确的定义，很多人也不认为侧链是二层方案的一种。但我们这里限定一个条件，当侧链的共识机制依赖于一层的共识机制，提供了一种仲裁机制，允许侧链的用户或者节点运营方对侧链共识达成的状态在一层进行挑战，并可以通过一层的仲裁机制，推翻侧链共识状态，我们就认为这种侧链方案属于一种二层的解决方案，否则侧链是一个独立的链，本质上和多个链之间的跨链没有区别。侧链作为二层解决方案的好处是可以扩展到任意多方，并且侧链有了一层的仲裁约束，可以做到只要有一个侧链节点是诚实节点即可保证网络安全。

RollupChain

RollupChain 是区块链社区新兴的一种二层解决方案，本质上可以理解成是对原来 Commit-Chain 方案(如 Plasma )的改进。在 Commit-Chain 方案中，二层链的运营方需要定时向一层提交二层链的状态根或者区块头证明，而用户可以通过自己状态的证明直接在一层退出二层的资产，如果运营方提供了错误的证明，用户也可以对运营方提交的证明进行挑战，从而保证二层的安全。但 Plasma 的方案中，数据可用性一直是一个难题，用户没有全量的数据，二层链的运营方可能通过隐藏数据或者拒绝服务等方式阻止用户构造出挑战自己的证明。而 RollupChain 的关键改进就是将二层的数据直接提交到一层区块中，一层的区块只是『记录』了二层的交易数据，但并不执行。但当用户需要挑战运营方时，总能在一层找到数据并构造证明，从而解决了数据可用性问题。虽然 RollupChain 也会受限于一层的容量（因为它的交易也需要占用一层区块的容量），但它简化了 Plasma 等方案的挑战机制设计的复杂度，是当前更容易落地实现的方案。

可验证的链下计算

可验证的链下计算入 zk-rollup 等方案，思路和 RollupChain 的机制一样。但它引入了零知识证明，避免了二层的交易如果需要挑战，依然需要在一层执行的难题，一层只需要提供校验零知识证明的能力即可。

统一的二层方案模型

总结当前的各种二层方案，可以发现并没有『银弹』可以一次性解决区块链的可扩展性问题，区块链的扩展性问题的解决，需要在实践中不断的演进。但同时，二层各种方案之间本质上是有共同之处的，因此我们可以抽象出一种通用的二层方案模型，以适应二层方案的不断演进。当前各种二层网络中的几个关键问题：

1. 应用的状态（包括资产）如何在一层和二层之间安全的转移。
2. 如何保证二层的数据可用性。
3. 如何证明和提供仲裁机制。

这几个关键问题的解决，都和二层交易和状态的存储机制有关系。任何二层的方案，都是将一层的状态锁定并在二层重建，这些状态的变更可以表达为一个状态树，只需要定时或者最终（取决于证明以及挑战机制的设置）将状态树的根提交到一层，作为一层状态树的一个外部子树节点。这样状态的迁移以及证明可以和一层使用同样一套机制。而在 Starcoin 的一层设计中，更容易实现这样的统一模型，主要体现在：

1. 所有合约的状态抽象为统一的资源模型，方便一层和二层之间的状态迁移。
2. 合约的无状态设计，使得合约本身不维护状态，状态由底层的状态存储模型提供，方便合约在一层二层之间迁移。
3. 交易的累加器以及状态存储的模型，可以更好的提供状态证明机制，一二层复用。

关于 Starcoin 的二层设计的具体方案，会在未来发布的 Starcoin 二层设计白皮书中详述，这里只阐述了一层设计中对二层的考量。

总结

综上所述，Starcoin 通过在共识机制，状态存储以及智能合约编程语言方面的改进，一方面增强了安全性，使其更适合当前去中心化金融的应用场景，另外一方面也为分层架构奠定了基础，不同的层做出不同的取舍，未来可支撑高性能 DApp 运行的需求。同时通过链上治理机制，保证了链的持续演进能力和生态构建能力。

参考资源

1. S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” Bitcoin - Open source P2P money 2008.
2. V. Buterin, “Ethereum A Next-Generation Smart Contract and Decentralized Application Platform”, 2014.
3. Z. Amsden et al., “The Libra Blockchain.” https://developers.libra.org/docs/the-libra-blockchainpaper.
4. V. Buterin, “A rollup-centric ethereum roadmap" A rollup-centric ethereum roadmap - ethereum-roadmap - Fellowship of Ethereum Magicians.
5. S. Blackshear et al., “Move: A language with programmable resources,” Move | Diem Documentation .
6. EOS IO. Eos.io technical white paper. https://github.com/EOSIO/Documentation, 2017.
7. “Nervos CKB: A Common Knowledge Base for Crypto-Economy” https://github.com/nervosnetwork/rfcs/blob/master/rfcs/0002-ckb/0002-ckb.md.