Dynamic adjustment method and device of block capacity, computer readable medium and electronic equipment

Abstract

This application provides a method, apparatus, computer-readable medium, and electronic device for dynamically adjusting block capacity. The method includes: for each of a plurality of blockchain nodes in a blockchain network, acquiring node load data corresponding to the processing of each block during the processing of multiple blocks, wherein each block is added to the blockchain maintained by the blockchain network after its corresponding processing; determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing of each block, so that each blockchain node can continue to execute the processing of other blocks according to the maximum block capacity. This application can dynamically adjust the block capacity according to the load of the blockchain nodes, thereby improving system performance.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a method, apparatus, computer-readable medium, and electronic device for dynamically adjusting block capacity. Background Technology

[0002] In the blockchain field, the block size affects operations such as consensus mechanisms and transaction packaging in the blockchain network.

[0003] Currently, the block size in blockchain networks is often fixed. Using a fixed block size can, in some cases, cause excessive load on nodes, leading to a decrease in the performance of the blockchain system. Summary of the Invention

[0004] The embodiments of this application provide a method, apparatus, computer-readable medium, and electronic device for dynamically adjusting block capacity, which can at least to some extent dynamically adjust the block capacity according to the load of blockchain nodes, thereby improving system performance.

[0005] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0006] According to one aspect of the embodiments of this application, a method for dynamically adjusting block capacity is provided. The method includes: for each of a plurality of blockchain nodes in a blockchain network, obtaining node load data corresponding to the processing process of each block in the processing of the plurality of blocks, wherein each block is added to the blockchain maintained by the blockchain network after its corresponding processing process; determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing process of each block, so that each blockchain node continues to execute the processing process of other blocks according to the maximum block capacity.

[0007] According to one aspect of the embodiments of this application, a dynamic adjustment device for block capacity is provided. The device includes: a load data acquisition unit, configured to acquire, for each of a plurality of blockchain nodes in a blockchain network, node load data corresponding to the processing process of each block in the processing of the plurality of blocks, wherein each block is added to the blockchain maintained by the blockchain network after its corresponding processing process; and a block capacity determination unit, configured to determine the maximum block capacity of each blockchain node based on the node load data corresponding to the processing process of each block, so that each blockchain node can continue to execute the processing process of other blocks according to the maximum block capacity.

[0008] In some embodiments of this application, based on the foregoing scheme, the load data acquisition unit is configured to: acquire node load data corresponding to the processing process of each block in the processing of the blockchain node and multiple blocks from the sensing block of the blockchain, wherein the node load data is packaged into the sensing block in the form of transactions.

[0009] In some embodiments of this application, based on the foregoing scheme, the node load data corresponding to the processing of each block of the blockchain node is determined based on the indicator data corresponding to at least one indicator collected from the blockchain node during the processing of the block, wherein the indicator data is collected by the sensor in the blockchain node.

[0010] In some embodiments of this application, based on the foregoing scheme, the node load data corresponding to the processing of each block of the blockchain node is determined based on the statistical data of indicators corresponding to at least one indicator during the processing of the block. The statistical data of indicators corresponding to each indicator is determined based on at least one indicator data corresponding to the indicator collected from the blockchain node during the processing of the block.

[0011] In some embodiments of this application, based on the foregoing scheme, the node load data corresponding to the processing of each block of the blockchain node is the largest indicator statistical data among the indicator statistical data corresponding to at least one indicator.

[0012] In some embodiments of this application, based on the foregoing scheme, the transaction further includes a signature generated by the private key of the blockchain node for the node load data corresponding to the processing process of the blockchain node and multiple blocks. The device further includes a verification and elimination unit. The load data acquisition unit is configured to: acquire the node load data corresponding to the processing process of each block and the signature from the sensing blocks of the blockchain. Before determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing process of each block, the verification and elimination unit is used to: verify the signature based on the node load data corresponding to the processing process of the blockchain node and multiple blocks and the public key of the blockchain node; if the signature verification fails, the node load data corresponding to the processing process of the blockchain node and multiple blocks is eliminated.

[0013] In some embodiments of this application, based on the foregoing scheme, the apparatus further includes a block capacity acquisition unit; before determining the maximum block capacity of each blockchain node according to the node load data corresponding to the processing process of each blockchain node and each block, the block capacity acquisition unit is used to: acquire the block capacity of each block among the plurality of blocks respectively; the block capacity determination unit is configured to: determine the maximum block capacity of each blockchain node according to the node load data corresponding to the processing process of each blockchain node and each block, and the block capacity of each block.

[0014] In some embodiments of this application, based on the foregoing scheme, the block capacity determination unit is configured to: determine the average block capacity of the plurality of blocks according to the block capacity of each block; for each blockchain node, determine the average value of each node load data according to the node load data corresponding to the processing process of each blockchain node and each block; for each blockchain node, determine the candidate maximum block capacity of the blockchain node according to the average block capacity of the plurality of blocks and the average value of each node load data determined for the blockchain node; and determine the maximum block capacity of each blockchain node according to the candidate maximum block capacity of each blockchain node.

[0015] In some embodiments of this application, based on the foregoing scheme, the block capacity determination unit is configured to: determine the original maximum block capacity that each blockchain node can accept based on the node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block; determine an adjustment coefficient for the original maximum block capacity based on the current maximum block capacity that each blockchain node can accept and the original maximum block capacity that each blockchain node can accept; and adjust the original maximum block capacity according to the adjustment coefficient to obtain the new maximum block capacity of each blockchain node.

[0016] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method for dynamically adjusting block capacity as described in the above embodiments.

[0017] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the block capacity dynamic adjustment method as described in the above embodiments.

[0018] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions, causing the computer device to perform the block capacity dynamic adjustment method as described in the above embodiments.

[0019] In some embodiments of this application, the technical solutions provided first obtain the node load data corresponding to the processing of each block in the processing of multiple blocks for each blockchain node. Then, based on the node load data corresponding to the processing of each blockchain node and each block, the maximum block capacity that each blockchain node can accept is determined. This realizes the dynamic adjustment of the maximum block capacity according to the load of the blockchain node, which can reduce the dependence on human experience and effectively alleviate the problem of excessive node load caused by excessively large blocks, thereby improving system performance.

[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0022] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown;

[0023] Figure 2 A flowchart of a method for dynamically adjusting block capacity according to an embodiment of this application is shown;

[0024] Figure 3 A schematic diagram of a smart contract-based consortium blockchain node load awareness on-chain process according to an embodiment of this application is shown.

[0025] Figure 4 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 210 in the embodiment;

[0026] Figure 5 An embodiment according to this application is shown. Figure 4Details of step 210' and flowcharts of steps preceding step 250 in the embodiment;

[0027] Figure 6 A schematic diagram of a consensus process for block size in a consortium blockchain based on a perceptual contract, according to an embodiment of this application, is shown.

[0028] Figure 7 An embodiment according to this application is shown. Figure 2 A flowchart of the steps preceding step 250 and details of step 250 in the embodiment;

[0029] Figure 8 A flowchart illustrating the determination of the maximum block capacity of each blockchain node based on node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block, according to an embodiment of this application, is shown.

[0030] Figure 9 A flowchart illustrating the determination of the maximum block capacity of each blockchain node based on node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block, according to an embodiment of this application, is shown.

[0031] Figure 10 A block diagram of a dynamic adjustment device for block capacity according to an embodiment of this application is shown;

[0032] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0033] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0034] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0035] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0036] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0037] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0038] A blockchain is a data structure consisting of several blocks linked together by hash values. Each block consists of transactions generated within a certain period of time, packaged by computer nodes that have the right to record transactions, and independently verified by each computer node.

[0039] Different blockchain nodes form a consortium of participants, and the blockchain system jointly maintained by these consortium participants is called a consortium blockchain system.

[0040] In related technologies, consortium blockchain systems, such as Chang'an Chain and FISCO-BCOS, often have their block sizes set manually based on experience at system startup, and these settings are often unable to be adjusted subsequently or dynamically adjusted according to node load. Furthermore, current consortium blockchain systems cannot perceive node load on-chain, and adjusting the block size often requires manual intervention and coordination, making it difficult to reach consensus among all network nodes.

[0041] Therefore, the solutions of related technologies mainly have the following drawbacks:

[0042] 1. On-chain detection of node load is impossible. Currently, workload performance monitoring of blockchain nodes is often off-chain, making it impossible to view the computing, storage, and other resource usage of each node on-chain, i.e., the node load cannot be perceived.

[0043] 2. Difficulty in reaching consensus on block size adjustments. If the block size is adjusted based on business needs and node load, this process often requires manual intervention and coordination, making it difficult to reach a consensus among all nodes in the network.

[0044] The inventors of this application discovered that during the operation of a blockchain system, operations such as consensus mechanisms and transaction packaging are significantly affected by block size. Block size directly relates to system performance; excessively small blocks increase transaction latency, while excessively large blocks overload nodes. However, current consortium blockchains often pre-determine block sizes based on experience, which requires a high level of expertise from personnel, fails to consider dynamic adjustments based on the load of blockchain nodes, and often fails to achieve rapid consensus across the entire network.

[0045] To address the issues of on-chain load perception and difficulty in reaching consensus on block size (block capacity) in blockchain full nodes, this application first provides a method for dynamically adjusting block capacity. The dynamic block capacity adjustment method provided in this application overcomes the aforementioned deficiencies of related technologies. It can adjust block capacity by perceiving network-wide load consensus, thereby improving system performance and reducing reliance on human experience. Here, a full node refers to a complete node that maintains the blockchain, capable of independently packaging and verifying transactions and handling client read / write requests for smart contract states.

[0046] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown. For example... Figure 1 As shown, the system architecture 100 may include multiple user terminals and a blockchain network 140. Specifically, the multiple user terminals may include a first user terminal 110, a second user terminal 120, and a third user terminal 130. The blockchain network 140 includes multiple blockchain nodes, specifically a first blockchain node 141, a second blockchain node 142, a third blockchain node 143, a fourth blockchain node 144, and a fifth blockchain node 145. Each user terminal is connected to the blockchain network 140 via a communication link, enabling each user terminal to communicate with any blockchain node in the blockchain network 140. A communication connection is established between any two blockchain nodes in the blockchain network 140, and any two blockchain nodes in the blockchain network 140 can also communicate with each other. Each blockchain node is deployed with a sensing contract, a sensor, and an accounting program, and stores and maintains the blockchain. Each user terminal is deployed with a client that can access each blockchain node located in the blockchain network 140. Each blockchain node in the blockchain network 140 can be the execution subject of the scheme in this application embodiment. When the dynamic adjustment method for block capacity provided in this application is applied... Figure 1In the system architecture shown, a process can be as follows: First, users on each user terminal continuously send transaction requests carrying transactions to each blockchain node in the blockchain network 140 through the client on their user terminal. Each blockchain node in the blockchain network 140, upon receiving a transaction request from the client, retrieves the transactions in the request. When a blockchain node retrieves a sufficient number of transactions based on the maximum acceptable block capacity, it packages these transactions into a block and synchronously sends the block to other blockchain nodes in the blockchain network for consensus. When consensus on the block is passed, each blockchain node adds the block to the blockchain for on-chain storage. The process of packaging transactions into on-chain storage for each block is part of the block's processing. During the processing of each block, each blockchain node in the blockchain network 140 collects data through sensors deployed on it. The current node load data of the blockchain node; after the sensor on each blockchain node collects the node load data of the blockchain node in the processing of all blocks, it calls the accounting program on the blockchain node. The accounting program generates load transactions based on these node load data and forwards the load transactions to the load transaction packaging node in the blockchain network 140, which is defined by the consensus mechanism used by the blockchain network 140. The load transaction packaging node will package the load transactions into a sensing block in the same way as packaging ordinary transactions, and add the sensing block to the blockchain for on-chain storage; finally, each blockchain node will read the load transactions from the sensing blocks of the blockchain by calling the sensing contract, obtain the node load data corresponding to the processing of each blockchain node and each block, and calculate the new acceptable maximum block capacity based on the node load data corresponding to the processing of each blockchain node and each block.

[0047] In some embodiments of this application, the load transaction packaging node defined by the consensus mechanism is a fixed blockchain node in the blockchain network 140.

[0048] In some embodiments of this application, the load transaction packaging node defined by the consensus mechanism is a blockchain node determined under a round-robin rule; under the round-robin rule, each blockchain node serves as the load transaction packaging node in turn.

[0049] In some embodiments of this application, the load transaction packaging node defined by the consensus mechanism is a blockchain node corresponding to the current time period. Each blockchain node in the blockchain network corresponds to a time period, and each blockchain node is responsible for packaging the load transactions generated within that time period.

[0050] In some embodiments of this application, the correspondence between each blockchain node and time period is updated periodically.

[0051] In some embodiments of this application, the blockchain node packages the acquired transactions into blocks of the largest acceptable block size.

[0052] In some embodiments of this application, after a blockchain node receives a transaction, it executes the transaction; the blockchain node packages multiple transactions and the execution result corresponding to each transaction into a block.

[0053] In some embodiments of this application, the block processing procedure also includes the execution of the corresponding transaction.

[0054] In some embodiments of this application, the blockchain network is also provided with a node load data synchronization mechanism between different blockchain nodes. After a sensor on a blockchain node collects the node load data of the blockchain node during the processing of all blocks, if the accounting program on the blockchain node is in a busy state, the sensor on the blockchain node will synchronize the node load data to the sensors on other blockchain nodes, and the accounting program on other blockchain nodes will generate load transactions based on these node load data.

[0055] It should be understood that Figure 1 The number of user terminals and blockchain nodes in the blockchain network shown are merely illustrative. Depending on implementation needs, there can be any number of user terminals, and the number of blockchain nodes in the blockchain network can also be arbitrary; that is, the number of user terminals can be more than or less than 3, and the number of blockchain nodes in the blockchain network can be more than or less than 5.

[0056] It should be noted that, Figure 1 The illustration shown is merely one embodiment of this application. Although in Figure 1 In the embodiment, each blockchain node in the blockchain network is a server, and each user terminal is a desktop computer. However, in other embodiments of this application, the blockchain nodes and user terminals can also be various types of terminal devices such as laptops, desktop computers, tablets, vehicle terminals, portable wearable devices, and workstations. Furthermore, different types of blockchain nodes and different types of user terminals can also be different. Figure 1 In the embodiment, all load transactions generated by blockchain nodes are packaged into a single sensing block. However, in other embodiments of this application, only a subset of load transactions generated by blockchain nodes can be packaged into a single sensing block each time a sensing block is packaged. Thus, multiple sensing blocks can be obtained based on the load transactions generated by all blockchain nodes. Furthermore, each load transaction can be packaged into a sensing block by each ledger program on each blockchain node. Although in Figure 1In the embodiment, each transaction is packaged into a block by the blockchain node that receives the transaction. However, in other embodiments of this application, there may also be ledger nodes in the blockchain network. After receiving the transaction, each ordinary blockchain node can forward the transaction to a ledger node (e.g., the ledger node closest to the blockchain node), which is then responsible for packaging the transaction onto the chain. Although in Figure 1 In the embodiment, transactions executed on a blockchain node are obtained directly from the user terminal by that blockchain node. However, in other embodiments of this application, transactions executed on a blockchain node can also be obtained by that blockchain node from other blockchain nodes. For example, when a blockchain node lacks resources, it can forward the transactions it receives to other blockchain nodes for execution. Although in Figure 1 In the embodiments described, each blockchain node is equipped with a sensor and a ledger program. However, in other embodiments of this application, the sensor and ledger program may be deployed only on some blockchain nodes. For example, the sensor and ledger program may be deployed only on blockchain nodes that have historically experienced overload alerts. This application does not limit the scope of protection in any way.

[0057] It is easy to understand that the dynamic block capacity adjustment method provided in the embodiments of this application is generally executed by a server, and correspondingly, the dynamic block capacity adjustment device is generally located in the server. However, in other embodiments of this application, the terminal device may also have similar functions to the server, thereby executing the dynamic block capacity adjustment scheme provided in the embodiments of this application.

[0058] Therefore, the embodiments of this application can be applied to terminals or servers. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions.

[0059] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0060] Figure 2A flowchart illustrating a method for dynamically adjusting block capacity according to an embodiment of this application is shown. This method can be executed by various devices with processing and computational capabilities that can function as blockchain nodes. Specifically, it can be executed by a target device, such as a user terminal or a cloud server. User terminals include, but are not limited to, mobile phones, computers, smart voice interaction devices, smart home appliances, vehicle terminals, aircraft, smartwatches, etc. Please refer to... Figure 2 As shown, the method for dynamically adjusting the block capacity includes at least the following steps:

[0061] In step 210, for each of the multiple blockchain nodes in the blockchain network, the node load data corresponding to the processing process of each block in the processing of the blockchain node and multiple blocks is obtained, wherein each block is added to the blockchain maintained by the blockchain network after its corresponding processing process.

[0062] The blockchain network here can be a consortium blockchain network, a public blockchain network, or other types of blockchain networks.

[0063] A blockchain network can include multiple blockchain nodes that can communicate with each other. These multiple blockchain nodes can be all blockchain nodes in the blockchain network, or they can be a subset of the blockchain nodes. The following example illustrates the solution of this application embodiment using the scenario of all blockchain nodes in the blockchain network.

[0064] The processing of multiple blocks can be completed before the current moment. The block processing process can include the complete process from transaction packaging to block uploading, and can further include the execution of the acquired transactions used to package them into a block. Therefore, the block processing process can specifically include three stages: transaction execution stage, transaction packaging stage, and block synchronization and uploading stage.

[0065] Different blocks may be packaged by different blockchain nodes. Therefore, the processing of different blocks will impose different loads on different blockchain nodes.

[0066] Although the entire block processing process may not continuously load every blockchain node. For example, during the transaction execution phase, it may only load one or a few blockchain nodes. Specifically, each transaction is usually executed on one blockchain node; similarly, the transaction packaging phase usually only loads the blockchain node responsible for packaging transactions into blocks.

[0067] However, in this embodiment of the application, the load data of each blockchain node during the processing of each block will be collected. Therefore, for the processing of each block, the node load data of each blockchain node corresponding to the processing of that block can be obtained.

[0068] In one embodiment of this application, the processing of multiple blocks is the processing of all blocks that are completed within a predetermined time period before the current time.

[0069] The predetermined time period can start from the moment before the current moment when the predetermined duration has elapsed, and end at the current moment. Once the processing of a block is completed within this predetermined time period, it constitutes the processing of one block within a larger block processing sequence.

[0070] Of course, the processing of multiple blocks can also be the processing of some blocks that will be completed within a predetermined time period before the current moment.

[0071] Specifically, a predetermined number of block processing steps can be randomly selected from the processing of all blocks that finished within a predetermined time period before the current time, to form multiple block processing steps. Alternatively, a predetermined proportion of block processing steps can be randomly selected from the processing of all blocks that finished within the predetermined time period before the current time, to form multiple block processing steps. For example, if the processing of all blocks that finished within the predetermined time period before the current time includes 20 block processing steps, and the predetermined proportion is 50%, then 20 × 50% = 10 block processing steps can be randomly selected from these 20 block processing steps to form multiple block processing steps. Of course, the number of block processing steps to be randomly selected can also be determined based on the number of all block processing steps that finished within the predetermined time period before the current time. For example, a correspondence table between processing step number ranges and selection quantities can be pre-set. This correspondence table includes multiple processing step number ranges and the corresponding selection quantities for each processing step number range. By querying this correspondence table, the number of block processing steps to be randomly selected can be determined.

[0072] Of course, the processing steps for multiple blocks don't have to be randomly selected from the processing steps of all blocks. For example, you can start from the processing steps of the first block and select the processing steps for the next block after every other block.

[0073] In one embodiment of this application, the processing of multiple blocks is the processing of multiple consecutive blocks prior to the current time.

[0074] Since each block is added to the blockchain after its processing, and the blockchain consists of multiple consecutive blocks, the processing of multiple consecutive blocks before the current moment is actually the processing of multiple consecutive blocks that were added to the blockchain before the current moment.

[0075] In one embodiment of this application, the processing of multiple blocks is the processing of the most recently completed consecutive blocks up to the current time.

[0076] In other words, the processing of multiple blocks can be the processing of the latest consecutive blocks added to the blockchain before the current moment.

[0077] Although the processing of multiple blocks in the foregoing embodiments is determined based on a time range, it can actually be determined solely based on the number of processing steps for each block. For example, the processing of multiple blocks can be the processing of K blocks, specifically the processing of the K most recently completed blocks up to the current time. K can be an integer greater than 1, such as 100.

[0078] Therefore, in this embodiment of the application, the processing of K blocks can be taken as a cycle. At the end of each cycle, the node load data corresponding to the processing of each block in the cycle can be obtained, and the maximum block capacity to be set in the next cycle can be determined based on these node load data.

[0079] Of course, the processing of multiple blocks can also be the processing of K blocks randomly sampled from the processing of the most recently completed consecutive blocks. That is, the processing of K blocks does not have to be a consecutive block processing process.

[0080] Figure 3 A schematic diagram illustrating the on-chain load-aware process of a smart contract-based consortium blockchain node according to an embodiment of this application is shown. Please refer to... Figure 3As shown, this consortium blockchain network includes three nodes: Node A, Node B, and Node C. Each node includes a sensor and a ledger program. For example, Node A includes sensor A and ledger program A, Node B includes sensor B and ledger program B, and Node C includes sensor C and ledger program C. The consortium blockchain nodes are those that actually run the blockchain ledger program and load sensor. The ledger program is the blockchain node program that maintains the state data of the blockchain world and processes blockchain transactions. The sensor is used to sense the node's original load data and calculate the node's load data based on this data. The sensor can also call the ledger program to upload the node's load data as a transaction to the blockchain. The sensor can obtain the node's original load data by calling an operating system interface. Figure 3 The document also shows historical blocks, including blocks NK to N-1, which are added to the blockchain. Block N-1 represents the most recently added block in the historical blocks, and block NK represents the earliest added block in the historical blocks. Therefore, the historical blocks here correspond to the K blocks involved in the processing of the aforementioned K blocks.

[0081] Figure 4 An embodiment according to this application is shown. Figure 2 A flowchart detailing step 210 in the embodiment is provided. Please refer to [link / reference]. Figure 4 As shown, obtaining the node load data corresponding to the processing of each block in the blockchain node and multiple blocks can specifically include the following steps:

[0082] In step 210', the node load data corresponding to the processing process of each block in the blockchain node and multiple blocks is obtained from the sensing block of the blockchain. The node load data is packaged into sensing blocks in the form of transactions.

[0083] The perception block can include node load data corresponding to the processing of each blockchain node and each block. In the perception block, node load data exists in the form of transactions.

[0084] Figure 3 The diagram also illustrates a perceptual block, which is added to the blockchain after a historical block is added to it; therefore, the perceptual block is Block N. Within the blockchain, a perceptual block can be located after a historical block.

[0085] The following section details how to obtain the perception block.

[0086] Please continue reading Figure 3As shown, the on-chain process of load awareness for consortium blockchain nodes based on smart contracts can specifically include the following steps:

[0087] 1. Pack / synchronize historical blocks.

[0088] In this embodiment of the application, it is necessary to collect the original load data of the blockchain node during the packaging and synchronization of historical blocks.

[0089] Of course, the original load data of the blockchain nodes can also be collected during the execution of each transaction used to package them into historical blocks.

[0090] Historical blocks can be the K most recently added blocks to the chain. In this embodiment, the processing time for K blocks constitutes one cycle, and the block capacity is adjusted every cycle. Therefore, the block capacity can be adjusted when block N is added to the chain. This approach reduces the impact on the complexity of the consensus mechanism and also reduces the overhead of computational resources.

[0091] Specifically, the blocks of load data that need to be perceived during the corresponding processing are as follows:

[0092] SenseBlocks = {Block i}(NK≤i <N-1),

[0093] SenseBlocks refers to the blocks that need to sense load data during their corresponding processing, which are the multiple blocks that can obtain node load data in step 210.

[0094] In one embodiment of this application, the node load data corresponding to the processing of each block of the blockchain node is determined based on the indicator data corresponding to at least one indicator collected from the blockchain node during the processing of that block. The indicator data is collected by the sensor in the blockchain node.

[0095] At least one metric may include at least one of the following: CPU utilization, memory utilization, and disk I / O utilization.

[0096] At least one metric can also include CPU utilization, memory utilization, and disk I / O utilization simultaneously.

[0097] Of course, at least one metric can also include other metrics, such as network usage.

[0098] The metric data can be the original load data of the aforementioned blockchain nodes. The metric data corresponding to each metric is the metric value, which can be expressed as a percentage of utilization. For example, the metric data corresponding to CPU utilization can be 70%, the metric data corresponding to memory utilization can be 50%, and the metric data corresponding to disk I / O utilization can be 80%.

[0099] Please continue reading Figure 3 As shown, after step 1, the following steps may also be included:

[0100] 2. Sensing CPU / Memory / IO.

[0101] The load on a blockchain node's CPU, memory, and disk I / O can be sensed through sensors on the node itself. For the j-th node:

[0102] CPU j =GET_CPU()

[0103] MEM j =GET_MEM()

[0104] IO j =GET_IO()

[0105] Here, GET* is a function that calls the operating system interface to obtain the corresponding CPU, memory, and disk I / O load percentages. Therefore, the CPU utilization of the j-th node can be obtained. j Memory usage (MEM) j and disk I / O utilization j .

[0106] In one embodiment of this application, the node load data corresponding to the processing of each block of the blockchain node is determined based on the statistical data of indicators corresponding to at least one indicator during the processing of the block. The statistical data of each indicator is determined based on the at least one indicator data corresponding to the indicator collected from the blockchain node during the processing of the block.

[0107] During the processing of a block, for each indicator, one or more indicator data corresponding to that indicator can be collected. By statistically analyzing the one or more indicator data corresponding to that indicator, the indicator statistics data corresponding to that indicator can be obtained.

[0108] Specifically, for each indicator, the median or average of the corresponding indicator data can be determined as the statistical data for that indicator.

[0109] Of course, if multiple data points are collected for each indicator, only a portion of the data can be used to obtain the corresponding statistical data. For example, a predetermined number of data points can be randomly sampled from multiple data points, and the corresponding statistical data can be calculated based on these predetermined number of data points; another example is that the maximum and minimum values ​​of multiple data points can be removed, and the statistical data can be calculated based on the remaining data points.

[0110] During the processing of a block, the amount of indicator data collected for different indicators can be the same or different.

[0111] Of course, statistical data for a given indicator can also be obtained through other methods. For example, since the processing of each block can include three stages: transaction execution, transaction packaging, and block synchronization and on-chain processing, for each indicator, at least two data points corresponding to that indicator can be collected at each stage. Then, by determining the average, median, or other values ​​of these two data points, the statistical result for that stage corresponding to the indicator can be obtained. After obtaining the statistical results for different stages, a weighted sum of these results can be calculated based on the weights of each stage, serving as the statistical data for that indicator. The weights for different stages can be different. The statistical data for all indicators can be determined using the above method.

[0112] In this embodiment of the application, indicator data is collected in stages, and the indicator statistics corresponding to each stage are obtained. Then, the final indicator statistics are obtained by calculating the weighted sum of the indicator statistics of different stages. Therefore, when calculating the final indicator statistics, the influence of different stages is taken into account, and the indicator statistics can be calculated more accurately, so as to achieve more accurate updating of block capacity.

[0113] In one embodiment of this application, the node load data corresponding to the processing of each block of a blockchain node is the maximum indicator statistical data among the indicator statistical data corresponding to at least one indicator.

[0114] After obtaining the statistical data of each indicator during the processing of a block, the node load data corresponding to the processing of that block can be obtained by determining the maximum value of the statistical data of each indicator.

[0115] Specifically, the node load data of node j corresponding to the processing of a block can be obtained in the following way:

[0116] P j=MAX(CPU) j MEM j IO j ),

[0117] Where MAX is a function to obtain the maximum value of the statistical data corresponding to each indicator, and P j This is the node load data for node j corresponding to the processing of a block.

[0118] The node load data of node j corresponding to the processing of a block can be calculated immediately after the processing of that block ends, or it can be calculated after the processing of all blocks ends.

[0119] In this embodiment of the application, by determining the maximum value of the statistical data corresponding to each indicator as the node load data corresponding to the block processing process, the node load data can reflect the resources that the node lacks the most, thereby enabling the final determined block capacity to match the actual state of each node more accurately.

[0120] For node j, during the processing of each block i, the corresponding node load data P is calculated. j After processing through K blocks, the following data can be obtained:

[0121] <P j ,P j ,P j ,P j ,…,P j >(A total of K P) j ).

[0122] Please continue reading Figure 3 As shown, after step 2, the following steps may also be included:

[0123] 3. Generate percentage and signature.

[0124] The percentage here refers to the node load data of node j corresponding to the processing of each block, calculated by the sensor in the blockchain node. This node load data is presented as a percentage.

[0125] After obtaining the node load data corresponding to the processing of each block for node j, the sensor in a node will call the accounting program in that node. The accounting program will use the node's private key to sign the node load data corresponding to the processing of each block, and generate a transaction (i.e., a load-aware transaction) based on the node load data and the signature, and add the transaction to the blockchain.

[0126] The node load data corresponding to the processing of each block can be arranged in chronological order; then, a digest of the arrangement result can be obtained through a digest algorithm; finally, the digest can be asymmetrically encrypted using the private key of the node to obtain the corresponding digital signature.

[0127] Specifically, in a blockchain network, a consensus mechanism determines the blockchain node responsible for packaging the received load-aware transactions into a sensing block. After other blockchain nodes generate load-aware transactions through their accounting programs, they forward the load-aware transactions to the blockchain node responsible for packaging them. The blockchain node responsible for packaging the load-aware transactions will then package the received load-aware transactions into a sensing block and upload the sensing block to the blockchain.

[0128] exist Figure 3 In this system, the sensors on different nodes can communicate with each other, which allows a sensor on one node to forward the node load data generated on that node to the sensors on other nodes, and the sensors on other nodes are responsible for generating transactions from this node load data.

[0129] In one embodiment of this application, the transaction further includes a signature generated based on the private key of the blockchain node for the node load data corresponding to the processing of multiple blocks by the blockchain node.

[0130] Each transaction generated on a blockchain node includes node load data obtained for that blockchain node and a signature generated based on that node load data.

[0131] Please continue reading Figure 3 As shown, after step 3, the following steps may also be included:

[0132] 4. Write the perception smart contract.

[0133] Smart contracts are computer programs that can automatically execute contract terms, possessing characteristics such as event-driven nature, value transfer, and automatic execution. Aware smart contracts are also known as awareness contracts.

[0134] Figure 3 The diagram also illustrates a perceptual contract, used for calculating block size. The perceptual contract executes independently and reaches consensus across nodes, ensuring consistency in block size calculations across all nodes. All blockchain nodes can have the same perceptual contract.

[0135] Specifically, a storage space (such as memory space) corresponding to the perception contract can be allocated on each blockchain node, and the content of transactions in the perception block can be written into this storage space.

[0136] Specifically, this storage space can contain a mapping called Performance, where the key is the block number of the sensing block, i.e., N, and the values ​​are a two-dimensional array used to store the node load data corresponding to the processing of each node and each block, as follows:

[0137] Contract.Performance[N] = {P} j,i},

[0138] Where N is the block number of the sensing block, P j,i This represents the node load data corresponding to the processing of node j and block i.

[0139] This storage space can also contain a mapping called Signature, whose key is also N, and whose value is the signature submitted by each node. This mapping is as follows:

[0140] Contract.Signature[N] = {Sig j},

[0141] Among them, Sig j This represents the signature submitted by node j.

[0142] Please continue reading Figure 3 As shown, after step 4, the following steps may also be included:

[0143] 5. Calculate and update the block size.

[0144] After all M nodes have submitted their node load data corresponding to blocks NK to N-1, each blockchain node calls its smart contract to calculate the node load data, thereby obtaining the block size adjustment result. Note that the start of the calculation and the time of updating the block size are determined by each node itself, because it only reads, does not write, load data and does not affect the consistency of load data across the entire network. The specific calculation method for the block size will be described in detail below.

[0145] In one embodiment of this application, obtaining node load data corresponding to the processing process of each block in the processing of multiple blocks from the sensing block of the blockchain includes: obtaining node load data corresponding to the processing process of each block in the processing of multiple blocks from the sensing block of the blockchain through the sensing smart contract in the blockchain node.

[0146] After packaging and storing the node load data into the sensing block, the maximum block capacity corresponding to this sensing cycle needs to be obtained through the sensing smart contract based on this node load data. This can be done by first obtaining the node load data or transactions containing node load data from the sensing block, and then calculating the maximum block capacity based on the node load data or transactions containing node load data.

[0147] Figure 5 An embodiment according to this application is shown. Figure 4 Details of step 210' and flowcharts of steps preceding step 250 in the embodiment are provided. Please refer to [link / reference]. Figure 5 As shown, obtaining node load data corresponding to the processing process of each block in the blockchain node's processing of multiple blocks from the blockchain's sensing block can include:

[0148] In step 210", the signature and node load data corresponding to the processing process of each block are obtained from the sensing block of the blockchain.

[0149] In this embodiment of the application, it is necessary not only to obtain node load data, but also to obtain a signature in order to verify the legality of the data.

[0150] Figure 6 A schematic diagram illustrating a consensus process for block size in a consortium blockchain based on a contract-aware architecture, according to an embodiment of this application, is shown. Please refer to... Figure 6 As shown, the data used for block size calculation is the on-chain transaction of the perception record. The on-chain transaction of the perception record is the aforementioned load perception transaction, which can be stored in the storage space corresponding to the perception contract. Figure 6 M sensing record on-chain transactions (Tx) are shown, which can correspond to M nodes respectively. Each sensing record on-chain transaction (Tx) is the node load data corresponding to the processing process of a blockchain node and each block in this sensing cycle.

[0151] Figure 6 The modules below the perception contract are all built-in computing modules of the perception contract.

[0152] Please continue reading Figure 5 As shown, before determining the maximum block capacity of each blockchain node in step 250 based on the node load data corresponding to the processing of each blockchain node and each block, the method may include the following steps:

[0153] In step 220, the signature is verified based on the node load data corresponding to the processing of multiple blocks by the blockchain node and the public key of the blockchain node.

[0154] Each blockchain node can store the public keys of all blockchain nodes, including the one containing the blockchain node. The perceptual contract can use the public keys of each blockchain node to verify the signatures provided by each blockchain node.

[0155] The node load data corresponding to the processing of multiple blocks of the blockchain node can be arranged in chronological order, and a digest of the arrangement result can be obtained using a digest algorithm. Then, the signature can be decrypted using the public key of the blockchain node to obtain the decrypted digest. Finally, the signature is verified by comparing the digest of the arrangement result obtained by the digest algorithm with the decrypted digest.

[0156] In step 230, if the signature verification fails, the node load data corresponding to the processing of multiple blocks of the blockchain node will be removed.

[0157] When the blockchain node's perception contract verifies each signature, if a signature fails verification, it skips the node load data of the corresponding node, that is, it does not use the node load data of the corresponding node to calculate the maximum block capacity.

[0158] Please see Figure 6 As shown, the consensus process for block size in a consortium blockchain based on perceptual contracts may specifically include the following steps:

[0159] 1. Read the perception record.

[0160] <[P1,P2,...,PK],Sig> can be read from the storage space corresponding to the perception contract, where PK represents the node load data corresponding to the processing of the node and the Kth block, and Sig represents the signature generated according to [P1,P2,...,PK].

[0161] Specifically, for each node j, signature verification can be performed as follows: Res = Valid(Contract.Performance[N][j][:],Contract.Signature[N][j],PK j ), where Valid is the signature verification function, and the parameter PK j Let be the public key of node j.

[0162] If any of the above signature verification processes fail, i.e., the Res value is False, then the data submitted by node j is considered incorrect, and the data of that node is skipped.

[0163] Figure 7 An embodiment according to this application is shown. Figure 2 A flowchart detailing the steps preceding step 250 and step 250 itself is provided in this embodiment. Please refer to [link / reference needed]. Figure 7As shown, before determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing of each blockchain node and each block, the method may further include the following steps:

[0164] In step 240, the block capacity of each block in the multiple blocks is obtained respectively.

[0165] Block capacity is the same as block size. Block capacity can be either the amount of data that a block can contain or the number of transactions that a block can contain.

[0166] Please continue reading Figure 6 As shown, after step 1, the following steps may also be included:

[0167] 2. Read the block size.

[0168] The SenseBlocks contract can obtain the block size of historical blocks on the running blockchain by calling the environment variable retrieval function SIZEOF. Specifically, for each block in SenseBlocks, the block size can be obtained as follows:

[0169] SenseBlockSizes={SIZEOF(Block i )}(NK≤i <N-1),

[0170] SenseBlockSizes is the set of block sizes for all blocks, and each element is referred to as SenseBlockSize below. i .

[0171] In one embodiment of this application, before step 250, the method may further include the following steps: for each blockchain node, removing outlier data from the node load data corresponding to the processing of each blockchain node and each block.

[0172] Step 250 can be performed based on the remaining node load data after removing outliers.

[0173] In this embodiment of the application, by removing outlier data, the accuracy of the calculated maximum block capacity can be improved to a certain extent.

[0174] Please continue reading Figure 6 As shown, after step 2, the following steps may also be included:

[0175] 3. Remove outliers.

[0176] For the validated and valid Contract.Performance[N][j][:], i.e., the load data of node j, it is necessary to call a regular outlier removal algorithm function (such as a regular outlier removal algorithm based on the mean, variance, etc.) and construct a temporary array to record the Performance after removing outliers, as follows:

[0177] TempPerformance[N][j][:]=ADJUST(Contract.Performance[N][j][:]),

[0178] ADJUST is the outlier removal algorithm function, which is executed for each node j of Performance[N].

[0179] The maximum block capacity can be calculated using the regular points after removing outliers.

[0180] In step 250, the maximum block capacity of each blockchain node is determined based on the node load data corresponding to the processing of each blockchain node and each block, so that each blockchain node can continue to execute the processing of other blocks according to the maximum block capacity.

[0181] In this embodiment of the application, the block capacity can be the amount of data that can be contained in the block, or the number of transactions that can be contained in the block.

[0182] The maximum block capacity of each blockchain node is the maximum block capacity that each blockchain node can accept (the maximum acceptable block size). Each blockchain node can use the maximum block capacity as the upper limit of the acceptable block size and continue to process other blocks.

[0183] The maximum acceptable block size is the upper limit of the block size. The maximum acceptable block size for each blockchain node is the maximum block size used by all blockchain nodes. When processing other blocks, each blockchain node can only process blocks whose actual block size is smaller than this maximum block size. For example, when a blockchain node generates a new block, the size of the resulting block cannot exceed this maximum block size.

[0184] Each blockchain node can independently calculate the maximum block capacity by calling its perception contract. After obtaining the maximum block capacity that all blockchain nodes can accept, a blockchain node can configure the maximum block capacity on that blockchain node.

[0185] In one embodiment of the present application, determining the maximum block capacity of each blockchain node based on the node load data respectively corresponding to the processing processes of each blockchain node and each block includes: determining the maximum block capacity that each blockchain node can accept through a sensing smart contract in the blockchain node according to the node load data respectively corresponding to the processing processes of each blockchain node and each block.

[0186] Please continue to refer to Figure 7 As shown, when the block capacity of each block is obtained, determining the maximum block capacity that each blockchain node can accept according to the node load data respectively corresponding to the processing processes of each blockchain node and each block may specifically include the following steps:

[0187] In step 250', determine the maximum block capacity of each blockchain node according to the node load data respectively corresponding to the processing processes of each blockchain node and each block, and the block capacity of each block.

[0188] Figure 8 The figure shows a flowchart for determining the maximum block capacity of each blockchain node according to the node load data respectively corresponding to the processing processes of each blockchain node and each block, and the block capacity of each block in one embodiment of the present application. Please refer to Figure 8 As shown, determining the maximum block capacity of each blockchain node according to the node load data respectively corresponding to the processing processes of each blockchain node and each block, and the block capacity of each block may specifically include the following steps:

[0189] In step 810, determine the average block capacity of multiple blocks according to the block capacity of each block.

[0190] Specifically, the average block capacity of multiple blocks, that is, the mean value of the block capacity, can be obtained through the following method:

[0191]

[0192] where K represents the number of blocks with block numbers belonging to N - K ≤ i < N - 1, and AvgSize is the mean value of the block capacity.

[0193] In step 820, for each blockchain node, determine the average value of each node load data according to the node load data respectively corresponding to the processing processes of the blockchain node and each block.

[0194] For each node j, the average value of the node load data sensed by it can be calculated through the following method:

[0195]

[0196] where AvgSensej This represents the average load data for each node corresponding to node j.

[0197] In step 830, for each blockchain node, the candidate maximum block capacity of the blockchain node is determined based on the average block capacity of multiple blocks and the average value of the node load data determined for each blockchain node.

[0198] Specifically, the maximum candidate block size that a blockchain node can accept can be obtained by dividing the average block size of multiple blocks by the average node load data determined for each blockchain node.

[0199] For each node j, the maximum acceptable candidate block size is calculated as follows:

[0200] MaxSize j =AvgSize / AvgSense j ,

[0201] Among them, MaxSize j Let be the maximum candidate block capacity that node j can accept.

[0202] In step 840, the maximum block capacity of each blockchain node is determined based on the candidate maximum block capacity of each blockchain node.

[0203] The maximum block size that each blockchain node can accept is determined based on the maximum candidate block size that each blockchain node can accept.

[0204] The maximum candidate block size that each blockchain node can accept is a separate maximum candidate block size for each blockchain node, and there are multiple values ​​for these values; different blockchain nodes may have different maximum candidate block sizes. However, the maximum block size that each blockchain node can accept is a single value; it is the maximum block size that all blockchain nodes can accept.

[0205] In one embodiment of this application, determining the maximum block capacity of each blockchain node based on the candidate maximum block capacity of each blockchain node includes: taking the minimum value among the candidate maximum block capacities that each blockchain node can accept as the maximum block capacity of each blockchain node.

[0206] Specifically, the target maximum block size, i.e., the maximum block size that each blockchain node can accept, can be obtained in the following way:

[0207] TagetSize = MIN(MaxSize) j ),

[0208] Where MIN is the function used to find the minimum value, and TagetSize is the maximum block size that each blockchain node can accept.

[0209] For each node, the maximum block capacity that it can actually accept is different due to the difference in its hardware. Therefore, it is necessary to find the minimum value so that the blockchain network can meet the operation of the node with the worst hardware.

[0210] Please continue reading Figure 6 As shown, after step 3, the following steps may also be included:

[0211] 4. Calculate the target maximum block.

[0212] The target maximum block capacity can be calculated based on regular points by dividing the average block capacity by the average perceived load.

[0213] Figure 9 A flowchart illustrating an embodiment of this application is provided, showing how the maximum block capacity of each blockchain node is determined based on node load data corresponding to the processing procedures of each blockchain node and each block, and the block capacity of each block. Please refer to [link to flowchart documentation]. Figure 9 As shown, the maximum block capacity of each blockchain node is determined based on the node load data corresponding to the processing of each blockchain node and each block, as well as the block capacity of each block. This can specifically include the following steps:

[0214] In step 910, the maximum original block capacity that each blockchain node can accept is determined based on the node load data corresponding to the processing of each blockchain node and each block, as well as the block capacity of each block.

[0215] The original maximum block size here can be the maximum block size that each blockchain node can accept, i.e., TagetSize.

[0216] In step 920, an adjustment coefficient for the original maximum block capacity is determined based on the current maximum block capacity that each blockchain node can accept and the original maximum block capacity that each blockchain node can accept.

[0217] In one embodiment of this application, determining an adjustment coefficient for the original maximum block capacity based on the current maximum block capacity that each blockchain node can accept and the original maximum block capacity that each blockchain node can accept includes: determining an adjustment coefficient for the original maximum block capacity based on a comparison between the current maximum block capacity that each blockchain node can accept and the original maximum block capacity that each blockchain node can accept.

[0218] Alternatively, the original maximum block capacity that each blockchain node can accept can be multiplied by a preset ratio, and then the adjustment coefficient for the original maximum block capacity can be determined based on the comparison between the product and the current maximum block capacity that each blockchain node can accept.

[0219] The preset ratio can be set to 80%, 90%, etc.

[0220] In one embodiment of this application, an adjustment coefficient for the original maximum block capacity is determined based on a comparison between the current maximum block capacity that each blockchain node can accept and the original maximum block capacity that each blockchain node can accept. This includes: if the original maximum block capacity that each blockchain node can accept is greater than the current maximum block capacity that each blockchain node can accept, the adjustment coefficient is determined as a first adjustment coefficient; if the original maximum block capacity that each blockchain node can accept is less than the current maximum block capacity that each blockchain node can accept, the adjustment coefficient is determined as a second adjustment coefficient, wherein the first adjustment coefficient is less than the second adjustment coefficient. For example, the first adjustment coefficient can be (1-Y%), and the second adjustment coefficient can be (1+Y%).

[0221] Please continue reading Figure 6 As shown, after step 4, the following steps may also be included:

[0222] 5. Gradually increase or decrease the threshold.

[0223] Multiplying TargetSize by a preset percentage X% gives:

[0224] TagetSize=TagetSize×X%,

[0225] X can be set to 80, 90, etc.

[0226] After obtaining the new TagetSize after multiplying by X%, compare TagetSize with the maximum block size set in the current system. If the maximum block size set in the current system is greater than TagetSize, increase TagetSize by Y%. If the maximum block size set in the current system is less than TagetSize, decrease TagetSize by Y%.

[0227] The advantage of doing this is that after the business stabilizes, the block capacity will gradually converge after several K-block cycles, and there will be no sudden adjustments.

[0228] Of course, when the maximum block size set in the current system is greater than TagetSize, TagetSize can be increased by Y%, and when the maximum block size set in the current system is less than TagetSize, TagetSize can be decreased by Z%. The sizes of Y and Z can be different.

[0229] In one embodiment of this application, determining an adjustment coefficient for the original maximum block capacity based on the current maximum block capacity that each blockchain node can accept and the original maximum block capacity that each blockchain node can accept includes: determining the proportion of the change in the original maximum block capacity that each blockchain node can accept relative to the current maximum block capacity that each blockchain node can accept; and determining the adjustment coefficient for the original maximum block capacity based on this proportion.

[0230] Specifically, if the original maximum block size that each blockchain node can accept is A% larger than the current maximum block size that each blockchain node can accept, then the adjustment factor can be determined as follows: If the original maximum block size that each blockchain node can accept is B% smaller than the current maximum block size that each blockchain node can accept, then the adjustment factor can be determined as follows:

[0231] If the maximum initial block size that each blockchain node can accept is greater than the maximum block size that each blockchain node can currently accept, the adjustment coefficient will be determined as the first adjustment coefficient; if the maximum initial block size that each blockchain node can accept is less than the maximum block size that each blockchain node can currently accept, the adjustment coefficient will be determined as the second adjustment coefficient, wherein the first adjustment coefficient is less than the second adjustment coefficient. For example, the first adjustment coefficient can be (1-Y%), and the second adjustment coefficient can be (1+Y%).

[0232] In step 930, the original maximum block capacity is adjusted according to the adjustment coefficient to obtain the new maximum block capacity for each blockchain node.

[0233] By adjusting the original maximum block capacity according to the adjustment coefficient, a new maximum block capacity that each blockchain node can accept can be obtained.

[0234] The new maximum block capacity can be obtained by multiplying the adjustment factor by the original maximum block capacity; alternatively, the original maximum block capacity can be multiplied by a preset ratio to obtain a product, and then the product can be multiplied by the adjustment factor to obtain the new maximum block capacity.

[0235] The update of the maximum block capacity that each blockchain node can currently accept is achieved by calculating the new maximum block capacity that each blockchain node can accept.

[0236] In summary, the dynamic adjustment method for block capacity provided in the embodiments of this application can achieve at least the following technical effects:

[0237] 1. On-chain load perception: The on-chain load perception technology for consortium blockchain nodes based on smart contracts described in this application embodiment uses load sensors for each consortium blockchain node to perceive the load of each block cycle and uniformly encrypt and store it in the smart contract, so that the consortium blockchain can perceive the off-chain performance load.

[0238] 2. High accuracy of block capacity consensus: The consortium blockchain block capacity consensus technology based on perceptual contracts described in this application uses perceptual contracts to perform outlier removal and maximum block capacity calculation, and performs incremental block capacity threshold increase and decrease operations in the system, so that the block capacity approaches the optimal solution after consensus. The optimal block capacity will improve the packaging efficiency of consortium blockchain transactions.

[0239] The following describes an apparatus embodiment of this application, which can be used to execute the dynamic block capacity adjustment method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the dynamic block capacity adjustment method described above.

[0240] Figure 10 A block diagram of a dynamic block capacity adjustment apparatus according to an embodiment of this application is shown. Please refer to... Figure 10 As shown, a block capacity dynamic adjustment device 1000 according to an embodiment of this application includes: a load data acquisition unit 1010 and a block capacity determination unit 1020. The load data acquisition unit 1010 is used to acquire, for each of a plurality of blockchain nodes in a blockchain network, node load data corresponding to the processing process of each block in the processing of a plurality of blocks, wherein each block is added to the blockchain maintained by the blockchain network after its corresponding processing process; the block capacity determination unit 1020 is used to determine the maximum block capacity of each blockchain node based on the node load data corresponding to the processing process of each block, so that each blockchain node can continue to execute the processing process of other blocks according to the maximum block capacity.

[0241] In some embodiments of this application, based on the foregoing scheme, the load data acquisition unit 1010 is configured to: acquire node load data corresponding to the processing process of each block in the processing of the blockchain node and multiple blocks from the sensing block of the blockchain, wherein the node load data is packaged into the sensing block in the form of transactions.

[0242] In some embodiments of this application, based on the foregoing scheme, the node load data corresponding to the processing of each block of the blockchain node is determined based on the indicator data corresponding to at least one indicator collected from the blockchain node during the processing of the block, wherein the indicator data is collected by the sensor in the blockchain node.

[0243] In some embodiments of this application, based on the foregoing scheme, the node load data corresponding to the processing of each block of the blockchain node is determined based on the statistical data of indicators corresponding to at least one indicator during the processing of the block. The statistical data of indicators corresponding to each indicator is determined based on at least one indicator data corresponding to the indicator collected from the blockchain node during the processing of the block.

[0244] In some embodiments of this application, based on the foregoing scheme, the node load data corresponding to the processing of each block of the blockchain node is the largest indicator statistical data among the indicator statistical data corresponding to at least one indicator.

[0245] In some embodiments of this application, based on the foregoing scheme, the transaction further includes a signature generated by the private key of the blockchain node for the node load data corresponding to the processing process of the blockchain node and multiple blocks. The device further includes a verification and elimination unit. The load data acquisition unit 1010 is configured to: acquire the node load data corresponding to the processing process of each block and the signature from the sensing blocks of the blockchain; before determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing process of each blockchain node and each block, the verification and elimination unit is used to: verify the signature based on the node load data corresponding to the processing process of the blockchain node and multiple blocks and the public key of the blockchain node; if the signature verification fails, the node load data corresponding to the processing process of the blockchain node and multiple blocks is eliminated.

[0246] In some embodiments of this application, based on the foregoing scheme, the device further includes a block capacity acquisition unit; before determining the maximum block capacity of each blockchain node according to the node load data corresponding to the processing process of each blockchain node and each block, the block capacity acquisition unit is used to: acquire the block capacity of each block among the plurality of blocks respectively; the block capacity determination unit 1020 is configured to: determine the maximum block capacity of each blockchain node according to the node load data corresponding to the processing process of each blockchain node and each block, and the block capacity of each block.

[0247] In some embodiments of this application, based on the foregoing scheme, the block capacity determination unit 1020 is configured to: determine the average block capacity of the plurality of blocks according to the block capacity of each block; for each blockchain node, determine the average value of the node load data corresponding to the processing process of each blockchain node and each block respectively; for each blockchain node, determine the candidate maximum block capacity of the blockchain node according to the average block capacity of the plurality of blocks and the average value of the node load data determined for the blockchain node; and determine the maximum block capacity of each blockchain node according to the candidate maximum block capacity of each blockchain node.

[0248] In some embodiments of this application, based on the foregoing scheme, the block capacity determination unit 1020 is configured to: determine the original maximum block capacity that each blockchain node can accept based on the node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block; determine an adjustment coefficient for the original maximum block capacity based on the current maximum block capacity that each blockchain node can accept and the original maximum block capacity that each blockchain node can accept; and adjust the original maximum block capacity according to the adjustment coefficient to obtain the new maximum block capacity of each blockchain node.

[0249] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0250] It should be noted that, Figure 11 The computer system 1100 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0251] like Figure 11 As shown, the computer system 1100 includes a Central Processing Unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1102 or programs loaded from storage portion 1108 into Random Access Memory (RAM) 1103, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1103. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via bus 1104. An Input / Output (I / O) interface 1105 is also connected to bus 1104.

[0252] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1110 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

[0253] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit (CPU) 1101, it performs various functions defined in the system of this application.

[0254] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0255] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0256] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0257] In one aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0258] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0259] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0260] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0261] The data collection and processing plan outlined in this application must be implemented in strict accordance with the requirements of relevant national laws and regulations, obtaining the informed consent or separate consent of the data subject (or having a legal basis as stipulated by the relevant national laws and regulations), and conducting subsequent data use and processing within the scope authorized by laws and regulations and the data subject.

[0262] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for dynamically adjusting block capacity, characterized in that, The method includes: For each of the multiple blockchain nodes in the blockchain network, obtain the node load data corresponding to the processing process of each block in the processing of the multiple blocks, wherein each block is added to the blockchain maintained by the blockchain network after its corresponding processing process. Based on the node load data corresponding to the processing of each blockchain node and each block, the maximum block capacity of each blockchain node is determined so that each blockchain node can continue to execute the processing of other blocks according to the maximum block capacity.

2. The method for dynamically adjusting block capacity according to claim 1, characterized in that, The step of obtaining the node load data corresponding to the processing process of each block in the blockchain node and multiple blocks includes: The node load data corresponding to the processing process of each block in the blockchain node and multiple blocks is obtained from the sensing block of the blockchain. The node load data is packaged into the sensing block in the form of transactions.

3. The method for dynamically adjusting block capacity according to claim 2, characterized in that, The node load data corresponding to the processing of each block of the blockchain node is determined based on the indicator data corresponding to at least one indicator collected from the blockchain node during the processing of the block. The indicator data is collected by the sensor in the blockchain node.

4. The method for dynamically adjusting block capacity according to claim 3, characterized in that, The node load data corresponding to the processing of each block of the blockchain node is determined based on the statistical data of indicators corresponding to at least one indicator during the processing of the block. The statistical data of each indicator is determined based on at least one indicator data corresponding to the indicator collected from the blockchain node during the processing of the block.

5. The method for dynamically adjusting block capacity according to claim 4, characterized in that, The node load data corresponding to the processing of each block of the blockchain node is the maximum statistical data of the statistical data of the statistical data of at least one indicator.

6. The method for dynamically adjusting block capacity according to claim 2, characterized in that, The transaction also includes a signature generated based on the private key of the blockchain node for the node load data corresponding to the processing of multiple blocks by the blockchain node. The step of obtaining the node load data corresponding to the processing of each block in the blockchain's sensing blocks includes: Obtain the signature and the node load data corresponding to the processing process of each block in the blockchain node's processing of multiple blocks from the sensing block of the blockchain; Before determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing procedures of each blockchain node and each block, the method further includes: The signature is verified based on the node load data corresponding to the processing of the blockchain node and multiple blocks, and the public key of the blockchain node. If the signature verification fails, the node load data corresponding to the processing of the blockchain node and multiple blocks will be removed.

7. The method for dynamically adjusting block capacity according to claim 1, characterized in that, Before determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing procedures of each blockchain node and each block, the method further includes: Obtain the block capacity of each block in the plurality of blocks respectively; The step of determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing of each blockchain node and each block includes: Based on the node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block, the maximum block capacity of each blockchain node is determined.

8. The method for dynamically adjusting block capacity according to claim 7, characterized in that, The step of determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block, includes: The average block size of the plurality of blocks is determined based on the block size of each block; For each blockchain node, the average value of the node load data is determined based on the node load data corresponding to the processing process of each blockchain node and each block. For each blockchain node, the candidate maximum block capacity of the blockchain node is determined based on the average block capacity of the multiple blocks and the average value of the node load data determined for the blockchain node. The maximum block capacity of each blockchain node is determined based on the candidate maximum block capacity of each blockchain node.

9. The method for dynamically adjusting block capacity according to claim 7, characterized in that, The step of determining the maximum block capacity of each blockchain node based on the node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block, includes: Based on the node load data corresponding to the processing of each blockchain node and each block, and the block capacity of each block, determine the original maximum block capacity that each blockchain node can accept. Based on the maximum block capacity that each blockchain node can currently accept and the original maximum block capacity that each blockchain node can accept, an adjustment coefficient for the original maximum block capacity is determined. The original maximum block capacity is adjusted according to the adjustment coefficient to obtain the new maximum block capacity for each blockchain node.

10. A device for dynamically adjusting block capacity, characterized in that, The device includes: The load data acquisition unit is used to acquire, for each of the multiple blockchain nodes in the blockchain network, the node load data corresponding to the processing process of each block in the processing of multiple blocks, wherein each block is added to the blockchain maintained by the blockchain network after its corresponding processing process. The block capacity determination unit is used to determine the maximum block capacity of each blockchain node based on the node load data corresponding to the processing process of each blockchain node and each block, so that each blockchain node can continue to execute the processing process of other blocks according to the maximum block capacity.

11. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the method for dynamically adjusting the block capacity as described in any one of claims 1 to 9.

12. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs that, when executed by one or more processors, cause the one or more processors to implement the method for dynamically adjusting block capacity as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium, a processor of a computer device reading the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to cause the computer device to perform the method for dynamically adjusting the block capacity as described in any one of claims 1 to 9.

Images