A smart contract parallel execution conflict resolution method and system based on write hotness prediction

Abstract

The application discloses a smart contract parallel execution conflict resolution method and system based on write heat prediction, relates to the technical field of blockchain smart contract execution, and specifically comprises the following steps: acquiring an actual write set of historical successful transactions in the first preset number of confirmed blocks, and generating a write heat table recording the rewriting frequency of storage items; performing pre-execution on a to-be-scheduled transaction to obtain a predicted write set and determine a conflict probability; determining a dynamic threshold according to the number of to-be-processed transactions in a current transaction pool and the parallel execution conflict rate in the second preset number of confirmed blocks; dividing the to-be-scheduled transaction into a parallel group and a serial group according to the conflict probability and the dynamic threshold, and generating a conflict resolution scheduling plan for high-conflict to-be-scheduled transactions before execution. The application can shunt high-conflict transactions before execution, thereby reducing the rollback rate of parallel execution.

Description

Technical Field

[0001] This invention relates to the field of blockchain smart contract execution technology, specifically to a method and system for resolving conflicts in parallel execution of smart contracts based on write heat prediction. Background Technology

[0002] Blockchain systems execute and verify transactions within a block through multiple nodes to ensure consistent state transitions across different nodes for the same block. For blockchain systems supporting smart contracts, transaction execution involves not only basic state changes such as account balances and account serial numbers, but also read and write operations on on-chain states such as contract state variables, mapping items, array elements, and storage slots. With the increasing prevalence of applications such as decentralized finance, on-chain transaction matching, popular asset minting, and on-chain games, the number of smart contract transactions to be executed within a single block and the intensity of state access are constantly increasing. Transaction execution performance is gradually becoming a crucial factor affecting blockchain throughput.

[0003] Existing blockchain systems typically execute transactions within a block serially, meaning they call the smart contract virtual machine to execute each transaction in the block's order. While serial execution can relatively easily guarantee deterministic results, it struggles to fully utilize multi-core processor resources, limiting transaction throughput. To improve execution efficiency, existing solutions employ optimistic parallel execution, distributing multiple transactions within the same block to multiple execution threads. This initially assumes no conflicts between transactions and executes them in parallel. After execution, it checks for read-write set conflicts and rolls back and re-executes conflicting transactions.

[0004] However, in highly competitive scenarios such as decentralized finance (DeFi) trading, popular asset auctions, on-chain clearing, and transfers between popular accounts, a large number of transactions may frequently write to the same contract state item, such as the same liquidity pool reserve, the same auction status, the same account balance, the same counter, or the same mapping item. If it is still assumed that all transactions are suitable for parallel execution, a large number of transactions will experience read-write conflicts or write-write conflicts during the execution phase, leading to frequent rollbacks and repeated executions. This causes the overhead of parallel scheduling, conflict detection, and re-execution to offset the benefits of parallel execution.

[0005] Existing parallel execution schemes typically only detect conflicts during the execution phase. The scheduling phase relies more on transaction arrival order, transaction fees, intra-block order, or simple dependency analysis, lacking the ability to predict potential transaction conflict risks. Furthermore, on-chain historical transactions already contain a wealth of information about the frequency of state item writes, but existing schemes typically do not archive the write sets of successful historical transactions into reusable statistical metrics. This results in transactions with similar access patterns repeatedly undergoing conflict detection and rollback in subsequent blocks.

[0006] Therefore, this invention proposes a method and system for resolving conflicts in the parallel execution of smart contracts based on write heat prediction. Summary of the Invention

[0007] To address the shortcomings of existing technologies, the present invention aims to provide a method and system for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction.

[0008] To achieve the above objectives, the present invention provides the following technical solution:

[0009] A method for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction, characterized by comprising:

[0010] Obtain the actual write set of historical successful transactions within the most recent first preset number of confirmed blocks in the local ledger of the blockchain node. The storage items in the actual write set include contract addresses and storage keys.

[0011] Based on the number of times each storage item appears in the actual write set of each historical successful transaction, a write heat table is generated to record the rewrite frequency of each storage item.

[0012] Obtain a set of transactions to be packaged, including multiple transactions to be scheduled, pre-execute each transaction to be scheduled in an isolated pre-execution sandbox and collect state write actions to obtain the predicted write set of each transaction to be scheduled.

[0013] Based on the write heat table, query the rewrite frequency of each predicted write set storage item, and determine the conflict probability of each transaction to be scheduled based on the query results.

[0014] The dynamic threshold is determined based on the number of pending transactions in the current transaction pool and the proportion of parallel execution transactions that have been rolled back or re-executed due to conflicts within the most recent second preset number of confirmed blocks to the number of parallel execution transactions.

[0015] Based on the conflict probability and the dynamic threshold, the transactions to be scheduled are divided into parallel groups and serial groups, and a conflict resolution scheduling plan is generated. The conflict resolution scheduling plan is used to divert high-conflict transactions to be scheduled from the parallel batch before execution.

[0016] Further, obtaining the actual write set of historical successful transactions within the most recent first preset number of confirmed blocks in the local ledger of the blockchain node includes: determining the current confirmed block height of the local ledger of the blockchain node; using the current confirmed block height as the statistical endpoint, determining the first statistical interval formed by the most recent first preset number of confirmed blocks; traversing the transaction execution records of each confirmed block within the first statistical interval in block height order; filtering out failed transactions, rollback transactions, and transactions that have not formed state writes to obtain historical successful transactions; reading the state write information generated after the execution of each historical successful transaction, and determining the set of state items written in the state write information as the actual write set of the corresponding historical successful transaction.

[0017] Furthermore, based on the number of times each storage item appears in the actual write set of each historical successful transaction, a write heat table is generated to record the rewrite frequency of each storage item. This includes: identifying the status items corresponding to the same contract address and the same storage key as the same storage item; counting the total number of historical successful transactions within the first statistical interval; counting the number of times each storage item appears in the actual write set of each historical successful transaction to obtain the rewrite count of the storage item; determining the rewrite frequency of the storage item based on the ratio of the rewrite count to the total number of transactions; and writing the storage item, rewrite count, rewrite frequency, statistical interval height, table version identifier, and update time into the write heat table.

[0018] Furthermore, the write heat table is updated in a sliding window manner, including: when a new confirmed block is synchronized, adding the actual write set of historical successful transactions in the new confirmed block to the statistics window; removing the write set statistics corresponding to historical blocks that exceed the range of the most recent first preset number of confirmed blocks from the statistics window; redetermining the number of rewrites and rewrite frequency of each storage item based on the updated statistics window; when there are no historical successful transactions in the statistics window, using the previous version of the write heat table, or allocating the transactions to be scheduled to the serial group.

[0019] Furthermore, each scheduled transaction is pre-executed in an isolated pre-execution sandbox, and state write actions are collected to obtain a predicted write set for each scheduled transaction. This includes: creating a pre-execution sandbox isolated from the main execution environment based on the current blockchain state snapshot; pre-executing each scheduled transaction in the pre-execution sandbox and intercepting state write actions generated by each scheduled transaction during the pre-execution process; combining the contract address and storage key corresponding to each state write action into a storage item; deduplicating the storage items corresponding to the same scheduled transaction to obtain the predicted write set for the scheduled transaction; and identifying the scheduled transaction as a transaction with an unknown write set when the pre-execution of the scheduled transaction times out, is abnormal, or cannot obtain a predicted write set.

[0020] Further, based on the write heat table, the rewrite frequency of each storage item in the predicted write set is queried, and the conflict probability of each transaction to be scheduled is determined according to the query results, including: for each transaction to be scheduled, querying the write heat table for the rewrite frequency of each storage item in the predicted write set of the transaction to be scheduled; determining the highest rewrite frequency in the predicted write set as the conflict probability of the transaction to be scheduled; when the predicted write set is empty, determining the conflict probability of the transaction to be scheduled as the lowest conflict probability; when there is a storage item in the predicted write set that is not recorded in the write heat table, determining the rewrite frequency of that storage item as a preset default rewrite frequency; when the transaction to be scheduled is a transaction with an unknown write set, determining the transaction to be scheduled as a high-conflict transaction to be scheduled.

[0021] Further, determining the dynamic threshold includes: determining a transaction pool pressure index based on the number of pending transactions in the current transaction pool and a preset transaction pool reference capacity; determining a parallel execution conflict rate based on the number of parallel execution transactions that have been rolled back or re-executed due to conflicts within the most recent second preset number of confirmed blocks and the number of transactions participating in parallel execution; increasing the dynamic threshold when the transaction pool pressure index increases; decreasing the dynamic threshold when the parallel execution conflict rate increases; and limiting the adjusted threshold between a preset lower threshold and a preset upper threshold to obtain the dynamic threshold.

[0022] Further, based on the conflict probability and the dynamic threshold, the transactions to be scheduled are divided into parallel groups and serial groups, and a conflict resolution scheduling plan is generated, including: assigning a deterministic sequence number to each transaction to be scheduled in the transaction set to be packaged; identifying transactions to be scheduled with a conflict probability less than the dynamic threshold as low-conflict transactions to be scheduled, and adding them to the parallel group according to the deterministic sequence number; identifying transactions to be scheduled with a conflict probability greater than or equal to the dynamic threshold as high-conflict transactions to be scheduled, and adding them to the serial group according to the order in which they entered the transaction pool; and generating the conflict resolution scheduling plan based on the parallel group, the serial group, the deterministic sequence number, the write heat table version identifier, and the dynamic threshold.

[0023] Furthermore, the method also includes: sending the conflict resolution scheduling plan to a preset smart contract execution engine; executing the transactions to be scheduled in the parallel group in parallel through the smart contract execution engine, and performing version verification on the parallel execution results; when a residual read-write conflict or write-write conflict occurs in a transaction to be scheduled in the parallel group, re-executing the conflicting transaction to be scheduled or downgrading it to serial execution; executing the transactions to be scheduled in the serial group serially in a preset order through the smart contract execution engine; and generating block execution results based on the parallel group execution results, the serial group execution results, and the conflict records.

[0024] A system for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction, comprising:

[0025] The actual write set acquisition module is used to acquire the actual write set of historical successful transactions in the most recent first preset number of confirmed blocks in the local ledger of the blockchain node. The storage items in the actual write set include contract address and storage key.

[0026] The write heat table generation module is used to generate a write heat table that records the rewrite frequency of each storage item based on the number of times each storage item appears in the actual write set of each historical successful transaction.

[0027] The predictive write set extraction module is used to obtain a set of transactions to be packaged, including multiple transactions to be scheduled. It pre-executes each transaction to be scheduled in an isolated pre-execution sandbox and collects state write actions to obtain the predictive write set of each transaction to be scheduled.

[0028] The conflict probability determination module is used to query the rewrite frequency of each storage item in the predicted write set based on the write heat table, and determine the conflict probability of each transaction to be scheduled based on the query results.

[0029] The dynamic threshold determination module is used to determine the dynamic threshold based on the number of pending transactions in the current transaction pool and the proportion of parallel execution transactions that have been rolled back or re-executed due to conflicts within the most recent second preset number of confirmed blocks.

[0030] The scheduling plan generation module is used to divide the transactions to be scheduled into parallel groups and serial groups according to the conflict probability and the dynamic threshold, and generate a conflict resolution scheduling plan. The conflict resolution scheduling plan is used to divert high-conflict transactions to be scheduled from the parallel batch before execution.

[0031] The present invention has the following beneficial effects:

[0032] 1. This invention does not passively roll back only after a conflict occurs during parallel execution. Instead, it first uses the actual write set of historically successful transactions within the most recent first preset number of confirmed blocks to form a write heat table. Then, it uses the predicted write set of the transactions to be scheduled to query this write heat table, thereby identifying transactions that may be concentrated in hot storage items during the scheduling phase. This process transforms the state access patterns that have already appeared in historical blocks into the basis for current block scheduling, reducing the probability of highly competitive transactions blindly entering parallel batches.

[0033] 2. This invention combines a pre-execution sandbox, a write heat table, and a dynamic threshold to form a closed loop for predicting write sets, conflict risk, and group scheduling. The pre-execution sandbox provides state entries that transactions to be scheduled may write, the write heat table provides the historical rewrite intensity of these state entries, and the dynamic threshold adjusts the diversion scale based on transaction pool pressure and recent parallel execution conflict rate, thereby enabling the division of parallel groups and serial groups to change according to on-chain load and conflict situation.

[0034] 3. The present invention dynamically determines the threshold based on the number of pending transactions in the current transaction pool and the parallel execution conflict rate within the most recent second preset number of confirmed blocks. When the transaction pool pressure is high and the conflict rate is controllable, the parallelism is increased. When the conflict rate is high, the proportion of high-risk pending transactions entering the parallel group is reduced, thereby balancing throughput and rollback cost.

[0035] 4. This invention generates a conflict resolution scheduling plan for diverting high-conflict pending transactions before execution, so that high-conflict pending transactions are divided into serial groups before entering the parallel execution phase, thereby reducing the rollback frequency of the parallel execution phase from the source. Attached Figure Description

[0036] Figure 1 This is a flowchart illustrating a method for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction.

[0037] Figure 2 This is a schematic diagram of the heat table construction process provided in an embodiment of the present invention;

[0038] Figure 3 This is a schematic diagram of the architecture of a smart contract parallel execution conflict resolution system based on write popularity prediction. Detailed Implementation

[0039] Example 1:

[0040] Reference Figure 1 This embodiment provides a method for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction. This method can be applied to blockchain nodes that support smart contract execution, such as block producer nodes, verification nodes, execution nodes, or scheduling nodes with transaction pre-execution capabilities.

[0041] S1. The blockchain node obtains the actual write set of historical successful transactions within the most recent first preset number of confirmed blocks.

[0042] Blockchain nodes first read the current confirmed block height from their local ledger, and then, using the current confirmed block height as the statistical endpoint, determine the most recent first preset quantity. The first statistical interval is defined as a number of confirmed blocks. The first preset number represents the size of the historical block window used to build the write heat table, and is preset based on on-chain transaction volume, block production speed, and the rate of change in state access hotspots. If the current chain height is less than the first preset number, then the actual first statistical interval is defined as the confirmed blocks already existing in the local ledger.

[0043] Traverse the confirmed blocks within the first statistical interval in ascending order of block height, and read the transaction execution record from each confirmed block. The transaction execution record includes transaction receipts, state change logs, execution traces, virtual machine write operation logs, or node state database commit records. For each transaction, determine whether it is a historically successful transaction. A historically successful transaction is one that has been executed successfully and generated a valid state transition in the smart contract virtual machine or transaction execution environment; failed transactions, rolled-back transactions, and transactions that did not generate a state write due to insufficient fees or permission verification failures are not included in the statistical scope of this step.

[0044] In this embodiment, the actual write set is the collection of on-chain state items that were actually written or modified when historical successful transactions were executed and state changes were committed. Each storage item in the actual write set includes a contract address and a storage key. The contract address is used to identify the accessed smart contract account, and the storage key is used to identify the location information of a specific state variable, mapping item, array element, or storage slot under that contract account. The storage key is not a label artificially attached to the transaction, but rather a key in the smart contract state storage. The contract address and storage key together locate an on-chain state item that can be written to by a transaction.

[0045] When the underlying blockchain system's virtual machine can directly output transaction write sets, the blockchain nodes directly read these write sets as the actual write sets. When the underlying virtual machine does not directly output write sets, the blockchain nodes can generate actual write sets by intercepting the state database write interface. When a node only saves transaction receipts and not fine-grained state write records, the blockchain node can re-execute transactions within the first statistical interval on historical state snapshots to recover the actual write sets. Historical transactions whose actual write sets cannot be recovered are not included in the valid statistical sample.

[0046] S2. Generate a write heat table that records the rewrite frequency of each storage item based on the number of times each storage item appears in the actual write set of each historical successful transaction.

[0047] The system counts and analyzes the stored items appearing in the actual write set. A write frequency table records how frequently each stored item was modified by historical successful transactions within the first statistical interval. This table can be implemented using a key-value table, an in-memory cache combined with persistent logs, or a database index.

[0048] In this embodiment, each record in the write heat table may include a storage item, contract address, storage key, number of rewrites, rewrite frequency, statistical start block height, statistical end block height, table version identifier, and update time. The number of rewrites indicates how many historical successful transactions in the actual write set contain the storage item within the first statistical interval; the rewrite frequency indicates the empirical proportion of the storage item written by historical successful transactions; the table version identifier is used to identify the update round of the write heat table; the statistical start block height and statistical end block height are used to determine the historical block range corresponding to the table.

[0049] To count the number of times a storage item has been overwritten, the occurrences of each storage item in the actual write set of historical successful transactions within the first statistical interval are summed, and the number of times the storage item has been overwritten is determined according to the following formula:

[0050]

[0051] in, Indicates storage item The number of rewrites within the first statistical interval. This represents a storage item determined by both the contract address and the storage key. Indicates the first statistical interval. A collection of actual accounts of successful historical transactions. This indicates the sequence number of a historically successful transaction within the first statistical interval. This represents the total number of historically successful transactions within the first statistical interval. Indicates a pointer function, when a storage item... Belongs to the actual writing collection The value is 1 when the stored item is stored. Not a collection of actual writings The value is zero at that time.

[0052] After obtaining the number of rewrites, the ratio of the number of rewrites of the stored item to the total number of historical successful transactions within the first statistical interval is calculated, and the rewrite frequency of the stored item is calculated according to the following formula:

[0053]

[0054] in, Indicates storage item The rewrite frequency. The value ranges from zero to one, and is used to represent any historical successful transaction rewriting a storage item. The empirical probability.

[0055] When a storage item is frequently written to within the first statistical interval, its rewrite frequency is high, indicating that the storage item is a write hotspot. Conversely, when a storage item is written to less frequently, its rewrite frequency is low, indicating that the storage item has a low risk of write conflicts within the current statistical window. On-chain historical state write behavior is transformed into queryable and computable write hotspot data during the subsequent online scheduling phase.

[0056] In some embodiments, the write heat table is updated using a sliding window approach. When a new confirmed block is synchronized, the blockchain node adds the actual write set of historically successful transactions in that new confirmed block to the statistics window, and removes the write set statistics corresponding to the oldest block that is outside the range of the most recent first preset number of confirmed blocks from the statistics window. For storage items added to the statistics window, their rewrite count is increased; for storage items removed from the statistics window, their rewrite count is decreased. The rewrite frequency of each storage item is recalculated based on the updated statistics window. By updating using a sliding window, the write heat table can be adjusted according to changes in on-chain access hotspots, avoiding the influence of outdated historical data on current scheduling decisions.

[0057] In some embodiments, when on-chain hotspots change rapidly, time decay weights are set for historical write records at different block heights within the first statistical interval, and the decay rewrite frequency of storage items is determined according to the following formula:

[0058]

[0059] in, Indicates storage item The attenuation rewrite frequency, Indicates the attenuation coefficient. Indicates the block height at which the statistics end. Indicates the first The block height where the last successful transaction was recorded. Indicates the first A collection of actual accounts of successful historical transactions. Indicates the first The time decay weight corresponds to each historical successful transaction. This formula is used to give higher impact weight to write records that are closer to the current block height.

[0060] When the total number of historically successful transactions within the first statistical interval is zero, the write heat table maintenance logic does not perform division by zero, but continues to use the previous version of the write heat table, or allocates all transactions to be scheduled to the serial group to ensure correct execution. When a storage item does not have a statistical sample in the write heat table, the rewrite frequency of that storage item can be set to a preset default rewrite frequency in subsequent scheduling phases. The preset default rewrite frequency is set by the node based on the historical average conflict rate, the average rewrite frequency of low-frequency storage items, or a conservative scheduling strategy.

[0061] S3. Obtain a set of transactions to be packaged, including multiple transactions to be scheduled. Pre-execute each transaction to be scheduled in an isolated pre-execution sandbox and collect state write actions to obtain the predicted write set of each transaction to be scheduled.

[0062] The transaction set to be packaged is obtained from the transaction pool. The transaction pool is a memory queue or persistent queue in which nodes temporarily store transactions that have not yet been packaged into blocks or executed. The transaction set to be packaged includes multiple transactions to be scheduled, which are selected by the block producing node based on block capacity, transaction fees, transaction arrival time, transaction validity verification results or other deterministic rules, or read by the verification node from the block to be verified.

[0063] For each transaction to be scheduled in the set of transactions to be packaged, an isolated pre-execution sandbox is created. The pre-execution sandbox is a virtual machine execution environment isolated from the main execution environment. Its initial state is read from a snapshot of the current blockchain state, but its execution results are not committed to the main state database. The purpose of the pre-execution sandbox is to observe in advance the on-chain state items that the transaction to be scheduled may write.

[0064] The transactions to be scheduled are input into a pre-execution sandbox, where state write actions generated by the smart contract virtual machine are intercepted during the pre-execution process. State write actions can include contract storage writes, account balance writes, account sequence number updates, code or storage writes generated during contract creation, and other operations that change the on-chain state. For each state write action, the corresponding contract address and storage key are extracted and combined to form a storage item. If the same transaction to be scheduled writes to the same storage item multiple times during the pre-execution process, only one entry is retained to avoid amplifying the probability of conflicts due to repeated writes within the same transaction to be scheduled.

[0065] The pre-execution sandbox should use the same virtual machine version, contract bytecode, fee metering rules, state reading interface, and block context parameters as the main execution environment. For scheduled transactions that depend on block time, block height, caller address, or other context information, the pre-execution sandbox uses context parameters that are consistent with or deterministic of the block to be executed. For scheduled transactions that include cross-contract calls, the pre-execution sandbox continues to track state write actions generated during the cross-contract calls and incorporates them into the predicted write set of that scheduled transaction.

[0066] When a scheduled transaction times out, encounters an exception, depends on an undetermined state, triggers undetermined input, or cannot obtain a predicted write set in the pre-execution sandbox, the scheduled transaction is marked as a write set unknown transaction. For write set unknown transactions, they can be directly identified as high-conflict scheduled transactions and assigned to the serial group in subsequent scheduling, or a conservative conflict probability can be assigned when calculating the conflict probability. Preferably, to reduce the risk of rollback caused by unknown write set transactions entering the parallel group, write set unknown transactions are directly assigned to the serial group.

[0067] S4. Based on the write heat table, query the rewrite frequency of each predicted write set storage item, and determine the conflict probability of each transaction to be scheduled based on the query results.

[0068] In this embodiment, the conflict probability is an empirical conflict risk value used for scheduling decisions, estimated based on historical write activity to estimate the likelihood of conflict after the transaction to be scheduled enters the parallel batch. For each transaction to be scheduled in the set of transactions to be packaged, the maximum value of the rewrite frequency of each storage item in the predicted write set of the transaction to be scheduled is selected, and the conflict probability of the transaction to be scheduled is determined according to the following formula:

[0069]

[0070] in, Indicates transactions pending scheduling The probability of conflict, This represents any transaction to be scheduled within the set of transactions to be packaged. Indicates transactions pending scheduling The corresponding prediction write set, Represents the predictive write set Any storage item in, Indicates storage item The frequency of rewriting in the heat table.

[0071] The reason for using the maximum rewrite frequency as the conflict probability is that if a highly popular storage item exists in the predicted write set of a transaction to be scheduled, the risk of that transaction engaging in write-write or read-write conflicts with other transactions in the same parallel batch increases significantly. This calculation method does not require enumerating pairwise combinations among transactions to be scheduled, and can identify transactions containing hot storage items with low computational cost, making it suitable for quickly filtering a large number of transactions to be scheduled during the blockchain node scheduling phase.

[0072] For example, if the predicted write set of a transaction to be scheduled includes three storage items with rewrite frequencies of 0.02, 0.08, and 0.45, respectively, then the conflict probability of the transaction to be scheduled is 0.45. Even if two of the storage items have low activity, as long as the other storage item is a high-activity storage item, the transaction to be scheduled is still considered to have a high conflict risk.

[0073] To simultaneously consider the impact of the predicted write set size on conflict risk, the non-conflict probabilities of all storage items within the predicted write set are multiplied together, and the joint conflict probability of the transactions to be scheduled is determined according to the following formula:

[0074]

[0075] in, Indicates transactions pending scheduling The probability of joint conflict, This represents any transaction to be scheduled within the set of transactions to be packaged. This represents a chain reaction of the non-conflict probabilities corresponding to all storage items within the predicted write set. Indicates storage item Estimated probability of no hotspot write conflicts occurring.

[0076] When the predicted write set is empty, it indicates that the transaction to be scheduled did not generate any state write actions during the pre-execution process, and the conflict probability calculation logic can set its conflict probability to zero. For read-only transactions, write-write conflicts are usually not generated, but they may still be affected by writes from other transactions and thus cause read-write conflicts. In scenarios requiring more conservative handling, further judgment is made by combining read set popularity. For the main scheme of this embodiment, write popularity is used to prioritize the identification of high write contention storage items, thereby reducing write-write conflicts and rollbacks caused by hot writes.

[0077] When a storage item in the predicted write set does not appear in the write heat table, it means that the storage item has not been written by a historical successful transaction within the most recent first preset number of confirmed blocks, or the write heat table has not yet recorded the storage item. In this case, the rewrite frequency of the storage item can be set to the preset default rewrite frequency. The preset default rewrite frequency can be zero, the average rewrite frequency of low-frequency storage items, the value corresponding to the historical average conflict rate, or a higher value according to a conservative scheduling strategy.

[0078] S5. Determine the dynamic threshold based on the number of pending transactions in the current transaction pool and the proportion of parallel execution transactions that have been rolled back or re-executed due to conflicts within the most recent second preset number of confirmed blocks.

[0079] A dynamic threshold is used to determine whether a transaction to be scheduled enters the parallel group or the serial group. If the dynamic threshold is too high, more transactions to be scheduled will enter the parallel group, which is beneficial for improving parallelism, but may lead to a large number of rollbacks in high-conflict scenarios. If the dynamic threshold is too low, more transactions to be scheduled will enter the serial group, which is beneficial for reducing rollbacks, but may reduce the parallel acceleration effect. Therefore, this embodiment dynamically determines the threshold based on the number of transactions to be processed in the current transaction pool and the parallel execution conflict rate within the most recent second preset number of confirmed blocks. The second preset number represents the block window size used to calculate the recent parallel execution conflict rate, and can be the same as the first preset number or smaller than the first preset number to reflect recent conflict changes more quickly.

[0080] Read the number of pending transactions in the current transaction pool. The number of pending transactions reflects the current scheduling pressure on the node. Normalize the number of pending transactions in the current transaction pool and the preset reference capacity of the transaction pool, and determine the transaction pool pressure index according to the following formula:

[0081]

[0082] in, This indicates the trading pool's stress level. This indicates the number of pending transactions in the current transaction pool. This indicates the preset reference capacity of the transaction pool.

[0083] Further, retrieve the parallel execution statistics of the most recent second-preset number of confirmed blocks. Calculate the ratio of the number of parallel execution transactions that experienced rollbacks or conflict re-executions within the most recent second-preset number of confirmed blocks to the number of transactions participating in parallel execution, and determine the parallel execution conflict rate according to the following formula:

[0084]

[0085] in, Indicates the conflict rate during parallel execution. This indicates the number of concurrently executed transactions that have been rolled back or re-executed due to conflicts within the most recent second-preset number of confirmed blocks. This indicates the number of transactions that participated in parallel execution within the most recent second preset number of confirmed blocks.

[0086] when When the value is zero, it indicates that no parallel execution or no parallel execution samples have been recorded within the most recent second preset number of confirmed blocks. In this case, the dynamic threshold determination logic will... Set the default conflict rate. The default conflict rate can be set based on the system's historical average conflict rate, the type of application on the chain, or a conservative scheduling strategy.

[0087] After obtaining the transaction pool pressure index and parallel execution conflict rate, the base threshold, transaction pool pressure adjustment item, and conflict rate adjustment item are combined and limited. The dynamic threshold is determined according to the following formula:

[0088]

[0089] in, Indicates a dynamic threshold. Indicates the basic threshold. This represents the trading pool pressure adjustment coefficient. This indicates the trading pool's stress level. This represents the conflict rate adjustment coefficient. Indicates the conflict rate during parallel execution. This indicates the lower limit of the preset threshold. This indicates the upper limit of the preset threshold.

[0090] In some embodiments, the dynamic threshold can also be determined using segmented rules. For example, when the parallel execution conflict rate is higher than a first conflict rate threshold and the number of pending transactions is lower than a first transaction pool size threshold, the dynamic threshold is set to a low threshold; when the parallel execution conflict rate is higher than the first conflict rate threshold and the number of pending transactions is not lower than the first transaction pool size threshold, the dynamic threshold is set to an intermediate threshold; and when the parallel execution conflict rate is not higher than a second conflict rate threshold, the dynamic threshold is set to a high threshold. Segmented rules can reduce computational complexity and are suitable for resource-constrained node environments.

[0091] S6. Based on the conflict probability and dynamic threshold, divide the transactions to be scheduled into parallel groups and serial groups, and generate a conflict resolution scheduling plan.

[0092] The system receives the conflict probability and dynamic threshold of each transaction to be scheduled and assigns a deterministic sequence number to each transaction in the set of transactions to be packaged. The deterministic sequence number can be derived from the order of the transactions in the set of transactions to be packaged, the sorting result of the transaction hash value, the order of the transaction pool selection, or the sequence number within the block predetermined by the block production node.

[0093] For each transaction to be scheduled in the set of transactions to be packaged, the following judgment is performed: if the conflict probability of the transaction is less than the dynamic threshold, the transaction is identified as a low-conflict transaction and assigned to the parallel group; if the conflict probability of the transaction is greater than or equal to the dynamic threshold, the transaction is identified as a high-conflict transaction and assigned to the serial group. The parallel group is used to store transactions with a low predicted conflict risk, and the serial group is used to store transactions with a high predicted conflict risk.

[0094] A conflict resolution scheduling plan is generated based on parallel groups, serial groups, the deterministic sequence number of each transaction to be scheduled, the write heat table version identifier, and dynamic thresholds. This conflict resolution scheduling plan diverts high-conflict transactions from the parallel batches before the smart contract execution engine begins parallel execution, thereby reducing the contention for the same hot storage item between high-conflict and low-conflict transactions during the parallel execution phase.

[0095] In some embodiments, the conflict resolution scheduling plan includes a parallel group transaction list, a serial group transaction list, a deterministic sequence number of each transaction to be scheduled, a conflict probability of each transaction to be scheduled, a dynamic threshold, a write heat table version identifier, a statistical interval height, a scheduling generation time, and a scheduling plan verification value.

[0096] To ensure the determinism of block execution results, after generating the conflict resolution scheduling plan, the schedule plan checksum is written to the block header or block extension field. Upon receiving the block, the verification node recalculates the conflict resolution scheduling plan using its local write heat table and the block transaction set, and verifies whether the recalculated schedule plan checksum matches the checksum recorded in the block. If they match, the transaction is executed or verified according to the conflict resolution scheduling plan; if they do not match, a full-sequence execution fallback is triggered to ensure the correctness of the final state.

[0097] In this embodiment, the conflict resolution scheduling plan does not change the deterministic semantic order of the transactions to be scheduled. The conflict resolution scheduling plan records the deterministic sequence number of each transaction to be scheduled, and makes the final execution result equivalent to the result obtained by executing the set of transactions to be packaged sequentially according to the deterministic sequence number.

[0098] When different nodes have inconsistent write heat table versions, the write heat table version identifier and statistical interval height are included as part of the conflict resolution scheduling plan, and it is stipulated that only write heat tables that have reached the specified version can participate in the scheduling. If a node's local write heat table is missing or outdated, the node can either use the conflict resolution scheduling plan carried in the block or degrade to serial verification. This fallback mechanism ensures that even if there is a delay in write heat table synchronization, it will not affect the correctness of the blockchain state transition results.

[0099] S7. In some embodiments, the smart contract execution engine is driven to execute the scheduled transactions in accordance with the conflict resolution scheduling plan.

[0100] The conflict resolution schedule is delivered to a smart contract execution engine that supports optimistic parallel execution. The smart contract execution engine can employ versioned state, multi-version read / write verification, task queues, transactional memory, or other parallel execution mechanisms capable of detecting and handling conflicts. This embodiment does not limit the execution-time conflict detection algorithm; it only requires that the execution engine can receive the conflict resolution schedule and return the parallel execution results and residual conflict records.

[0101] For parallel groups, the smart contract execution engine distributes multiple pending transactions to multiple worker threads for execution. Each worker thread reads the state version and generates a write result when executing a pending transaction. After execution, the smart contract execution engine performs version checks on the transaction's read and write sets to determine if there are any read-write or write-write conflicts. If the transaction passes the check, its execution result enters the pending commit state; if the transaction fails the check, the smart contract execution engine either re-executes the transaction according to its own rules or returns the transaction to the execution control logic and degrades it to serial execution.

[0102] For serial groups, transactions are submitted to the smart contract execution engine for execution one by one in FIFO order or deterministic sequence number. Since the transactions to be scheduled in a serial group are predicted to have a high risk of conflict, their serial execution avoids frequent contention for hot storage items during the parallel execution phase. Serial groups can be executed after the parallel groups have finished executing, or they can be inserted between parallel execution windows according to the system's deterministic execution rules. As long as all nodes use the same conflict resolution scheduling plan and the same submission rules, the final state consistency is guaranteed.

[0103] In some embodiments, if the blockchain system requires strict preservation of the original order of the transaction set to be packaged, the transaction set can be divided into multiple consecutive segments based on high-conflict scheduled transactions. For low-conflict scheduled transaction segments between two adjacent high-conflict scheduled transactions, these segments are executed in parallel; when a high-conflict scheduled transaction is encountered, it is executed serially. This segmented scheduling method allows for the parallel acceleration of low-risk consecutive segments while maintaining the original sequential semantics.

[0104] Upon completion, the smart contract execution engine returns the execution result to the execution control logic. The execution result may include the execution status, resource consumption, state root, actual write set, actual read set, rollback count, conflict type, conflict storage item, and execution time for each transaction to be scheduled. Based on the parallel group execution results and the serial group execution results, a block execution result is generated and submitted to the consensus or verification process of the blockchain nodes.

[0105] S8. Update the write heat table and the statistical information on which the dynamic threshold is based based on the residual conflict records during the execution period.

[0106] Receive residual conflict records returned by the smart contract execution engine. Residual conflict records may include the transaction identifier where the conflict occurred, the conflict type, the conflicted storage item, the number of rollbacks, and the number of re-executions. Conflict types include read-write conflicts, write-write conflicts, and version verification failures.

[0107] The parallel execution conflict rate within the most recent second preset number of confirmed blocks is updated based on residual conflict records. For example, for each executed block, the number of transactions participating in parallel execution and the number of parallel execution transactions that were rolled back or re-executed due to conflicts are counted and added to the conflict rate statistics window. When a new block execution result is generated, the conflict statistics for that block are added to the window, and old statistics that exceed the range of the most recent second preset number of confirmed blocks are removed.

[0108] In some embodiments, if a storage item appears multiple times in the residual conflict record during execution, the storage item is added to a temporary hotspot set. Records in the temporary hotspot set may include the storage item, conflict count, height of the most recent conflicting block, and expiration height. During the next scheduling, if the predicted write set of the transaction to be scheduled contains a storage item from the temporary hotspot set, the system can increase the conflict probability of the transaction to be scheduled, or directly assign it to a serial group, even if the rewrite frequency of that storage item in the write heat table has not yet increased.

[0109] In some embodiments, to ensure that residual conflicts occurring during actual execution affect subsequent write activity prediction, the number of rewrites for conflicting storage items is corrected by feedback, and the corrected number of rewrites is determined according to the following formula:

[0110]

[0111] in, Indicates storage item The number of rewrites after correction This represents a storage item determined by both the contract address and the storage key. Indicates storage item The original number of rewrites in the historical statistics window; Indicates the conflict feedback weight, Indicates storage item The number of times a conflict storage item appears in the feedback statistics window.

[0112] When execution feedback records are missing, the smart contract execution engine does not return conflicting storage items, or the node does not enable feedback updates, the write heat table is updated only based on the historical write set sliding window, which does not affect the basic execution of the method in this embodiment. Feedback updates are a further optimization method, designed to enhance the solution's adaptability to sudden hotspots and actual conflicts during the execution period.

[0113] Example 2:

[0114] Reference Figure 3 This embodiment provides a smart contract parallel execution conflict resolution system based on write heat prediction. This system can be deployed inside a blockchain node or used as a scheduling component preceding the blockchain execution engine, working collaboratively with the blockchain ledger, transaction pool, and smart contract execution engine. The system includes an actual write set acquisition module, a write heat table generation module, a predicted write set extraction module, a conflict probability determination module, a dynamic threshold determination module, and a scheduling plan generation module.

[0115] The actual write set acquisition module connects to the blockchain ledger and is used to obtain the actual write sets of historical successful transactions within the most recent first preset number of confirmed blocks, with the current confirmed block height as the statistical endpoint. Historical successful transactions are those that have been executed and generated valid state writes. The storage items in the actual write set include the contract address and storage key. Transactions that failed to execute, were rolled back, or did not generate state writes are not included in the statistical sample by the actual write set acquisition module.

[0116] The write heat table generation module is connected to the actual write set acquisition module. It identifies state items corresponding to the same contract address and the same storage key as the same storage item, and counts the number of times each storage item appears in the actual write set of historical successful transactions, obtaining the rewrite count and rewrite frequency to generate the write heat table. The write heat table records the storage item, rewrite count, rewrite frequency, statistical interval height, and table version identifier. The write heat table generation module can also use a sliding window method to update the statistical results, allowing the write heat table to be updated as confirmed blocks are added.

[0117] The predictive write set extraction module connects to the transaction pool to obtain a set of transactions to be packaged, including multiple transactions awaiting scheduling. Based on a snapshot of the current blockchain state, it creates a pre-execution sandbox isolated from the main execution environment. Within the pre-execution sandbox, the module pre-executes each transaction, intercepts state write actions generated during pre-execution, combines the contract address and storage key corresponding to the state write actions into a storage item, and removes duplicate storage items for the same transaction to obtain the predictive write set. Transactions that time out, encounter errors, or cannot obtain a predictive write set are marked as transactions with unknown write sets.

[0118] The conflict probability determination module is connected to both the write heat table generation module and the predicted write set extraction module. It is used to query the rewrite frequency of storage items within each predicted write set based on the write heat table, and determine the conflict probability of each transaction to be scheduled based on the query results. The conflict probability is an empirical conflict risk value used for scheduling decisions. When there are storage items with high rewrite frequency in the predicted write set, the corresponding transaction to be scheduled is determined to have a high conflict risk. When a transaction to be scheduled is a transaction with an unknown write set, it is treated as a high-conflict transaction to be scheduled.

[0119] The dynamic threshold determination module determines a dynamic threshold based on the number of pending transactions in the current transaction pool and the parallel execution conflict rate within the most recent second preset number of confirmed blocks. The parallel execution conflict rate is determined by the number of parallel execution transactions that have been rolled back or re-executed due to conflicts, and the number of transactions participating in parallel execution. The dynamic threshold determination module adjusts the dynamic threshold positively based on the transaction pool pressure and negatively based on the parallel execution conflict rate, ensuring that the threshold is limited between a preset lower threshold and a preset upper threshold.

[0120] The scheduling plan generation module is connected to both the conflict probability determination module and the dynamic threshold determination module. It compares the conflict probability of each transaction to be scheduled with the dynamic threshold, assigns low-conflict transactions to a parallel group, and high-conflict transactions to a serial group, generating a conflict resolution scheduling plan. This plan includes the parallel group, the serial group, the deterministic sequence number of each transaction to be scheduled, the write heat table version identifier, and the dynamic threshold. It is used to divert high-conflict transactions from the parallel batches before execution. This scheduling plan can be delivered to the smart contract execution engine, enabling parallel execution and version verification of transactions in the parallel group, and ensuring that transactions in the serial group are executed in a preset order, guaranteeing that the final execution result meets the deterministic requirements of the blockchain nodes.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction, characterized in that, include: Obtain the actual write set of historical successful transactions within the most recent first preset number of confirmed blocks in the local ledger of the blockchain node. The storage items in the actual write set include contract addresses and storage keys. Based on the number of times each storage item appears in the actual write set of each historical successful transaction, a write heat table is generated to record the rewrite frequency of each storage item. Obtain a set of transactions to be packaged, including multiple transactions to be scheduled, pre-execute each transaction to be scheduled in an isolated pre-execution sandbox and collect state write actions to obtain the predicted write set of each transaction to be scheduled. Based on the write heat table, query the rewrite frequency of each predicted write set storage item, and determine the conflict probability of each transaction to be scheduled based on the query results. The dynamic threshold is determined based on the number of pending transactions in the current transaction pool and the proportion of parallel execution transactions that have been rolled back or re-executed due to conflicts within the most recent second preset number of confirmed blocks to the number of parallel execution transactions. Based on the conflict probability and the dynamic threshold, the transactions to be scheduled are divided into parallel groups and serial groups, and a conflict resolution scheduling plan is generated. The conflict resolution scheduling plan is used to divert high-conflict transactions to be scheduled from the parallel batch before execution.

2. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction as described in claim 1, characterized in that, The acquisition of the actual write set includes: taking the current confirmed block height of the blockchain node's local ledger as the statistical endpoint, determining the first statistical interval formed by the most recent first preset number of confirmed blocks; traversing the transaction execution records within the first statistical interval, filtering out failed transactions, rollback transactions, and transactions that have not formed state writes to obtain historical successful transactions; reading the state write information of historical successful transactions to obtain the corresponding actual write set.

3. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction according to claim 2, characterized in that, The generation of the write heat table includes: identifying the status items corresponding to the same contract address and the same storage key as the same storage item; calculating the total number of historical successful transactions within the first statistical interval and the number of times each storage item appears in each actual write set to obtain the rewrite count of each storage item; determining the rewrite frequency based on the ratio of the rewrite count to the total number of transactions; and writing the storage item, rewrite count, rewrite frequency, statistical interval height, table version identifier, and update time into the write heat table.

4. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction according to claim 3, characterized in that, The write heat table is updated using a sliding window method, including: adding the actual write set of historical successful transactions in newly synchronized confirmed blocks to the statistics window, removing the write set statistics corresponding to historical blocks that exceed the range of the most recent first preset number of confirmed blocks; redetermining the rewrite count and rewrite frequency of each storage item based on the updated statistics window; when there are no historical successful transactions in the statistics window, using the previous version of the write heat table or assigning the transactions to be scheduled to the serial group.

5. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction according to claim 1, characterized in that, In an isolated pre-execution sandbox, each scheduled transaction is pre-executed and state write actions are collected to obtain a predicted write set for each scheduled transaction. This includes: creating a pre-execution sandbox isolated from the main execution environment based on the current blockchain state snapshot; pre-executing each scheduled transaction in the pre-execution sandbox and intercepting state write actions; combining the contract address and storage key corresponding to each state write action into a storage item, and deduplicating the storage items corresponding to the same scheduled transaction to obtain a predicted write set; when pre-execution times out, an error occurs, or a predicted write set cannot be obtained, the corresponding scheduled transaction is determined as a transaction with an unknown write set.

6. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction according to claim 1, characterized in that, Determining the conflict probability includes: querying the rewrite frequency of storage items in the prediction write set of each transaction to be scheduled in the write heat table, and determining the highest rewrite frequency as the conflict probability of the corresponding transaction to be scheduled; when the prediction write set is empty, determining the conflict probability of the corresponding transaction to be scheduled as the lowest conflict probability; when there are storage items in the prediction write set that are not recorded in the write heat table, determining the rewrite frequency of the storage items as the preset default rewrite frequency; when the transaction to be scheduled is a transaction with an unknown write set, it is determined as a high-conflict transaction to be scheduled.

7. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction according to claim 1, characterized in that, Determining the dynamic threshold includes: determining the transaction pool pressure index based on the number of pending transactions in the current transaction pool and the preset transaction pool reference capacity; determining the parallel execution conflict rate based on the ratio of the number of parallel execution transactions that have been rolled back or re-executed due to conflicts within the most recent second preset number of confirmed blocks to the number of transactions participating in parallel execution; adjusting the dynamic threshold positively based on the transaction pool pressure index and negatively based on the parallel execution conflict rate; and limiting the adjusted threshold between the preset lower threshold and the preset upper threshold to obtain the dynamic threshold.

8. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction according to claim 1, characterized in that, Generate a conflict resolution scheduling plan, including: assigning a deterministic sequence number to each transaction to be scheduled; identifying transactions with a conflict probability less than a dynamic threshold as low-conflict transactions and adding them to the parallel group, and identifying transactions with a conflict probability greater than or equal to the dynamic threshold as high-conflict transactions and adding them to the serial group; and generating a conflict resolution scheduling plan based on the parallel group, serial group, deterministic sequence number, write heat table version identifier, and dynamic threshold.

9. The method for resolving conflicts in parallel execution of smart contracts based on write popularity prediction according to claim 8, characterized in that, The method further includes: sending the conflict resolution scheduling plan to the smart contract execution engine; executing and verifying the pending transactions in the parallel group through the execution engine, re-executing or downgrading the pending transactions that have residual read-write conflicts or write-write conflicts to serial execution; executing the pending transactions in the serial group serially through the engine, and generating block execution results based on the execution results and conflict records.

10. A system for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction, used to implement the method for resolving conflicts in the parallel execution of smart contracts based on write popularity prediction as described in any one of claims 1 to 9, characterized in that, include: The actual write set acquisition module is used to acquire the actual write set of historical successful transactions in the most recent first preset number of confirmed blocks in the local ledger of the blockchain node. The storage items in the actual write set include contract address and storage key. The write heat table generation module is used to generate a write heat table that records the rewrite frequency of each storage item based on the number of times each storage item appears in the actual write set of each historical successful transaction. The predictive write set extraction module is used to obtain a set of transactions to be packaged, including multiple transactions to be scheduled. It pre-executes each transaction to be scheduled in an isolated pre-execution sandbox and collects state write actions to obtain the predictive write set of each transaction to be scheduled. The conflict probability determination module is used to query the rewrite frequency of each storage item in the predicted write set based on the write heat table, and determine the conflict probability of each transaction to be scheduled based on the query results. The dynamic threshold determination module is used to determine the dynamic threshold based on the number of pending transactions in the current transaction pool and the proportion of parallel execution transactions that have been rolled back or re-executed due to conflicts within the most recent second preset number of confirmed blocks. The scheduling plan generation module is used to divide the transactions to be scheduled into parallel groups and serial groups according to the conflict probability and the dynamic threshold, and generate a conflict resolution scheduling plan. The conflict resolution scheduling plan is used to divert high-conflict transactions to be scheduled from the parallel batch before execution.

Images