本期，我们针对实现节点时如何更有效率地执行交易的核心问题，来谈一谈 Conflux 的延迟执行策略。
Conflux 通过改进的共识协议，把交易的吞吐量提升到了每秒数千笔，这已经接近了普通计算机硬件处理能力的极限（以现在主流 CPU 和 SSD 硬盘的性能为例，一般每秒钟也就能处理几千到一万笔交易）。
实际上，如果不考虑执行交易的速度，Conflux 共识协议在 10Mbps 带宽下超过 9.6Mbps 的共识吞吐量已经可以支持每秒上万笔交易了。 " 如何更有效率地执行交易，是我们实现 Conflux 节点时候要解决的核心问题之一，也是经常被社区的朋友们问到的问题。这次我们就来简单介绍一下 Conflux 是如何高效率地执行交易的。 " Conflux 采用的基于树图结构的共识有一个非常重要的特点，就是“交易的执行和打包相分离”。即矿工在打包新区块的时候只需要验证被打包的交易形式上合法即可，而不需要实际执行这些交易。
在传统的区块链系统中，矿工往往需要执行自己打包的区块中的所有交易，再将执行交易以后的状态根（State root）一并放在区块头里。这样的设计虽然效率上不是最优，但是对于本身吞吐量很低的系统来说已经足够了。
如果希望充分压榨硬件的潜能，把区块链的性能提高到现有硬件可以支持的极限，那么就会看到“打包即执行”的模式是有缺陷的。
首先，任何区块链都难免出现回滚的现象，出块速度越快则回滚也越容易发生。
诚然，长度比较短的回滚并不会对区块链的安全性构成任何威胁。但是每次回滚发生的时候，都意味着当前的世界状态也要跟着回滚，之前执行过一遍的交易在回滚后都要重新执行。这无疑会浪费计算资源。
对于出块速度慢、吞吐量低的区块链来说，这点浪费实际上无伤大雅，反正本来计算能力也不是共识吞吐量的瓶颈。而对于追求极限性能的 Conflux 共识协议来说，每一份资源都必须精打细算地用到刀刃上，这样无谓的浪费是不可容忍的。
其次，为了充分利用网络带宽资源，就必须允许并发区块——否则的话几乎每个时刻整个网络中最多只能有一个区块在广播，大部分带宽都处于闲置浪费的状态
这些并发区块对应的区块链历史往往是互不包含的，因此，验证每个区块内状态根的正确性也将是一件非常耗费计算资源的任务。
最后，我们不难看到，打包区块的时候就执行交易看上去“很快很及时”，实际上是没有意义的。
在一个基于工作量证明的共识系统里，刚刚被打包的区块处于“未被确认”的状态，此时它里面的交易实际上没有被执行的价值。即使执行了也只能得到一个“未被确认的结果”，并不能带来任何有意义的效果。只有当区块被确认以后，其中的交易产生的结果才真正生效。
与其在打包的时候就执行所有交易，不如“让子弹先飞一会儿”，等到区块稍微稳定一点（甚至被初步确认以后）再执行更有效率。实际上，最有效率的执行方式无疑是等一个区块被确认以后再执行区块里面的交易，这样可以保证不会因为回滚而重复执行交易；但是考虑到，通常我们都希望尽早确定交易执行的结果，执行的步骤可以稍微提前一点，保证在区块被最终确认的时候可以拿到区块内交易执行的结果，这样就不会耽误任何后续的使用。
注意到这点以后，Conflux 在基于树图的共识协议中采用了延迟执行的策略。简单来说，就是当矿工打包一个新的区块时，只需要执行到之前某个区块（例如沿着父边向前数五层的祖先区块）为止的所有交易即可，无需执行新打包的区块里面的交易——这些交易会留给挖到之后区块的矿工去执行。通过这种简单的方式就可以极大地减少因为回滚引发的重复执行交易的现象。
根据测试网的实验结果，Conflux 中的枢轴链时不时会回滚两到三个区块，但是鲜少出现连续回滚四个或更多区块的情况。因此我们把交易执行的延迟设置为5个 Epoch（简单理解就是延迟5个区块执行），这样既能减少回滚带来重复执行交易的问题，又能保证在交易得到确认前就能拿到交易的结果。
另一方面，为了减少检查每个区块内的状态根带来的计算负担，Conflux 采用了一种比较“节俭”的检测规则，即只检查位于枢轴链（主链）上的区块的状态根是否正确。对于别的区块，除非它们因为某次回滚而落在新的枢轴链上，否则就不检查其状态根是否正确。这样就大大减少了单纯为了检查正确性而花费计算资源执行交易的情况，将宝贵的计算资源用在执行影响共识状态的有用的交易上，同时也让区块回归其最初的“打包交易”的作用。
至于安全性方面，即便有一部分矿工偷懒填了错误的状态根，也不会影响别的全节点对于当前共识状态的判断。只要这些矿工依然遵照共识协议检查区块间的引用关系和正确地选择引用的区块，他们的算力依然为系统的安全性作出贡献。
总结来说，Conflux 通过将交易的打包与交易的执行相分离的方式，避免了短回滚和重复执行交易造成的浪费，实现了更高的计算资源利用率。这也是 Conflux 在提高交易执行效率的方面除了重写 Solidity 虚拟机以外做出的最重要的改进。
