A high-performance alliance blockchain steel logistics traceability method

Abstract

The application discloses a high-performance alliance blockchain steel logistics traceability method, comprising the following steps: acquiring data information of a chain in steel logistics; adopting a word frequency statistical method and an optimized hash function to identify transaction information; performing transaction verification on the transaction identification information; performing caching through block caching and receipt caching, and processing transaction verification in parallel; performing traceability result display; accelerating traceability to obtain a traceability result through multi-layer distributed caching and an optimized hash function; and improving data transmission efficiency through cross-domain information interaction and a mark field processing to obtain a DAG graph type blockchain. The application reduces redundant verification, applies caching to transactions, processes block transaction verification in parallel, selects a hash function with high execution speed, and adopts a multi-level distributed caching technology to perform high-performance optimization on alliance blockchain steel logistics traceability.

Description

Technical Field

[0001] This invention belongs to the technical field of blockchain-based traceability methods, and in particular relates to a high-performance consortium blockchain steel logistics traceability method. Background Technology

[0002] As a pillar industry of my country's national economy, the steel industry has seen continuous supply-side reforms in recent years. These reforms involve optimizing industrial policies, transforming government functions, and phasing out excess capacity to adjust the steel industry structure. For steel companies, promoting the digital transformation of steel logistics is an inevitable choice. While my country's traditional logistics industry has grown rapidly in recent years, many problems remain unresolved, such as low efficiency, frequent package loss and warehouse overload, misdelivery, and information leaks. Relying on consortium blockchain technology, logistics companies and both parties in transactions can reliably record and transmit the flow of funds, goods, and information. By utilizing blockchain platforms, the logistics industry can optimize resource utilization, reduce intermediate links, and improve overall industry efficiency.

[0003] In classic blockchain systems, such as Ethereum and Bitcoin, the transaction verification mechanism involves participants (miners) confirming each transaction by transmitting it to other participants, encapsulating the transaction into a block, transmitting the block to other participants, re-verifying and executing the block transaction, storing the block, and finally, the sender confirming that the transaction has been submitted. A major drawback of this process is that each participant must verify a transaction twice, resulting in redundant data. Furthermore, due to this redundancy, reading transactions and storing blocks require more expensive I / O.

[0004] Steel logistics comprises three stages: raw material procurement and transportation, on-site logistics for steel production, and finished product sales logistics. As an industry inherently possessing multimodal transport attributes, steel logistics can be well integrated with blockchain technology. When combined with blockchain, steel logistics utilizes its notarization technology to ensure that every stage of a steel mill's product lifecycle—from raw materials to production, from leaving the mill to warehousing, trading, processing, logistics, and distribution, and even to the final consumer—is immutably recorded and traceable. For steel logistics to achieve data security, all information, such as product information, transaction details, logistics information (driver and vehicle scheduling, transportation routes, etc.), and transportation start and end times, must be recorded on the blockchain. This may also involve further encryption of user privacy data, resulting in a massive blockchain. Furthermore, traditional blockchains generate a large amount of redundant data, making the total size of this blockchain unimaginable. Existing blockchain processing methods cannot meet the unique traceability requirements of steel logistics. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a high-performance consortium blockchain steel logistics traceability method. This method reduces redundant verification by using word frequency statistics, caches application transactions, processes block transaction verifications in parallel, selects a fast hash function, and employs multi-level distributed caching technology to optimize the consortium blockchain steel logistics traceability system for high performance.

[0006] To achieve the above objectives, the technical solution adopted by this invention is: a high-performance consortium blockchain steel logistics traceability method, comprising the following steps:

[0007] Obtain on-chain data information in steel logistics;

[0008] The transaction information identification is performed using a word frequency statistics method and an optimized hash function. The client performs word frequency statistics on the transaction data to determine whether the transaction data contains sensitive information, and then determines whether the transaction data needs to be encrypted. The verification node determines whether to encrypt the data based on word frequency statistics, and then determines whether the information is sensitive.

[0009] Transaction verification is performed using transaction identification information; transaction verification is processed in parallel using block cache and receipt cache.

[0010] The system displays the traceability results, accelerates the tracing process through multi-layered distributed caching and optimized hash functions, and improves data transmission efficiency by obtaining a DAG graph blockchain through cross-domain information interaction and flag field processing.

[0011] Furthermore, in the process of identifying transaction information using word frequency statistics and optimized hash functions:

[0012] Before submitting transaction data to the verification node, the client performs word frequency statistics on the transaction data to be submitted using natural language processing technology. The dictionary used for word frequency statistics is a dictionary constructed based on the consortium consensus mechanism. The results of word frequency statistics are used to determine whether the transaction data to be submitted contains sensitive data and whether encryption is required. If keywords of sensitive data appear in the word frequency statistics, encryption is performed.

[0013] After receiving the transaction data, the verification node uses word frequency statistics to judge the transaction data. Unencrypted transaction data has a fixed format, while encrypted transaction data has a pseudo-random string. The verification node applies word frequency statistics to the received data. If the statistical result contains a pseudo-random string, the received data is encrypted sensitive data; otherwise, it is unencrypted non-sensitive data.

[0014] Furthermore, the dictionary constructed based on the consortium consensus mechanism performs a character-by-character sequential scan for each corpus entry; given a window width W, a string is extracted from the corpus and the dictionary is searched for a corresponding term; if a corresponding term is found, the counter for that term is incremented by one; otherwise, the string length is reduced and the comparison is repeated.

[0015] Furthermore, during the transaction verification process based on transaction identification information, an urgent verification mechanism is used for transactions involving sensitive information, while a lazy verification mechanism is used for transactions involving non-sensitive information, based on the Steel Alliance blockchain consensus mechanism.

[0016] For the verification of sensitive data, an eager verification method is adopted: This verification is carried out when a validator receives a transaction submitted by a client. The validator first verifies the validity of the transaction based on the consortium consensus mechanism. After the verification is valid, the validator will propagate the transaction to other validators, encapsulate the transaction into a block, pass the block to other validators, re-verify and execute the block transaction, store the block, and finally the sender confirms that the transaction has been submitted.

[0017] When verifying non-sensitive information data transactions, a lazy verification method is used: this verification method occurs before the transaction in the block is executed, that is, all verifiers will only verify the transaction when the transaction is about to be executed.

[0018] Furthermore, during the transaction verification process using transaction identification information, caching is performed through block caching and receipt caching:

[0019] The block caching is optimized by using the block number to identify a unique block. After a client submits a transaction, the validator caches the block of the submitted transaction by maintaining a hash table, and then inserts the block into the chain and writes it to the database. The block number is used to uniquely identify a block and is used as the key to quickly retrieve the block in the hash table, thereby reducing the number of reads and writes to the database and speeding up the retrieval.

[0020] For receipt caching optimization, receipts are cached after transaction block execution and before being inserted into the chain. This allows the client to quickly query the cached data first when checking whether a newly submitted transaction has been submitted. Only if the data is not found in the cache will the database be accessed for querying, thereby reducing database read and write operations.

[0021] Furthermore, when verifying transaction identification information using parallel processing, the following steps are taken:

[0022] To further accelerate the processing speed of transactions and other events, a parallel execution protocol is established. This protocol accelerates transaction execution by leveraging the parallelism of the block verification process across multiple node committees. The execution protocol operates through an interactive protocol between a leader and a committee of n executors. Each executor committee member is responsible for executing a segment and verifying that the execution process was correctly executed by the leader.

[0023] The blockchain mechanism mainly consists of two tasks: block selection and transaction execution. Based on the consortium consensus mechanism, a leader and n committees are temporarily selected. Each committee consists of several nodes, and the committee members are called executors, representing their role in executing transactions during block verification. The leader performs the block selection operation and executes all transactions of the selected block. Transaction execution is also responsible for outputting the execution result, also known as the transaction receipt, to apply the block transactions to the previous state and calculate the new state of the blockchain system. The description of state transition is divided into two processes: execution and application of write operations. Transaction execution is a process in which the validity of each transaction is checked, calculations are performed, and the write operation that should be performed on the state is determined. The write operation is stored in the format of (memory address, value) in a set-write data structure. Set-write allows each committee to calculate in advance the exact updated state after its segmented execution.

[0024] Furthermore, by using multi-layered distributed caching to accelerate the process of obtaining tracing results:

[0025] Based on the consortium consensus mechanism, access frequency is defined, which refers to the frequency of access to a certain object; each node stores the defined access frequency of the object and its key in local storage; the access frequency of each object is measured by calculating the number of accesses within a given time period and storing the object together in local storage; a storage class is defined as a group of nodes with similar node availability; data availability is defined, which refers to the probability that data can be found in a node or storage class.

[0026] Nodes are divided into different storage classes based on their availability. Each storage class has a different access frequency level for deleting objects from local storage. The access frequency level of an object is determined by the number of times it is accessed and a threshold time. Except for the highest storage class, each group deletes unaccessed objects based on its access frequency level.

[0027] Furthermore, in the process of improving data transmission efficiency by obtaining a DAG graph blockchain through cross-domain information interaction and flag field processing:

[0028] Based on the graph blockchain DAG blockchain, a hierarchical steel logistics traceability model is constructed. The blockchain is partitioned: before storing steel logistics traceability information, steel logistics is classified by a flag field based on the consortium consensus mechanism, so that steel logistics information of different levels is stored in the corresponding different blockchain partitions. The entire blockchain network nodes are also divided into a main network and multiple different partition sub-networks to reduce the storage pressure on nodes, thereby improving the data transmission efficiency of the blockchain network.

[0029] The hierarchical steel logistics traceability model based on graph blockchain divides all network nodes into a main network and multiple partition sub-networks. The main network stores all block information, while each different partition sub-network stores steel logistics traceability information with different flag field values. Furthermore, the model stores the IP addresses of these sub-network nodes in a tag database, which is jointly stored by all network nodes.

[0030] In the entire network environment, the main network stores all blocks on the DAG blockchain, while the partition sub-networks store the main chain information and the DAG sub-chain corresponding to the partition flag field value.

[0031] Furthermore, cross-domain information exchange is achieved through the hierarchical steel logistics traceability model based on graph blockchain, with different sub-network nodes interacting, including the following steps:

[0032] (1) The node that sends cross-domain interaction information queries the tag database to determine whether the flag field value of the information exists;

[0033] (2) If the flag field value exists, select the node according to the matching results in the database and send the information to the node, then proceed to step (4);

[0034] (3) If the flag field value does not exist, throw an exception and terminate the interaction;

[0035] (4) The selected node reconstructs a block based on the request information;

[0036] (5) All nodes in the partitioned subnetwork complete information verification, information broadcasting, and information storage.

[0037] Furthermore, based on the consortium consensus mechanism, the partitioning process for the flag field includes the following steps:

[0038] (1) Determine whether a certain data is normal based on the alliance consensus mechanism. If it is normal, proceed to step (2); otherwise, proceed to step (3).

[0039] (2) Broadcast the network updates of the main network and the subnet nodes, and wait for the whole network to verify. After verification, store the data and the process ends.

[0040] (3) Determine whether the flag field is the same as the flag field that this node should store. If yes, perform domain authentication and broadcast to wait for verification and storage, and the process ends. If not, proceed to step (4).

[0041] (4) Perform cross-domain interaction and query the tag database; if the TAG tag field does not exist in the database, throw an exception and the process ends; otherwise, proceed to step (5);

[0042] (5) Select the node to be processed based on the IP address corresponding to the flag field in the flag database. The selected node performs block packing, block broadcasting, waiting for verification, and storage operations.

[0043] The beneficial effects of adopting this technical solution are:

[0044] This invention distinguishes and encrypts transaction data information, uses word frequency statistics to determine whether the transaction information contains sensitive data, adopts different verification methods for different types of transaction data to improve node throughput, applies caching technology to newly submitted transaction data to reduce database read and write operations, accelerates transaction processing speed by parallel processing of blockchain transaction verification, selects a faster hash algorithm to improve system execution speed, optimizes the overall storage cost of the blockchain by using multi-layer distributed caching, and improves network data transmission efficiency by combining a graph blockchain structure with a consortium blockchain in the steel logistics field.

[0045] This invention addresses the issue of encryption for transaction data. Using natural language processing technology and a dictionary based on a consortium consensus mechanism, the client performs word frequency statistics on the transaction data to determine if it contains sensitive information, and thus whether encryption is necessary. Verification nodes also use word frequency statistics to determine whether encryption is required, thereby identifying whether the information is sensitive.

[0046] This invention categorizes information data, allowing non-sensitive information to be verified only once, while sensitive information requiring encryption protection is verified twice. Given that sensitive information (such as personal identification information) constitutes a relatively small proportion, and most information needs to be made public for traceability, this effectively improves verification efficiency and thus increases the throughput of the entire blockchain system. Verification nodes can use a consensus mechanism to determine whether transaction data has been encrypted, thereby employing different verification mechanisms for submitted transaction data and reducing redundant verification.

[0047] This invention addresses transaction verification management by changing the traditional transaction verification methods in Ethereum and Bitcoin by applying caching technology: A block number uniquely identifies a block; before new transaction data is uploaded to the blockchain, nodes cache the transaction and its receipt based on the consortium blockchain consensus mechanism. When verifying a transaction, the verification node prioritizes reading data from the cache. Simultaneously, when confirming a transaction, the sender can first read the transaction receipt from the cache to determine whether the transaction has been submitted, reducing database read / write operations. This allows the sender to quickly submit new transactions and confirm existing ones. Based on the Iron Consortium blockchain consensus mechanism, transactions involving sensitive information are verified twice using the traditional verification mechanism; transactions involving non-sensitive information are verified only once, employing a lazy verification mechanism during transaction execution.

[0048] This invention improves throughput by: processing and storing blocks within a single block; reducing read / write operations by caching newly submitted transactions based on the Iron Consortium blockchain consensus mechanism, allowing submitters to quickly retrieve and confirm data; and for block transaction verification, where typically all verification nodes execute the entire block and provide an indication by comparing their execution results with the updated state in the proposal, this technology employs a parallel mode. Based on the consortium consensus mechanism, it divides block verification into multiple disjoint tasks to improve time efficiency, thereby increasing throughput. It also selects a fast hash algorithm. Each block needs to be hashed before being uploaded to the chain to ensure its immutability. Instead of traditional, slower hash functions, the faster Xxhash128 function is used to digest transaction information, block information, and transaction verification data to obtain hash values, thus accelerating the system execution process and improving system throughput.

[0049] This invention optimizes storage costs by employing a multi-layered distributed caching mechanism based on a consortium consensus mechanism and reducing data replication through data access patterns. Nodes participating in the consortium blockchain are categorized, and based on node availability, different node access frequencies are set for different node categories according to the consortium consensus mechanism, thereby deleting data from local storage. Over time, each node only stores frequently accessed data, thus reducing overall storage costs.

[0050] This invention improves the data transmission efficiency of consortium blockchain networks. The method employs a novel consensus mechanism for blockchain networks, the DAG protocol, and proposes a graph-based hierarchical consortium blockchain model for steel logistics traceability. By introducing graph-based blockchains into the steel logistics field, partitioning the graph-based blockchain structure, and classifying information according to a flag field, the information is stored in its corresponding partitions, thereby improving the efficiency of traceability information verification. Based on the consortium consensus mechanism, all network nodes can be divided into multiple sub-networks, with each node only needing to store its own corresponding information, reducing node storage overhead and thus improving the data transmission efficiency of the consortium blockchain network. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of a high-performance consortium blockchain steel logistics traceability method according to the present invention;

[0052] Figure 2 This is a flowchart illustrating the transaction verification process in an embodiment of the present invention.

[0053] Figure 3 This is a schematic diagram of the urgent transaction verification process of the verification node in an embodiment of the present invention;

[0054] Figure 4 This is a schematic diagram of the lazy verification transaction process of the verification node in an embodiment of the present invention;

[0055] Figure 5 This is a schematic diagram of the partition structure in an embodiment of the present invention;

[0056] Figure 6 This is a schematic diagram of the DAG cross-domain interaction process in an embodiment of the present invention;

[0057] Figure 7 This is a schematic diagram of the DAG flag field processing in an embodiment of the present invention. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described below with reference to the accompanying drawings.

[0059] In this embodiment, see Figure 1 As shown, this invention proposes a high-performance consortium blockchain method for tracing the origin of steel logistics, comprising the following steps:

[0060] Obtain on-chain data information in steel logistics;

[0061] The transaction information identification is performed using a word frequency statistics method and an optimized hash function. The client performs word frequency statistics on the transaction data to determine whether the transaction data contains sensitive information, and then determines whether the transaction data needs to be encrypted. The verification node determines whether to encrypt the data based on word frequency statistics, and then determines whether the information is sensitive.

[0062] Transaction verification is performed using transaction identification information; transaction verification is processed in parallel using block cache and receipt cache.

[0063] The system displays the traceability results, accelerates the tracing process through multi-layered distributed caching and optimized hash functions, and improves data transmission efficiency by obtaining a DAG graph blockchain through cross-domain information interaction and flag field processing.

[0064] As an optimization of the above embodiments:

[0065] Based on the consensus mechanism of the consortium blockchain, the data that needs to be uploaded to the blockchain in steel blockchain logistics is categorized according to security. For example, non-sensitive information such as product information and transaction information of both parties does not need to be encrypted during transactions; however, when it comes to some private information in logistics and transportation information, such as driver information, it involves personal privacy and is therefore sensitive data that needs to be encrypted.

[0066] In the process of identifying transaction information using word frequency statistics:

[0067] Before submitting transaction data to the verification node, the client performs word frequency statistics on the transaction data to be submitted using natural language processing technology. The dictionary used for word frequency statistics is a dictionary constructed based on the consortium consensus mechanism. The results of word frequency statistics are used to determine whether the transaction data to be submitted contains sensitive data and whether encryption is required. If keywords of sensitive data appear in the word frequency statistics, encryption is performed.

[0068] After receiving the transaction data, the verification node uses word frequency statistics to judge the transaction data. Unencrypted transaction data has a fixed format, while encrypted transaction data has a pseudo-random string. The verification node applies word frequency statistics to the received data. If the statistical result contains a pseudo-random string, the received data is encrypted sensitive data; otherwise, it is unencrypted non-sensitive data.

[0069] Word frequency statistics can be subject to errors due to the inaccuracy of word segmentation algorithms. These errors can be eliminated by constructing a dictionary based on consortium blockchain logistics. The dictionary, constructed based on the consortium consensus mechanism, performs a character-by-character sequential scan for each corpus. Given a window width W, a string is extracted from the corpus and the dictionary is searched for a corresponding word. If a corresponding word is found, its counter is incremented; otherwise, the string length is reduced and the comparison is repeated.

[0070] As an optimization of the above embodiments:

[0071] During the transaction verification process based on transaction identification information, the Steel Alliance blockchain consensus mechanism employs an eager verification mechanism for transactions involving sensitive information and a lazy verification mechanism for transactions involving non-sensitive information. For example... Figure 2 As shown.

[0072] For the verification of sensitive data, an eager verification method is adopted: This verification is performed when a validator receives a transaction submitted by a client. The validator first verifies the validity of the transaction based on the consortium consensus mechanism, such as verifying the block size, whether the transaction is correctly signed, whether the transaction is ordered, and whether the sender has the necessary permissions. After verification, the validator propagates the transaction to other validators, encapsulates the transaction into a block, passes the block to other validators, re-verifies and executes the block transaction, stores the block, and finally the sender confirms that the transaction has been submitted. The flowchart of the eager verification transaction process is as follows: Figure 3 As shown;

[0073] For non-sensitive information data transactions, a lazy verification method is used: this verification occurs before the transaction in the block is executed. That is, all verifiers only verify the transaction when it is about to be executed. This lazy verification is necessary to ensure the validity of transactions in newly received blocks, and it saves more time than an eager verification mechanism. The lazy verification transaction flowchart is as follows. Figure 4 As shown, we optimize the system by reducing the number of transactions requiring urgent verification through information categorization.

[0074] As an optimization of the above embodiments:

[0075] During transaction verification of transaction identification information, caching is performed through block caching and receipt caching:

[0076] After a block is inserted onto the chain, it is written to the database. When a client needs transaction confirmation, it retrieves the block from the database and checks if the transaction is included in the block. Traditional verification mechanisms require distinguishing between two or more blocks appended to the same index on the blockchain, as these blocks share the same block number. To uniquely identify each block, traditional blockchain technology derives a key for each block before storage by applying recursive length prefix encoding to the block prefix, block number, and block hash. This makes block retrieval less optimal for the client, as it requires re-deriving the key and performing read / write operations to access the block from the database to confirm transaction submission. Traditional blockchain technology only caches transaction receipts when reading them. To check if newly appended transactions are included in the blockchain, the client always needs to access the database first before performing subsequent operations. We propose a new caching scheme based on a consortium consensus mechanism:

[0077] The block caching is optimized so that, unlike traditional blockchains, a key is not derived for each block. Instead, a block number is used to identify a unique block. After a client submits a transaction, the validator caches the blocks of the submitted transaction by maintaining a hash table. Then, the block is inserted onto the chain and written to the database. A block is uniquely identified by its block number, which is used to quickly retrieve the key of the block in the hash table, thereby reducing database reads and writes and speeding up the retrieval process.

[0078] For receipt caching optimization, receipts are cached after transaction block execution and before being inserted into the chain. This allows the client to quickly query the cached data first when checking whether a newly submitted transaction has been submitted. Only if the data is not found in the cache will the database be accessed for querying, thereby reducing database read and write operations.

[0079] Based on the consensus mechanism of fast transaction submission in consortium blockchain, caching technology is applied to reduce database read and write operations by caching newly submitted data, and at the same time, it makes it easier for the sender to quickly confirm the transaction submission, thereby improving the performance of the consortium blockchain system.

[0080] Due to limitations in specific equipment, the cache space may be restricted. The following solution optimizes the use of the cache area to maintain a hash table, which stores block numbers and receipt hash values. First, define a formula:

[0081]

[0082] Where I refers to the total number of receipts that can be cached in the node cache; i represents a specific receipt, and n... i This represents the number of times receipt i is requested to be viewed within time T, where n is the number of times. iThe sum represents the number of times a verification node is requested to view transactions within time T. Using this formula, we can calculate the popularity of a transaction receipt. When a new transaction receipt arrives, we can compare the popularity of receipts, and the cached receipt with the lowest popularity will be replaced. Furthermore, a periodic time is set; every period, the node will clear n. i The value is reset and the counting restarts. We also employ an exponentially decaying access control pattern for cached transaction receipts. We remove rarely accessed transaction receipts from the cache. In this case, it can be represented as a lifecycle analysis problem, and the exponential distribution is an effective approach to solving this problem. We assume that the probability of when an object needs to access a receipt follows an exponential distribution. The cumulative probability of the exponential distribution is:

[0083] D(t,λ)=(1-e -λt );

[0084] Where λ represents the rate that determines the shape of the slope.

[0085] When performing transaction verification using transaction identification information and employing parallel transaction verification:

[0086] To further accelerate the processing speed of transactions and other events, a parallel execution protocol is established. This protocol accelerates transaction execution by leveraging the parallelism of the block verification process across multiple node committees. The execution protocol operates through an interactive protocol between a leader and a committee of n executors. Each executor committee member is responsible for executing a segment and verifying that the execution process was correctly executed by the leader.

[0087] The blockchain mechanism mainly consists of two tasks: block selection and transaction execution. Based on a consortium consensus mechanism, a leader and n committees are temporarily selected. Each committee consists of several nodes, and the committee members are called executors, representing their role in executing transactions during block verification. The leader performs the block selection operation and executes all transactions of the selected block. Transactions can be simple payment operations or other general functions. Transaction execution is also responsible for outputting the execution results, also known as transaction receipts, to apply the block transactions to the previous state and calculate the new state of the blockchain system. The description of state transition is divided into two processes: execution and application of write operations. Transaction execution is a process in which the validity of each transaction is checked, calculations are performed, and the write operations that should be performed on the state are determined. The write operations are stored in the format of (memory address, value) in a set-write data structure. Set-write allows each committee to pre-calculate the exact updated state after its segmented execution.

[0088] The main advantage of this acceleration protocol is that, if the leader's honesty can be ensured (which is obviously a prerequisite) and the number of nodes in the network is moderate, the verification of block execution is time-efficient, which can help improve the overall block production rate of the network. Furthermore, when the leader node proposing a block has an incorrect implicit state change, the block proposal will be rejected, and another node will be re-elected as the leader node to be responsible for proposing blocks. Another advantage is that parallel execution can be seamlessly integrated into the application, providing strong portability.

[0089] As an optimization of the above embodiments:

[0090] Accelerating the process of obtaining tracing results through multi-layered distributed caching:

[0091] Based on the consortium consensus mechanism, access frequency is defined, which refers to the frequency of access to a certain object; each node stores the defined access frequency of the object and its key in local storage; the access frequency of each object is measured by calculating the number of accesses within a given time period and storing the object together in local storage; a storage class is defined as a group of nodes with similar node availability; data availability is defined, which refers to the probability that data can be found in a node or storage class.

[0092] Nodes are divided into different storage classes based on their availability. Each storage class has a different access frequency level for deleting objects from local storage. The access frequency level of an object is determined by the number of times it is accessed and a threshold time. Except for the highest storage class, each group deletes unaccessed objects according to its access frequency level.

[0093] This structural approach allows lower-level storage classes to contain a large number of nodes with low availability and short threshold times, while higher-level storage classes contain nodes with high availability and long threshold times. Higher-level storage classes, due to their longer threshold times, store more objects than lower-level classes. To ensure data availability, nodes in the highest-level storage classes must store all objects, regardless of their access frequency. Since object access frequency is updated periodically, frequently accessed objects are retained in local storage, optimizing storage costs and reducing query costs. Different threshold times are assigned to each storage class based on a consortium consensus mechanism for its initial access frequency level. Each node deletes unaccessed objects if its access time exceeds the threshold time by even once. Therefore, if an object is not accessed at least once within the threshold time, it will be deleted.

[0094] The optimized hash function is the Xxhash function.

[0095] The Xxhash function is a very fast non-cryptographic hashing algorithm. Its execution speed is close to the RAM limit, i.e., close to the upper limit of server processing speed. We chose the Xxhash128 algorithm, which outputs a 128-bit hash value. This algorithm has very high code portability; given specific input information, it produces the same hash value on all platforms. Furthermore, the hash function quality is also very high; the hash value it produces has good dispersion and randomness, and any segment of it can maximize the expansion of a table or index. The Xxhash function can minimize collisions. Using a 128-bit output satisfies the birthday paradox, effectively preventing collisions.

[0096] As an optimization of the above embodiments:

[0097] In the process of improving data transmission efficiency by obtaining a DAG graph blockchain through cross-domain information interaction and flag field processing:

[0098] Based on the graph blockchain DAG blockchain, a hierarchical steel logistics traceability model is constructed. The blockchain is partitioned: before storing steel logistics traceability information, steel logistics is classified by a flag field based on the consortium consensus mechanism, so that steel logistics information of different levels is stored in the corresponding different blockchain partitions. The entire blockchain network nodes are also divided into a main network and multiple different partition sub-networks to reduce the storage pressure on nodes, thereby improving the data transmission efficiency of the blockchain network.

[0099] The hierarchical steel logistics traceability model based on graph blockchain divides all network nodes into a main network and multiple partition sub-networks. The main network stores all block information, and each different partition sub-network stores steel logistics traceability information with different flag field values. Furthermore, the model stores the IP addresses of these sub-network nodes in a tag database (TAG database, which stores the correspondence between flag fields and node IP addresses), which is jointly stored by all network nodes.

[0100] In the entire network environment, the main network stores all blocks on the DAG blockchain, while the partition sub-networks store main chain information and the DAG sub-chain corresponding to the partition flag field value. For example... Figure 5 As shown, the blockchain network for steel logistics traceability is divided into multiple partitions, which facilitates steel logistics traceability, reduces storage overhead, and improves the data transmission efficiency of the blockchain network.

[0101] Cross-domain information exchange is achieved through the hierarchical steel logistics traceability model based on graph blockchain, with different sub-network nodes interacting, such as... Figure 6 As shown, the steps include:

[0102] (1) The node that sends cross-domain interaction information queries the tag database to determine whether the flag field value of the information exists;

[0103] (2) If the flag field value exists, select the node according to the matching result in the database (i.e. the IP address of the target partition sub-network node) and send the information to the node, then proceed to step (4).

[0104] (3) If the flag field value does not exist, throw an exception and terminate the interaction;

[0105] (4) The selected node reconstructs a block based on the request information;

[0106] (5) All nodes in the partitioned subnetwork complete information verification, information broadcasting, and information storage.

[0107] Based on the consortium consensus mechanism, the partitioning of the flag field is processed as follows: Figure 7 As shown, the steps include:

[0108] (1) Determine whether a certain data is normal based on the alliance consensus mechanism. If it is normal, proceed to step (2); otherwise, proceed to step (3).

[0109] (2) Broadcast the network updates of the main network and the subnet nodes, and wait for the whole network to verify. After verification, store the data and the process ends.

[0110] (3) Determine whether the flag field is the same as the flag field that this node should store. If yes, perform domain authentication and broadcast to wait for verification and storage, and the process ends. If not, proceed to step (4).

[0111] (4) Perform cross-domain interaction and query the tag database. If the TAG tag field does not exist in the database, throw an exception and the process ends; otherwise, proceed to step (5).

[0112] (5) Select the node to be processed based on the IP address corresponding to the flag field in the flag database. The selected node performs block packing, block broadcasting, waiting for verification, and storage operations.

[0113] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A high-performance consortium blockchain method for tracing the origin of steel logistics, characterized in that, Including the following steps: Obtain on-chain data information in steel logistics; The transaction information identification is performed using a word frequency statistics method and an optimized hash function. The client performs word frequency statistics on the transaction data to determine whether the transaction data contains sensitive information, and then determines whether the transaction data needs to be encrypted. The verification node determines whether to encrypt the data based on word frequency statistics, and then determines whether the information is sensitive. In the process of identifying transaction information using word frequency statistics and optimized hash functions: Before submitting transaction data to the verification node, the client performs word frequency statistics on the transaction data to be submitted using natural language processing technology. The dictionary used for word frequency statistics is a dictionary constructed based on the consortium consensus mechanism. The results of word frequency statistics are used to determine whether the transaction data to be submitted contains sensitive data and whether encryption is required. If keywords of sensitive data appear in the word frequency statistics, encryption is performed. After receiving the transaction data, the verification node uses word frequency statistics to judge the transaction data. Unencrypted transaction data has a fixed format, while encrypted transaction data has a pseudo-random string. The verification node applies word frequency statistics to the received data. If the statistical result contains a pseudo-random string, the received data is encrypted sensitive data; otherwise, it is unencrypted non-sensitive data. Transaction verification is performed using transaction identification information; transaction verification is processed in parallel using block cache and receipt cache. Specifically, when performing transaction verification using transaction identification information and employing parallel transaction verification: To further accelerate transaction processing, a parallel execution protocol is established, which accelerates transaction execution through the parallelism of the block verification process of multiple node committees. The execution protocol is an interactive protocol between a leader and n executor committees, where each executor committee is responsible for executing a segment and verifying that the execution process is correctly executed by the leader. The blockchain mechanism consists of two tasks: block selection and transaction execution. Based on a consortium consensus mechanism, a leader and n committees are temporarily selected. Each committee consists of several nodes, and the committee members are called executors, representing their role in executing transactions during block verification. The leader performs the block selection operation and executes all transactions of the selected block. Transaction execution is also responsible for outputting the execution result, also known as a transaction receipt, to apply the block transactions to the previous state and calculate the new state of the blockchain system. The description of state transition is divided into two processes: execution and application of write operations. Transaction execution is a process in which the validity of each transaction is checked, calculations are performed, and the write operation that should be performed on the state is determined. The write operation is stored in a set-write data structure in the format of (memory address, value). Set-write allows each committee to calculate in advance the exact updated state after its segmented execution. The system displays the traceability results, accelerates the tracing process through multi-layered distributed caching and optimized hash functions, and improves data transmission efficiency by obtaining a DAG graph blockchain through cross-domain information interaction and flag field processing.

2. The high-performance consortium blockchain steel logistics traceability method according to claim 1, characterized in that, The dictionary, constructed based on the consortium consensus mechanism, performs a character-by-character sequential scan for each corpus entry. Given a window width W, extract a string from the corpus and search the dictionary for a corresponding term. If a corresponding term is found, increment the counter for that term. If not, decrease the string length and re-examine.

3. The high-performance consortium blockchain steel logistics traceability method according to claim 1, characterized in that, During the transaction verification process based on transaction identification information, an urgent verification mechanism is used for transactions involving sensitive information, while a lazy verification mechanism is used for transactions involving non-sensitive information, based on the consensus mechanism of the Steel Alliance blockchain. For the verification of sensitive data, an eager verification method is adopted: This verification is carried out when a validator receives a transaction submitted by a client. The validator first verifies the validity of the transaction based on the consortium consensus mechanism. After the verification is valid, the validator will propagate the transaction to other validators, encapsulate the transaction into a block, pass the block to other validators, re-verify and execute the block transaction, store the block, and finally the sender confirms that the transaction has been submitted. When verifying non-sensitive information data transactions, a lazy verification method is used: this verification method occurs before the transaction in the block is executed, that is, all verifiers will only verify the transaction when the transaction is about to be executed.

4. The high-performance consortium blockchain steel logistics traceability method according to claim 1, characterized in that, During transaction verification of transaction identification information, caching is performed through block caching and receipt caching: The block caching is optimized by using the block number to identify a unique block. After a client submits a transaction, the validator caches the block of the submitted transaction by maintaining a hash table, and then inserts the block into the chain and writes it to the database. The block number is used to uniquely identify a block and is used as the key to quickly retrieve the block in the hash table, thereby reducing the number of reads and writes to the database and speeding up the retrieval. For receipt caching optimization, receipts are cached after transaction block execution and before being inserted into the chain. This allows the client to quickly query the cached data first when checking whether a newly submitted transaction has been submitted. Only if the data is not found in the cache will the database be accessed for querying, thereby reducing database read and write operations.

5. The high-performance consortium blockchain steel logistics traceability method according to claim 1, characterized in that, Accelerating the process of obtaining tracing results through multi-layered distributed caching: Based on the consortium consensus mechanism, an access frequency is defined, which refers to the frequency of access to a certain object; each node stores the defined access frequency of the object and its key in local storage; the access frequency of each object is measured by calculating the number of accesses within a given time period and storing the object together in local storage; a storage class is defined as a group of nodes with similar node availability; Define data availability, which refers to the probability of finding data in a node or storage class; Nodes are divided into different storage classes based on their availability. Each storage class has a different access frequency level for deleting objects from local storage. The access frequency level of an object is determined by the number of times it is accessed and the threshold time. Except for the highest storage class group, each group deletes unaccessed objects based on their access frequency level.

6. The high-performance consortium blockchain steel logistics traceability method according to claim 1, characterized in that, In the process of improving data transmission efficiency by obtaining a DAG graph blockchain through cross-domain information interaction and flag field processing: Based on the graph blockchain DAG blockchain, a hierarchical steel logistics traceability model is constructed. The blockchain is partitioned: before storing steel logistics traceability information, steel logistics is classified by a flag field based on the consortium consensus mechanism, so that steel logistics information of different levels is stored in the corresponding different blockchain partitions. The entire blockchain network nodes are divided into a main network and multiple different partition sub-networks to reduce node storage pressure and thus improve the data transmission efficiency of the blockchain network. The hierarchical steel logistics traceability model based on graph blockchain divides all network nodes into a main network and multiple partition sub-networks. The main network stores all block information, while each different partition sub-network stores steel logistics traceability information with different flag field values. Furthermore, the model stores the IP addresses of these sub-network nodes in a tag database, which is jointly stored by all network nodes. In the entire network environment, the main network stores all blocks on the DAG blockchain, while the partition sub-networks store the main chain information and the DAG sub-chain corresponding to the partition flag field value.

7. The high-performance consortium blockchain steel logistics traceability method according to claim 6, characterized in that, Cross-domain information exchange is achieved through the hierarchical steel logistics traceability model based on graph blockchain, with different sub-network nodes interacting, including the following steps: The node sending cross-domain interaction information queries the tag database to determine if the flag field value of the information exists. If the flag field value exists, select a node based on the matching results in the database, send the information to that node, and proceed to step (4); If the flag field value does not exist, an exception is thrown and the interaction is terminated; The selected node reconstructs a block based on the request information; All nodes in the partitioned subnetwork complete information verification, information broadcasting, and information storage.

8. The high-performance consortium blockchain steel logistics traceability method according to claim 6, characterized in that, Based on the consortium consensus mechanism, the partitioning process for the flag field includes the following steps: Based on the alliance consensus mechanism, determine whether a certain data is normal. If it is normal, proceed to step (2); otherwise, proceed to step (3). Broadcast the network updates to the main network and partition subnet nodes, wait for network-wide verification, store the updates after verification, and the process ends. Determine whether the flag field is the same as the flag field that this node should store. If yes, perform domain authentication and broadcast to wait for verification and storage, and the process ends. If not, proceed to step (4). Perform cross-domain interaction and query the tag database; if the TAG tag field does not exist in the database, throw an exception and the process ends. Otherwise proceed to step (5); Based on the IP address corresponding to the flag field in the flag database, the node to be processed is selected. The selected node performs block packaging, block broadcasting, waiting for verification, and storage operations.

Images