Hot switching transaction scheduling execution method for two-stage concurrent block chain

Abstract

The invention discloses a hot switching transaction scheduling execution method oriented to a two-stage concurrent block chain. The hot switching transaction scheduling execution method comprises hot switching scheduling based on load characteristics and a self-adaptive concurrent protocol oriented to hot switching. Firstly, based on a multi-arm bandit model, according to current load characteristics, a concurrency control protocol selected by execution nodes is dynamically switched; secondly, in order to realize hot switching of a concurrency control protocol, a multi-version data management and write intention mechanism is added on the basis of a traditional concurrency protocol: an execution node executes a transaction by using an optimistic concurrency protocol under the condition of low conflict load, and broadcasts a write intention that a write set is not submitted to other nodes; a pessimistic concurrency protocol is used to execute a transaction under a high conflict load condition, and whether a write intention of an unsubmitted block with a lower block height exists or not is checked in advance, so that the consistency of state data is prevented from being damaged by dirty reading. According to the method, fairness, high efficiency and self-adaptability of the block chain system are considered, the transaction abortion rate under the dynamic load is remarkably reduced, and the overall throughput of the system is improved.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular to a concurrent execution method on a public chain. Background Art

[0002] Blockchain, a distributed ledger technology, has recently gained widespread application in finance, supply chain management, the Internet of Things, and other fields due to its decentralized, tamper-proof, and traceable nature. With the rapid growth of blockchain users and increasing transaction processing demands, performance bottlenecks in traditional blockchain systems, such as transaction throughput and latency, have become increasingly prominent. To address this challenge, blockchain systems have become a key technology for improving system performance by distributing blocks of varying block heights across multiple execution nodes for concurrent processing. However, ensuring transaction determinism, consistency, and efficiency in a parallel execution environment remains a key challenge in the blockchain field.

[0003] In blockchain systems, the concurrent execution of transactions typically relies on multi-version concurrency control or lock-based concurrency control protocols to ensure data consistency and deterministic transaction execution. Optimistic concurrency control protocols effectively improve system throughput by allowing transactions to freely read and write data during execution and verifying consistency upon commit. However, this only works well in scenarios with low conflict loads. Under high conflict loads, optimistic protocols can lead to frequent transaction aborts and rollbacks, which in turn reduces system efficiency. In contrast, pessimistic concurrency control protocols, which prevent read-write conflicts by locking data items before execution, are more suitable for high-conflict scenarios. However, their locking mechanisms can introduce additional latency and resource overhead, limiting the system's concurrent performance. While these existing methods perform well under static single-load scenarios, real-world loads are constantly changing, and these limitations make it particularly difficult to adaptively balance system efficiency and consistency.

[0004] Although existing concurrency control protocols can effectively support parallel block execution in specific scenarios, their performance in dynamic load scenarios still has significant limitations. First, a single concurrency control protocol is difficult to adapt to changes in transaction conflict rates. For example, optimistic concurrency control can lead to a high transaction abort rate in high-conflict scenarios, while pessimistic concurrency control can reduce the overall concurrency of the system due to overly pessimistic locking mechanisms in low-conflict scenarios. Second, existing methods generally lack a mechanism for dynamically adjusting concurrency strategies and are unable to select the optimal protocol based on real-time load characteristics, resulting in insufficient system resource utilization. Furthermore, in a multi-node parallel execution environment, the coordination and consistency of protocol switching are also insufficient, which can easily lead to inconsistent states between execution nodes. All of these factors limit the throughput of blockchain systems in complex application scenarios.

[0005] Therefore, given the limitations of concurrency control protocols in existing blockchain systems under dynamic loads, there is an urgent need for a method that can adaptively switch concurrency strategies based on load characteristics, reduce transaction abort rates, and improve system throughput, while ensuring state consistency and determinism in a multi-node execution environment. Summary of the Invention

[0006] The purpose of the present invention is to overcome the limitations of concurrent control protocols in existing blockchain systems under dynamic load environments, and propose a hot-swap transaction scheduling and execution method for two-stage concurrent blockchains. Through hot-swap scheduling based on the multi-armed bandit model, the benefits brought by the currently selected protocol are dynamically evaluated according to the real-time load characteristics, and the concurrent control protocol with the highest expected future benefits is selected as the execution scheduling strategy for the execution node in subsequent blocks, which significantly improves the system throughput; through the hot-swap adaptive concurrent protocol, multi-version data management and write intent mechanism are introduced to avoid the state data consistency conflict caused by the mutual switching of traditional optimistic concurrent protocols and pessimistic concurrent protocols, and maintain the strict determinism of transaction execution. The present invention takes into account the fairness, efficiency and adaptability of the blockchain system, and is suitable for blockchain application scenarios under dynamic loads.

[0007] The specific technical solution for achieving the purpose of the present invention is:

[0008] A hot-swap transaction scheduling execution method for a two-stage concurrent blockchain, comprising: hot-swap scheduling based on load characteristics and an adaptive concurrent protocol for hot-swap; wherein,

[0009] The load-characteristics-based hot-swap scheduling uses a multi-armed bandit model to regularly update the expected returns of each concurrency strategy based on the recent historical conflict-free transaction ratio, dynamically select the concurrency protocol used by transactions executing subsequent blocks, and ensure that nodes that have not yet executed the next block consistently adopt the newly selected protocol through protocol version management and consensus mechanisms.

[0010] The hot-swap-oriented adaptive concurrency protocol maintains version numbers and write intent statements for ledger data items. This prevents read / write conflicts between transactions executed using a pessimistic concurrency protocol and uncommitted transactions using an optimistic concurrency protocol in scenarios where multiple blocks are executed concurrently.

[0011] The hot switching scheduling based on load characteristics specifically includes:

[0012] Step A1: The execution node periodically collects the execution results of the transaction and broadcasts the conflict re-execution rate along with the submission information to the master node. Based on the execution information returned by the execution node, the master node uses the multi-armed bandit model to dynamically estimate the future expected returns of different concurrency control protocols.

[0013] Step A2: Based on the evaluation results of the profit function, the concurrency control protocol with the best expected profit is selected as the default execution strategy for transactions in subsequent blocks. The master node generates a switch instruction and broadcasts it to all execution nodes. The switch decision is recorded in the block header submitted by consensus to ensure that the protocol update has a consistent effective block height.

[0014] The adaptive concurrent protocol for hot switching specifically includes:

[0015] Step B1: The master node maintains a transaction pool and continuously stores the transaction requests submitted by monitored users in the transaction pool. After packaging a batch of transactions from the transaction pool, it executes them concurrently to generate a proposal block. The current transaction execution order is then used as the global order and broadcast to the execution nodes along with the proposal block containing the execution results. The execution nodes then replay the transactions in order and verify whether the execution results are consistent with those of the master node.

[0016] Step B2: Executing nodes concurrently execute transactions according to the global order given by the master node. During transaction execution, the executing node declares its uncommitted write operations, forming write intent information, and broadcasts this information to other executing nodes during the execution process. Based on the read and write sets of each transaction, each node generates a data version snapshot during the execution period and maintains a read-write dependency graph locally to resolve the dirty read problem caused by the data version view when the pessimistic protocol is executed without the optimistic protocol during the hot switch process.

[0017] Step B3: During the concurrent execution of transactions by execution nodes, execution nodes currently using the optimistic concurrency control protocol will record the version snapshot of the initial read set during transaction execution and initiate a commit request after execution is complete. During the commit process, consistency verification is performed based on the previously recorded read set version snapshot. Only after verification is passed can the write set be committed and the data item version number be updated. If verification fails, the transaction is aborted and rolled back. Execution nodes currently using the pessimistic concurrency control protocol must check the local write intent state table before acquiring the read-write lock and can only continue execution after confirming that there is no conflict.

[0018] Furthermore, the step A1 specifically includes:

[0019] Step A11: Perform a scheduling decision update every fixed number of blocks, collect the conflict rate information of all concurrent transactions in the current round, and use it as the benefit update of the current round scheduling strategy;

[0020] Step A12: Combine the historical returns of each scheduling algorithm and the model's return update based on the transaction conflict rate of the current batch of transactions to dynamically update the estimated expected returns of each strategy in the multi-armed bandit model. The strategy with the highest return is used as the input for the next round of strategy selection.

[0021] Furthermore, the step A2 specifically includes:

[0022] Step A21: The system selects the theoretically optimal execution protocol for subsequent blocks based on the slot machine model and broadcasts the switching strategy to all execution nodes;

[0023] Step A22: The execution node that receives the broadcast updates the protocol version mapping table locally and determines the execution scheduling strategy for the newly entered block transactions accordingly. The newly joined execution nodes that have not received the broadcast are synchronized with the decision information in the submitted block header to ensure the consistency of the transaction execution scheduling strategy of each node that perceives the protocol switch.

[0024] Furthermore, the step B2 specifically includes:

[0025] Step B21: After receiving the proposed block broadcast by the master node, the execution node will concurrently execute transactions according to the global order attached to the broadcast. To ensure the subsequent hot switch from the optimistic concurrency protocol to the pessimistic concurrency protocol without downtime, each transaction declares its write intent in advance before execution. The write intent includes the target data item, expected version number, and write value information.

[0026] Step B22: The execution node broadcasts the write intent to other nodes in the network before the transaction is completed and committed. This allows these nodes to perceive the potential uncommitted write operations in real time in the pessimistic concurrency paths of subsequent rounds, thereby predicting and avoiding conflicts before locking.

[0027] Step B23: Each node registers the received write intent in a local "write intent status table" to subsequently determine whether there is a potential write conflict between different block transactions executed by each node. This table supports read version snapshot verification in the current optimistic execution phase and avoids dirty read problems caused by switching from optimistic concurrency to pessimistic concurrency.

[0028] Furthermore, the step B3 specifically includes:

[0029] Step B31: For the execution node currently using the optimistic concurrency control protocol, it builds an initial version snapshot of the required read set based on the current write intention state table and concurrently executes the transaction logic in a lock-free manner;

[0030] Step B32: For execution nodes currently using the optimistic concurrency control protocol, after the transaction is completed, it will enter the commit verification phase, and the current read set version will be verified for consistency based on the initial version snapshot of the read set. If the verification passes, the write set will be officially written to the ledger state and the corresponding data item version number will be updated. If the version verification fails, the write set of the transaction will be discarded and rolled back.

[0031] Step B33: For nodes currently using the pessimistic concurrency control protocol, before acquiring the target data item lock, they will first query the local write intent state table. If a write intent version conflict that has not yet been committed is detected, it will enter a waiting state to avoid damaging the transaction submission of uncommitted blocks with lower block heights that are being executed optimistically concurrently at the same time, thereby ensuring the monotonicity and determinism of state data access.

[0032] The beneficial effects of the present invention include:

[0033] The present invention provides a hot-swap transaction scheduling and execution method for a two-stage concurrent blockchain. The hot-swap scheduling based on load characteristics utilizes real-time conflict rate information to dynamically select the expected optimal concurrency control protocol when executing the transaction on the execution node, thereby improving the execution efficiency and throughput of the system under alternating high-conflict and low-conflict scenarios. At the same time, by introducing multi-version data management and write intent mechanisms for traditional optimistic and pessimistic concurrency control protocols, the state data consistency conflict problem caused by the hot-swap of the two in the concurrent execution of multiple blocks is effectively avoided. The present invention is based on the inherent determinism of the blockchain, taking into account the fairness, efficiency, and adaptability of the system. The method has demonstrated excellent adaptability and stability in theoretical scenarios such as financial transactions and supply chain management, can efficiently cope with dynamic load changes, and has certain practical value. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is the overall architecture diagram of the present invention;

[0035] Figure 2 This is an example diagram of the adaptive concurrent protocol for hot switching proposed by the present invention. DETAILED DESCRIPTION

[0036] The present invention is further described in detail with reference to the following specific examples and accompanying drawings. The processes, conditions, experimental methods, etc. for implementing the present invention, except for those specifically mentioned below, are common knowledge and common common sense in the art and are not particularly limited by the present invention.

[0037] The present invention discloses a hot-swap transaction scheduling and execution method for a two-stage concurrent blockchain. The method specifically includes two core contents: first, hot-swap scheduling based on a multi-armed bandit model dynamically selects the optimal concurrency control protocol according to real-time load characteristics, taking into account execution efficiency in low-conflict and high-conflict scenarios; second, an adaptive concurrency protocol for hot-switching is implemented, and multi-version data management and write intent mechanisms are introduced, which effectively avoids state data consistency conflicts caused by switching between traditional optimistic and pessimistic concurrency protocols, significantly improves system throughput, and ensures consistency of state data and certainty of transaction execution. Through a series of optimization schemes, the present invention can ensure the high consistency of blocks of execution nodes during protocol switching, greatly improving system throughput and resource utilization while enhancing the system's adaptability and reliability.

[0038] Figure 1 This is the overall architecture diagram of the hot-swap transaction scheduling and execution method for the two-stage concurrent blockchain proposed in this invention, which shows how the master node and the execution node can achieve efficient transaction processing through hot-swap scheduling and adaptive concurrent protocol in the scenario of changing load characteristics. Figure 1 , describes in detail the specific implementation of the present invention, covering the three main stages of transaction execution, conflict detection and protocol switching.

[0039] Transaction execution phase: Figure 1 As shown, (Step 1) the master node first packages a batch of transactions from the transaction pool as transactions for the current proposed block. After the transactions are executed, the execution order is used as the global transaction order for the current block. (Step 2) These transactions are finally encapsulated into a structured form (in this case, a directed acyclic graph) and distributed to each execution node along with the proposed block. Based on the strategy determined during the consensus phase, the execution node replays the block transactions broadcast by the master node using either an optimistic or pessimistic concurrency control protocol. (Steps 3 and 4) In low-contention scenarios, the execution node's scheduling controller executes transactions using an optimistic concurrency protocol. During this process, transactions record read-write sets and generate data snapshots during lock-free execution. They also broadcast their potential write operations to other nodes through write intent declarations, which are then written to the write intent cache in the multi-version storage. (Step 5) After execution completes, the version verification module of the optimistic concurrency execution checks the version consistency of the read set. (Step 6a) If verification passes, the data version is updated. (Step 6b) Otherwise, the transaction is aborted and retried.

[0040] Conflict Detection Phase: Based on the hot-swap scheduling process described in Algorithm 1, the conflict monitor on the execution node calculates the transaction conflict rate in real time as the current load feature to be extracted. (Algorithm 1, lines 1 to 5) In this phase, the conflict rate calculation module calculates the transaction abort ratio q and feeds the result back to the master node's policy decision maker. The policy decision maker calculates the benefit of using the i-th scheduling strategy in this round at a specific block height based on the received load information. , which is specifically expressed as,

[0041] (1)

[0042] in 、 and are preset parameter constants, (Algorithm 1, lines 10 to 13) At this time, the i-th scheduling is selected as the expected benefit of the next round of scheduling strategy Updated to,

[0043] (2)

[0044] in is the total number of times the current i-th scheduling strategy has been selected. The multi-armed bandit model is used to estimate the expected returns of optimistic and pessimistic concurrency protocols based on historical conflict rates and current load characteristics. The concurrency control protocol with the highest expected return Q in the next round is dynamically selected as the concurrency control protocol for subsequent execution by the execution node.

[0045]

[0046] Protocol Switching Phase: (Step 7) The master node includes its decision in the consensus phase along with the next round of blocks. When the load transitions from low-conflict to high-conflict, the execution nodes, in accordance with the consensus hot-switch decision, switch their local schedulers to pessimistic concurrency protocol mode. (Step 8) Before executing a transaction, the pessimistic execution unit uses write intent detection to query the local write intent cache to check for conflicts with write sets in uncommitted blocks. (Step 9) If there are no conflicts, the transaction acquires a read-write lock and executes in order. (Step 10) The data version is updated after submission. Throughout this process, the protocol switching decision is implemented through multi-version management and consensus mechanisms to ensure that all nodes consistently execute the new protocol at the specified block.

[0047] Figure 2 This is an example diagram of the adaptive concurrent protocol for hot switching proposed in this invention. It shows the execution process in a two-stage concurrent blockchain system when the adjacent block B1 executed in parallel adopts optimistic concurrency control and block B2 adopts pessimistic concurrency control, and further explains the collaborative mechanism of multi-version data management and write intent cache. Figure 2The pseudo code algorithm 2 is executed concurrently with the execution node, and the specific implementation of the present invention is described in detail, which covers three parts: optimistic concurrent execution, pessimistic concurrent execution and version management.

[0048] In the optimistic concurrent execution phase, such as Figure 2 As shown in Algorithm 2, block B1, which uses the optimistic concurrency protocol, first executes transactions according to the global transaction order assigned by the master node. (Algorithm 2, line 6) Given a transaction T1, it executes instructions in a lock-free manner, reads the current version v1 of data item X, and records the write set. (Algorithm 2, lines 8-14) A write intention is then generated, represented in the diagram as a tuple consisting of the target data item, target version number, and current version number. This tuple records the expected version change of the target data item X from v1 to v2. This is then broadcast to the write intention caches of the remaining nodes, and the post-read execution logic proceeds normally. After execution completes, transaction T1 verifies whether the version number of the current read set X is still the same as the version v1 read before execution. If the version remains unchanged, the verification passes, the write set is committed to the multi-version storage, the version of X is updated to v2, and the write intention is marked as "completed." If the verification fails, the transaction is aborted and re-executed.

[0049] In the pessimistic concurrent execution phase, such as Figure 2 As shown in Algorithm 2 (lines 18-20), block B2, which uses the pessimistic concurrency protocol, first queries its local write intent cache to detect any uncommitted transaction write intents related to data item X before executing transaction T2, which also requires reading data item X. Upon discovering that a write intent for data item X from transaction T1 in block B1 is in the "incomplete" state, T2 must wait for transaction T1 in B1 to successfully commit. After confirming that the write intent for data item X in T1 is in the "completed" state, T2 attempts to acquire a read lock on X and read the latest version of data item X, v2 (lines 21-24). T2 then executes instructions sequentially, releasing the read lock upon completion and committing the write set.

[0050] During the version management phase, multi-version storage maintains version records of data items (e.g., v1 and v2 of X), supporting optimistic and pessimistic version verification queries and updates. The write intent cache records the write intent of all uncommitted block transactions using the optimistic concurrency control protocol, ensuring that pessimistic execution nodes can detect potential read-write conflicts between different blocks before locking, avoiding uncommitted dirty reads and ensuring the eventual consistency of state data.

[0051] The protection content of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, changes and advantages that can be thought of by those skilled in the art are included in the present invention and are protected by the appended claims.

[0052]

Claims

1. A hot-swap transaction scheduling execution method for a two-stage concurrent blockchain, characterized in that: include: Hot switching scheduling based on load characteristics and adaptive concurrency protocol for hot switching; The load-characteristics-based hot-swap scheduling uses a multi-armed bandit model to regularly update the expected returns of each concurrency strategy based on the recent historical conflict-free transaction ratio, dynamically select the concurrency protocol used by transactions executing subsequent blocks, and ensure that nodes that have not yet executed the next block consistently adopt the newly selected protocol through protocol version management and consensus mechanisms. The adaptive concurrency protocol for hot switching maintains version numbers and write intent statements for ledger data items. This prevents read / write conflicts between transactions executed using a pessimistic concurrency protocol and uncommitted transactions using an optimistic concurrency protocol in scenarios where multiple blocks are executed concurrently. The hot switching scheduling based on load characteristics specifically includes: Step A1: The execution node periodically collects the execution results of the transaction and broadcasts the conflict re-execution rate along with the submission information to the master node. Based on the execution information returned by the execution node, the master node uses the multi-armed bandit model to dynamically estimate the future expected returns of different concurrency control protocols. Step A2: Based on the evaluation results of the profit function, the concurrency control protocol with the best expected profit is selected as the default execution strategy for transactions in subsequent blocks. The master node generates a switch instruction and broadcasts it to all execution nodes. The switch decision is recorded in the block header submitted by consensus to ensure that the protocol update has a consistent effective block height. The adaptive concurrent protocol for hot switching specifically includes: Step B1: The master node maintains a transaction pool and continuously stores the transaction requests submitted by monitored users in the transaction pool. After packaging a batch of transactions from the transaction pool, it executes them concurrently to generate a proposal block. The current transaction execution order is then used as the global order and broadcast to the execution nodes along with the proposal block containing the execution results. The execution nodes then replay the transactions in order and verify whether the execution results are consistent with those of the master node. Step B2: Executing nodes concurrently execute transactions according to the global order given by the master node. During transaction execution, the executing node declares its uncommitted write operations, forming write intent information, and broadcasts this information to other executing nodes during the execution process. Based on the read and write sets of each transaction, each node generates a data version snapshot during the execution period and maintains a read-write dependency graph locally to resolve the dirty read problem caused by the data version view when the pessimistic protocol is executed without the optimistic protocol during the hot switch process. Step B3: During the concurrent execution of transactions by execution nodes, for execution nodes currently using the optimistic concurrency control protocol, they will record the version snapshot of the initial read set during transaction execution and initiate a commit request after execution is completed. During the commit process, consistency verification is performed based on the previously recorded read set version snapshot. After the verification passes, the write set can be committed and the data item version number can be updated. If the verification fails, the transaction is aborted and rolled back. For execution nodes currently using the pessimistic concurrency control protocol, they need to check the local write intent state table before obtaining the read-write lock and can continue execution only after confirming that there is no conflict.

2. The hot-swap transaction scheduling execution method according to claim 1, characterized in that: The step A1 specifically includes: Step A11: Perform a scheduling decision update every fixed number of blocks, collect the conflict rate information of all concurrent transactions in the current round, and use it as the benefit update of the current round scheduling strategy; Step A12: Combine the historical returns of each scheduling algorithm and the model's return update based on the transaction conflict rate of the current batch of transactions to dynamically update the estimated expected returns of each strategy in the multi-armed bandit model. The strategy with the highest return is used as the input for the next round of strategy selection.

3. The hot-swap transaction scheduling execution method according to claim 1, wherein: The step A2 specifically includes: Step A21: The system selects the theoretically optimal execution protocol for subsequent blocks based on the slot machine model and broadcasts the switching strategy to all execution nodes; Step A22: The execution node that receives the broadcast updates the protocol version mapping table locally and determines the execution scheduling strategy for the newly entered block transactions accordingly. The newly joined execution nodes that have not received the broadcast are synchronized with the decision information in the submitted block header to ensure the consistency of the transaction execution scheduling strategy of each node that perceives the protocol switch.

4. The hot-swap transaction scheduling execution method according to claim 1, wherein: The step B2 specifically includes: Step B21: After receiving the proposed block broadcast by the master node, the execution node will concurrently execute transactions according to the global order attached to the broadcast. To ensure the subsequent hot switch from the optimistic concurrency protocol to the pessimistic concurrency protocol without downtime, each transaction declares its write intent in advance before execution. The write intent includes the target data item, expected version number, and write value information. Step B22: The execution node broadcasts the write intent to other nodes in the network before the transaction is completed and committed. This allows these nodes to perceive the potential uncommitted write operations in real time in the pessimistic concurrency paths of subsequent rounds, thereby predicting and avoiding conflicts before locking. Step B23: Each node registers the received write intent in a local "write intent state table" to subsequently determine whether there is a potential write conflict between different block transactions executed by each node. This table supports read version snapshot verification in the current optimistic execution phase and avoids dirty read problems caused by switching from optimistic concurrency to pessimistic concurrency.

5. The hot-swap transaction scheduling execution method according to claim 1, wherein: The step B3 specifically includes: Step B31: For the execution node currently using the optimistic concurrency control protocol, it builds an initial version snapshot of the required read set based on the current write intention state table and concurrently executes the transaction logic in a lock-free manner; Step B32: For execution nodes currently using the optimistic concurrency control protocol, after the transaction is completed, it will enter the commit verification phase, and the current read set version will be verified for consistency based on the initial version snapshot of the read set. If the verification passes, the write set will be officially written to the ledger state and the corresponding data item version number will be updated. If the version verification fails, the write set of the transaction will be discarded and rolled back. Step B33: For nodes currently using the pessimistic concurrency control protocol, before acquiring the target data item lock, they will first query the local write intent state table. If a write intent version conflict that has not yet been committed is detected, it will enter a waiting state to avoid damaging the transaction submission of uncommitted blocks with lower block heights that are being executed optimistically concurrently at the same time, thereby ensuring the monotonicity and determinism of state data access.

Images