Efficient Concurrent Execution of Smart Contracts in Blockchains using Object-based Transactional Memory
本文提出了一种基于对象语义的智能合约事务(SCT)并发执行的有效框架,使用乐观的单版本基于对象的软件事务存储系统(SVOSTM)和多版本OSTM(MVOSTM)。在我们的框架中,一个多线程的矿工构造一个块图(BG),捕获SCT之间的对象冲突关系,并将其存储在块中。稍后,验证器根据这个BG并发地、确定性地重新执行相同的SCT。恶意矿工可以修改BG以损害区块链,例如,造成双重消费为了识别恶意矿工,我们提出了智能多线程验证器(SMV)。实验分析表明,所提出的多线程的矿工和验证器实现了显着的性能增益比国家的最先进的SCT执行框架。
2020-03-27 cs.DC
An Efficient Framework for Execution of Smart Contracts in Hyperledger Sawtooth
区块链技术是一种分布式、去中心化和不可变的账本系统。它是管理智能合约交易(SCT)的首选平台。智能合约是利益相关方之间的自动执行协议代码,通常使用区块链实现。一个区块包含一组代表系统变化的交易和前一个区块的哈希。SCT在整个网络的块生产和验证阶段期间被多次执行。在大多数区块链技术中,执行是顺序的。在这项工作中,我们将采用直接无环图(DAG)为基础的并行调度框架的并发执行的SCT。块的事务之间的依赖关系通过有助于吞吐量优化的并发DAG数据结构来表示。我们已经创建了一个DAG调度器模块,可以将其集成到区块链平台中,以便轻松地进行并发执行。我们还正式建立了DAG调度程序的安全性和活性属性。为了进行评估,我们的框架在Hyperledger Sawtooth V1.2.6中实现。针对各种调度器类型测量多个智能合约应用程序的性能。实验分析表明,该框架实现了显着的性能改善并行SCT执行框架。
2023-03-03 cs.DC
Mangrove: Fast and Parallelizable State Replication for Blockchains
Mangrove提出为每个智能合约使用独立共识实例的并行状态复制方案,通过并行乐观协议和拜占庭可靠广播,在乐观条件下实现2步通信延迟。
2025-09-08 cs.DC
Transactional Smart Contracts in Blockchain Systems
本文介绍了TXSC,这是一个为智能合约开发人员提供事务原语的框架。这些原语允许开发人员编写智能合约,而无需考虑由于并发智能合约函数执行而可能出现的异常。
2019-09-14 cs.DB cs.DC
Groundhog: Linearly-Scalable Smart Contracting via Commutative Transaction Semantics
本文提出 Groundhog 智能合约执行引擎,利用区块内无序交易、可交换语义和预留—提交机制消除争用,在 96 核上实现每秒逾 50 万笔支付交易。
2024-04-04 cs.DC
An Empirical Study of Speculative Concurrency in Ethereum Smart Contracts
我们使用历史数据来估计并行执行以太坊智能合约的投机技术的潜在好处。我们使用一个简单的推测执行引擎,随着时间的推移,从以太坊区块链中重放采样块的交易跟踪。在这个引擎中,矿工试图并行执行块中的所有事务,回滚那些导致数据冲突的事务。然后按顺序执行中止的事务。验证器执行与矿工相同的调度。我们发现,我们的推测性技术估计从2016年开始加速约8倍,到2017年底下降到约2倍,其中加速使用gas成本或指令计数来衡量。我们还观察到,一个小的合同集负责许多数据冲突所造成的投机并发执行。
2019-01-22 cs.DC
Anthemius: Efficient & Modular Block Assembly for Concurrent Execution
针对区块链并行执行受同资源交易冲突限制的问题,本文提出模块化区块构建算法 Anthemius,通过组装区块优化并发交易吞吐量,并在多类工作负载下使并行引擎处理能力提升逾两倍。
2025-02-14 cs.DC
Epoch-based Optimistic Concurrency Control in Geo-replicated Databases
University of Toronto(多伦多大学);Keio University(庆应义塾大学);Concordia University(康考迪亚大学)
本文提出 Minerva 系统,通过 epoch 基异步复制协议和冲突图算法,实现高并发可扩展的地理复制数据库,提升吞吐量和性能。
2026-03-16 cs.DB cs.DC
Utilizing Parallelism in Smart Contracts on Decentralized Blockchains by Taming Application-Inherent Conflicts
由于共识协议本身的瓶颈,传统的公共区块链系统通常具有非常有限的交易吞吐量。随着共识技术的最新进展,性能限制已经大大提高,通常达到每秒数千笔交易。这样一来,事务执行就成了一个新的性能瓶颈。利用事务执行中的并行性是解决此问题并进一步提高事务吞吐量的一种明确而直接的方法。尽管最近的一些文献引入了并发控制机制来并行执行智能合约交易,但它们所能实现的加速效果远不理想。主要原因是,所提出的并行执行机制不能有效地处理许多区块链应用程序中固有的冲突。在这项工作中,我们深入研究了以太坊中的历史交易执行痕迹。我们观察到,应用程序固有的冲突是限制可利用的并行执行过程中的主要因素。我们建议使用分区计数器和特殊的交换指令,打破应用程序的冲突链,以最大限度地提高潜在的加速比。当我们评估可实现的最大并行加速比时,这些技术将此限制加倍,与串行执行相比,总体加速比为18倍,从而接近最佳值。我们还提出了OCC-DA,一种具有确定性中止的乐观并发控制调度器,这使得在公共区块链设置中使用OCC调度成为可能。
2022-02-10 cs.DC
Static Application-Level Race Detection in STM Haskell using Contracts
编写并发程序是一项艰巨的任务,即使使用高级同步原语(如事务存储器)和具有良好控制副作用的函数式语言(如Haskell),因为进程之间产生的干扰可能发生在不同的级别,并且以非常微妙的方式发生。当线程将共享数据保留或公开为与应用程序逻辑或数据的真实含义不一致的状态时,就会出现问题。在本文中,我们建议将合同与交易相关联,并定义了一个程序转换,使得在STM Haskell的上下文中扩展静态合同检查成为可能。因此,我们能够静态地检查STM Haskell程序的每个事务处理共享数据的方式,即以用户定义的布尔函数的形式表示的给定一致性属性被保留。这确保了在并发程序的执行过程中不会发生不良干扰。
2013-12-10 cs.DC cs.LO cs.PL
Static Analysis for Detecting Transaction Conflicts in Ethereum Smart Contracts
本文提出一种静态分析方法,通过分析 Solidity 合约的状态变量访问模式检测交易对间的读-写、写-写和函数调用冲突,并在真实数据集上验证了高精确度,为提升验证者吞吐量和区块链可扩展性提供支持。
2025-07-22 cs.CR cs.DC
The Smart Contract Model
本文提出智能合约模型,用博弈论刻画跨链协议中可能拜占庭式的参与方,强调由合约而非参与方决定资产转移输出,以捕捉区块链与经典分布式计算的异同。
2025-02-07 cs.DC
The Singularity Theory of Concurrent Programs: A Topological Characterization and Detection of Deadlocks and Livelocks
该研究提出并发程序分析的奇点理论范式,通过分支拓扑空间建模程序执行,用代数拓扑不变量检测死锁与活锁,为并发验证提供新的拓扑基础。
2025-10-29 cs.DC cs.LO cs.PL
Slipstream: Ebb-and-Flow Consensus on a DAG with Fast Confirmation for UTXO Transactions
Slipstream是一种基于DAG的BFT共识协议,提供乐观和最终两种排序,支持快速UTXO交易确认,并在同步下三轮确认交易,创新解决双花问题。
2025-04-22 cs.DC cs.DS
Scaling Nakamoto Consensus to Thousands of Transactions per Second
本文介绍了Conflux,一个快速,可扩展和分散的区块链系统,它乐观地处理并发块,而不会丢弃任何分叉。Conflux共识协议将块之间的关系表示为直接非循环图,并在块的总顺序上实现共识。然后,Conflux从区块订单中确定性地导出交易总订单作为区块链分类账。我们在最多20 k个完整节点的Amazon EC2集群上评估了Conflux。Conflux实现了5.76GB/h的交易吞吐量,同时在4.5-7.4分钟内确认交易。对于典型的比特币交易,吞吐量相当于每秒6400笔交易。我们的研究结果还表明,当运行Conflux时,共识协议不再是吞吐量瓶颈。相反,瓶颈在于各个节点的处理能力。
2018-08-31 cs.DC
Concurrency Protocol Aiming at High Performance of Execution and Replay for Smart Contracts
虽然可编程智能合约的出现使得区块链系统可以轻松地涵盖更广泛的行业领域,但如何高效地执行智能合约成为当今的一大挑战。由于Byzantine节点的存在,智能合约的执行机制与数据库系统中的执行机制有很大的不同,使得现有成功的并发控制协议不能直接应用于数据库系统中。此外,尽管智能合约执行遵循两阶段风格,即矿工节点在第一阶段执行一批智能合约,验证者在第二阶段重放它们,但现有的并行解决方案只关注第一阶段的优化,而不包括第二阶段。在本文中,我们提出了一个新的有效的并发控制计划,这是第一个做优化的两个阶段。具体来说,(i)在第一阶段,我们给出了一个基于{ \em队列}特性的OCC(乐观并发控制)协议的变体,以提高矿工的并发执行效率,并为验证器生成具有高并行度的调度日志。此外,设计了一种图划分算法,将原始调度日志划分为小块,进一步降低通信成本;(ii)在第二阶段,我们给出了一个确定性OCC协议,可以在多核验证器上有效地重放所有智能合约,其中所有核都可以独立重放智能合约。理论分析和大量的实验结果表明,该方案优于国家的最先进的解决方案显着。
2019-05-17 cs.DB cs.DC
Adapting Persistent Data Structures for Concurrency and Speculation
这项工作统一了来自系统和函数式编程社区的见解,以实现对软件的组合推理,而软件在硬件中是可以有效实现的。它利用高效并发数据结构和高效不可变持久化数据结构的设计目标之间的对应关系,产生具有低争用和高效快照操作的可变并发树的新颖实现,以支持推测性执行模型。它还利用交换性来表征将传统的高性能并发数据结构集成到软件transmittance Memory(STM)运行时的设计空间,并扩展了这种技术,以产生一种用于并发执行所谓的“智能合约”(操纵区块链分类账状态的专用程序)的新算法。
2020-03-16 cs.DC cs.DS cs.PL
Batch-Schedule-Execute: On Optimizing Concurrent Deterministic Scheduling for Blockchains (Extended Version)
本文研究区块链中同一区块内交易冲突图上的最大并行度,提出严格可串行化的主动状态机复制框架和图调度概念,证明最小延迟调度问题NP难,并揭示其对现有并发方案的安全影响。
2024-08-19 cs.DB cs.DC
Bonded Recourse for Smart-Contract Settlement of Compensable Agent Side Effects
Max Planck Institute for Software Systems(马克斯·普朗克软件系统研究所);Research Institute for Cryptoeconomics, Vienna University of Economics and Business(维也纳经济与商业大学密码经济学研究所)
针对智能体行动失败后的残余损害问题,设计了智能合约结算协议Recourse,通过绑定行动相关要素并结合链上机制减少未补偿损害,已实现并验证其有效性。
2026-09-03 cs.CR cs.DC cs.MA
Conthereum: Concurrent Ethereum Optimized Transaction Scheduling for Multi-Core Execution
Conthereum 提出一种基于柔性作业车间调度问题的贪心启发式调度器,结合智能合约静态冲突分析,实现以太坊区块内交易的并发无冲突执行,在多核环境下显著提升吞吐量并优于现有并发方案。
2025-07-22 cs.CR cs.DC
Unleashing Multicore Strength for Efficient Execution of Transactions
针对区块链智能合约交易串行验证的性能瓶颈,提出含冲突检测、箱创建、执行三阶段的MBPS多核并行调度框架,在Hyperledger Sawtooth v1.2.6上验证显示性能优于现有方案,助力区块链扩展性与效率提升。
2024-10-29 cs.DC
On the Synchronization Power of Token Smart Contracts
现代区块链支持加密货币以外的各种分布式应用程序,包括智能合约-允许用户以分布式和分散的方式执行任意代码。无论其预期的应用如何,区块链平台都隐含地假设正确执行智能合约的共识,因此要求所有交易都是完全有序的。直到最近才认识到,共识对于防止加密货币的双重支出是不必要的(Guerraoui等人,#21019;,与一般人的看法相反。这个结果表明,当前的实现可能会牺牲效率和可伸缩性,因为它们比实际需要的更紧密地同步事务。在这项工作中,我们研究了以太坊ERC 20令牌合约的同步要求,ERC 20令牌合约是最广泛采用的智能联系人之一。也就是说,我们将智能合约令牌建模为并发对象,并分析其共识数作为同步功率的度量。我们发现,与标准加密货币相比,ERC 20代币支持的更丰富的方法集会导致严格的更强同步要求。更令人惊讶的是,ERC 20令牌的同步能力取决于对象的状态,因此可以通过方法调用进行修改。为了证明这一结果,我们开发了一个专用的框架来表达对象的状态如何影响所需的同步级别。我们的研究结果表明,ERC 20代币以及其他代币标准比普通加密货币更强大,更通用,并且受到动态要求的影响。开发利用这些动态需求的特定同步协议将为更强大和可扩展的区块链平台铺平道路。
2021-01-14 cs.CR cs.DC
SoK: Concurrency in Blockchain -- A Systematic Literature Review and the Unveiling of a Misconception
本文首次系统综述智能合约并发性,提出并发层次分类法并分析漏洞与对策,同时揭示一个主要研究类别中的错误并发假设,以纠正误解并指明未来研究方向。
2025-07-22 cs.CR cs.DC cs.PF
Ethereum Conflicts Graphed
本研究针对Ethereum智能合约交互与并行化潜力问题,通过追踪超200万个近期区块,分析交易分布、调用树结构等,发现冲突图多呈星型等结构特性,为性能优化提供支撑。
2025-07-29 cs.DB cs.DC
T-Watch: Towards Timed Execution of Private Transaction in Blockchains
针对区块链定时交易的隐私与成本问题,提出结合门限秘密共享和智能合约的T-Watch方案,支持隐私定时交易执行,通过双模式与请求池机制大幅降低成本,经测试验证可扩展性更优、成本降幅超90%。
2024-05-14 cs.CR cs.DC
Sui Lutris: A Blockchain Combining Broadcast and Consensus
Sui Lutris是结合无共识协议与高吞吐量共识的区块链平台,实现亚秒级最终性,兼具高表达力与吞吐量,还推出可证明安全的重配置协议,已在生产环境支撑Sui智能合约平台,性能显著优于现有共识系统。
2024-10-30 cs.CR cs.DC
Resume Means Resume: A Machine-Checked Conformance Contract for Checkpoint, Interrupt, and Resume Semantics in Workflow Persistence Layers
该研究提出了RESUME CONTRACT契约,用TLA+模型等方法验证了五个智能体工作流框架的一致性问题,并通过REMIT修复了相关故障。
2026-08-11 cs.DC cs.LG cs.LO
A Transactional Perspective on Execute-order-validate Blockchains
智能合约使区块链系统能够从简单的加密货币平台(如比特币)发展到一般的交易系统(如以太坊)。为了满足新兴的业务需求,Hyperledger Fabric中提出了一种名为execute-order-validate的新架构,以支持并行交易并提高区块链的吞吐量。但是,这种新的体系结构在序列化事务时可能会导致许多无效事务。这个问题被进一步夸大了,因为区块形成率由于数据处理之外的其他因素而固有地受到限制,例如密码学和共识。在这项工作中,我们提出了一种新的方法来增强执行顺序验证架构,通过减少无效交易来提高区块链的吞吐量。我们的方法的灵感来自现代数据库系统中最先进的乐观并发控制技术。与现有的采用数据库的预防方法(可能会中止可序列化的事务)的区块链相比,我们的方法在理论上更细粒度。具体地说,在排序之前中止不可序列化的事务,并且保证剩余的事务是可序列化的。为了进行评估,我们分别在两个区块链上实现了我们的方法,Hyperledger Fabric上的FabricSharp和FastFabric上的FastFabricSharp。我们比较了FabricSharp与vanilla Fabric和三个相关系统的性能,其中两个系统分别采用一种标准的和一种最先进的数据库并发控制技术来实现。结果表明,FabricSharp实现了25%的吞吐量相比,其他系统在几乎所有的实验方案。此外,FastFabricSharp…
2020-03-23 cs.DB cs.DC cs.PF