Block compression method, device and equipment based on block chain and readable storage medium

Abstract

The invention discloses a block compression method, device and equipment based on a block chain, and a readable storage medium. The method comprises the steps of obtaining M to-be-packaged transactions; one to-be-packaged transaction comprises transaction attribute values of N transaction attribute types; according to the transaction attribute type priorities corresponding to the N transaction attribute types and the M transaction attribute values corresponding to the N transaction attribute types, performing position sorting processing on the M to-be-packaged transactions to obtain M position sorted transactions; adding transaction attribute values with the same transaction attribute type in the M position sorting transactions to the same to-be-compressed attribute value set to obtain N to-be-compressed attribute value sets; performing incremental coding compression processing on the N to-be-compressed attribute value sets to obtain N attribute value incremental codes; and performing block encapsulation processing on the N attribute value increment codes to obtain a to-be-chained block. By adopting the method and the device, the storage space required by the block can be reduced, and the performance of the block chain system is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a blockchain-based block compression method, apparatus, device, and readable storage medium. Background Technology

[0002] Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism and encryption algorithm. It is mainly used to organize data in chronological order and encrypt it into a ledger so that it cannot be tampered with or forged. At the same time, it can verify, store and update data.

[0003] Due to the decentralized and multi-node nature of blockchain systems, each blockchain node needs to store a complete copy of all blocks. A single block often requires a very large amount of space. Over time, the amount of data stored on each blockchain node will continuously increase, leading to an exponential increase in storage resource consumption. This results in increasingly lower data operation performance for blockchain nodes, ultimately impacting the performance of the entire blockchain system. Summary of the Invention

[0004] This application provides a blockchain-based block compression method, apparatus, device, and readable storage medium, which can reduce the storage space required for blocks and improve the performance of the blockchain system.

[0005] This application provides a blockchain-based block compression method, including:

[0006] Retrieve M transactions to be packaged; M is a positive integer; each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types; N is a positive integer;

[0007] Based on the priority of each of the N transaction attribute types and the M transaction attribute values ​​corresponding to each of the N transaction attribute types, the M transactions to be packaged are sorted by position to obtain M position-sorted transactions.

[0008] Take the transaction attribute values ​​with the same transaction attribute type from the M position-sorted transactions, add them to the same set of attribute values ​​to be compressed according to the position order among the M position-sorted transactions, and get the set of attribute values ​​to be compressed corresponding to N transaction attribute types respectively;

[0009] Incremental encoding compression is performed on each of the N sets of attribute values ​​to be compressed to obtain N incremental codes for attribute values;

[0010] Incremental encoding of N attribute values ​​is performed on a block encapsulation process to obtain a block to be added to the blockchain; the block to be added to the blockchain is used to be added to the blockchain when consensus is passed.

[0011] One embodiment of this application provides a blockchain-based block compression device, comprising:

[0012] The acquisition module is used to acquire M transactions to be packaged; M is a positive integer; each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types; N is a positive integer;

[0013] The sorting module is used to sort the positions of M transactions to be packaged according to the priority of the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types, so as to obtain M position-sorted transactions.

[0014] The classification module is used to add transaction attribute values ​​with the same transaction attribute type from M position-sorted transactions to the same set of attribute values ​​to be compressed according to the positional order among the M position-sorted transactions, so as to obtain sets of attribute values ​​to be compressed for N transaction attribute types respectively.

[0015] The encoding module is used to perform incremental encoding compression on N sets of attribute values ​​to be compressed, so as to obtain N incremental encodings of attribute values.

[0016] The encapsulation module is used to encapsulate the incremental encoding of N attribute values ​​into blocks, resulting in blocks to be added to the blockchain. These blocks are then added to the blockchain when consensus is reached.

[0017] In one possible implementation, the sorting module is used to sort the M transactions to be packaged according to the priority of the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types. When the M position-sorted transactions are obtained, the module is specifically used to perform the following operations:

[0018] Iterate through the N transaction attribute types according to their respective priorities to obtain the k-th transaction attribute type; the priority of the transaction attribute type corresponding to the k-th transaction attribute type is lower than the priority of the transaction attribute type corresponding to the (k-1)-th transaction attribute type obtained.

[0019] Based on the M transaction attribute values ​​corresponding to the kth transaction attribute type, the M intermediate position sorted transactions after the (k-1)th position sort are sorted again to obtain the M intermediate position sorted transactions after the kth position sort; when k is 1, the M intermediate position sorted transactions after the (k-1)th position sort are M transactions to be packaged.

[0020] If the M transaction attribute values ​​corresponding to the kth transaction attribute type contain the same transaction attribute value, then continue to obtain the (k+1)th transaction attribute type, and perform the (k+1)th position sorting on the M middle position sorted transactions after the kth position sorting according to the M transaction attribute values ​​corresponding to the (k+1)th transaction attribute type.

[0021] If the M transaction attribute values ​​corresponding to the k-th transaction attribute type do not contain any consecutive and identical transaction attribute values, then stop traversing the N transaction attribute types and determine the M middle position sorted transactions after the k-th position sort as the M position sorted transactions.

[0022] In one possible implementation, the sorting module is used to sort the M intermediate position transactions after the (k-1)th position sorting according to the M transaction attribute values ​​corresponding to the kth transaction attribute type. When obtaining the M intermediate position transactions after the kth position sorting, it is specifically used to perform the following operations:

[0023] Sort the M transaction attribute values ​​corresponding to the kth transaction attribute type to obtain M sorted transaction attribute values;

[0024] Among the M intermediate position sorted transactions after the (k-1)th position sort, those intermediate position sorted transactions that contain the same first transaction attribute value and are in consecutive positions are identified as intermediate position sorted transactions to be adjusted; the first transaction attribute value refers to the transaction attribute value with the (k-1)th transaction attribute type; when k is 1, the intermediate position sorted transactions to be adjusted are M transactions to be packaged.

[0025] Based on the positional relationship of the second transaction attribute value contained in the intermediate position sorting transaction to be adjusted among the M sorted transaction attribute values, the intermediate position sorting transactions to be adjusted among the M intermediate position sorting transactions are subjected to position adjustment processing to obtain the M intermediate position sorting transactions after the kth position sorting; the second transaction attribute value refers to the transaction attribute value with the kth transaction attribute type.

[0026] In one possible implementation, the N sets of attribute values ​​to be compressed include the set K of attribute values ​​to be compressed. n n is a positive integer less than or equal to N; the encoding module is used to perform incremental encoding compression on the N sets of attribute values ​​to be compressed, and to obtain the incremental encoding of N attribute values, it is specifically used to perform the following operations:

[0027] The set of attribute values ​​to be compressed, K n The first transaction attribute value is written into the incremental encoding set and the attribute value set to be compressed, K, respectively. n The corresponding transaction attribute labeling field;

[0028] Iterate through the set of attribute values ​​to be compressed, K, in sequence.n Get the value of the i-th transaction attribute; i is a positive integer greater than or equal to 2 and less than or equal to M;

[0029] If the i-th transaction attribute value is different from the transaction attribute value contained in the transaction attribute labeling field, then the i-th transaction attribute value is added sequentially to the incremental encoding set, and the transaction attribute value contained in the transaction attribute labeling field is replaced with the i-th transaction attribute value.

[0030] If the i-th transaction attribute value is the same as the transaction attribute value contained in the transaction attribute labeling field, then the special encoded characters are added sequentially to the incremental encoding set until the set of attribute values ​​to be compressed, K, is determined. n Completed; the set of attribute values ​​K to be compressed has been determined based on the incremental encoding set. n The corresponding attribute value is incrementally encoded.

[0031] In one possible implementation, the N transaction attribute types include transaction attribute type T. j , j is a positive integer less than or equal to N; the sorting module is also used to perform the following operations:

[0032] Get transaction attribute type T j The corresponding transaction attribute type sliding window; the transaction attribute type sliding window contains L items with transaction attribute type T. j Corresponding historical transaction attribute values;

[0033] Based on the transaction attribute type T among the M transactions to be packaged j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j The corresponding latest attribute value is far from the standard deviation;

[0034] When the distance from the latest attribute value to the standard deviation of each of the N transaction attribute types is obtained, the priority of each of the N transaction attribute types is determined based on the distance from the latest attribute value to the standard deviation of each of the N transaction attribute types.

[0035] In one possible implementation, the sorting module is used to sort the M transactions to be packaged according to the transaction attribute type T. j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0036] Among the M transactions to be packaged, those with transaction attribute type T j The transaction attribute values ​​are placed sequentially before the position in the transaction attribute type slider window;

[0037] The transaction attribute type sliding window is forward-sliding to obtain a new sliding window containing L latest transaction attribute values. These L latest transaction attribute values ​​contain M transactions of type T to be packaged. j The transaction attribute value;

[0038] Determine the transaction attribute type T based on the L latest transaction attribute values. j The latest attribute value is far from the standard deviation.

[0039] In one possible implementation, the sorting module is used to determine the transaction attribute type T based on the L latest transaction attribute values. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0040] An attribute value mapping map is generated based on L latest transaction attribute values. The attribute value mapping map contains P mapped attribute values ​​and the occurrence count of each of the P mapped attribute values. An occurrence count refers to the number of latest transaction attribute values ​​that are the same as a mapped attribute value among the L latest transaction attribute values.

[0041] Based on the quantity L and the occurrence counts corresponding to the P mapped attribute values, the transaction attribute type T is calculated. j The latest attribute value is far from the standard deviation.

[0042] In one possible implementation, when the sorting module generates an attribute value mapping map based on the L latest transaction attribute values, it specifically performs the following operations:

[0043] Create an initial attribute value mapping map;

[0044] Iterate through the L latest transaction attribute values ​​and obtain the qth latest transaction attribute value; q is a positive integer less than or equal to L;

[0045] If the initial attribute value mapping map contains a mapping attribute value that is the same as the qth latest transaction attribute value, then the occurrence count of the mapping attribute value that is the same as the qth latest transaction attribute value is accumulated.

[0046] If the initial attribute value mapping map does not contain a mapping attribute value that is the same as the qth latest transaction attribute value, then the qth latest transaction attribute value is taken as the new mapping attribute value, the starting quantity is determined as the occurrence quantity corresponding to the new mapping attribute value, and the new mapping attribute value and the occurrence quantity corresponding to the new mapping attribute value are added to the initial attribute value mapping map.

[0047] The initial attribute value mapping map after traversing the L latest transaction attribute values ​​is determined as the attribute value mapping map.

[0048] In one possible implementation, the sorting module is used to calculate the transaction attribute type T based on the quantity L and the occurrence counts corresponding to the P mapped attribute values. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0049] Iterate through the occurrence counts of each of the P mapped attribute values ​​and obtain the s-th occurrence count; s is a positive integer less than or equal to P.

[0050] The difference between the quantity L and the s-th occurrence quantity is determined as the s-th unit attribute distance. The product of the s-th unit attribute distance and the s-th occurrence quantity is determined as the s-th attribute distance. This process continues until the occurrence quantities corresponding to P mapped attribute values ​​have been traversed. The sum of the P attribute distances is then divided by the square of the quantity L to obtain the transaction attribute type T. j The latest attribute value is far from the standard deviation.

[0051] In one possible implementation, the sorting module is used to sort the M transactions to be packaged according to the transaction attribute type T. j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0052] Get transaction attribute type T j The corresponding historical attribute value's distance from the standard deviation; the historical attribute value's distance from the standard deviation is determined based on the transaction attribute values ​​contained in the transaction attribute type sliding window;

[0053] Among the M transactions to be packaged, those with transaction attribute type T j The transaction attribute values ​​are placed sequentially before the position in the transaction attribute type slider window;

[0054] Perform a forward unit sliding process on the transaction attribute type sliding window after the (t-1)th unit sliding to obtain the transaction attribute type sliding window after the tth unit sliding.

[0055] The transaction attribute value at the end of the transaction attribute type sliding window after the (t-1)th unit slide is determined as the t-th slide-removed transaction attribute value, and the transaction attribute value at the beginning of the transaction attribute type sliding window after the t-th unit slide is determined as the t-th slide-added transaction attribute value; the t-th slide-added transaction attribute value belongs to the M transactions to be packaged that have transaction attribute type T. j The transaction attribute value;

[0056] The distance standard deviation of the (t-1)th updated attribute value is updated based on the t-th sliding addition and t-th sliding removal transaction attribute values ​​to obtain the distance standard deviation of the t-th updated attribute value; when t is 1, the distance standard deviation of the (t-1)th updated attribute value is the distance standard deviation of the historical attribute value.

[0057] When t equals M, the distance from the standard deviation of the Mth updated attribute value is determined as the transaction attribute type T. j The latest attribute value is far from the standard deviation.

[0058] In one possible implementation, the sorting module is used to update the distance to the standard deviation of the (t-1)th updated attribute value based on the t-th sliding addition and t-th sliding removal transaction attribute values. Specifically, when obtaining the distance to the standard deviation of the t-th updated attribute value, it performs the following operations:

[0059] Get the number of added attributes with the same transaction attribute value as the t-th swipe in the transaction attribute type sliding window after the (t-1)-th unit swipe, and the number of removed attributes with the same transaction attribute value as the t-th swipe in the transaction attribute type sliding window after the (t-1)-th unit swipe;

[0060] Subtract the difference between the quantity L and the number of added attributes from the difference between the quantity L and the number of removed attributes to obtain the distance of the changed attributes;

[0061] The quotient between the distance to the changed attribute and the square of the quantity L is added to the standard deviation of the distance to the (t-1)th updated attribute value to obtain the standard deviation of the distance to the tth updated attribute value.

[0062] One embodiment of this application provides a computer device, including: a processor, a memory, and a network interface;

[0063] The processor is connected to the memory and the network interface. The network interface is used to provide a data communication network element, the memory is used to store a computer program, and the processor is used to call the computer program to execute the method in the embodiments of this application.

[0064] One aspect of this application provides a computer-readable storage medium storing a computer program adapted for loading by a processor and executing the methods described in this application.

[0065] One aspect of this application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method described in this application.

[0066] In this embodiment, a blockchain node can obtain M transactions to be packaged, each of which contains N transaction attribute values ​​of different transaction attribute types. Then, based on the priority of each of the N transaction attribute types and the M transaction attribute values ​​corresponding to each of the N transaction attribute types, the M transactions to be packaged are sorted by position to obtain M position-sorted transactions. The transaction attribute values ​​of the same transaction attribute type among the M position-sorted transactions are then added to the same set of attribute values ​​to be compressed according to the positional order among the M position-sorted transactions, resulting in N sets of attribute values ​​to be compressed for each of the N transaction attribute types. Incremental encoding compression is then performed on each of the N sets of attribute values ​​to obtain N incremental attribute codes. Finally, the N incremental attribute codes are encapsulated into blocks to obtain a block to be added to the blockchain. This block is used to be added to the blockchain when consensus is reached. The method provided in this application embodiment can first reorder the transactions to be packaged based on the priority of the transaction attribute type and the transaction attribute value corresponding to the transaction attribute type. This sorting mechanism will make transactions with smaller changes in transaction attribute values ​​processed first in the incremental encoding and compression stage. Therefore, higher data redundancy elimination efficiency can be achieved in the incremental encoding and compression stage, thereby reducing the storage space required for blocks and improving the performance of the blockchain system. Attached Figure Description

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

[0068] Figure 1 This is a schematic diagram of the network structure of a blockchain node system provided in an embodiment of this application;

[0069] Figure 2 This is a schematic diagram illustrating a blockchain-based block compression method provided in an embodiment of this application.

[0070] Figure 3 This is a flowchart illustrating a blockchain-based block compression method provided in an embodiment of this application.

[0071] Figure 4 This is a schematic diagram illustrating a transaction location sorting method provided in an embodiment of this application;

[0072] Figure 5 This is a flowchart illustrating a priority determination method based on blockchain provided in an embodiment of this application;

[0073] Figure 6 This is a schematic diagram of a sliding window for transaction attribute types provided in an embodiment of this application;

[0074] Figure 7 This application provides a system architecture for a transaction incremental coding block compression scheme based on sliding window and dynamic standard deviation.

[0075] Figure 8 This is a schematic diagram of a transaction sorting process based on a sliding window and dynamic standard deviation provided in an embodiment of this application;

[0076] Figure 9 This is a schematic diagram of a block compression process based on transaction incremental coding provided in an embodiment of this application;

[0077] Figure 10 This is a schematic diagram of the structure of a blockchain-based block compression device provided in an embodiment of this application;

[0078] Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0080] To facilitate understanding, the following brief explanations are provided for some of the terms:

[0081] 1. Blockchain: In a narrow sense, blockchain is a chain-like data structure with blocks as the basic unit. The blocks use digital digests to verify the previously obtained transaction history, which is suitable for the needs of anti-tampering and scalability in distributed ledger scenarios. In a broad sense, blockchain also refers to the distributed ledger technology implemented by the blockchain structure, including distributed consensus, privacy and security protection, peer-to-peer communication technology, network protocols, smart contracts, etc.

[0082] The goal of blockchain is to create a distributed data ledger that allows only additions and not deletions. The underlying structure of the ledger is a linear linked list. This list consists of interconnected "blocks," with each subsequent block recording the hash value of its predecessor. The validity of each block (and the transactions within it) can be quickly verified by calculating the hash value. If a node in the network proposes adding a new block, the block must be confirmed through a consensus mechanism.

[0083] 2. Block: A block is a data packet carrying transaction data on a blockchain network. It is a data structure marked with a timestamp and the hash value of the previous block. A block is verified and confirmed by the network's consensus mechanism. A block consists of a block header and a block body. The block header records the metadata of the current block, including the current version number, the hash value of the previous block, a timestamp, a random number, and the hash value of the Merkle root. The block body records detailed data generated over a period of time, including all verified transactions and other information generated during the block creation process; it can be understood as a form of ledger representation. Furthermore, the detailed data in the block body may include a unique Merkle root recorded in the block header, generated through a Merkle tree hashing process.

[0084] The predecessor block, also known as the parent block, is the block in which the blockchain achieves temporal ordering by recording the hash value of the block and the hash value of the parent block in the block header.

[0085] 3. Hash Value: Also known as an information feature value or characteristic value, a hash value is generated by converting input data of arbitrary length into cryptographic data and producing a fixed output using a hash algorithm. The original input data cannot be retrieved by decrypting the hash value; it is a one-way cryptographic function. In a blockchain, each block (except the initial block) contains the hash values ​​of its predecessor blocks. The hash value is a core foundation and the most important aspect of blockchain technology, preserving the authenticity of recorded and viewed data, as well as the integrity of the blockchain as a whole.

[0086] 4. Smart Contracts: A smart contract is a computer protocol designed to disseminate, verify, or execute contracts in an informational manner. The concept of a smart contract possesses three key elements: commitment, agreement, and digital form. Therefore, it can extend the application scope of blockchain to all aspects of transactions, payments, settlements, and clearing in the financial industry. A smart contract means that when a pre-programmed condition is triggered, the corresponding contractual terms are executed immediately, and its working principle is similar to the if-then statement in a computer program. Smart contracts allow for trusted transactions without a third party; these transactions are traceable and irreversible.

[0087] 5. State Data: State data is the data structure used in a blockchain system to represent the current state of the system. State data includes the balances of all accounts, the state of smart contracts, and other relevant information. State data is continuously updated as transactions are executed, reflecting the global state of the blockchain system at a given point in time. In blockchain systems, state data is typically stored in the form of a Merkle tree or other cryptographic data structures to ensure its integrity and security.

[0088] 6. Transaction Pool: A transaction pool (also known as a mempool) is a data structure in a blockchain network used to store transactions that have not yet been packaged into blocks. When a user submits a new transaction to the blockchain network, the transaction first enters the transaction pool. When blockchain nodes are preparing to generate a new block, they select a certain number of transactions from the transaction pool to package. Transaction pools help improve the processing capacity of the blockchain network.

[0089] 7. Sliding Window: A sliding window is a data processing technique used to create a dynamic subset of a series of data points, containing the data points before and after the current processing point. In blockchain transaction processing, a sliding window can be used to continuously monitor and analyze recent transaction data. The window "slides" as new transactions are added, meaning new transactions are added to one end of the window while older transactions are removed from the other. This method allows the system to dynamically detect changes in transaction data in order to implement various optimization strategies, such as transaction sorting or data compression.

[0090] 8. Dynamic Variance: Dynamic variance is a measure of how the variance of data points (i.e., the average of the squares of the differences between each data point and its mean) changes dynamically over a given time window. In blockchain transaction data, dynamic variance can be used to measure the degree of change of specific attributes (such as transaction amount, transacting party address, etc.) over a recent period. By calculating dynamic variance, the system can identify attributes with smaller changes (i.e., lower variance), which are easier to compress during incremental encoding because they have higher continuity.

[0091] 9. Incremental Encoding: Incremental encoding is a data compression technique that stores only the changing parts of a data sequence, rather than storing the complete data point each time. In blockchain transactions, incremental encoding can be used to reduce redundancy in storing identical or similar transaction data. For example, if consecutive transactions come from the same sender, the sender's address can be stored only once, and subsequent transactions only need to store a tag or reference indicating that the field is the same as the previous transaction.

[0092] 10. Block Compression: Block compression refers to the process of compressing block data in a blockchain to reduce the space required for storage and transmission. A block typically contains multiple transactions, each with multiple fields. By applying data compression algorithms, such as incremental encoding, the block size can be reduced, thereby lowering storage costs and improving network transmission efficiency. Block compression is crucial for improving the scalability and performance of a blockchain, especially in public blockchain networks that process large volumes of transactions.

[0093] Please see Figure 1 , Figure 1 This is a schematic diagram of the network structure of a blockchain node system provided in an embodiment of this application. Figure 1 The blockchain network shown may include, but is not limited to, the blockchain network corresponding to a consortium blockchain. This blockchain network may include multiple blockchain nodes, specifically blockchain node 10a, blockchain node 10b, blockchain node 10c, blockchain node 10d, ..., blockchain node 10n. Each blockchain node, during normal operation, can receive data sent from the outside world and perform block-up processing based on the received data, and can also send data to the outside world. To ensure data interoperability between the various blockchain nodes, data connections may exist between each blockchain node; for example, there is a data connection between blockchain node 10a and blockchain node 10b, a data connection between blockchain node 10a and blockchain node 10c, and a data connection between blockchain node 10b and blockchain node 10c.

[0094] It is understood that the above data connection is not limited to the connection method. It can be connected directly or indirectly through wired communication, or directly or indirectly through wireless communication, or through other connection methods. This application does not impose any restrictions on this.

[0095] It is understandable that blockchain nodes can transmit data or blocks through the aforementioned data connections. The blockchain network can establish data connections between blockchain nodes based on node identifiers. Each blockchain node in the network has a corresponding node identifier, and each blockchain node can store the node identifiers of other blockchain nodes that are connected to it. This allows it to broadcast acquired data or generated blocks to other blockchain nodes based on their node identifiers. For example, blockchain node 10a can maintain a node identifier list as shown in Table 1, which stores the node names and node identifiers of other nodes.

[0096] Table 1

[0097]

[0098]

[0099] The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify a node in a blockchain network. Table 1 only uses IP addresses as an example. For instance, blockchain node 10a can send information (e.g., a block) to blockchain node 10b using the node identifier BBB.BBB.BBB.BBB, and blockchain node 10b can determine that the information was sent by blockchain node 10a using the node identifier AAA.AAA.AAA.AAA.

[0100] In blockchain, before a block is added to the chain, it must pass consensus among the consensus nodes in the blockchain network. Only after consensus is reached can the block be added to the blockchain. Understandably, when blockchain is used in scenarios involving government or commercial institutions, not all participating nodes in the blockchain (i.e., the blockchain nodes in the aforementioned blockchain network) have sufficient resources and the necessity to become consensus nodes. For example, in... Figure 1In the blockchain network shown, blockchain nodes 10a, 10b, 10c, and 10d can be considered as consensus nodes. Consensus nodes participate in consensus, which means reaching an agreement on blocks (containing a batch of transactions), i.e., voting on blocks; while non-consensus nodes do not participate in consensus but help propagate block and voting messages, and synchronize states with each other.

[0101] It is understandable that a block often requires a very large amount of space. Over time, the amount of data stored by each blockchain node in the blockchain system will continue to grow. Therefore, this application proposes a blockchain-based block compression method, which prioritizes and compresses transactions with smaller changes in transaction attribute values ​​by sorting the transactions to be packaged, thereby achieving higher data redundancy elimination efficiency and reducing the storage space required for blocks. Specifically, any blockchain node in the blockchain network, when meeting the block production conditions, can obtain M transactions to be packaged, where M is a positive integer, and each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types, where N is a positive integer. Then, based on the priority of each of the N transaction attribute types and the M transaction attribute values ​​corresponding to each of the N transaction attribute types, the M transactions to be packaged are sorted by position, resulting in M ​​position-sorted transactions. Next, transaction attribute values ​​with the same transaction attribute type from the M position-sorted transactions are added to the same set of attribute values ​​to be compressed, according to the positional order among the M position-sorted transactions, resulting in N sets of attribute values ​​to be compressed for each transaction attribute type. Finally, incremental encoding compression is performed on each of the N sets of attribute values ​​to be compressed, resulting in N incremental attribute codes. Block encapsulation processing is then performed on these N incremental attribute codes to obtain the block to be added to the blockchain. This block to be added to the blockchain is used when consensus is reached.

[0102] It is understood that the above-mentioned data connection is not limited to the connection method. It can be connected directly or indirectly through wired communication, or directly or indirectly through wireless communication, or through other connection methods. This application does not impose any restrictions on this.

[0103] It is understood that the block compression method provided in this application embodiment can be executed by a computer device, which includes, but is not limited to, a blockchain node (which can be a terminal or a server). The aforementioned server can be an independent 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 aforementioned terminal can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited to these.

[0104] It is understood that the embodiments of this application can be applied to various application scenarios, including but not limited to cloud technology, artificial intelligence, smart driving, supply chain management, Internet of Things data storage, cross-platform or regional remittances, etc.

[0105] For example, embodiments of this application can be applied to supply chain management, where blockchain is used to record every stage of a product's journey from production to consumption. This information often contains a large amount of repetitive data, such as supplier information and batch numbers. Embodiments of this application can be applied to these systems to improve the efficiency of data storage and retrieval by compressing transaction data in blocks, while ensuring the transparency and immutability of the supply chain.

[0106] For example, embodiments of this application can be applied to Internet of Things (IoT) data storage. IoT devices typically generate large amounts of data, and blockchain can provide a secure storage and sharing platform for this data. Embodiments of this application can be used for blockchain storage of IoT data, reducing storage requirements and improving data transmission efficiency by compressing similar data frequently exchanged between devices. This is particularly important for IoT applications with limited bandwidth and high requirements for real-time data processing.

[0107] It is understood that, in the specific embodiments of this application, the data related to transactions, transaction attribute values, etc., when applied to specific products or technologies, requires user permission or consent, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant regions.

[0108] To better understand the above block encoding compression process, please refer to [link / reference]. Figure 2 , Figure 2 This is a schematic diagram illustrating a blockchain-based block compression method provided in an embodiment of this application. Wherein, as... Figure 2 The blockchain node 20 shown can be any blockchain node in the aforementioned blockchain network, such as blockchain node 10a.

[0109] like Figure 2 As shown, when blockchain node 20 meets the block production condition, i.e., when blockchain node 20 is the block production node for this round, blockchain node 20 can obtain the transaction to be packaged 21 from the transaction pool. Assume that the obtained transaction to be packaged 21 includes transaction 0x12 (i.e., the transaction with transaction ID 0x12), transaction 0x65 (i.e., the transaction with transaction ID 0x65), transaction 0x17 (i.e., the transaction with transaction ID 0x17), and transaction 0x91 (i.e., the transaction with transaction ID 0x91). It can be understood that a transaction can contain multiple transaction attribute values ​​of different transaction attribute types. For example, a transaction needs to contain transaction attribute values ​​of transaction ID, chain ID, ..., contract name, etc. Many transaction attribute values ​​of different transaction attribute types may appear repeatedly in multiple consecutive transactions. For example, regarding chain ID, when there is only one blockchain in the blockchain network, all transactions generated in that blockchain network contain the same chain ID. Repeatedly storing the chain ID of each transaction would lead to unnecessary space waste.

[0110] Therefore, before encoding and compressing transactions, blockchain node 20 can first sort the transactions 21 to be packaged according to the priority of the transaction attribute type and the transaction attribute value corresponding to the transaction attribute type, resulting in the sorted transactions 22. The priority of the transaction attribute type can be used to characterize the degree of change in the transaction attribute value corresponding to the transaction attribute type. The higher the priority of the transaction attribute type, the smaller the degree of change in the transaction attribute value corresponding to that transaction attribute type. In other words, the higher the probability of duplicate data appearing among the transaction attribute values ​​corresponding to transaction attribute types with higher priorities in multiple transactions.

[0111] like Figure 2As shown, assuming the chain ID priority is 1, the contract name priority is 2, ..., and the transaction ID priority is n, when blockchain node 20 sorts the transactions to be packaged 21, it can first sort the transactions in the packaged transaction 21 based on the transaction attribute value corresponding to the chain ID to obtain the initial sorted transactions. Then, it can sort the initial sorted transactions based on the transaction attribute value corresponding to the contract name to obtain the secondary sorted transactions, ..., and finally, it can sort the n-1 transactions based on the transaction attribute value corresponding to the transaction ID to obtain the position-sorted transactions 22. It should be noted that when sorting transactions based on the transaction attribute value corresponding to the transaction attribute type priority with lower priority, the sorting result of the transaction attribute value corresponding to the transaction attribute type priority with higher priority contained in the transactions before sorting should be consistent with the sorting result of the transaction attribute value corresponding to the transaction attribute type priority with higher priority contained in the transactions after sorting. For example, after sorting the initial transactions based on the transaction attribute values ​​corresponding to the contract names, the resulting secondary sorted transactions are: transaction 0x12, transaction 0x91, transaction 0x65, and transaction 0x17. At this time, the sorting result of the transaction attribute values ​​corresponding to the contract names is [c1, c1, c2, c2]. Then, the n-1 transactions are sorted based on the transaction attribute values ​​corresponding to the transaction IDs. The resulting position-sorted transaction 22 contains the transactions: transaction 0x12, transaction 0x91, transaction 0x17, and transaction 0x65. At this time, the sorting result of the transaction attribute values ​​corresponding to the contract names is still [c1, c1, c2, c2].

[0112] like Figure 2 As shown, after obtaining the position-sorted transaction 22, blockchain node 20 performs incremental encoding compression on the position-sorted transaction 22. Specifically, it performs incremental encoding compression on the transaction attribute values ​​for different transaction attribute types, resulting in attribute value incremental encoding 23. For example, for the chain ID transaction attribute value, blockchain node 20 performs incremental encoding compression, resulting in chain ID incremental encoding of [chain1, *, *, *]. For the contract name transaction attribute value, blockchain node 20 performs incremental encoding compression, resulting in contract name incremental encoding of [c1, *, c2, *]. Finally, blockchain node 20 performs block encapsulation processing on the attribute value incremental encoding 23, obtaining block 53. Then, blockchain node 20 can send block 53 to other blockchain nodes in the blockchain network. Once blockchain node 20 confirms that consensus on block 53 has been passed, it can write block 53 into the blockchain.

[0113] The implementation of the above-mentioned process for sorting the positions of transactions to be packaged and the incremental encoding process for sorting the positions of transactions can be found in the following: Figure 3 , Figure 5 Specific descriptions in the corresponding embodiments.

[0114] Depend on Figure 2 As can be seen, the block compression method provided in this application embodiment can reorder transactions according to the priority of the transaction attribute type and the transaction attribute value corresponding to the transaction attribute type. This sorting mechanism will arrange the duplicate transaction attribute values ​​contained in multiple transactions together as much as possible, thereby achieving higher data redundancy elimination efficiency in the subsequent incremental encoding compression stage, reducing the storage space required for blocks, and thus improving the performance of the blockchain system.

[0115] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based block compression method provided in an embodiment of this application. The method can be implemented by blockchain nodes (e.g., the aforementioned...). Figure 1 This is executed by any blockchain node in the blockchain network of the corresponding embodiment, such as blockchain node 10a). The following description will use the execution of this method by a blockchain node as an example, wherein the blockchain-based data processing method may include at least the following steps S101-S105:

[0116] Step S101: Obtain M transactions to be packaged; M is a positive integer; each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types; N is a positive integer.

[0117] Specifically, transactions awaiting packaging refer to transactions that have not yet been packaged into a block and are typically stored in a transaction pool. When a user submits a new transaction to the blockchain network, the transaction first enters the transaction pool. When preparing to generate a new block, a blockchain node selects a certain number of transactions from the transaction pool to package. This certain number of transactions refers to the M transactions awaiting packaging described in this application. M is determined by the current blockchain's block configuration; for example, if a block in the current blockchain can contain 100 transactions, then M is 100.

[0118] Specifically, to facilitate understanding of the transaction structure of the transactions to be packaged, please refer to Table 2 below. Table 2 provides a feasible example of a transaction structure:

[0119] Table 2

[0120]

[0121] As shown in Table 2 above, a transaction to be packaged can contain transaction attribute values ​​of 10 transaction attribute types. However, in different transactions to be packaged, the same transaction attribute type might contain identical transaction attribute values. For example, in the three transactions to be packaged mentioned above, the transaction attribute value for the transaction sender identity type is "Alice," and the transaction attribute value for the contract name type is "c1." In other words, transaction attribute values ​​corresponding to transaction attribute types such as address, contract name, and transaction sender identity might appear repeatedly in the M transactions to be packaged. Traditional block storage schemes often repeatedly store this same data, leading to unnecessary space waste.

[0122] Step S102: Based on the transaction attribute type priority corresponding to each of the N transaction attribute types and the M transaction attribute values ​​corresponding to each of the N transaction attribute types, perform position sorting processing on the M transactions to be packaged to obtain M position sorted transactions.

[0123] Specifically, in order to effectively compress transaction attribute values ​​that appear repeatedly in M ​​transactions to be packaged, blockchain nodes can sort the M transactions by position. Without affecting the integrity and accessibility of the transactions, transactions with smaller changes in transaction attribute values ​​should be placed at the front, thereby achieving higher data redundancy elimination efficiency in the subsequent incremental encoding and compression stage.

[0124] Specifically, the transaction attribute type priority is used to characterize the probability of the transaction attribute value corresponding to a transaction attribute type changing among the M transactions to be packaged. The transaction attribute type priority can be set based on manual experience, or it can be set according to the changes in the transaction attribute values ​​corresponding to each transaction attribute type in transactions generated over a period of time (for example, calculating the dynamic variance or dynamic standard deviation corresponding to the transaction attribute value, and reflecting the changes based on the magnitude of the dynamic variance or dynamic standard deviation). This application does not impose any restrictions here. It can be understood that the higher the priority of the transaction attribute type (the earlier it appears), the less likely the transaction attribute value corresponding to that transaction attribute type will change among the M transactions to be packaged. Therefore, when sorting the M transactions to be packaged, the blockchain node should prioritize the transaction attribute type with the highest priority, that is, try to group the transactions to be packaged together with the transaction attribute values ​​corresponding to the highest priority of the same transaction attribute type, and then consider the transaction attribute type with the second highest priority.

[0125] Specifically, based on the priority of each of the N transaction attribute types and the M transaction attribute values ​​corresponding to each of the N transaction attribute types, a feasible implementation process for sorting the M transactions to be packaged into M position-sorted transactions can be as follows: Iterate through the N transaction attribute types according to their priorities to obtain the k-th transaction attribute type; the priority of the transaction attribute type corresponding to the k-th transaction attribute type is lower than the priority of the (k-1)-th transaction attribute type; perform the k-th position sorting on the M intermediate position-sorted transactions after the (k-1)-th position sorting according to the M transaction attribute values ​​corresponding to the k-th transaction attribute type. Sort the M intermediate transactions after the k-th position sorting; when k is 1, the M intermediate transactions after the (k-1)-th position sorting are the M transactions to be packaged; if the M transaction attribute values ​​corresponding to the k-th transaction attribute type contain the same transaction attribute value, then continue to obtain the (k+1)-th transaction attribute type, and sort the M intermediate transactions after the k-th position sorting by the (k+1)-th position according to the M transaction attribute values ​​corresponding to the (k+1)-th position sorting; if the M transaction attribute values ​​corresponding to the k-th transaction attribute type do not contain consecutive and identical transaction attribute values, then stop traversing the N transaction attribute types, and determine the M intermediate transactions after the k-th position sorting as the M position sorting transactions.

[0126] One feasible implementation process for sorting the M intermediate position transactions after the (k-1)th position sorting based on the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain the M intermediate position transactions after the k-th position sorting can be as follows: Sorting the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain M sorted transaction attribute values; identifying intermediate position transactions among the M intermediate position transactions after the (k-1)th position sorting that contain the same first transaction attribute value and are in consecutive positions as intermediate position transactions to be adjusted; the first transaction attribute value refers to the transaction attribute value with the (k-1)-th transaction attribute type; when k is 1, the intermediate position transactions to be adjusted are M transactions to be packaged; based on the positional relationship of the second transaction attribute value contained in the intermediate position transactions to be adjusted among the M sorted transaction attribute values, performing position adjustment processing on the intermediate position transactions to be adjusted among the M intermediate position transactions to obtain the M intermediate position transactions after the k-th position sorting; the second transaction attribute value refers to the transaction attribute value with the k-th transaction attribute type.

[0127] To better understand the process of sorting the M transactions to be packaged, please refer to [the previous text]. Figure 4 , Figure 4This is a schematic diagram illustrating a transaction location sorting method provided in an embodiment of this application. For example... Figure 4 As shown, assuming the blockchain node (not shown in the diagram, but could be one of the above) Figure 1 In the blockchain network shown, for example, blockchain node 10b), there are four transactions to be packaged that need to be sorted by position: transactions 41, 42, 43, and 44. Each transaction to be packaged contains transaction attribute values ​​of four transaction attribute types. These four transaction attribute types can be transaction ID, chain ID, contract method, and contract name. The priority of the transaction attribute type corresponding to transaction ID is 4, the priority of the transaction attribute type corresponding to chain ID is 1, the priority of the transaction attribute type corresponding to contract method is 3, and the priority of the transaction attribute type corresponding to contract name is 2. That is, the priority of the transaction attribute type corresponding to chain ID > the priority of the transaction attribute type corresponding to contract name > the priority of the transaction attribute type corresponding to contract method > the priority of the transaction attribute type corresponding to transaction ID. Therefore, when the blockchain node traverses the four transaction attribute types according to their respective priorities, the first transaction attribute type obtained should be chain ID.

[0128] like Figure 4 As shown, the blockchain node first sorts the four transactions to be packaged according to the four transaction attribute values ​​corresponding to the chain ID, resulting in four transactions in intermediate positions after the first sort. The specific process of the first sort can be as follows: sort the four transaction attribute values ​​corresponding to the chain ID to obtain four sorted chain ID transaction attribute values; adjust the positions of the four transactions to be packaged according to the positional relationship of the four sorted chain ID transaction attribute values, resulting in four transactions in intermediate positions after the first sort. The attribute value sorting can be done using lexicographical sorting, also known as lexicographical ordering. Lexicographical sorting is a sorting method based on the alphabetical order of characters or numbers. In computer science, lexicographical sorting usually refers to arranging comparable objects such as strings, characters, or numbers according to lexicographical order. The basic principle of this sorting method is: if two objects have different characters at a certain position, they are sorted according to the alphabetical order of the characters at that position, i.e., smaller characters are placed first, and larger characters are placed later; if the comparison continues until one object is reached, the shorter string or object is placed first; if two objects are identical, their lexicographical order is the same. Depend on Figure 4 As can be seen, the four transaction attribute values ​​corresponding to the chain ID are all actually chain1. Therefore, the positions of the four sorted chain ID transaction attribute values ​​have not changed. Thus, the four transactions in the middle position after the first position sorting are transaction 41, transaction 42, transaction 43, and transaction 44 in order.

[0129] like Figure 4 As shown, when a blockchain node traverses the four transaction attribute types according to their priority, the second transaction attribute type obtained is the contract name. The blockchain node then performs a second sorting of the four transactions in the middle positions after the first sorting based on the four transaction attribute values ​​corresponding to the contract name, resulting in the four transactions in the middle positions after the second sorting. The specific process of the second position sorting can be as follows: First, sort the four transaction attribute values ​​corresponding to the contract name to obtain four sorted contract name transaction attribute values, which are: c1 contained in transaction 41, c1 contained in transaction 42, c1 contained in transaction 44, and c2 contained in transaction 43. Then, since the transaction attribute value corresponding to the chain ID contained in the four intermediate position sorted transactions after the first position sorting is chain1, the four intermediate position sorted transactions after the first position sorting are all intermediate position sorted transactions to be adjusted. At this time, the blockchain node will adjust the position of the intermediate position sorted transactions to be adjusted according to the position relationship of the transaction attribute value corresponding to the contract name contained in the intermediate position sorted transactions to be adjusted among the four sorted contract name transaction attribute values, to obtain the four intermediate position sorted transactions after the second position sorting, which are in the following order: transaction 41, transaction 42, transaction 44, and transaction 43.

[0130] like Figure 4As shown, when a blockchain node traverses the four transaction attribute types according to their priority, the third transaction attribute type obtained is the contract method. The blockchain node then performs a third sorting on the four intermediate transactions after the second sorting based on the four transaction attribute values ​​corresponding to the contract method, resulting in four intermediate transactions after the third sorting. The specific process of the third sorting is as follows: First, the four transaction attribute values ​​corresponding to the contract method are sorted, resulting in four sorted contract method transaction attribute values: `set` contained in transaction 41, `set` contained in transaction 44, `set` contained in transaction 43, and `get` contained in transaction 42. Then, because only transactions 41, 42, and 44 have the same contract name and are in consecutive positions among the four intermediate transactions after the second sorting, the blockchain node will only identify transactions 41, 42, and 44 as the intermediate transactions to be adjusted in the third sorting. At this point, the blockchain node will adjust the position of the intermediate order transactions to be adjusted in the third position sorting process based on the positional relationship of the transaction attribute values ​​corresponding to the contract methods contained in the intermediate order transactions to be adjusted among the four sorted contract name transaction attribute values. That is, because in the four sorted contract name transaction attribute values, the set contained in transaction 41 is before the set contained in transaction 44, and the set contained in transaction 44 is before the get contained in transaction 42, after the position adjustment, transaction 41 should be before transaction 44, and transaction 44 should be before transaction 42. Therefore, the four intermediate order transactions after the third position sorting are obtained in the following order: transaction 41, transaction 44, transaction 42, and transaction 43.

[0131] like Figure 4As shown, when a blockchain node traverses the four transaction attribute types according to their priority, the fourth transaction attribute type obtained is the transaction ID. The blockchain node then performs a fourth sorting of the four intermediate transactions after the third sorting based on the four transaction attribute values ​​corresponding to the contract method. The specific process of the fourth sorting is as follows: First, the four transaction attribute values ​​corresponding to the transaction ID are sorted, resulting in four sorted transaction ID transaction attribute values: 0x12 for transaction 44, 0x17 for transaction 43, 0x65 for transaction 42, and 0x91 for transaction 41. Then, because only transactions 41 and 44 have the same contract name and consecutive positions among the four intermediate transactions after the third sorting, the blockchain node will only determine transactions 41 and 44 as the fourth sorted transactions. When the transaction to be sorted in the middle position is adjusted, the blockchain node will adjust the position of the transaction to be sorted in the middle position according to the position relationship of the transaction attribute value corresponding to the transaction ID contained in the middle position of the four sorted contract name transaction attribute values. That is, because 0x12 contained in transaction 44 is before 0x91 contained in transaction 41 in the four sorted contract name transaction attribute values, after the position adjustment, transaction 44 should be before transaction 41. Therefore, the four middle position sorted transactions after the fourth position sort are obtained in the following order: transaction 44, transaction 41, transaction 42, and transaction 43.

[0132] It is understandable that after all four transaction attribute types have been traversed, the blockchain node will determine the four middle position transactions after the last position sort as the four position sorted transactions, in the following order: transaction 44, transaction 41, transaction 42, and transaction 43.

[0133] Optionally, a feasible implementation process for sorting the M intermediate position transactions after the (k-1)th position sorting based on the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain the M intermediate position transactions after the k-th position sorting can be as follows: Among the M intermediate position transactions after the (k-1)th position sorting, intermediate position transactions containing the same first transaction attribute value and with consecutive positions are identified as intermediate position transactions to be adjusted; the first transaction attribute value refers to a transaction attribute value with the (k-1)th transaction attribute type; when k is 1, the intermediate position transactions to be adjusted are M transactions to be packaged; the second transaction attribute values ​​contained in the intermediate position transactions to be adjusted are sorted to obtain sorted second transaction attribute values; the intermediate position transactions to be adjusted among the M intermediate position transactions are adjusted according to the positional relationship of the attribute values ​​of the sorted second transaction attribute values ​​to obtain the M intermediate position transactions after the k-th position sorting; the second transaction attribute value refers to a transaction attribute value with the k-th transaction attribute type. For example, in the above... Figure 4 The blockchain node shown will perform a fourth sorting of the four intermediate transactions after the third sorting, based on the four transaction attribute values ​​corresponding to the contract method. The specific process of the fourth sorting is as follows: The blockchain node first determines the intermediate transactions to be adjusted. Because among the four intermediate transactions after the third sorting, only transactions 41 and 44 have the same transaction attribute value corresponding to their contract names and are in consecutive positions, the blockchain node will only sort transactions 41 and 44 among the four intermediate transactions after the third sorting. Transaction 44 is identified as the intermediate transaction to be adjusted in the fourth position sorting. Then, the blockchain node sorts the transaction attribute values ​​corresponding to the transaction IDs contained in transaction 41 and transaction 44, resulting in the sorted transaction ID transaction attribute values ​​as follows: 0x12 contained in transaction 44 and 0x91 contained in transaction 41. Based on the positional relationship between the sorted transaction ID transaction attribute values, the blockchain node will adjust transaction 44 to a position before transaction 41. Therefore, the four intermediate transactions after the fourth position sorting are obtained in the following order: transaction 44, transaction 41, transaction 42, and transaction 43.

[0134] Step S103: Add the transaction attribute values ​​with the same transaction attribute type from the M position-sorted transactions to the same set of attribute values ​​to be compressed according to the positional order among the M position-sorted transactions, to obtain the set of attribute values ​​to be compressed corresponding to the N transaction attribute types respectively.

[0135] Specifically, as mentioned above Figure 4Taking the four positions of the transaction as an example, the set of attribute values ​​to be compressed corresponding to the transaction ID is {0x12, 0x91, 0x65, 0x17}, the set of attribute values ​​to be compressed corresponding to the chain ID is {chain1, chain1, chain1, chain1}, the set of attribute values ​​to be compressed corresponding to the contract method is {set, set, get, set}, and the set of attribute values ​​to be compressed corresponding to the contract name is {c1, c1, c1, c2}.

[0136] Step S104: Perform incremental encoding compression on the N sets of attribute values ​​to be compressed to obtain N incremental encodings of attribute values.

[0137] Specifically, incremental encoding is a data compression technique that stores only the changing parts of a data sequence, rather than storing the complete data point each time. In blockchain transactions, incremental encoding can be used to reduce redundancy in storing identical or similar transaction data. For example, if consecutive transactions come from the same sender, the sender's address can be stored only once when storing these transactions; subsequent transactions only need to store a tag or reference indicating that the field is the same as the previous transaction.

[0138] Specifically, assume there are N sets of attribute values ​​to be compressed, including a set K of attribute values ​​to be compressed. n Let n be a positive integer less than or equal to N. A feasible implementation process for incremental encoding compression of N sets of attribute values ​​to be compressed can be as follows: The set of attribute values ​​to be compressed, K... n The first transaction attribute value is written into the incremental encoding set and the attribute value set to be compressed, K, respectively. n The corresponding transaction attribute labeling field; sequentially traverse the set K of attribute values ​​to be compressed. n To obtain the i-th transaction attribute value, where i is a positive integer greater than or equal to 2 and less than or equal to M, if the i-th transaction attribute value is different from the transaction attribute value contained in the transaction attribute labeling field, then the i-th transaction attribute value is added sequentially to the incremental encoding set, and the transaction attribute value contained in the transaction attribute labeling field is replaced with the i-th transaction attribute value; if the i-th transaction attribute value is the same as the transaction attribute value contained in the transaction attribute labeling field, then the special encoded characters are added sequentially to the incremental encoding set, until the set of attribute values ​​to be compressed, K, is determined. n Completed; the set of attribute values ​​K to be compressed has been determined based on the incremental encoding set. n The corresponding attribute values ​​are incrementally encoded. For example, the set of attribute values ​​K to be compressed. nLet K3 = {set, set, get, set} be the set of attribute values ​​to be compressed corresponding to the contract method described in step S103 above. Then, the blockchain node can first write the first transaction attribute value into the incremental encoding set Z and the transaction attribute labeling field word, i.e., Z = {set}, word = set. Next, the blockchain node iterates through the set of attribute values ​​to be compressed K3 corresponding to the contract method to obtain the second transaction attribute value (set). Because the second transaction attribute value is the same as the transaction attribute value contained in the transaction attribute labeling field word, the blockchain node only needs to add the special encoded character (assuming it is *) sequentially to the incremental encoding set Z. At this point, the incremental encoding set Z = {set, *}, and the transaction attribute labeling field word is... The field `word` is set. Then, the blockchain node obtains the third transaction attribute value (get). Because the third transaction attribute value is different from the transaction attribute value contained in the transaction attribute identification field `word`, the blockchain node will write the third transaction attribute value into the incremental encoding set Z and the transaction attribute identification field `word` respectively. At this time, the incremental encoding set Z = {set, *, get}, and the transaction attribute identification field `word` = get. This process continues until the last transaction attribute value in the set of attribute values ​​to be compressed K3 is traversed, resulting in the incremental encoding set Z = {set, *, get, set}. Therefore, the incremental encoding of the attribute value corresponding to the set of attribute values ​​to be compressed K3 is {set, *, get, set}.

[0139] Step S105: Perform block encapsulation processing on the incremental encoding of the N attribute values ​​to obtain a block to be added to the blockchain; the block to be added to the blockchain is used to be added to the blockchain when consensus is passed.

[0140] Specifically, a blockchain node can incrementally encode and add the obtained N attribute values ​​to a block, resulting in a block to be added to the blockchain. This block is then broadcast to other blockchain nodes in the network to achieve consensus. Once a blockchain node confirms that the consensus on the block has been reached, it can add the block to the blockchain ledger for storage.

[0141] The method provided in this application introduces an incremental encoding mechanism. For transaction attribute values ​​corresponding to consecutively occurring transaction attribute types, only a special symbol needs to be used to represent them, instead of repeatedly storing the entire transaction attribute value, thus avoiding unnecessary space waste. Furthermore, this application can reorder the transactions to be packaged based on the priority of the corresponding transaction attribute types and the transaction attribute values. This sorting mechanism ensures that transactions with less change in transaction attribute values ​​are processed first in the incremental encoding compression stage. Therefore, higher data redundancy elimination efficiency can be achieved in the incremental encoding compression stage, thereby reducing the storage space required for blocks and improving the performance of the blockchain system.

[0142] Further, please see Figure 5 , Figure 5 This is a flowchart illustrating a blockchain-based priority determination method provided in an embodiment of this application. The method can be implemented by blockchain nodes (e.g., the aforementioned...). Figure 1 Any blockchain node in the blockchain network of the corresponding embodiment, such as blockchain node 10a), executes this method. This method can be used to determine the above... Figure 3 The corresponding transaction attribute types in the various embodiments are prioritized according to their respective transaction attribute types. The following explanation will use the execution of this method by a blockchain node as an example. This blockchain-based priority determination method will at least include the following steps S201-S203:

[0143] Step S201: Obtain transaction attribute type T from N transaction attribute types. j The corresponding transaction attribute type sliding window; j is a positive integer less than or equal to N; the transaction attribute type sliding window contains L values ​​with the transaction attribute type T. j The corresponding historical transaction attribute values.

[0144] Specifically, transaction attribute type T j Belonging to the above Figure 3 In the corresponding embodiment, there are N transaction attribute types, where j is a positive integer less than or equal to N. Transaction attribute type T j The corresponding transaction attribute type sliding window is used to continuously detect and analyze the transaction attribute type T contained in the most recently added transactions on the blockchain. j The corresponding transaction attribute value, and the sliding window for this transaction attribute type will change according to the transaction attribute type T included in the new exchange. j The "sliding" occurs due to the addition of corresponding transaction attribute values, i.e., the transaction attribute type T included in the new exchange. j The corresponding transaction attribute value is added to one end of the sliding window for that transaction attribute type, while the old exchange contains transaction attribute type T. j The corresponding transaction attribute value is then output from the other end.

[0145] Step S202, based on the M transactions to be packaged that have the transaction attribute type T j The transaction attribute type T is determined by the transaction attribute value and the transaction attribute type sliding window. j The latest attribute value is far from the standard deviation.

[0146] Specifically, the M transactions to be packaged can be as described above. Figure 3 The corresponding embodiment refers to the M transactions to be packaged. The latest attribute value's distance from the standard deviation refers to the distance from the M transactions to be packaged to the transaction attribute type T. jThe transaction attribute type T is included in the transaction attribute value and transaction attribute type sliding window. j The attribute value distance standard deviation is determined by the corresponding historical transaction attribute values. The attribute value distance standard deviation reflects the degree of change in a set of transaction attribute values. The larger the attribute value distance standard deviation, the greater the degree of change in the set of transaction attribute values, meaning fewer times the same transaction attribute value appears. Attribute value distance refers to the distance between two transaction attribute values. Specifically, it is defined as follows: when two transaction attribute values ​​are the same, the attribute value distance between them is 0; when two transaction attribute values ​​are different, the attribute value distance between them is 1.

[0147] Specifically, based on the transaction attribute type T among the M transactions to be packaged... j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j A feasible implementation process for determining the distance between the latest attribute value and the standard deviation can be as follows: Among the M transactions to be packaged, those with transaction attribute type T... j The transaction attribute values ​​are placed sequentially before the position of the transaction attribute type sliding window; the transaction attribute type sliding window is then slid forward to obtain the slid-out transaction attribute type sliding window; the slid-out transaction attribute type sliding window contains L of the latest transaction attribute values; the L latest transaction attribute values ​​contain M transactions to be packaged that have transaction attribute type T. j The transaction attribute values; determine the transaction attribute type T based on the L latest transaction attribute values. j The latest attribute value is far from the standard deviation.

[0148] To better understand the sliding process of the transaction attribute type slider window, please also refer to... Figure 6 , Figure 6 This is a schematic diagram of a sliding window for transaction attribute types provided in an embodiment of this application. For example... Figure 6 As shown, assuming the transaction attribute type is T j The contract name is the corresponding transaction attribute type sliding window, which is the contract name sliding window. After obtaining the contract names (c2, c1, c2, c2) contained in the four transactions to be packaged, the blockchain node can obtain the contract name sliding window. At this time, it can contain eight historical contract names, namely c1, c2, c1, c1, c3, c4, c1, c2. Then, the blockchain node can slide the contract name sliding window to obtain the slidable contract name sliding window. Figure 6As can be seen, the sliding window for contract names will contain the contract names of the four transactions to be packaged, while the four historical contract names that were originally at the end of the sliding window will be removed. Therefore, the sliding window for contract names will contain eight new contract names, namely c3, c4, c1, c2, c2, c1, c2, c2.

[0149] Specifically, the transaction attribute type T is determined based on the L latest transaction attribute values. j A feasible implementation process for determining the distance between the latest attribute value and the standard deviation can be as follows: Generate an attribute value mapping map based on L latest transaction attribute values; calculate the transaction attribute type T based on the quantity L and the occurrence counts of the P mapped attribute values. j The latest attribute value is far from the standard deviation.

[0150] The attribute value mapping map contains P mapped attribute values ​​and the occurrence counts corresponding to each of the P mapped attribute values. An occurrence count refers to the number of the latest transaction attribute values ​​that are the same as a mapped attribute value among the L latest transaction attribute values. A mapped attribute value refers to a transaction attribute value that has appeared among the L latest transaction attribute values. Multiple identical transaction attribute values ​​correspond to the same mapped attribute value. A feasible implementation process for generating an attribute value mapping map based on L latest transaction attribute values ​​can be as follows: Create an initial attribute value mapping map; traverse the L latest transaction attribute values ​​to obtain the q-th latest transaction attribute value; q is a positive integer less than or equal to L; if the initial attribute value mapping map contains a mapping attribute value identical to the q-th latest transaction attribute value, then accumulate the occurrence count corresponding to the mapping attribute value identical to the q-th latest transaction attribute value; if the initial attribute value mapping map does not contain a mapping attribute value identical to the q-th latest transaction attribute value, then use the q-th latest transaction attribute value as the new mapping attribute value, determine the starting quantity as the occurrence count corresponding to the new mapping attribute value, and add the new mapping attribute value and its occurrence count to the initial attribute value mapping map; the initial attribute value mapping map after traversing the L latest transaction attribute values ​​is determined as the attribute value mapping map. For example, the attribute value mapping map generated from the sliding window containing the 8 latest contract names (c3, c4, c1, c2, c2, c1, c2, c2) is the contract name: Map(c1:2, c2:4, c3:1, c4:1). Here, c1:2 indicates that c2 appears twice among the 8 latest contract names.

[0151] The transaction attribute type T is calculated based on the quantity L and the occurrence counts corresponding to the P mapping attribute values. jA feasible implementation of the distance between the latest attribute value and the standard deviation can be as follows: Iterate through the occurrence counts corresponding to P mapped attribute values ​​to obtain the s-th occurrence count; s is a positive integer less than or equal to P; determine the difference between the count L and the s-th occurrence count as the s-th unit attribute distance; determine the product of the s-th unit attribute distance and the s-th occurrence count as the s-th attribute distance; continue until the occurrence counts corresponding to P mapped attribute values ​​are traversed; divide the sum of the P attribute distances by the square of the count L to obtain the transaction attribute type T. j The corresponding latest attribute value is far from the standard deviation. The above calculation process can be expressed by formula (1):

[0152]

[0153] Where Dis represents the distance of the latest attribute value from the standard deviation, and P... s This refers to the number of occurrences of the s-th mapped attribute value out of P mapped attribute values. L refers to the total length of the attribute value mapping map, which is the number of the latest transaction attribute values ​​used when generating the attribute value mapping map. P simply refers to the number of mapped attribute values.

[0154] It is understandable that the longer the transaction attribute type sliding window is (i.e., the more transaction attribute values ​​it can contain), the more transactions of type T can be included, based on the transaction attribute type sliding window and the number of M transactions to be packaged. j The transaction attribute type T is calculated from the transaction attribute value. j The more stable the latest attribute value is from the standard deviation, the more difficult it is to directly calculate the transaction attribute type T based on the L latest transaction attribute values. j The more computing resources are required to determine the distance between the latest attribute value and the standard deviation, the better. At this point, the blockchain node can choose to update the already calculated distance between the attribute value and the standard deviation based on the transaction attribute values ​​that have been added to the transaction attribute type sliding window and the transaction attribute values ​​that need to be removed from the transaction attribute type sliding window, thus obtaining the latest distance between the attribute value and the standard deviation.

[0155] Therefore, the above is based on the transaction attribute type T among the M transactions to be packaged. j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j Another feasible implementation of the process for determining the distance between the latest attribute value and the standard deviation is: obtaining the transaction attribute type T. j The corresponding historical attribute value's distance from the standard deviation; the historical attribute value's distance from the standard deviation is determined based on the transaction attribute values ​​contained in the transaction attribute type sliding window; among the M transactions to be packaged, those with transaction attribute type T jThe transaction attribute values ​​are sequentially placed before the position of the transaction attribute type sliding window; the transaction attribute type sliding window after the (t-1)th unit slide is processed with the tth forward unit slide to obtain the transaction attribute type sliding window after the tth unit slide; the transaction attribute value at the end of the transaction attribute type sliding window after the (t-1)th unit slide is determined as the tth slide-removed transaction attribute value, and the transaction attribute value at the beginning of the transaction attribute type sliding window after the tth unit slide is determined as the tth slide-added transaction attribute value; the tth slide-added transaction attribute value belongs to the M transactions to be packaged that have transaction attribute type T. j The transaction attribute values ​​are used to update the standard deviation of the (t-1)th updated attribute value based on the t-th sliding addition and removal transaction attribute values. When t is 1, the standard deviation of the (t-1)th updated attribute value is the standard deviation of the historical attribute value. When t equals M, the standard deviation of the Mth updated attribute value is determined as the transaction attribute type T. j The corresponding latest attribute value is the distance from the standard deviation. In other words, if a blockchain node has already obtained the distance from the standard deviation of the historical attribute values ​​corresponding to the transaction attribute values ​​included in the transaction attribute type sliding window, the blockchain node can directly update based on the distance from the historical attribute values ​​to the standard deviation, without having to directly calculate the distance from the standard deviation of the latest attribute values ​​again.

[0156] One feasible implementation process for updating the distance standard deviation of the (t-1)th updated attribute value based on the t-th sliding addition and removal transaction attribute values ​​is as follows: Obtain the number of added attributes with the same transaction attribute value as the t-th sliding addition transaction attribute value in the transaction attribute type sliding window after the (t-1)th unit sliding, and the number of removed attributes with the same transaction attribute value as the t-th sliding removal transaction attribute value in the transaction attribute type sliding window after the (t-1)th unit sliding; subtract the difference between the quantity L and the number of added attributes and the difference between the quantity L and the number of removed attributes to obtain the changed attribute distance; add the quotient between the changed attribute distance and the square of the quantity L to the distance standard deviation of the (t-1)th updated attribute value to obtain the distance standard deviation of the t-th updated attribute value. The above update process can be represented by formula (2):

[0157]

[0158] Among them, Dis t Dis refers to the distance of the t-th updated attribute value from the standard deviation. t-1 P represents the distance of the (t-1)th updated attribute value from the standard deviation. t This refers to the number of attributes added, P t-1The value is the number of attributes to remove. L refers to the window length of the transaction attribute type sliding window, which is the number of transaction attribute values ​​it can contain.

[0159] Step S203: When the distance from the latest attribute value to the standard deviation of the N transaction attribute types is obtained, the priority of the transaction attribute types corresponding to the N transaction attribute types is determined according to the distance from the latest attribute value to the standard deviation of the N transaction attribute types.

[0160] Specifically, transaction attribute type T j The smaller the distance between the latest attribute value and the standard deviation, the more likely the transactions contain the same type of transaction attribute T. j The smaller the degree of change in the corresponding transaction attribute value, the more likely duplicate transaction attribute values ​​will appear. Therefore, the transaction attribute type T j The higher the priority of the corresponding transaction attribute type, the better. For example, if the latest attribute value of transaction attribute type T1 is less than the latest attribute value of transaction attribute type T3, which is less than the latest attribute value of transaction attribute type T2, then the blockchain node can determine that the priority of transaction attribute type T1 is 1, the priority of transaction attribute type T3 is 2, and the priority of transaction attribute type T2 is 3. That is, the priority of transaction attribute type T1 > the priority of transaction attribute type T3 > the priority of transaction attribute type T2.

[0161] The method provided in this application can calculate the dynamic standard deviation of each transaction attribute type in the transaction data (i.e., calculate the distance from the latest attribute value to the standard deviation each time a block is generated), and use this statistical characteristic to redetermine the priority of the transaction attribute type. This allows for prioritizing transactions with smaller changes in transaction attribute values ​​when sorting the positions of transactions to be packaged, thereby achieving higher data redundancy elimination efficiency in the subsequent incremental encoding compression stage. Furthermore, by using sliding window technology to analyze the continuity of transaction attributes (calculating the dynamic standard deviation), the system can monitor and evaluate the changing trends of transaction attribute values ​​in real time, adapt to changes in transaction patterns, and ensure the optimal performance of the compression mechanism under different transaction environments.

[0162] Furthermore, the above Figure 3 and Figure 5 The methods described in the corresponding embodiments can be implemented using different system architectures based on actual conditions. For example, please refer to [link to relevant documentation]. Figure 7 , Figure 7 This application provides a system architecture for a transaction incremental coding block compression scheme based on a sliding window and dynamic standard deviation, as illustrated in an embodiment. Figure 7As shown, a blockchain node can include a network module, a verification module, a transaction pool module, a scheduling module, a consensus module, and a storage module. The internal implementation of a blockchain node and the interactions between these modules are described in detail below:

[0163] like Figure 7 The network module shown is responsible for handling all network communication between nodes, including sending, receiving, and forwarding data. It acts as a bridge between nodes and the outside world, ensuring that information can be transmitted securely and efficiently within the blockchain network. It handles all network-level operations, such as connection management, implementation of data transmission protocols, node discovery, and data synchronization.

[0164] like Figure 7 The primary responsibility of the verification module shown is to ensure the legitimacy and correctness of transactions and blocks. It typically comprises two sub-modules: certificate verification and permission verification. Certificate verification verifies the identity certificate of the transaction or block creator, ensuring its legitimacy and trustworthiness. Permission verification checks whether the entity initiating the transaction has the authority to execute it, and whether the transaction complies with the rules and policies of the blockchain network; for example, some transactions may only be allowed to be executed by specific users or roles.

[0165] like Figure 7 The transaction pool module shown is a temporary storage area used to hold transactions that have been received by blockchain nodes but have not yet been packaged into a block. It allows nodes to sort and select transactions to determine which transactions will be included in the next block.

[0166] like Figure 7 The scheduling module shown is responsible for coordinating the activities of blockchain nodes, including transaction reception, processing, and block generation. It includes the following sub-modules: a block generator, a transaction scheduling module, a contract repository, and a contract process pool. The block generator is responsible for generating new blocks; it selects suitable transactions from the transaction pool and assembles them into blocks according to specific rules. The transaction scheduling module manages the transactions in the transaction pool, deciding which transactions should be prioritized or included in new blocks. The contract repository stores all smart contract code and related metadata deployed on the blockchain. The contract process pool manages the execution environment of smart contracts, providing resource isolation and execution efficiency.

[0167] like Figure 7The block generator shown includes the following sub-modules: a transaction compressor, a transaction sequencer, an incremental encoder, a multi-transaction attribute sliding window, and a multi-transaction attribute window number mapping. The transaction compressor is responsible for compressing transaction data to reduce block size. The transaction sequencer determines the order of transactions within a block. The incremental encoder uses incremental encoding technology to encode transaction data for further compression. The multi-transaction attribute sliding window implements sliding window technology to detect the continuity of transaction attributes. The multi-transaction attribute window number mapping maintains the mapping relationship between transaction attribute types within the sliding window to support dynamic standard deviation calculation.

[0168] like Figure 7 The consensus module shown implements the consensus algorithm in the blockchain network, which is crucial for blockchain security and consistency. The consensus module ensures that all nodes reach a consensus on the network state and verifies the legitimacy of new blocks.

[0169] like Figure 7 The storage module shown is responsible for maintaining and managing all data storage on the blockchain, including the current state and historical records. It typically contains two sub-modules: a state database and a block ledger. The state database stores the current blockchain state, such as account balances and smart contract states. The block ledger stores all blocks and transactions that have been confirmed by the network, forming the blockchain's historical record.

[0170] Understandable, such as Figure 7 Each module shown can be deployed on a blockchain node, and the functions provided by each module can also be implemented by the blockchain node.

[0171] By having all the modules in the transaction incremental coding block compression scheme system architecture based on sliding window and dynamic standard deviation provided in this application work together, it can be ensured that the blockchain node can efficiently and stably implement the entire lifecycle process of the transaction incremental coding block compression scheme based on sliding window and dynamic standard deviation. This includes the transaction sorting process based on sliding window and dynamic standard deviation (when creating a new block, the blockchain node calculates the dynamic standard deviation of the transaction attribute type according to the latest sliding window information, determines the priority of the transaction attribute type according to the dynamic standard deviation, and then sorts the transactions) and the block compression process based on transaction incremental coding (the process by which the blockchain node incrementally encodes the attributes of each transaction in the sorted transactions, thereby compressing redundant and continuous fields).

[0172] Furthermore, to facilitate understanding of the methods proposed based on the above embodiments and the above-described... Figure 7The system architecture shown is based on a transaction incremental encoding block compression scheme using a sliding window and dynamic standard deviation. The transaction sorting process based on the sliding window and dynamic standard deviation is also described. Please refer to [link / reference needed]. Figure 8 , Figure 8 This is a schematic diagram of a transaction sorting process based on a sliding window and dynamic standard deviation, provided in an embodiment of this application. Figure 8 As shown, the entire transaction sorting process may include the following steps S301-S311:

[0173] In step S301, the blockchain node receives the block signal and obtains a batch of transactions from the transaction pool through the scheduling module.

[0174] Specifically, the quantity of this batch of transactions can be M, where M is a positive integer. Therefore, this batch of transactions is actually the one described above. Figure 3 The corresponding embodiment describes the M transactions to be packaged.

[0175] In step S302, the transaction scheduling module sends these transactions to the contract process pool in parallel for execution.

[0176] In step S303, the block generator receives the transaction results processed by the contract process pool.

[0177] Step S304: The multi-transaction attribute sliding window places the information of each field of the above transaction into the multi-transaction attribute sliding window.

[0178] Specifically, a transaction can consist of multiple fields. Each field stores the transaction attribute value corresponding to a transaction attribute type. Therefore, the information in each field of a transaction actually refers to the transaction attribute values ​​of each transaction attribute type contained in the transaction.

[0179] Specifically, a multi-transaction attribute sliding window can contain sliding windows for transaction attribute types corresponding to various transaction attribute types. Placing the information of each field of the above transaction into the multi-transaction attribute sliding window is essentially adding the transaction attribute values ​​corresponding to the same transaction attribute type to the corresponding transaction attribute type sliding window.

[0180] Step S305: Delete the oldest transaction from the multi-transaction attribute sliding window.

[0181] Specifically, deleting the oldest transaction actually means deleting the corresponding historical transaction attribute values. The number of transactions to be deleted is determined by the number of transaction attribute values ​​added, and the two should be consistent.

[0182] Step S306: Update the attribute map values ​​for all transaction attribute types by mapping the number of multi-transaction attribute windows.

[0183] Specifically, updating the attribute map value corresponding to the transaction attribute type involves determining the attribute value mapping map corresponding to the transaction attribute type. For details on the implementation, please refer to the above. Figure 5 The specific description of step S202 in the corresponding embodiment will not be repeated here.

[0184] Step S307: The transaction sequencer updates the attribute distance standard deviation of all transaction attribute types within the multi-transaction sliding window.

[0185] Specifically, the transaction sequencer updates the standard deviation of the attribute distance for all transaction attribute types within the multi-transaction sliding window. This involves determining the standard deviation of the latest attribute value for each transaction attribute type based on its corresponding sliding window. The detailed determination process can be found above. Figure 5 The feasible implementation process of step S202 in the corresponding embodiment will not be described in detail here.

[0186] Step S308: Determine whether all transactions have been completed. If yes, proceed to step S309; ​​otherwise, return to step S303.

[0187] Step S309: The transaction sequencer sorts all transactions according to the priority of the attribute distance standard deviation from smallest to largest.

[0188] For details, please refer to the above sorting process. Figure 3 The specific description of step S102 in the corresponding embodiment will not be repeated here.

[0189] In step S310, the transaction compressor traverses all transactions and compresses them. If a transaction has a field attribute value that is the same as the attribute value of the previous transaction, it is set as the default placeholder.

[0190] Specifically, transaction compression is essentially incremental encoding compression of transactions; the specific implementation can be found above. Figure 3 The specific descriptions of steps S103-S104 in the corresponding embodiments will not be repeated here.

[0191] In step S311, the block generator packages transactions according to the transaction order and sends the blocks to other blockchain nodes for consensus.

[0192] Specifically, the implementation of step S311 can be found above. Figure 3 The implementation of step S105 in the corresponding embodiment will not be described in detail here.

[0193] The method provided in this application presents an adaptive multi-attribute transaction data dynamic standard deviation sorting and optimized storage mechanism. It calculates the dynamic standard deviation of each attribute in the transaction data and uses this statistical characteristic to reorder the transactions. This sorting mechanism prioritizes transactions with smaller attribute value changes, thereby achieving higher data redundancy elimination efficiency in the subsequent incremental encoding and compression stage. This adaptive sorting method can significantly reduce storage requirements while maintaining data integrity and accessibility. This mechanism is not only applicable to current transaction data but can also be extended to future data patterns, demonstrating strong foresight and adaptability.

[0194] Furthermore, to facilitate understanding of the methods proposed based on the above embodiments and the above-described... Figure 7 The system architecture of the transaction incremental coding block compression scheme based on sliding window and dynamic standard deviation, as shown, implements the block compression process based on transaction incremental coding. Please refer to [link / reference needed]. Figure 9 , Figure 9 This is a schematic diagram of a block compression process based on transaction incremental encoding provided in an embodiment of this application. Figure 9 As shown, the entire block compression process may include the following steps S401-S410:

[0195] Step S401: After the blockchain nodes have sorted the transactions, they begin incremental transaction encoding and compression.

[0196] In step S402, the transaction sequencer starts a coroutine for priority traversal of all transaction attribute types.

[0197] Specifically, a blockchain node can launch a coroutine for each transaction attribute type. This coroutine iterates through the transactions in order, retrieving the transaction attribute values ​​for the corresponding transaction attribute type in each transaction. Optionally, the coroutine can first retrieve the transaction attribute values ​​for the corresponding transaction attribute type from all transactions, add them sequentially to the same set of attribute values ​​to be compressed, and then directly retrieve the corresponding transaction attribute values ​​from the set of attribute values ​​to be compressed to complete the incremental encoding and compression processing of the transaction attribute values ​​for the corresponding transaction attribute type.

[0198] Step S403: Each coroutine sets the current attribute calibration value to the attribute value of the first transaction.

[0199] Specifically, each coroutine will execute steps S404-S408 below, and they do not affect each other. Assuming that the transaction attribute type corresponding to coroutine A is contract name, coroutine A can set the current attribute value to the transaction attribute value corresponding to the contract name included in the first transaction.

[0200] Step S404: Begin checking from the next transaction.

[0201] Step S405: Is the attribute value of the current transaction the same as the current attribute calibration value? If yes, proceed to step S406; otherwise, proceed to step S407.

[0202] Step S406: Set the corresponding field of this attribute of the transaction to a special character, and then proceed to step S408.

[0203] Specifically, special characters are often placeholders that require less storage space, such as *.

[0204] Step S407: Set the current attribute calibration value to the value of the transaction attribute, and then proceed to step S408.

[0205] Step S408: Determine whether the current transaction is the last transaction. If yes, proceed to step S409; otherwise, return to step S404.

[0206] Step S409: Wait for all coroutine incremental encoding compression to complete.

[0207] Step S410: Notify the block generator to encapsulate and sign the block.

[0208] The method provided in this application presents a compression strategy that utilizes sliding window technology to analyze the continuity of transaction attribute values ​​and implements incremental encoding accordingly. By dynamically updating the transaction data within the sliding window, the system can monitor and evaluate the changing trends of transaction attribute values ​​in real time, thereby effectively marking and compressing continuously repeating transaction attribute values ​​during the encoding process. This strategy not only improves the efficiency of data compression but also, due to its dynamic nature, can adapt to changes in transaction patterns, ensuring optimal performance of the compression mechanism under different transaction environments.

[0209] Please see Figure 10 , Figure 10 This is a schematic diagram of a block compression device provided in an embodiment of this application. The block compression device can be a computer program (including program code) running on a computer device; for example, the block compression device is an application software. The block compression device 1 can be used to execute corresponding steps in the block compression method provided in the embodiment of this application. Figure 10 As shown, the block compression device 1 may include: an acquisition module 110, a sorting module 120, a classification module 130, an encoding module 140, and an encapsulation module 150.

[0210] Module 110 is used to obtain M transactions to be packaged; M is a positive integer; each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types; N is a positive integer;

[0211] The sorting module 120 is used to sort the positions of M transactions to be packaged according to the priority of the transaction attribute types corresponding to the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types, so as to obtain M position-sorted transactions.

[0212] The classification module 130 is used to add the transaction attribute values ​​with the same transaction attribute type from the M position-sorted transactions to the same set of attribute values ​​to be compressed according to the position order among the M position-sorted transactions, so as to obtain the set of attribute values ​​to be compressed corresponding to N transaction attribute types respectively.

[0213] Encoding module 140 is used to perform incremental encoding compression processing on N sets of attribute values ​​to be compressed, so as to obtain N incremental encodings of attribute values.

[0214] The encapsulation module 150 is used to encapsulate the incremental encoding of N attribute values ​​into blocks to obtain blocks to be added to the blockchain; the blocks to be added to the blockchain are used to be added to the blockchain when consensus is passed.

[0215] In one possible implementation, the sorting module 120 is used to sort the M transactions to be packaged according to the priority of the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types. When obtaining the M position-sorted transactions, it is specifically used to perform the following operations:

[0216] Iterate through the N transaction attribute types according to their respective priorities to obtain the k-th transaction attribute type; the priority of the transaction attribute type corresponding to the k-th transaction attribute type is lower than the priority of the transaction attribute type corresponding to the (k-1)-th transaction attribute type obtained.

[0217] Based on the M transaction attribute values ​​corresponding to the kth transaction attribute type, the M intermediate position sorted transactions after the (k-1)th position sort are sorted again to obtain the M intermediate position sorted transactions after the kth position sort; when k is 1, the M intermediate position sorted transactions after the (k-1)th position sort are M transactions to be packaged.

[0218] If the M transaction attribute values ​​corresponding to the kth transaction attribute type contain the same transaction attribute value, then continue to obtain the (k+1)th transaction attribute type, and perform the (k+1)th position sorting on the M middle position sorted transactions after the kth position sorting according to the M transaction attribute values ​​corresponding to the (k+1)th transaction attribute type.

[0219] If the M transaction attribute values ​​corresponding to the k-th transaction attribute type do not contain any consecutive and identical transaction attribute values, then stop traversing the N transaction attribute types and determine the M middle position sorted transactions after the k-th position sort as the M position sorted transactions.

[0220] In one possible implementation, the sorting module 120 is used to sort the M intermediate position transactions after the (k-1)th position sorting according to the M transaction attribute values ​​corresponding to the kth transaction attribute type. When obtaining the M intermediate position transactions after the kth position sorting, it is specifically used to perform the following operations:

[0221] Sort the M transaction attribute values ​​corresponding to the kth transaction attribute type to obtain M sorted transaction attribute values;

[0222] Among the M intermediate position sorted transactions after the (k-1)th position sort, those intermediate position sorted transactions that contain the same first transaction attribute value and are in consecutive positions are identified as intermediate position sorted transactions to be adjusted; the first transaction attribute value refers to the transaction attribute value with the (k-1)th transaction attribute type; when k is 1, the intermediate position sorted transactions to be adjusted are M transactions to be packaged.

[0223] Based on the positional relationship of the second transaction attribute value contained in the intermediate position sorting transaction to be adjusted among the M sorted transaction attribute values, the intermediate position sorting transactions to be adjusted among the M intermediate position sorting transactions are subjected to position adjustment processing to obtain the M intermediate position sorting transactions after the kth position sorting; the second transaction attribute value refers to the transaction attribute value with the kth transaction attribute type.

[0224] In one possible implementation, the N sets of attribute values ​​to be compressed include the set K of attribute values ​​to be compressed. n n is a positive integer less than or equal to N; the encoding module 140 is used to perform incremental encoding compression processing on the N sets of attribute values ​​to be compressed, and to obtain the incremental encoding of N attribute values, it is specifically used to perform the following operations:

[0225] The set of attribute values ​​to be compressed, K n The first transaction attribute value is written into the incremental encoding set and the attribute value set to be compressed, K, respectively. n The corresponding transaction attribute labeling field;

[0226] Iterate through the set of attribute values ​​to be compressed, K, in sequence. n Get the value of the i-th transaction attribute; i is a positive integer greater than or equal to 2 and less than or equal to M;

[0227] If the i-th transaction attribute value is different from the transaction attribute value contained in the transaction attribute labeling field, then the i-th transaction attribute value is added sequentially to the incremental encoding set, and the transaction attribute value contained in the transaction attribute labeling field is replaced with the i-th transaction attribute value.

[0228] If the i-th transaction attribute value is the same as the transaction attribute value contained in the transaction attribute labeling field, then the special encoded characters are added sequentially to the incremental encoding set until the set of attribute values ​​to be compressed, K, is determined. n Completed; the set of attribute values ​​K to be compressed has been determined based on the incremental encoding set. n The corresponding attribute value is incrementally encoded.

[0229] In one possible implementation, the N transaction attribute types include transaction attribute type T. j , j is a positive integer less than or equal to N; the sorting module 120 is also used to perform the following operations:

[0230] Get transaction attribute type T j The corresponding transaction attribute type sliding window; the transaction attribute type sliding window contains L items with transaction attribute type T. j Corresponding historical transaction attribute values;

[0231] Based on the transaction attribute type T among the M transactions to be packaged j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j The corresponding latest attribute value is far from the standard deviation;

[0232] When the distance from the latest attribute value to the standard deviation of each of the N transaction attribute types is obtained, the priority of each of the N transaction attribute types is determined based on the distance from the latest attribute value to the standard deviation of each of the N transaction attribute types.

[0233] In one possible implementation, the sorting module 120 is used to sort the M transactions to be packaged according to the transaction attribute type T. j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0234] Among the M transactions to be packaged, those with transaction attribute type T j The transaction attribute values ​​are placed sequentially before the position in the transaction attribute type slider window;

[0235] The transaction attribute type sliding window is forward-sliding to obtain a new sliding window containing L latest transaction attribute values. These L latest transaction attribute values ​​contain M transactions of type T to be packaged. j The transaction attribute value;

[0236] Determine the transaction attribute type T based on the L latest transaction attribute values. j The latest attribute value is far from the standard deviation.

[0237] In one possible implementation, the sorting module 120 is used to determine the transaction attribute type T based on the L latest transaction attribute values. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0238] An attribute value mapping map is generated based on L latest transaction attribute values. The attribute value mapping map contains P mapped attribute values ​​and the occurrence count of each of the P mapped attribute values. An occurrence count refers to the number of latest transaction attribute values ​​that are the same as a mapped attribute value among the L latest transaction attribute values.

[0239] Based on the quantity L and the occurrence counts corresponding to the P mapped attribute values, the transaction attribute type T is calculated. j The latest attribute value is far from the standard deviation.

[0240] In one possible implementation, when the sorting module 120 generates an attribute value mapping map based on the L latest transaction attribute values, it specifically performs the following operations:

[0241] Create an initial attribute value mapping map;

[0242] Iterate through the L latest transaction attribute values ​​and obtain the qth latest transaction attribute value; q is a positive integer less than or equal to L;

[0243] If the initial attribute value mapping map contains a mapping attribute value that is the same as the qth latest transaction attribute value, then the occurrence count of the mapping attribute value that is the same as the qth latest transaction attribute value is accumulated.

[0244] If the initial attribute value mapping map does not contain a mapping attribute value that is the same as the qth latest transaction attribute value, then the qth latest transaction attribute value is taken as the new mapping attribute value, the starting quantity is determined as the occurrence quantity corresponding to the new mapping attribute value, and the new mapping attribute value and the occurrence quantity corresponding to the new mapping attribute value are added to the initial attribute value mapping map.

[0245] The initial attribute value mapping map after traversing the L latest transaction attribute values ​​is determined as the attribute value mapping map.

[0246] In one possible implementation, the sorting module 120 is used to calculate the transaction attribute type T based on the quantity L and the occurrence counts corresponding to the P mapping attribute values. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0247] Iterate through the occurrence counts of each of the P mapped attribute values ​​and obtain the s-th occurrence count; s is a positive integer less than or equal to P.

[0248] The difference between the quantity L and the s-th occurrence quantity is determined as the s-th unit attribute distance. The product of the s-th unit attribute distance and the s-th occurrence quantity is determined as the s-th attribute distance. This process continues until the occurrence quantities corresponding to P mapped attribute values ​​have been traversed. The sum of the P attribute distances is then divided by the square of the quantity L to obtain the transaction attribute type T. j The latest attribute value is far from the standard deviation.

[0249] In one possible implementation, the sorting module 120 is used to sort the M transactions to be packaged according to the transaction attribute type T. j The transaction attribute type T is determined by the sliding window of the transaction attribute value and transaction attribute type. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0250] Get transaction attribute type T j The corresponding historical attribute value's distance from the standard deviation; the historical attribute value's distance from the standard deviation is determined based on the transaction attribute values ​​contained in the transaction attribute type sliding window;

[0251] Among the M transactions to be packaged, those with transaction attribute type T j The transaction attribute values ​​are placed sequentially before the position in the transaction attribute type slider window;

[0252] Perform a forward unit sliding process on the transaction attribute type sliding window after the (t-1)th unit sliding to obtain the transaction attribute type sliding window after the tth unit sliding.

[0253] The transaction attribute value at the end of the transaction attribute type sliding window after the (t-1)th unit slide is determined as the t-th slide-removed transaction attribute value, and the transaction attribute value at the beginning of the transaction attribute type sliding window after the t-th unit slide is determined as the t-th slide-added transaction attribute value; the t-th slide-added transaction attribute value belongs to the M transactions to be packaged that have transaction attribute type T. j The transaction attribute value;

[0254] The distance standard deviation of the (t-1)th updated attribute value is updated based on the t-th sliding addition and t-th sliding removal transaction attribute values ​​to obtain the distance standard deviation of the t-th updated attribute value; when t is 1, the distance standard deviation of the (t-1)th updated attribute value is the distance standard deviation of the historical attribute value.

[0255] When t equals M, the distance from the standard deviation of the Mth updated attribute value is determined as the transaction attribute type T. j The latest attribute value is far from the standard deviation.

[0256] In one possible implementation, the sorting module 120 is used to update the distance standard deviation of the (t-1)th updated attribute value based on the t-th sliding addition transaction attribute value and the t-th sliding removal transaction attribute value. When obtaining the distance standard deviation of the t-th updated attribute value, it is specifically used to perform the following operations:

[0257] Get the number of added attributes with the same transaction attribute value as the t-th swipe in the transaction attribute type sliding window after the (t-1)-th unit swipe, and the number of removed attributes with the same transaction attribute value as the t-th swipe in the transaction attribute type sliding window after the (t-1)-th unit swipe;

[0258] Subtract the difference between the quantity L and the number of added attributes from the difference between the quantity L and the number of removed attributes to obtain the distance of the changed attributes;

[0259] The quotient between the distance to the changed attribute and the square of the quantity L is added to the standard deviation of the distance to the (t-1)th updated attribute value to obtain the standard deviation of the distance to the tth updated attribute value.

[0260] In this embodiment, a blockchain node can obtain M transactions to be packaged, each of which contains N transaction attribute values ​​of different transaction attribute types. Then, based on the priority of each of the N transaction attribute types and the M transaction attribute values ​​corresponding to each of the N transaction attribute types, the M transactions to be packaged are sorted by position to obtain M position-sorted transactions. The transaction attribute values ​​of the same transaction attribute type among the M position-sorted transactions are then added to the same set of attribute values ​​to be compressed according to the positional order among the M position-sorted transactions, resulting in N sets of attribute values ​​to be compressed for each of the N transaction attribute types. Incremental encoding compression is then performed on each of the N sets of attribute values ​​to obtain N incremental attribute codes. Finally, the N incremental attribute codes are encapsulated into blocks to obtain a block to be added to the blockchain. This block is used to be added to the blockchain when consensus is reached. The method provided in this application embodiment can first reorder the transactions to be packaged based on the priority of the transaction attribute type and the transaction attribute value corresponding to the transaction attribute type. This sorting mechanism will make transactions with smaller changes in transaction attribute values ​​processed first in the incremental encoding and compression stage. Therefore, higher data redundancy elimination efficiency can be achieved in the incremental encoding and compression stage, thereby reducing the storage space required for blocks and improving the performance of the blockchain system.

[0261] Please see Figure 11 , Figure 11 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 11 As shown above, Figure 10The block compression device 1 in the corresponding embodiment can be applied to a computer device 1000, which may include a processor 1001, a network interface 1004, and a memory 1005. Furthermore, the computer device 1000 may also include a user interface 1003 and at least one communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen and a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located remotely from the processor 1001. Figure 10 As shown, the memory 1005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

[0262] In such Figure 10 In the computer device 1000 shown, the network interface 1004 provides network communication elements; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call the device control application stored in the memory 1005 to achieve:

[0263] Retrieve M transactions to be packaged; M is a positive integer; each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types; N is a positive integer;

[0264] Based on the priority of the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types, the M transactions to be packaged are sorted by position to obtain M position-sorted transactions.

[0265] Take the transaction attribute values ​​with the same transaction attribute type from the M position-sorted transactions and add them to the same set of attribute values ​​to be compressed according to the position order among the M position-sorted transactions, to obtain the set of attribute values ​​to be compressed for each of the N transaction attribute types.

[0266] Incremental encoding compression is performed on each of the N sets of attribute values ​​to be compressed to obtain N incremental codes for attribute values;

[0267] Incremental encoding of N attribute values ​​is performed on a block encapsulation process to obtain a block to be added to the blockchain; the block to be added to the blockchain is used to be added to the blockchain when consensus is passed.

[0268] It should be understood that the computer device 1000 described in the embodiments of this application can execute the foregoing text. Figure 3 , Figure 5 The description of the block compression method in any corresponding embodiment will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0269] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned block compression device 1. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 , Figure 5 The description of the block compression method in any corresponding embodiment is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0270] The aforementioned computer-readable storage medium can be the block compression device provided in any of the foregoing embodiments or the internal storage unit of the aforementioned computer device, such as the hard disk or memory of the computer device. The computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer device. Furthermore, the computer-readable storage medium may include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0271] Furthermore, it should be noted that this application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figure 3 , Figure 4 The method provided in any of the corresponding embodiments.

[0272] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0273] 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.

[0274] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the foregoing description as a network element. Whether these network elements are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can implement the described network elements using different methods for each specific application, but such implementation should not be considered beyond the scope of this application.

[0275] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A blockchain-based block compression method, characterized in that, The method is executed by a blockchain node, and the method includes: Retrieve M transactions to be packaged; M is a positive integer; each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types; N is a positive integer; Based on the priority of the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types, the M transactions to be packaged are sorted by position to obtain M position-sorted transactions. The transaction attribute values ​​with the same transaction attribute type among the M position-sorted transactions are added to the same set of attribute values ​​to be compressed according to the positional order among the M position-sorted transactions, thus obtaining the set of attribute values ​​to be compressed corresponding to the N transaction attribute types respectively. Incremental encoding compression is performed on each of the N sets of attribute values ​​to be compressed to obtain N incremental codes for attribute values; The incremental encoding of the N attribute values ​​is encapsulated into blocks to obtain blocks to be added to the blockchain; these blocks are used to be added to the blockchain when consensus is reached.

2. The method according to claim 1, characterized in that, The step of sorting the M transactions to be packaged according to the priority of the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types to obtain M position-sorted transactions includes: Based on the priority of the N transaction attribute types, the N transaction attribute types are traversed to obtain the k-th transaction attribute type; the priority of the transaction attribute type corresponding to the k-th transaction attribute type is lower than the priority of the transaction attribute type corresponding to the (k-1)-th transaction attribute type obtained. Based on the M transaction attribute values ​​corresponding to the kth transaction attribute type, the M intermediate position sorted transactions after the (k-1)th position sort are sorted again to obtain the M intermediate position sorted transactions after the kth position sort; when k is 1, the M intermediate position sorted transactions after the (k-1)th position sort are the M transactions to be packaged. If the M transaction attribute values ​​corresponding to the kth transaction attribute type contain the same transaction attribute value, then continue to obtain the (k+1)th transaction attribute type, and perform the (k+1)th position sorting on the M intermediate position sorted transactions after the kth position sorting according to the M transaction attribute values ​​corresponding to the (k+1)th transaction attribute type. If the M transaction attribute values ​​corresponding to the k-th transaction attribute type do not contain any consecutive and identical transaction attribute values, then stop traversing the N transaction attribute types and determine the M intermediate position sorted transactions after the k-th position sort as the M position sorted transactions.

3. The method according to claim 2, characterized in that, The step of performing a k-th position sort on the M intermediate position sorted transactions after the (k-1)-th position sorting based on the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain the M intermediate position sorted transactions after the k-th position sorting includes: The M transaction attribute values ​​corresponding to the kth transaction attribute type are sorted to obtain M sorted transaction attribute values; Among the M intermediate position sorted transactions after the (k-1)th position sort, those intermediate position sorted transactions that contain the same first transaction attribute value and are in consecutive positions are identified as intermediate position sorted transactions to be adjusted; the first transaction attribute value refers to the transaction attribute value with the (k-1)th transaction attribute type; when k is 1, the intermediate position sorted transactions to be adjusted are M transactions to be packaged. Based on the positional relationship of the second transaction attribute value contained in the intermediate position sorting transaction to be adjusted among the M sorted transaction attribute values, the intermediate position sorting transaction to be adjusted among the M intermediate position sorting transactions is subjected to position adjustment processing to obtain the M intermediate position sorting transactions after the kth position sorting; the second transaction attribute value refers to the transaction attribute value with the kth transaction attribute type.

4. The method according to claim 1, characterized in that, The N sets of attribute values ​​to be compressed include the set K of attribute values ​​to be compressed. n n is a positive integer less than or equal to N; The incremental encoding compression process is performed on each of the N sets of attribute values ​​to be compressed to obtain N incremental codes for attribute values, including: The set of attribute values ​​to be compressed K n The first transaction attribute value is written into the incremental encoding set and the attribute value set to be compressed K, respectively. n The corresponding transaction attribute labeling field; Iterate through the set K of attribute values ​​to be compressed in sequence. n Obtain the i-th transaction attribute value; i is a positive integer greater than or equal to 2 and less than or equal to M; If the i-th transaction attribute value is different from the transaction attribute value contained in the transaction attribute labeling field, then the i-th transaction attribute value is added sequentially to the incremental encoding set, and the transaction attribute value contained in the transaction attribute labeling field is replaced with the i-th transaction attribute value. If the i-th transaction attribute value is the same as the transaction attribute value contained in the transaction attribute labeling field, then the special coded characters are added sequentially to the incremental encoding set until it is determined that the set K of attribute values ​​to be compressed has been traversed. n Completed, the set of attribute values ​​to be compressed, K, is determined based on the incremental encoding set. n The corresponding attribute value is incrementally encoded.

5. The method according to claim 1, characterized in that, The N transaction attribute types include transaction attribute type T. j j is a positive integer less than or equal to N; The method further includes: Obtain the transaction attribute type T j The corresponding transaction attribute type sliding window; the transaction attribute type sliding window contains L elements with the transaction attribute type T. j Corresponding historical transaction attribute values; Based on the M transactions to be packaged, those with the transaction attribute type T j The transaction attribute type T is determined by the transaction attribute value and the transaction attribute type sliding window. j The corresponding latest attribute value is far from the standard deviation; When the distance from the latest attribute value to the standard deviation of the N transaction attribute types is obtained, the priority of the transaction attribute types corresponding to the N transaction attribute types is determined according to the distance from the latest attribute value to the standard deviation of the N transaction attribute types.

6. The method according to claim 5, characterized in that, The transaction attribute type T is determined from the M transactions to be packaged. j The transaction attribute type T is determined by the transaction attribute value and the transaction attribute type sliding window. j The corresponding latest attribute value's distance from the standard deviation includes: Among the M transactions to be packaged, those with the transaction attribute type T are... j The transaction attribute values ​​are placed sequentially before the position of the transaction attribute type sliding window; The transaction attribute type sliding window is forward-sliding to obtain a slidable transaction attribute type sliding window; the slidable transaction attribute type sliding window contains L latest transaction attribute values; the L latest transaction attribute values ​​contain the transaction attribute type T from the M transactions to be packaged. j The transaction attribute value; The transaction attribute type T is determined based on the L latest transaction attribute values. j The latest attribute value is far from the standard deviation.

7. The method according to claim 6, characterized in that, The transaction attribute type T is determined based on the L latest transaction attribute values. j The corresponding latest attribute value's distance from the standard deviation includes: An attribute value mapping map is generated based on the L latest transaction attribute values; the attribute value mapping map contains P mapped attribute values ​​and the occurrence counts corresponding to the P mapped attribute values; an occurrence count refers to the number of latest transaction attribute values ​​among the L latest transaction attribute values ​​that are the same as a mapped attribute value. The transaction attribute type T is calculated based on the quantity L and the occurrence counts corresponding to the P mapping attribute values. j The latest attribute value is far from the standard deviation.

8. The method according to claim 7, characterized in that, The step of generating an attribute value mapping map based on the L latest transaction attribute values ​​includes: Create an initial attribute value mapping map; Iterate through the L latest transaction attribute values ​​to obtain the qth latest transaction attribute value; q is a positive integer less than or equal to L; If the initial attribute value mapping map contains a mapping attribute value that is the same as the qth latest transaction attribute value, then the occurrence count of the mapping attribute value that is the same as the qth latest transaction attribute value is accumulated. If the initial attribute value mapping map does not contain a mapping attribute value that is the same as the qth latest transaction attribute value, then the qth latest transaction attribute value is used as a new mapping attribute value, the starting quantity is determined as the occurrence quantity corresponding to the new mapping attribute value, and the new mapping attribute value and the occurrence quantity corresponding to the new mapping attribute value are added to the initial attribute value mapping map. The initial attribute value mapping map obtained after traversing the L latest transaction attribute values ​​is determined as the attribute value mapping map.

9. The method according to claim 8, characterized in that, The transaction attribute type T is calculated based on the quantity L and the occurrence counts corresponding to the P mapping attribute values. j The corresponding latest attribute value's distance from the standard deviation includes: Iterate through the occurrence counts corresponding to the P mapping attribute values ​​to obtain the s-th occurrence count; s is a positive integer less than or equal to P; The difference between the quantity L and the s-th occurrence quantity is determined as the s-th unit attribute distance. The product of the s-th unit attribute distance and the s-th occurrence quantity is determined as the s-th attribute distance. This process continues until the occurrence quantities corresponding to the P mapped attribute values ​​are traversed. The sum of the P attribute distances is divided by the square of the quantity L to obtain the transaction attribute type T. j The latest attribute value is far from the standard deviation.

10. The method according to claim 5, characterized in that, The transaction attribute type T is determined from the M transactions to be packaged. j The transaction attribute type T is determined by the transaction attribute value and the transaction attribute type sliding window. j The corresponding latest attribute value's distance from the standard deviation includes: Obtain the transaction attribute type T j The corresponding historical attribute value distance standard deviation; the historical attribute value distance standard deviation is determined based on the transaction attribute values ​​contained in the transaction attribute type sliding window; Among the M transactions to be packaged, those with the transaction attribute type T are... j The transaction attribute values ​​are placed sequentially before the position of the transaction attribute type sliding window; Perform a forward unit sliding process on the transaction attribute type sliding window after the (t-1)th unit sliding to obtain the transaction attribute type sliding window after the tth unit sliding. The transaction attribute value at the end of the transaction attribute type sliding window after the (t-1)th unit slide is determined as the t-th slide-removed transaction attribute value, and the transaction attribute value at the beginning of the transaction attribute type sliding window after the t-th unit slide is determined as the t-th slide-added transaction attribute value; the t-th slide-added transaction attribute value belongs to the M transactions to be packaged that have the transaction attribute type T. j The transaction attribute value; The distance standard deviation of the (t-1)th updated attribute value is updated based on the t-th sliding add transaction attribute value and the t-th sliding remove transaction attribute value to obtain the distance standard deviation of the t-th updated attribute value; when t is 1, the distance standard deviation of the (t-1)th updated attribute value is the distance standard deviation of the historical attribute value; When t equals M, the distance from the standard deviation of the Mth updated attribute value is determined as the transaction attribute type T. j The latest attribute value is far from the standard deviation.

11. The method according to claim 10, characterized in that, The step of updating the distance standard deviation of the (t-1)th updated attribute value based on the t-th sliding add transaction attribute value and the t-th sliding remove transaction attribute value to obtain the distance standard deviation of the t-th updated attribute value includes: Get the number of added attributes with the same transaction attribute value as the t-th swipe added transaction attribute value in the transaction attribute type sliding window after the (t-1)-th unit swipe, and the number of removed attributes with the same transaction attribute value as the t-th swipe removed transaction attribute value in the transaction attribute type sliding window after the (t-1)-th unit swipe; Subtract the difference between the quantity L and the number of added attributes and the difference between the quantity L and the number of removed attributes to obtain the distance of the changed attributes; The quotient between the distance of the changed attribute and the square of the quantity L is added to the standard deviation of the distance of the (t-1)th updated attribute value to obtain the standard deviation of the distance of the tth updated attribute value.

12. A blockchain-based block compression device, characterized in that, The device is operated by a blockchain node, and the device includes: The acquisition module is used to acquire M transactions to be packaged; M is a positive integer; each transaction to be packaged contains N transaction attribute values ​​of transaction attribute types; N is a positive integer; The sorting module is used to sort the M transactions to be packaged according to the priority of the N transaction attribute types and the M transaction attribute values ​​corresponding to the N transaction attribute types, so as to obtain M position-sorted transactions. The classification module is used to add transaction attribute values ​​with the same transaction attribute type from the M position-sorted transactions to the same set of attribute values ​​to be compressed according to the positional order among the M position-sorted transactions, so as to obtain the set of attribute values ​​to be compressed corresponding to the N transaction attribute types respectively. The encoding module is used to perform incremental encoding compression on N sets of attribute values ​​to be compressed, so as to obtain N incremental encodings of attribute values. The encapsulation module is used to encapsulate the incremental encoding of the N attribute values ​​into blocks to obtain blocks to be added to the blockchain; the blocks to be added to the blockchain are used to be added to the blockchain when consensus is passed.

13. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide data communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-11.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method according to any one of claims 1-11.

15. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they can perform the method described in any one of claims 1-11.

Images