Chainspace-智能合约分片技术

Chainspace: A Sharded Smart Contracts Platform

  Chainspace是一个去中心化的基础设施，被称为分布式账本，它支持用户定义的智能合约，并在其对象上执行用户提供的交易。所有人都可以验证智能合约交易的正确执行。该系统可扩展，通过分片状态和事务执行，并使用分布式提交协议S-BAC来保证一致性。通过拜占庭容错(BFT)，以及极高的可扩展性、不可抵赖性和“区块链”技术，Chainspace可以安全抵御试图破坏其完整性或可用性属性的节点子集。即使BFT失败，也会有跟踪恶意参与者的审计机制。我们介绍了Chainspace的设计、基本原理和细节;我们通过对系统的可扩展性和其他特征的评价来论证;我们演示了许多隐私友好型智能合约，用于智能计量、轮询和银行业务，并测量它们的性能。

Contributions

• 它提出了Chainspace，一个可以随节点数量增加任意扩展的系统，可以容忍拜占庭式故障，并可以完全公开审计。
• 它提出了一种新的分布式原子提交协议，称为S-BAC，用于跨多个拜占庭节点分片通用智能合约交易，并正确协调这些节点以确保安全性、活动性和安全性属性。
• 本文介绍了执行计算的智能合约部分和检查计算部分之间的区别，并讨论了这种区别对支持隐私友好型智能合约的关键。
• 它提供了一个完整的实现和评估拜占庭分布式提交协议，S-BAC的性能，在一个真实的分布式节点集和在不同的事务负载下。
• 介绍了一些关键的系统和应用智能合约，并评估其性能。隐私友好型智能计量和隐私友好型投票的合同说明并验证了对高完整性和高隐私性应用程序的支持。

  论文的贡献，简要说起来就是：作者自己定义了一套分片机制，提出了一套分布式原子提交协议： S-BAC：Sharded Byzantine Atomic Commit，作者把智能合约中执行计算的部分和验证计算部分分开了，由用户来执行计算，chainspace负责验证。

个人觉得论文主要贡献应该看两个，一个是S-BAC，一个是将计算跟验证分开。

Data Model

1. Objects
   对象是Chainspace系统中保存状态的原子结构。用 o 来表示一个对象，对 o 有如下操作：
   • id(o): 通过加密生成的唯一标识符。
   • type(o): 标识对象的类型。
   对象有 active 跟 inactive 两种状态
   id之所以会提到加密，是为了利用加密之后碰撞的概率很小的特点，给每个object分配一个唯一的id。

2. Contracts
   智能合约，可以视为一种特殊的对象。包含如何操作智能合约定义的其他object的信息。智能合约初始化了一组对象。

3. Procedure
   处理对象的逻辑。对象作为参数，可以有input和reference两种身份。
   • procedure会使input对象变无效，reference对象是只读的。
   • 逻辑会输出output对象。
   理解：可以当做是一个函数，输入参数是object，允许只读的引用（object），有输出。本质上跟算法的定义很接近。有输入一定有输出，有输出不一定需要输入。

4. checker
   每个智能合约都有一个checker，记为v。checker是单纯的函数，返回布尔值。

5. Transaction
   交易，由一个或更多个procedure构成，是原子性的。
   输入必须是 active 的 objects，与一些引用object
   输出一系列 active 的output objects。
   理解： 作者对transaction进行了逻辑上的拆分，通过子过程的执行，保证最终原子性。

数据结构在chainspace系统上的位置如下：

运作逻辑

1. 首先，作者对交易进行了一个划分，在数据结构层面上，将一个transaction划分成了一系列 traces：
   
   可以看到，一个Transaction由一系列trace组成，trace之间又具有依赖性。

2. 计算工作与验证工作的划分
   

• 第一个式子是表示：trace之间是串行的，下一个trace执行之前要更新objects的状态。
• 第二个式子是表示：trace的合法性，依赖于dep的合法性 与 智能合约的checker 结果。
  （这里作者把问题抽象了，实际上真的可以这么验证吗，而且 checker（v）作为一个函数，它的有效性和准确性存疑）

简单来说，第一个sequence就是计算工作部分，第二个check就是验证部分。实际上，计算部分跟验证部分分开是有实例的，比如：比特币。比特币中的Proof of work共识所设计的puzzle，具备“Difficult to solve, easy to verify”的性质，它就将计算过程跟验证过程分开了。但是论文所描述的场景，是基于智能合约的，而一般来说，要验证一个智能合约的执行结果，除了完整的执行一遍，似乎没有捷径？此处存疑。

系统共识

论文所采用的共识系统如下：

  作者给这个共识起名叫做 Sharded Byzantine Atomic Commit （S-BAC）。实际上，S-BAC就是一个BFT共识+两阶段提交（2PC）的过程，中间套了一层分片。
  这里要再次明确，chainspace 把交易计算和部分处理交易冲突的工作交给客户端来干，系统的工作变成了验证客户端的执行是否合法，以及处理冲突。
object 到 分片的映射，一开始是用一个函数$\varphi (o)$来表示的，后面chainspace又引入了系统智能合约来进行管理

结论

  论文最大的亮点，个人觉得是 objects 只能用一次的设定，通过这种存储状态的 objects 的一次性使用，能够将智能合约并行的冲突判断转化为，判断两个智能合约是否用到了同一个 objects 作为输入。其次chainspace将交易的计算与验证一分为二，将计算交给用户来执行，确实某种程度上能够减少系统的开销。
  但是论文也有一些缺点。首先是，论文对transaction的假设，是基于乐观并发控制（数据库名词，optimistic concurrency control），简单来说，事务在提交之前会检查在事务读取数据后，有没有其他事务修改了该数据，如果有，正在提交的事务会进行回滚。然而此处论文仅提到了乐观并发，对于回滚和悲观并发没有讨论。
另外，将分片的 objects 看成资源的话，在chainspace系统中应该会存在死锁的可能性。

  本文介绍的是分片中的一种：智能合约分片。除了对智能合约分片，区块链系统中的分片还有基于UTXO模型的分片：Elastico(交易分片)，Omniledger和rapidchain，基于Account/Balance模型的分片：Monoxide，Pyramid等。后续有时间再将学习过程放上来。