到目前为止，一个简单的合约语言与合约虚拟机已经完成了；接下来，我们让我们的整个系统可以并行化；
性能，如果我们用现在的互联网应用去衡量dapp，dapp无法支撑这种量级的访问，当然退而求其次，即使我们把关键数据上链，这种量级对于现在的dapp也是不可想象的；所以性能一直都是区块链一个热门话题，于是乎，出现了众多解决方案，侧链，分片，二层等等，我们即将要做的并行化也是为了提高性能的一种方案。
一般我们第一反应就是交易并行，五条交易同时运行；那如果我们在深究一下，交易之下是什么？每条交易的本质是什么？其实是操作链上数据，对链上数据的读写，我们对这些读写操作，称之为读写集，即一个交易对链的读操作，写操作的集合；我们需要把这些读写集并行起来，有点类似与数据库，很明显会有一些问题，读写之间的冲突，那我们应该如何解决这个问题呢；
说并行之前，我们先说一下，现在的模式——串行执行，交易一个一个的执行，执行完之后的状态，作为后一个交易的起始状态，如此依次执行所有的交易；
我们并行的时候，有一个前提，就是并行执行的结果，与串行执行的结果保持一致。并行是多线程同时执行合约，但是并不会导致交易的顺序产生变化，这样也在不同的节点上，运行时，也能有一个统一的标准。
以块为单位进行处理，同时选取块中的多个交易执行，然后将交易产生的读写集，保存到缓存中，保存的时候，会将要读写的数据版本号，也进行保存，作为后续校验的依据；交易执行完之后，还需要进行校验，主要的校验工作，就是验证本交易的读取的数据是否被修改过，如果被其他交易修改过，则版本号会有变化，则该交易无效，需要重新执行，如果验证没有问题，就可以标记为完成。然后重复该过程，直到区块中的所有交易都被执行，当cpu的核数越多，处理速度也会提高，但是还依赖与，交易之间的依赖程度，依赖程度越搞，则交易的重复执行的次数也会越多，速度也会变慢。
后续我们就按照这个思路，对之前合约引擎系统进行改造升级。