目标

提高合约的可执行复杂度，可以理解为：相同的吞吐量下，区块内交易可执行时间越长，则可执行复杂度越高（即可执行时间越长）。

以以太坊为例，为了保持良好的吞吐量，那么出块间隔会尽可能的减小，于是区块内交易执行与验证的时间就会减少，从而限制交易的可执行复杂度。

该model并不是为了改进或者提升以太坊而提出，是一种新的合约并行执行model。

个人认为，文章中用 gas 来说明复杂度是不合适的，因为一个区块内的gas总和是有限制的，交易并行是无法摆脱这个限制的，因为无论交易是否并行执行，gas的总和始终是不变的。这一点和以时间为指标是不同的，交易串行执行的场景下，时间花费等于每笔交易的时间加和，而交易并行执行的场景下，时间花费等于所有交易执行时间的最大值。

方法

1. 合约部署

Client部署合约A，需要指定可以执行该合约的service providers (SPs)，以及最少需要q个SPs来执行，即如果交易Tx涉及到合约A，则Tx由合约A的至少q个SPs来执行。

SPs是区块链网络中的节点，和其他节点没有区别。

2. 独立合约调用

这里指的是交易调用合约过程中不涉及其他的子合约调用，即如果交易Tx执行合约A，那么合约A不会调用其他合约。

交易Tx0及其他交易被矿工打包到区块Block0中后，并不会被矿工执行，矿工首先对交易列表进行排序，然后直接将该区块广播到网络中，网络中的节点接接收到区块之后，执行自己需要执行的交易（根据交易所涉及的合约在部署时指定的SPs列表来确定自己是否需要执行），执行完成之后，将状态转换列表信息广播到网络中，矿工只有收到Tx0的大于等于q个状态转换列表信息时，才将该状态转换应用到本地，并写入未来区块（不一定就是下一个，最快是下一个区块）的结果项中。矿工将已经完成状态转换的区块广播到网络中，其他节点验证该区块，除区块基本信息外，需要验证结果项中每一笔交易所对应的状态转换是否来自q个SPs，由于每一笔状态转换是SPs签名之后的内容，所以矿工无法更改状态转换信息。

3. 嵌套合约调用

这里指的是交易调用合约过程中涉及其他的子合约调用，即如果交易Tx执行合约A，那么合约A会调用子合约B、C、D等等。

客户端预执行交易Tx1（类似于gasEstimate功能）获取所有涉及到的合约列表信息（A、B、C），将该合约列表附着在交易Tx1的字段中。矿工将该交易打包进区块Block1并广播到网络中后，节点判断自己是否属于合约A、B、C的SPs，如果属于其中则执行该交易。

比如合约 A 由node1、node2、node3执行，合约B由node3、node4执行，合约C由node5执行。此时node1~5都需要执行该交易Tx1。基于此，考虑下面这种特殊场景：Block1中的另一笔交易Tx0在Tx1执行之前已经执行，且Tx0涉及到合约A，即合约A的状态已经被node1~3改变到了StateA-v1位置，由于此时只有node1~3改变了合约A的状态，node4~5还保持Block0中合约A的状态SteteA-v0，所以如果node4~5直接执行交易Tx1是有问题的。

针对该问题，本文的做法是：每个节点执行完一笔交易（涉及合约F）时，就将合约F的状态转换列表信息进行广播，并标志为“未定状态”，其他需要合约F状态的SPx收到大于等于q个消息后，更新本地合约F的状态，如果SPx在某个时间内没有收到大于等于q个合约F的状态消息，则直接中断执行。

4. 实验

以模拟实验为主。区块大小固定，出块时间固定（15秒），网络传播延时固定（50ms）。

实验指标包括：合约采样集大小，每笔交易所涉及的合约数量，系统吞吐量、交易平均执行时间（数值越大说明效果越好）。

实验1

每笔交易所涉及的合约数量最大为5，随着系统吞吐量的变化，对于不同大小的合约采样集，观察交易平均执行时间的变化。

实验2

固定合约采样集大小，随着系统吞吐量的变化，对于不同大小的合约采样集，观察交易平均执行时间的变化。