Blockchain accounting method and device, electronic equipment and storage medium
By employing a dynamic thread pool in the Fabric platform to execute blockchain accounting operations in parallel, the problem of low resource utilization is solved, parallel processing and resource reuse between blocks are achieved, and the performance of blockchain services is improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA MOBILE QUANTONG SYST INTEGRATION CO LTD
- Filing Date
- 2021-10-11
- Publication Date
- 2026-07-10
AI Technical Summary
Low resource utilization in the Fabric platform's accounting process leads to performance bottlenecks, especially in the serial processing between blocks, which results in concentrated computation and I/O operations and low resource utilization.
The system employs a dynamic thread pool to execute target operations and sub-operations in parallel, including block verification, transaction verification, block submission, and updating the world state. It processes operations between different blocks and within the same block in parallel through a pipeline approach and supports dynamically expandable thread pools to reuse thread resources.
It improved resource utilization, enhanced the overall performance and business logic execution efficiency of the Fabric platform, and enabled efficient parallel processing of blockchain services.
Smart Images
Figure CN115981801B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication technology, and in particular to a blockchain ledger method, apparatus, electronic device, and storage medium. Background Technology
[0002] The distributed ledger platform Fabric, also known as Hyperledger Fabric, is the first open-source distributed ledger platform designed for enterprise applications and is widely used to implement consortium blockchains.
[0003] The Fabric platform's transaction processing flow comprises three parts: endorsement, transaction sequencing, and accounting. However, performance testing and analysis of the Fabric platform indicate that resource utilization is low in the accounting process, resulting in the accounting process being the performance bottleneck. Therefore, improving the performance of the Fabric platform in the accounting process is a crucial issue that the industry urgently needs to address. Summary of the Invention
[0004] This invention provides a blockchain accounting method, apparatus, electronic device, and storage medium to address the shortcomings of low resource utilization in the accounting process of the Fabric platform in the prior art, thereby improving the overall performance of the Fabric platform.
[0005] In a first aspect, the present invention provides a blockchain ledger method, comprising:
[0006] The distributed ledger platform Fabric determines the target block to be processed for accounting.
[0007] The Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation;
[0008] In this context, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block.
[0009] Optionally, in one embodiment, the parallel execution of at least two target operations includes:
[0010] The at least two target operations are executed in parallel in a pipeline manner.
[0011] Optionally, in one embodiment, the at least two types of sub-operations include block verification sub-operations and transaction verification sub-operations.
[0012] Optionally, in one embodiment, the Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, including:
[0013] Based on the target block, a target task is determined, wherein the target task is used to indicate the target operation corresponding to the target block;
[0014] Based on the target task, the target thread is determined from the idle threads in the dynamic thread pool;
[0015] Assign the target task to the target thread;
[0016] Based on the target thread, execute the target operation indicated by the target task.
[0017] Optionally, in one embodiment, determining the target thread from the idle threads in the dynamic thread pool based on the target task includes:
[0018] If the number of threads in the idle state is less than the number of threads required by the target task, the target task is added to the blocking queue;
[0019] If the number of threads in the idle state is greater than or equal to the number of threads required by at least one target task in the blocking queue, the target thread is determined from the threads in the idle state.
[0020] Optionally, in one embodiment, determining the target thread from the idle threads in the dynamic thread pool based on the target task includes:
[0021] If the number of target tasks in the blocking queue is greater than or equal to a first preset threshold when the target task is added to the blocking queue, at least one temporary thread is created in the dynamic thread pool.
[0022] The temporary thread is used to expand the dynamic thread pool.
[0023] Optionally, in one embodiment, determining the target thread from the idle threads in the dynamic thread pool based on the target task includes:
[0024] If the number of temporary threads created is greater than or equal to a second preset threshold, perform at least one of the following operations:
[0025] Repeat the operation of adding the first target task to the blocking queue;
[0026] After waiting for a preset time, the operation of adding the first target task to the blocking queue is executed again;
[0027] Perform the operation to discard the first target task;
[0028] The first target task includes the target tasks that are not placed in the blocking queue.
[0029] Secondly, the present invention provides a blockchain ledger device, comprising: a determining module and an execution module, wherein:
[0030] The determination module is used by the Fabric distributed ledger platform to determine the target block to be processed for accounting.
[0031] The execution module is used by the Fabric platform to execute at least two target operations in parallel based on a dynamic thread pool, and / or execute at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation;
[0032] In this context, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block.
[0033] Thirdly, the present invention provides an electronic device, including a memory and a memory storing a computer program, wherein the processor executes the program to implement the steps of the blockchain ledger method described in the first aspect.
[0034] Fourthly, the present invention provides a processor-readable storage medium storing a computer program for causing the processor to perform the steps of the blockchain ledger method described in the first aspect.
[0035] The present invention provides a blockchain accounting method, apparatus, electronic device and storage medium, which can achieve parallel processing of accounting processes between different blocks and / or parallel processing of processes between the same block by executing at least two target operations in parallel based on a dynamic thread pool, and / or executing at least two types of sub-operations in parallel. This improves resource utilization and supports dynamically expandable thread pools to reuse thread resources, improve the execution efficiency of business logic, and thus improve the overall performance of the Fabric platform. Attached Figure Description
[0036] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0037] Figure 1 This is a flowchart of the transaction processing flow of the Fabric platform provided by the relevant technologies;
[0038] Figure 2 This is a flowchart of the accounting process provided by the Fabric platform, which is related to the technology.
[0039] Figure 3 This is a flowchart of the block-sequential execution process of the Fabric platform provided by related technologies;
[0040] Figure 4 This is a flowchart illustrating the blockchain ledger method provided by the present invention;
[0041] Figure 5 This is a schematic diagram of the pipeline method of the blockchain ledger method provided by the present invention;
[0042] Figure 6 This is a flowchart of the block parallel execution process of the blockchain accounting method provided by the present invention;
[0043] Figure 7 This is a schematic diagram of the internal block processing flow of the blockchain accounting method provided by the present invention;
[0044] Figure 8 This is a schematic diagram of the task allocation process of the dynamic thread pool provided by the present invention;
[0045] Figure 9 This is a schematic diagram of the structure of the blockchain accounting device provided by the present invention;
[0046] Figure 10 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation
[0047] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.
[0048] Figure 1This is a flowchart of the transaction processing flow of the Fabric platform provided by the relevant technology provider, such as... Figure 1 As shown, the Fabric platform execution process can be roughly divided into the following three parts:
[0049] (1) Endorsement process (simulated execution): When a node (peer) receives a transaction from a client, it will first perform a verification operation on the transaction, such as verifying whether the client's signature is valid and whether the initiator's identity is valid; then it will perform a pre-execution (or simulated execution) operation on the transaction through the contract; if the execution is successful, the peer node will sign (endorse) the transaction.
[0050] (2) Transaction sorting process: The sorting node (orderer) receives the transaction (the execution result of the simulated transaction) submitted by the client, sorts the transaction, cuts it into blocks, and distributes it to the peer.
[0051] (3) Accounting process: Verify and submit blocks, maintain the ledger
[0052] In the process of performance testing and analysis of the Fabric platform, it was found that the performance bottleneck of the Fabric platform is concentrated in the accounting process.
[0053] Figure 2 It is a flowchart of the accounting process of the Fabric platform provided by the relevant technology provider, such as Figure 2 As shown, the Fabric platform currently processes blocks (accounting processes) primarily in a serial manner.
[0054] Figure 3 This is a flowchart of the block-sequential execution process of the Fabric platform provided by related technologies, such as... Figure 3 As shown, the processing between blocks is sequential. For example, for blocks 1 and 2 that need to be processed for accounting, on the timeline, the accounting process of block 2 can only be executed after the accounting process of block 1 is completed.
[0055] like Figure 2 and Figure 3 As shown, the accounting process can be roughly divided into the following five stages: (1) Block verification, which verifies the signature and hash calculation of the block; (2) Transaction verification, which verifies the read / write set and endorsement strategy; (3) Block submission, which writes the private data and serialized block structure to the file; (4) Update world state, which is the business data stored and retrieved in the contract; (5) Synchronization and cleanup, which broadcasts the received block to other peer nodes through the information exchange protocol (gossip protocol).
[0056] Of the five stages mentioned above, stages (1) and (2) mainly involve serialization, deserialization, and signature verification, which consume relatively more central processing unit (CPU) resources; stages (3) and (4) involve file operations, which consume more disk input / output (IO) resources.
[0057] Within a block, each stage, such as the transaction verification stage, involves parallel processing of the endorsement strategy for the transaction (signature verification operation). However, processing between blocks is sequential. This results in computational operations and I / O operations being processed in a concentrated manner, but the computational and I / O operations are not processed in parallel.
[0058] It is evident that the resource utilization of each hardware component varies significantly at each stage of the Fabric platform's accounting process. Consequently, the sequential processing of blocks makes it difficult to improve resource utilization and overall blockchain service performance during the execution of each stage.
[0059] Therefore, the existing accounting process of the Fabric platform has two main problems: (1) the operations that consume different hardware resources in the accounting process are not fully parallelized, resulting in low resource utilization; (2) the accounting process within a single block is serial, resulting in low resource utilization.
[0060] Figure 4 This is a flowchart illustrating the blockchain ledger method provided by the present invention, as follows: Figure 4 As shown, the method includes:
[0061] Step 401: The distributed ledger platform Fabric determines the target block to be processed for accounting.
[0062] Step 402: The Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation;
[0063] In this context, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block.
[0064] Specifically, in one embodiment, the target block may be a block to be processed for accounting purposes.
[0065] For example, in the process of determining the target block on the Fabric platform, if there are blocks 1, 2, 3, 4, and 5 that need to be recorded, then blocks 1-5 can be determined as the target blocks.
[0066] Specifically, in one embodiment, the target operation may include a block verification sub-operation, a transaction verification sub-operation, a block commit sub-operation, a world state update sub-operation, and a synchronization cleanup sub-operation.
[0067] Specifically, in one embodiment, for block n and block (n+1) in the target block, after the m-th sub-operation of block n is executed, the (m+1)-th sub-operation of block n and the m-th sub-operation of block (n+1) can be executed in parallel.
[0068] For example, for blocks 1 and 2 in the target block, after the block commit sub-operation of block 1 is executed, the update world state sub-operation of block 1 and the block commit sub-operation of block 2 can be executed concurrently.
[0069] Specifically, in one embodiment, the Fabric platform can execute sub-operations corresponding to the target block in parallel.
[0070] For example, after determining block 1 as the target block, the block verification sub-operation and transaction verification sub-operation corresponding to block 1 can be executed in parallel.
[0071] Specifically, in one embodiment, the Fabric platform can execute at least two target operations in parallel, and at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation.
[0072] For example, after determining blocks 1-5 as target blocks, the Fabric platform can execute the target operations corresponding to block 1, block 2, block 3, block 4, and block 5 in parallel. It can also process the block verification sub-operations and transaction verification sub-operations corresponding to block 1 in parallel, the block verification sub-operations and transaction verification sub-operations corresponding to block 2 in parallel, and so on, processing the block verification sub-operations and transaction verification sub-operations corresponding to blocks 3-5 in parallel.
[0073] Specifically, in one embodiment, a dynamic thread pool can reuse threads, with all or some of the threads in the dynamic thread pool used to perform the target operation at least twice.
[0074] For example, a dynamic thread pool can maintain 5 threads (thread 1, thread 2, thread 3, thread 4, and thread 5). In the first time period, blocks 1-5 are identified as target blocks. Thread 1 can then process the target operation for block 1, thread 2 for block 2, thread 3 for block 3, thread 4 for block 4, and thread 5 for block 5. After processing the target operations for blocks 1-5, threads 1-5 are not destroyed. In the second time period, blocks 6-8 are identified as target blocks. Thread 1 can then process the target operation for block 6, thread 2 for block 7, and thread 3 for block 8. Therefore, in this process, threads 1-3 are used to execute the target operation at least twice.
[0075] Specifically, in one embodiment, the dynamic thread pool can be a thread pool that supports dynamic expansion. When the number of threads required for the target operation corresponding to the target block exceeds the number of idle threads in the thread pool, temporary threads can be created to handle the target operation.
[0076] For example, a dynamic thread pool can maintain three threads (thread 1, thread 2, and thread 3). During a certain period, if block 1-5 is determined as the target block and threads 1-3 are idle, the number of threads required for the target operation corresponding to block 1-5 exceeds the number of idle threads in the thread pool. Therefore, temporary threads 4 and 5 can be created. Threads 1-3 are used to process the target operation corresponding to block 1-3, temporary thread 4 is used to process the target operation corresponding to block 4, and temporary thread 5 is used to process the target operation corresponding to block 5.
[0077] Understandably, due to hardware limitations of computer systems, frequent thread creation on the same CPU or CPU core can reduce system efficiency, as frequent thread creation and destruction consume time and resources. This invention manages threads through a dynamic thread pool, which can quickly allocate threads to target operations that require parallel processing of multiple blocks. Compared to creating new threads each time, this reduces unnecessary time and resource consumption, reuses thread resources, and improves the overall execution efficiency of business logic.
[0078] Specifically, in one embodiment, the Fabric platform's accounting process is modularized. The first two computational sub-operations (block verification sub-operation and transaction verification sub-operation) are executed in parallel, separated from the subsequent IO sub-operations (block commit sub-operation and world state update sub-operation). Computational and IO sub-operations between different blocks are also parallelized, which can improve resource utilization and enhance the performance of the Fabric blockchain service. Additionally, a dynamically scalable thread pool is designed to reuse thread resources and improve the execution efficiency of business logic.
[0079] The blockchain accounting method provided by this invention can achieve parallel processing of accounting processes between different blocks and / or parallel processing of processes between the same block by executing at least two target operations in parallel based on a dynamic thread pool, and / or executing at least two types of sub-operations in parallel. This improves resource utilization and supports dynamically expandable thread pools to reuse thread resources, improve the execution efficiency of business logic, and thus improve the overall performance of the Fabric platform.
[0080] Optionally, in one embodiment, the parallel execution of at least two target operations includes:
[0081] The at least two target operations are executed in parallel in a pipeline manner.
[0082] Figure 5 This is a schematic diagram of the pipeline method of the blockchain ledger provided by the present invention, as shown below. Figure 5 As shown, the accounting process between blocks can be done in a pipeline manner.
[0083] Figure 6 This is a flowchart of the block parallel execution process of the blockchain ledger method provided by the present invention, as follows: Figure 6 As shown, the target block can be block 1, block 2, block 3, block 4, or block 5. After the block verification sub-operation of block 1 is completed, the transaction verification sub-operation of block 1 and the block verification sub-operation of block 2 can be executed in parallel. Then, the block commit sub-operation of block 1, the transaction verification sub-operation of block 2, and the block verification sub-operation of block 3 are executed in parallel. Then, the update world state sub-operation of block 1, the block commit sub-operation of block 2, the transaction verification sub-operation of block 3, and the block verification sub-operation of block 4 are executed in parallel. Finally, the synchronization and cleanup sub-operation of block 1, the update world state sub-operation of block 2, the block commit sub-operation of block 3, the transaction verification sub-operation of block 4, and the block verification sub-operation of block 5 are executed in parallel.
[0084] It is understandable that each block commit and world state update (creation, deletion, modification, and querying of business data) is executed after the previous block is completed. Therefore, it will not cause business data to be disordered and affect the final ledger data.
[0085] Therefore, by executing at least two target operations in parallel through a pipelined approach, parallel processing between blocks can be achieved, enabling computational and I / O operations to be executed in parallel, thereby improving resource utilization and enhancing the performance of the Fabric platform service itself.
[0086] Optionally, in one embodiment, the at least two types of sub-operations include block verification sub-operations and transaction verification sub-operations.
[0087] Figure 7 This is a schematic diagram of the internal block processing flow of the blockchain accounting method provided by the present invention, as shown below. Figure 7 As shown, the block verification sub-operation and transaction verification sub-operation within each block can be performed in parallel. By using multi-threading, tasks can be assigned to different threads for execution. Once multiple tasks have been successfully executed, the next sub-operation can continue to be executed.
[0088] like Figure 7 As shown, the target block can be block 1, block 2, and block 3. The accounting process between blocks 1 and 3 can be carried out in a pipeline manner. The block verification sub-operations and transaction verification sub-operations of block 1 can be processed in parallel, the block verification sub-operations and transaction verification sub-operations of block 2 can be processed in parallel, and the block verification sub-operations and transaction verification sub-operations of block 3 can be processed in parallel.
[0089] Therefore, the design that allows parallel processing of processes between multiple blocks enables computational operations and I / O operations to be executed in parallel, making full use of system resources. However, the process of each block is still executed step by step. For example, the block verification sub-operation and the transaction verification sub-operation are CPU-intensive. These two sub-operations have no dependency relationship and can be further parallelized.
[0090] Therefore, by executing the block verification sub-operations and transaction verification sub-operations in the process of each block in parallel, resource utilization can be improved and the performance of the Fabric platform service itself can be enhanced.
[0091] Optionally, in one embodiment, the Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, including:
[0092] Based on the target block, a target task is determined, wherein the target task is used to indicate the target operation corresponding to the target block;
[0093] Based on the target task, the target thread is determined from the idle threads in the dynamic thread pool;
[0094] Assign the target task to the target thread;
[0095] Based on the target thread, execute the target operation indicated by the target task.
[0096] Specifically, in one embodiment, the target task can be used to indicate the target operation corresponding to the target block.
[0097] For example, if block 1 is determined to be the target block, the target tasks of block 1 can be determined to include: the block verification sub-operation to be executed for block 1, the transaction verification sub-operation to be executed for block 1, the block commit sub-operation to be executed for block 1, the world state update sub-operation to be executed for block 1, and the synchronization cleanup sub-operation to be executed for block 1.
[0098] Specifically, in one embodiment, after determining the target task, the target thread can be determined from the threads that are idle in the dynamic thread pool.
[0099] For example, if the target task includes task 1 (the block verification sub-operation to be executed) and task 2 (the transaction verification sub-operation to be executed), thread 1 and thread 2 can be identified as the target threads from threads 1-5 that are in an idle state in the dynamic thread pool.
[0100] Specifically, in one embodiment, after the target thread is determined, the target task can be assigned to the target thread.
[0101] For example, after determining thread 1 and thread 2 as target threads based on the target tasks (block verification sub-operations to be executed and transaction verification sub-operations to be executed), the task of "block verification sub-operations to be executed" can be assigned to thread 1, and the task of "transaction verification sub-operations to be executed" can be assigned to thread 2.
[0102] Therefore, managing threads through a dynamic thread pool allows for the rapid allocation of threads to target operations that require parallel processing of multiple blocks. Compared to creating a new thread each time, this reduces the consumption of unnecessary timer resources, reuses thread resources, and improves the overall execution efficiency of business logic.
[0103] Optionally, in one embodiment, determining the target thread from the idle threads in the dynamic thread pool based on the target task includes:
[0104] If the number of threads in the idle state is less than the number of threads required by the target task, the target task is added to the blocking queue;
[0105] If the number of threads in the idle state is greater than or equal to the number of threads required by at least one target task in the blocking queue, the target thread is determined from the threads in the idle state.
[0106] Specifically, in one embodiment, if the number of idle threads is less than the number of threads required by the target task, the target task can be added to the blocking queue.
[0107] For example, if blocks 1-3 are determined to be the target blocks, the threads in the idle state are thread 1 and thread 2. If processing the target task corresponding to block 1 (including task 1 and task 2) requires two threads, then task 1 can be assigned to thread 1, task 2 can be assigned to thread 2, and the target tasks corresponding to blocks 2 and 3 can be added to the blocking queue.
[0108] Specifically, in one embodiment, the target thread is determined from the idle threads if the number of idle threads is greater than or equal to the number of threads required by at least one target task in the blocking queue.
[0109] For example, if there are target tasks 1, 2 and 3 in the blocking queue, and each of the target tasks 1-3 requires two threads, while the threads that are currently idle are threads 1-4, then it can be determined that threads 1 and 2 are the target threads for processing target task 1, and threads 3 and 4 are the target threads for processing target task 2.
[0110] Therefore, by managing threads through a dynamic thread pool, threads can be quickly allocated to the target operation when multiple blocks need to be processed in parallel. When the number of idle threads is less than the number of threads required by the target task, the target task can be added to the blocking queue, thus enabling the dynamic thread pool to adapt to various concurrent scenarios.
[0111] Optionally, in one embodiment, determining the target thread from the idle threads in the dynamic thread pool based on the target task includes:
[0112] If the number of target tasks in the blocking queue is greater than or equal to a first preset threshold when the target task is added to the blocking queue, at least one temporary thread is created in the dynamic thread pool.
[0113] The temporary thread is used to expand the dynamic thread pool.
[0114] Specifically, in one embodiment, the first preset threshold may be the maximum capacity value of the blocking queue.
[0115] Specifically, in one embodiment, the first preset threshold may be a preset value that is less than the maximum capacity of the blocking queue.
[0116] For example, if the first preset threshold is 10 units of capacity and the number of target tasks already placed in the blocking queue is 11, it can be determined that the number of target tasks in the blocking queue is greater than or equal to the first preset threshold, and at least one temporary thread can be created in the dynamic thread pool.
[0117] Specifically, in one embodiment, the created temporary thread can be used to process the target task in the blocking queue.
[0118] Specifically, in one embodiment, the created temporary thread can be used to process target tasks that are not placed in the blocking queue.
[0119] Therefore, by managing threads through a dynamic thread pool, threads can be quickly allocated to target operations that require parallel processing of multiple blocks. Temporary threads can be created in the dynamic thread pool when the number of target tasks in the blocking queue is greater than or equal to a first preset threshold, thus enabling the dynamic thread pool to adapt to various concurrent scenarios.
[0120] Optionally, in one embodiment, determining the target thread from the idle threads in the dynamic thread pool based on the target task includes:
[0121] If the number of temporary threads created is greater than or equal to a second preset threshold, perform at least one of the following operations:
[0122] Repeat the operation of adding the first target task to the blocking queue;
[0123] After waiting for a preset time, the operation of adding the first target task to the blocking queue is executed again;
[0124] Perform the operation to discard the first target task;
[0125] The first target task includes the target tasks that are not placed in the blocking queue.
[0126] For example, if the number of temporary threads already created is 11 when the second preset threshold is 10, it can be determined that the number of temporary threads created at this time is greater than or equal to the second preset threshold.
[0127] Specifically, in one embodiment, if the operation of adding the first target task to the blocking queue fails again, the operation of discarding the first target task can be performed.
[0128] Specifically, in one embodiment, if the operation of adding the first target task to the blocking queue fails again after waiting for a preset time, the operation of discarding the first target task can be performed.
[0129] Therefore, by managing threads through a dynamic thread pool, threads can be quickly allocated to target operations that require parallel processing of multiple blocks. When the number of temporary threads created is greater than or equal to a second preset threshold, the first target task can be added to the blocking queue in various ways, thus enabling the dynamic thread pool to adapt to various concurrent scenarios.
[0130] Figure 8 This is a schematic diagram of the task allocation process of the dynamic thread pool provided by the present invention, as shown below. Figure 8 As shown, the Fabric platform can maintain a thread pool consisting of a preset number of threads, which are created during program initialization. When the accounting process for a target block needs to be executed, the target task can be delegated to the target thread.
[0131] Specifically, in one embodiment, when it is necessary to execute the block verification sub-operation and the transaction verification sub-operation corresponding to the target block, the target tasks that can be generated may include task A and task B, wherein task A is used to indicate the block verification sub-operation corresponding to the target block, and task B is used to indicate the transaction verification sub-operation corresponding to the target block. Then, two target threads can be determined from the threads in the idle state in the dynamic thread pool, and task A and task B are assigned to the two target threads, one target thread is used to execute the block verification sub-operation, and the other target thread is used to execute the transaction verification sub-operation.
[0132] Once a thread task is completed, it is recycled by the thread pool and awaits the next task assignment. When the number of task requests exceeds the number maintained by the thread pool during initialization, the thread pool dynamically creates temporary threads. When the number of dynamically created temporary threads reaches a second preset threshold, the corresponding block processing logic is blocked until an idle thread becomes available to receive the task.
[0133] Specifically, in one embodiment, such as Figure 8 As shown, the Fabric platform's dynamic thread pool can manage threads according to the following logic:
[0134] Step 1: During program initialization, a preset number of independent threads are created to execute asynchronous tasks. When a task requirement arrives, any one of the threads is directly called to execute the task.
[0135] Step 2: When the number of task requests exceeds the preset number or all threads are in use, if the current blocking queue is not full (the number of target tasks in the blocking queue is less than or equal to the first preset threshold), the request is placed in the queue.
[0136] Step 3: If the current blocking queue is full (the number of target tasks in the blocking queue is greater than or equal to the first preset threshold), consider expanding the thread pool by creating temporary threads or other means.
[0137] Step 4: When the number of expansions reaches the second preset threshold (the number of temporary threads created is greater than or equal to the second preset threshold), the scheduling strategy module performs scheduling: if a specified error is returned, the Fabric platform performs at least one of the following operations: re-execute the operation of adding the first target task to the blocking queue; after waiting for a preset time, re-execute the operation of adding the first target task to the blocking queue; or execute the operation of discarding the first target task.
[0138] The blockchain accounting method provided by this invention can achieve parallel processing of accounting processes between different blocks and / or parallel processing of processes between the same block by executing at least two target operations in parallel based on a dynamic thread pool, and / or executing at least two types of sub-operations in parallel. This improves resource utilization and supports dynamically expandable thread pools to reuse thread resources, improve the execution efficiency of business logic, and thus improve the overall performance of the Fabric platform.
[0139] The blockchain accounting device provided by the present invention is described below. The blockchain accounting device described below can be referred to in correspondence with the blockchain accounting method described above.
[0140] Figure 9 This is a schematic diagram of the blockchain ledger device provided by the present invention, as shown below. Figure 9 As shown, the device includes: a determining module 901 and an execution module 902, wherein...
[0141] The determination module 901 is used by the distributed ledger platform Fabric to determine the target block to be processed for accounting.
[0142] The execution module 902 is used by the Fabric platform to execute at least two target operations in parallel based on a dynamic thread pool, and / or execute at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation;
[0143] In this context, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block.
[0144] Specifically, in one embodiment, the Fabric platform's accounting process is modularized. The first two computational sub-operations (block verification sub-operation and transaction verification sub-operation) are executed in parallel, separated from the subsequent IO sub-operations (block commit sub-operation and world state update sub-operation). Computational and IO sub-operations between different blocks are also parallelized, which can improve resource utilization and enhance the performance of the Fabric blockchain service. Additionally, a dynamically scalable thread pool is designed to reuse thread resources and improve the execution efficiency of business logic.
[0145] The blockchain accounting device provided by this invention can achieve parallel processing of accounting processes between different blocks and / or parallel processing of processes between the same block by executing at least two target operations in parallel based on a dynamic thread pool, and / or executing at least two types of sub-operations in parallel. This improves resource utilization and supports dynamically expandable thread pools to reuse thread resources, improve the execution efficiency of business logic, and thus improve the overall performance of the Fabric platform.
[0146] Optionally, in one embodiment, the execution module is further configured to:
[0147] The at least two target operations are executed in parallel in a pipeline manner.
[0148] Optionally, in one embodiment, the at least two types of sub-operations include block verification sub-operations and transaction verification sub-operations.
[0149] Optionally, in one embodiment, the execution module is further configured to:
[0150] Based on the target block, a target task is determined, wherein the target task is used to indicate the target operation corresponding to the target block;
[0151] Based on the target task, the target thread is determined from the idle threads in the dynamic thread pool;
[0152] Assign the target task to the target thread;
[0153] Based on the target thread, execute the target operation indicated by the target task.
[0154] Optionally, in one embodiment, the execution module is further configured to:
[0155] If the number of threads in the idle state is less than the number of threads required by the target task, the target task is added to the blocking queue;
[0156] If the number of threads in the idle state is greater than or equal to the number of threads required by at least one target task in the blocking queue, the target thread is determined from the threads in the idle state.
[0157] Optionally, in one embodiment, the execution module is further configured to:
[0158] If the number of target tasks in the blocking queue is greater than or equal to a first preset threshold when the target task is added to the blocking queue, at least one temporary thread is created in the dynamic thread pool.
[0159] The temporary thread is used to expand the dynamic thread pool.
[0160] Optionally, in one embodiment, the execution module is further configured to:
[0161] If the number of temporary threads created is greater than or equal to a second preset threshold, perform at least one of the following operations:
[0162] Repeat the operation of adding the first target task to the blocking queue;
[0163] After waiting for a preset time, the operation of adding the first target task to the blocking queue is executed again;
[0164] Perform the operation to discard the first target task;
[0165] The first target task includes the target tasks that are not placed in the blocking queue.
[0166] The blockchain accounting device provided by this invention can achieve parallel processing of accounting processes between different blocks and / or parallel processing of processes between the same block by executing at least two target operations in parallel based on a dynamic thread pool, and / or executing at least two types of sub-operations in parallel. This improves resource utilization and supports dynamically expandable thread pools to reuse thread resources, improve the execution efficiency of business logic, and thus improve the overall performance of the Fabric platform.
[0167] Figure 10 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 10As shown, the electronic device may include: a processor 1010, a communication interface 1020, a memory 1030, and a communication bus 1040, wherein the processor 1010, the communication interface 1020, and the memory 1030 communicate with each other via the communication bus 1040. The processor 1010 can call a computer program in the memory 1030 to execute steps of the blockchain ledger method, such as:
[0168] The distributed ledger platform Fabric determines the target block to be processed for accounting.
[0169] The Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation;
[0170] In this context, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block.
[0171] Furthermore, the logical instructions in the aforementioned memory 1030 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0172] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program stored on a non-transitory computer-readable storage medium, the computer program comprising program instructions, wherein when the program instructions are executed by a computer, the computer is able to execute the blockchain ledger method provided by the above methods, the method comprising:
[0173] The distributed ledger platform Fabric determines the target block to be processed for accounting.
[0174] The Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation;
[0175] In this context, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block.
[0176] On the other hand, embodiments of this application also provide a processor-readable storage medium storing a computer program for causing the processor to execute the methods provided in the above embodiments, such as including:
[0177] The distributed ledger platform Fabric determines the target block to be processed for accounting.
[0178] The Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation;
[0179] In this context, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block.
[0180] The processor-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic memory (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO)), optical memory (e.g., CD, DVD, BD, HVD), and semiconductor memory (e.g., ROM, EPROM, EEPROM, non-volatile memory (NAND FLASH), solid-state drive (SSD)).
[0181] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.
[0182] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.
[0183] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.
Claims
1. A blockchain ledger method, characterized in that, include: The distributed ledger platform Fabric determines the target block to be processed for accounting. The Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation; Wherein, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block; The parallel execution of at least two target operations includes: The at least two target operations are executed in parallel in a pipeline manner. The Fabric platform executes at least two target operations in parallel based on a dynamic thread pool, and / or executes at least two types of sub-operations in parallel, including: Based on the target block, a target task is determined, wherein the target task is used to indicate the target operation corresponding to the target block; Based on the target task, the target thread is determined from the idle threads in the dynamic thread pool; Assign the target task to the target thread; Based on the target thread, execute the target operation indicated by the target task; The step of determining the target thread from the idle threads in the dynamic thread pool based on the target task includes: If the number of threads in the idle state is less than the number of threads required by the target task, the target task is added to the blocking queue; When the target task is added to the blocking queue, if the number of target tasks in the blocking queue is greater than or equal to a first preset threshold, at least one temporary thread is created in the dynamic thread pool; wherein the temporary thread is used to expand the dynamic thread pool.
2. The blockchain ledger method according to claim 1, characterized in that, The at least two types of sub-operations include block verification sub-operations and transaction verification sub-operations.
3. The blockchain ledger method according to claim 1, characterized in that, The step of determining the target thread from the idle threads in the dynamic thread pool based on the target task further includes: If the number of threads in the idle state is greater than or equal to the number of threads required by at least one target task in the blocking queue, the target thread is determined from the threads in the idle state.
4. The blockchain ledger method according to claim 1, characterized in that, The step of determining the target thread from the idle threads in the dynamic thread pool based on the target task includes: If the number of temporary threads created is greater than or equal to a second preset threshold, perform at least one of the following operations: Repeat the operation of adding the first target task to the blocking queue; After waiting for a preset time, the operation of adding the first target task to the blocking queue is executed again; Perform the operation to discard the first target task; The first target task includes the target tasks that are not placed in the blocking queue.
5. A blockchain ledger device, characterized in that, include: The determination module is used by the Fabric distributed ledger platform to determine the target block to be processed for accounting. An execution module is used by the Fabric platform to execute at least two target operations in parallel based on a dynamic thread pool, and / or execute at least two types of sub-operations in parallel, wherein the at least two target operations correspond to different target blocks, and the at least two types of sub-operations belong to the same target operation; Wherein, all or some of the threads in the dynamic thread pool are used to execute the target operation at least twice, and the target operation is used to implement the accounting processing of the target block; The execution module is specifically configured to: execute the at least two target operations in parallel in a pipeline manner; determine a target task based on the target block, wherein the target task is used to indicate the target operation corresponding to the target block; determine a target thread from the idle threads in the dynamic thread pool based on the target task; assign the target task to the target thread; and execute the target operation indicated by the target task based on the target thread. The execution module is further configured to: add the target task to the blocking queue when the number of threads in the idle state is less than the number of threads required by the target task; and, when the target task is added to the blocking queue, if the number of target tasks in the blocking queue is greater than or equal to a first preset threshold, create at least one temporary thread in the dynamic thread pool; wherein the temporary thread is used to expand the dynamic thread pool.
6. An electronic device comprising a processor and a memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the blockchain ledger method according to any one of claims 1 to 4.
7. A processor-readable storage medium, characterized in that, The processor-readable storage medium stores a computer program that causes the processor to perform the steps of the blockchain ledger method according to any one of claims 1 to 4.