Cross-platform block chain credible authentication method

Abstract

The invention relates to the technical field of block chains, and discloses a cross-platform block chain credible authentication method, which comprises the following steps: acquiring application information of a block chain platform participating in cross-chain authentication and checking, and completing access authentication on the block chain platform passing the checking; the participant node sends a cross-chain request to the authenticated block chain platform, preliminarily verifies the cross-chain request, and sends a cross-platform trusted authentication request after the verification is passed; carrying out multi-dimensional authentication on the cross-platform credible authentication request, generating an authentication report, synchronizing the authentication report to a target platform, carrying out verification, and carrying out cross-chain interaction after the verification is passed; a cross-chain interaction data packet is generated according to a preset feedback node, a real-time interaction coefficient is calculated, and whether an early warning instruction is generated or not is judged according to the real-time interaction coefficient, so that dynamic monitoring and risk early warning of the cross-chain interaction process are realized, and a data island between heterogeneous block chain platforms is effectively broken. And safe and credible technical support is provided for cross-platform collaboration in the fields of bid inviting, purchasing and the like.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and in particular to a cross-platform blockchain trusted authentication method. Background Technology

[0002] With the rapid development of blockchain technology, it has been widely applied in various fields such as finance, government affairs, and bidding and procurement. Currently, different industries and institutions have built their own independent blockchain platforms based on their own business needs, forming a large number of "data silos." These blockchain platforms exhibit significant heterogeneity in consensus algorithms, ledger structures, encryption mechanisms, and data formats, making it impossible for platforms to achieve effective interconnection and trusted data sharing. In cross-platform blockchain application scenarios, especially in fields such as bidding and procurement where data credibility and business compliance requirements are extremely high, this heterogeneity not only hinders efficient collaboration between platforms but also brings security risks and trust crises in data interaction. Therefore, there is an urgent need for a cross-platform blockchain trusted authentication method that can support secure, reliable, and efficient interconnection between different heterogeneous blockchain platforms, addressing the current blockchain "data silo" problem and improving the credibility and security of cross-chain interactions. Summary of the Invention

[0003] To address the aforementioned technical challenges, this application provides a cross-platform blockchain trusted authentication method. By constructing a cross-platform blockchain consortium architecture, it rigorously reviews and authenticates the application information of the connected blockchain platforms. When initiating a cross-chain request, a multi-layered verification mechanism generates a detailed authentication report and performs secondary verification on the target platform, ensuring the consistency and credibility of information between the two parties in the cross-chain interaction. Through the calculation of real-time interaction coefficients and the generation of early warning commands, it achieves dynamic monitoring and risk warning of the cross-chain interaction process, effectively breaking down the "data silos" between heterogeneous blockchain platforms and providing secure and reliable technical support for cross-platform collaboration in fields such as bidding and procurement.

[0004] In some embodiments of this application, a cross-platform blockchain trusted authentication method is provided, applied to a cross-platform blockchain consortium architecture, including:

[0005] Obtain application information from blockchain platforms participating in cross-chain certification, review the application information, and complete access certification for blockchain platforms that pass the review;

[0006] Participating nodes send cross-chain requests to the certified blockchain platform, perform preliminary verification of the cross-chain requests, and send cross-platform trusted authentication requests after the verification is successful.

[0007] Perform multi-dimensional authentication on cross-platform trusted authentication requests, generate authentication reports, synchronize the authentication reports to the target platform for verification, and perform cross-chain interaction after successful verification;

[0008] Generate cross-chain interaction data packets according to preset feedback nodes, calculate real-time interaction coefficients, and determine whether to generate warning instructions based on real-time interaction coefficients.

[0009] In some embodiments of this application, the cross-platform blockchain consortium architecture includes a consortium management node and several heterogeneous member blockchain platform primary participant nodes;

[0010] The member blockchain platform includes an independent blockchain built by the parties involved in the bidding and procurement process;

[0011] The participating nodes include bidding nodes, tendering nodes, regulatory nodes, and financial nodes.

[0012] In some embodiments of this application, the application information is reviewed, and access authentication is completed for blockchain platforms that pass the review, including:

[0013] The application information includes platform identifier, consensus algorithm type, encryption mechanism parameters, node list, and business scope;

[0014] The alliance management node reviews the application information of each blockchain platform. The review includes verifying the uniqueness of the platform identifier, assessing the compatibility of the consensus algorithm type with the alliance architecture, verifying the security of the encryption mechanism parameters, verifying the authenticity of the node identity in the node list, and detecting the matching degree between the business scope and the alliance admission rules.

[0015] Generate a quantitative value for the review result of each reviewed item, and perform weighted summation to obtain a comprehensive quantitative value;

[0016] Pre-set the threshold for the comprehensive quantification value;

[0017] If the comprehensive quantitative value is greater than the comprehensive quantitative value threshold, the review is deemed successful, a unique alliance identifier is assigned to the blockchain platform, and an access key pair based on an asymmetric encryption algorithm is generated to complete the access authentication.

[0018] If the overall quantitative value is not greater than the overall quantitative value threshold, the review is deemed unsuccessful.

[0019] In some embodiments of this application, a preliminary verification of the cross-chain request is performed, and after successful verification, a cross-platform trusted authentication request is sent, including:

[0020] The cross-chain request includes the target platform identifier, the interaction data digest, the business type, and the authentication requirements.

[0021] The initial verification of cross-chain requests includes: verifying whether the target platform identifier is a blockchain platform identifier that has completed access authentication; verifying whether the format of the interaction data digest conforms to the hash algorithm specification preset by the consortium; verifying whether the business type is within the scope of cross-chain business allowed by the consortium; and verifying whether the authentication requirements match the authentication capabilities supported by the target platform.

[0022] If the above preliminary verifications all pass, the blockchain platform where the participating node is located will generate a cross-platform trusted authentication request and send the encrypted request to the consortium management node.

[0023] If any preliminary verification fails, a rejection request is returned to the participating nodes.

[0024] In some embodiments of this application, multi-dimensional authentication is performed on cross-platform trusted authentication requests, and an authentication report is generated, including:

[0025] The multi-dimensional authentication includes identity authentication, data authentication, and business authentication;

[0026] The identity authentication adopts a dual authentication mechanism, which compares the access key with the platform public key library pre-stored at the alliance management node, and compares the digital certificate of the participating node with the digital certificate of the participating node pre-stored at the alliance management node. An identity authentication score is generated based on the comparison results.

[0027] The data authentication process involves a hierarchical comparison between the interactive data digest in the cross-chain request and the original data hash value on the blockchain platform of the initiating member, while also introducing timestamp verification. A data authentication score is generated based on the comparison and verification results.

[0028] The business authentication process calls the corresponding business rule base based on the business type in the cross-chain request, performs multi-dimensional verification of the business qualifications, business operation permissions, and historical business performance records of the participating nodes, and generates a business authentication score based on the verification results.

[0029] A weighted summation algorithm is used to process the identity authentication score, data authentication score, and business authentication score according to preset weights to obtain a comprehensive authentication score.

[0030] When the overall authentication score is greater than the preset authentication score threshold, an authentication report is generated. The authentication report includes authentication process logs, details of authentication results in each dimension, timestamps, and signatures of the consortium blockchain management node.

[0031] In some embodiments of this application, the authentication report is synchronized to the target platform and verified. After successful verification, cross-chain interaction is performed, including:

[0032] The generated unified authentication report is encapsulated according to the data format and encryption standard specified by the target platform, and the encapsulated unified authentication report is pushed to the authentication interface of the target platform through the cross-chain communication protocol;

[0033] After receiving the report, the target platform activates its built-in verification module to parse and verify the report content. The verification process includes:

[0034] The signature of the consortium blockchain management node in the report is matched and verified with the pre-stored public key of the management node by calling a preset signature verification algorithm.

[0035] The timestamp in the unified authentication report is verified a second time to obtain its time deviation from the local time of the target platform, and the timestamp format is checked to see if it conforms to the alliance's unified standard.

[0036] Compare whether the calculation logic of identity authentication score, data authentication score and business authentication score is consistent with the preset rules, and focus on verifying the three-level traceability comparison process records of the difference fields in the hierarchical comparison and the key indicator data in the business qualification verification.

[0037] Perform integrity verification on the authentication process logs to check whether they contain information on key nodes throughout the entire process, from the initiation of the cross-chain request to the generation of the comprehensive authentication score.

[0038] If all the above verifications pass, the target platform generates a verification pass receipt and returns it to the alliance management node, triggering the cross-chain interaction process;

[0039] If any verification fails, the cross-chain request will be rejected and a verification failure report will be generated and simultaneously fed back to the initiating node and the alliance management node.

[0040] In some embodiments of this application, the method further includes setting a time interval for a preset feedback time node, specifically;

[0041] Obtain historical cross-chain interaction data packets from each member's blockchain platform;

[0042] Based on several preset interaction evaluation indicators, historical cross-chain interaction data packets are evaluated and analyzed to obtain the historical evaluation value of each preset interaction evaluation indicator.

[0043] The historical evaluation values ​​of all preset interactive evaluation indicators are weighted and summed to obtain the historical comprehensive evaluation value of the corresponding member blockchain platform.

[0044] The time interval for preset feedback time nodes is set based on historical comprehensive evaluation values.

[0045] In some embodiments of this application, cross-chain interaction data packets are generated according to preset feedback nodes, and real-time interaction coefficients are generated, including:

[0046] The cross-chain interaction data packet includes an interaction process log, data transmission record, authentication report summary, and target platform response result;

[0047] According to the preset time interval of the feedback nodes, the cross-chain interaction data related to the participating nodes within that time interval is extracted from the consortium blockchain evidence storage module, and the data is structured to generate a cross-chain interaction data packet.

[0048] Based on cross-chain interactive data packets, real-time authentication pass coefficient, data transmission latency coefficient, interactive data integrity coefficient, business rule compliance coefficient, and exception handling timeliness coefficient are generated, and then weighted and summed to obtain the real-time interaction coefficient.

[0049] In some embodiments of this application, determining whether to generate a warning instruction based on a real-time interaction coefficient includes:

[0050] Calculate the absolute value of the difference between the real-time interaction coefficients at adjacent preset feedback time nodes, and generate the fluctuation coefficient of the real-time interaction coefficient at the current preset feedback time node based on the absolute value of the difference.

[0051] Whether to generate an early warning instruction is determined based on the fluctuation coefficient and the real-time interaction coefficient.

[0052] When the fluctuation coefficient is greater than the preset fluctuation threshold, or the current real-time interaction coefficient is less than the preset interaction coefficient threshold, the interaction status is determined to be abnormal, and an early warning command is generated.

[0053] In some embodiments of this application, before synchronizing the authentication report to the target platform and performing verification, the following steps are also included:

[0054] The improved PBFT consensus mechanism of the consortium blockchain is used to complete node confirmation. After confirmation, a consensus certificate is generated and embedded in the authentication report.

[0055] The improved PBFT consensus mechanism of the consortium blockchain adjusts the weight of consensus nodes through a dynamic weight allocation mechanism, the number of nodes in the member blockchain platform, and historical interaction coefficients.

[0056] The authentication report and consensus certificate are encrypted using the national cryptographic SM4 algorithm and synchronized to the target platform through a preset cross-chain secure communication channel. The encrypted authentication report, consensus certificate and decryption key are then fed back to the blockchain platform of the initiating member and the participating node.

[0057] The cross-platform blockchain trusted authentication method of this application embodiment has the following advantages compared with the prior art:

[0058] By constructing a cross-platform blockchain alliance architecture, the application information of the connected blockchain platforms is strictly reviewed and certified. When a cross-chain request is initiated, a multi-level verification mechanism is used to generate a detailed certification report and perform secondary verification on the target platform to ensure the consistency and credibility of information between the two parties in the cross-chain interaction. Through the calculation of real-time interaction coefficients and the generation of early warning instructions, dynamic monitoring and risk warning of the cross-chain interaction process are achieved, effectively breaking down the "data silos" between heterogeneous blockchain platforms and providing secure and reliable technical support for cross-platform collaboration in fields such as bidding and procurement. Attached Figure Description

[0059] Figure 1 This is a flowchart illustrating a cross-platform blockchain trusted authentication method in an embodiment of this application. Detailed Implementation

[0060] The specific embodiments of this application will be described in further detail below with reference to the accompanying drawings and examples. The following examples are used to illustrate this application, but are not intended to limit the scope of this application.

[0061] In the description of this application, it should be understood that the terms "center", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0062] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0063] In the description of this application, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0064] like Figure 1 As shown in the figure, a cross-platform blockchain trusted authentication method according to an embodiment of this application is applied to a cross-platform blockchain consortium architecture, including:

[0065] S101: Obtain the application information of blockchain platforms participating in cross-chain certification, review the application information, and complete the access certification for blockchain platforms that pass the review;

[0066] S102: Participating nodes send cross-chain requests to the certified blockchain platform, perform preliminary verification of the cross-chain requests, and send cross-platform trusted authentication requests after the verification is passed.

[0067] S103: Perform multi-dimensional authentication on cross-platform trusted authentication requests, generate an authentication report, synchronize the authentication report to the target platform and verify it, and perform cross-chain interaction after successful verification;

[0068] S104: Generate cross-chain interaction data packets according to preset feedback nodes, calculate real-time interaction coefficients, and determine whether to generate warning instructions based on real-time interaction coefficients.

[0069] In some embodiments of this application, the cross-platform blockchain consortium architecture includes a consortium management node and several heterogeneous member blockchain platform primary participant nodes;

[0070] The member blockchain platform includes an independent blockchain built by the parties involved in the bidding and procurement process;

[0071] The participating nodes include bidding nodes, tendering nodes, regulatory nodes, and financial nodes.

[0072] In this embodiment, the alliance management node is responsible for the overall rule formulation, member management, certification process coordination, and cross-chain interaction monitoring of the alliance architecture.

[0073] In this embodiment, the heterogeneous member blockchain platform is the main component of the alliance. Each member platform is independently built by specific participants in the bidding and procurement field (such as the bidding department of a large enterprise group, professional bidding agency, etc.) according to their own business needs, retaining the original blockchain technical characteristics and business data, while achieving interconnection and interoperability with other member platforms through alliance access authentication.

[0074] In this embodiment, the participating nodes are the operational entities that actually conduct bidding and procurement business interactions. Among them, the bidding node is responsible for initiating operations such as putting bidding project information on the blockchain, publishing bidding documents, and publicizing the winning bid results; the bidding node can submit key data such as the hash value of the bid document and qualification certificates to its respective blockchain platform and participate in cross-chain bidding activities; the regulatory node is deployed by the government bidding and tendering supervision and management department or a third-party professional regulatory agency, which can obtain bidding and procurement business data of each member blockchain platform in real time, and supervise key links such as bid opening and bid evaluation to ensure the compliance of the bidding process; the financial node connects to financial institutions such as banks and insurance companies to provide financial service support for bidding and procurement activities, such as deposit custody, performance bond issuance, and online payment settlement. Through cross-chain authentication, it realizes closed-loop management of fund flow and business flow. Each participating node connects to the alliance through its respective member blockchain platform, and its business operations must follow the alliance's unified cross-chain interaction specifications and security protocols.

[0075] In this embodiment, by constructing a cross-platform blockchain alliance architecture, it is possible to effectively integrate the scattered blockchain resources in the field of bidding and procurement, while preserving the technical autonomy and business independence of each member platform, and realizing trusted data circulation and business collaboration between heterogeneous platforms through a unified access authentication mechanism and cross-chain interaction rules.

[0076] In some embodiments of this application, the application information is reviewed, and access authentication is completed for blockchain platforms that pass the review, including:

[0077] The application information includes platform identifier, consensus algorithm type, encryption mechanism parameters, node list, and business scope;

[0078] The alliance management node reviews the application information of each blockchain platform. The review includes verifying the uniqueness of the platform identifier, assessing the compatibility of the consensus algorithm type with the alliance architecture, verifying the security of the encryption mechanism parameters, verifying the authenticity of the node identity in the node list, and detecting the matching degree between the business scope and the alliance admission rules.

[0079] Generate a quantitative value for the review result of each reviewed item, and perform weighted summation to obtain a comprehensive quantitative value;

[0080] Pre-set the threshold for the comprehensive quantification value;

[0081] If the comprehensive quantitative value is greater than the comprehensive quantitative value threshold, the review is deemed successful, a unique alliance identifier is assigned to the blockchain platform, and an access key pair based on an asymmetric encryption algorithm is generated to complete the access authentication.

[0082] If the overall quantitative value is not greater than the overall quantitative value threshold, the review is deemed unsuccessful.

[0083] In this embodiment, the quantitative value of the review results is set using a percentage-based scoring standard. The platform identifier uniqueness verification is worth 20 points. If the applicant platform identifier is completely duplicated with an existing identifier within the alliance, it receives 0 points. If some characters are similar but can be corrected by adding a distinguishing identifier, it receives 10-15 points. If there are no duplicates and it conforms to the alliance's naming conventions, it receives 20 points. The consensus algorithm compatibility assessment is worth 25 points. It uses the alliance's preset algorithm compatibility matrix for matching. Complete compatibility with mainstream consortium blockchain consensus algorithms (such as PBFT, RAFT) receives 25 points. If there are some compatibility adaptation requirements but they are technically feasible, it receives 15-20 points. If it uses a non-mainstream algorithm not supported by the alliance and is extremely difficult to adapt, it receives 0-10 points. The encryption mechanism parameter security verification is worth 25 points. It verifies the hash algorithm (such as SHA-256, SM3), symmetric encryption algorithm (such as AES-256, SM4), and key length used by the applicant platform. The security baseline requirements for all nodes are fully met, scoring 25 points. Individual parameters that are not up to standard but can be improved through upgrades receive 10-20 points. Core encryption parameters with significant security vulnerabilities that cannot be rectified in the short term receive 0-5 points. The node list identity verification is worth 15 points. Verification of the node operator's identity is conducted through the enterprise credit system and business registration information database. All node identity information is authentic and traceable, receiving 15 points. Individual nodes with ambiguous identity information but for which supplementary materials can be provided receive 5-10 points. Forged node identity information receives 0 points. The business scope matching test is worth 15 points. The application platform's business scope description is semantically matched with the core business areas of bidding and procurement in the alliance's access rules. A matching degree ≥90% receives 15 points. A matching degree between 60% and 90% that includes core business modules receives 8-12 points. A matching degree <60% or missing core business modules receives 0-5 points.

[0084] In this embodiment, the comprehensive quantitative value threshold is set to 75 points. When the quantitative values ​​of each review content are weighted and summed according to the above weights (platform identifier 20%, consensus algorithm 25%, encryption mechanism 25%, node identity 15%, business scope 15%), the total score is determined to be approved if it exceeds 75 points.

[0085] In this embodiment, by conducting multi-dimensional and rigorous audits of the blockchain platform for access authentication, it is ensured that the member platforms joining the alliance meet the alliance's unified standards in terms of technical security, business compliance, and identity authenticity, thus laying a trustworthy foundation for subsequent cross-chain interactions.

[0086] In some embodiments of this application, a preliminary verification of the cross-chain request is performed, and after successful verification, a cross-platform trusted authentication request is sent, including:

[0087] The cross-chain request includes the target platform identifier, the interaction data digest, the business type, and the authentication requirements.

[0088] The initial verification of cross-chain requests includes: verifying whether the target platform identifier is a blockchain platform identifier that has completed access authentication; verifying whether the format of the interaction data digest conforms to the hash algorithm specification preset by the consortium; verifying whether the business type is within the scope of cross-chain business allowed by the consortium; and verifying whether the authentication requirements match the authentication capabilities supported by the target platform.

[0089] If the above preliminary verifications all pass, the blockchain platform where the participating node is located will generate a cross-platform trusted authentication request and send the encrypted request to the consortium management node.

[0090] If any preliminary verification fails, a rejection request is returned to the participating nodes.

[0091] In this embodiment, preliminary verification of cross-chain requests can filter out invalid requests, illegal targets, and non-compliant data in the early stages of cross-chain interaction, effectively reducing the authentication load of consortium management nodes and improving the overall efficiency and security of cross-chain interaction.

[0092] In some embodiments of this application, multi-dimensional authentication is performed on cross-platform trusted authentication requests, and an authentication report is generated, including:

[0093] The multi-dimensional authentication includes identity authentication, data authentication, and business authentication;

[0094] The identity authentication adopts a dual authentication mechanism, which compares the access key with the platform public key library pre-stored at the alliance management node, and compares the digital certificate of the participating node with the digital certificate of the participating node pre-stored at the alliance management node. An identity authentication score is generated based on the comparison results.

[0095] The data authentication process involves a hierarchical comparison between the interactive data digest in the cross-chain request and the original data hash value on the blockchain platform of the initiating member, while also introducing timestamp verification. A data authentication score is generated based on the comparison and verification results.

[0096] The business authentication process calls the corresponding business rule base based on the business type in the cross-chain request, performs multi-dimensional verification of the business qualifications, business operation permissions, and historical business performance records of the participating nodes, and generates a business authentication score based on the verification results.

[0097] A weighted summation algorithm is used to process the identity authentication score, data authentication score, and business authentication score according to preset weights to obtain a comprehensive authentication score.

[0098] When the overall authentication score is greater than the preset authentication score threshold, an authentication report is generated. The authentication report includes authentication process logs, details of authentication results in each dimension, timestamps, and signatures of the consortium blockchain management node.

[0099] In this embodiment, the identity authentication score is based on a 100-point scale. The comparison between the access key and the platform's public key library accounts for 60%. If the key matches perfectly and is within its validity period, it scores 60 points. If the key matches but is close to its expiration date (less than 7 days remaining), it scores 40-50 points. If the key does not match or has expired, it scores 0 points. The comparison of the participating node's digital certificate accounts for 40%. If the certificate information (including node identity identifier, certificate authority, and validity period) is completely consistent with the pre-stored record, it scores 40 points. If there are minor differences in the certificate information but it can be verified through the certificate chain, it scores 20-30 points. If the certificate is invalid or forged, it scores 0 points.

[0100] In this embodiment, the data authentication score is also based on a percentage system. The hierarchical comparison between the interactive data digest and the original data hash value includes a basic layer (data format verification), a digest layer (hash value consistency verification), and an association layer (association with historical business data verification), accounting for 30%, 50%, and 20% respectively. A passing basic layer verification earns 30 points, a consistent digest layer verification earns 50 points, and an association layer verification that conforms to business logic earns 20 points. If any layer of verification fails, the corresponding points are deducted. Timestamp verification is a bonus item. If the timestamp is within the time error range allowed by the alliance (±30 seconds), an additional 5 points are added. If it exceeds the error range but can be calibrated through a trusted time source, 2 points are added. If it cannot be calibrated, 0 points are added.

[0101] In this embodiment, the business authentication score adopts dynamic weighting according to the differences in business type. For information exchange business of bidding projects, business qualification verification accounts for 40%, operation permission verification accounts for 30%, and historical performance record accounts for 30%. For tender document submission business, business qualification verification accounts for 50%, operation permission verification accounts for 20%, and historical performance record accounts for 30%. If each verification is passed, a score is awarded according to the weight; if it is not passed, a score is deducted according to the actual degree of compliance, with a maximum of 100 points.

[0102] In this embodiment, business qualification verification includes checking the validity period of the business license and the coverage of the business scope of the participating node; business operation permission verification includes verifying whether the participating node has the permission level to initiate cross-chain requests for the current business type; and historical business performance record verification includes statistically analyzing the business performance success rate, number of abnormal performances, and processing time of the participating node in the past 6 months.

[0103] In this embodiment, the hierarchical comparison is as follows: First, a first-level full comparison is performed between the interactive data digest and the original data hash value. If the first-level comparison is consistent, a data consistency pass conclusion is directly generated. If there is a difference in the first-level comparison, the difference fields are extracted for a second-level field-level comparison. For the inconsistent fields in the second-level comparison, a third-level source tracing comparison is further performed in combination with the data generation time and modification records. The cause of the data difference is determined based on the results of the third-level comparison.

[0104] In this embodiment, timestamp verification includes verifying whether the time difference between the timestamp generated by the interactive data digest and the timestamp of the original data being uploaded to the blockchain is within a preset time threshold, and verifying whether the timestamp format conforms to the consortium's unified UTC time standard.

[0105] In this embodiment, the preset authentication score threshold is set to 85 points. The comprehensive authentication score is calculated as follows: identity authentication score × 30% + data authentication score × 40% + business authentication score × 30%. An authentication report is generated when the total score exceeds 85 points. The authentication process log in the report records in detail the operation time, execution node and result status of each step from receiving the cross-chain request to completing the authentication of each dimension, ensuring that the authentication process is auditable and traceable.

[0106] In this embodiment, by generating an authentication report, the process and results of multi-dimensional authentication can be solidified in a standardized and verifiable form, providing authoritative proof of the legality and credibility of cross-chain interaction. After the authentication report is synchronized to the target platform, the target platform can quickly reproduce the authentication process and verify its compliance based on the authentication process log and the details of the results in each dimension in the report, without having to repeat the complex multi-dimensional authentication operations, thereby greatly improving the efficiency of cross-chain interaction.

[0107] In some embodiments of this application, the authentication report is synchronized to the target platform and verified. After successful verification, cross-chain interaction is performed, including:

[0108] The generated unified authentication report is encapsulated according to the data format and encryption standard specified by the target platform, and the encapsulated unified authentication report is pushed to the authentication interface of the target platform through the cross-chain communication protocol;

[0109] After receiving the report, the target platform activates its built-in verification module to parse and verify the report content. The verification process includes:

[0110] The signature of the consortium blockchain management node in the report is matched and verified with the pre-stored public key of the management node by calling a preset signature verification algorithm.

[0111] The timestamp in the unified authentication report is verified a second time to obtain its time deviation from the local time of the target platform, and the timestamp format is checked to see if it conforms to the alliance's unified standard.

[0112] Compare whether the calculation logic of identity authentication score, data authentication score and business authentication score is consistent with the preset rules, and focus on verifying the three-level traceability comparison process records of the difference fields in the hierarchical comparison and the key indicator data in the business qualification verification.

[0113] Perform integrity verification on the authentication process logs to check whether they contain information on key nodes throughout the entire process, from the initiation of the cross-chain request to the generation of the comprehensive authentication score.

[0114] If all the above verifications pass, the target platform generates a verification pass receipt and returns it to the alliance management node, triggering the cross-chain interaction process;

[0115] If any verification fails, the cross-chain request will be rejected and a verification failure report will be generated and simultaneously fed back to the initiating node and the alliance management node.

[0116] In this embodiment, synchronizing and verifying the authentication report to the target platform ensures that the target platform has a consistent understanding of the trusted foundation for cross-chain interaction. Specifically, when the target platform receives the encapsulated authentication report, its verification module first verifies the signature of the consortium blockchain management node using an asymmetric encryption algorithm. If the signature verification fails (e.g., the signature value does not match the public key decryption result or the signature has expired), the report is directly deemed invalid and the verification process is terminated. If the signature verification passes, a secondary verification of the timestamp is performed. If the time deviation exceeds ±30 seconds and cannot be calibrated by a trusted time source (e.g., the time synchronization error between the target platform and the consortium management node's NTP server exceeds a threshold), verification is also suspended, and a time calibration request is initiated to the consortium management node. For the layered comparison difference fields in the certification report, the target platform will retrieve its own stored historical business data to reproduce the three-level traceability comparison process. If it finds that the initiating platform has data tampering traces (such as the modification record contradicting the on-chain timestamp), it will mark the anomaly as high risk and refuse interaction. The target platform will also pay close attention to key indicators in the business qualification verification (such as the remaining validity period of the business license of the participating node is less than 30 days) and determine whether to accept cross-chain requests from such nodes in combination with its own business rules to ensure the sustainability and security of business cooperation.

[0117] In this embodiment, multi-dimensional verification by the target platform can effectively avoid the interaction risks caused by tampering or parsing errors during the transmission of the authentication report, further consolidating the trusted interaction foundation of the cross-platform blockchain alliance.

[0118] In some embodiments of this application, a time interval for setting a preset feedback time node is also included, specifically;

[0119] Obtain historical cross-chain interaction data packets from each member's blockchain platform;

[0120] Based on several preset interaction evaluation indicators, historical cross-chain interaction data packets are evaluated and analyzed to obtain the historical evaluation value of each preset interaction evaluation indicator.

[0121] The historical evaluation values ​​of all preset interactive evaluation indicators are weighted and summed to obtain the historical comprehensive evaluation value of the corresponding member blockchain platform.

[0122] The time interval for preset feedback time nodes is set based on historical comprehensive evaluation values.

[0123] In this embodiment, the preset interaction evaluation indicators include authentication pass rate, data consistency compliance rate, business compliance rate, etc. The historical evaluation value is obtained by comparing the historical data associated with each preset interaction evaluation indicator in the historical cross-chain interaction data packet with the standard data range of the preset interaction evaluation indicator. If it is within the standard data range, the historical evaluation value is larger; conversely, if it is not within the standard data range and is farther away from the range boundary value, the historical evaluation value is smaller. The evaluation value of each preset interaction evaluation indicator is in the range of 0-1.

[0124] In this embodiment, the higher the historical comprehensive evaluation value, the longer the time interval; conversely, the lower the historical comprehensive evaluation value, the shorter the time interval. For example, when the historical comprehensive evaluation value of a member blockchain platform is 0.9 (at a relatively high level), the time interval for the preset feedback time node can be set to 24 hours, that is, feedback and evaluation of the interaction status can be performed every 24 hours. When the historical comprehensive evaluation value of another member blockchain platform is 0.3 (at a relatively low level), the time interval is adjusted to 2 hours to monitor its interaction process more frequently and promptly identify and address any potential problems.

[0125] In this embodiment, by dynamically adjusting the time interval, differentiated feedback cycle settings can be achieved based on the past interaction performance of member blockchain platforms. For platforms with excellent performance, unnecessary frequent evaluations are reduced, thus lowering system resource consumption. At the same time, for platforms with poor performance, monitoring is strengthened, thereby improving the overall stability and reliability of cross-chain interaction.

[0126] In some embodiments of this application, cross-chain interaction data packets are generated according to preset feedback nodes, and real-time interaction coefficients are generated, including:

[0127] The cross-chain interaction data packet includes an interaction process log, data transmission record, authentication report summary, and target platform response result;

[0128] According to the preset time interval of the feedback nodes, the cross-chain interaction data related to the participating nodes within that time interval is extracted from the consortium blockchain evidence storage module, and the data is structured to generate a cross-chain interaction data packet.

[0129] Based on cross-chain interactive data packets, real-time authentication pass coefficient, data transmission latency coefficient, interactive data integrity coefficient, business rule compliance coefficient, and exception handling timeliness coefficient are generated, and then weighted and summed to obtain the real-time interaction coefficient.

[0130] In this embodiment, the real-time authentication pass coefficient is set based on the ratio of the number of cross-chain requests that have passed verification within the time interval to the total number of cross-chain requests. The data transmission latency coefficient is set based on the average time difference from the issuance of the cross-chain request to the receipt of the response from the target platform. The interaction data integrity coefficient is set by comparing the matching rate of the transmitted data fields with the preset set of required fields. The business rule compliance coefficient is quantified based on the degree of matching between the business execution results fed back by the target platform and the preset business standards. The anomaly handling timeliness coefficient is set based on the average time taken from the occurrence of an anomaly event to the system generating an early warning instruction and completing the feedback. Specifically, the formula for calculating the real-time authentication pass coefficient can be expressed as: Real-time authentication pass coefficient = Number of cross-chain requests that have passed verification ÷ Total number of cross-chain requests. Its value ranges from 0 to 1. This coefficient directly reflects the overall success rate of cross-chain requests being authenticated by the consortium blockchain evidence storage module within the set time interval. The higher the value, the better the performance of the participating node's cross-chain requests in the authentication process. The data transmission latency coefficient is set by first statistically analyzing the transmission latency of all cross-chain requests within the time interval (i.e., the time difference from the moment the cross-chain request is sent to the moment the participating node receives the response result from the target platform), calculating the average latency value, and then comparing this average latency value with a preset baseline latency threshold. According to a preset mapping rule (for example, when the average latency value is less than or equal to the baseline latency threshold, the coefficient is 1; for every certain percentage exceeding the baseline latency threshold, the coefficient decreases by a certain value, with a minimum of 0), the average latency value is converted into a data transmission latency coefficient, thereby quantifying the data transmission efficiency in the cross-chain interaction process. Determining the completeness coefficient of interactive data first requires identifying a pre-defined set of required fields. This set contains key information fields necessary to ensure the integrity of business logic and the validity of data in cross-chain interactive data. Then, for each field in the transmitted data packet of the cross-chain interactive data, it is compared with the pre-defined set of required fields one by one, and the number of fields that match successfully is counted. The completeness coefficient of interactive data = number of fields that match successfully ÷ total number of fields in the pre-defined set of required fields. Its value is also between 0 and 1. The higher the matching rate, the more complete the transmitted data is and the stronger its ability to meet the needs of subsequent business processing. The quantitative setting of the business rule compliance coefficient relies on the feedback information from the target platform regarding the execution results of cross-chain interaction business. The system will compare these feedback results with the preset business standards in multiple dimensions, such as whether the execution steps of the business process comply with the specifications, whether the returned business data format is correct, and whether the key business indicators meet expectations. Based on the degree of compliance of each comparison dimension, a corresponding score is assigned (e.g., 100 points for complete compliance, points for partial compliance according to the compliance ratio, and 0 points for complete non-compliance). After weighted summation of the scores of each dimension, the total score is normalized to the range of 0 to 1, which is the business rule compliance coefficient. This coefficient reflects the degree of conformity between the cross-chain interaction business and the established business specifications during the execution process.The setting of the anomaly handling timeliness coefficient first identifies all abnormal events occurring within the time interval (such as data transmission errors, authentication failures, business execution anomalies, etc.). It records the time taken for each abnormal event from its occurrence to the system successfully generating an early warning command and completing feedback to relevant nodes (such as notifying participating nodes, target platforms, or consortium blockchain management nodes). The average of these times is calculated, and then the average time is compared with a preset anomaly handling baseline timeliness threshold. Similarly, the average time is converted into an anomaly handling timeliness coefficient through preset conversion rules (such as a coefficient of 1 when the average time is less than or equal to the baseline timeliness threshold; the coefficient decreases proportionally for each time the average time exceeds the baseline timeliness threshold, with a minimum of 0). This measures the system's response speed and processing efficiency when facing abnormal situations. After obtaining the above five specific coefficients, according to the actual needs of cross-chain interaction business and the importance of each coefficient, a corresponding weight is assigned to each coefficient (the sum of each weight value is 1). In this application, the weight of real-time authentication pass rate is 0.3, the weight of data transmission latency is 0.2, the weight of interaction data integrity is 0.2, the weight of business rule compliance is 0.2, and the weight of exception handling timeliness is 0.1. The real-time interaction coefficient of the preset feedback node is obtained by weighted summation formula.

[0131] In this embodiment, by calculating the real-time interaction coefficient, the cross-chain interaction performance of member blockchain platforms within a preset feedback time interval can be comprehensively and quantitatively evaluated. The value directly reflects the quality of the current interaction status of the platform and can also provide participating nodes with a real-time profile of their own interaction status, helping them to optimize business processes, improve data quality, or improve anomaly handling mechanisms, thereby promoting the continuous improvement of the interaction efficiency of the entire cross-platform blockchain alliance.

[0132] In some embodiments of this application, determining whether to generate a warning instruction based on a real-time interaction coefficient includes:

[0133] Calculate the absolute value of the difference between the real-time interaction coefficients at adjacent preset feedback time nodes, and generate the fluctuation coefficient of the real-time interaction coefficient at the current preset feedback time node based on the absolute value of the difference.

[0134] Whether to generate an early warning instruction is determined based on the fluctuation coefficient and the real-time interaction coefficient.

[0135] When the fluctuation coefficient is greater than the preset fluctuation threshold, or the current real-time interaction coefficient is less than the preset interaction coefficient threshold, the interaction status is determined to be abnormal, and an early warning command is generated.

[0136] In this embodiment, the warning instruction includes an anomaly type identifier (such as fluctuation anomaly or absolute value anomaly), anomaly coefficient name, current coefficient value, historical comparison value, and suggested handling measures, and the warning instruction is encrypted and sent to the alliance management node and the corresponding participating node.

[0137] In this embodiment, the preset fluctuation threshold is determined statistically based on the normal fluctuation range of the real-time interaction coefficient in historical interaction data, for example, it is set to 1.5 times the historical average fluctuation value; the preset difference threshold is set based on the distribution characteristics of historical comprehensive evaluation values, for example, it is set to 20% of the average historical comprehensive evaluation value. When both abnormal fluctuation amplitude and abnormal absolute value are met simultaneously, the warning instruction is determined to be of the highest priority and marked as "emergency" in the instruction.

[0138] In some embodiments of this application, before synchronizing the authentication report to the target platform and performing verification, the following steps are also included:

[0139] The improved PBFT consensus mechanism of the consortium blockchain is used to complete node confirmation. After confirmation, a consensus certificate is generated and embedded in the authentication report.

[0140] The improved PBFT consensus mechanism of the consortium blockchain adjusts the weight of consensus nodes through a dynamic weight allocation mechanism, the number of nodes in the member blockchain platform, and historical interaction coefficients.

[0141] The authentication report and consensus certificate are encrypted using the national cryptographic SM4 algorithm and synchronized to the target platform through a preset cross-chain secure communication channel. The encrypted authentication report, consensus certificate and decryption key are then fed back to the blockchain platform of the initiating member and the participating node.

[0142] In this embodiment, the dynamic weight allocation mechanism is implemented through the following steps: First, the number of active nodes on each member blockchain platform is counted. The more nodes there are, the higher the basic weight percentage. For example, the node number weight coefficient is set to 0.4. Second, the historical interaction coefficient of each platform is retrieved. This coefficient is calculated based on the consensus response speed, data accuracy, and abnormal behavior records during historical interactions. The higher the historical interaction coefficient, the higher the reputation weight percentage. The reputation weight coefficient is set to 0.6. Finally, the node number weight and reputation weight are weighted and summed to obtain the final consensus node weight of each member blockchain platform. For example, if member platform A has 50 active nodes (node ​​number weight is 50 / total number of nodes × 0.4) and a historical interaction reputation score of 90 points (reputation weight is 90 / 100 × 0.6), then its final weight is the sum of the two. Through this dynamic adjustment method, platforms with large node scale and good reputation have greater influence in the consensus process, improving consensus efficiency and security. At the same time, during the consensus certificate generation stage, the system automatically records the weight value and participation process log of each consensus node as the basis for subsequent weight adjustment and reputation evaluation.

[0143] In this embodiment, when using the national cryptographic SM4 algorithm to encrypt the authentication report and consensus certificate, the authentication report and consensus certificate are first combined into a data block to be encrypted according to a preset splicing rule. The data block is then padded to meet the block length requirement of the SM4 algorithm. Then, the session key generated by the consortium blockchain management node is used to perform block encryption operation on the padded data block to generate encrypted ciphertext.

[0144] In this embodiment, the cross-chain secure communication channel adopts a two-layer encryption transmission mechanism based on the TCP / IP protocol. The bottom layer establishes a transport layer secure connection through the SSL / TLS protocol, and the upper layer adds a message authentication code (MAC) to the encrypted ciphertext. The message authentication code is generated by hashing the ciphertext, timestamp, and channel identifier to ensure the confidentiality and integrity of the data during transmission.

[0145] In this embodiment, the decryption key is transmitted separately using asymmetric encryption. The consortium management node uses the public keys of the initiating member's blockchain platform and the participating node to encrypt the session key, generating corresponding key ciphertext, which is fed back along with the encrypted authentication report and consensus certificate. After the recipient decrypts the key ciphertext using its own private key, it can obtain the session key to decrypt the authentication report and consensus certificate.

[0146] In this embodiment, by adjusting the weight of synchronous nodes and introducing national cryptographic algorithms, the flexibility, security and credibility of the consortium blockchain consensus process are effectively improved. Combined with a two-layer encrypted communication channel and an asymmetric key transmission method, a full-link security protection system from data generation to transmission is constructed, further reducing the risk of cross-chain data being tampered with or leaked.

[0147] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and substitutions can be made without departing from the technical principles of this application, and these improvements and substitutions should also be considered within the scope of protection of this application.

Claims

1. A cross-platform blockchain trusted authentication method, characterized in that, Applied to cross-platform blockchain consortium architectures, including: Obtain application information from blockchain platforms participating in cross-chain certification, review the application information, and complete access certification for blockchain platforms that pass the review; Participating nodes send cross-chain requests to the certified blockchain platform, perform preliminary verification of the cross-chain requests, and send cross-platform trusted authentication requests after the verification is successful. Perform multi-dimensional authentication on cross-platform trusted authentication requests, generate authentication reports, synchronize the authentication reports to the target platform for verification, and perform cross-chain interaction after successful verification; Generate cross-chain interaction data packets according to preset feedback nodes, calculate real-time interaction coefficients, and determine whether to generate warning instructions based on real-time interaction coefficients.

2. The cross-platform blockchain trusted authentication method as described in claim 1, characterized in that, The cross-platform blockchain alliance architecture includes an alliance management node and several heterogeneous member blockchain platform primary participant nodes. The member blockchain platform includes an independent blockchain built by the parties involved in the bidding and procurement process; The participating nodes include bidding nodes, tendering nodes, regulatory nodes, and financial nodes.

3. The cross-platform blockchain trusted authentication method as described in claim 2, characterized in that, The application information is reviewed, and access certification is completed for blockchain platforms that pass the review, including: The application information includes platform identifier, consensus algorithm type, encryption mechanism parameters, node list, and business scope; The alliance management node reviews the application information of each blockchain platform. The review includes verifying the uniqueness of the platform identifier, assessing the compatibility of the consensus algorithm type with the alliance architecture, verifying the security of the encryption mechanism parameters, verifying the authenticity of the node identity in the node list, and detecting the matching degree between the business scope and the alliance admission rules. Generate a quantitative value for the review result of each reviewed item, and perform weighted summation to obtain a comprehensive quantitative value; Pre-set the threshold for the comprehensive quantification value; If the comprehensive quantitative value is greater than the comprehensive quantitative value threshold, the review is deemed successful, a unique alliance identifier is assigned to the blockchain platform, and an access key pair based on an asymmetric encryption algorithm is generated to complete the access authentication. If the overall quantitative value is not greater than the overall quantitative value threshold, the review is deemed unsuccessful.

4. The cross-platform blockchain trusted authentication method as described in claim 2, characterized in that, The cross-chain request undergoes initial verification. Once verification is successful, a cross-platform trusted authentication request is sent, including: The cross-chain request includes the target platform identifier, the interaction data digest, the business type, and the authentication requirements. The initial verification of cross-chain requests includes: verifying whether the target platform identifier is a blockchain platform identifier that has completed access authentication; verifying whether the format of the interaction data digest conforms to the hash algorithm specification preset by the consortium; verifying whether the business type is within the scope of cross-chain business allowed by the consortium; and verifying whether the authentication requirements match the authentication capabilities supported by the target platform. If the above preliminary verifications all pass, the blockchain platform where the participating node is located will generate a cross-platform trusted authentication request and send the encrypted request to the consortium management node. If any preliminary verification fails, a rejection request is returned to the participating nodes.

5. The cross-platform blockchain trusted authentication method as described in claim 4, characterized in that, Perform multi-dimensional authentication on cross-platform trusted authentication requests and generate authentication reports, including: The multi-dimensional authentication includes identity authentication, data authentication, and business authentication; The identity authentication adopts a dual authentication mechanism, which compares the access key with the platform public key library pre-stored at the alliance management node, and compares the digital certificate of the participating node with the digital certificate of the participating node pre-stored at the alliance management node. An identity authentication score is generated based on the comparison results. The data authentication process involves a hierarchical comparison between the interactive data digest in the cross-chain request and the original data hash value on the blockchain platform of the initiating member, while also introducing timestamp verification. A data authentication score is generated based on the comparison and verification results. The business authentication process calls the corresponding business rule base based on the business type in the cross-chain request, performs multi-dimensional verification of the business qualifications, business operation permissions, and historical business performance records of the participating nodes, and generates a business authentication score based on the verification results. A weighted summation algorithm is used to process the identity authentication score, data authentication score, and business authentication score according to preset weights to obtain a comprehensive authentication score. When the overall authentication score is greater than the preset authentication score threshold, an authentication report is generated. The authentication report includes authentication process logs, details of authentication results in each dimension, timestamps, and signatures of the consortium blockchain management node.

6. The cross-platform blockchain trusted authentication method as described in claim 5, characterized in that, The certification report is synchronized to the target platform and verified. Once verification is successful, cross-chain interaction is performed, including: The generated unified authentication report is encapsulated according to the data format and encryption standard specified by the target platform, and the encapsulated unified authentication report is pushed to the authentication interface of the target platform through the cross-chain communication protocol; After receiving the report, the target platform activates its built-in verification module to parse and verify the report content. The verification process includes: The signature of the consortium blockchain management node in the report is matched and verified with the pre-stored public key of the management node by calling a preset signature verification algorithm. The timestamp in the unified authentication report is verified a second time to obtain its time deviation from the local time of the target platform, and the timestamp format is checked to see if it conforms to the alliance's unified standard. Compare whether the calculation logic of identity authentication score, data authentication score and business authentication score is consistent with the preset rules, and focus on verifying the three-level traceability comparison process records of the difference fields in the hierarchical comparison and the key indicator data in the business qualification verification. Perform integrity verification on the authentication process logs to check whether they contain information on key nodes throughout the entire process, from the initiation of the cross-chain request to the generation of the comprehensive authentication score. If all the above verifications pass, the target platform generates a verification pass receipt and returns it to the alliance management node, triggering the cross-chain interaction process; If any verification fails, the cross-chain request will be rejected and a verification failure report will be generated and simultaneously fed back to the initiating node and the alliance management node.

7. The cross-platform blockchain trusted authentication method as described in claim 1, characterized in that, It also includes setting the time interval for preset feedback time nodes, specifically; Obtain historical cross-chain interaction data packets from each member's blockchain platform; Based on several preset interaction evaluation indicators, historical cross-chain interaction data packets are evaluated and analyzed to obtain the historical evaluation value of each preset interaction evaluation indicator. The historical evaluation values ​​of all preset interactive evaluation indicators are weighted and summed to obtain the historical comprehensive evaluation value of the corresponding member blockchain platform. The time interval for preset feedback time nodes is set based on historical comprehensive evaluation values.

8. The cross-platform blockchain trusted authentication method as described in claim 7, characterized in that, Generate cross-chain interaction data packets according to preset feedback nodes, and generate real-time interaction coefficients, including: The cross-chain interaction data packet includes an interaction process log, data transmission record, authentication report summary, and target platform response result; According to the preset time interval of the feedback nodes, the cross-chain interaction data related to the participating nodes within that time interval is extracted from the consortium blockchain evidence storage module, and the data is structured to generate a cross-chain interaction data packet. Based on cross-chain interactive data packets, real-time authentication pass coefficient, data transmission latency coefficient, interactive data integrity coefficient, business rule compliance coefficient, and exception handling timeliness coefficient are generated, and then weighted and summed to obtain the real-time interaction coefficient.

9. The cross-platform blockchain trusted authentication method as described in claim 8, characterized in that, Whether to generate an early warning instruction is determined based on the real-time interaction coefficient, including: Calculate the absolute value of the difference between the real-time interaction coefficients at adjacent preset feedback time nodes, and generate the fluctuation coefficient of the real-time interaction coefficient at the current preset feedback time node based on the absolute value of the difference. Whether to generate an early warning instruction is determined based on the fluctuation coefficient and the real-time interaction coefficient. When the fluctuation coefficient is greater than the preset fluctuation threshold, or the current real-time interaction coefficient is less than the preset interaction coefficient threshold, the interaction status is determined to be abnormal, and an early warning command is generated.

10. The cross-platform blockchain trusted authentication method as described in claim 1, characterized in that, Before synchronizing the certification report to the target platform and verifying it, the following steps are also included: The improved PBFT consensus mechanism of the consortium blockchain is used to complete node confirmation. After confirmation, a consensus certificate is generated and embedded in the authentication report. The improved PBFT consensus mechanism of the consortium blockchain adjusts the weight of consensus nodes through a dynamic weight allocation mechanism, the number of nodes in the member blockchain platform, and historical interaction coefficients. The authentication report and consensus certificate are encrypted using the national cryptographic SM4 algorithm and synchronized to the target platform through a preset cross-chain secure communication channel. The encrypted authentication report, consensus certificate and decryption key are then fed back to the blockchain platform of the initiating member and the participating node.

Images