当前位置: X-MOL 学术Distrib. Comput. › 论文详情
Our official English website, www.x-mol.net, welcomes your feedback! (Note: you will need to create a separate account there.)
Adding concurrency to smart contracts
Distributed Computing ( IF 1.3 ) Pub Date : 2019-07-06 , DOI: 10.1007/s00446-019-00357-z
Thomas Dickerson , Paul Gazzillo , Maurice Herlihy , Eric Koskinen

Modern cryptocurrency systems, such as the Ethereum project, permit complex financial transactions through scripts called smart contracts . These smart contracts are executed many, many times, always without real concurrency. First, all smart contracts are serially executed by miners before appending them to the blockchain. Later, those contracts are serially re-executed by validators to verify that the smart contracts were executed correctly by miners. Serial execution limits system throughput and fails to exploit today’s concurrent multicore and cluster architectures. Nevertheless, serial execution appears to be required: contracts share state, and contract programming languages have a serial semantics. This paper presents a novel way to permit miners and validators to execute smart contracts in parallel, based on techniques adapted from software transactional memory. Miners execute smart contracts speculatively in parallel, allowing non-conflicting contracts to proceed concurrently, and “discovering” a serializable concurrent schedule for a block’s transactions, This schedule is captured and encoded as a deterministic fork-join program used by validators to re-execute the miner’s parallel schedule deterministically but concurrently. We have proved that the validator’s execution is equivalent to miner’s execution. Smart contract benchmarks run on a JVM with ScalaSTM show that a speedup of 1.39 $$\times $$ × can be obtained for miners and 1.59 $$\times $$ × for validators with just three concurrent threads.

中文翻译:

为智能合约添加并发

现代加密货币系统,例如以太坊项目,允许通过称为智能合约的脚本进行复杂的金融交易。这些智能合约执行了很多很多次,总是没有真正的并发性。首先,所有智能合约在将它们附加到区块链之前由矿工连续执行。之后,这些合约由验证器连续重新执行,以验证矿工是否正确执行了智能合约。串行执行限制了系统吞吐量并且无法利用当今的并发多核和集群架构。然而,串行执行似乎是必需的:合约共享状态,合约编程语言具有串行语义。本文提出了一种允许矿工和验证器并行执行智能合约的新方法,基于改编自软件事务内存的技术。矿工推测性地并行执行智能合约,允许非冲突合约并发进行,并“发现”一个区块交易的可序列化并发调度,这个调度被捕获并编码为一个确定性的分叉连接程序,供验证者用来重新执行矿工的并行计划确定性但同时发生。我们已经证明验证者的执行等同于矿工的执行。在带有 ScalaSTM 的 JVM 上运行的智能合约基准测试表明,矿工可以获得 1.39 $$\times $$ × 的加速,只有三个并发线程的验证器可以获得 1.59 $$\times $$ × 的加速。并且“发现”一个区块交易的可序列化并发调度,这个调度被捕获并编码为一个确定性的分叉连接程序,验证者使用它来确定性但并发地重新执行矿工的并行调度。我们已经证明验证者的执行等同于矿工的执行。在带有 ScalaSTM 的 JVM 上运行的智能合约基准测试表明,矿工可以获得 1.39 $$\times $$ × 的加速,只有三个并发线程的验证器可以获得 1.59 $$\times $$ × 的加速。并“发现”一个区块交易的可序列化并发调度,这个调度被捕获并编码为一个确定性的分叉连接程序,验证者使用它来确定性但并发地重新执行矿工的并行调度。我们已经证明验证者的执行等同于矿工的执行。在带有 ScalaSTM 的 JVM 上运行的智能合约基准测试表明,矿工可以获得 1.39 $$\times $$ × 的加速,只有三个并发线程的验证器可以获得 1.59 $$\times $$ × 的加速。我们已经证明验证者的执行等同于矿工的执行。在带有 ScalaSTM 的 JVM 上运行的智能合约基准测试表明,矿工可以获得 1.39 $$\times $$ × 的加速,只有三个并发线程的验证器可以获得 1.59 $$\times $$ × 的加速。我们已经证明验证者的执行等同于矿工的执行。在带有 ScalaSTM 的 JVM 上运行的智能合约基准测试表明,矿工可以获得 1.39 $$\times $$ × 的加速,只有三个并发线程的验证器可以获得 1.59 $$\times $$ × 的加速。
更新日期:2019-07-06
down
wechat
bug