Lightweight migration fragmented block chain account scheduling method, device and processing system

Abstract

The invention provides a fragmented block chain account scheduling method and device for lightweight migration and a processing system, which are used for avoiding excessive migration through a specially designed migration sensing partition mechanism and a transaction sensing type lightweight account migration mechanism in a fragmented block chain application scene aiming at the condition that two parties of a transaction request relate to different fragments, so that the transaction efficiency is improved. The problem that the partitioning result is not matched with the actual performance is solved for the first time, the burden on the chain is remarkably reduced, the throughput and delay are remarkably improved, and therefore the efficient account scheduling effect of the fragmented block chain of lightweight migration is achieved, and good application prospects are achieved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to a lightweight migration method, apparatus, and processing system for sharded blockchain account scheduling. Background Technology

[0002] Blockchain technology, with its decentralized and immutable characteristics, has been widely used in many fields. However, its limited processing efficiency remains a key bottleneck.

[0003] Among existing scaling solutions, sharding is considered one of the most direct and effective solutions. By dividing the network into multiple independent consensus committees and distributing accounts across different shards, sharding enables parallel processing of transactions, thereby significantly improving system performance. However, sharding also brings new challenges.

[0004] In a sharded blockchain system based on an account model, a transaction typically involves changes to the state of both the sender's and receiver's accounts. When these two accounts are distributed across different shards, additional cross-shard coordination is required to ensure consistency in account state updates across shards and complete transaction execution. As the number of shards increases, the proportion of cross-shard transactions will rise significantly when accounts are randomly assigned.

[0005] Furthermore, due to significant differences in activity levels among different accounts, some shards may aggregate a large number of high-frequency trading accounts, resulting in these shards processing far more trading volumes than other shards.

[0006] To address these challenges, Account Shuffling technology has emerged. This technology effectively reduces cross-shard interactions and optimizes workload balancing by dynamically adjusting the shard allocation of accounts. It comprises two core modules: partitioning and migration. Logically, the system reallocates shards for each account based on transaction patterns and system load. Physically, it seamlessly migrates the account status from the original shard to the newly allocated shard according to the updated partitioning scheme.

[0007] The inventors of this application have discovered that existing sharded blockchain technology still has the following problems in account scheduling: 1) Current account partitioning methods fail to adequately consider migration costs. Most existing sharding account partitioning schemes focus on reducing the proportion of cross-shard transactions and balancing shard workloads, but these methods often ignore migration costs (i.e., the workload generated by transferring account states across shards after the system makes a partitioning decision). Ignoring migration costs may lead to frequent and unnecessary account migrations, making it difficult to achieve the expected performance improvements in actual deployments.

[0008] 2) High account migration costs constrain the effectiveness of the scheduling mechanism. Account migration is a key step in realizing the performance advantages of the scheduling mechanism. Existing methods typically implement migration operations as special cross-shard transactions. This process includes initiating migration requests, verifying state proofs to create accounts, and broadcasting state updates. All of these operations are submitted to the chain as transactions, which not only significantly increases the on-chain workload of the system but also reduces the throughput efficiency of regular transactions. Summary of the Invention

[0009] This application provides a lightweight migration method, apparatus, and processing system for sharded blockchain account scheduling. In sharded blockchain application scenarios, when both parties in a transaction request involve different shards, a specially designed migration-aware partitioning mechanism and a transaction-aware lightweight account migration mechanism are used to avoid over-migration. This solves for the first time the problem of "partitioning results not matching actual performance," significantly reducing on-chain burden and significantly improving throughput and latency. Thus, it achieves efficient account scheduling in sharded blockchains with lightweight migration and has promising application prospects.

[0010] Firstly, this application provides a lightweight migration method for scheduling sharded blockchain accounts, the method comprising: Get the user transaction requests that are currently waiting to be processed by the blockchain sharding network; Check whether the current time meets the preset cycle start time condition, where the cycle start time condition is used to indicate the trigger time for the start of the current cycle of account scheduling or transaction processing; If so, the transaction request is processed under the sharded blockchain account scheduling mechanism, wherein the sharded blockchain network includes The sharded blockchain account scheduling mechanism, consisting of one executor shard and one coordinator shard, includes the following processing: In the first phase, the nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the rumor protocol to synchronize the pending transactions and the latest status of all shards. Among them, account partitioning is performed under the migration-aware partitioning mechanism. In the second phase, after all executor shards reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this phase, only the account-shard mapping relationship is updated, and accounts that do not belong to the current shard are locked. In the third stage, each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating a transaction for the account. The second and third stages are handled under a transaction-aware lightweight account migration mechanism.

[0011] Secondly, this application provides a lightweight migration sharded blockchain account scheduling device, the device comprising: The acquisition unit is used to acquire user transaction requests that are currently awaiting processing by the blockchain network to be sharded. The detection unit is used to detect whether the current time meets the preset cycle start time condition. If so, the processing unit is triggered. The cycle start time condition is used to indicate the trigger time of the current cycle start of account scheduling or transaction processing. Processing units are used to process transaction requests under the sharded blockchain account scheduling mechanism, wherein the sharded blockchain network includes... The sharded blockchain account scheduling mechanism, consisting of one executor shard and one coordinator shard, includes the following processing: In the first phase, the nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the rumor protocol to synchronize the pending transactions and the latest status of all shards. Among them, account partitioning is performed under the migration-aware partitioning mechanism. In the second phase, after all executor shards reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this phase, only the account-shard mapping relationship is updated, and accounts that do not belong to the current shard are locked. In the third stage, each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating a transaction for the account. The second and third stages are handled under a transaction-aware lightweight account migration mechanism.

[0012] Thirdly, this application provides a processing device, including a processor and a memory, wherein a computer program is stored in the memory, and the processor executes the method provided in the first aspect of this application when it invokes the computer program in the memory.

[0013] Fourthly, this application provides a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute the method provided in the first aspect of this application.

[0014] From the above, it can be concluded that this application has the following beneficial effects: In response to the optimization goals of sharded blockchain networks, this application addresses the issue of "mismatch between partitioning results and actual performance" in sharded blockchain application scenarios, specifically for situations where both parties in a transaction request involve different shards. It employs a specially designed migration-aware partitioning mechanism and a transaction-aware lightweight account migration mechanism to avoid over-migration. This is the first time such a mechanism has solved the problem of "mismatch between partitioning results and actual performance," significantly reducing on-chain burden and improving throughput and latency. This achieves efficient account scheduling in sharded blockchains with lightweight migration, demonstrating promising application prospects. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart illustrating a sharded blockchain account scheduling method for lightweight migration as described in this application. Figure 2 This is a schematic diagram of a sharded blockchain account scheduling device for lightweight migration as described in this application. Figure 3 This is a schematic diagram of the processing equipment involved in the processing system of this application. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved.

[0019] The module division described in this application is a logical division. In practical applications, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection between modules shown or discussed may be through some interfaces, and the indirect coupling or communication connection between modules may be electrical or other similar forms, none of which are limited in this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed in multiple circuit modules. Some or all of the modules may be selected to achieve the purpose of the solution in this application according to actual needs.

[0020] First, refer to Figure 1 , Figure 1 This paper illustrates a flowchart of a lightweight migration method for scheduling sharded blockchain accounts, as described in this application. The lightweight migration method for scheduling sharded blockchain accounts provided in this application may specifically include the following steps S101 to S103: Step S101: Obtain the user transaction requests currently awaiting processing by the blockchain network to be sharded; Understandably, the proposed solution is specifically applied to sharded blockchain networks, which are blockchain networks / platforms that employ sharded blockchain mechanisms.

[0021] For user transaction requests that need to be processed by a sharded blockchain network (user transaction requests in the blockchain do not directly involve financial transactions; they can also refer to specific request names such as processing requests, user requests, or names based on specific business scenarios, such as data storage requests), the requests involve the accounts of the two parties involved, namely the sender's (proposer's) account and the receiver's account. Therefore, there is a technical limitation arising from the fact that the accounts involved in the request belong to different shards: 1) The current account partitioning method fails to adequately consider migration costs; 2) High account migration costs limit the effectiveness of the scheduling mechanism.

[0022] It should be noted that in practical applications, sharded blockchain networks can be involved in specific application scenarios such as the Internet of Things, copyright protection, government services, public services, supply chain management, or financial business. This is very flexible. In fact, a lot of data processing can be handled by blockchain technology to improve data processing efficiency by taking advantage of its decentralization and immutability. Therefore, the specific application scenario of this application scheme is not limited in too much, and it can be flexibly configured according to the actual situation.

[0023] As a concrete example, for a company, its core business might be providing payment and settlement services to external clients. This could involve building a unified corporate payment and settlement platform to provide daily payment settlement and reconciliation services for upstream and downstream partners. In this case, sharded blockchain network technology can be introduced to record various payment instructions and settlement results on a sharded blockchain network, thereby improving the traceability and security of transaction records.

[0024] In this payment settlement scenario based on a sharded blockchain network, a payment transaction typically involves changes to the status of both the payer's and payee's accounts. When these two accounts are distributed across different executor shards due to random sharding, each payment transaction becomes a cross-shard transaction, requiring additional cross-shard coordination processes to update account balances and confirm payment results.

[0025] As business scale expands and the number of shards increases, the proportion of cross-shard payment transactions rises significantly. The resulting transaction confirmation delays, failure retries, and system resource consumption, among other existing technical defects, will limit the practical value of enterprise payment services, hinder the reduction of overall management costs, and make it difficult to guarantee the stability and timeliness of payment services.

[0026] Therefore, the lightweight migration sharded blockchain account scheduling operation specifically designed in this application to address the shortcomings of the existing technology can ensure that the evidence storage business has more prominent low-cost management costs and high-quality business services.

[0027] Step S102: Detect whether the current time meets the preset cycle start time condition, wherein the cycle start time condition is used to indicate the trigger time for the start of the current cycle of account scheduling or transaction processing; Understandably, the start time of each cycle can be determined based on the preset cycle length and initial start time, given the cycle start time condition mentioned here.

[0028] Specifically, checking whether the current time meets the preset period start time condition can include: Get the current system time; Read the pre-configured cycle start time parameter, which may specifically include the initial start time T0 and the cycle length ΔT; The starting time of the new cycle should be calculated based on the cycle start time parameter, and it is determined whether the current time has reached or exceeded the start time of the new cycle, or whether the time difference between the current time and the start time of a certain cycle falls within the preset tolerance range, so as to determine whether the cycle start time condition is met. If the conditions are met, it can be considered that we are at the beginning of a new scheduling cycle, thereby triggering subsequent account scheduling and transaction processing operations. If the conditions are not met, the current state can be maintained until the conditions are met before proceeding with subsequent steps, namely account scheduling and transaction processing operations.

[0029] Step S103: If yes, then the transaction request is processed under the sharded blockchain account scheduling mechanism, wherein the sharded blockchain network includes... The sharded blockchain account scheduling mechanism, consisting of one executor shard and one coordinator shard, includes the following processing: In the first phase, the nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the rumor protocol to synchronize the pending transactions and the latest status of all shards. Among them, account partitioning is performed under the migration-aware partitioning mechanism. In the second phase, after all executor shards reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this phase, only the account-shard mapping relationship is updated, and accounts that do not belong to the current shard are locked. In the third stage, each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating a transaction for the account. The second and third stages are handled under a transaction-aware lightweight account migration mechanism.

[0030] Specifically, in the sharded blockchain network involved in this application, the executor shard (which can be referred to as E-Shard) is responsible for transaction consensus and execution, while the coordinator shard (which can be referred to as C-Shard) is responsible for maintaining the mapping relationship between nodes and shards and dynamically adjusting the mapping of accounts to executor shards.

[0031] All shards use an account model, maintaining the state information of all accounts through a sparse Merkle tree, with the root hash value representing the current global state of the shard.

[0032] Each shard uses the Practical Byzantine Fault Tolerance (PBFT) protocol as its intra-shard consensus mechanism and uses a relay transaction mechanism to handle cross-shard transactions. Transactions are routed to the shard where the account is located (initially determined by the account address), then added to the account's transaction pool and queued for execution. If a transaction has not been executed at the start of a new cycle, it is used for account scheduling analysis.

[0033] Based on this, the sharded blockchain account scheduling mechanism has three stages as shown above. The following is a detailed explanation of the processing of these three stages.

[0034] 1) First stage The nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the gossip protocol to synchronize the pending transactions and the latest status of all shards. Account partitioning is performed under the migration-aware partitioning mechanism. At the beginning of each cycle, the coordinator shard (C-Shard) constructs an account network graph using the set of transactions to be processed, and performs account partitioning under the migration-aware partitioning mechanism or the migration-aware partitioning algorithm. After reaching a consensus, the new account partitioning results are recorded in the configuration block.

[0035] Specifically, this application may have the following preconditions for the migration-aware partitioning mechanism: In each cycle, an account interaction graph (or account relationship network graph) is constructed based on the set of transactions to be processed. In this account interaction graph, the account set sharded set Each slice is an execution unit; edge set The weight is the number of transactions between accounts; a binary variable is introduced. Used to indicate account Assign to a fragment , Indicates the first The start time of each cycle, It is a positive integer; Assuming the workload of processing transactions within a single shard is 1, then, given an account partitioning scheme... Shards that perform internal transaction processing workload It can then be expressed as the following formula (1): ; Cross-shard transactions are processed using a relay transaction mechanism, which consists of two parts: the first part follows the structural framework of intra-shard transactions, while the second part depends on the specific protocol implementation. In this case, [the mechanism] uses [the following method]... This represents the processing complexity ratio of a relay transaction relative to a transaction within the same shard. Therefore, the complexity is determined by sharding. Cross-shard transaction workloads to be processed This can be expressed as the following formula (2): ; When the sharding of an account changes, a migration operation is used to complete the corresponding state transition. This represents the processing complexity ratio of a single account migration operation relative to the transaction processing within a shard. Its value depends on the specific migration method used, determined by the sharding mechanism. Workload when processing all account migrations This is related to the number of accounts that have undergone sharding changes within that shard, and can be expressed as the following formula (3): ; Therefore, by fragmentation The total workload to be processed based on the current set of pending transactions and the current account partitioning results. This can be expressed as the following formula (4): ; Correspondingly, the difference in workload between shards The load balance of the system can be measured by the following formula (5): , in, This represents the average workload processed by each shard; Under the account partitioning results, the total system workload generated by relay transactions triggered by cross-shard transaction processing. This can be expressed as the following formula (6): ; Based on this, the goal of account partitioning is to find an account partitioning scheme for a given set of transactions to be processed. Thus, the optimization problem of minimizing the additional workload caused by cross-shard transaction processing and account migration while achieving load balancing can be expressed as the following formula (7): , , , in, This represents a coefficient indicating the relative weight of additional workload and load imbalance during the control optimization process. .

[0036] Under the aforementioned preconditions, the migration-aware partitioning mechanism specifically designed in this application to solve the aforementioned account partitioning problem takes the account interaction graph and the maximum number of iterations as input and outputs the updated account partitioning results. Specifically, it can include the following processing: Traverse each vertex in the account interaction graph, determine the corresponding label representing the account shard number, and assign an initial label to the vertex that did not appear in the previous round of partitioning results based on the corresponding address hash value; Subsequently, in each iteration, a target label that makes the score function value greater than 0 is selected from the set of neighboring labels of the vertex as the new label. This iterative process continues until the maximum number of iterations is reached or no more label update events occur. The score function is used to calculate the score function value. This can be expressed as the following formulas (8), (9), and (10): , , , in, Indicates account adjustment Previous fragments workload, Indicates account adjustment Previous fragments workload, Indicates account adjustment Subsequent fragmentation workload, Indicates account adjustment Subsequent fragmentation Workload.

[0037] Specifically, and The difference between these two intermediate values ​​reflects the effect of adjusting the fragmentation. To fragment account The number of cross-shard transactions that can be reduced is calculated using the formulas (9) and (10) above, and then this difference is multiplied by a coefficient. Subtract the account migration The resulting workload This allows for the calculation of the overall reduction in system workload, enabling the consideration of the workload of migrated accounts during the tag propagation process.

[0038] In addition, through , , and By comparing the load differences before and after the adjustment, the load balancing optimization effect brought about by this adjustment can be quantified. At this point, the weighted sum of the above two indicators is used to comprehensively evaluate the contribution of the account sharding adjustment to the optimization goal.

[0039] Thus, this application incorporates migration overhead into the optimization objective, avoids excessive migration, and solves the problem of "mismatch between partitioning results and actual performance" for the first time.

[0040] Furthermore, this application also considers that the system performance is significantly more sensitive to load balancing than the cross-shard transaction ratio, so an adaptive weight adjustment mechanism can be used to optimize the label propagation process.

[0041] Correspondingly, the migration-aware partitioning processing in this application may also include the following processing: The adaptive weight adjustment mechanism to optimize the label propagation process can be expressed as the following formula (11): , Under the binary splitting mechanism, when the load difference between the shards is large, that is... When the condition of significant difference is met, the system prioritizes load balancing, i.e., adopts a load balancing strategy. When the load difference is very small, that is When the condition of very small difference is met, the focus shifts to minimizing cross-shard transactions, that is, adopting a strategy of minimizing cross-shard transactions.

[0042] 2) Second stage After all executor shards (E-Shard) reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this block, only the account-shard mapping relationship is updated (or the account-shard mapping relationship), and accounts that do not belong to the current shard are locked. During this phase, only the mapping relationship between accounts and shards is updated, and accounts that do not belong to the current shard are locked, without migrating the account state.

[0043] Specifically, the account migration process follows the new partitioning results, transferring the account state of the transferred shard ownership from the source shard to the target shard. To this end, this application proposes a transaction-aware lightweight account migration mechanism, which divides the account migration into two stages: the Lock stage and the Mint stage, which correspond to the second stage and the subsequent third stage.

[0044] The transaction-aware, lightweight account migration mechanism specifically designed in this application can be subject to the following preconditions: set up Given a global set of account addresses, the global account mapping function can be expressed as the following formula (12): , For any account , Indicates in Period allocation Fragmentation, Fragmentation exist The set of accounts that changed during the period can be represented by the following formula (13): , Unlike traditional sharded blockchains that statically map accounts to shards, the blockchain in this application with account scheduling function dynamically manages the mapping relationship between accounts and shards, thereby ensuring the accuracy of transaction routing. Correspondingly, the chain state of each executor shard maintains two types of mapping tables: a global mapping table and a mapping table to be migrated. The global mapping table records the latest account to shard allocation for all accounts, and the corresponding mapping can be expressed as formula (14): ,in, This indicates the latest cycle, updated at the beginning of each cycle. To reflect the latest allocation from account to shard; The pending migration mapping table records all accounts waiting to be migrated to the current shard, and is updated at the beginning of each period. The mapping table of accounts to be migrated can be represented by formula (15): ; Indicates plans to Migration into the slab at the beginning of the period A collection of accounts, This can be expressed as the following formula (16): , in, Indicates the first The root hash set of the ledger state of the executor shard at the start of each cycle.

[0045] Under the aforementioned preconditions, the transaction-aware lightweight account migration mechanism specifically designed in this application involves the partition update and account locking phases in the second stage, namely the lock phase mentioned above. Specifically, the following processing can be performed: At the start of each cycle, the coordinator shard (C-Shard) determines the new account partitioning results based on the current set of transactions to be processed, and calculates the set of accounts that need to have their shards changed. It generates a configuration block, the header of which contains the hash value of the previous block and the current period. The state root of all actuator fragments And the state root of the modified Merkle Patricia Trie (MMPT) constructed based on the account partitioning results; After the coordinator shard generates the latest account partitioning result for the new block, each executor shard (E-Shard) encapsulates the latest account partitioning result into a rebind block. The rebind block is used to update the account partitioning information of the executor shard. If the account partitioning information does not contain regular transaction records, it includes a configuration block header and... Once consensus is reached on the rebinding blocks, according to renew ; At the same time, newly migrated accounts to the current shard are added to After the rebinding block is executed, any transaction involving the migrated account is prohibited from execution, thereby realizing the account shard ownership locking mechanism; In addition, transactions are automatically forwarded to the corresponding target shards, and transactions related to newly migrated accounts will be executed after the completion of the third stage, or casting stage.

[0046] 3) Third stage Each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating a transaction for the account. The second and third phases are handled under a transaction-aware lightweight account migration mechanism.

[0047] If the packaged transaction involves an account that is scheduled to be migrated, the requester will request proof of the account's status and create a Mint transaction, which will be added to the block to complete the migration process.

[0048] Specifically, for the transaction-aware lightweight account migration mechanism specifically designed in this application, the third stage, involving consensus transactions and account creation (i.e., the mint stage mentioned above), can include the following processing: After the rebinding block is completed, the executor shard (E-Shard) enters a new cycle, and consensus nodes begin packaging and executing transactions. For transactions involving the current shard and newly migrated accounts, the requester creates the transaction through the account. The account state migration is completed by (constructing the account state transaction), and the corresponding data structure is represented as follows: , in, Indicates account status. Includes information such as balance and random number. This indicates proof of account status, obtained by the current shard's block producer through a request to the source shard. This represents the block producer's signature on the transaction; This application also uses a sparse Merkle tree data structure to store account status.

[0049] By leveraging the properties of sparse Merkle trees, we can ensure that source shards can efficiently generate membership and non-membership proofs for any account.

[0050] In this case, the system will record the data to be migrated. The entry and the root hash value during the migration of the original shard state tree make this type of proof unforgeable. The block generator of the target shard can easily obtain the required proof by simply sending a standard network request to any consensus node of the source shard.

[0051] Multiple account states and their corresponding proofs can be obtained with a single request, which greatly reduces communication overhead. Based on this information, the current shard can directly verify the correctness of the account states, create the corresponding account states in that shard, and then transfer the accounts from... Delete it.

[0052] Through the aforementioned transaction-aware lightweight account migration mechanism, namely the "Lock-Mint" strategy, the number of on-chain transactions during migration is reduced from 2 to 1, effectively reducing communication and verification overhead while ensuring uniqueness, validity, and replay protection.

[0053] In addition, the overall system processing performance has been significantly improved. Specifically, the throughput has increased by up to 27.8% and the latency has been reduced by up to 81.1% under real Ethereum data, which is significantly better than existing methods.

[0054] After the current transaction request has been processed, it is easy to understand that there may be a further feedback process for the processing results.

[0055] For example, it can output processing results to the requester for viewing and storage, display processing results, output reminders to the requester / preset reminders that the request processing has been completed, and perform further data processing and analysis based on the processing results, so as to meet the diverse application needs of practical applications.

[0056] Regarding the results display function, it can be understood that it can be accomplished through the device's own display screen (including touch screen), through an external monitor, or through other devices with displays, which is quite flexible.

[0057] In conclusion, regarding the above solutions, this application addresses the optimization goals of sharded blockchain networks. Specifically, in sharded blockchain application scenarios, it addresses situations where both parties in a transaction request involve different shards. Through a specially designed migration-aware partitioning mechanism and a transaction-aware lightweight account migration mechanism, it avoids over-migration and, for the first time, solves the problem of "mismatch between partitioning results and actual performance." This significantly reduces on-chain burden, and throughput and latency are also significantly improved. Thus, it achieves efficient account scheduling in sharded blockchains with lightweight migration, demonstrating promising application prospects.

[0058] The above is an introduction to the lightweight migration sharded blockchain account scheduling method provided in this application. To facilitate better implementation of the lightweight migration sharded blockchain account scheduling method provided in this application, this application also provides a lightweight migration sharded blockchain account scheduling device from the perspective of functional modules.

[0059] See Figure 2 , Figure 2 This is a schematic diagram of a lightweight migration sharded blockchain account scheduling device according to this application. In this application, the lightweight migration sharded blockchain account scheduling device 200 may specifically include the following structure: The acquisition unit 201 is used to acquire user transaction requests that are currently to be processed by the blockchain network to be sharded. The detection unit 202 is used to detect whether the current time meets the preset cycle start time condition. If so, the processing unit 203 is triggered. The cycle start time condition is used to indicate the trigger time of the start of the current cycle of account scheduling or transaction processing. Processing unit 203 is used to process transaction requests under the sharded blockchain account scheduling mechanism, wherein the sharded blockchain network includes The sharded blockchain account scheduling mechanism, consisting of one executor shard and one coordinator shard, includes the following processing: In the first phase, the nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the rumor protocol to synchronize the pending transactions and the latest status of all shards. Among them, account partitioning is performed under the migration-aware partitioning mechanism. In the second phase, after all executor shards reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this phase, only the account-shard mapping relationship is updated, and accounts that do not belong to the current shard are locked. In the third stage, each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating a transaction for the account. The second and third stages are handled under a transaction-aware lightweight account migration mechanism.

[0060] In one exemplary embodiment, the following preset conditions apply to the migration-aware partitioning mechanism: In each cycle, an account interaction graph is constructed based on the set of transactions to be processed. In the account interaction graph, the account set... sharded set Each slice is an execution unit; edge set The weight is the number of transactions between accounts; a binary variable is introduced. Used to indicate account Assign to a fragment , Indicates the first The start time of each cycle; Assuming the workload of processing transactions within a single shard is 1, given an account partitioning scheme... Shards that perform internal transaction processing workload Represented as: ; use This represents the ratio of the processing complexity of a relay transaction to that of a transaction within the same shard, determined by the sharding. Cross-shard transaction workloads to be processed It is expressed as follows: ; When the sharding of an account changes, a migration operation is used to complete the corresponding state transition. This represents the ratio of the processing complexity of a single account migration operation to the processing complexity of transactions within a shard, determined by the sharding. Workload when processing all account migrations It is expressed as follows: ; From fragments The total workload to be processed based on the current set of pending transactions and the current account partitioning results. Represented as: ; Differences in workload between fragments Represented as: , in, This represents the average workload processed by each shard; Under the account partitioning results, the total system workload generated by relay transactions triggered by cross-shard transaction processing. Represented as: ; The optimization problem of minimizing the additional workload caused by cross-shard transaction processing and account migration while achieving load balancing can be expressed as: , , , in, This represents a coefficient indicating the relative weight of additional workload and load imbalance during the control optimization process. .

[0061] In yet another exemplary embodiment, the migration-aware partitioning mechanism includes the following processing: Traverse each vertex in the account interaction graph, determine the corresponding label representing the account shard number, and assign an initial label to the vertex that did not appear in the previous round of partitioning results based on the corresponding address hash value; In each iteration, a target label that makes the score function value greater than 0 is selected from the set of neighboring labels of a vertex as the new label. This iteration process continues until the maximum number of iterations is reached or no more label update events occur. The score function is used to calculate the score function value. Represented as: , , , in, Indicates account adjustment Previous fragments workload, Indicates account adjustment Previous fragments workload, Indicates account adjustment Subsequent fragmentation workload, Indicates account adjustment Subsequent fragmentation Workload.

[0062] In yet another exemplary embodiment, the migration-aware partitioning process further includes the following processing: The adaptive weight adjustment mechanism optimizes the label propagation process, which can be represented as: , Under the dichotomy treatment mechanism, when When the criteria for determining significant differences are met, a load balancing strategy is adopted; when... When the condition of very small difference is met, the strategy of minimizing cross-shard transactions is adopted.

[0063] In yet another exemplary embodiment, the following preset conditions apply to the transaction-aware lightweight account migration mechanism: set up Given a global set of account addresses, the global account mapping function is expressed as: , For any account , Indicates in Period allocation Fragmentation, Fragmentation exist The set of accounts that changed during the period is represented as: , Each executor slice maintains two types of mapping tables in its chain state: a global mapping table and a mapping table to be migrated. The global mapping table records the latest account-to-shard allocation for all accounts, and the corresponding mapping is represented as follows: ,in, This indicates the latest cycle, updated at the beginning of each cycle. ; The pending migration mapping table records all accounts waiting to be migrated to the current shard, and is updated at the beginning of each period. The mapping table of accounts to be migrated is represented as follows: ; Indicates plans to Migration into the slab at the beginning of the period A collection of accounts, Represented as: , in, Indicates the first The root hash set of the ledger state of the executor shard at the start of each cycle.

[0064] In yet another exemplary embodiment, for a transaction-aware lightweight account migration mechanism, the second phase, which involves updating partitions and locking accounts, includes the following processing: At the start of each cycle, the coordinator shard determines the new account partitioning results based on the current set of transactions to be processed, and calculates the set of accounts that need to be sharded. It generates a configuration block, the header of which contains the hash value of the previous block and the current period. The state root of all actuator fragments And the state root of the modified Merkel-Patricia tree constructed based on the account partitioning results; After the coordinator shard generates the latest account partitioning result for the new block, each executor shard encapsulates the latest account partitioning result into a rebinding block. The rebinding block is used to update the account partitioning information of the executor shard. If the account partitioning information does not contain regular transaction records, it includes a configuration block header and... Once consensus is reached on the rebinding blocks, according to renew ; At the same time, newly migrated accounts to the current shard are added to After the rebinding block is executed, any transactions involving migrated accounts are prohibited from execution; Transactions are automatically forwarded to the corresponding target shard. Transactions related to newly migrated accounts will be executed after the third phase is completed.

[0065] In yet another exemplary embodiment, for the transaction-aware lightweight account migration mechanism, the third stage, involving consensus transactions and account creation, includes the following processing: After the rebinding block is completed, the executor sharding enters a new cycle, and the consensus nodes begin packaging and executing transactions. For transactions involving the current shard and newly migrated accounts, the requester creates the transaction through the account. To complete the account status migration, the corresponding data structure is represented as follows: , in, Indicates account status. This indicates proof of account status, obtained by the current shard's block producer through a request to the source shard. This represents the block producer's signature on the transaction; Use a sparse Merkle tree data structure to store account status.

[0066] This application also provides a processing system from a hardware architecture perspective. This system can be either a sharded blockchain network (involving multiple blockchain nodes deployed in a sharded manner) directly applicable to the scheme of this application, or a device cluster that includes a sharded blockchain network and other devices. This addresses the situation where, in practical blockchain applications, not all devices are necessarily part of the blockchain network or are blockchain nodes. Clearly, the specific system deployment architecture of the processing system is quite flexible. For ease of explanation, the devices involved in the processing system can be collectively referred to as processing devices. (See reference...) Figure 3 , Figure 3 This diagram illustrates a structural schematic of the processing device involved in the processing system of this application. Specifically, the processing device of this application may include a processor 301, a memory 302, and an input / output device 303. The processor 301 executes the computer program stored in the memory 302 to implement, for example... Figure 1 The corresponding steps of the lightweight migration sharded blockchain account scheduling method in the corresponding embodiment are as follows: Alternatively, when processor 301 executes the computer program stored in memory 302, it implements the following... Figure 2 Corresponding to the functions of each unit in the embodiment, the memory 302 is used to store the functions executed by the processor 301 as described above. Figure 1 The corresponding embodiment provides the computer program required by the execution entity for the lightweight migration sharded blockchain account scheduling method.

[0067] For example, a computer program may be divided into one or more modules / units, one or more of which are stored in memory 302 and executed by processor 301 to complete this application. One or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in a computer device.

[0068] The processing device may include, but is not limited to, processor 301, memory 302, and input / output device 303. Those skilled in the art will understand that the illustrations are merely examples of the processing device and do not constitute a limitation on the processing device. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the processing device may also include network access devices, buses, etc., and processor 301, memory 302, input / output device 303, etc., are connected via a bus.

[0069] Processor 301 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. Processor 301 is the control center of the processing device, connecting various parts of the entire device through various interfaces and lines.

[0070] The memory 302 can be used to store computer programs and / or modules. The processor 301 implements various functions of the computer device by running or executing the computer programs and / or modules stored in the memory 302 and by calling data stored in the memory 302. The memory 302 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function, etc.; the data storage area may store data created according to the use of the processing device, etc. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0071] When processor 301 executes a computer program stored in memory 302, it can specifically implement the following functions of the corresponding execution entity: Get the user transaction requests that are currently waiting to be processed by the blockchain sharding network; Check whether the current time meets the preset cycle start time condition, where the cycle start time condition is used to indicate the trigger time for the start of the current cycle of account scheduling or transaction processing; If so, the transaction request is processed under the sharded blockchain account scheduling mechanism, wherein the sharded blockchain network includes The sharded blockchain account scheduling mechanism, consisting of one executor shard and one coordinator shard, includes the following processing: In the first phase, the nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the rumor protocol to synchronize the pending transactions and the latest status of all shards. Among them, account partitioning is performed under the migration-aware partitioning mechanism. In the second phase, after all executor shards reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this phase, only the account-shard mapping relationship is updated, and accounts that do not belong to the current shard are locked. In the third stage, each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating a transaction for the account. The second and third stages are handled under a transaction-aware lightweight account migration mechanism.

[0072] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the lightweight migration sharded blockchain account scheduling device, processing system, and its corresponding units described above can be found in, for example... Figure 1 The description of the sharded blockchain account scheduling method for lightweight migration in the corresponding embodiment will not be repeated here.

[0073] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0074] Therefore, this application provides a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute the present application. Figure 1 The steps of the sharded blockchain account scheduling method for lightweight migration in the corresponding embodiment can be found in the following example. Figure 1 The description of the sharded blockchain account scheduling method for lightweight migration in the corresponding embodiment will not be repeated here.

[0075] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0076] Because of the instructions stored in the computer-readable storage medium, the present application can be executed as described above. Figure 1 The steps of the sharded blockchain account scheduling method for lightweight migration in the corresponding embodiment can therefore achieve the results of this application. Figure 1The beneficial effects that the lightweight migration sharded blockchain account scheduling method in the corresponding embodiment can achieve are detailed in the preceding description and will not be repeated here.

[0077] The above provides a detailed description of the lightweight migration sharded blockchain account scheduling method, apparatus, processing system, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A lightweight migration method for scheduling sharded blockchain accounts, characterized in that, The method includes: Get the user transaction requests that are currently waiting to be processed by the blockchain sharding network; Detect whether the current time meets the preset cycle start time condition, wherein the cycle start time condition is used to indicate the trigger time for the start of the current cycle of account scheduling or transaction processing; If so, the transaction request is processed under the sharded blockchain account scheduling mechanism, wherein the sharded blockchain network includes The sharded blockchain account scheduling mechanism includes the following processing steps: (1 executor shard and 1 coordinator shard) In the first phase, the nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the rumor protocol to synchronize the pending transactions and the latest status of all shards. Account partitioning is performed under the migration-aware partitioning mechanism. In the second phase, after all the executor shards reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this phase, only the account-shard mapping relationship is updated, and accounts that do not belong to the current shard are locked. In the third stage, each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating an account transaction. The second and third stages are processed under a transaction-aware lightweight account migration mechanism.

2. The method according to claim 1, characterized in that, The migration-aware partitioning mechanism has the following preset conditions: In each cycle, an account interaction graph is constructed using the set of transactions to be processed, where the account set... sharded set Each slice is an execution unit; edge set The weight is the number of transactions between accounts; a binary variable is introduced. Used to indicate account Assign to a fragment , Indicates the first The start time of each cycle; Assuming the workload of processing transactions within a single shard is 1, given an account partitioning scheme... Shards that perform internal transaction processing workload Represented as: ； use This represents the ratio of the processing complexity of a relay transaction to that of a transaction within the same shard, determined by the shard. Cross-shard transaction workloads to be processed It is expressed as follows: ； When the sharding of an account changes, a migration operation is used to complete the corresponding state transition. This represents the ratio of the processing complexity of a single account migration operation to the processing complexity of transactions within a shard, as indicated by the shard. Workload when processing all account migrations It is expressed as follows: ； From the fragments The total workload to be processed under the current set of pending transactions and the current account partitioning results. Represented as: ； Differences in workload between fragments Represented as: ， in, This represents the average workload processed by each shard; Under the aforementioned account partitioning results, the total system workload generated by the relay transactions triggered by cross-shard transaction processing. Represented as: ； The optimization problem of minimizing the additional workload caused by cross-shard transaction processing and account migration while achieving load balancing can be expressed as: ， ， ， in, This represents a coefficient indicating the relative weight of the additional workload and load imbalance during the control optimization process. .

3. The method according to claim 2, characterized in that, The migration-aware partitioning mechanism includes the following processing: Traverse each vertex in the account interaction graph and determine the corresponding label representing the account shard number. For vertices that did not appear in the previous round of partitioning results, assign an initial label based on the corresponding address hash value. In each iteration, a target label that makes the scoring function value greater than 0 is selected from the set of neighbor labels of the vertex as the new label. The entire iteration process continues until the maximum number of iterations is reached or no more label update events occur. The scoring function used to calculate the scoring function value is... Represented as: ， ， ， in, Indicates account adjustment Previous fragments workload, Indicates adjustment of the account Previous fragments workload, Indicates adjustment of the account Subsequent fragmentation workload, Indicates adjustment of the account Subsequent fragmentation Workload.

4. The method according to claim 3, characterized in that, The migration-aware partitioning process also includes the following processing steps: The adaptive weight adjustment mechanism optimizes the label propagation process, which can be represented as: ， Under the dichotomy treatment mechanism, when When the criteria for determining significant differences are met, a load balancing strategy is adopted. when When the condition of very small difference is met, the strategy of minimizing cross-shard transactions is adopted.

5. The method according to claim 2, characterized in that, The transaction-aware lightweight account migration mechanism has the following preset conditions: set up Given a global set of account addresses, the global account mapping function is expressed as: ， For any account , Indicates in Period allocation Fragmentation, Fragmentation exist The set of accounts that changed during the period is represented as: ， Each of the aforementioned actuator fragments maintains two types of mapping tables in its chain state: a global mapping table and a mapping table to be migrated. The global mapping table records the latest account-to-shard allocation for all accounts, and the corresponding mapping is represented as follows: ,in, This indicates the latest cycle, updated at the beginning of each cycle. ; The migration mapping table records all accounts waiting to be migrated to the current shard, and is updated at the beginning of each period. The shard... The mapping table of accounts to be migrated is represented as follows: ; Indicates plans to The fragments were migrated at the start of the period. A collection of accounts, Represented as: ， in, Indicates the first The root hash set of the ledger state of the executor shard at the start of each cycle.

6. The method according to claim 5, characterized in that, For the transaction-aware lightweight account migration mechanism, the second stage involves updating partitions and locking accounts, and includes the following processing: At the start of each period, the coordinator shard determines a new account partitioning result based on the current set of transactions to be processed, and calculates the set of accounts that need to have their shards changed. It then generates a configuration block, the header of which includes the hash value of the previous block and the current period. The state root of all the aforementioned actuator fragments And the state root of the modified Merkel-Patricia tree constructed based on the account partitioning results; After the coordinator shard generates the latest account partitioning result for the new block, each executor shard encapsulates the latest account partitioning result into a rebinding block. The rebinding block is used to update the account partitioning information of the executor shard. This account partitioning information, excluding regular transaction records, includes a configuration block header and... Once the rebinding blocks reach a consensus, according to renew ; At the same time, newly migrated accounts to the current shard are added to After the rebinding block is executed, any transactions involving migrated accounts are prohibited from execution; Transactions are automatically forwarded to the corresponding target shard. Transactions related to newly migrated accounts will be executed after the completion of the third stage.

7. The method according to claim 6, characterized in that, For the aforementioned transaction-aware lightweight account migration mechanism, the third stage, which involves consensus transactions and account creation, includes the following processing: After the rebinding block is executed, the executor shard enters a new cycle, and the consensus node begins packaging and executing transactions. For transactions involving the current shard and the newly migrated account, the requesting party creates the transaction through the account. To complete the account status migration, the corresponding data structure is represented as follows: ， in, Indicates account status. This indicates proof of account status, obtained by the current shard's block producer through a request to the source shard. This represents the block producer's signature on the transaction; Use a sparse Merkle tree data structure to store account status.

8. A lightweight migration sharded blockchain account scheduling device, characterized in that, The device includes: The acquisition unit is used to acquire user transaction requests that are currently awaiting processing by the blockchain network to be sharded. The detection unit is used to detect whether the current time meets the preset cycle start time condition. If so, the processing unit is triggered. The cycle start time condition is used to indicate the trigger time of the start of the current cycle of account scheduling or transaction processing. The processing unit is used to process the transaction request under the sharded blockchain account scheduling mechanism, wherein the sharded blockchain network includes... The sharded blockchain account scheduling mechanism includes the following processing steps: (1 executor shard and 1 coordinator shard) In the first phase, the nodes in the coordinator shard continuously monitor the transaction pool and the latest block of each executor shard, and transmit information between nodes within the shard through the rumor protocol to synchronize the pending transactions and the latest status of all shards. Account partitioning is performed under the migration-aware partitioning mechanism. In the second phase, after all the executor shards reach a consensus, the latest account partitioning results are synchronized and recorded in the rebinding block. In this phase, only the account-shard mapping relationship is updated, and accounts that do not belong to the current shard are locked. In the third stage, each executor shard executes transactions through consensus, generating multiple transaction execution blocks. If the packaged transaction involves a target account to be migrated, the requester completes the account state migration by creating an account transaction. The second and third stages are processed under a transaction-aware lightweight account migration mechanism.

9. A processing device, characterized in that, The method includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the method as described in any one of claims 1 to 7 when it invokes the computer program in the memory.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the method of any one of claims 1 to 7.

Images