RTChain: a real-time permissioned blockchain leveraging priority-based deterministic concurrency

1 Introduction

Blockchain, a distributed ledger (Ruan et al., 2021), has garnered significant attention and research due to its decentralization, traceability, and tamper-proof nature. Its application has evolved from cryptocurrencies (Nakamoto, 2008) to the deployment of a wide range of decentralized applications (Buterin, 2014; Androulaki et al., 2018) used in fields such as the Internet of Things (Wang et al., 2023) and supply chain (Helo and Shamsuzzoha, 2020). Decentralized applications are programs composed of smart contracts that are transparent, secure, verifiable, and cost effective. By deploying customized smart contracts on the blockchain, users can implement decentralized applications with specific functions according to different scenario requirements.

In many application scenarios, systems must handle tens of thousands of data requests with low latency. However, throughput and latency have been the main factors limiting the utilization of blockchain. In blockchain, one reason for low performance is that all nodes need to reach a consensus on the order of transaction execution to ensure consistent execution across all nodes. To improve the efficiency of consensus among nodes, Ouroboros Praos (David et al., 2018) has enhanced consensus algorithms to increase the consensus efficiency and security of blockchain systems, and the DumboBFT algorithm proposed in Dumbo (Guo et al., 2020) achieves tens of thousands of throughputs. Sequential execution of transactions is another reason for the low performance of blockchain. In BitCoin (Nakamoto, 2008) and Ethereum (Buterin, 2014), transactions are processed using a sequencing-first, execution-second, and verification-last approach. A consensus algorithm determines the order of execution, and then the transactions are executed serially in order. Hyperledger Fabric (Androulaki et al., 2018) improves on this by introducing an execute-first, sort-second, and verify-last approach, which allows for parallel execution of transactions during the execution phase. Although current blockchain systems have made specific improvements in throughput, none of them consider the time-sensitive nature of the transactions themselves, which prevents them from providing time-sensitive guarantees for applications in time-sensitive areas.

The primary characteristic of blockchain decentralization is full-node data replication (Nathan et al., 2019), where all nodes maintain complete block data. This not only bolsters the system’s security but also imposes performance constraints dictated by the capacity limit of each node. To harness the full potential of multiple nodes, Elastico (Luu et al., 2016) pioneers the introduction of sharding in the realm of blockchain technology, fragmenting transactions into nonoverlapping groups and delegating their execution to distinct committees. OmniLedger (Kokoris-Kogias et al., 2018) employs a verifiable random function algorithm to ensure the randomness of sharding and enhances ByzCoin to attain expeditious consensus. Rapidchain (Zamani et al., 2018) augments scalability and security constraints in sharding through cross-shard transaction validation techniques, thereby averting the need to broadcast transactions to the entire network. Monoxide (Wang and Wang, 2019) leverages regional asynchronous consensus to extend the blockchain and introduces the notion of final atomicity to mitigate the overhead associated with a two-stage commit mechanism.

These studies have improved the performance of blockchain to a certain extent and significantly contributed to the widespread adoption of decentralized applications across various industries. In areas such as the Internet of Things (Chen et al., 2024), supply chain (Vazquez Melendez et al., 2024), healthcare (Mohammed et al., 2024), and industrial control (Frikha et al., 2024), there are requirements for data to be anticounterfeit, tamper-proof, and traceable, and the emergence of blockchain has aptly met this need. However, these applications impose stringent time constraints on transactions, requiring them to be completed within predefined timeframes. Although current blockchain systems have made specific improvements in throughput, none of them consider the time-sensitive nature of the transactions themselves, which prevents them from providing time-sensitive guarantees for applications in these areas. This limitation restricts the use of decentralized applications in many scenarios with highly real-time requirements, making it an urgent challenge for current blockchain systems.

In the present study, we propose RTChain, a prototype for permissioned blockchains that supports real-time transactions and handles transactions through a priority-based scheme. The main idea is to allocate priorities to transactions based on the deadlines of real-time transactions and then execute transactions concurrently according to these priorities to ensure the timeliness of transactions. First, we have designed a priority assignment algorithm for scheduling nodes, which converts the deadline attributes of real-time transactions into priorities that reflect the urgency of the transactions, thereby controlling the processing flow of transactions within the system. Transactions with higher priorities will be packaged into transaction batches and sent to execution nodes first. Subsequently, we have developed a deterministic concurrency control algorithm for execution nodes based on transaction priorities. This approach allows for the concurrent execution of batches of transactions and ensures conflict resolution based on transaction priorities. Additionally, we have optimized the method for detecting transaction conflicts to enhance the system’s ability to handle real-time transactions.

In summary, the contributions of this study are as follows:

• We propose RTChain, a framework for a permissioned blockchain supporting real-time transactions, to meet the timeliness requirements of transaction execution. To the best of our knowledge, this is the first time that the timeliness characteristics of transactions are considered in permissioned blockchains.
• We presented a concurrency control algorithm for real-time transactions in permissioned blockchains. The submission of conflicting transactions in a pre-determined order of priorities is referred to as Priority-based Deterministic Concurrency Control (PDCC). Building upon this foundation, an Optimized Priority-based Deterministic Concurrency Control (OPDCC) is proposed, utilizing an address-based conflict detection table.
• Through performance evaluations, it has been verified that both PDCC and OPDCC exhibit superior performance in terms of the rate of missed deadlines across various metrics. Moreover, they maintain high levels of throughput and latency in their respective performances.

2 Related work

2.1 Blockchain transaction processing framework

Transaction processing involves the entire lifecycle of a transaction, so its framework is a hot topic in current research. In the Order-Execute (OE) framework (Nakamoto, 2008; Buterin, 2014), transactions are arranged in a determined order by consensus algorithms such as POW (Dwork and Naor, 1992) and POS (King and Nadal, 2012), and then the transactions are executed serially in each node according to the determined order. To address the problem of inefficiency of execution in serial execution, some scholars have improved on the OE framework.

Regarding the constraints of the OE framework, the Execute-Order (EO) framework Androulaki et al. (2018) significantly improves the throughput of the blockchain by executing transactions in parallel and using traditional crash-tolerant protocols (Paxos Lamberti et al., 2019; Raft Ongaro and Ousterhout, 2014) or Byzantine Fault Tolerance Protocols (PBFT Castro and Liskov, 2002) during ordering. EO frameworks do not consider conflicts between transactions, but rather sequences the transactions at the end. When conflicting transactions are aborted based on a determined order, the efficiency of Fabric’s execution will sharply decline, especially in cases of high conflict rates. Sharma et al. (2019) proposed Fabric++, which introduces transaction reordering technique in the sorting phase to reduce the aborting of transactions due to conflicts during validation, but still at the cost of aborting some of the transactions. On the basis of transaction reordering, FabricSharp (Ruan et al., 2020) aborts the unserializable transactions in advance, and guarantees serializability of the remaining transactions. Fabric-HT (Wu et al., 2023) considers intra-block and inter-block conflicts on the EO framework, and solves the intra-block conflicts by scheduling mechanism. And it detects the inter-block conflicts in advance, which effectively reduces the transaction conflicts, and improves the throughput of the system.

Among some enhanced frameworks, OXII framework (Amiri et al., 2019b) improves concurrency by sorting transactions before analyzing their dependency graphs and concurrently executing nonconflicting transactions during the execution phase. ACE Wüst et al. (2020) moves the execution phase of the transaction off-chain, and supports the execution of complex contracts through the scaling capacity of off-chain nodes. SOEF framework (Chen et al., 2021; Qi et al., 2023) supports inter-block parallelism and intra-block concurrency of transactions, which further improves the performance of the blockchain. Fang et al. (2021) introduce trusted hardware in the transaction execution phase to avoid duplicate execution of transactions between nodes. SlimChain (Xu et al., 2021) moves the execution phase and data storage of the transaction under the chain, and only performs the validation and sorting phases on the chain, which improves the blockchain’s storage and execution capacity. Peng et al. (2022) highlight the drawbacks of explicitly ordering transactions and propose the EV framework, which executes transactions concurrently based on implicit deterministic ordering, although it suffers from a high transaction abort rate. While these studies improve blockchain performance, they do not extend the types of transactions the blockchain can handle. Transactions are always committed in block units, limiting the timeliness of transaction commitment.

2.2 Blockchain concurrency control

To improve the throughput of blockchain, increasing the concurrency of transaction execution is a crucial direction. Some scholars propose leveraging traditional database concurrency control methods within the OE framework to execute transactions concurrently. Zhang and Zhang (2018) introduce multi-version transaction ordering, allowing miners to employ any concurrency control to achieve conflict serializability and verifying transactions in blocks using a deterministic concurrency approach during the validation phase. Saraph and Herlihy (2019) speculatively execute all transactions concurrently in the first phase and serially execute conflicting transactions in the second phase. Hyperledger Fabric (Androulaki et al., 2018) adopts an optimistic approach to execute transactions directly in parallel without considering conflicts, and then examining transaction conflicts during the sorting phase to abort them. ParBlockchain (Amiri et al., 2019b) records transaction dependencies using a transaction dependency graph, allowing conflict-free transactions to be executed concurrently. While transactions with dependencies need to wait for the completion of the transactions they depend on before execution. Nazha (Xiao et al., 2022) proposes an address-based dependency graph to capture conflicting transactions and establish a total order of transactions. In addition, SlimChain (Xu et al., 2021) supports two mainstream concurrency control methods, namely, optimistic concurrency control and serializable snapshot isolation. Lai (2021), Xia et al. (2023), and NeuChain Peng et al. (2022) adopt deterministic concurrency control to abort conflicting transactions violating serializability. Each node executes a set of transactions in a deterministic order, ultimately producing a consistent state across all nodes. Although these methods improve the execution efficiency of existing blockchains, they cannot be directly used when considering the execution of real-time transactions and require redesign.

Another approach involves the introduction of transactional memory techniques (Guerraoui and Kapalka, 2008) to execute transactions, such as single-version timestamp software transactional memory, multi-version timestamp software transactional memory (Anjana et al., 2019), and object-semantics-based software transactional memory (Anjana et al., 2021). By recording read-write conflicts, other validators can swiftly verify transactions concurrently during the execution phase. Based on software transactional memory, Dickerson et al. (2017) propose a method allowing miners and validators to speculatively execute smart contracts in parallel, enabling conflict-free contract concurrency. Fastblock (Li et al., 2021) introduces hardware transactional memory to process transactions concurrently without violating atomicity.

2.3 Real-time database

After decades of development, real-time databases have found applications in various industrial fields. The motivation of this work is the recognition that current blockchain technologies lack support for real-time transactions in these domains. In the real-time transaction scheduling, priority assignment is a critical strategy. The Earliest Deadline First (EDF) algorithm Abbott and Garcia-Molina (1989) is one such scheme that assigns priorities based on transaction deadlines. Liu and Layland (1973) note that EDF is a hybrid allocation algorithm where priority is inversely proportional to transaction deadlines. Abbott and Garcia-Molina (1992) test performance on the EDF scheduling strategy through simulations employing various concurrency control methods. Pang et al. (1995) address EDF’s bias towards long transactions by allocating virtual deadlines. However, EDF still assigns higher priority to transactions that have already exceeded their deadlines, which is detrimental to the execution of other transactions that have not yet exceeded their deadlines. Although concurrency control algorithms in real-time databases have undergone extensive development, these algorithms are not applicable to blockchain systems requiring Byzantine fault tolerance.

In a series of optimistic concurrency control algorithms, the Optimistic Broadcast Commit (OBC) algorithm (Haritsa et al., 1990) utilizes forward validation to detect conflicts. When conflicts arise, it directly commits the current detecting transaction and aborts all transactions conflicting with it. The Optimistic Sacrifice (OS) algorithm (Haritsa et al., 1992) improves upon the OBC algorithm by validating the set of transactions conflicting with the detecting transaction during detection. If a higher-priority transaction exists, the current transaction is aborted; otherwise, all transactions in the conflicting set are aborted. The optimistic wait algorithm (Lee and Son, 1993) enhances the OS algorithm by incorporating a priority-based waiting strategy. If a transaction detects higher-priority transactions in the conflicting set during the detection phase, it will wait until there are no higher-priority transactions in the conflicting set. Although concurrency control algorithms in real-time databases have undergone extensive development, these algorithms are not applicable to blockchain systems requiring Byzantine fault tolerance.

3 Background and motivation

Blockchain enables decentralized applications (Buterin, 2014) and offers a transparent, traceable, and tamper-proof (Amiri et al., 2019a) operational environment for a wide range of application scenarios, including IoT, supply chain, healthcare, and finance. However, current research primarily focuses on enhancing blockchain throughput and reducing latency, which can not satisfy the transaction timeliness requirements. However, existing real-time database concurrency control methods cannot be directly applied to the blockchain environment. Additionally, existing research lacks clear indicators to guide nodes to pack transactions and does not consider the real-time scheduling of transactions.

To illustrate the above limitations, let us consider creating a trusted real-time supply chain network, as discussed in the study (Helo and Shamsuzzoha, 2020). In supply chains, RFID and IoT technologies provide real-time information and data. Conversely, blockchain technology provides a series of immutable transactions. However, since these data types differ in timeliness, treating them equally without prioritization can significantly impact all parties.

Figure 1 illustrates a supply chain scenario centered on a manufacturer. Five participants are involved: suppliers, manufacturers, warehouses, sellers, and consumers. The information interactions of different participants are as follows. In P 1, the manufacturer orders raw materials from the raw material supplier, and the transaction to record the ordering information is T 1. In P 2, the supplier transports the materials to the manufacturer’s warehouse, and the real-time location obtained from the location sensor is noted as transaction T 2. In P 3, the manufacturer removes the materials from the warehouse and puts them into production, and in P 4, the manufacturer deposits the products in the warehouse, and the operations involving the recording of the raw materials and products are recorded as T 3, T 4. In P 5, the seller orders the product from the manufacturer, and the transaction to record the product ordering information is T 5. In P 6, the warehouse delivers the product to the seller, and the transportation of the product involves recording the temperature, humidity, and location information, which are recorded as transactions T 6, T 7, and T 8, respectively. In P 7, the consumer buys the product from the seller, and the transaction to record the product sales information is recorded as transaction T 9.

In constructing a unified view of the global supply chain, real-time tracking of information, including logistics, inventory, and the status of goods, is often essential. Transactions T 2, T 3, T 4, and T 8, which record inventory, logistics, and other critical data, require real-time updates and recording to enable real-time production control and route planning for transportation. Similarly, transactions T 1 and T 5, related to material procurement, typically have specific timeframes for completion. Conversely, T 6 and T 7 pertain to product status during transportation, often involving data for quality assurance (e.g., temperature and humidity), which should be recorded within a specified period. To meet the timeliness requirements for establishing a trustworthy real-time view of transactions within the global supply chain, it becomes essential to prioritize transactions such as T 2, T 3, T 4, and T 8 that necessitate real-time recording, given the limited processing capacity of the blockchain.

To address this issue, the blockchain must be capable of handling real-time transactions to meet distinct transaction timeliness requirements. First, transactions within the blockchain should include attributes that allow for the specification of time limits, and transaction scheduling should be based on these defined time limits. Second, transaction processing should ensure the prioritized execution of time-sensitive transactions. Given the performance demands of blockchain, transactions should be able to execute concurrently, requiring the design of concurrency control algorithms that consider transaction priority. Finally, the transaction processing framework should be systematically modified to meet the timeliness requirements of transactions and ensure their timely submission.

In the current study, we propose a new prototype for permissioned blockchains. It is capable of scheduling transactions by priority to satisfy timeliness and concurrency control based on priority to process transactions efficiently.

4 RTChain overview

4.1 Design goals

The design of RTChain needs to fulfill the following objectives:

• Meet the requirement for transaction timeliness. As mentioned previously, supporting time-sensitive transactions is crucial for the widespread adoption of blockchain systems in industry. Therefore, the primary objective of designing RTChain is to enable real-time transactions.
• Support the parallel execution of transactions between nodes. To fulfill the timeliness requirements and optimize system throughput, it is essential to enable various nodes to execute transactions concurrently. Simultaneously, transactions must be guaranteed to produce identical execution results across different nodes to maintain the overall system’s consistency.
• Enable concurrent execution of transactions within individual nodes. To fully utilize the hardware capabilities of nodes and enhance the processing power for real-time transactions, concurrent intranode transaction execution is employed. This necessitates the resolution of real-time transaction conflicts to guarantee that concurrent execution of intranode transactions adheres to serializability.

4.2 System architecture

To meet our design objectives, we define real-time transactions in RTChain, implement transaction priority assignments based on deadlines, and enforce concurrency control using priorities. Figure 2 illustrates the system architecture, comprising three types of interconnected nodes that communicate with each other through a network.

• Client( C ), which can execute a transaction or invoke a smart contract by sending a transaction request to the blockchain. In particular, the transactions initiated by the user client in RTChain are real-time. There is an expectation of the transaction completion time, and the system needs to meet this timeframe as much as possible.
• Scheduling Node( S ), unified scheduling of transactions, sent to the execution node. Scheduling node mainly accomplishes two tasks: receive transactions from the client and prioritize them according to the deadline; pack the collected transactions into batches according to the priority; and reach a consensus on the batch of transactions.
• Execution Nodes( E ) receive transaction batches from scheduling nodes and concurrently execute transactions to generate blocks. Execution nodes will keep the complete ledger and associate it with the state database.

To meet the timeliness requirements of transactions, the concept of real-time transactions will be introduced, as defined below:

Definition 1. For the transaction in RTChain, it will additionally include the deadline attribute and call it a real-time transaction, denoted as T = {r s ( T ), w s ( T ), d l T, t s T , h a s h ( T ), σ T. r s ( T )} is the read set of transaction T, w s ( T ) is the write set of transaction T, d l T is the deadline of transaction T, t s T is the timestamp when transaction T is generated, h a s h ( T ) is the hash value of transaction T, and σ T is the client’s signature for transaction T.

In RTChain, scheduling nodes prioritize real-time transactions based on their deadlines, ensuring scheduling follows transaction timeliness. Execution nodes determine the execution order of transactions based on transaction priorities to fulfill the timeliness requirements of transaction execution.

4.3 Workflow

According to the system architecture shown in Figure 2, the transaction process in RTChain consists of two primary phases, and the detailed process is shown in Figure 3.

4.4 Scheduling phase

The goal of scheduling node S is to meet the timeliness requirements of real-time transactions by targeting their scheduling. The scheduling node comprises a collection of nodes distributed across various locations, interconnected via a network.

Transaction Reception. When client C needs to initiate a transaction, it sends a transaction request message r e q u e s t ⟨ T , t s c ⟩ σ c to the scheduler node S, which it considers the primary node. T is the real-time transaction, t s c is the timestamp of the client initiating the request message, and the whole request message is signed with σ c. After receiving the transaction request r e q u e s t ⟨ T , t s c ⟩ σ c from C, the scheduling node S will check whether the signature σ c of the request is valid or not to ensure that the accepted transaction is legitimate (Figure 3, step ①). After verifying the signature of the request, S needs to broadcast the received request to all other scheduling nodes S j.

Priority Assignment. The scheduling node S, after receiving the request message r e q u e s t, has another task, which is to prioritize real-time transactions. Node S takes out the real-time transaction T from the request message and calculates the priority of the transaction p r i T according to Equation 1, where d l T is the deadline of T. For each scheduling node S.

p r i T = 1 d l T . (1)

Transaction Batch Generation. Scheduling node S packages the transactions in the locally maintained transaction set according to the priority, generates a transaction batch proposal p r o p o s e ⟨ h a s h _ s e t b a t c h i ⟩ σ s, and initiates the proposal to other scheduling node S j. h a s h _ s e t b a t c h i is the hash set of all transactions contained in the current transaction batch i, and σ s is the signature of the scheduling node S. After the consensus is reached, each scheduling node will maintain a copy of the transaction batch locally and send it to the execution node E (steps ② and ③ in Figure 3).

4.5 Execution phase

After the transaction batch has gone through the scheduling phase, it will enter the following execution phase.

Transaction Batch Execution. After the transaction batch is generated, the scheduling node S will send it to its associated execution node E. Execution node E will be responsible for the execution of all the transactions in the transaction batch (step ④ in Figure 3). Transactions are executed according to a priority-based deterministic concurrency control protocol. Execution node E updates the state database after the execution is completed and returns the execution result r e s p o n d ⟨ h a s h ( T ) ⟩ σ e to the client C (step ⑤ of Figure 3). σ e is the signature of execution node E.

Block Generation and Appending. Execution node E packs all the transactions in a transaction batch into a block after executing the transactions in the batch. The process of packing blocks is independent of each execution node. E will sign the hash of the block using the private key to obtain the ⟨ h a s h block ⟩ σ e (step ⑥ of Figure 3). To ensure the consistency of the generated blocks in all execution nodes, E needs to sign its own generated block hash and broadcast it to other execution nodes, and it also receives the block hash signature message from another execution node E j (step ⑦ of Figure 3). Each execution node will verify whether the received block hash is consistent with its own generated block hash, and when it collects a certain number of signature messages that are consistent with its block hash, it will append its generated block to the local ledger it maintains (Figure 3, step ⑧).

5 RTChain concurrency control

5.1 Overview

After the scheduling node generates a transaction batch, all transactions in the batch will be handed over to the execution node for completion. To ensure that the transactions are completed as much as possible within the expected timeframe, the execution efficiency of the transactions needs to be improved. Ideally, transactions are executed in parallel between nodes and concurrently within nodes.In addition, improving execution efficiency requires targeted execution of transactions, prioritizing the execution of high-priority transactions. To this end, the PDCC protocol is designed in RTChain to execute real-time transactions to ensure the consistency of execution results between execution nodes and to resolve intranode transaction conflicts.

The PDCC protocol uses an optimistic policy where transactions in the same batch are executed simultaneously and conflicts are detected later. The detection process will abort and restart the transaction based on the priority. The execution of the transaction is divided into the following phases:

• Execution phase: During this phase, the transaction is executed, holding a copy of the latest committed version of the key it accesses. Simultaneously, two sets of accessed keys are maintained: the read set (containing the keys read by the transaction) and the write set (containing the keys written by the transaction). Read and write operations are performed on temporary versions.
• Detection phase: Once the transaction’s execution is completed, it checks whether its operations on the key conflict with the operations of other transactions. Successful detection allows the transaction to proceed with the commit; otherwise, conflicts are resolved according to the appropriate rules.
• Commit phase: After completing the detection phase, all temporary versions of the transaction’s records are updated in the state database, marking the end of the transaction’s execution.

5.2 Priority-based deterministic concurrency control

Regarding concurrency control, the primary objective is to address data inconsistency issues arising from the contention for read and write resources among conflicting transactions. To achieve this goal, the PDCC protocol identifies conflicts between transactions through detection rules and subsequently identifies the transactions requiring abortion based on abortion rules.

Detection Rules for Transactions. To guarantee the serializability of transaction execution, it is crucial to identify conflicts between transactions using read–write conflict rules. Transactions within the same batch are ordered based on the real-time transaction priority. During the detection phase, if a transaction does not conflict with others, it proceeds to the commit phase. However, if a conflict arises, the conflicting transaction is aborted and restarted by the deterministic abort rule.

For transactions T i and T j in batch B (where i ≠ j), R S ( T ) denotes the read set of transaction T, W S ( T ) denotes the write set of transaction T, k e y is the key accessed by the transaction, C o n f l i c t ( T i , T j , k e y , x x ) denotes that there exists a conflict of type x x between transactions T i and T j on k e y, and x x stands for the three r w , w r , w w types of conflicts. To ensure the serializability of all the transactions in it, the following rule is adopted for conflict detection:

Rule 1 IF ∃ T i , T j ∈ B ∩ ∃ k e y ∈ R S ( T i ) ∩ ∃ k e y ∈ W S ( T j ) THEN C o n f l i c t ( T i , T j , k e y , r w )

When the read set of transaction T i contains the k e y, there is a read-write conflict between transaction T i and T j if the write set of transaction T j also contains the k e y.

Rule 2 IF ∃ T i , T j ∈ B ∩ ∃ k e y ∈ W S ( T i ) ∩ ∃ k e y ∈ R S ( T j ) THEN C o n f l i c t ( T i , T j , k e y , w r )

When the write set of transaction T i contains the k e y, there is a write-read conflict between transaction T i and T j if the read set of transaction T j also contains the k e y.

Rule 3 IF ∃ T i , T j ∈ B ∩ ∃ k e y ∈ W S ( T i ) ∩ ∃ k e y ∈ W S ( T j ) THEN C o n f l i c t ( T i , T j , k e y , w w )

When the write set of transaction T i contains the k e y, there is a write-write conflict between transaction T i and T j if the write set of transaction T j also contains the k e y.

Notably, to meet the transaction timeliness requirements, the PDCC protocol advances to the commit phase immediately upon completing transaction detection. This necessitates that the currently detected transaction has undergone conflict detection with all transactions in batch B to prevent any incorrect commitments. Thus, during the detection of transaction T i, the following comparisons are performed: T i’s read set is compared with the write sets of all transactions in batch B (Rule 1), and T i’s write set is compared with the read and write sets of all transactions in batch B (Rule 2 and Rule 3).

Deterministic Abort Rules. To ensure the consistency of concurrent execution results across all nodes, the execution order of conflicting transactions within a node needs to be considered. To this end, we propose a priority-based deterministic abort rule that guarantees all nodes use a consistent scheme to abort and restart the same transaction.

Let transactions T i and T j (where i ≠ j) in batch B are in the process of aborting a transaction: P r i ( T ) denotes the priority of transaction T; H a s h ( T ) denotes the hash value of transaction T; A b o r t ( T ) denotes aborting transaction T; and R e s t a r t ( T ) denotes restarting transaction T. Subsequently, the deterministic abort rule based on priority is as follows:

Rule 4 IF ∃ T i , T j ∈ B ∩ P r i ( T i ) > P r i ( T j ) THEN A b o r t ( T j ) ∩ R e s t a r t ( T j )

If transaction T i has a higher priority than T j, prepare to abort and restart T j.

Rule 5 IF ∃ T i , T j ∈ B ∩ P r i ( T j ) > P r i ( T i ) THEN A b o r t ( T i ) ∩ R e s t a r t ( T i )

If transaction T j has a higher priority than T i, prepare to abort and restart T i.

Rule 6 IF ∃ T i , T j ∈ B ∩ P r i ( T i ) = P r i ( T j ) IF H a s h ( T i ) > H a s h ( T j ) THEN A b o r t ( T j ) ∩ R e s t a r t ( T j ) IF H a s h ( T j ) > H a s h ( T i ) THEN A b o r t ( T i ) ∩ R e s t a r t ( T i )

If the priority of transaction T i is equal to T j, compare the hash values of T i and T j. If the hash value of T i is greater than that of T j, prepare to abort and restart T j; otherwise, prepare to abort and restart T i.

Algorithm 1 illustrates the PDCC protocol, following the above rules. The protocol takes two inputs: ① the transaction set T S of the transaction batch i from the scheduling node, and ② the latest stateful database snapshot D B i − 1 observed by the current execution node. Initially, the protocol checks for unexecuted transactions in the transaction set T S (line 1) and sets up R e s t a r t S e t for the transaction batch i (line 2). The protocol concurrently executes the transactions within the transaction set T S while recording their corresponding read set R S ( T ) and write set W S ( T ) for transaction T (lines 3–4). The protocol then waits for all transactions within the transaction set T S (line 5) and then performs conflict detection concurrently on these transactions (lines 6–21). This includes detecting write-read, write-write, and read-write conflicts between the read-write set of transaction T and those of other transactions. Detected conflicts result in pending aborting transactions being added to A b o r t S e t (lines 10–15). If transaction T is found in the abort transaction set, it is aborted and added to the restart transaction set R e s t a r t S e t (lines 16–17). Otherwise, the transactions in A b o r t S e t are aborted and added to the restart transaction set R e s t a r t S e t. Subsequently, transaction T is committed, and the state database is updated accordingly (lines 18–21). The protocol waits for all transaction detections in T S to complete (line 22) and assigns the transactions in the restart transaction set R e s t a r t S e t back to T S to be re-execution. If the R e s t a r t S e t is null, all transactions have completed execution (line 23).

Algorithm 1 PDCC Protocol.

Example 1. Assume that a batch of transactions to be executed is shown in Table 1, which contains the read and write sets and priorities for the six transactions in the batch.

TABLE 1. A batch of pending transactions.

In this example, let us consider how a batch of transactions is analyzed for concurrency control following the PDCC protocol. Once a transaction completes its execution phase, it proceeds to the detection phase. As per the information presented in Table 1, we can analyze the conflicts among the six transactions in the batch, resulting in the conflict relationships outlined in Table 2. Specifically, transactions T 1, T 2, and T 3 exhibit conflicts concerning k e y 1, while transactions T 4 and T 5 involve conflicts related to k e y 4. By contrast, transaction T 6 does not conflict with any other transaction. The specific conflict relationships are detailed in Table 2.

TABLE 2. Conflict analysis of transactions.

According to the PDCC protocol, the detection phase concurrently detects conflicts between these six transactions. Taking transaction T 1 as an example, it compares its read and write sets with T 2, T 3, T 4, T 5, and T 6, adhering to Rule 1, Rule 2, and Rule 3. The conflict relationships in Table 2 indicate that T 1 conflicts with T 2 and T 3. T 1 applies Rule 4, Rule 5, and Rule 6 to determine which conflicting transaction to abort. Given the priorities of T 1, T 2, and T 3 as 3, 4, and 2, respectively, T 1 will decide to abort itself. Similarly, Transaction T 2 will abort T 1 and T 3 during its detection process, and transaction T 3 will also abort itself. Since the detection of transactions occurs concurrently, a transaction may either abort on its own or be instructed to abort by other transactions. Nevertheless, the overall detection process and the final commitment of transactions are still intact. Transactions T 4 and T 5 conflict, and T 4 will be aborted. Transaction T 6, which does not conflict with other transactions, will be committed. Eventually, the first round of execution results for the batch of transactions, as shown in Table 3, can be summarized as follows: T 2, T 5, and T 6 are committed, whereas T 1, T 3, and T 4 are aborted. The above process continues, including the restart of aborted transactions, leading to the results of the second and third rounds of execution, as detailed in Table 3, until no more transactions are left to be aborted.

TABLE 3. The submission order of transactions.

5.3 Optimized PDCC

When detecting conflicts, the previously mentioned PDCC protocol requires comparing the transaction under examination with all other transactions in the worst-case scenario before it can be committed. We propose an optimized priority-based deterministic concurrency control to reduce the detection overhead. Instead of recording the set of transaction reads and writes in the execution phase, the priority and hash of the transaction that reads and writes to an address are recorded. This set is examined at detection time to determine whether the transaction conflicts with other transactions. Transactions only need to be compared with the priority of the most urgent transaction that reads or writes the same address, reducing detection consumption.

For transaction T i in batch B, R M ( k e y ) holds the maximum priority and its hash of the transaction that reads the address k e y, and W M ( k e y ) holds the maximum priority and its hash of the transaction that writes the address k e y. M ( k e y ) is used to represent R M ( k e y ) and W M ( k e y ), and S ( T i ) is used to represent R S ( T i ) and W S ( T i ). To ensure the serializability of all the transactions therein, the following rules will be adopted to detect and deterministically abort the transactions:

Rule 7 IF ∃ T i ∈ B ∩ ∃ k e y ∈ S ( T i ) ∩ M ( k e y ) . P r i > P r i ( T i ) THEN A b o r t ( T i ) ∩ R e s t a r t ( T i )

When the read set R S ( T i ) of transaction T i contains the address k e y and the priority in the write detection table W M ( k e y ) is greater than transaction T i, then T i has a read-write conflict with other transactions on the k e y, and transaction T i needs to abort. When the write set W S ( T i ) of transaction T i contains the address k e y and the priority in the write detection table W M ( k e y ) (read detection table R M ( k e y )) is greater than that of transaction T i, then there is a write-write conflict (write-read conflict) between T i and other transactions on the k e y, and transaction T i needs to abort.

Rule 8 IF ∃ T i ∈ B ∩ ∃ k e y ∈ S ( T i ) ∩ M ( k e y ) . P r i = P r i ( T i ) IF M ( k e y ) . H a s h > H a s h ( T ) THEN A b o r t ( T i ) ∩ R e s t a r t ( T i )

When the read set R S ( T i ) of transaction T i contains the address k e y, the priority in the write detection table W M ( k e y ) is equal to transaction T i. If the hash in the write detection table W M ( k e y ) is greater than transaction T i, then T i has a read/write conflict with other transactions on the k e y, and transaction T i needs to abort. When the write set W S ( T i ) of transaction T i contains the address k e y and the priority in the write detection table W M ( k e y ) (read detection table R M ( k e y )) is equal to transaction T i. If the hash in the write detection table W M ( k e y ) is greater than transaction T i, then T i has a write-write conflict (write-read conflict) with another transaction on the k e y, and transaction T i needs to abort.

Algorithm 2 is obtained from the preceding rules. Initially, the algorithm checks for unexecuted transactions in the transaction set T S (line 1). Algorithm 2 initializes the write detection table and read detection table W M and R M and sets up the restart transaction set R e s t a r t S e t for the transaction batch i (lines 2–3). Algorithm 2 concurrently executes the transactions within T S to collect the corresponding read set R S ( T ) and write set W S ( T ), recording the maximum priority of the transactions for write and read addresses along with their hashes in R M and W M (lines 4–9). The algorithm then awaits the completion of all transactions in set T S (line 10). The algorithm subsequently performs conflict detection concurrently for all transactions in T S (lines 11–20). This process includes iterating through the read set of transaction T to detect read-write conflicts with other transactions according to the detection abort rule (lines 11–14). Following the detection abort rule, it scans through the write set of transaction T to identify write-write and write-read conflicts with other transactions (lines 15–19). The algorithm then commits transaction T and updates it in the status database (line 20). Afterward, it waits for the completion of detection for all transactions in T S (line 21). Finally, the algorithm reassigns the transactions in the restart transaction set R e s t a r t S e t back to T S for re-execution. If the R e s t a r t S e t is null, all transactions have completed execution (line 22). h

Algorithm 2 OPDCC Protocol.

Example 2. The following example uses the transactions in Table 1 to illustrate how optimized detection and aborting are performed. The write-write conflict detection process and abort results for the batch of transactions are given, as shown in Figure 4. Each transaction’s write set will be traversed and compared with the write detection table W M. For write-write conflict detection T 1, it will traverse its write set. It only contains k e y 1, and then it compares with the maximum priority stored in W M for k e y 1. Since the priority of T 1 is 3, which is less than 4, T 1 is aborted in the detection. Similarly, T 2 traverses its write set and compares it with the value stored in the corresponding key in W M. At this time, the priority of T 2 is 4, which is equal to the priority of k e y 1 stored in W M, so it continues to compare with the hash corresponding to k e y 1. The hash is omitted in Figure 4, but for this batch of transactions, the priority and hash stored in k e y 1 in W M is that of transaction T 2. Therefore, due to the equal priority and equal hash, the write-write conflict detection of T 2 is completed, and there is no need to abort T 2. The detection of T 3, T 4, T 5, and T 6 is the same; only T 4 is aborted. Eventually, T 1 and T 4 are terminated, and several other transactions continue to detect write-read and read-write conflicts in this manner.

5.4 Proof of correctness

A correctness proof is given below to verify the correctness of the PDCC (OPDCC) protocol. The correctness proof is required to prove that the PDCC (OPDCC) protocol is correct, i.e., to show that the protocol’s scheduling of transactions is serializable and produces consistent results in all nodes. The basic idea is first to prove that the PDCC (OPDCC) protocol’s execution of all conflicting transactions in a batch is serializable in all nodes and produces consistent results in all nodes. Finally, it is proven that the execution of the PDCC (OPDCC) protocol in all nodes for all transactions in the batch is serializable, and the execution result is consistent. The following lemma is given and proved below:

For proof, the following definition of a transaction relationship in batch B is given:

Definition 2. The set of all the transactions contained in batch B is called transaction set, denoted as T S B = { T 1 , T 2 , … , T n }. T is the number of transactions contained in batch B, which contains n in total.

Definition 3. The set of all conflicting transactions contained in batch B is called the conflicting transaction set, denoted as C T S B = { T i } , ( C T S B ⊆ T S B ). Where, i ∈ { 1,2 , … , n }.

Definition 4. The set of all conflict-free transactions contained in batch B is called the conflict-free transaction set, denoted as U C T S B = { T j } , ( U C T S B ⊆ T S B ), and U C T S B ∪ C T S B = T S B where j ∈ { 1,2 , … , n }, and j ≠ i.

Lemma 1. For the set of conflicting transactions C T S B in batch B, the execution at all nodes is serializable.

Proof: For Algorithm 1, several conditions need to be considered when dealing with transactions T i and T i + 1 within the set C T S B. If T i reads keys written by T i + 1, Rule 1 is violated, necessitating the abortion and restart of one of the transactions. If T i writes keys also written by T i + 1, Rule 2 is not satisfied, and one of the transactions must be aborted and restarted. Furthermore, if a key written by T i is subsequently read by T i + 1, Rule 3 is breached, requiring one of the transactions to be aborted and restarted. Consequently, in all nodes, transactions T i and T i + 1 with conflicting operations must undergo a process where one is aborted and restarted to ensure serializability, regardless of the specific type of conflict leading to nonserializability.

For Algorithm 2, regarding transaction T i in the set C T S B, if it performs read or write operations on key and has the highest priority, it will be recorded in the read and write detection table and will not be overwritten by other transactions. According to Rule 7 and Rule 8, any conflicting transactions with T i, due to having lower priorities, will eventually be aborted and restarted to ensure serializability.

Thus, the execution of set C T S B in batch B in all nodes is serializable.

Lemma 2. For the conflicting transaction set C T S B in batch B, the execution result is the same in all nodes.

Proof: For Algorithm 1, transactions T i and T i + 1 in set C T S B: if read-write conflicts, write-write conflicts, or write-read conflicts occurs, according to Rules 1, 2, and 3, the conflicts of T i and T i + 1 will be detected, and one of the transaction must be aborted and restarted. The determination of aborting transactions is done by Rules 4, 5, and 6. Since the priority of a transaction is jointly determined by all nodes before the execution of the transaction and the transaction hash value is unique, the final aborted transaction is the one with a low priority among all nodes, regardless of the order of detection of the transactions. According to this abort rule, conflicting transactions in all nodes will be aborted and restarted in the predetermined order, thus producing consistent results.

For Algorithm 2, the priorities and hashes of conflicting transactions within the set C T S B are already determined. Consequently, the transaction with the highest priority will be committed, while the remaining transactions will be aborted and restarted. Thus, the execution result of set C T S B in batch B is the same for all nodes. By the above lemma, the following theorem is given to prove the correctness of the PDCC protocol.

Theorem 1. For a transaction set T S B in batch B, the execution of a transaction is serializable in all nodes, and the result of the execution of the transaction is the same.

Proof: For the transactions in U C T S B, their executions are concurrent. However, no conflict violates serializability, and it can be known that their executions satisfy serializability in all nodes, and the execution results are the same. Lemma 1 guarantees that the transactions of C T S B in batch B are serializable at all nodes. Lemma 2 guarantees that the execution result of the transaction C T S B in batch B is the same for all nodes. It follows that concurrent execution of transactions in U C T S B and C T S B in batch B at all nodes must be equivalent to serializing them in some order and updating them with the same result. Therefore, the execution of set T S B in batch B at all nodes is serializable, and the execution result is the same.

6 Experimental evaluation

In this section, we will experimentally demonstrate that RTChain effectively supports real-time transactions without significantly reducing system throughput. We will evaluate the performance of RTChain, examining transaction missing ratio, throughput, and latency.

6.1 Experimental setup

The experiments in this study were conducted on a PC with an 8-core, 16-thread, 3.20 GHz AMD Ryzen 7 5800H processor and 16 GB of DDR4 RAM. A Java-based prototype of RTChain was developed to simulate a blockchain environment with four nodes. All experiments were conducted five times to ensure the generalizability of the experimental results, and the average values were considered the final results.

Comparison Schemes. We will compare three schemes, one of which is a variant of NeuChain. Conversely, the other two are the foundational and optimized schemes of RTChain.

• Pri-Neu: This scheme is a variant of NeuChain, and it implements a deterministic concurrency control scheme in RTChain based on priority. Pri-Neu utilizes an address-based reservation table for conflict detection and directly aborts conflicting transactions.
• PDCC: This scheme is the basic version of RTChain’s priority-based deterministic concurrency control. PDCC employs a method that checks read and write sets and adopts an abort-and-restart policy for conflicting transactions, as detailed in Section 5.2.
• OPDCC: This scheme represents the optimized version of RTChain’s PDCC. OPDCC utilizes the inspection of address read–write tables for conflict detection and adopts an abort-and-restart policy for conflicting transactions, as detailed in Section 5.3.

Workloads. A SmallBank benchmark contract, written in Java, is utilized for evaluation and is also employed to assess Fabric++, FabricSharp, and NeuChain. The total number of accounts accessible for transactions is 20k, with 300k transactions generated. To vary the conflict rate of transactions, the account access follows a Zipfian distribution, where higher skew values result in increased transaction conflict rates.

6.2 Overall performance

To evaluate the overall performance of RTChain, we compared three scenarios. We obtained average values based on the transaction missing ratio, throughput, and corresponding latency measured in five experiments. Figure 5 presents the performance results regarding the compared schemes’ transaction missing ratio, throughput, and latency. These measurements were obtained when the system operated under moderate skewness and deadlines. Notably, the OPDCC scheme exhibits exceptional performance in transaction missing ratio, throughput, and latency compared with PDCC and Pri-Neu.

As shown in Figure 5a, OPDCC exhibits a lower missing ratio than the other two schemes. This is due to OPDCC’s address-based detection table approach and its restart strategy for aborted transactions, which can fully consider the time constraints of transactions to meet their deadlines. As shown in Figure 5b, in terms of throughput and latency, OPDCC exhibits higher throughput and lower latency than PDCC. OPDCC employs address-based detection, which consumes less time than PDCC’s read–write set detection approach. In contrast, compared with Pri-Neu, OPDCC also shows higher throughput and comparable latency. Combined with Figures 5a,b, this fully demonstrates the advantages of adopting a restart strategy for aborted transactions, i.e., ensuring a lower transaction missing ratio while keeping the performance in terms of throughput and latency as high as possible. As well as the advantages of the address-based detection approach in reducing the execution elapsed time, thus increasing the system throughput and reducing the transaction latency. In conclusion, OPDCC has excellent overall performance.

6.3 The impact of deadlines

In this experiment, we evaluated the performance of OPDCC, PDCC, and Pri-Neu for different cutoff ranges. Figure 6 reports the performance results for various aspects of the three comparison schemes for the range from 1 to 100 m at moderate skewness, and after that, the range is incremented incrementally by 50 m. Figure 6a illustrates the variation in the missing ratio, which consistently decreases as the transaction deadline range widens. Figures 6b,c displays the transaction throughput and latency. These figures show that changes in the deadline range have no discernible impact on system throughput or latency. In real-time transaction processing, the scheduling and execution processes must adhere to deadline requirements, but the efficiency of execution remains constant regardless of changes in the deadline range. Unlike throughput and latency, the transaction missing ratio is closely linked to the deadline range. As the deadline becomes more stringent, the likelihood of transactions exceeding the deadline increases, which explains the decreasing trend observed in Figure 6a. Notably, the PDCC scheme exhibits a higher transaction missing ratio when the deadline range is 1–100 m due to its read–write set detection approach and its latency of approximately 90 m.

6.4 The impact of conflict rate

In this series of experiments, we evaluated the impact of transaction conflict rates. The skewness controls the conflict rate, with larger skew values resulting in higher conflict rates. Skew ranges from 0.2 to 1.4 in increments of 0.2. Figure 7 illustrates the variations of the three scenarios in terms of transaction missing ratio, throughput, and latency under medium deadlines. Figure 7a depicts the variation of the transaction missing ratio with skewness. Due to its no-restart strategy, the Pri-Neu scheme exhibits an increasing missing ratio as skewness increases. In contrast, after OPDCC and PDCC reach the saturation point, Pri-Neu shows a lower missing ratio due to the no-restart strategy, which avoids waiting for the next batch of transactions. OPDCC and PDCC maintain a stable missing ratio in the early stages of skewness changes due to the restart strategy. However, the missing ratio increases after the conflict rate reaches the saturation point of OPDCC and PDCC’s processing capacity (skew = 1.0). Figure 7b presents the trend of throughput. Again, OPDCC and PDCC exhibit a certain degree of stability until they reach the saturation point of processing capacity and start to decline. At the same time, Pri-Neu shows a gradual decline due to the direct abort of transactions. Figure 7C demonstrates the latency trend, where OPDCC and PDCC similarly remain stable until they reach saturation. In contrast, Pri-Neu’s latency remains stable due to the direct abort of conflicting transactions.

6.5 The impact of transaction arrival rate

In this experiment, we observed the performance variation of RTChain by varying the transaction arrival rate. Figure 8 illustrates the variation of the three compared schemes in terms of transaction missing ratio, throughput, and latency at moderate skewness and deadline. Figure 8a shows the variation of the transaction missing ratio with the transaction arrival rate. As the transaction arrival rate increases, all three schemes reach a saturation point after a specific range of stabilization. During the stabilization phase, OPDCC remains optimal, followed by PDCC and Pri-Neu. Figure 8b shows the throughput variation with the transaction arrival rate. All three schemes exhibit an expected linear increase until stabilization. Again, OPDCC outperforms PDCC and Pri-Neu. Figure 8c illustrates the variation in latency performance. After a specific range of stabilization, latency starts to increase significantly. PDCC reaches saturation first, followed by OPDCC and Pri-Neu.

6.6 Latency analysis

To analyze RTChain’s performance in processing real-time transactions, we measured the latency incurred by each subphase in the transaction lifecycle. This experiment measured latency for skews of 0.2, 0.6, 1.0, and 1.4. Figure 9 displays the transaction delay in the sending and scheduling phases for different skews. Figure 9a illustrates the transaction sending elapsed time for the three schemes under various skewness levels. Notably, in a LAN environment, the sending delay of the transaction remains approximately 20 m. Figure 9b presents the elapsed time of the scheduling node in the scheduling phase. The vertical axis uses a logarithmic scale due to the significant difference in elapsed time in this phase for different skews. As skewness increases, the delay in this phase becomes abnormally high for OPDCC and PDCC schemes. This occurs because, as skewness increases, the conflict rate of transactions also rises. In OPDCC and PDCC, due to the restart scheme, the restarted transactions become more frequent, resulting in transactions of the later batches waiting longer times in the scheduling phase.

Figure 10 illustrates the latency variation at each stage on the execution node. Figure 10a shows that OPDCC and PDCC experience increased execution elapsed time as skewness rises. By contrast, Pri-Neu maintains stable performance. This phenomenon is attributed to the increasing conflict rate with higher skewness, leading to more restarted transactions and longer execution times for these transactions. In the detection phase, as shown in Figure 10b, the detection elapsed time for the OPDCC and PDCC schemes consistently decreases. With transactions being repeatedly restarted, the number of required detections reduces, gradually decreasing time consumption. In the commit phase, as shown in Figure 10c, the time consumed per individual transaction remains relatively constant for OPDCC and PDCC since they implement real-time commit. Conversely, Pri-Neu reduces time consumption due to the gradual reduction in committed transactions.

7 Conclusion

In the current study, we designed RTChain, a prototype for permissioned blockchains that supports real-time transactions. RTChain schedules and concurrently executes transactions by priority. Specifically, once a transaction arrives at the scheduling node of the blockchain, it is assigned a priority based on its deadline and packaged for execution by its priority. To ensure efficient transaction execution and timeliness, we have developed a priority-based concurrency control algorithm. Additionally, we have restructured the transaction processing framework to accommodate real-time transactions. Numerous experiments show that RTChain effectively meets the timeliness requirements of transactions while maintaining stable performance, even when deadlines and conflict rates vary. Comparative results demonstrate that RTChain excels in transaction miss ratio, throughput, and latency. Handling real-time transactions within the blockchain presents a valuable research challenge, and we are further considering the relationship between transaction timeliness and their value.

Generative AI statement

The author(s) declared that generative AI was not used in the creation of this manuscript.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Rohit Tanwar, Shri Mata Vaishno Devi University, India

Reviewed by: Xiaoding Wang, Fujian Normal University, China

Minal Shukla, Parul University, India