Blockchain-based trusted interaction method before chain, electronic device and program product

Abstract

This application relates to the field of blockchain technology and provides a pre-chain trusted interaction method, electronic device, and program product for blockchain. The method includes: upon detecting a user-triggered commit event, suspending the redirection behavior of the commit event and obtaining the underlying data corresponding to the commit event; after suspending the redirection behavior of the commit event, capturing the current webpage rendering screen corresponding to the commit event; and, based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen, either passing or circuit breaking the commit event. This solution ensures that the first semantics of the underlying data corresponding to the commit event matches the second semantics of the current webpage rendering screen before the commit event is passed. This effectively identifies the problem of the current webpage rendering screen being disconnected from the underlying data due to front-end spoofing attacks, ensuring the authenticity of the pre-chain data and improving the security of the blockchain.

Description

Technical Field

[0001] This application belongs to the field of blockchain technology, and in particular relates to a blockchain front-end trusted interaction method, electronic device and program product. Background Technology

[0002] Blockchain-based trusted evidence storage technology relies on mechanisms such as hash digests, Merkle trees, digital signatures, and on-chain storage to ensure the tamper-proof protection of on-chain data. However, existing technological systems focus excessively on maintaining the trustworthiness of on-chain data, lacking effective protective measures for the pre-chain data collection stage.

[0003] In practical applications, the browser front-end environment, due to its open nature, is vulnerable to multi-dimensional attack threats: attackers can tamper with the Document Object Model (DOM) structure through task execution timing or hijack the native DOM interface to induce business code to obtain distorted data; simultaneously, they can use front-end camouflage strategies such as CSS opacity hiding techniques, pixel-level absolute positioning overlays, or text direction reversals to create a semantic disconnect between the rendered webpage and the underlying data, causing a fundamental discrepancy between the content seen by the user and the actual submitted data. For example, the rendered webpage displays a contract amount of A (e.g., 100,000), while the actual contract amount submitted in the underlying data has been altered to B (e.g., 10 million).

[0004] It can be seen that existing technologies cannot guarantee a complete semantic match between the semantics of the rendered webpage and the underlying data, making it difficult to guarantee the authenticity of the data before the blockchain, and ultimately reducing the security of the blockchain. Summary of the Invention

[0005] In view of this, embodiments of this application provide a pre-chain trusted interaction method, electronic device, and program product for blockchain, in order to solve the technical problem of low security of blockchain in the prior art.

[0006] In a first aspect, embodiments of this application provide a pre-chain trusted interaction method for blockchain, applied to a blockchain interaction system, the method comprising: When a user triggers a submit event, the redirection behavior of the submit event is suspended, and the underlying data corresponding to the submit event is obtained. After suspending the redirection behavior of the submitted event, capture the current webpage rendering screen corresponding to the submitted event; Based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen, the submission event is either triggered or circuit-broken.

[0007] Optionally, the blockchain interaction system includes a trusted probe, a business server, and an end-side trusted host. The trusted probe is used to suspend the redirection behavior and obtain the underlying data. The trusted probe achieves the highest running priority in the following ways: In a controlled engineering scenario, the trusted probe is preferentially injected into the response stream by the business server, and a dynamic random security token is sent to the trusted probe by the business server, while the target browser is controlled to block unauthorized external scripts. In uncontrolled engineering scenarios, the trusted probe is injected into the front end of the target webpage's code before the target webpage's network traffic is parsed by the target browser through the trusted host on the end side. The target webpage corresponds to the currently rendered webpage.

[0008] Optionally, the blockchain interaction system further includes a notarization backend; obtaining the underlying data corresponding to the submission event includes: After freezing the underlying functionality of the target browser and wrapping the underlying data corresponding to the submission event with the proxy object of the trusted probe, the security salt corresponding to the submission event is obtained from the evidence storage backend, and the underlying data corresponding to the submission event and the security salt are stored in a private linear memory space.

[0009] Optionally, the blockchain interaction system includes a browser privileged process; the step of capturing the current webpage rendering screen corresponding to the submission event includes: By using the privileged browser process, the front-end webpage sandbox corresponding to the submission event is bypassed, and the image capture interface corresponding to the privileged browser process is used to capture the current webpage rendering screen, and the current webpage rendering screen is stored in a private linear memory space.

[0010] Optionally, the blockchain interaction system includes a semantic comparison model, wherein the step of triggering or circuit breaking the submission event based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen includes: Using the semantic comparison model, the underlying data and the current webpage rendering screen are obtained from the private linear memory space, and the first semantic corresponding to the underlying data and the second semantic corresponding to the current webpage rendering screen are identified. Determine the edit distance between the first semantic and the second semantic, and / or perform a key field numerical comparison between the first semantic and the second semantic, and / or perform structured semantic matching between the first semantic and the second semantic; Based on the edit distance, and / or the result of the key field numerical comparison, and / or the result of the structured semantic matching, the submit event is either bypassed or circuited.

[0011] Optionally, the step of bypassing or circumventing the submission event based on the edit distance, and / or the result of the key field numerical comparison, and / or the result of the structured semantic matching includes: If the edit distance is greater than a preset distance threshold, or if the result of the key field value comparison shows that the difference between the key field value of the first semantic and the key field value of the second semantic is greater than a preset difference threshold, or if the result of the structured semantic matching shows that the first semantic and the second semantic have a semantic structure separation phenomenon, then the submission event is aborted; otherwise, the submission event is passed.

[0012] Optionally, after determining whether to pass or circuit break the submission event based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen, the method further includes: A Merkle tree is constructed based on the hash corresponding to the underlying data, the hash corresponding to the current webpage rendering screen, and the hash corresponding to the security salt of the submission event. The Merkle root of the Merkle tree is determined by recursively calculating each node of the Merkle tree. The Merkle root is used to provide evidence for the submission event.

[0013] Optionally, after determining the Merkle root corresponding to the Merkle tree, the method further includes: The Merkle root is digitally signed using the underlying encryption interface of the target browser, and the Merkle root and its corresponding digital signature are uploaded to the target blockchain. The underlying data and the current webpage rendering are encrypted and stored on a preset server.

[0014] Secondly, embodiments of this application provide a pre-chain trusted interaction device for blockchain, applied to a blockchain interaction system, the device comprising: The first data acquisition unit is used to suspend the jump behavior of the submission event when the user triggers the submission event, and to acquire the underlying data corresponding to the submission event. The second data acquisition unit is used to capture the current webpage rendering screen corresponding to the submission event after suspending the redirection behavior of the submission event; The event handling unit is used to either trigger or circuit-break the submission event based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen.

[0015] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the blockchain pre-chain trusted interaction method as described in any of the first aspects above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the blockchain pre-chain trusted interaction method as described in any of the first aspects above.

[0017] Fifthly, embodiments of this application provide a computer program product that, when run on a display device, causes the display device to perform the steps of the blockchain pre-chain trusted interaction method as described in any of the first aspects above.

[0018] The beneficial effects of the blockchain pre-chain trusted interaction method provided in this application embodiment are as follows: The blockchain pre-chain trusted interaction method provided in this application includes: when a user triggers a submit event, suspending the redirection behavior of the submit event and obtaining the underlying data corresponding to the submit event; after suspending the redirection behavior of the submit event, capturing the current webpage rendering screen corresponding to the submit event; and, based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen, either passing or circuit breaking the submit event. This solution ensures that the first semantics of the underlying data corresponding to the submit event matches the second semantics of the current webpage rendering screen corresponding to the submit event before submitting the event. This effectively identifies the problem of the current webpage rendering screen being disconnected from the underlying data due to front-end spoofing attacks, ensuring the authenticity of the pre-chain data and improving the security of the blockchain. Attached Figure Description

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

[0020] Figure 1 A flowchart illustrating the implementation of the blockchain pre-chain trusted interaction method provided in this application embodiment; Figure 2 A schematic diagram of the structure of a blockchain front-end trusted interaction device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] It should be noted that the terminology used in the embodiments of this application is only for explaining specific embodiments of this application and is not intended to limit this application. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, "at least one" or "one or more" means one, two or more. 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 indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0022] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0023] In traditional blockchain-based trusted evidence storage technologies, existing solutions primarily rely on on-chain storage mechanisms to prevent data tampering, but pre-chain data protection mechanisms are significantly lacking. Specifically, the openness of the browser front-end environment allows for temporal alteration of the Document Object Model (DOM) structure, hijacking of native DOM interfaces, and visual spoofing attacks, leading to inconsistencies between the rendered webpage and the underlying data. Furthermore, such attacks may result in malicious modification of the underlying data captured when a user submits an event, without the system recognizing the separation between visual presentation and the structural layer. This issue directly impacts the credibility of the data source and the legal validity of the evidence storage results.

[0024] For example, in electronic contract signing scenarios, when a user triggers a submission, CSS opacity hiding or absolute positioning overlay techniques can be used to separate the current webpage rendering of key contract fields from the underlying data. Specifically, there is a difference between the contract amount displayed in the current webpage rendering and the actual submitted data bound to the underlying data, while the system only processes the underlying data at the structural layer. Therefore, the evidence preservation process calculates the hash of the tampered underlying data and uploads it to the blockchain. While the blockchain ensures the subsequent immutability of this data, the authenticity of the source data cannot be verified. In this scenario, the judicial evidence presentation process faces substantial obstacles due to the lack of multimodal comparison evidence between the webpage rendering and the underlying data.

[0025] If the aforementioned issues are not addressed, the evidence preservation system will be unable to ensure the consistency between the data uploaded to the blockchain and the actual user interactions, rendering the blockchain's immutability applicable only to contaminated data sources. Furthermore, this deficiency will render the evidence preservation results lack credible evidence in judicial proceedings and may lead to the failure of user rights protection mechanisms. In particular, the existence of blind spots in pre-chain data fundamentally undermines the basic reliability of the entire evidence preservation chain.

[0026] To address the above issues, this application provides a pre-chain trusted interaction method for blockchain, which can be applied to blockchain interaction systems.

[0027] For ease of understanding, the following explains some key terms in this embodiment: The pre-chain trusted interaction method for blockchain aims to address security issues such as data tampering and forgery that may arise before data is uploaded to the blockchain. This method ensures the authenticity of the uploaded data and the consistency of the user's intent by performing dual verification on the underlying data and the user's view before the user submits the data.

[0028] A blockchain interaction system refers to the overall technical architecture that supports data interaction between users and the blockchain. This system typically includes a user interface, a business logic processing module, and an interface for communicating with the blockchain network.

[0029] A submission event refers to an action triggered by a user on a webpage or application that results in data submission or sending. Examples include clicking the "Confirm" or "Submit" button, or completing a form and triggering data sending.

[0030] Redirect behavior refers to the page navigation or state update operation that a browser or application performs by default after a submission event occurs. Examples include page redirection, page refresh, or partial content update.

[0031] Underlying data refers to the raw data directly associated with the submission event that will be processed or sent to the backend system (including the blockchain). This data typically resides in the DOM structure of a webpage, form fields, or JavaScript variables.

[0032] The current rendered webpage refers to the actual visual presentation of the webpage that the user sees on the screen when the submission event occurs. This screen includes all HTML elements, CSS styles, images, and content dynamically generated via JavaScript.

[0033] The first semantic meaning refers to the semantic information extracted or parsed from the underlying data that represents the actual meaning and content of the data. For example, the specific value "1,000,000" extracted from the underlying data of a transfer amount.

[0034] The second semantic refers to the semantic information that is identified or parsed from the currently rendered webpage, representing the visual meaning and content of the image. For example, the transfer amount "100000" identified from a screenshot using optical character recognition (OCR).

[0035] The "pass" or "circuit breaker" approach to event submissions determines whether to allow the submission to proceed based on a comparison of the first and second semantics. If the two semantics are consistent or within an acceptable range, the submission is "passed"; otherwise, if there is a significant inconsistency, the submission is "circuited," preventing further processing of the event.

[0036] Please see Figure 1 , Figure 1 The flowchart illustrates the implementation of the blockchain pre-chain trusted interaction method provided in this application embodiment. This blockchain pre-chain trusted interaction method may include steps S101 to S103, detailed below: In S101, when a user triggers a submit event, the jump behavior of the submit event is suspended, and the underlying data corresponding to the submit event is obtained.

[0037] In this embodiment, when a user performs blockchain-related operations, such as clicking the "Confirm Transfer" button, a commit event is triggered. To ensure the security of this event, the system first needs to detect its occurrence. One possible implementation is to deploy an event listener in the front-end page to detect whether the user has triggered a commit event.

[0038] In practical applications, in order to ensure the security and trustworthiness of the entire interaction process, how to effectively and reliably suspend the jump behavior of the submission event and obtain the underlying data, and prevent malicious scripts or user behavior from interfering with or tampering with these critical operations, is an important challenge in achieving the trustworthiness of this method.

[0039] In response, this application further proposes a blockchain interaction system comprising a trusted probe, a business server, and an end-side trusted host. The trusted probe is used to suspend redirection behavior and obtain underlying data. The trusted probe achieves the highest running priority in the following ways: In a controlled engineering scenario, the business server preferentially injects the trusted probe into the response stream and sends a dynamic random security token to the trusted probe, while controlling the target browser to intercept unauthorized external scripts; In an uncontrolled engineering scenario, the end-side trusted host injects the trusted probe into the very front end of the target webpage's code before the target webpage's network traffic is parsed by the target browser, and the target webpage corresponds to the currently rendered webpage.

[0040] A trusted probe is a program module that runs in the target webpage environment. Its main function is to suspend the redirection behavior of a submission event and securely obtain the underlying data corresponding to the submission event. Its core role is to act as a pre-execution unit for trusted interaction methods, ensuring that it can intervene and control the process as soon as a user submits an operation, providing reliable input for subsequent data collection and semantic comparison.

[0041] A business server is a backend system that provides the target webpage content and services. In controlled engineering scenarios, a business server can be configured to preprocess the response content when sending webpage responses to the client, such as inserting specific scripts into the HTML response stream. Furthermore, the business server can also be responsible for generating and managing security tokens used for authentication or authorization, and has the ability to control the behavior of client browsers to a certain extent. A trusted host on the user's device refers to an application or environment that runs locally and possesses high privileges and trustworthiness. In uncontrolled engineering scenarios, this host can be a standalone client application, a browser extension, or an operating system-level proxy service. Its main function is to preprocess the code of the target webpage before the target browser parses network traffic, injecting a trusted probe into the very front of the webpage. This ensures that the trusted probe executes before any other scripts, gaining ultimate control over the webpage environment.

[0042] The highest execution priority means that the trusted probe has priority over any other script or code in the target webpage environment in terms of execution order and control. This priority ensures that the trusted probe can intervene as soon as a submission event occurs, suspend the redirection behavior and obtain the underlying data, thereby effectively preventing interference or tampering by malicious scripts.

[0043] "In controlled engineering scenarios, injecting trusted probes preferentially into the response stream via the business server" refers to the business server embedding the trusted probe code into a very early location in the HTML document when generating and sending the webpage's HTTP response, such as at the beginning of the `<head>` tag, or even in the `<body>` tag.<!DOCTYPE html> Following the declaration, this injection method ensures that the trusted probe's code is loaded and executed first when the browser begins parsing and rendering the webpage, thus establishing listening and control over the submission event before any other user scripts or third-party scripts run.

[0044] "Sending a dynamic, random security token to a trusted probe via the business server" refers to a one-time or short-term valid encrypted credential generated by the business server. This token can be sent to the trusted probe along with the webpage response for authentication during subsequent communication between the probe and the business server, or as authorization credentials for the probe to perform certain sensitive operations. Because the token is dynamically and randomly generated and has a limited validity period, it effectively prevents replay attacks and unauthorized access, enhancing the security of probe operations.

[0045] "Control the target browser to block unauthorized external scripts" instructs the browser to block the loading or execution of scripts from sources not on the default whitelist. This measure aims to eliminate potential interference from malicious scripts to the trusted probe or tampering with webpage content, further ensuring the purity and security of the trusted probe's operating environment.

[0046] "In uncontrolled engineering scenarios, injecting a trusted probe into the very beginning of the target webpage's code via a trusted host on the client side, before the target browser parses the target webpage's network traffic," refers to the process where, because the business server may not be able to directly control the webpage content, the trusted host on the client side intercepts the target webpage's network traffic and modifies the webpage's original code before the data reaches the target browser for parsing and rendering. Specifically, the host inserts the trusted probe's code at the very beginning of the HTML document, ensuring that the probe is loaded and executed before the browser processes any other HTML elements or scripts. This pre-parsing injection mechanism allows the trusted probe to gain ultimate control over the webpage environment, enabling trusted interaction even on third-party websites.

[0047] This application's solution introduces a trusted probe, a business server, and a trusted host on the client side, assigning the trusted probe the highest execution priority. This ensures that the process of suspending the redirection and obtaining underlying data when a user triggers a submission event is secure and tamper-proof. This mechanism allows the trusted probe to be loaded and executed before any other scripts or content on the webpage, thereby capturing and suspending the submission event immediately and securely obtaining the underlying data. By guaranteeing the highest execution priority in two different scenarios, this solution effectively solves the problem of ensuring the reliability and security of suspending submission events and obtaining underlying data in complex and ever-changing webpage environments. This provides trusted input for subsequent semantic comparison, thereby improving the overall security and effectiveness of the entire blockchain front-end trusted interaction method.

[0048] In some of the above implementations, it is proposed to suspend the jump behavior of the submission event and obtain the underlying data when the user triggers the submission event. However, in the process of obtaining the underlying data, how to ensure the integrity and authenticity of the obtained data and prevent potential tampering is a key challenge to ensure the security of trusted interaction in the front chain.

[0049] In response, this application further proposes that the blockchain interaction system also includes a backend for evidence storage; obtaining the underlying data corresponding to the submission event includes: after freezing the underlying functions of the target browser and wrapping the underlying data corresponding to the submission event with the proxy object of the trusted probe, obtaining the security salt corresponding to the submission event from the backend for evidence storage, and storing the underlying data corresponding to the submission event and the security salt in a private linear memory space.

[0050] The evidence storage backend is a dedicated service module for generating, managing, and distributing secure credentials or encrypted materials. It can be a standalone server cluster responsible for generating and providing one-time security salts upon request; alternatively, it can be part of a business server, providing encryption services and security salt management functionality.

[0051] Freezing the underlying functionality of the target browser is designed to prevent unauthorized modifications to the browser environment or data leaks during the acquisition and processing of sensitive data.

[0052] Wrapping the underlying data with a proxy object of a trusted probe is to strictly control and audit access to and operations on the underlying data without directly modifying the original data structure, ensuring the integrity and immutability of the data during processing.

[0053] A security salt is a randomly generated piece of additional data associated with a specific commit event. Its main purpose is to enhance the security of data hashes, prevent rainbow table attacks and collision attacks, and ensure that the hash value generated for each commit is unique, even if the underlying data is the same. The backend can generate a high-entropy random string as a security salt based on the unique identifier of the commit event and send it to a trusted probe via an encrypted channel; alternatively, the backend can maintain a pre-generated security salt pool and allocate an unused security salt for each request.

[0054] Private linear memory space refers to an isolated and protected memory region designed to prevent unauthorized external processes or malicious scripts from accessing, reading, or tampering with the sensitive data stored therein.

[0055] In the aforementioned blockchain interaction method, when the trusted probe acquires the underlying data corresponding to the submission event, to ensure data integrity and security, this application further introduces a notarization backend and a series of data protection mechanisms. Specifically, before acquiring the underlying data, the trusted probe first freezes the underlying functions of the target browser. This effectively prevents any unauthorized browser behavior or script tampering that may occur during the data acquisition process, thereby ensuring the originality and authenticity of the underlying data. Subsequently, the trusted probe uses its proxy object to wrap the acquired underlying data. This means that any access to or modification of the underlying data must be controlled by the trusted probe, further enhancing the data's anti-tampering capability. Based on this, the trusted probe obtains a security salt from the notarization backend that uniquely corresponds to the current submission event. The introduction of this security salt ensures that subsequent hash calculations on the underlying data will generate different hash values ​​even if the original data is the same, greatly improving the collision resistance and security of the data hash. Finally, the underlying data wrapped by the proxy object and the acquired security salt are stored together in a private linear memory space. This private linear memory space is isolated from other browser processes and scripts, forming a highly secure storage environment that effectively prevents the leakage or tampering of sensitive data before subsequent processing. Through this series of interconnected measures, this application ensures that the underlying data is of reliable origin, complete in content, and securely stored before semantic comparison and final submission, thus laying a solid security foundation for the entire pre-chain trusted interaction process.

[0056] In S102, after suspending the redirection behavior of the submit event, the current webpage rendering screen corresponding to the submit event is captured.

[0057] In this embodiment of the application, after successfully suspending the redirection behavior and obtaining the underlying data, the system will immediately capture the webpage rendering screen currently seen by the user in order to capture the visual information that the user actually sees when submitting data.

[0058] In practical applications, since front-end web pages usually run in a sandbox environment, there are technical challenges to directly, securely and completely capturing the rendered screen. It may be limited by the sandbox mechanism, resulting in the inability to obtain the real and untampered rendered screen, thus affecting the accuracy and reliability of subsequent semantic comparison.

[0059] In response, this application further proposes a blockchain interaction system including a browser privileged process; capturing the current webpage rendering screen corresponding to the submission event, including: bypassing the front-end webpage sandbox corresponding to the submission event through the browser privileged process, capturing the current webpage rendering screen using the image acquisition interface corresponding to the browser privileged process, and storing the current webpage rendering screen in a private linear memory space.

[0060] Browser privileged processes refer to processes within the browser architecture that possess higher privileges and broader access to system resources than ordinary rendering processes. These processes are typically responsible for handling sensitive operations such as file system access, network communication, and graphics rendering, and are not subject to the limitations of the front-end webpage sandbox. Their role is to provide a secure and high-privilege execution environment to perform operations that require bypassing conventional security restrictions.

[0061] In the section on "Bypassing the Front-End Sandbox for Submission Events," the front-end sandbox is a security mechanism designed to isolate webpage content and restrict its access to system resources to prevent malicious webpages from harming user devices. Bypassing the sandbox means that privileged processes can break through this isolation and directly access or control the rendered content within the sandbox.

[0062] In the section on "capturing the current webpage rendering screen using the image capture interface corresponding to the browser's privileged process," the image capture interface is a programming interface provided by the operating system or the browser's underlying layer, used to capture screen content or the rendering output of a specific window. When the browser's privileged process bypasses the front-end webpage sandbox, the image capture interface can call these interfaces to obtain the rendering screen of the current webpage.

[0063] Private linear memory space is a memory region independently allocated and managed by privileged processes, and cannot be directly accessed by other processes. Storing captured rendered images in such space can effectively prevent other malicious processes or scripts within the sandbox from tampering with or stealing the image data, thereby ensuring data integrity and security.

[0064] This application's solution addresses the challenge of securely and reliably capturing webpage rendering in a restricted sandbox environment by introducing a privileged browser process. When a user triggers a submission event and their redirection is suspended, the blockchain interaction system initiates or utilizes an existing privileged browser process to obtain the current webpage rendering for semantic comparison. This privileged process, with its high privileges, effectively bypasses the front-end webpage sandbox's access restrictions on rendered content. Specifically, the privileged process does not directly rely on the interfaces provided by the rendering process within the sandbox; instead, it uses its own system-level privileges to call image capture interfaces provided by the operating system or browser's underlying layer. These interfaces allow the privileged process to directly capture pixel data of the current webpage from the graphics buffer or display memory, ensuring that the captured image is the real, complete content seen by the user and is unaffected by malicious scripts within the sandbox. The captured rendering image is then securely stored in a private linear memory space managed by the privileged process. This storage method further enhances data security, preventing unauthorized access or tampering of the rendering image data by other processes. Through this mechanism, this application ensures the authenticity and integrity of the rendered image data upon which subsequent semantic comparisons rely, providing a solid data foundation for trusted front-end blockchain interaction and significantly improving the security and reliability of the entire interaction process.

[0065] In S103, the event is submitted via either the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen.

[0066] In this embodiment of the application, the blockchain interaction system includes a semantic comparison model. Based on this model, the "submission of events via or circuit breaking based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen" can be achieved in the following manner, as detailed below: Using a semantic comparison model, the underlying data and the current webpage rendering screen are obtained from the private linear memory space, and the first semantic corresponding to the underlying data and the second semantic corresponding to the current webpage rendering screen are identified. The edit distance between the first semantic and the second semantic is determined, and / or, key field values ​​are compared between the first semantic and the second semantic, and / or, structured semantic matching is performed between the first semantic and the second semantic. Based on the edit distance, and / or the results of the key field value comparison, and / or the results of the structured semantic matching, a submission event is triggered via either a circuit breaker or a submission event.

[0067] Semantic comparison models are computational models used to analyze and compare the semantic content of text or data. They can be rule-based, machine learning-based, or a hybrid approach. As the core component for performing semantic analysis and comparison, this model is responsible for transforming raw data and rendered images into comparable semantic representations and performing subsequent comparison operations.

[0068] Retrieving underlying data and the current webpage rendering from a private linear memory space separately aims to ensure that the acquired data is tamper-proof and isolated, providing reliable input for subsequent semantic comparison. This can be achieved by directly accessing data blocks pre-stored in a specific private linear memory region via memory addresses, or by reading data from protected memory segments through a secure memory access interface provided by the operating system.

[0069] Identifying the primary semantics of the underlying data and the secondary semantics of the current webpage rendering serves to transform the raw underlying data and rendering into semantic representations that can be processed by the semantic comparison model. For example, for underlying data, its structure (such as JSON or XML) can be parsed, key fields and their values ​​extracted, and structured semantics generated in conjunction with predefined business rules; for the rendering, optical character recognition (OCR) technology can be used to extract text content, key areas can be identified in conjunction with layout analysis, and it can be transformed into an understandable semantic description.

[0070] Determining the edit distance between the first and second semantics is used to quantify the degree of difference between two semantic strings or sequences. This can be achieved using the Levenshtein distance algorithm, which calculates the minimum number of single-character edits required to transform one string into another.

[0071] The comparison of key field values ​​between the first and second semantic meanings aims to verify the consistency of values ​​for key business fields in structured data. This can be achieved by predefining a set of key fields (such as transaction amount, payee account, product name, etc.) and then directly comparing whether the values ​​of these fields in the first and second semantic meanings match exactly, or by allowing value comparisons within a preset error range.

[0072] Structured semantic matching is performed on the first and second semantics to compare whether the overall structure and logical relationships of the two semantics are consistent. This can be achieved by constructing a semantic tree or semantic graph and then comparing whether the topological structure and node content of the two trees or graphs are consistent, or by defining a set of semantic rules and checking whether the first and second semantics both conform to these rules and whether the correlation between the rules is consistent.

[0073] After determining the edit distance between the first and second semantics, and / or, the result of the key field numerical comparison, and / or, the result of the structured semantic matching, the following method can be used to "break the commit event based on the edit distance, and / or, the result of the key field numerical comparison, and / or, the result of the structured semantic matching," detailed below: If the edit distance is greater than the preset distance threshold, or if the result of the key field value comparison shows that the difference between the key field value of the first semantic and the key field value of the second semantic is greater than the preset difference threshold, or if the result of the structured semantic matching shows that the first semantic and the second semantic have semantic structure separation, then the circuit breaker submission event will be aborted; otherwise, the submission event will be aborted.

[0074] In semantic comparison, edit distance is used to quantify the similarity between the first and second semantic elements in text content. A preset distance threshold is a value pre-set by the system; when the calculated edit distance exceeds this threshold, it indicates that the difference between the two semantic elements is too large, potentially suggesting tampering or inconsistency.

[0075] Key field numerical comparison refers to identifying and extracting fields with significant business implications from both the primary and secondary semantics (such as transaction amount, payee account, and product quantity), and then comparing the values ​​of these key fields. The degree of difference is an indicator that measures the inconsistency between these key field values; it can be a percentage difference or an absolute value difference. The preset degree of difference threshold is a value pre-set by the system. When the degree of difference in key field values ​​exceeds this threshold, it indicates significant inconsistencies in key business data, potentially suggesting malicious tampering or user input errors.

[0076] Structured semantic matching refers to the analysis and comparison of the overall structure, field order, and nesting relationships of the first and second semantics. Semantic structure separation refers to significant structural inconsistencies between two semantics, such as missing fields, disordered field order, data type mismatch, or the presence of unexpected additional fields. This separation indicates that data may have been tampered with during transmission or rendering, or that the user interface is inconsistent with the underlying data model.

[0077] A circuit breaker commit event refers to immediately interrupting or blocking a user-initiated commit operation when a potential security risk or data inconsistency is detected, preventing the operation from continuing and being written to the blockchain. This is a proactive security mechanism designed to protect the integrity of user assets and blockchain data. Circuit breaker operations can include issuing warnings to users, rolling back the current operation, or directly terminating the session. A successful commit event, on the other hand, means that when the semantic comparison results meet preset security and consistency standards, the user-initiated commit operation is allowed to continue execution, and the relevant data is ultimately written to the blockchain. This indicates that the system has confirmed that the current commit operation is trustworthy and meets expectations.

[0078] This application's solution addresses the problem of accurate decision-making after semantic comparison by establishing clear semantic comparison judgment criteria. Specifically, after obtaining the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering, the system executes edit distance calculation, key field value comparison, and structured semantic matching in parallel or sequentially. These three comparison mechanisms comprehensively evaluate the consistency of the two semantics from different dimensions (text content similarity, core business data consistency, and data structure integrity). If the difference in any of these dimensions exceeds a preset safety threshold (i.e., the edit distance is greater than the preset distance threshold, or the key field value difference is greater than the preset difference threshold, or semantic structure separation occurs), the system will immediately determine that there is a risk and execute the circuit breaker submission event. Conversely, only when the comparison results of all three dimensions are within the safety threshold—that is, the edit distance does not exceed the threshold, the key field value difference does not exceed the threshold, and no semantic structure separation occurs—will the system determine that the submission event is credible and allow it to pass. This multi-dimensional and rigorous judgment logic ensures that only fully verified and highly consistent submission events can enter the subsequent blockchain processing flow, thereby effectively avoiding misjudgments or security vulnerabilities that may be caused by a single judgment standard, and significantly improving the security and reliability of blockchain interaction.

[0079] Through the aforementioned technical solution, this application enables multi-dimensional and refined semantic analysis and comparison of underlying data and the rendered screen seen by the user. This method can detect not only simple numerical tampering but also subtle differences in text content, as well as deeper structural or logical inconsistencies. The dual verification mechanism combining underlying data and rendered screen significantly improves the security and credibility of blockchain front-end interactions. The promise of "what you see is what you get" is effectively guaranteed, thereby effectively preventing asset losses caused by malicious scripts tampering with transaction information, phishing attacks, or user misoperation. This solution provides a robust security barrier for blockchain applications while ensuring transaction transparency and the user's right to know.

[0080] In some embodiments described above, this application proposes a method that, when a user triggers a submission event, suspends the redirection behavior, obtains underlying data, and captures the currently rendered webpage. Then, it compares the first semantics corresponding to the underlying data with the second semantics corresponding to the currently rendered webpage to determine whether to approve or abort the submission event. However, in practical applications, even if the submission event is approved, there may still be a need to trace and prove the authenticity and integrity of the underlying data and the user's view at the time the submission event occurred. If a reliable mechanism is lacking to solidify and prove this crucial information, challenges may arise in subsequent audits or dispute resolution processes, affecting the credibility of the entire interaction process.

[0081] In response, this application further proposes that after submitting an event by passing or breaking the circuit breaker based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen, the method further includes: constructing a Merkle tree based on the hash corresponding to the underlying data, the hash corresponding to the current webpage rendering screen, and the hash corresponding to the security salt of the submission event; and determining the Merkle root corresponding to the Merkle tree by recursively operating on each node of the Merkle tree; the Merkle root is used to provide evidence for the submission event.

[0082] The hashes corresponding to the underlying data, the current webpage rendering, and the security salt of the submitted event are all fixed-length strings of characters generated by applying a cryptographic hash function to the original data. Cryptographic hash functions possess characteristics such as one-wayness, collision resistance, and avalanche effect. This means that the original data cannot be deduced from the hash value, the probability of different data producing the same hash value is extremely low, and even minor changes to the original data can lead to significant changes in the hash value.

[0083] Constructing a Merkle tree is a type of hash tree where leaf nodes store the hash values ​​of data blocks, and non-leaf nodes store the hash values ​​of their child nodes. This tree structure can efficiently verify the integrity and consistency of large-scale data.

[0084] The core process of constructing a Merkle tree is to perform recursive operations on each node. This involves starting from a leaf node, concatenating two adjacent hash values, and then performing another hash operation to generate the hash value of its parent node. This process is repeated until a unique root hash value is generated.

[0085] Determining the Merkle root of a Merkle tree means that the Merkle root is the top hash value of the Merkle tree, which combines information from the hash values ​​of all leaf nodes. Any change to the data in any leaf node will cause a change in the Merkle root.

[0086] For example, a Merkle tree can be constructed as follows: the left leaf nodes of the Merkle tree can be constructed using the hashes corresponding to the underlying data and the change history audit hashes; the right leaf nodes of the Merkle tree can be constructed using the hashes corresponding to the current webpage rendering and the hashes of the second semantic digest; and the top perturbation factor of the Merkle tree can be constructed using the security salts corresponding to the submission events. Here, the change history audit hash refers to stringing together the entire process of each data modification into an immutable, traceable, and auditable "change fingerprint chain."

[0087] In one possible implementation, the change history audit hash can be determined by recording the change history of the underlying data through an underlying data change monitor (such as MutationObserver) and calculating the change history audit hash based on the change history of the underlying data.

[0088] In the aforementioned method, a semantic comparison mechanism is used to decide whether to approve or reject a submission event, ensuring data consistency during the interaction process. Building upon this, to further enhance the traceability and verifiability of submission events, this application introduces a Merkle tree construction and Merkle root determination mechanism. Specifically, after a submission event is approved or rejected, the system immediately performs hash operations on the underlying data constituting the core elements of the submission event, the current webpage rendering, and the security salt used to enhance security, generating their respective encrypted fingerprints. Subsequently, these independent hash values ​​are used as leaf nodes, and according to the Merkle tree construction rules, they are recursively aggregated upwards through the hash values ​​of adjacent nodes, ultimately generating a unique Merkle root. This Merkle root encapsulates the integrity and order of all key information at the time of the submission event in a compact and encrypted manner. Any minor modification to the underlying data, webpage rendering, or security salt will result in a recalculated Merkle root that is inconsistent with the original Merkle root, thus enabling immediate detection of data tampering. Therefore, the Merkle root can serve as irrefutable cryptographic evidence of the state at the time of the submission event, greatly enhancing the transparency, auditability, and non-repudiation of the entire blockchain interaction process, and providing a solid technical foundation for subsequent dispute resolution and compliance review.

[0089] This application further proposes that after determining the Merkle root corresponding to the Merkle tree, the Merkle root is digitally signed through the underlying encryption interface of the target browser, and the Merkle root and the corresponding digital signature are uploaded to the target blockchain. The underlying data and the current webpage rendering screen are encrypted and stored on a preset server.

[0090] The underlying encryption interface refers to a low-level API or functional module provided by the target browser, used to perform security operations such as encryption, decryption, and digital signatures. Its purpose is to provide secure and reliable encryption services, ensuring the authenticity and non-repudiation of digital signatures.

[0091] Digital signatures are a technique based on public-key cryptography used to verify data integrity, sender identity, and prevent repudiation. They encrypt data (or its hash) using the sender's private key, and the recipient can decrypt and verify the data using the sender's public key.

[0092] A target blockchain refers to a decentralized ledger system used to store transaction records, smart contracts, or other data, and maintained by distributed nodes.

[0093] A pre-configured server is a network server that is pre-configured to store specific data.

[0094] This application's scheme provides a preliminary evidentiary basis for trusted interaction by performing semantic analysis and consistency verification on the submitted event and generating a Merkle root representing key information of the event. Based on this, to solidify the Merkle root as undeniable evidence, it first digitally signs the Merkle root through the target browser's underlying encryption interface. This interface utilizes the browser's built-in security mechanisms or the encryption services provided by the operating system to ensure the signing process takes place in a protected environment, thus guaranteeing the authenticity and validity of the digital signature and proving that the Merkle root was indeed confirmed and generated by the user in a specific browser environment. Subsequently, the Merkle root and its corresponding digital signature are uploaded to the target blockchain. The decentralized, immutable, and timestamped characteristics of the blockchain provide a highly trusted storage and verification environment for the Merkle root and its signature. Once uploaded to the chain, this information becomes a permanent record, unalterable by anyone, and its generation time can be traced at any time. Simultaneously, to protect user privacy and data security, the original underlying data and the current webpage rendering are encrypted before being uploaded to the blockchain. This encrypted data is then stored on a pre-set server. This mechanism combines the immutability of on-chain evidence with the privacy protection of off-chain data, forming a complete, credible, and traceable chain of evidence. When evidence is required, the integrity and origin of the data can be verified through the on-chain Merkle root and signature, and the encrypted original data can be obtained through a pre-set server for decryption and verification. This effectively solves the limitation of only generating Merkle roots without solidifying and protecting the evidentiary information.

[0095] As can be seen from the above, this method demonstrates a significant contribution in terms of technical conception. Specifically, traditional blockchain evidence preservation methods typically only focus on the immutability of on-chain data, while lacking effective protection for the security of pre-chain data, especially data in the front-end environment. When malicious attackers use front-end spoofing techniques to make the page seen by the user inconsistent with the actual underlying data submitted, traditional methods cannot identify this "pre-chain data blind spot" problem, which may ultimately lead to the irreversible recording of tampered "fake data" on the blockchain. This method fundamentally solves this problem by simultaneously acquiring the underlying data and capturing the rendered webpage when the user submits an event, and then performing a semantic comparison between the two.

[0096] Furthermore, this method provides multimodal evidence for future judicial proceedings by capturing the rendered webpage. In the event of a dispute, not only is the underlying data presented as evidence, but the visual images actually seen by the user also serve as supporting evidence. This significantly enhances the integrity and credibility of the evidence chain, solving the problem of traditional blockchain-based evidence storage lacking multimodal evidence in judicial proceedings. Therefore, this method represents a significant technological advancement in ensuring the credibility of front-end blockchain data, preventing front-end attacks, and providing comprehensive evidence.

[0097] Based on the blockchain pre-chain trusted interaction method provided in the above embodiments, this application further provides a blockchain pre-chain trusted interaction device for implementing the above method embodiments. This blockchain pre-chain trusted interaction device is applied to a blockchain interaction system. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This application provides a schematic diagram of the structure of a blockchain front-end trusted interaction device, as shown in the embodiments. Figure 2 As shown, the blockchain's front-chain trusted interaction device 20 may include: a first data acquisition unit 21, a second data acquisition unit 22, and an event processing unit 23. Wherein: The first data acquisition unit 21 is used to suspend the jump behavior of the submission event when the user triggers the submission event, and to acquire the underlying data corresponding to the submission event.

[0098] The second data acquisition unit 22 is used to capture the current webpage rendering screen corresponding to the submission event after the jump behavior of the suspended submission event is suspended.

[0099] The event handling unit 23 is used to submit events via or circuit breaking based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen.

[0100] Optionally, the blockchain interaction system includes a trusted probe, a business server, and an end-side trusted host. The trusted probe is used to suspend redirection behavior and obtain underlying data. The trusted probe achieves the highest running priority through the following methods: In a controlled engineering scenario, a trusted probe is injected into the response stream via the business server, and a dynamic random security token is sent to the trusted probe via the business server. The target browser is also controlled to block unauthorized external scripts. In uncontrolled engineering scenarios, a trusted probe is injected into the front end of the target webpage's code before the target webpage's network traffic is parsed by the target browser, through a trusted host on the client side, so that the target webpage corresponds to the current webpage rendering screen.

[0101] Optionally, the blockchain interaction system also includes a notarization backend; the first data acquisition unit 21 is specifically used for: After freezing the underlying functionality of the target browser and wrapping the underlying data corresponding to the submission event with the proxy object of the trusted probe, the security salt corresponding to the submission event is obtained from the evidence storage backend, and the underlying data and security salt corresponding to the submission event are stored in a private linear memory space.

[0102] Optionally, the blockchain interaction system includes a browser privileged process; the second data acquisition unit 22 is specifically used for: By using a privileged browser process, the front-end webpage sandbox corresponding to the submission event is bypassed, and the image capture interface corresponding to the privileged browser process is used to capture the current webpage rendering screen and store the current webpage rendering screen in a private linear memory space.

[0103] Optionally, the blockchain interaction system includes a semantic comparison model, and the event processing unit 23 is specifically used for: Using a semantic comparison model, the underlying data and the current webpage rendering screen are obtained from the private linear memory space, and the first semantic corresponding to the underlying data and the second semantic corresponding to the current webpage rendering screen are identified. Determine the edit distance between the first semantic and the second semantic, and / or perform a key field numerical comparison between the first semantic and the second semantic, and / or perform structured semantic matching between the first semantic and the second semantic; Based on edit distance, and / or the results of key field numerical comparison, and / or the results of structured semantic matching, pass or circuit breaker submission events.

[0104] Optionally, the event handling unit 23 is specifically used for: If the edit distance is greater than the preset distance threshold, or if the result of the key field value comparison shows that the difference between the key field value of the first semantic and the key field value of the second semantic is greater than the preset difference threshold, or if the result of the structured semantic matching shows that the first semantic and the second semantic have semantic structure separation, then the circuit breaker submission event will be aborted; otherwise, the submission event will be aborted.

[0105] Optionally, the blockchain's front-chain trusted interaction device 20 may also include a Merkle tree building block, wherein: Merkle tree building blocks are specifically used for: Based on the hashes corresponding to the underlying data, the hashes corresponding to the current webpage rendering, and the hashes corresponding to the security salts of the submitted events, a Merkle tree is constructed. The Merkle root of the Merkle tree is determined by recursively calculating each node of the Merkle tree. The Merkle root is used to provide evidence for the submitted events.

[0106] Optionally, Merkle tree building blocks are also specifically used for: The Merkle root is digitally signed using the target browser's underlying encryption interface. The Merkle root and its corresponding digital signature are then uploaded to the target blockchain. The underlying data and the current webpage rendering are encrypted and stored on a preset server.

[0107] It should be noted that the information interaction and execution process between the above-mentioned units are based on the same concept as the method embodiments of this application. Their specific functions and technical effects can be referred to the method embodiments section, and will not be repeated here.

[0108] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 provided in this embodiment may include: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program corresponding to the pre-chain trusted interaction method of blockchain. When the processor 30 executes the computer program 32, it implements the steps described above in the embodiment of the pre-chain trusted interaction method applied to blockchain, for example... Figure 1 S101~S103 are shown. Alternatively, when processor 30 executes computer program 32, it implements the functions of each module / unit in the above-described blockchain pre-chain trusted interaction device embodiment, for example... Figure 2 The functions of units 21-23 shown.

[0109] For example, computer program 32 can be divided into one or more modules / units, one or more of which are stored in memory 31 and executed by processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of computer program 32 in electronic device 3. For example, computer program 32 can be divided into a first data acquisition unit 21, a second data acquisition unit 22, and an event processing unit 23. For the specific functions of each unit, please refer to... Figure 2 The relevant descriptions in the corresponding embodiments are not repeated here.

[0110] Those skilled in the art will understand that Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or use different components.

[0111] The processor 30 can be a central processing unit (CPU), a graphics processing unit (GPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0112] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, or flash card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.

[0113] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units is merely an example. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the blockchain's front-end trusted interaction device can be divided into different functional units to complete all or part of the functions described above. The functional units in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0114] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.

[0115] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.

[0116] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, refer to the relevant descriptions of other embodiments.

[0117] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0118] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A pre-chain trusted interaction method for blockchain, characterized in that, The method, applied to a blockchain interaction system, includes: When a user triggers a submit event, the redirection behavior of the submit event is suspended, and the underlying data corresponding to the submit event is obtained. After suspending the redirection behavior of the submitted event, capture the current webpage rendering screen corresponding to the submitted event; Based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen, the submission event is either triggered or circuit-broken.

2. The method according to claim 1, characterized in that, The blockchain interaction system includes a trusted probe, a business server, and a trusted client-side host. The trusted probe is used to suspend the redirection behavior and obtain the underlying data. The trusted probe achieves the highest running priority through the following methods: In a controlled engineering scenario, the trusted probe is preferentially injected into the response stream through the business server, and a dynamic random security token is sent to the trusted probe through the business server, while the target browser is controlled to block unauthorized external scripts. In uncontrolled engineering scenarios, the trusted probe is injected into the front end of the target webpage's code before the target browser parses the network traffic of the target webpage through the trusted host on the end side. The target webpage corresponds to the current webpage rendering screen.

3. The method according to claim 2, characterized in that, The blockchain interaction system also includes a notarization backend; obtaining the underlying data corresponding to the submission event includes: After freezing the underlying functionality of the target browser and wrapping the underlying data corresponding to the submission event with the proxy object of the trusted probe, the security salt corresponding to the submission event is obtained from the evidence storage backend, and the underlying data corresponding to the submission event and the security salt are stored in a private linear memory space.

4. The method according to claim 1, characterized in that, The blockchain interaction system includes a browser privileged process; the step of capturing the current webpage rendering screen corresponding to the submission event includes: By using the privileged browser process, the front-end webpage sandbox corresponding to the submission event is bypassed, and the image capture interface corresponding to the privileged browser process is used to capture the current webpage rendering screen and store the current webpage rendering screen in a private linear memory space.

5. The method according to claim 1, characterized in that, The blockchain interaction system includes a semantic comparison model. The step of triggering or circuit breaking the submission event based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen includes: Using the semantic comparison model, the underlying data and the current webpage rendering screen are obtained from the private linear memory space, and the first semantic corresponding to the underlying data and the second semantic corresponding to the current webpage rendering screen are identified. Determine the edit distance between the first semantic and the second semantic, and / or perform a key field numerical comparison between the first semantic and the second semantic, and / or perform structured semantic matching between the first semantic and the second semantic; Based on the edit distance, and / or the result of the key field numerical comparison, and / or the result of the structured semantic matching, the submit event is either bypassed or circuited.

6. The method according to claim 5, characterized in that, The step of triggering or circumventing the submission event based on the edit distance, and / or the result of the key field numerical comparison, and / or the result of the structured semantic matching includes: If the edit distance is greater than a preset distance threshold, or if the result of the key field value comparison shows that the difference between the key field value of the first semantic and the key field value of the second semantic is greater than a preset difference threshold, or if the result of the structured semantic matching shows that the first semantic and the second semantic have a semantic structure separation phenomenon, then the submission event is aborted; otherwise, the submission event is passed.

7. The method according to any one of claims 1 to 6, characterized in that, After the method verifies or circuit-breaks the submission event based on the first semantics corresponding to the underlying data and the second semantics corresponding to the current webpage rendering screen, the method further includes: A Merkle tree is constructed based on the hash corresponding to the underlying data, the hash corresponding to the current webpage rendering screen, and the hash corresponding to the security salt of the submission event. The Merkle root of the Merkle tree is determined by recursively calculating each node of the Merkle tree. The Merkle root is used to provide evidence for the submission event.

8. The method according to claim 7, characterized in that, After determining the Merkle root corresponding to the Merkle tree, the method further includes: The Merkle root is digitally signed using the underlying encryption interface of the target browser, and the Merkle root and its corresponding digital signature are uploaded to the target blockchain. The underlying data and the current webpage rendering are encrypted and stored on a preset server.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step of the pre-chain trusted interaction method for the blockchain as described in any one of claims 1 to 8.

10. A computer program product, characterized in that, When the computer program product is executed by a processor, it implements the steps of the pre-chain trusted interaction method for the blockchain as described in any one of claims 1 to 8.

Images