[论文研读] Adding Concurrency to Smart Contracts
1 Motivation
由于区块内的交易按顺序依次执行会显著降低了系统的处理能力, 未能充分运用现代计算机系统的多核资源来进行并行计算, 因此应当尽可能地并行执行区块内的交易
2 Contribution
- 采用动态并行方式实现区块内部交易处理方案。
- 通过该系统能够准确验证矿工所指定的一组交易在并行执行过程中的完整性，并且能够基于此序列可靠地进行相应的验证工作。
- 本研究采用JVM和ScalaSTM开发了原型系统，在测试过程中发现：针对普通矿工节点，在完成相同任务时相比传统系统提升了约1.33倍；而针对系统管理员等关键节点，则提升了约1.69倍。
3 Method
Miner
每一次合约调用（包括嵌套调用）视为一个ACTION；
每个ACTION都涉及涵盖多个storage operations（SOP），可被视为单独的操作。
每个SOP都配有一个专用锁，并且每一种不同的SOP拥有独一无二的锁定机制；因此一个ACTION会有多个锁定点；当某个具体的SOP尝试获取锁定时；其对应的逆操作会被记录在日志文件中；以便于在执行失败时进行回滚操作；
如果ACTION-B必须锁住LOCK-0，则当LOCK-0正在被AION-A中的某个SOP-A-0占用时,ACTION-B将不得不等待直至AION-A的所有操作全部完成（不仅仅是其中某个）。
完成时有两种情况：1）当ACTION-A成功提交时，则该动作包含的所有Standard Operating Procedures（SOP）的锁将全部释放，并且相关的日志将被丢弃；2）当该动作发生中断时，则根据记录反转操作（inverse operations），恢复并撤销所有相关操作，并最终全部释放这些SOP的锁。无论成功完成还是因中断而终止，在该动作中涉及的所有锁都将被正确地释放以确保系统的稳定性。
每个SOP均配备有reverse operation,通过其使用可实现对虚拟机进行细粒度并行控制。例如,在传统并行控制中,可能会对某段内存区域实施粗粒度加锁,并记录该reverse operation.然而,在一段内存可能涉及其他操作的情况下,执行回滚操作时会导致冲突.
每次当一个ACTION被提交后才会解密该ACTION所拥有的所有锁资源。同时，在locker i对应的lock lock i上会递增其counter值，并将locker i及其counter值记录到当前action的profile中。locker profile的主要作用在于确定每个lock lock i对应的传递队列状态。
矿工在执行的时候会根据counter构建锁LOCK-i的传递队列，比如ACTION-2拥有锁LOCK-i，然后ACTION-2执行完成，LOCK-i传递到了ACTION-3的手中，ACTION-3继续执行，因此对于每个LOCK-i可以构建一个传递队列，队列的元素是交易的标识符。为什么是交易而不是ACTION？因为一笔交易在合约嵌套的情况下可以产生多个ACTION，子ACTION执行完成后，会将其所拥有的锁返给父ACTION，即这些ACTION中的锁始终被一笔交易所拥有，且只有父ACTION成功提交后，子ACTION的状态变化才算是提交成功。可以理解为一笔交易中的所有ACTION是绑定在一起的，所以锁LOCK-i的传递队列中的元素是交易。
矿工会把所有锁的传递队列H放到区块中，广播给验证者。
Validator
当验证者接收到锁传递队列H时
如果矿工提交了一个假的锁传递队列fake-H，则该队列在运行效率上低于H但仍可正常工作，并发行为文章中所指出的那种不可避免的情况。
当矿工发送一个错误标记化的锁传递队列error-H时（即发送一个错误标记化的lock transfer queue labeled as error-H），那么验证者如何检测并识别这一异常情况呢？文中提到的方法是：验证者在处理交易时会记录每个锁的所有传递路径（即会记录每个lock的所有transfer paths），若这些路径与矿工声明的模式不一致（即若这些paths与mining operation所声明的行为模式不一致），则会拒绝接收该交易块（即thus reject the transaction block）。我认为这种做法存在不足之处：矿工可以通过模拟error-H运行一遍来获取所有锁的具体传递路径（即通过实际运行一次error-H来获取每一个lock的具体transfer paths），并据此自定义相应的行为模式（即 profile）；然后将这一自定义 profile 传输给验证者（即可将此customized profile sent to the validator）。
此外，在论文中涉及到了fork-join以及work-stealing方案的实现，并未能完全掌握它们各自的功能。
4 EVALUATION
主要评估两个方面：
- 给定的数据冲突数量，在线交易量上升的情况下会经历怎样的变化？预期分析表明，在线交易量增加的同时会使系统面临更高的并发压力；随着时间推移系统的并行化性能将不断改善直至受到硬件性能的限制；在这一过程中系统的运行效率不断提高；
- 当系统中的数据冲突次数增加时，在线交易量固定的条件下运行效率会经历怎样的变化？预期分析指出，在初始阶段当系统中的数据冲突次数较低时系统运行效率优于顺序处理方式；然而当系统中的数据冲突次数较多时由于事务处理失败率上升导致资源利用率下降最终可能导致整体运行效率低于顺序处理方式
结果：对于矿工而言，可以实现1.33x的提升；对于验证者而言，可以实现1.69x的提升。