智能合约语言（eDSL）—— 并行化方案 2

        这个并行算法最初其实是在aptos上实现的，aptos上使用的是move虚拟机，后来我把它移植到我们链上了，但是wasm虚拟机。还是费了不少事情。

        目前evm并行也比较火，像monad，sei等。经过调研发现，其实evm的并行，还是occ的路子，和aptos的方案也差不多，都是在这之上进行各种优化，比较链结果和vm都不一样。所以现在又准备再次移植，把他移植到evm上，不过这次打算把并行做成一个通用的模块，这样不管你用的什么虚拟机，你的交易格式有啥不一样的，存储有啥区别的，简单的修改，就可以顺利的将并行模块加入到自己的链上，直接使用，不需要像我之前那么麻烦。

      为了做成通用的模型，所以我们先对虚拟机进行抽象。

虚拟机抽象

        在区块链中，所有的虚拟机都是类似的，用来执行合约，更新链上的状态；不论是move，wasm还是evm，都是一样的，是一个黑盒子。你输入交易，它返回读写集和结果；

        需要抽象的部分，虚拟机就是输入与输出，这一部分每个vm都是不一样的；所有的虚拟机，大概可以认为是输入交易以及链的上下文；输出就是交易的结果，包括是否成功，以及改变的状态。这些数据我们不会变化，为了规范，可能就是使用trait来进行定义。

        除了这些原始数据之外，还需要添加一个缓存模块，用来缓存整个区块处理过程中，所有交易涉及到的读写集；这个缓存模块下边会介绍到。

      另外vm还需要进行一些修改，VM在需要读写数据的时候，需要先读取缓存模块，如果没有再从数据中读取，写入数据也是先写入缓存模块，等整个块都处理完了，没有问题，才写入数据库。

缓存模型

全局缓存

多版本存储

        并行处理区块交易的过程中，每一笔交易，每一次执行（incarnation），写入的数据集合。每一笔交易，每一次执行（incarnation），的读取也是优先从这里读取。相当于保存了当前链世界状态的一个子集，由于处理过程中，有验证阶段，可能会导致某些交易多次执行，所以在未处理完区块之前，数据还是不稳定的。

数据结构如下:

key：map<txid，map<incarnation , value>>

块交易读写集

块中所有的交易的读写集数组，每个交易都会分开记录，用于验证。

局部缓存

交易读集合

每一笔交易，读集合；

交易写集合

每一笔交易，写集合，交易处理完成之后，会更新到全局缓存之中，等整个区块处理完成之后，在写入数据库中。

为什么需要缓存

        为什么需要它，这就和我们并行处理的调度有关系了，当我们并行的处理一个块的交易时，这些交易就是一个整体，他们既有独立的部分，又有关联的部分；独立的部分就是每个交易需要处理的内容不一样，有的可能是nft，有的可能是质押，或者dex等；但是所有的交易都需要修改世界状态，而且还会因为修改世界状态的先后，产生依赖关系，需要我们就需要记录每笔交易的与世界状态交互的记录，以此作为依据，及时的调整我们的调度策略。