Blockchain-based block compression method and apparatus, device, and readable storage medium

Abstract

Provided are a blockchain-based block compression method and apparatus, a device, and a readable storage medium. The method comprises: acquiring M transaction data packets, each of the transaction data packets comprising transaction attribute values of N transaction attribute types; on the basis of the transaction attribute values and type priorities respectively corresponding to the N transaction attribute types, determining a positional order of the M transaction data packets, so as to obtain a transaction data packet sequence; for the N transaction attribute types, on the basis of the transaction attribute values corresponding to the same transaction attribute types in the transaction data packet sequence, respectively generating attribute value sets according to the positional order, so as to obtain N attribute value sets; respectively performing delta encoding processing on the N attribute value sets to obtain N attribute value delta encodings; and performing block encapsulation processing on the N attribute value delta encodings to obtain a block pending for blockchain uploading.

Description

Block compression methods, devices, equipment, and readable storage media based on blockchain

[0001] This application claims priority to Chinese Patent Application No. 2024109107402, filed on July 8, 2024, entitled "Block Compression Method, Apparatus, Device and Readable Storage Medium Based on Blockchain", the entire contents of which are incorporated herein by reference. Technical Field

[0002] 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

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

[0004] 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

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

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

[0007] Obtain M transaction data packets, each of which contains N transaction attribute values ​​corresponding to N transaction attribute types, where M and N are both positive integers;

[0008] Based on the type priority and transaction attribute value of the above N transaction attribute types, the positional order of the above M transaction data packets is determined to obtain the transaction data packet sequence.

[0009] For the above N transaction attribute types, based on the transaction attribute values ​​of the same transaction attribute type in the above transaction data packet sequence, attribute value sets are generated according to the above positions to obtain N attribute value sets;

[0010] Incremental encoding is performed on the above N attribute value sets respectively to obtain N attribute value incremental codes;

[0011] The incremental encoding of the above N attribute values ​​is encapsulated into blocks to obtain blocks to be added to the blockchain; these blocks to be added to the blockchain are used to be added to the blockchain when consensus is reached.

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

[0013] The acquisition module is used to acquire M transaction data packets. Each of the above transaction data packets contains transaction attribute values ​​corresponding to N transaction attribute types, where M and N are both positive integers.

[0014] The sorting module is used to determine the positional order of the M transaction data packets according to the type priority and transaction attribute value corresponding to the N transaction attribute types, so as to obtain the transaction data packet sequence.

[0015] The classification module is used to generate N attribute value sets by sorting the transaction attribute values ​​of the same transaction attribute type in the transaction data packet sequence according to the above-mentioned position for the above N transaction attribute types.

[0016] The encoding module is used to perform incremental encoding on N attribute value sets respectively to obtain N attribute value incremental codes;

[0017] The encapsulation module is used to encapsulate the incremental encoding of the above 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.

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

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

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

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

[0022] In this embodiment, a blockchain node can acquire M transaction data packets, each containing N transaction attribute values ​​for different transaction attribute types. Then, based on the type priority and M transaction attribute values ​​corresponding to each of the N transaction attribute types, the order of the M transaction data packets is determined, resulting in a transaction data packet sequence. Next, for each of the N transaction attribute types, based on the corresponding transaction attribute values ​​within the transaction data packet sequence, attribute value sets are generated according to the aforementioned order, resulting in N attribute value sets. Incremental encoding is then performed on each of these N attribute value sets to obtain N incremental attribute value codes. Finally, these N incremental attribute value codes are encapsulated into a block to be added to the blockchain. This block is used to add to the blockchain upon consensus approval. The method provided in this embodiment allows for the reordering of transaction data packets based on the type priority and transaction attribute values ​​corresponding to different transaction attribute types. This reordering mechanism prioritizes transaction data packets with smaller changes in transaction attribute values ​​during the incremental encoding stage, thus achieving higher data redundancy elimination efficiency, reducing the storage space required for blocks, and improving the performance of the blockchain system. Attached Figure Description

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

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

[0025] Figure 2 is a schematic diagram of a blockchain-based block compression method provided in an embodiment of this application;

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

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

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

[0029] Figure 6 is a schematic diagram of a sliding window of one type provided in an embodiment of this application;

[0030] Figure 7 is a system architecture of a transaction incremental coding block compression scheme based on sliding window and dynamic standard deviation provided in an embodiment of this application;

[0031] Figure 8a 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;

[0032] Figure 8b is a schematic diagram of a sliding window with multiple transaction attributes provided in an embodiment of this application;

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

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

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

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

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

[0038] 1. Blockchain: In a narrow sense, blockchain is a chain-like data structure with blocks as the basic unit. The digital digests in the blocks are used to verify the transaction history obtained previously, 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.

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

[0040] 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. The transactions within a block are 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.

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

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

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

[0044] 5. State Data: State data is a 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 transaction data packets 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.

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

[0046] 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 transaction data packets are added; 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.

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

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

[0049] 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 handle large amounts of transaction data packets.

[0050] Please refer to Figure 1, which is a schematic diagram of the network structure of a blockchain node system provided in an embodiment of this application. The blockchain network shown in Figure 1 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-on-chain 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.

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

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

[0053] Table 1

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

[0055] 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 the blockchain network shown in Figure 1, blockchain nodes 10a, 10b, 10c, and 10d can be considered as consensus nodes. Consensus nodes in the blockchain network participate in consensus, which means reaching consensus 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.

[0056] 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 sorts transaction data packets to prioritize and compress transactions with smaller changes in transaction attribute values, 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 transaction data packets, where M is a positive integer. Each transaction data packet contains N transaction attribute values ​​of transaction attribute types, where N is a positive integer. Then, according to the type 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 transaction data packets are sorted by position to obtain a transaction data packet sequence. Next, transaction attribute values ​​with the same transaction attribute type in the transaction data packet sequence are added to the same attribute value set according to the positional order between the transaction data packet sequences, resulting in attribute value sets corresponding to each of the N transaction attribute types. Finally, incremental encoding is performed on each of the N attribute value sets to obtain N attribute value incremental codes. Block encapsulation processing is then performed on the N attribute value incremental codes to obtain the block to be added to the blockchain. This block to be added to the blockchain is used when consensus is passed.

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

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

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

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

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

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

[0063] To facilitate understanding of the above block encoding compression process, please also refer to Figure 2, which is a schematic diagram of a blockchain-based block compression method provided in an embodiment of this application. As shown in Figure 2, blockchain node 20 can be any blockchain node in the aforementioned blockchain network; for example, blockchain node 20 can be blockchain node 10a.

[0064] As shown in Figure 2, 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 transaction data packet 21 from the transaction pool. Assume that the obtained transaction data packet 21 contains transaction 0x12 (i.e., transaction ID 0x12), transaction 0x65 (i.e., transaction ID 0x65), transaction 0x17 (i.e., transaction ID 0x17), and transaction 0x91 (i.e., 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 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 data packet would lead to unnecessary space waste.

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

[0066] As shown in Figure 2, 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 transaction data packet 21, it can first sort the transactions in transaction data packet 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 lower type priority, the sorting results of the transaction attribute values ​​corresponding to the higher type priority in the transactions before sorting should be consistent with the sorting results of the transaction attribute values ​​corresponding to the higher type priority 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].

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

[0068] The implementation of the above-mentioned process of sorting the position of the transaction data packets and the incremental encoding process of sorting the position of the transaction data packets can be found in the specific descriptions in the embodiments corresponding to Figures 3 and 5 below.

[0069] As shown in Figure 2, the block compression method provided in this application embodiment can reorder transactions according to the type priority and 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 coding stage, reducing the storage space required for blocks, and thus improving the performance of the blockchain system.

[0070] Further, please refer to Figure 3, which is a flowchart illustrating a blockchain-based block compression method provided in an embodiment of this application. This method can be executed by a blockchain node (e.g., any blockchain node in the blockchain network corresponding to the embodiment in Figure 1 above, 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:

[0071] Step S101: Obtain M transaction data packets. Each of the above transaction data packets contains transaction attribute values ​​corresponding to N transaction attribute types, where M and N are both positive integers.

[0072] Specifically, a transaction data packet refers to a pending transaction that has not yet been packaged into a block. These packets 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 is the M transaction data packets 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.

[0073] Specifically, to facilitate understanding of the transaction structure of the transaction data packet, please refer to Table 2 below. Table 2 provides a feasible example of a transaction structure:

[0074] Table 2

[0075] As shown in Table 2 above, a transaction data packet can contain transaction attribute values ​​for 10 transaction attribute types. However, the same transaction attribute type may contain identical transaction attribute values ​​in different transaction data packets. For example, in the three transaction data packets 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 may appear repeatedly in the acquired M transaction data packets. Traditional block storage schemes often repeatedly store this identical data, leading to unnecessary space waste.

[0076] Step S102: Based on the type priority and transaction attribute value corresponding to the above N transaction attribute types, determine the position order of the above M transaction data packets to obtain the transaction data packet sequence.

[0077] Specifically, in order to effectively compress transaction attribute values ​​that appear repeatedly in M ​​transaction data packets, blockchain nodes can sort the M transaction data packets by position. Without affecting the integrity and accessibility of the transaction data packets, 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 coding stage.

[0078] Specifically, type priority is used to characterize the probability of the transaction attribute value corresponding to a transaction attribute type changing across M transaction data packets. Type priority can be set based on manual experience, meaning it can be pre-set, or it can be set based on the changes in the transaction attribute values ​​corresponding to various transaction attribute types within a period of time (e.g., calculating the dynamic variance or dynamic standard deviation of the transaction attribute values ​​and using the magnitude of the dynamic variance or dynamic standard deviation to reflect the changes). This application does not impose any restrictions here. It can be understood that the higher the type priority (the earlier it appears), the less likely the transaction attribute value corresponding to that type will change across the M transaction data packets. Therefore, when sorting the M transaction data packets, blockchain nodes should prioritize the transaction attribute type with the highest type priority, that is, group transaction data packets containing the same transaction attribute value corresponding to the highest type priority type together as much as possible, and then consider the transaction attribute type with the second highest type priority.

[0079] In one embodiment, the type priority corresponding to each of the N transaction attribute types can be determined based on the probability of change of the transaction attribute values ​​under the N transaction attribute types. That is, the lower the probability of change of the transaction attribute value under a certain transaction attribute type, the higher the type priority of that transaction attribute type; the higher the probability of change of the transaction attribute value under a certain transaction attribute type, the lower the type priority of that transaction attribute type. The probability of change of the transaction attribute value under each transaction attribute type reflects the likelihood of the transaction attribute value corresponding to the transaction attribute type changing in the M transaction data packets. The probability of change of the transaction attribute value under each transaction attribute type can be determined based on at least one of the dynamic variance or dynamic standard deviation of the transaction attribute values ​​corresponding to each transaction attribute type in transactions generated within a certain period. Here, a period can refer to a historical period, or it can refer to a current period, such as the probability of change of the transaction attribute value being determined based on the transaction attribute values ​​in the M transaction data packets.

[0080] Specifically, a feasible implementation process for determining the positional order of the M transaction data packets and obtaining the transaction data packet sequence based on the type priorities corresponding to the N transaction attribute types and the transaction attribute values ​​can be as follows: Iterate through the N transaction attribute types according to their respective type priorities to obtain the k-th transaction attribute type; the type priority of the k-th transaction attribute type is lower than the type priority of the (k-1)-th transaction attribute type; perform a k-th positional sort on the M candidate transaction data packets after the (k-1)-th positional sort according to the M transaction attribute values ​​corresponding to the k-th transaction attribute type, to obtain the M data packets after the k-th positional sort. Candidate transaction data packets; when k is 1, the M candidate transaction data packets after the (k-1)th position sorting are the M transaction data packets; 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 candidate transaction data packets 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 kth transaction attribute type do not contain consecutive and identical transaction attribute values, then stop traversing the N transaction attribute types, and determine the M candidate transaction data packets after the kth position sorting as the transaction data packet sequence. By sorting the transaction data packets in descending order of type priority, it is beneficial to arrange the transaction data packets with the most identical transaction data in consecutive adjacent positions, thereby facilitating incremental encoding processing, reducing data redundancy, and improving blockchain performance. One feasible implementation of the above-mentioned process of sorting the M candidate transaction data packets after the (k-1)th position sorting according to the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain the M candidate transaction data packets 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 candidate transaction data packets containing the same first transaction attribute value and whose positions are consecutive among the M candidate transaction data packets after the (k-1)th position sorting as candidate transaction data packets 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 candidate transaction data packets to be adjusted are M transaction data packets; and adjusting the positions of the candidate transaction data packets to be adjusted among the M candidate transaction data packets according to the positional relationship of the second transaction attribute value contained in the candidate transaction data packets to be adjusted among the M sorted transaction attribute values ​​to obtain the M candidate transaction data packets after the k-th position sorting; the second transaction attribute value refers to the transaction attribute value with the k-th transaction attribute type. This helps to arrange the same transaction attribute values ​​under each transaction attribute type in consecutive adjacent positions as much as possible, which is conducive to incremental encoding processing, reduces data redundancy, and improves blockchain performance.

[0081] It should be noted that the above-mentioned sorting of the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain M sorted transaction attribute values ​​includes: counting the number of identical transaction attribute values ​​among the M transaction attribute values ​​corresponding to the k-th transaction attribute type; arranging identical transaction attribute values ​​in consecutive adjacent positions according to the order of the number of identical transaction attribute values ​​from largest to smallest, and sorting different transaction attribute values ​​lexicographically to obtain M sorted transaction attribute values. This is beneficial for using special encoding symbols to replace identical transaction attribute values, avoiding the need to repeatedly store the entire transaction attribute value, avoiding unnecessary space waste, reducing data redundancy, and improving the performance of the blockchain system.

[0082] To facilitate understanding of the above process of sorting the positions of M transaction data packets, please refer to Figure 4, which is a schematic diagram of transaction position sorting provided in an embodiment of this application. As shown in Figure 4, assuming that a blockchain node (not shown in the figure, but can be any blockchain node in the blockchain network shown in Figure 1, such as blockchain node 10b) has four transaction data packets that need to be sorted, namely transaction data packet 41, transaction data packet 42, transaction data packet 43, and transaction data packet 44. Each transaction data packet contains transaction attribute values ​​of four transaction attribute types. The four transaction attribute types can be transaction ID, chain ID, contract method, and contract name. The type priority corresponding to transaction ID is 4, the type priority corresponding to chain ID is 1, the type priority corresponding to contract method is 3, and the type priority corresponding to contract name is 2. That is, the type priority corresponding to chain ID > the type priority corresponding to contract name > the type priority corresponding to contract method > the type priority corresponding to transaction ID. Therefore, when the blockchain node traverses the four transaction attribute types according to their respective type priorities, the first transaction attribute type obtained should be chain ID.

[0083] As shown in Figure 4, the blockchain node first sorts the four transaction data packets according to the four transaction attribute values ​​corresponding to the chain ID, resulting in four candidate transaction data packets 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 transaction data packets according to the positional relationship of the four sorted chain ID transaction attribute values ​​to obtain four candidate transaction data packets 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., the smaller character comes first, and the larger character comes last; if the comparison continues until one object is reached, the shorter string or object comes first; if two objects are identical, their lexicographical order is the same. As shown in Figure 4, 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 candidate transaction data packets after the first position sorting are transaction data packet 41, transaction data packet 42, transaction data packet 43, and transaction data packet 44 in order.

[0084] As shown in Figure 4, when a blockchain node traverses the four transaction attribute types according to their respective type priorities, the second transaction attribute type obtained is the contract name. The blockchain node then performs a second sorting of the four candidate transaction data packets after the first sorting based on the four transaction attribute values ​​corresponding to the contract name, resulting in four candidate transaction data packets 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 data packet 41, c1 contained in transaction data packet 42, c1 contained in transaction data packet 44, and c2 contained in transaction data packet 43. Then, since the transaction attribute value corresponding to the chain ID contained in the four candidate transaction data packets after the first position sorting is chain1, the four candidate transaction data packets after the first position sorting are all candidate transaction data packets to be adjusted. At this time, the blockchain node will adjust the position of the candidate transaction data packets to be adjusted according to the position relationship of the transaction attribute value corresponding to the contract name contained in the intermediate sorted transaction to be adjusted among the four sorted contract name transaction attribute values, to obtain the four candidate transaction data packets after the second position sorting, which are in the following order: transaction data packet 41, transaction data packet 42, transaction data packet 44, and transaction data packet 43.

[0085] As shown in Figure 4, when the blockchain node traverses the four transaction attribute types according to their respective type priorities, the third transaction attribute type obtained is the contract method. The blockchain node then performs a third sorting of the four candidate transaction data packets after the second sorting based on the four transaction attribute values ​​corresponding to the contract method, resulting in four candidate transaction data packets after the third sorting. The specific process of the third position sorting can be as follows: First, sort the four transaction attribute values ​​corresponding to the contract method to obtain four sorted contract method transaction attribute values, in the following order: the set contained in transaction data packet 41, the set contained in transaction data packet 44, the set contained in transaction data packet 43, and the get contained in transaction data packet 42; then, because only transaction data packets 41, 42, and 44 contain the same transaction attribute value corresponding to the contract name, and are in consecutive positions, among the four candidate transaction data packets after the second position sorting, the blockchain node will only determine transaction data packets 41, 42, and 44 as candidate transaction data packets to be adjusted in the third position sorting. The blockchain node adjusts the positions of the candidate transaction data packets to be adjusted after the third position sorting based on the positional relationship of the transaction attribute values ​​corresponding to the contract methods contained in the intermediate sorted transactions 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 data packet 41 is before the set contained in transaction data packet 44, and the set contained in transaction data packet 44 is before the get contained in transaction data packet 42, after the position adjustment, transaction data packet 41 should be before transaction data packet 44, and transaction data packet 44 should be before transaction data packet 42. Therefore, the four candidate transaction data packets after the third position sorting are, in order: transaction data packet 41, transaction data packet 44, transaction data packet 42, and transaction data packet 43.

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

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

[0088] Optionally, a feasible implementation of the above-mentioned method of sorting the M candidate transaction data packets after the (k-1)th position sorting according to the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain the M candidate transaction data packets after the k-th position sorting can be as follows: Among the M candidate transaction data packets after the (k-1)th position sorting, candidate transaction data packets containing the same first transaction attribute value and whose positions are consecutive are identified as candidate transaction data packets 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 candidate transaction data packets to be adjusted are M transaction data packets; the second transaction attribute values ​​contained in the candidate transaction data packets to be adjusted are sorted according to their attribute values ​​to obtain sorted second transaction attribute values; the positions of the candidate transaction data packets to be adjusted in the M candidate transaction data packets are adjusted according to the positional relationship of the attribute values ​​of the sorted second transaction attribute values ​​to obtain the M candidate transaction data packets after the k-th position sorting; the second transaction attribute value refers to the transaction attribute value with the k-th transaction attribute type. For example, in the blockchain node shown in Figure 4 above, when the four candidate transaction data packets after the third position sort are sorted a fourth time according to the four transaction attribute values ​​corresponding to the contract method, the specific process of the fourth position sort can be as follows: The blockchain node first determines the candidate transaction data packets to be adjusted. Because among the four candidate transaction data packets after the third position sort, only transaction data packets 41 and 44 contain the same transaction attribute value corresponding to the contract name and are in consecutive positions, the blockchain node will only determine transaction data packets 41 and 44 as the four candidate transaction data packets after the third position sort. The candidate transaction data packets to be adjusted are sorted in the fourth position. Then, the blockchain node sorts the transaction attribute values ​​corresponding to the transaction IDs contained in transaction data packets 41 and 44, resulting in sorted transaction ID transaction attribute values ​​as follows: 0x12 contained in transaction data packet 44 and 0x91 contained in transaction data packet 41. Based on the positional relationship between the sorted transaction ID transaction attribute values, the blockchain node adjusts transaction data packet 44 to a position before transaction data packet 41. Therefore, the four candidate transaction data packets after the fourth position sort are obtained in the following order: transaction data packet 44, transaction data packet 41, transaction data packet 42, and transaction data packet 43.

[0089] Step S103: For the above N transaction attribute types, based on the transaction attribute values ​​of the same transaction attribute type in the above transaction data packet sequence, generate attribute value sets according to the above positions to obtain N attribute value sets.

[0090] Specifically, taking the four-position sorted transactions shown in Figure 4 above as an example, the attribute value set corresponding to the transaction ID is {0x12, 0x91, 0x65, 0x17}, the attribute value set corresponding to the chain ID is {chain1, chain1, chain1, chain1}, the attribute value set corresponding to the contract method is {set, set, get, set}, and the attribute value set corresponding to the contract name is {c1, c1, c1, c2}.

[0091] Step S104: Perform incremental encoding on the N attribute value sets respectively to obtain the N attribute value incremental codes.

[0092] 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 originate 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.

[0093] By intelligently sorting and incrementally encoding transaction data packets, this application reduces the demand for storage resources, thereby lowering storage costs. Simultaneously, the reduced size of the compressed transaction data packets improves data transmission efficiency, reduces network load, and facilitates data synchronization and propagation within the blockchain system. Furthermore, smaller data volumes mean shorter response times for data queries and processing, thus enhancing the overall performance of the blockchain system.

[0094] Specifically, assume there are N attribute value sets including attribute value set K. n Let n be a positive integer less than or equal to N. A feasible implementation process for incremental encoding of N attribute value sets can be obtained by performing incremental encoding on each of the N attribute value sets. This process can be: [The text then abruptly shifts to a different topic:] ... n The first transaction attribute value is written into the incremental encoding set and the attribute value set K, respectively. n The corresponding transaction attribute labeling field; sequentially traversing the attribute value set K 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 traversed attribute values ​​K is determined. nCompleted; attribute value set K is determined based on the incremental encoding set. n The corresponding attribute value is incrementally encoded. For example, the attribute value set K. n Let K3 = {set, set, get, set} be the set of attribute values ​​corresponding to the contract method described in step S103 above. 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. Then, the blockchain node iterates through the set of attribute values ​​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 = {set, *}. The field `word` is set. Then, the blockchain node retrieves the third transaction attribute value (get). Because this third transaction attribute value is different from the transaction attribute values ​​contained in the transaction attribute identification field `word`, the blockchain node writes the third transaction attribute value into both the incremental encoding set `Z` and the transaction attribute identification field `word`. At this point, 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 attribute value set `K3` is traversed, resulting in the incremental encoding set `Z` = {set, *, get, set}. Therefore, the incremental encoding of the attribute value corresponding to the attribute value set `K3` is {set, *, get, set}. By using special encoded characters to represent the same transaction attribute value appearing in consecutive positions without first encountering it, it is not necessary to store the complete transaction attribute value. This helps reduce the redundancy of the blockchain and improves the performance of the blockchain system.

[0095] Step S105: Perform block encapsulation processing on the incremental encoding of the above N attribute values ​​to obtain the 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.

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

[0097] The method provided in this application introduces an incremental encoding mechanism. For transaction attribute values ​​corresponding to consecutively occurring transaction attribute types, only special encoding symbols are needed to represent them, eliminating the need to repeatedly store the entire transaction attribute value and avoiding unnecessary space waste. Furthermore, this application can reorder transaction data packets based on the type priority and transaction attribute value corresponding to each transaction attribute type. This sorting mechanism prioritizes transaction data packets with less change in transaction attribute values ​​during the incremental encoding stage, thus achieving higher data redundancy elimination efficiency, reducing the storage space required for blocks, and improving the performance of the blockchain system.

[0098] Further, please refer to Figure 5, which is a flowchart illustrating a blockchain-based priority determination method provided in an embodiment of this application. This method can be executed by a blockchain node (e.g., any blockchain node in the blockchain network corresponding to the embodiment shown in Figure 1, such as blockchain node 10a). This method can be used to determine the type priority corresponding to N transaction attribute types in the embodiment corresponding to Figure 3. The following description will take the execution of this method by a blockchain node as an example, wherein the blockchain-based priority determination method can at least include the following steps S201-S203:

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

[0100] Specifically, transaction attribute type T j The N transaction attribute types described in the embodiment corresponding to Figure 3 above, where j is a positive integer less than or equal to N. Transaction attribute type T j The corresponding type sliding window is used to continuously detect and analyze the transaction attribute type T contained in the most recently added transactions. j The corresponding transaction attribute value; this type of sliding window 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 of this type, while the old exchange contains transaction attribute type T. j The corresponding transaction attribute value is then output from the other end.

[0101] Step S202, based on the transaction attribute type T in the M transaction data packets. j The transaction attribute value and the type sliding window determine the transaction attribute type T.j The latest attribute value is far from the standard deviation.

[0102] Specifically, the M transaction data packets can be the M transaction data packets described in the embodiment corresponding to Figure 3 above. The latest attribute value distance from the standard deviation refers to the distance based on the transaction attribute type T among the M transaction data packets. j The transaction attribute type T is included in the transaction attribute value and 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.

[0103] Specifically, based on the transaction attribute type T in the M transaction data packets j The transaction attribute value and type sliding window determine the transaction attribute type T. j A feasible implementation process for the latest attribute value's distance from the standard deviation can be: Select the data packets containing transaction attribute type T from the M transaction data packets... j The transaction attribute values ​​are placed sequentially before the position of the type sliding window; the type sliding window is then slid forward to obtain the slid-out type sliding window; the slid-out type sliding window contains L of the latest transaction attribute values; the L latest transaction attribute values ​​contain M transaction data packets with 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.

[0104] To facilitate understanding of the sliding process of the type sliding window, please refer to Figure 6, which is a schematic diagram of the sliding of a type sliding window provided in an embodiment of this application. As shown in Figure 6, assume the transaction attribute type T... jLet c be the contract name, and its corresponding type sliding window is the contract name sliding window. After a blockchain node obtains the contract names (c2, c1, c2, c2 in sequence) contained in four transaction data packets, it 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 slid contract name sliding window. As shown in Figure 6, the slid contract name sliding window will contain the contract names contained in the four transaction data packets, while the four historical contract names that were originally at the end of the contract name sliding window will be removed. Therefore, the slid contract name sliding window will contain eight latest contract names, namely c3, c4, c1, c2, c2, c1, c2, c2.

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

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

[0107] The transaction attribute type T is calculated based on the quantity L and the occurrence counts corresponding to the P mapping attribute values. j A 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):

[0108] Where Dis represents the distance of the latest attribute value from the standard deviation, and P represents the distance from the standard deviation. sThis 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.

[0109] It is understandable that the longer the type sliding window is (i.e., the more transaction attribute values ​​it can contain), the more transaction attribute types T can be included in the M transaction data packets. 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 more computational resources are needed. 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 ​​of newly added transactions in the type sliding window and the transaction attribute values ​​of transactions that need to exit the type sliding window, thus obtaining the latest distance between the attribute value and the standard deviation.

[0110] Therefore, the above is based on the fact that the M transaction data packets have a transaction attribute type T. j The transaction attribute value and type sliding window determine the transaction attribute type T. 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 type sliding window; among M transaction data packets, those with transaction attribute type T... j The transaction attribute values ​​are sequentially placed before the position of the type sliding window; the type sliding window after the (t-1)th unit slide is processed with the t-th forward unit slide to obtain the type sliding window after the t-th unit slide; the transaction attribute value at the end of the 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 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 transaction data packets with 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. jThe 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 ​​contained in the 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.

[0111] One feasible implementation process for 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 is as follows: Obtain the number of added attributes with the same transaction attribute value as the t-th sliding add transaction attribute value in the 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 remove transaction attribute value in the 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):

[0112] 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 P refers to the number of attributes added. t-1 The value is the number of attributes to remove, and L is the window length of the type sliding window, which is the number of transaction attribute values ​​it can contain.

[0113] Step S203: When the distance between the latest attribute value and the standard deviation of the N transaction attribute types is obtained, the type priority of the N transaction attribute types is determined according to the distance between the latest attribute value and the standard deviation of the N transaction attribute types.

[0114] 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 jThe corresponding type priority should be higher. For example, when the distance from the standard deviation of the latest attribute value for transaction attribute type T1 is less than the distance from the standard deviation of the latest attribute value for transaction attribute type T3, which is less than the distance from the standard deviation of the latest attribute value for transaction attribute type T2, the blockchain node can determine that the type priority of transaction attribute type T1 is 1, the type priority of transaction attribute type T3 is 2, and the type priority of transaction attribute type T2 is 3. That is, the type priority of transaction attribute type T1 > the type priority of transaction attribute type T3 > the type priority of transaction attribute type T2. Determining the type priority based on the distance from the standard deviation of the latest attribute value is beneficial for increasing the type priority of transaction attribute types with low variability and decreasing the type priority of transaction attribute types with high variability, which is beneficial for enabling incremental encoding processing of transaction data packets.

[0115] The method provided in this application calculates the dynamic standard deviation of each transaction attribute type in the transaction data (i.e., the distance to the standard deviation of the latest attribute value is calculated each time a block is generated). This statistical characteristic is used to redetermine the type priority corresponding to the transaction attribute type. This allows for priority processing of transactions with smaller changes in transaction attribute values ​​during subsequent position sorting of transaction data packets, thereby achieving higher data redundancy elimination efficiency in the subsequent incremental encoding 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, adapting to changes in transaction patterns and ensuring optimal performance of the compression mechanism under different transaction environments. Based on the sliding window technology, which calculates and updates the distance to the standard deviation of the attribute values ​​of the data to be packaged in real time, this dynamic data processing method enables the blockchain system to adaptively adjust its data processing strategy, prioritizing and sorting transaction attribute values ​​with smaller changes, thereby achieving more efficient compression in the incremental encoding stage. This adaptability allows this application to cope with different transaction patterns and data changes, maintaining compression efficiency while also improving the blockchain system's adaptability to future data patterns.

[0116] Furthermore, the methods described in the embodiments corresponding to Figures 3 and 5 above can be implemented using different system architectures based on actual conditions. For example, please refer to Figure 7, which shows a system architecture for a transaction incremental coding block compression scheme based on a sliding window and dynamic standard deviation provided in this application embodiment. As shown in Figure 7, 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 the blockchain node and the interaction between the various modules are described in detail below. A detailed introduction follows:

[0117] As shown in Figure 7, the network module is responsible for handling all network communication between nodes and other nodes, including data sending, receiving, and forwarding. 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.

[0118] As shown in Figure 7, the primary responsibility of the verification module is to ensure the legality 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 legality and trustworthiness. Permission verification checks whether the entity initiating the transaction data packet 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.

[0119] As shown in Figure 7, the transaction pool module is a temporary storage area used to store 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.

[0120] As shown in Figure 7, the scheduling module coordinates the various activities of blockchain nodes, including the reception and processing of transaction data packets and the generation of blocks. 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.

[0121] The block generator shown in Figure 7 comprises 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 transaction data packets within the 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.

[0122] As shown in Figure 7, the consensus module 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.

[0123] As shown in Figure 7, the storage module 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.

[0124] It is understandable that each module shown in Figure 7 can be deployed in a blockchain node, and the functions provided by each module can also be implemented by the blockchain node.

[0125] By having all 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, 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 based on the latest sliding window information, determines the priority of the transaction attribute type based on 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 data packet of the already sorted transactions, thereby compressing redundant and continuous fields). Further, to facilitate understanding of the methods proposed in the above embodiments and the transaction sorting process based on sliding window and dynamic standard deviation implemented in the transaction incremental coding block compression scheme system architecture shown in Figure 7, please also refer to Figure 8a, which is a schematic diagram of a transaction sorting process based on sliding window and dynamic standard deviation provided in this application embodiment. As shown in Figure 8a, the entire transaction sorting process may include the following steps S301-S311:

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

[0127] Specifically, the number of these transaction data packets can be M, where M is a positive integer. Therefore, these transaction data packets are actually the M transaction data packets described in the embodiment corresponding to Figure 3 above.

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

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

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

[0131] Specifically, a transaction data packet 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 the transaction data packet actually refers to the transaction attribute values ​​of each transaction attribute type contained in the transaction data packet.

[0132] Specifically, a multi-transaction attribute sliding window can contain type sliding windows corresponding to various transaction attribute types. Placing the information of each field in the aforementioned transaction data packet into the multi-transaction attribute sliding window essentially means adding the transaction attribute values ​​corresponding to the same transaction attribute type to the type sliding window corresponding to that transaction attribute type. For example, as shown in Figure 8b, transaction attribute types include transaction ID, timestamp, chain ID, and contract name. Each transaction attribute type corresponds to one type sliding window. The corresponding transaction attribute values ​​in each new transaction data packet are added to the corresponding type sliding window, and old transaction data packets in the type sliding window are deleted. A new transaction data packet can refer to a transaction data packet to be packaged, and an old transaction data packet can refer to a packaged transaction data packet.

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

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

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

[0136] Specifically, updating the attribute map value corresponding to the transaction attribute type means determining the attribute value mapping map corresponding to the transaction attribute type. For a detailed implementation, please refer to the specific description of step S202 in the embodiment corresponding to Figure 5 above, which will not be repeated here.

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

[0138] Specifically, the transaction sequencer updates the standard deviation of the attribute distance for all transaction attribute types within the multi-transaction sliding window. This is essentially determining the latest attribute value distance standard deviation for each transaction attribute type based on the type sliding window corresponding to that transaction attribute type. The specific determination process can be found in the feasible implementation process of step S202 in the embodiment corresponding to Figure 5 above, and will not be elaborated here.

[0139] Step S308: Determine whether all transaction data packets have been executed. If yes, proceed to step S309; ​​otherwise, return to step S303.

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

[0141] Specifically, the sorting process can be found in the detailed description of step S102 in the embodiment corresponding to Figure 3 above, which will not be repeated here.

[0142] In step S310, the transaction compressor traverses all transaction data packets for compression. If a field attribute value of a transaction data packet is found to be the same as the attribute value of the previous transaction, it is set as the default placeholder.

[0143] Specifically, compressing the transaction data packet is essentially performing incremental encoding on the transaction data packet. For a detailed description of steps S103-S104 in the embodiment corresponding to Figure 3 above, it will not be repeated here.

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

[0145] Specifically, the implementation of step S311 can be found in the implementation of step S105 in the embodiment corresponding to Figure 3 above, and will not be repeated here.

[0146] 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 packet 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 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 packets but can also be extended to future data patterns, demonstrating strong foresight and adaptability.

[0147] Furthermore, to facilitate understanding of the methods proposed in the above embodiments and the system architecture of the transaction incremental coding block compression scheme based on sliding window and dynamic standard deviation as shown in Figure 7, please also refer to Figure 9. Figure 9 is a schematic diagram of a transaction incremental coding-based block compression process provided by an embodiment of this application. As shown in Figure 9, the entire block compression process may include the following steps S401-S410:

[0148] Step S401: After the blockchain nodes sort the transaction data packets, they begin incremental transaction encoding.

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

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

[0151] Step S403: Each coroutine sets the current attribute flag value to the attribute value of the first transaction data packet.

[0152] 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 flag value to the transaction attribute value corresponding to the contract name contained in the first transaction data packet.

[0153] Step S404: Begin checking from the next transaction data packet.

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

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

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

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

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

[0159] Step S409: Wait for all coroutine incremental coding to complete.

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

[0161] 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 packets 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.

[0162] Please refer to Figure 10, which 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 the corresponding steps in the block compression method provided in the embodiment of this application. As shown in Figure 10, the block compression device 1 may include: an acquisition module 110, a sorting module 120, a classification module 130, an encoding module 140, and a packaging module 150.

[0163] The acquisition module 110 is used to acquire M transaction data packets, each of which contains N transaction attribute values ​​corresponding to transaction attribute types, where M and N are both positive integers.

[0164] Sorting module 120 is used to determine the positional order of the above M transaction data packets according to the type priority and the above transaction attribute value corresponding to the above N transaction attribute types, so as to obtain the transaction data packet sequence;

[0165] The classification module 130 is used to generate N attribute value sets by sorting the transaction attribute values ​​of the same transaction attribute type in the transaction data packet sequence according to the above position for the above N transaction attribute types.

[0166] Encoding module 140 is used to perform incremental encoding processing on N sets of attribute values ​​respectively to obtain N attribute value incremental codes;

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

[0168] In one possible implementation, the sorting module 120 is used to determine the positional order of the M transaction data packets based on the type priority and transaction attribute value corresponding to the N transaction attribute types, and to obtain the transaction data packet sequence, specifically by performing the following operations:

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

[0170] Based on the M transaction attribute values ​​corresponding to the kth transaction attribute type, the M candidate transaction data packets after the (k-1)th position sorting are sorted again to obtain the M candidate transaction data packets after the kth position sorting; when k is 1, the M candidate transaction data packets after the (k-1)th position sorting are the M transaction data packets.

[0171] 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 candidate transaction data packets after the kth position sorting according to the M transaction attribute values ​​corresponding to the (k+1)th transaction attribute type.

[0172] 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 candidate transaction data packets after the k-th position sorting as the transaction data packet sequence.

[0173] In one possible implementation, the sorting module 120 is used to perform the k-th position sorting on the M candidate transaction data packets after the (k-1)-th position sorting according to the M transaction attribute values ​​corresponding to the k-th transaction attribute type. When obtaining the M candidate transaction data packets after the k-th position sorting, it is specifically used to perform the following operations:

[0174] Sort the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain M sorted transaction attribute values;

[0175] Among the M candidate transaction data packets after the (k-1)th position sorting, those containing the same first transaction attribute value and with consecutive positions are identified as candidate transaction data packets 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, there are M candidate transaction data packets to be adjusted.

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

[0177] In one possible implementation, the N attribute value sets include the attribute value set K. n n is a positive integer less than or equal to N; the encoding module 140 is used to perform incremental encoding processing on the N attribute value sets respectively. When obtaining the incremental encoding of N attribute values, it is specifically used to perform the following operations:

[0178] Set the attribute values ​​K n The first transaction attribute value is written into the incremental encoding set and the attribute value set K, respectively. n The corresponding transaction attribute labeling field;

[0179] Sequential traversal of the attribute value set K 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;

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

[0181] 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 traversed attribute values ​​K is determined. n Completed; attribute value set K is determined based on the incremental encoding set. n The corresponding attribute value is incrementally encoded.

[0182] 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:

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

[0184] Based on the transaction attribute type T in M ​​transaction data packets j The transaction attribute value and type sliding window determine the transaction attribute type T. j The corresponding latest attribute value is far from the standard deviation;

[0185] When the distance from the latest attribute value to the standard deviation of each of the N transaction attribute types is obtained, the type 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.

[0186] In one possible implementation, the sorting module 120 is used to sort M transaction data packets based on the transaction attribute type T. j The transaction attribute value and type sliding window determine the transaction attribute type T. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

[0187] Among the M transaction data packets, those with transaction attribute type T j The transaction attribute values ​​are placed in order before the position in the type slider window;

[0188] Perform a forward sliding process on the type sliding window to obtain the slid-out type sliding window; the slid-out type sliding window contains L latest transaction attribute values; the L latest transaction attribute values ​​contain M transaction data packets with transaction attribute type T. j Transaction attribute values;

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

[0190] 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:

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

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

[0193] 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:

[0194] Create an initial attribute value mapping map;

[0195] 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;

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

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

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

[0199] 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:

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

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

[0202] In one possible implementation, the sorting module 120 is used to sort M transaction data packets based on the transaction attribute type T. j The transaction attribute value and type sliding window determine the transaction attribute type T. j When the latest attribute value is far from the standard deviation, it is used to perform the following operations:

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

[0204] Among the M transaction data packets, those with transaction attribute type T j The transaction attribute values ​​are placed in order before the position in the type slider window;

[0205] Perform a forward unit slide on the type sliding window after the (t-1)th unit slide to obtain the type sliding window after the tth unit slide.

[0206] The transaction attribute value at the end of the 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 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 transaction data packets with transaction attribute type T. j Transaction attribute values;

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

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

[0209] In one possible implementation, the sorting module 120 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 transaction attribute value and the t-th sliding removal transaction attribute value. When obtaining the distance to the standard deviation of the t-th updated attribute value, it is specifically used to perform the following operations:

[0210] Get the number of added attributes with the same transaction attribute value as the t-th swipe in the 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 type sliding window after the (t-1)-th unit swipe;

[0211] 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;

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

[0213] In this embodiment, a blockchain node can obtain M transaction data packets, each containing N transaction attribute values ​​of different transaction attribute types. Then, based on the type priority and the M transaction attribute values ​​corresponding to each of the N transaction attribute types, the M transaction data packets are sorted to obtain a transaction data packet sequence. Transaction attribute values ​​with the same transaction attribute type in the sequence are then added to the same attribute value set according to their position within the sequence, resulting in attribute value sets corresponding to each of the N transaction attribute types. Incremental encoding is then performed on each of these N attribute value sets to obtain N incremental attribute codes. Finally, these N incremental attribute codes are encapsulated into a block to be added to the blockchain. This block is added to the blockchain upon consensus approval. The method provided in this embodiment allows for the reordering of transaction data packets based on the type priority and transaction attribute values. This sorting mechanism prioritizes transaction data packets with less variable transaction attribute values ​​during the incremental encoding stage, thus achieving higher data redundancy elimination efficiency, reducing the storage space required for blocks, and improving the performance of the blockchain system.

[0214] Please refer to Figure 11, which is a schematic diagram of the structure of a computer device provided in an embodiment of this application. As shown in Figure 11, the block compression device 1 in the embodiment corresponding to Figure 10 can be applied to a computer device 1000. The computer device 1000 may include: a processor 1001, a network interface 1004, and a memory 1005. In addition, 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 realize the connection and 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 and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface). The memory 1005 may be a high-speed RAM memory or a non-volatile memory, such as at least one disk storage device. Optionally, the memory 1005 may also be at least one storage device located away from the aforementioned processor 1001. As shown in Figure 10, 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 program.

[0215] In the computer device 1000 shown in Figure 10, 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:

[0216] Obtain M transaction data packets, each of which contains N transaction attribute values ​​corresponding to N transaction attribute types, where M and N are both positive integers;

[0217] Based on the type priority and transaction attribute value of the above N transaction attribute types, the positional order of the above M transaction data packets is determined to obtain the transaction data packet sequence.

[0218] For the above N transaction attribute types, based on the transaction attribute values ​​of the same transaction attribute type in the above transaction data packet sequence, attribute value sets are generated according to the above positions to obtain N attribute value sets;

[0219] Incremental encoding is performed on the above N attribute value sets respectively to obtain N attribute value incremental codes;

[0220] The incremental encoding of the above N attribute values ​​is encapsulated into blocks to obtain blocks to be added to the blockchain; these blocks to be added to the blockchain are used to be added to the blockchain when consensus is reached.

[0221] It should be understood that the computer device 1000 described in the embodiments of this application can execute the block compression method described in any of the embodiments corresponding to Figures 3 and 5 above, and will not be repeated here. In addition, the beneficial effects of using the same method will not be repeated here either.

[0222] Furthermore, it should be noted that this application 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 these instructions, it can execute the block compression method described in any of the embodiments corresponding to Figures 3 and 5 above. Therefore, these descriptions will not be repeated here. Additionally, the beneficial effects of using the same method will not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments of this application, please refer to the description of the method embodiments of this application.

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

[0224] 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 method provided in any of the embodiments corresponding to Figures 3 and 4 above.

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

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

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

[0228] 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: Obtain M transaction data packets, each of which contains N transaction attribute values ​​corresponding to N transaction attribute types, where M and N are both positive integers; Based on the type priority corresponding to the N transaction attribute types and the transaction attribute values, the position order of the M transaction data packets is determined to obtain the transaction data packet sequence; For the N transaction attribute types, based on the transaction attribute values ​​of the same transaction attribute type in the transaction data packet sequence, attribute value sets are generated according to the position to obtain N attribute value sets; Incremental encoding is performed on the N attribute value sets respectively to obtain N attribute value incremental codes; 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 determining the positional order of the M transaction data packets based on the type priority and transaction attribute value corresponding to the N transaction attribute types, to obtain a transaction data packet sequence, includes: Based on the type priority corresponding to each of the N transaction attribute types, the N transaction attribute types are traversed to obtain the k-th transaction attribute type; the type priority corresponding to the k-th transaction attribute type is lower than the type priority 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 candidate transaction data packets after the (k-1)th position sorting are sorted for the kth position to obtain the M candidate transaction data packets after the kth position sorting; when k is 1, the M candidate transaction data packets after the (k-1)th position sorting are the M transaction data packets. 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 candidate transaction data packets 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 candidate transaction data packets after the k-th position sorting as the transaction data packet sequence.

3. The method according to claim 2, characterized in that, The step of performing a k-th position sorting on the M candidate transaction data packets 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 candidate transaction data packets 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 candidate transaction data packets after the (k-1)th position sorting, those containing the same first transaction attribute value and whose positions are consecutive are determined as candidate transaction data packets 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 candidate transaction data packets to be adjusted are M transaction data packets; Based on the positional relationship of the second transaction attribute value contained in the candidate transaction data packet to be adjusted among the M sorted transaction attribute values, the candidate transaction data packet to be adjusted among the M candidate transaction data packets is subjected to position adjustment processing to obtain the M candidate transaction data packets 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 3, characterized in that, The step of sorting the M transaction attribute values ​​corresponding to the k-th transaction attribute type to obtain M sorted transaction attribute values ​​includes: Count the number of identical transaction attribute values ​​among the M transaction attribute values ​​corresponding to the k-th transaction attribute type; Arrange the M transaction attribute values ​​corresponding to the k-th transaction attribute type in consecutive adjacent positions according to the order of the number of identical transaction attribute values ​​from largest to smallest, to obtain M sorted transaction attribute values.

5. The method according to any one of claims 1-4, characterized in that, The N attribute value sets include attribute value set K. n n is a positive integer less than or equal to N; The incremental encoding process for each of the N attribute value sets to obtain N attribute value incremental codes includes: The attribute value set K n The first transaction attribute value is written into the incremental encoding set and the attribute value set K, respectively. n The corresponding transaction attribute labeling field; Iterate through the set of attribute values ​​K 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 the attribute value set K is determined to be traversed. n Completed, the attribute value set K is determined based on the incremental encoding set. n The corresponding attribute value is incrementally encoded.

6. The method according to any one of claims 1-4, 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 type sliding window; the type sliding window contains L types of transactions with the transaction attribute type T. j Corresponding historical transaction attribute values; Based on the transaction attribute type T among the M transaction data packets j The transaction attribute value and the type sliding window determine the transaction attribute type T. 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 type priority of 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.

7. The method according to claim 6, characterized in that, The transaction attribute type T is determined from the M transaction data packets. j The transaction attribute value and the type sliding window determine the transaction attribute type T. j The corresponding latest attribute value's distance from the standard deviation includes: Among the M transaction data packets, those with the transaction attribute type T j The transaction attribute values ​​are placed sequentially before the position of the sliding window of the type; The type sliding window is forward-sliding to obtain a slidable type sliding window; the slidable type sliding window contains L latest transaction attribute values; the L latest transaction attribute values ​​contain the transaction attribute type T from the M transaction data packets. j Transaction attribute values; 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.

8. The method according to claim 7, 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.

9. The method according to claim 8, 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.

10. The method according to claim 9, 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.

11. The method according to any one of claims 6-10, characterized in that, The transaction attribute type T is determined from the M transaction data packets. j The transaction attribute value and the type sliding window determine the transaction attribute type T. 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 from the standard deviation; the historical attribute value distance from the standard deviation is determined based on the transaction attribute values ​​contained in the sliding window of the type; Among the M transaction data packets, those with the transaction attribute type T j The transaction attribute values ​​are placed sequentially before the position of the sliding window of the type; Perform a forward unit slide on the type sliding window after the (t-1)th unit slide to obtain the type sliding window after the tth unit slide. The transaction attribute value at the end of the type sliding window after the (t-1)th unit slide is determined as the t-th slide-remove transaction attribute value, and the transaction attribute value at the beginning of the type sliding window after the t-th unit slide is determined as the t-th slide-add transaction attribute value; the t-th slide-add transaction attribute value belongs to the M transaction data packets that have the transaction attribute type T. j Transaction attribute values; 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.

12. The method according to claim 11, 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: Obtain the number of added attributes with the same transaction attribute value as the t-th swipe in the 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 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.

13. 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 transaction data packets, each of which contains N transaction attribute values ​​corresponding to different transaction attribute types, where M and N are both positive integers; The sorting module is used to determine the positional order of the M transaction data packets according to the type priority and the transaction attribute value corresponding to the N transaction attribute types, so as to obtain a transaction data packet sequence; The classification module is used to generate N attribute value sets by sorting the transaction attribute values ​​of the same transaction attribute type in the transaction data packet sequence according to their positions for the N transaction attribute types. The encoding module is used to perform incremental encoding on N attribute value sets respectively to obtain N attribute value incremental codes; 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.

14. 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-12.

15. 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-12.

16. 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-12.

Images