Method for tracing electronic component products in transaction based on block chain

Abstract

The invention relates to a method for tracing electronic component products in transaction based on a block chain. The method comprises the steps of obtaining electronic component transaction data, and dividing the electronic component transaction data into sensitive data, non-sensitive data and on-chain contract data through a preset classification model; encrypting sensitive data by adopting an encryption algorithm and a dynamic confusion technology to generate an encrypted data block, and constructing a structured encrypted data set together with non-sensitive data and on-chain contract data; performing Hash aggregation on the encrypted data set based on a timestamp Merkel forest structure to generate a block head and a block body containing timestamps and root Hash; verifying the block head and the block body through an improved asynchronous Byzantine consensus algorithm, and generating a consensus block for ensuring the consistency of network data; and when a query request is received, verifying the access permission based on a preset permission model, and outputting a verification result of whether to agree to query. By adopting the method, the security of electronic component product traceability in the transaction can be improved, the data privacy protection is enhanced, and the transaction data processing efficiency is improved.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain technology, and in particular relates to a method for tracking and tracing electronic component products in transactions based on blockchain. Background Art

[0002] With the development of electronic information technology, blockchain technology, with its decentralized, tamper-proof, time-series data traceability, and multi-party consensus-based characteristics, has gradually become a core solution to supply chain trust issues. In the field of electronic components, traditional traceability methods mainly rely on centralized databases or enterprise-built information systems, recording transaction data through manual entry or system integration. For example, manufacturers store component model, batch, production process, and other information on local servers, suppliers record raw material sources in spreadsheets, and logistics providers update transportation routes through ERP systems. This creates a linear traceability model with independent storage at each link and relying on manual connection.

[0003] However, current electronic component traceability technology faces multiple pain points: First, the vulnerability of centralized storage leads to significant data security risks. Single servers are vulnerable to hacker attacks or system failures. Second, information silos and sharing barriers are significant. Data formats and interface standards vary across different companies, and cross-link traceability requires connecting to each system one by one, taking days or even weeks. Furthermore, companies selectively conceal key data due to commercial privacy concerns. Third, sensitive data protection mechanisms are lacking. Traditional solutions lack effective encryption for sensitive information such as cost structures and customer resources, exposing companies to the risk of commercial secrets being leaked when sharing data, hindering supply chain collaboration efficiency. Fourth, verification efficiency and timeliness are insufficient. Traditional hash tree structures have high verification complexity when processing high-frequency transactions and cannot accurately reflect the chronological order of transactions. This makes it difficult to meet the real-time requirements of the electronic component supply chain, which processes hundreds of thousands of transactions daily. Summary of the Invention

[0004] Based on this, it is necessary to provide a method for tracking and tracing electronic components products in blockchain-based transactions that can improve traceability security in response to the above technical problems.

[0005] In a first aspect, the present application provides a method for tracking and tracing electronic components in transactions based on blockchain, comprising:

[0006] Obtain transaction data of electronic components in the transaction, classify the transaction data according to the preset classification model, and obtain sensitive data, non-sensitive data and on-chain contract data;

[0007] Sensitive data is encrypted based on a preset encryption algorithm and dynamic obfuscation technology to obtain encrypted data blocks of sensitive data. The encrypted data blocks, non-sensitive data, and on-chain contract data are then combined to form a structured encrypted data set.

[0008] Based on the timestamp Merkle forest structure, hash aggregation is performed on the structured encrypted data set to generate the block header and block body;

[0009] The block header and block body are verified according to the improved asynchronous Byzantine consensus algorithm to generate a consensus block; the consensus block is used to indicate the data consistency in the blockchain network;

[0010] When a query request for a consensus block is obtained, the query request is verified based on the preset query permission control model to obtain a permission verification result; the permission verification result is used to indicate consent to query transaction data in order to track and trace the transaction data of electronic components.

[0011] In one embodiment, sensitive data is encrypted based on a preset encryption algorithm and dynamic obfuscation technology to obtain encrypted data blocks of sensitive data. The encrypted data blocks, non-sensitive data, and on-chain contract data are combined to generate a structured encrypted data set, including:

[0012] Each data item in the sensitive data is encrypted using the Paillier homomorphic encryption algorithm to generate a set of ciphertext blocks;

[0013] Perform blind obfuscation processing on the ciphertext block set using a random mask to obtain an encrypted data block;

[0014] Integrate encrypted data blocks with non-sensitive data and on-chain contract data to generate structured encrypted data sets.

[0015] In one embodiment, a hash aggregation process is performed on a structured encrypted data set based on a timestamp Merkle forest structure to generate a block header and a block body, including:

[0016] Each transaction data in the structured encrypted data set is processed using a hash function to obtain an aggregated hash tree;

[0017] According to the preset time window, the aggregated hash tree is grouped and processed to construct a timestamp Merkle forest;

[0018] The root hash of the timestamp Merkle forest and the previous block information are packaged to obtain the block header and block body.

[0019] In one embodiment, the block header and block body are verified according to the improved asynchronous Byzantine consensus algorithm to generate a consensus block, including:

[0020] Based on the following verification conditions, block verification is performed on the block header and block body to obtain the block verification result:

[0021]

[0022] Among them, B j For nodes, Vote(B j ) is B j The verification result of , Block is the generated block, and Verify(·) is the verification function used to check the continuity and data integrity of the block hash and the previous block hash;

[0023] Based on the block verification result, according to the preset confirmation conditions, the block confirmation result is obtained; the confirmation conditions are expressed by the following formula:

[0024]

[0025] Among them, Vote(B j ) is B j Verification results, f is the maximum number of fault-tolerant nodes, n is the total number of nodes;

[0026] Generate a consensus block based on the block confirmation results.

[0027] In one embodiment, the query permission control model includes:

[0028] The distributed threshold signature module is used to obtain query requests and obtain authorization results after the number of authorized signatures reaches a preset number of authorized signatures. The authorization results are used to decrypt sensitive data. The query request meets the following conditions:

[0029]

[0030] Among them, Q is the query request, n is the total number of authorized parties, t is the minimum number of signatures required for decryption, Sign j (Q) is the signature of the query request by the jth authorized party;

[0031] The zero-knowledge range proof module is used to verify whether the transaction amount in the transaction data is within the legal range and obtain the legitimacy verification result;

[0032] The Merkle forest path verification module is used to verify whether the transaction timestamp in the transaction data exists in the Merkle forest of the blockchain and obtain the existence result;

[0033] The permission verification result module is used to generate permission verification results based on the authorization results, legitimacy verification results and existence results.

[0034] In one embodiment, when a query request for a consensus block is obtained, the query request is verified based on a preset query authority control model. After obtaining the authority verification result, the following steps are further included:

[0035] Build a transaction graph based on the permission verification results;

[0036] According to the PageRank algorithm, the transaction graph is analyzed and processed to calculate the PageRank value; the PageRank value is obtained using the following formula:

[0037]

[0038] Where PR(v) is the PageRank value of node v, d is the damping coefficient, which indicates the probability of users continuing to browse randomly, L(u) is the number of outbound links of the node, which is used to reflect the fund distribution ability, N is the total number of nodes in the transaction graph, and In(v) is the set of nodes adjacent to node v.

[0039] According to the preset abnormal threshold, the PageRank value is subjected to threshold judgment processing to generate an abnormal detection result; the abnormal detection result is used to indicate that there is a potential risk in the transaction of electronic components.

[0040] In one embodiment, after performing hash aggregation processing on a structured encrypted data set based on a timestamp Merkle forest structure to generate a block header and a block body, the process further includes:

[0041] Perform consistency check on the block header and block body to obtain the test results;

[0042] When the detection result is inconsistent, the node position of the data is located based on the gradient descent algorithm, and the node position of the data is repaired to obtain the repair result.

[0043] In one embodiment, it further includes:

[0044] Generate a hash lock based on the cross-chain transaction and generate a cross-chain transaction contract; the cross-chain transaction contract is used to verify the validity of the transaction data and perform atomic swaps;

[0045] When the cross-chain transaction contract is triggered, the execution result of the cross-chain transaction contract is obtained;

[0046] If the execution result satisfies the cross-chain transaction contract, the transaction is completed.

[0047] If the execution result does not meet the cross-chain transaction contract, the transaction rollback result is obtained.

[0048] In one embodiment, it further includes:

[0049] Monitor the load of each node in the blockchain network in real time and obtain monitoring results;

[0050] Based on the monitoring results, dynamically adjust the node allocation and transfer transactions from high-load nodes to low-load nodes;

[0051] Dynamically optimize sharding strategies based on changes in network load; sharding strategies include merging or splitting shards to adapt to different transaction volumes and load conditions.

[0052] Secondly, this application also provides a blockchain-based system for tracking and tracing electronic components in transactions, including:

[0053] The transaction data acquisition and classification module is used to obtain the transaction data of electronic components in the transaction, classify the transaction data according to the preset classification model, and obtain sensitive data, non-sensitive data and on-chain contract data;

[0054] The encryption module is used to encrypt sensitive data based on a preset encryption algorithm and dynamic obfuscation technology to obtain encrypted data blocks of sensitive data, and generate a structured encrypted data set by combining the encrypted data blocks, non-sensitive data, and on-chain contract data;

[0055] The block header and block body generation module is used to perform hash aggregation processing on the structured encrypted data set based on the timestamp Merkle forest structure to generate the block header and block body;

[0056] The consensus block generation module is used to verify the block header and block body according to the improved asynchronous Byzantine consensus algorithm to generate a consensus block; the consensus block is used to indicate the data consistency in the blockchain network;

[0057] The query and traceability module is used to verify the permissions of the query request based on the preset query permission control model when a query request for the consensus block is obtained, and obtain the permission verification result; the permission verification result is used to indicate the consent to query the transaction data in order to track and trace the transaction data of electronic components.

[0058] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method described in the first aspect when executing the computer program.

[0059] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the method described in the first aspect when the computer program is executed by a processor.

[0060] The above-mentioned method for tracking and tracing electronic component products in blockchain-based transactions divides transaction data into sensitive data, non-sensitive data, and on-chain contract data through a classification model, achieving the two-way needs of sensitive data encryption protection and non-sensitive data on-chain circulation; uses the timestamp Merkle forest structure to hash and aggregate structured encrypted data sets to generate block headers and block bodies containing timestamps and root hashes, ensuring data timeliness, integrity, and efficient verification; with the help of an improved asynchronous Byzantine consensus algorithm, consensus blocks are generated based on the majority rule after independent verification by multiple nodes to ensure data consistency and processing efficiency in the distributed network; relies on the query permission control model to perform hierarchical permission verification on query requests to achieve fine-grained control of data access. This method forms a tamper-proof, traceable, secure, and controllable electronic component transaction record system through data layered processing, time-series hash storage, distributed consensus mechanism, and hierarchical permission control, providing a transparent and reliable traceability path for the supply chain, supporting the trusted flow of transaction data throughout its life cycle, improving the efficiency of multi-party collaboration, and reducing the risk of data leakage and tampering and the cost of collaboration. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0062] Figure 1 A schematic diagram of an application environment for a method for tracking and tracing electronic components in transactions based on blockchain in one embodiment;

[0063] Figure 2 1. A flowchart of a method for tracking and tracing electronic components in blockchain-based transactions in one embodiment;

[0064] Figure 3 1. A schematic diagram of the structure of a system for tracking and tracing electronic components in transactions based on blockchain in one embodiment;

[0065] Figure 4 A schematic diagram of the structure of a computer device for tracking and tracing electronic component products in blockchain-based transactions in one embodiment. DETAILED DESCRIPTION

[0066] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0067] The method for tracking and tracing electronic components in transactions based on blockchain provided in the embodiments of the present application can be applied to Figure 1 In the application environment shown, electronic component supplier terminal 101 and electronic component purchaser terminal 102 communicate with blockchain 103 via a blockchain network to obtain or store blockchain resources. Terminal devices include, but are not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices include smart speakers, smart TVs, smart air conditioners, and smart car devices. Portable wearable devices include smart watches, smart bracelets, and head-mounted devices.

[0068] In an exemplary embodiment, Figure 2 As shown in the figure, a method for tracking and tracing electronic components in transactions based on blockchain is provided. Figure 1 Taking the supplier terminal 101 in FIG. 1 as an example, the following steps S201 to S205 are described:

[0069] S201, obtain the transaction data of electronic components in the transaction, classify the transaction data according to the preset classification model, and obtain sensitive data, non-sensitive data and on-chain contract data.

[0070] For example, in an electronic component transaction, the supplier terminal collects various transaction-related data, such as product specifications, price, quantity, production batch, and logistics information. Using a pre-set classification model (e.g., a machine learning classifier), the supplier terminal divides this data into three categories: sensitive data (e.g., encrypted payment credentials, buyer and seller identity information, and ciphertext of the transaction amount), non-sensitive data (e.g., logistics order numbers, transaction timestamps, and product batch numbers), and on-chain contract data (e.g., smart contract code, multi-party signature records, and fulfillment status). Categorizing transaction data by sensitivity and purpose facilitates subsequent differentiated processing, ensuring data security and query efficiency.

[0071] S202: Encrypt the sensitive data based on a preset encryption algorithm and dynamic obfuscation technology to obtain encrypted data blocks of the sensitive data, and generate a structured encrypted data set by combining the encrypted data blocks, non-sensitive data, and on-chain contract data.

[0072] For example, for sensitive data, the supplier terminal uses a pre-set encryption algorithm (such as Paillier or RSA) combined with dynamic obfuscation technology. Dynamic obfuscation uses randomly generated masks or transformation rules to further disrupt the data structure based on encryption, enhancing security. The encrypted sensitive data blocks are then integrated with unencrypted non-sensitive data and on-chain contract data to generate a structured encrypted data set according to a predefined format.

[0073] S203, based on the timestamp Merkle forest structure, hash aggregation processing is performed on the structured encrypted data set to generate a block header and block body.

[0074] The timestamp Merkle forest structure is a multi-level hash tree structure that calculates a hash value for each data item and then aggregates the calculated hash values ​​level by level to form higher-level hash values, ultimately generating a root hash value. Supplier terminals use the timestamp Merkle forest structure to perform hash aggregation processing on structured encrypted data sets. During the hash aggregation process, timestamp information is embedded in the hash calculation to ensure the data's timeliness and immutability. Through hash aggregation, a block header containing key information such as the root hash value and timestamp is generated, as well as a block body containing the original data. The timestamp Merkle forest structure can efficiently verify the integrity of large amounts of data.

[0075] S204: Verify the block header and block body according to the improved asynchronous Byzantine consensus algorithm to generate a consensus block; the consensus block is used to indicate the data consistency in the blockchain network.

[0076] The improved asynchronous Byzantine consensus algorithm, based on the traditional Byzantine fault-tolerant algorithm, optimizes the inter-node communication mechanism and voting process, allowing nodes to efficiently reach consensus in an asynchronous network environment. For example, the supplier terminal uses the improved asynchronous Byzantine consensus algorithm to verify the generated block header and block body. During the verification process, each participating node verifies the legitimacy of the block, including data integrity, timestamp validity, and transaction logic correctness. Only when a sufficient number of nodes reach consensus is a consensus block generated. This consensus block is added to the blockchain network to indicate data consistency within the blockchain network and ensure that all nodes reach consensus on the status of transaction data.

[0077] S205: When a query request for a consensus block is obtained, the query request is verified based on a preset query authority control model to obtain an authority verification result; the authority verification result is used to indicate consent to query transaction data to track and trace the transaction data of electronic components.

[0078] For example, when a supplier terminal receives a query request for a consensus block from a buyer terminal, it verifies the query request based on a pre-set query permission control model. The query permission control model determines whether the queryer has permission to access specific data based on factors such as the queryer's identity, role, and query purpose. For example, for sensitive data, only authorized auditors or parties involved in the transaction may have query permission; for non-sensitive data, query permission may be open to multiple participants in the supply chain. By verifying the query request, a permission verification result is obtained, which is used to indicate whether to agree or deny the query transaction data, thereby achieving controllable tracking and traceability of electronic component transaction data.

[0079] In the above-mentioned method for tracking and tracing electronic component products in blockchain-based transactions, through data classification and differentiated encryption processing, while ensuring the security of sensitive data, non-sensitive data can be effectively circulated on the blockchain, balancing the needs of data privacy protection and supply chain transparency; the combination of the timestamp Merkel forest structure and the improved asynchronous Byzantine consensus algorithm improves the performance and scalability of the blockchain, improves the efficiency of processing large amounts of transaction data, and quickly reaches consensus in a distributed network; the preset query permission control model ensures the controllability of data access, and only authorized users can obtain the corresponding data, enhancing data security; the entire method, from data generation, processing to storage and query, can effectively prevent data tampering and forgery, provide a trusted transaction environment and a transparent traceability path for the electronic component supply chain, and help improve the efficiency of the supply chain and reduce risks.

[0080] Optionally, the sensitive data is encrypted based on a preset encryption algorithm and dynamic obfuscation technology to obtain an encrypted data block of the sensitive data, and the encrypted data block, non-sensitive data, and on-chain contract data are combined to form a structured encrypted data set, including the following steps:

[0081] S1001: Each data item in the sensitive data is encrypted using the Paillier homomorphic encryption algorithm to generate a set of ciphertext blocks.

[0082] For example, when processing sensitive data, the supplier terminal uses the Paillier homomorphic encryption algorithm to encrypt each data item within the sensitive data. Paillier homomorphic encryption is a type of additive homomorphic encryption algorithm with the unique property of being able to perform specific mathematical operations on ciphertext. The decrypted results of these operations are identical to the results of the same operations on the plaintext. During the encryption process, the algorithm generates a corresponding ciphertext for each data item, and the generated ciphertexts collectively constitute a set of ciphertext blocks.

[0083] S1002: Perform blind obfuscation processing on the ciphertext block set using a random mask to obtain an encrypted data block.

[0084] For example, after the supplier terminal obtains the ciphertext block set, it will use a random mask to perform blind obfuscation processing on it. The random mask is a set of random numbers dynamically generated during each processing. During the blind obfuscation process, the random mask is combined with each ciphertext block in the ciphertext block set according to specific mathematical rules (such as multiplication or addition operations). The ciphertext block is further obfuscated through the operation of the random mask. Even if the attacker obtains the ciphertext, it is difficult to analyze any information of the original data because the specific value of the random mask is unknown. After the blind obfuscation process, a more secure encrypted data block is obtained, which enhances the security of sensitive data during transmission and storage.

[0085] S1003, integrate the encrypted data block with non-sensitive data and on-chain contract data to generate a structured encrypted data set.

[0086] For example, the supplier terminal integrates the encrypted data blocks obtained through encryption and blinding obfuscation with non-sensitive data that does not require encryption and on-chain contract data used for blockchain smart contract execution. During the integration process, the encrypted data blocks, non-sensitive data, and on-chain contract data are organized together in a pre-designed structured format (such as JSON, XML, and other data structures) to form a complete structured encrypted data set. Different types of data maintain their respective characteristics and uses. The encrypted data blocks ensure the security of sensitive data, non-sensitive data can be publicly verified when needed, and on-chain contract data can automatically execute the corresponding transaction logic when the conditions are met, providing comprehensive and orderly data support for the tracking and tracing of electronic component transactions.

[0087] Optionally, based on the timestamp Merkle forest structure, hash aggregation processing is performed on the structured encrypted data set to generate a block header and a block body, including the following steps:

[0088] S2001, each transaction data in the structured encrypted data set is processed using a hash function to obtain an aggregated hash tree.

[0089] For example, the supplier terminal uses a specific hash function (such as SHA-256) to process each transaction data in the structured encrypted data set. The hash function maps each transaction data into a fixed-length hash value, and an aggregate hash tree is constructed based on these hash values. In the aggregate hash tree, adjacent hash values ​​are combined two by two, and the hash values ​​are calculated again to form a higher-level node. This process is repeated until a root hash value is finally formed. Constructing an aggregate hash tree can efficiently verify the integrity of large amounts of transaction data. This is because if any transaction data is changed, the entire root hash value will also change.

[0090] S2002: Group the aggregated hash tree according to the preset time window to construct a timestamp Merkle forest.

[0091] Exemplarily, the supplier terminal groups the aggregated hash trees according to a preset time window. The time window is a time interval (such as every minute, every hour, etc.) pre-set based on business needs and system performance. The aggregated hash trees within each time window will be grouped together. Then, a corresponding Merkle tree is constructed for the aggregated hash trees within each time window, and these Merkle trees together constitute the timestamp Merkle forest. Each Merkle tree has its own root hash value, and the timestamp information will be embedded in the construction process of the timestamp Merkle forest. The timestamp Merkle forest can not only reflect the temporal relationship of transaction data, but also use the characteristics of the Merkle tree to quickly verify the integrity of the data.

[0092] S2003: Pack the root hash of the timestamp Merkle forest and the previous block information to obtain the block header and block body.

[0093] For example, the supplier terminal packages the root hash of the timestamp Merkle forest with the previous block information (including the hash value and timestamp of the previous block). The block header contains key information used to identify and verify the block, such as the root hash of the timestamp Merkle forest, the hash value of the previous block, the timestamp, and the difficulty value; while the block body contains the original transaction data. Through this packaging process, each block is closely connected to the previous block, forming the chain structure of the blockchain. At the same time, the root hash of the timestamp Merkle forest ensures the integrity of all transaction data within the block, while the previous block information ensures the continuity and immutability of the blockchain.

[0094] Optionally, the block header and block body are verified according to the improved asynchronous Byzantine consensus algorithm to generate a consensus block, including the following steps:

[0095] S3001: Based on the following verification conditions, block verification is performed on the block header and block body to obtain the block verification result:

[0096]

[0097] Among them, B j For nodes, Vote(B j ) is B j The verification result of , Block is the generated block, and Verify(·) is the verification function used to check the continuity and data integrity of the block hash and the previous block hash.

[0098] In the verification results above, a pass is 1 and a fail is 0. For example, each node in the network performs comprehensive verification on newly generated blocks (including the block header and block body) according to specific verification criteria. The verification function checks several key aspects. First, it checks the continuity of the block hash with the previous block hash. If the two hash values ​​are discontinuous, it indicates that the blockchain may have been tampered with or forked. Second, it checks data integrity to ensure that the transaction data within the block has not been modified during transmission and processing. After completing verification, each node will output a verification result, which indicates whether the block has passed verification.

[0099] S3002: Based on the block verification result and according to the preset confirmation conditions, a block confirmation result is obtained; the confirmation condition is expressed by the following formula:

[0100]

[0101] Among them, Vote(B j ) is B j Verification results, f is the maximum number of fault-tolerant nodes, n is the total number of nodes.

[0102] For example, based on the block verification results output by all nodes, the supplier terminal will determine whether the block can be confirmed according to the preset confirmation conditions. The core idea of ​​the above confirmation condition formula is that a block can only be confirmed when more than two-thirds of the honest nodes in the network have verified it. The confirmation condition is designed to address the existence of Byzantine nodes (nodes that may be malicious or faulty) and ensure that the correct consensus can still be reached even with a certain number of Byzantine nodes.

[0103] S3003: Generate a consensus block based on the block confirmation result.

[0104] For example, based on the block confirmation results, if the preset confirmation conditions are met, that is, more than two-thirds of the nodes verify and approve the block, then this block will be confirmed as a consensus block. The consensus block will be added to the blockchain network and become part of the blockchain. At this time, all nodes will update their own copies of the blockchain to align with the consensus block. The entire blockchain network has reached a consensus on the new block, ensuring data consistency across all nodes.

[0105] Optionally, the query permission control model includes:

[0106] The distributed threshold signature module is used to obtain query requests and obtain authorization results after the number of authorized signatures reaches a preset number of authorized signatures. The authorization results are used to decrypt sensitive data. The query request meets the following conditions:

[0107]

[0108] Among them, Q is the query request, n is the total number of authorized parties, t is the minimum number of signatures required for decryption, Sign j (Q) is the signature of the query request by the j-th authorized party.

[0109] For example, when a purchasing terminal needs to query sensitive data, it sends a query request to the blockchain. The blockchain then transmits the query request to the supplier terminal via the blockchain network. After receiving the query request, the supplier terminal uses the distributed threshold signature module to manage the query request. The query request must be jointly approved by multiple authorized parties. Specifically, there are n authorized parties, and decrypting sensitive data requires the signatures of at least t authorized parties. Each authorized party independently signs the query request, and only when the number of signatures reaches or exceeds t is a valid authorization result obtained. The advantage of the threshold signature mechanism is that it does not require all authorized parties to sign; only a preset minimum number of signatures is required, which ensures both security and efficiency. The distributed threshold signature module effectively prevents the abuse of authority by a single authorized party. Only query requests approved by a sufficient number of authorized parties are approved, thus protecting the security of sensitive data.

[0110] The zero-knowledge range proof module is used to verify whether the transaction amount in the transaction data is within the legal range and obtain the legitimacy verification result.

[0111] For example, the primary function of the zero-knowledge range proof module is to verify whether the transaction amount in transaction data is within a legal range. Without revealing the specific transaction amount, the module can prove that the transaction amount meets the pre-defined range conditions. Zero-knowledge proofs are inherently zero-knowledge proofs, meaning that the verifier does not obtain the specific transaction amount during the verification process, only whether it is legal. This is crucial for protecting transaction privacy. For example, in electronic component transactions, the transaction amount may involve commercial secrets. Using the zero-knowledge range proof module, the legality of the transaction can be proven without revealing the specific amount, ensuring compliance with relevant regulations and agreements while protecting the privacy of both parties.

[0112] The Merkle forest path verification module is used to verify whether the transaction timestamp in the transaction data exists in the Merkle forest of the blockchain and obtain the existence result.

[0113] The Merkle Forest Path Verification Module verifies whether the transaction timestamp in the transaction data exists in the blockchain's Merkle Forest. The Merkle Forest is a multi-level hash tree structure that efficiently verifies the existence and integrity of large amounts of data. For example, when a supplier terminal receives a query request from a buyer terminal, the Merkle Forest Path Verification Module searches the Merkle Forest for a corresponding path based on the transaction timestamp and verifies the validity of that path. If a valid path is found, it indicates that the transaction timestamp does exist in the blockchain and the transaction truly occurred. Merkle Forest Path Verification effectively prevents fraudulent transactions and data tampering, ensuring the authenticity of transaction data.

[0114] The permission verification result module is used to generate permission verification results based on the authorization results, legitimacy verification results and existence results.

[0115] Among them, the permission verification result module will comprehensively integrate the authorization result, legality verification result and existence result to generate the final permission verification result; the query request will only be approved when all conditions are met; specifically, the authorization result must show that the query request has obtained sufficient signatures from authorized parties; the legality verification result must prove that the transaction amount is within the legal range; the existence result must confirm that the transaction timestamp exists in the blockchain; if any of these conditions is not met, the query request will be rejected; the permission verification result module ensures that only legal and authorized queries can access sensitive data, providing protection for the secure query and tracking and tracing of electronic component transaction data.

[0116] Optionally, when a query request for a consensus block is obtained, the query request is verified based on a preset query authority control model. After obtaining the authority verification result, the following steps are further included:

[0117] S4001: Build a transaction graph based on the permission verification results.

[0118] Among them, the transaction graph is a graph structure, in which nodes represent entities involved in the transaction (such as suppliers, manufacturers, distributors, etc.), edges represent the transaction relationships between entities, and the weight of the edges can represent information such as transaction amount and transaction quantity; for example, after the supplier terminal obtains the permission verification result, if the verification is passed, the supplier terminal will construct a transaction graph based on the transaction data in the consensus block; by constructing the transaction graph, the flow path of electronic components in the supply chain and the transaction network between entities can be intuitively displayed, providing a basis for subsequent analysis.

[0119] S4002: Analyze and process the transaction graph according to the PageRank algorithm to calculate the PageRank value. The PageRank value is obtained using the following formula:

[0120]

[0121] Where PR(v) is the PageRank value of node v, d is the damping coefficient, which indicates the probability of the user continuing to browse randomly, L(u) is the number of outbound links of the node, which is used to reflect the fund distribution ability, N is the total number of nodes in the transaction graph, and In(v) is the set of nodes adjacent to node v.

[0122] For example, the supplier terminal uses the PageRank algorithm to analyze and process the transaction graph. Originally developed to assess the importance of web pages, the PageRank algorithm is innovatively applied here to transaction network analysis. In the transaction graph, a node's PageRank value reflects its importance and influence within the entire transaction network. The damping coefficient in the above formula represents the probability of a user continuing to browse randomly. A typical value of 0.85 indicates an 85% probability of continuing to browse along the transaction relationship and a 15% probability of randomly jumping to another node. The number of outlinks a node has reflects its fund distribution capacity—its ability to transfer funds to other nodes. By iteratively calculating the PageRank value of each node, the status and role of each entity in the transaction network can be quantified.

[0123] S4003, performing threshold judgment processing on the PageRank value according to the preset abnormality threshold, and generating an abnormality detection result; the abnormality detection result is used to indicate that there is a potential risk in the transaction of electronic components.

[0124] For example, the supplier terminal will perform threshold judgment processing on the calculated PageRank value based on the preset abnormal threshold. The PageRank value of each node is compared with the preset abnormal threshold. If the PageRank value of a node is higher or lower than the preset threshold, it may indicate that the entity corresponding to the node has abnormal trading behavior. Specifically, a node with an excessively high PageRank value may indicate that the entity has an abnormally high influence in the trading network and may have monopolistic or market manipulation behaviors; while a node with an excessively low PageRank value may indicate that the entity's trading behavior does not conform to the normal pattern and may have potential risks such as fraud or money laundering. Through threshold judgment, anomaly detection results can be generated to provide a basis for risk warning of electronic component transactions.

[0125] Optionally, after performing hash aggregation processing on the structured encrypted dataset based on the timestamp Merkle forest structure to generate the block header and block body, the following steps are also included:

[0126] S5001: Perform consistency check on the block header and block body to obtain the test result.

[0127] For example, after the block header and block body are generated, the supplier terminal will immediately perform a consistency check on them. The consistency check mainly checks two aspects: first, whether the root hash value in the block header is consistent with the root hash value obtained through hash aggregation of the actual transaction data in the block body, ensuring that the block header accurately reflects the contents of the block body; second, whether the hash value of the previous block in the block header is consistent with the actual hash value of the previous block, ensuring the continuity and integrity of the blockchain. Through this two-way verification, errors or tampering that may occur during data transmission or processing can be discovered in a timely manner, providing a basis for subsequent data repair.

[0128] S5002: When the detection result is inconsistent, the node position of the data is located based on the gradient descent algorithm, and the node position of the data is repaired to obtain a repair result.

[0129] The gradient descent algorithm, originally designed for optimization problems, is innovatively applied here to error location. For example, when the consistency check result is inconsistent, the supplier terminal uses the gradient descent algorithm to locate the erroneous node position of the data. Specifically, the supplier terminal treats the inconsistency between the block header and the block body as an optimization problem, and through continuous iterative adjustments, searches for the node position that minimizes this inconsistency. Once the erroneous node is located, the system repairs it. Repair methods may include recalculating the hash value, correcting erroneous data, or synchronizing correct data from other nodes. After the repair is complete, the consistency check is performed again until the test result is consistent, ensuring the accuracy and reliability of the block data.

[0130] Optionally, the method further comprises the following steps:

[0131] S6001, generates a hash lock based on the cross-chain transaction and generates a cross-chain transaction contract; the cross-chain transaction contract is used to verify the validity of the transaction data and perform atomic swaps.

[0132] A hash lock is an encryption mechanism that leverages the unidirectional nature of hash functions to ensure that only parties with knowledge of a specific key (hash preimage) can unlock and complete a transaction. A cross-chain transaction contract is a smart contract that defines the rules and conditions for cross-chain transactions, including verifying the validity of transaction data and executing atomic swaps. For example, in a cross-chain transaction scenario, the supplier terminal generates a hash lock based on the specific information of the cross-chain transaction and creates a cross-chain transaction contract based on it. Atomic swaps mean that transactions are either completely successful or completely failed, with no intermediate states, thus ensuring the security and reliability of cross-chain transactions.

[0133] S6002: When the cross-chain transaction contract is triggered, the execution result of the cross-chain transaction contract is obtained.

[0134] For example, when the trigger conditions preset in a cross-chain transaction contract are met, the supplier terminal will execute the cross-chain transaction contract. During execution, the contract verifies the validity of the transaction data, specifically checking the identities of both parties, the sufficiency of asset balances, and compliance with the transaction rules. Simultaneously, the contract attempts to perform an atomic swap, transferring assets from one blockchain to another. Upon completion, the supplier terminal receives an execution result indicating whether the transaction successfully met the contract requirements.

[0135] S6003: If the execution result satisfies the cross-chain transaction contract, the transaction completion result is obtained.

[0136] For example, if the cross-chain transaction contract's execution result satisfies the contractual conditions, indicating that both parties have fulfilled their respective obligations as specified in the contract, the atomic swap has been successfully executed. At this point, the supplier's terminal will record the cross-chain transaction as completed, generate a completed transaction result, and update the asset record on the relevant blockchain, indicating that the asset has been successfully transferred from one blockchain to another, and the cross-chain transaction has been successfully completed.

[0137] S6004: If the execution result does not satisfy the cross-chain transaction contract, the transaction rollback result is obtained.

[0138] For example, if the execution result fails to meet the cross-chain transaction contract, it indicates that a problem occurred during the transaction, such as one party failing to fulfill its obligations or invalid transaction data. To ensure transaction security, the supplier's terminal triggers a transaction rollback mechanism. This transaction rollback undoes all executed operations and restores the blockchain state to its pre-transaction state, ensuring that assets are not lost or inconsistent due to transaction failures. This transaction rollback mechanism effectively protects the interests of all parties involved in cross-chain transactions and reduces transaction risks.

[0139] Optionally, the method further comprises the following steps:

[0140] S7001, monitors the load of each node in the blockchain network in real time and obtains the monitoring results.

[0141] For example, the supplier terminal will monitor the load of each node in the blockchain network in real time, including indicators such as CPU usage, memory usage, network bandwidth, and transaction processing volume. By collecting these monitoring data, the supplier terminal can fully understand the operating status of the entire blockchain network, promptly discover potential performance bottlenecks and problem nodes, and provide a basis for subsequent dynamic adjustments.

[0142] S7002, based on the monitoring results, dynamically adjust the node allocation and transfer transactions from high-load nodes to low-load nodes.

[0143] For example, based on monitoring results, the supplier terminal dynamically adjusts node allocation. Specifically, if a node is found to be overloaded, the supplier terminal will transfer some of that node's transactions to a less-loaded node. This dynamic load balancing mechanism effectively prevents performance degradation or crashes of individual nodes due to excessive load, improving the processing capacity and stability of the entire blockchain network and ensuring timely and efficient transaction processing.

[0144] S7003, dynamically optimize sharding strategies based on changes in network load; sharding strategies include merging or splitting shards to adapt to different transaction volumes and load conditions.

[0145] For example, the supplier terminal will dynamically optimize the sharding strategy based on changes in network load. Sharding involves dividing the blockchain network into multiple smaller partitions (shards), each of which can independently process transactions, thereby increasing the throughput of the entire network. Specifically, when network transaction volume increases, the supplier terminal can split a shard into multiple smaller shards to increase parallel processing capabilities; when network transaction volume decreases, the system can merge multiple shards into a larger shard to improve resource utilization. By dynamically adjusting the sharding strategy in this way, the blockchain network can better adapt to different transaction volumes and load conditions and maintain efficient operation.

[0146] The above-mentioned method for tracking and tracing electronic component products in blockchain-based transactions balances the protection of sensitive data with the circulation of non-sensitive data through data classification and differentiated encryption. Data integrity, timing, and network consensus efficiency are ensured by relying on a timestamp Merkel forest structure and an improved asynchronous Byzantine consensus algorithm. A query permission control model is used to implement hierarchical authorization and security verification for data access. Transaction graph construction and the PageRank algorithm are used to analyze transaction network risks. Block data accuracy is ensured through consistency testing and gradient descent algorithm repair. A cross-chain transaction mechanism is used to achieve secure multi-chain asset interaction. Dynamic load balancing and sharding strategy optimization enhance network processing capabilities. This method forms a complete system covering data processing, storage, verification, query, and network optimization, providing the electronic component supply chain with a trusted transaction environment, transparent traceability paths, and risk warning capabilities, while achieving tamper-proof transaction data, controllable permissions, cross-chain interoperability, and adaptive performance.

[0147] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0148] Based on the same inventive concept, the embodiments of the present application also provide a system for tracking and tracing electronic components in blockchain-based transactions, which is used to implement the aforementioned method for tracking and tracing electronic components in blockchain-based transactions. The implementation solution provided by this system is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of one or more embodiments of the system for tracking and tracing electronic components in blockchain-based transactions provided below can be found in the limitations of the method for tracking and tracing electronic components in blockchain-based transactions above, and will not be repeated here.

[0149] In an exemplary embodiment, Figure 3 As shown, a system for tracking and tracing electronic components in transactions based on blockchain is provided, including:

[0150] The transaction data acquisition and classification module 301 is used to obtain the transaction data of electronic components in the transaction, classify the transaction data according to the preset classification model, and obtain sensitive data, non-sensitive data and on-chain contract data;

[0151] Encryption module 302, used to encrypt sensitive data based on a preset encryption algorithm and dynamic obfuscation technology to obtain encrypted data blocks of sensitive data, and generate a structured encrypted data set by combining the encrypted data blocks, non-sensitive data, and on-chain contract data;

[0152] The block header and block body generation module 303 is used to perform hash aggregation processing on the structured encrypted data set based on the timestamp Merkle forest structure to generate the block header and block body;

[0153] The consensus block generation module 304 is used to verify the block header and block body according to the improved asynchronous Byzantine consensus algorithm to generate a consensus block; the consensus block is used to indicate the data consistency in the blockchain network;

[0154] The query and traceability module 305 is used to verify the authority of the query request based on the preset query authority control model when a query request for the consensus block is obtained, and obtain the authority verification result; the authority verification result is used to indicate the consent to query the transaction data to track and trace the transaction data of electronic components.

[0155] Furthermore, the encryption module 302 is further configured to:

[0156] Each data item in the sensitive data is encrypted using the Paillier homomorphic encryption algorithm to generate a set of ciphertext blocks;

[0157] Perform blind obfuscation processing on the ciphertext block set using a random mask to obtain an encrypted data block;

[0158] Integrate encrypted data blocks with non-sensitive data and on-chain contract data to generate structured encrypted data sets.

[0159] Furthermore, the block header and block body generation module 303 is also used to:

[0160] Each transaction data in the structured encrypted data set is processed using a hash function to obtain an aggregated hash tree;

[0161] According to the preset time window, the aggregated hash tree is grouped and processed to construct a timestamp Merkle forest;

[0162] The root hash of the timestamp Merkle forest and the previous block information are packaged to obtain the block header and block body.

[0163] Furthermore, the consensus block generation module 304 is further configured to:

[0164] Based on the following verification conditions, block verification is performed on the block header and block body to obtain the block verification result:

[0165]

[0166] Among them, B j For nodes, Vote(B j ) is B j The verification result of , Block is the generated block, and Verify(·) is the verification function used to check the continuity and data integrity of the block hash and the previous block hash;

[0167] Based on the block verification result, according to the preset confirmation conditions, the block confirmation result is obtained; the confirmation conditions are expressed by the following formula:

[0168]

[0169] Among them, Vote(B j) is B j Verification results, f is the maximum number of fault-tolerant nodes, n is the total number of nodes;

[0170] Generate a consensus block based on the block confirmation results.

[0171] Furthermore, the query permission control model includes:

[0172] The distributed threshold signature module is used to obtain query requests and obtain authorization results after the number of authorized signatures reaches a preset number of authorized signatures. The authorization results are used to decrypt sensitive data. The query request meets the following conditions:

[0173]

[0174] Among them, Q is the query request, n is the total number of authorized parties, t is the minimum number of signatures required for decryption, Sign j (Q) is the signature of the query request by the jth authorized party;

[0175] The zero-knowledge range proof module is used to verify whether the transaction amount in the transaction data is within the legal range and obtain the legitimacy verification result;

[0176] The Merkle forest path verification module is used to verify whether the transaction timestamp in the transaction data exists in the Merkle forest of the blockchain and obtain the existence result;

[0177] The permission verification result module is used to generate permission verification results based on the authorization results, legitimacy verification results and existence results.

[0178] Furthermore, the query tracing module 305 includes:

[0179] A transaction graph construction unit, used to construct a transaction graph based on the permission verification results;

[0180] The PageRank value calculation module is used to analyze and process the transaction graph according to the PageRank algorithm and calculate the PageRank value. The PageRank value is obtained using the following formula:

[0181]

[0182] Where PR(v) is the PageRank value of node v, d is the damping coefficient, which indicates the probability of users continuing to browse randomly, L(u) is the number of outbound links of the node, which is used to reflect the fund distribution ability, N is the total number of nodes in the transaction graph, and In(v) is the set of nodes adjacent to node v.

[0183] The anomaly detection unit is used to perform threshold judgment processing on the PageRank value according to a preset anomaly threshold and generate an anomaly detection result; the anomaly detection result is used to indicate that there is a potential risk in the transaction of electronic components.

[0184] Furthermore, the block header and block body generation module 303 is also used to:

[0185] Perform consistency check on the block header and block body to obtain the test results;

[0186] When the detection result is inconsistent, the node position of the data is located based on the gradient descent algorithm, and the node position of the data is repaired to obtain the repair result.

[0187] Furthermore, the system also includes:

[0188] The cross-chain transaction contract module is used to generate a hash lock based on the cross-chain transaction and generate a cross-chain transaction contract; the cross-chain transaction contract is used to verify the validity of the transaction data and perform atomic swaps;

[0189] The contract execution module is used to obtain the execution result of the cross-chain transaction contract when the cross-chain transaction contract is triggered;

[0190] The transaction completion module is used to obtain the transaction completion result if the execution result satisfies the cross-chain transaction contract;

[0191] The transaction rollback module is used to obtain the transaction rollback result if the execution result does not meet the cross-chain transaction contract.

[0192] Furthermore, the system also includes:

[0193] The load monitoring module is used to monitor the load of each node in the blockchain network in real time and obtain monitoring results;

[0194] Dynamic node allocation module, used to dynamically adjust node allocation based on monitoring results, transferring transactions from high-load nodes to low-load nodes;

[0195] The sharding strategy optimization module is used to dynamically optimize the sharding strategy according to changes in network load; the sharding strategy includes merging or splitting shards to adapt to different transaction volumes and load conditions.

[0196] In one embodiment, Figure 4 A computer device 400 is provided, comprising:

[0197] at least one processor 401;

[0198] and a memory 402 communicatively connected to at least one of the processors 401;

[0199] The memory stores application code that can be executed by at least one of the processors, and the application code is executed by at least one of the processors so that at least one of the processors can perform the steps of the method for tracking and tracing electronic components in blockchain-based transactions as described above.

[0200] The computer device may further include a transceiver 403 .

[0201] The processor 401, the memory 402 and the transceiver 403 may be connected via a bus 404 or other means. In the figure, the bus 404 is used as an example. Figure 4 Only one thick line is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0202] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0203] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the components described as separate parts may or may not be physically separated, and the parts displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the disclosed solution. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0204] The above-described embodiments merely represent several implementation methods of the embodiments of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the patent application. It should be noted that a person skilled in the art may make various modifications and improvements without departing from the concept of the embodiments of the present application, and these modifications and improvements fall within the scope of protection of the embodiments of the present application.

Claims

1. A method for tracking the origin of electronic components in transactions based on blockchain, characterized in that: The method comprises: Obtain transaction data of electronic components in the transaction, classify the transaction data according to a preset classification model, and obtain sensitive data, non-sensitive data, and on-chain contract data; Encrypt the sensitive data based on a preset encryption algorithm and dynamic obfuscation technology to obtain an encrypted data block of the sensitive data, and generate a structured encrypted data set by combining the encrypted data block, non-sensitive data, and on-chain contract data; Based on the timestamp Merkle forest structure, hash aggregation processing is performed on the structured encrypted data set to generate a block header and a block body; The block header and block body are verified according to an improved asynchronous Byzantine consensus algorithm to generate a consensus block; the consensus block is used to indicate data consistency in the blockchain network; When a query request for the consensus block is obtained, the query request is verified based on a preset query authority control model to obtain an authority verification result; the authority verification result is used to indicate consent to query the transaction data to track and trace the transaction data of the electronic components.

2. The method according to claim 1, characterized in that The sensitive data is encrypted based on a preset encryption algorithm and dynamic obfuscation technology to obtain an encrypted data block of the sensitive data, and the encrypted data block, non-sensitive data and on-chain contract data are combined to generate a structured encrypted data set, including: Encrypting each data item in the sensitive data using the Paillier homomorphic encryption algorithm to generate a ciphertext block set; Performing blind obfuscation processing on the ciphertext block set using a random mask to obtain an encrypted data block; The encrypted data block is integrated with non-sensitive data and on-chain contract data to generate a structured encrypted data set.

3. The method according to claim 1, characterized in that The method of performing hash aggregation processing on the structured encrypted data set based on the timestamp Merkle forest structure to generate a block header and a block body includes: Processing each transaction data in the structured encrypted data set using a hash function to obtain an aggregated hash tree; Grouping the aggregated hash tree according to a preset time window to construct a timestamp Merkle forest; The root hash of the timestamp Merkle forest and the previous block information are packaged to obtain a block header and a block body.

4. The method according to claim 1, wherein The block header and block body are verified according to the improved asynchronous Byzantine consensus algorithm to generate a consensus block, including: Based on the following verification conditions, block verification is performed on the block header and block body to obtain a block verification result: Among them, B j For nodes, Vote(B j ) is B j The verification result of , Block is the generated block, and Verify(·) is the verification function used to check the continuity and data integrity of the block hash and the previous block hash; Based on the block verification result, according to the preset confirmation conditions, a block confirmation result is obtained; the confirmation conditions are expressed by the following formula: Among them, Vote(B j ) is B j Verification results, f is the maximum number of fault-tolerant nodes, n is the total number of nodes; According to the block confirmation results, a consensus block is generated.

5. The method according to claim 1, wherein The query authority control model includes: The distributed threshold signature module is used to obtain a query request and obtain an authorization result after the number of authorized party signatures reaches a preset number of authorized party signatures; the authorization result is used to decrypt the sensitive data; the query request meets the following conditions: Among them, Q is the query request, n is the total number of authorized parties, t is the minimum number of signatures required for decryption, Sign j (Q) is the signature of the query request by the jth authorized party; A zero-knowledge range proof module is used to verify whether the transaction amount in the transaction data is within a legal range and obtain a legality verification result; A Merkle forest path verification module is used to verify whether the transaction timestamp in the transaction data exists in the Merkle forest of the blockchain and obtain an existence result; The authority verification result module is used to generate an authority verification result based on the authorization result, the legitimacy verification result and the existence result.

6. The method according to claim 1, characterized in that When a query request for the consensus block is obtained, the query request is subjected to permission verification based on a preset query permission control model. After obtaining the permission verification result, the following steps are further included: Building a transaction graph based on the permission verification result; The transaction graph is analyzed and processed according to the PageRank algorithm to calculate the PageRank value; the PageRank value is obtained using the following formula: Where PR(v) is the PageRank value of node v, d is the damping coefficient, which indicates the probability of users continuing to browse randomly, L(u) is the number of outbound links of the node, which is used to reflect the fund distribution ability, N is the total number of nodes in the transaction graph, and In(v) is the set of nodes adjacent to node v. According to a preset abnormality threshold, the PageRank value is subjected to a threshold judgment process to generate an abnormality detection result; the abnormality detection result is used to indicate that there is a potential risk in the transaction of the electronic component.

7. The method according to claim 1, characterized in that After performing hash aggregation processing on the structured encrypted data set based on the timestamp Merkle forest structure to generate a block header and a block body, the method further includes: Performing consistency testing on the block header and block body to obtain a test result; When the detection result is inconsistent, the node position of the data is located based on the gradient descent algorithm, and the node position of the data is repaired to obtain a repair result.

8. The method according to claim 1, characterized in that Also includes: Generate a hash lock based on the cross-chain transaction and generate a cross-chain transaction contract; the cross-chain transaction contract is used to verify the validity of the transaction data and perform atomic swaps; When the cross-chain transaction contract is triggered, the execution result of the cross-chain transaction contract is obtained; If the execution result satisfies the cross-chain transaction contract, the transaction result is completed; If the execution result does not satisfy the cross-chain transaction contract, the transaction rollback result is obtained.

9. The method according to claim 1, characterized in that Also includes: Monitor the load of each node in the blockchain network in real time and obtain monitoring results; Based on the monitoring results, dynamically adjust the node allocation and transfer transactions from high-load nodes to low-load nodes; Dynamically optimize sharding strategies based on changes in network load; the sharding strategies include merging or splitting shards to accommodate different transaction volumes and load conditions.

Images