A blockchain-based behavior traceable method, system, electronic device and storage medium

Abstract

This invention relates to the technical field of blockchain, and in particular provides a blockchain-based method, system, electronic device, and storage medium for traceable behavior. The method involves each node in the blockchain network checking whether a target message exists in its confirmed hash set before writing it into a block. The confirmed hash set refers to the set of dispatch messages that the node has already broadcast. If the check confirms that the target message does not exist in the confirmed hash set, the target message is added to the block to be generated. If the check confirms that the target message exists in the confirmed hash set, adding the target message to the block to be generated is stopped to prevent message duplication. This invention has the potential to be repeatedly executed in different forked blocks, ensuring ledger consistency in a decentralized construction environment.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, and in particular to a blockchain-based method, system, electronic device, and storage medium for traceable behavior. Background Technology

[0002] As internet technology continues to penetrate traditional industries, purchasing insurance through online platforms has gradually become a mainstream choice for consumers. However, if online platforms fail to meticulously record user activity, it becomes difficult to quickly pinpoint the source of disputes in the event of an incident. This is especially true when dealing with sensitive information such as payment records, which can easily lead to conflicts. To address this issue, the China Banking and Insurance Regulatory Commission (CBIRC) issued the "Measures for the Supervision of Internet Insurance Business" in December 2020. These measures require insurance institutions to utilize effective technological means to verify the authenticity of policyholders' identity information and to comprehensively record and retain key business processes for internet insurance, such as product sales page content, policyholder activity logs, and claims and complaint service records, to ensure the traceability of the entire process.

[0003] To comply with regulatory requirements, insurance companies have launched traceable systems for the insurance sales industry (hereinafter referred to as traceability systems). Taking a visual traceability system developed by a certain company as an example, this system can capture the dynamic changes of DOM elements on a webpage in real time and store these changes in a database. When an insurance company needs to query the operation records of an insured customer, the system uses data visualization technology to replay the user's actions on the webpage in the order of execution and converts them into an MP4 video file for easy review by the insurance company.

[0004] The existing technology has the following key drawbacks: 1. Centralized storage leads to insufficient data security and trustworthiness; Traditional backtracking systems often use centralized servers to store user behavior data, which poses risks of data tampering, deletion, or leakage. For example, centralized databases in financial institutions have repeatedly experienced insider tampering with transaction records, leading to regulatory compliance risks. While blockchain technology possesses the characteristic of immutability, existing blockchain backtracking systems do not deeply integrate behavioral data with the blockchain; they simply upload hash values ​​to the chain, while the original data remains stored in a centralized database, failing to fundamentally solve the data trustworthiness problem.

[0005] 2. The amount of backtracking data is large, and the storage and transmission efficiency is low; Mainstream behavior recording technologies record the page DOM structure and user interactions through "snapshots + operation commands." While this avoids the redundancy of full-screen screenshots, it still generates a large amount of data. Existing systems mostly use general compression algorithms that are not optimized for the characteristics of the DOM structure, such as the tag tree and operation command sequences. This results in low compression rates, leading to high storage costs and large transmission latency. In particular, in multi-node synchronization scenarios of consortium blockchains, data synchronization efficiency becomes a bottleneck.

[0006] 3. Consensus mechanisms struggle to balance fault tolerance and efficiency; The consensus mechanism of a blockchain system determines the allocation of accounting rights and data consistency. While the traditional PBFT algorithm can tolerate one-third of malicious nodes, in consortium blockchains (such as multi-node networks composed of insurance institutions and regulatory nodes), as the number of nodes increases, the number of consensus rounds increases, leading to a decrease in transaction throughput and making it unable to meet the needs of high-concurrency behavior backtracking.

[0007] To address the shortcomings of existing technologies, a blockchain-based method, system, electronic device, and storage medium for traceable behavior are provided. Summary of the Invention

[0008] To achieve the above objectives, the present invention adopts the following technical solution: One aspect of the present invention provides a blockchain-based method for traceable behavior, comprising the following steps: Before writing a target message into a block, each node in the blockchain network checks whether the target message exists in the node's confirmed hash set, where the confirmed hash set refers to the set of dispatch messages that the node has already broadcast. If it is confirmed through inspection that the target message does not exist in the confirmed hash set, then the target message is added to the block to be generated; If the target message is confirmed to exist in the confirmed hash set, then adding the target message to the block to be generated will be stopped to prevent message duplication.

[0009] In one optional implementation, prior to the step of adding the target message to the block to be generated, a pre-broadcast and verification step is further included: Any node in the blockchain network acts as a block building node. After completing the block building of the target message, it generates a pre-prepared message and broadcasts it to other nodes in the network. The pre-prepared message includes a view number, a block number, a block hash value, and the target message. Other nodes that receive the pre-prepared message verify the pre-prepared message. The verification includes verifying the legality of the block format, the correctness of the block hash value, the validity of the block signature, and the compliance of the node access permissions. If the verification passes, the process proceeds to the preparation phase; if the verification fails, the consensus process for the current block ends.

[0010] In one optional implementation, after the step of entering the Prepare phase, a message collection preparation step is further included: The node that passes the pre-prepared message verification sends a preparation message to other nodes in the network. The preparation message includes the view number, the block number, the block hash value, and the node ID that sent the preparation message. The node continuously collects preparation messages sent by other nodes and determines whether a preset number of valid preparation messages have been collected. If the preset number of valid preparation messages are not collected, the current consensus process ends; if the preset number of valid preparation messages are collected, the allocation phase begins.

[0011] In one optional implementation, the preset number is 2f, where f is the maximum number of malicious nodes that the system can tolerate, and the total number of nodes N in the system satisfies N≥3f+1; The determination of whether a preset number of valid preparation messages have been collected specifically involves determining whether preparation messages have been received from 2f different replica nodes, excluding the current node itself.

[0012] In one optional implementation, after the step of entering the allocation phase, a step of broadcasting and collecting allocation messages is further included: Nodes that meet the preparation phase conditions broadcast a relocation message to the entire network. The relocation message includes the view number, the block number, the hash digest of the target message, and the node ID that sent the relocation message. The node continuously collects allocation messages from the entire network and determines whether it has collected 2f+1 valid allocation messages, including its own. If 2f+1 valid allocation messages, including one's own, are collected, the consensus condition is confirmed, and the process enters the verification phase of writing the message into the block.

[0013] In one optional implementation, the step of checking whether the target message already exists in the node's confirmed hash set specifically includes: Calculate the hash value of the target message to be written; Search the locally stored set of confirmed hashes for a record that has the same hash value as the target message to be written. If the search is successful, it is determined that the target message already exists in the confirmed hash set of that node; If no match is found, it is determined that the target message does not exist in the confirmed hash set of that node.

[0014] In one optional implementation, the update and maintenance step of the confirmed hash set includes: When a node broadcasts a dispatch message about a certain message to the entire network, it immediately adds the hash value of that message to the local confirmed hash set. Alternatively, when a node determines to reject the allocation confirmation of a certain message, it adds the hash value of the message to the local confirmed hash set and marks it to distinguish between the confirmed and rejected states. If it is determined during the inspection phase that the target message already exists in the confirmed hash set of the node, the node generates and broadcasts a rejection response message containing a duplicate processing prompt to the block building node. The rejection response message contains the hash value and duplicate identifier of the target message. After adding the target message to the block to be generated, it also includes: The block containing the target message is permanently written to the blockchain ledger; Execute the business request corresponding to the target message, and update the status of the business execution result to the local state machine; The business execution results are used to generate a backtracking record, which includes the hash value of the target message, the execution timestamp, and the digital signature of the execution node. The backtracking record is then stored in a preset audit log. The method for storing the backtracking records includes: Merkle tree structure is used to aggregate multiple backtracking records within a preset time window to generate a Merkle root; Merkle root is embedded into the subsequently generated block header to enable rapid verification and tamper-proof backtracking of the historical state of business behavior; The confirmed hash set is managed using a time-based sliding window mechanism, retaining only hash records within a preset time period, or maintaining the set within the consensus period corresponding to the current view number. When the view number is updated, the set is archived or cleared. Before archiving or clearing the confirmed hash set, the node generates a state snapshot of the list of hash values ​​in the current set and synchronizes the state snapshot to at least one backup node in the network to prevent the loss of historical confirmed data due to node failure. In the pre-preparation broadcast and verification steps, the verification of the block signature validity adopts a multi-signature algorithm or an aggregate signature algorithm. The node confirms the identity and legitimacy of all initiating nodes at once by verifying the aggregate signature packet, so as to reduce the computational overhead in the verification process. The dispatch message also includes the expected state hash of the node's execution result of the target message; After determining whether 2f+1 valid allocation messages, including its own, have been collected, a consistency check step is also included, which compares whether the expected state hashes in all collected allocation messages are consistent. If there is a discrepancy, the node with abnormal behavior will be identified, and the inconsistent state will be recorded in the abnormal behavior blacklist, triggering the penalty mechanism for the abnormal node.

[0015] According to one aspect of the present invention, a blockchain-based behavior traceability system is provided, comprising: The deployment environment module is used to enable flexible deployment based on elastic computing services or physical servers and to expand system performance by dynamically adding computing resources. The data storage module, as the physical foundation of blockchain technology, defines the ledger data structure and the constituent elements of the blockchain, and is used to ensure the data integrity and security of the blockchain system. The P2P network module is based on a P2P network architecture to achieve decentralized operation and supports the broadcasting, verification and addition of new blocks to the main chain. The consensus processing module is used to manage node voting weights and the block proposal and verification process; The protocol support module provides support for blockchain network communication and operation, including node interconnection, data transmission and interface services; the smart contract module implements smart contract functions based on a microservice architecture, including backtracking management services and backtracking archiving services. The behavior backtracking module encapsulates the blockchain backtracking system and client, which is used to record user behavior by recording the page DOM structure and operation commands, and to compress the recorded data.

[0016] According to one aspect of the present invention, an electronic device is provided, comprising: At least one memory stores computer-executable instructions non-transiently; At least one processor, configured to run the computer-executable instructions, The computer-executable instructions, when executed by the processor, implement the aforementioned blockchain-based behavior traceability method. According to one aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer-executable instructions that, when executed by at least one processor, implement the aforementioned blockchain-based behavior traceability method.

[0017] Effects of the invention: 1. Effectively solves the problems of forking and duplicate processing in the masterless node mode: This invention eliminates the master node election mechanism in traditional PBFT, allowing all nodes to build blocks concurrently. While this improves system activity and resistance to single points of failure, it also introduces risks of forks and message duplication. By introducing a "confirmed hash set" and performing mandatory deduplication checks before writing blocks, this invention can effectively identify and filter messages that have already been confirmed across the entire network without master node coordination. This mechanism logically eliminates the possibility of the same transaction being executed repeatedly in different forked blocks, ensuring ledger consistency in a decentralized environment.

[0018] 2. Improve the accuracy and completeness of behavior retrospection: This invention combines rigorous signature verification, hash verification, and backtracking record generation mechanisms. By structurally recording information such as business execution results, timestamps, and node signatures in the audit log, and embedding them into the block header using a Merkle tree root, it achieves "full lifecycle" tracking of every action on the blockchain. Any node can quickly verify the authenticity and integrity of its actions at a specific moment through historical block headers, greatly enhancing the system's auditing capabilities and data credibility.

[0019] 3. Enhance the system's fault tolerance and security: This invention is based on an improved PBFT consensus process, retaining the 2f+1 fault tolerance feature, while optimizing the authentication process through multi-signature or aggregate signature algorithms. Furthermore, through anomaly behavior identification and punishment mechanisms, malicious nodes sending inconsistent Consensus messages can be promptly detected and isolated, further enhancing network security.

[0020] 4. Optimize resource utilization and reduce the consumption of ineffective consensus: By setting strict quantity thresholds during the Prepare and Commit phases, and in conjunction with pre-defined format validity checks, nodes can "stop the bleeding" as early as possible when processing invalid or malicious messages. In particular, the introduction of confirmed hash sets avoids nodes performing redundant consensus calculations and signature verifications on processed messages, saving network bandwidth and computing resources. Attached Figure Description

[0021] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart of a blockchain-based behavior traceability method provided in Embodiment 1 of the present invention; Figure 2 This is a framework diagram of a blockchain-based behavior traceability system provided in Embodiment 3 of the present invention; Figure 3 This is a comparison chart of the compression ratios of six commonly used compression algorithms provided in Embodiment 2 of the present invention; Figure 4 This is a comparison diagram of the compression of the four data structures provided in Embodiment 2 of the present invention; Figure 5 This is a comparison chart of the classic and optimized Brotli algorithms provided in Embodiment 2 of the present invention; Figure 6 The flowchart of the optimized PBFT algorithm provided in Embodiment 2 of the present invention is shown below; Figure 7 This is a block diagram of the electronic device provided in Embodiment 4 of the present invention; Figure 8 This is a block diagram of a computer-readable storage medium provided in Embodiment 4 of the present invention. Detailed Implementation

[0022] The technical solutions of the present invention will now be described with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0023] Hereinafter, the terms "first," "second," etc., are used for descriptive convenience 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 with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0024] In this invention, unless otherwise explicitly specified and limited, the term "connection" should be interpreted broadly. For example, "connection" can be a fixed mechanical connection, a detachable mechanical connection, or an integral part; or, "connection" can be a direct connection or an indirect connection through an intermediate medium. Furthermore, unless otherwise explicitly specified and limited, the term "coupling" should be interpreted broadly. For example, "coupling" can be a direct electrical connection, such as physical contact and electrical conduction between two components; it can also be understood as an electrical connection between different components in a circuit structure through physical lines capable of transmitting electrical signals, such as copper foil or wires on a printed circuit board (PCB), to transmit electrical signals; or, "coupling" can be an indirect electrical connection between two components through an intermediate medium; or, "coupling" can be an electrical connection between two components in a non-contact manner, such as an electrical connection between two components using capacitive coupling to transmit electrical signals.

[0025] In this embodiment of the invention, directional terms such as "up," "down," "left," and "right" may be defined relative to the orientation of the components shown in the accompanying drawings. It should be understood that these directional terms can be relative concepts, used for relative description and clarification, and can change accordingly depending on the orientation of the components in the accompanying drawings.

[0026] Example 1: like Figure 1 As shown, this embodiment of the invention provides a blockchain-based method for traceable behavior, comprising the following steps: Step S100: Before writing message m into a block, each node in the blockchain network checks whether message m exists in the node's confirmed hash set, where the confirmed hash set refers to the set of commit messages that the node has broadcast. Step S200: If it is confirmed through inspection that the message m does not exist in the confirmed hash set, then add the message m to the block to be generated; Step S300: If it is confirmed through inspection that the message m exists in the confirmed hash set, then stop adding the message m to the block to be generated to prevent message duplication.

[0027] In the above embodiments, when using rrweb technology to record data, the generated data volume is relatively large. After comparing various compression algorithms, the Brotli algorithm was ultimately selected for data compression. Furthermore, this proposal also features a carefully selected Brotli dictionary. In addition, considering that the Brotli algorithm has a good compression effect on byte arrays, the backtracking data is first converted into a byte array, and then the Brotli algorithm is used to compress the converted byte array.

[0028] The initial weight of each node is determined based on its historical success rate of block proposals (or historical success rate of block verification). During the operation of the blockchain, the weight of each node is dynamically adjusted based on its latest performance (i.e., latest success rate). This weight is used to determine the voting weight of a node, and nodes with higher voting weights can propose or verify blocks first.

[0029] This method does not broadcast new blocks through a single master node; instead, each node can broadcast new blocks. However, this may lead to forking issues. To further address these issues, each node checks whether message m already exists in its confirmed hash set (the confirmed hash set refers to the set of messages that the node has already broadcast committed) before writing message m into the block. Only if message m does not exist in this set can it be added to the block.

[0030] Example 2: like Figures 3-6 As shown, based on Embodiment 1, this embodiment of the invention further includes a Pre-Prepare broadcast and verification step before the step of adding message m to the block to be generated: Any node in the blockchain network acts as a block building node. After completing the block building of the message m, it generates a Pre-Prepare message and broadcasts it to other nodes in the network. The Pre-Prepare message includes the view number v, the block number n, the block hash value d, and the message m. Other nodes that receive the Pre-Prepare message verify the Pre-Prepare message, including verifying the validity of the block format, the correctness of the block hash value, the validity of the block signature, and the compliance of the node's access permissions. If the verification passes, the process proceeds to the Prepare stage; if the verification fails, the consensus process for the current block ends.

[0031] In one optional implementation, after the step of entering the Prepare phase, a Prepare message collection step is further included: The node that passes the verification of the Pre-Prepare message sends a Prepare message to other nodes in the network. The Prepare message includes the view number v, the block number n, the block hash value d, and the node ID that sent the Prepare message. The node continuously collects Prepare messages sent by other nodes and determines whether a preset number of valid Prepare messages have been collected. If the preset number of valid Prepare messages are not collected, the current consensus process ends; if the preset number of valid Prepare messages are collected, the process enters the Commit phase.

[0032] In one optional implementation, the preset number is 2f, where f is the maximum number of malicious nodes that the system can tolerate, and the total number of nodes N in the system satisfies N≥3f+1; The determination of whether a preset number of valid Prepare messages have been collected specifically involves determining whether Prepare messages have been received from 2f different replica nodes, excluding the current node itself.

[0033] In one optional implementation, after the step of entering the Commit phase, a Commit message broadcasting and collection step is further included: Nodes that meet the Prepare phase conditions broadcast a Commit message to the entire network. The Commit message includes the view number, the block number, the hash digest of message m, and the node ID that sent the Commit message. The node continuously collects commit messages from the entire network and determines whether it has collected 2f+1 valid commit messages, including its own. If 2f+1 valid commit messages, including one of your own, are collected, the consensus condition is confirmed, and the process proceeds to the verification phase of writing the message into the block.

[0034] In one optional implementation, the step of checking whether the message m already exists in the confirmed hash set of the node specifically includes: Calculate the hash value of the message m to be written; Search the locally stored set of confirmed hashes for a record that has the same hash value as the message m to be written. If the search is successful, it is determined that the message m already exists in the confirmed hash set of that node; If no match is found, it is determined that the message m does not exist in the confirmed hash set of this node.

[0035] In one optional implementation, the update and maintenance step of the confirmed hash set includes: When a node broadcasts a commit message about a certain message to the entire network, it immediately adds the hash value of that message to the local set of confirmed hashes. Alternatively, when a node determines to reject the Commit confirmation of a message, it adds the hash value of the message to the local set of confirmed hashes and marks it to distinguish between the confirmed and rejected states. If, during the inspection phase, it is determined that the message m already exists in the confirmed hash set of the node, then the node generates and broadcasts a rejection response message containing a duplicate processing prompt to the block building node. The rejection response message contains the hash value of the message m and the duplicate identifier code.

[0036] In one optional implementation, the consensus process does not rely on master node election. All nodes in the blockchain network have the authority to build new blocks. When multiple nodes build blocks with the same number at the same time, the blockchain fork problem caused by concurrent construction is solved by checking whether message m already exists in the confirmed hash set. After adding message m to the block to be generated, the process also includes: The block containing the message m is permanently written into the blockchain ledger; Execute the business request corresponding to message m, and update the status of the business execution result to the local state machine; The execution result of the business is used to generate a backtracking record. The backtracking record includes the hash value of message m, the execution timestamp, and the digital signature of the execution node. The backtracking record is then stored in a preset audit log.

[0037] In one optional implementation, the method for storing the backtracking record includes: Merkle tree structure is used to aggregate multiple backtracking records within a preset time window to generate a Merkle root; The Merkle root is embedded into the subsequently generated block header to enable rapid verification and tamper-proof backtracking of the historical state of business behavior; The confirmed hash set is managed using a time-based sliding window mechanism, retaining only hash records within the most recent preset time period, or maintaining the set only within the consensus period corresponding to the current view number v. When the view number is updated, the set is archived or cleared.

[0038] In one optional implementation, before archiving or clearing the confirmed hash set, the node generates a state snapshot of the list of hash values ​​in the current set and synchronizes the state snapshot to at least one backup node in the network to prevent the loss of historical confirmed data due to node failure. In the Pre-Prepare broadcasting and verification step, the verification of the validity of the block signature adopts a multi-signature algorithm or an aggregate signature algorithm. The node confirms the legitimacy of the identity of all initiating nodes at once by verifying the aggregate signature packet, so as to reduce the computational overhead in the verification process. The commit message also includes the expected state hash of the node's execution result of message m; After determining whether 2f+1 valid Commit messages, including its own, have been collected, a consistency check step is also included, which compares whether the expected state hashes in all collected Commit messages are consistent. If there is a discrepancy, the node with abnormal behavior will be identified, and the inconsistent state will be recorded in the abnormal behavior blacklist, triggering the penalty mechanism for the abnormal node.

[0039] In the above embodiments, a behavioral data stream of "snapshot + instruction" is constructed based on rrweb technology: The recording of user behavior does not rely on video recording or screenshots, but rather employs rrweb technology, which is based on the DOM (Document Object Model). The specific process is as follows: Initial Full Snapshot Generation: When a user starts a new business session, the client-side data collection module first loads the complete DOM structure of the current page. The system serializes this DOM tree to generate a JSON-formatted dataset containing complete page state information, which is recorded as the initial snapshot. This snapshot serves as the "base" for subsequent playback, ensuring that the page's initial appearance can be restored whenever playback begins at any point in time.

[0040] Incremental interaction command capture: During the session, the system no longer frequently captures full snapshots. Instead, it captures user interactions (such as clicks, input, scrolling, and navigation) in real time through listeners. Each interaction is converted into a minimal incremental operation command. For example, when a user enters characters in an input box, the system only records the "Input" event and its changed value, rather than the entire HTML code of the input box.

[0041] Data stream encapsulation: The system packages the initial snapshot and subsequent incremental operation instructions in timestamp order to form a time-series data stream. This "snapshot + instruction" model greatly reduces the redundancy of the original data, but in complex single-page applications (SPAs), the data volume may still reach hundreds of KB or even tens of MB.

[0042] The Brotli algorithm is used to perform lossless compression on the backtracking data: Although rrweb uses incremental recording, this embodiment introduces a compression step before data is uploaded to the blockchain to meet the stringent requirements of blockchain storage on data volume. Because behavior backtracking demands extremely high data accuracy, it is essential to ensure that the decompressed data is completely consistent with the original data. Therefore, this invention excludes lossy compression and selects the Brotli algorithm.

[0043] Algorithm selection: Compared to common Huffman coding, LZ77 or LZW algorithms, the Brotli algorithm combines the general compression approach of the LZ77 algorithm with modern context modeling technology, and has a very high compression rate, especially for text formats (such as JSON data generated by rrweb).

[0044] Compression execution: The client inputs the JSON-formatted time-series data stream generated in step one into the Brotli compressor.

[0045] Parameter Configuration: To balance client-side computational overhead and network transmission efficiency, this embodiment sets Brotli's compression parameters to a dictionary mode optimized for text. Through its built-in predefined dictionary of common HTML / JS keywords, Brotli can significantly identify and compress duplicate tags and attribute names within the DOM structure.

[0046] Output: After compression, the original rrweb data, ranging from hundreds of KB to tens of MB, is significantly reduced to a smaller binary data stream, generating backtracking data to be uploaded to the blockchain. This significantly reduces data transmission latency and saves storage space on blockchain nodes.

[0047] Dynamic weight-based node consensus and broadcast mechanism: In blockchain networks, to address the high energy consumption of traditional Proof-of-Work (PoW) or the severe Matthew effect of Proof-of-Stake (PoS), this embodiment employs a consensus mechanism that determines voting weights based on node performance. Simultaneously, it allows each node in the network the right to broadcast new blocks.

[0048] Broadcasting a new block: Once a node has collected a certain amount of backtracking data to be added to the chain, the node is eligible to act as a packager, package the data into a new candidate block, and broadcast the candidate block to other nodes in the network.

[0049] Node performance evaluation and weight calculation: Each node in the network maintains a dynamic reputation table. This table records the historical performance of other nodes, including: the rate of valid block generation; the accuracy of data verification; and the real-time performance of network responses.

[0050] The system periodically calculates a comprehensive score for each node based on the aforementioned indicators. The higher the score, the greater the node's weight in the consensus voting phase, meaning its vote carries more weight in the decision. Conversely, nodes that perform poorly (such as frequent offline activity or broadcasting incorrect data) will have their voting weight reduced.

[0051] Message deduplication based on confirmed hash sets: To prevent double-spending attacks or duplicate packaging of the same user behavior data in the network, which could lead to an bloated blockchain ledger, this embodiment introduces a strict local inspection mechanism when nodes process new blocks.

[0052] Establishing a confirmed hash set: Each blockchain node maintains a "confirmed hash set" locally. This set stores the unique hash values ​​of all confirmed transactions on the chain in the node's local ledger.

[0053] Message pre-check process: When a node receives a new block (or candidate transaction message m) broadcast, it first extracts the characteristic hash value of message m before writing it to the local ledger or performing consensus voting.

[0054] The node queries the local "confirmed hash set" to determine whether the hash value already exists in the set.

[0055] Decision logic: If it exists: This means that message m has already been recorded. The node directly refuses to add the message to the current block and discards the duplicate message to ensure data consistency.

[0056] If it does not exist: This means that message m is valid new data. The node continues to execute the subsequent verification process (such as signature verification and data format verification). After the verification is successful, message m is packaged into a block and its hash value is updated to the "confirmed hash set".

[0057] Behavioral backtracking and verification: When it is necessary to audit or backtrack historical operations: Retrieve blockchain block data corresponding to the target time period.

[0058] The compressed backtracking data is extracted from the block, decompressed using the Brotli decoder, and restored to the original JSON format data stream (snapshot + instructions).

[0059] To build an isolated sandbox environment, first load the initial snapshot, and then replay the incremental operation commands sequentially according to the timestamp.

[0060] Based on these instructions, the browser re-renders the DOM nodes, thereby dynamically and realistically reproducing the user's operation scenario and page state at that time, realizing the traceability of behavior based on the immutability of blockchain.

[0061] By combining rrweb technology with the Brotli algorithm, this method, compared to traditional video recording-based backtracking, compresses data volume by several times or even tens of times while ensuring lossless processing, significantly reducing the storage pressure and network bandwidth consumption of the blockchain. By introducing a pre-check mechanism of "confirmed hash sets" locally on the node, duplicate data is prevented from being uploaded to the chain at the underlying data structure level, ensuring the cleanliness of the ledger and the uniqueness of the data. The voting weight mechanism, dynamically adjusted based on node performance, incentivizes nodes to maintain the health and stability of the network while preventing computing power monopolies, thus improving the system's security and decentralization.

[0062] The deployment environment layer enables flexible deployment based on elastic computing services or physical servers, and supports expanding system performance by dynamically increasing computing resources. The data layer, as the physical foundation of blockchain technology, defines the ledger data structure and blockchain components, including a data identity management module, a data sharing module, a data governance module, and a data openness module, ensuring the data integrity and security of the blockchain system. The network layer, based on a P2P network architecture, achieves decentralized operation through information exchange between user nodes. Each node has both information receiving and generation functions, supporting the broadcasting, verification, and main chain addition of new blocks. The consensus layer encapsulates consensus mechanism algorithms, including an optimized Byzantine Fault Tolerance (PBFT) algorithm, a block synchronization management module, and a data consistency management module. The optimized PBFT algorithm improves fault tolerance and efficiency in consortium blockchain scenarios through dynamic node weight allocation and consensus round compression. The block synchronization management module controls the creation of new blocks and the main chain addition process, and the data consistency management module ensures the consistency of node data under malicious attacks or failures. The protocol layer provides support for blockchain network communication and operation, including network protocol and interface modules, and blockchain... The system comprises a service and backtracking data interface module and an identity authentication mechanism module. The network protocol and interface module maintains node interconnection and data transmission. The blockchain service and backtracking data interface module provides on-chain data query APIs and contract layer operation support. The identity authentication mechanism module supports user address creation, management, and data transfer. The contract layer, based on a microservice architecture, implements smart contract functions, including a user management service module, a backtracking data service module, a blockchain service module, and a backtracking archiving service module. The user management service module handles user digital identity creation and public / private key generation. The backtracking data service module performs encryption, persistent storage, archiving, and querying of backtracking data. The blockchain service module is deployed on an independent server and implements block data verification and confirmation. The backtracking archiving service module converts backtracking data into video format and supports long-term storage and export. The application layer encapsulates the blockchain backtracking system and client. The client serves as the user interaction entry point. The backtracking system integrates rrweb technology, recording user behavior by recording the page DOM structure and operation commands, and compressing the recorded data using a lossless compression algorithm.

[0063] Operating environment and database: To ensure the stable operation of the backtracking system, a suitable operating environment needs to be set up for it. This system can be flexibly deployed on a cloud server (ECS, Elastic Compute Service) or a dedicated physical server. This deployment method gives the system the ability to scale performance on demand, meaning that this paper can increase computing resources to meet the needs of business growth, ensuring that system performance improves in tandem with business development.

[0064] The database is responsible for storing the basic data required by the backtracking system; it is the central hub for all data in the backtracking system. Thanks to a clustered deployment strategy, this layer of data storage not only boasts high availability but also excellent performance.

[0065] For the NoSQL database cluster, this paper uses MongoDB as the storage solution to store backtracking data and block data. Storing block data in MongoDB ensures excellent read and write speeds, thereby improving block processing performance.

[0066] As for relational database clusters, they are essentially MySQL database clusters. They retain persistent relational data such as user information and configuration information, ensuring data stability and reliability.

[0067] Finally, the primary responsibility of the file storage system is to preserve and retrieve archived records, which typically include video files. This design aims to optimize the storage and retrieval efficiency of large data volumes.

[0068] Data layer: The data layer is the physical foundation of blockchain technology, defining in detail the data structure of the ledger—the building blocks of the blockchain. At this layer, this paper focuses primarily on key elements such as data identity management, data sharing, data governance, and data openness. These components collectively ensure the data integrity and security of the blockchain system.

[0069] Network layer and consensus layer: The backtracking system's network layer is based on a P2P network architecture, independent of a central server, and operates through information exchange between user nodes. In this network, each node is responsible for both receiving and generating information. When a node creates a new block, it broadcasts this block to other nodes. Upon receiving the notification, other nodes verify the new block. Only when the new block passes verification is it added to the main chain.

[0070] The consensus layer is a core component of a blockchain system, encapsulating various consensus mechanism algorithms. These algorithms determine which node has the right to record transactions, thus affecting the security and reliability of the entire system. This paper employs an optimized PBFT (Byzantine Fault Tolerance) algorithm, which better ensures the fairness and rationality of the system. Block synchronization management determines how new blocks are created and added to the blockchain. Data consistency management involves ensuring the consistency of blockchain data across all nodes, maintaining the system's normal operation even under malicious attacks or malfunctions.

[0071] Protocol layer and contract layer: The protocol layer described in this invention plays a fundamental role in the entire blockchain network, providing the necessary support environment for network communication and operation. The core components of the protocol layer include: Networking protocols and interfaces: This part is responsible for maintaining the interconnection between nodes within the blockchain network, ensuring effective data transmission and exchange, thereby promoting the healthy operation of the network. Blockchain services and backtracking data: This component provides a series of application programming interfaces (APIs), which not only enable on-chain data queries but also provide a solid foundation for the complex operations and services of the contract layer. Identity authentication mechanism: This function is quite similar to a client wallet, supporting users in creating and managing addresses, as well as performing data transfers and other related operations, serving as a key entry point for users to interact with the blockchain. Therefore, by providing these key services, the protocol layer ensures the security, interoperability, and smooth user experience of the blockchain network, making it an indispensable layer in the entire blockchain technology architecture.

[0072] In the backtracking system of this invention, the contract layer consists of a series of carefully designed microservices. These microservices are not merely the embodiment of smart contracts; they inject crucial data into the data layer and provide indispensable functional support for connected end users. From a functional perspective, this paper divides them into four core modules to ensure the efficient operation and stability of the system.

[0073] User management service is a crucial component, responsible for handling user-related microservice operations, including creating user digital identities and generating public and private keys. Through carefully designed algorithms and data structures, user management service ensures that the processing and maintenance of user information are efficient and reliable.

[0074] Retrospective data service is another key module, dedicated to comprehensive operations of retrospective data. Whether it's data reception encryption, persistent storage, archiving management, or data querying, retrospective data service can handle it all with ease. Through precise data processing workflows and optimized compression storage mechanisms, it ensures complete lifecycle management of retrospective data.

[0075] Blockchain services are microservices or programs specifically designed for blockchain operations. They can be flexibly deployed on independent servers, especially in consortium blockchain scenarios, where they enable effective verification and confirmation of block data. Through intelligent consensus algorithms and encryption technologies, blockchain services ensure the security and reliability of the system.

[0076] The retrospective archiving service is responsible for converting retrospective data into video formats and persistently storing it. It not only supports long-term storage of this archived data but also provides export functionality to meet user needs in different scenarios. Through efficient encoding and compression algorithms, the retrospective archiving service ensures the quality and accessibility of video data.

[0077] In summary, these four core modules work together to build a powerful and reliable backtracking system. Regardless of the challenges faced, they deliver superior performance and stability, providing users with a high-quality backtracking experience.

[0078] Application layer: The application layer encapsulates the blockchain's traceability system and client. The client is the insurance application page for policyholders. When a policyholder clicks to enter the application page, they are directed to the traceability system. The traceability system is essentially an application built on top of the blockchain system.

[0079] This front-end architecture is built on top of HTML and CSS, but it also utilizes Node.js and the ElementUI technology stack based on Vue 3, a combination highly regarded in the current technology community. Combined with rrweb technology, the front-end pages can implement data collection functionality.

[0080] In terms of data interaction, the system achieves load balancing and reverse proxy request forwarding through the use of an nginx cluster, ensuring high availability across all nodes. For backend service authentication, the system employs the general GWT authentication framework to ensure login security.

[0081] On the backend, the system utilizes several utility classes, such as RedisUtils, Hutool, HttpClient (network request class), FastJson (serialization class), and EasypoiExcel (export utility class). These classes provide convenient methods for better system operation. Of course, there are also core frameworks, such as Spring Boot and Spring Cloud, to achieve high availability of microservices, and Quartz (timed tasks) to better execute scheduled tasks. t-io is responsible for maintaining persistent connections between nodes, automatic reconnection, and stable heartbeat packet transmission. Ecdsa is a tool specifically developed for this system based on the Elliptic Curve Digital Signature Algorithm (ECDSA). Blockchain specifically handles blockchain data structures and methods. SecurityZip is a compression class based on the Brotli compression algorithm. FFmpeg is used to convert backtracking data into the required backtracking video format. For data registration and discovery, as well as the configuration center, the system uses Nacos.

[0082] For the data persistence layer, the system adopts the commonly used MyBatis and Druid technology architecture.

[0083] In terms of database storage layer selection, the system mainly uses the non-relational database mongoDB to store core block data, while the relational database mysql and the cache Redis are used to store backend configuration information and other data. Elasticsearch serves as the data underlying layer of the log service ELK

[35] (elasticsearch+logstash+kibana).

[0084] In terms of hardware deployment, the system uses Docker containerization on a popular Linux server for microservice deployment. The backend management interface, however, is typically deployed on a Windows system.

[0085] Recording data via snapshots results in relatively large datasets, typically ranging from hundreds of KB to tens of MB. To address this challenge, this paper proposes solutions from the perspective of reducing data volume.

[0086] rrweb's recording doesn't periodically capture the entire screen; instead, it records the page's DOM structure. During playback, the page is re-rendered based on the recorded information. In short, this process can be seen as "snapshot + operation commands." To record the page state, the system records the DOM state at each point in time, displaying it according to those points during playback.

[0087] rrweb's workflow begins by generating an initial, complete snapshot of the web pages participating in the session. Next, it incrementally tracks and records user interactions. To this end, this paper employs a compression algorithm aimed at significantly reducing data transmission volume and storage space requirements. This efficient compression technique enables faster content delivery and more economical space utilization, thereby improving overall performance and user experience.

[0088] Since this system is a backtracking system, it needs to clearly record user actions, making lossless compression the best approach. Commonly used compression algorithms include Huffman coding, RLE, BWT, LZ77, LZW, and Brotli. We will now select a suitable lossless compression algorithm to compress the backtracking data.

[0089] Analysis, comparison, and selection of compression algorithms: To thoroughly analyze the performance of data compression algorithms and evaluate their adaptability to specific datasets in particular scenarios, this study will calculate and compare the coding efficiency of the algorithm to perform a performance comparison with other existing algorithms. The method for calculating coding efficiency is crucial. The formula for calculating coding efficiency is as follows:

[0090] In the formula above, H(S) is the information value of the source S, and P(Xi) represents the probability of the i-th symbol appearing in the code symbol set. If the average codeword length R is not lower than the information entropy H(S) and is close to H(S), it indicates that the compression algorithm has high effectiveness; when R is much greater than H(S), it indicates that the compression technique has low effectiveness.

[0091] Let the encoding length of each symbol in the symbol set be respectively Therefore, the formula for calculating the average code length is as follows:

[0092] When measuring data compression performance, in addition to encoding efficiency, key metrics such as compression ratio, compression time, and decompression time should also be considered. Compression ratio reflects the ratio of the compressed data size to the original data size. However, while pursuing a low compression ratio, the time required for compression and decompression must also be taken into account to find an algorithm that achieves the optimal balance among these three factors, thus best suiting the requirements.

[0093] To thoroughly evaluate and compare the performance of lossless compression algorithms, compression tests were conducted on the same original file using Huffman coding, RLE, BWT, LZ77, LZW, and Brotli algorithms. To ensure the accuracy and reliability of the experimental results, the compression experiments were repeated multiple times, and the collected data was averaged to obtain stable and reliable performance metrics for each algorithm. Evaluating the performance of different algorithms in practical applications provides solid experimental support for subsequent algorithm selection and optimization. Specific experimental results are shown in Table 4-1. Table 4-1 Experimental Results of Six Commonly Used Compression Algorithms

[0094] Experimental results show that for the same source file, the RLE and BWT algorithms are significantly inferior to the other four algorithms in terms of compression ratio, compression time, and decompression time, so these two algorithms are excluded. The LZW algorithm has the shortest compression time, demonstrating a significant advantage in time performance; while the LZ77 algorithm, although having the best compression ratio, consumes relatively long time in both compression and decompression processes. The Brotli compression algorithm, through improvements to the LZ77 algorithm and Huffman coding, and the use of second-order text modeling and other techniques, achieves a perfect balance in compression time, decompression time, and compression ratio. It shortens the compression time while ensuring compression efficiency, and also has a good decompression time. Therefore, the Brotli compression algorithm was chosen as the compression algorithm in this paper.

[0095] Brotli's dictionary was specifically optimized to suit the characteristics of these particular file types. A custom dictionary was developed containing commonly used words and patterns for these file types. Compared to the 120KB dictionary used by the original Brotli algorithm, this dictionary contains over 13,000 carefully selected commonly used words, phrases, and other string fragments, requiring the same amount of vocabulary resources while reducing the dictionary size to one-tenth of the original.

[0096] By comparing the information contained in different data structures, we can evaluate their effectiveness in data compression and conduct a detailed comparative analysis of the experimental results, aiming to select the most suitable type for representing retrospective data.

[0097] To ensure the accuracy and reliability of the experimental results, we selected four popular data structures—HTML, XML, JSON, and Base64-encoded bytearrays—as our research subjects. These formats cover a wide range of applications, from markup languages ​​to data exchange formats. In the experiments, we will perform multiple rounds of compression tests on each data structure and take the average of the compression results. This method aims to avoid random errors that may be introduced by a single compression, thereby improving the accuracy and reliability of the experimental data.

[0098] By employing this rigorous experimental approach, we have laid a solid foundation for evaluating the Brotli compression algorithm's ability to process various data structures, ensuring higher accuracy and reliability of the research results. Specific experimental results are shown in Table 4-2 below: Table 4-2 Comparison of Compression of Four Data Structures

[0099] Through detailed analysis of the compression results, it was found that, except for JSON data type, the Brotli algorithm showed minimal difference in compression ratio when compressing data of different structure types. Given that byte array compression is better, byte arrays were chosen. At the beginning of this section, the Brotli algorithm was optimized; below is a comparison of the data before and after optimization. The data is shown in the table below: Table 4-3 Comparison of data after Brotli optimization

[0100] Given the unique characteristics of backtracking data structures, direct compression was chosen for this type of data. In the specific design process, the backtracking data received from the front end was first converted into a byte array. This array was then compressed using compression functions provided by Brotli, resulting in an optimized compressed byte array. The decompression stage also utilized decompression functions from the Brotli package to restore the data, and the decompressed result—the byte array—was then converted back to list format for subsequent use. This process not only ensures efficient data compression and restoration but also meets the specific data processing requirements.

[0101] Optimized PBFT algorithm: As a backtracking system, it adopts a strategy that combines transparency and openness, making consortium blockchains the optimal choice for this paper. In constructing this system, an improved PBFT (Byzantine Fault Tolerance) consensus algorithm is used to ensure both security and efficiency.

[0102] First, let's briefly understand the working principle of the classic PBFT (Practical Byzantine Fault Tolerance): An election is held among all nodes in the network to select a master node, which is responsible for generating new blocks.

[0103] Each node broadcasts the transactions sent by the client to the entire network. The master node collects these transactions, arranges them in a certain order, and broadcasts the arranged transaction list to the entire network.

[0104] After receiving the transaction list, each node simulates and executes these transactions according to their order. Once all transactions have been executed, the node calculates the hash digest of the new block based on the execution results and broadcasts it to the entire network.

[0105] If a node receives a digest from 2f other nodes (where f is the tolerable number of Byzantine nodes) that is identical to its own digest, it broadcasts a commit message to the entire network.

[0106] If a node receives 2f+1 commit messages, including its own, it can commit the new block to its local blockchain and state database.

[0107] The client can consider the write request successful if it receives f+1 successful responses (even if there are f failed responses and f malicious error messages, f+1 correct responses are still the majority).

[0108] In the classic PBFT algorithm, a master node is first elected. This master node is responsible for collecting transactions, assembling blocks, and broadcasting them to the network. Subsequently, other nodes in the network verify, vote on, and accumulate confirmations for the newly created blocks. After this series of processes, the new block is finally permanently added to the blockchain.

[0109] The above analysis clearly demonstrates the limitations of the PBFT algorithm. The first issue is the choice of a consortium blockchain. Consortium blockchains involve multiple organizations or institutions, and typically, each node corresponds to a specific organization or institution. Therefore, in real-world applications, the probability of nodes engaging in malicious behavior varies; some nodes will be highly stable, while others will be relatively less stable. The goal is to ensure that highly stable nodes receive verification information earlier and faster.

[0110] To achieve this goal, a weighted adaptive PBFT algorithm based on historical evaluation is proposed, introducing a mechanism to adjust the voting weight of nodes in the consensus process according to their historical performance. The following are the design steps and related calculation formulas of the algorithm: Step 1: Collect historical data: Each node needs to record its historical performance over a period of time, including the number of blocks it proposed or validated and the percentage of those blocks that were accepted.

[0111] Step 2: Calculate the historical success rate: For each node i, this paper defines its historical success rate Pi as follows:

[0112] Step 3: Initialize weights: Based on historical success rates, an initial weight can be assigned to each node. This weight can be a linear function, as shown in the following equation:

[0113] Where k is a positive constant used to map the success rate to a suitable weight range.

[0114] Step 4: Weight Adjustment During operation, the weights of nodes should be dynamically adjusted based on their latest performance. This paper uses an exponentially weighted moving average (EWMA) to update the weights, as shown in the following equation:

[0115] Step 5: Voting Weighting: In the PBFT algorithm, the voting weight of a node It can be determined based on its updated weights, as shown in the following formula:

[0116] The j iterates through all nodes.

[0117] Step 6: Priority Voting: During the consensus process, nodes with higher voting weight should be prioritized for proposing or validating blocks. This can be achieved through round-robin or random selection, ensuring that high-weight nodes have a higher probability of being selected.

[0118] Through the steps described above, this paper designs a weighted adaptive PBFT algorithm based on historical evaluation. This algorithm can dynamically adjust the voting weight of a node in the consensus process according to its historical performance, thereby prioritizing more voting opportunities for stable nodes. This design aims to improve the efficiency and stability of consortium blockchains, as nodes with historically good performance are more likely to maintain their good performance.

[0119] The second issue is that the view switching mechanism of round-robin master node election in the classic PBFT algorithm may adversely affect the system's security and consensus efficiency. If the master node fails, the re-election process is not only time-consuming but also affects the system's high availability. Therefore, this paper decides to abandon the traditional single master node model and instead implement a decentralized strategy, in which every node in the network has the potential to serve as a master node, thereby ensuring the robustness of the network and the efficiency of distributed consensus.

[0120] After removing the leader election process, this scheme grants block building permissions to all nodes, allowing them to broadcast newly built blocks to the entire network. Nodes receiving a new block enter the Pre-Prepare phase, thoroughly verifying the block's format, hash value, signature, and access permissions. If verification is successful, the node enters the Prepare state and broadcasts this information. When a node collects Prepare information from more than 2f+1 other nodes, it enters the Commit state and broadcasts again to the entire network. Finally, once nodes receive more than 2f+1 Commit confirmations, global consensus is reached, and the block is permanently incorporated into the blockchain.

[0121] Abandoning the concept of a leader brings challenges to ensuring the correct block order. In scenarios with a leader, the generation order is guaranteed because the leader is responsible for broadcasting new blocks in a fixed order. For example, if all nodes have processed block number 5 and need to create the next two blocks, the presence of the leader ensures that the new blocks are generated in the order of 6 and 7. However, without a leader, multiple nodes may simultaneously attempt to generate block number 6.

[0122] To address potential fork issues, a series of measures were implemented. For example, before writing information m into a block, an operating node checks its own confirmed hash set, which contains messages that have already been broadcast allowing or denying a commit. If the hash of the information to be written already exists in the set, the information is accepted; otherwise, it is added to the blockchain.

[0123] Example 3: like Figure 2 As shown, this invention proposes a blockchain-based behavior traceability system, comprising: The deployment environment module is used to enable flexible deployment based on elastic computing services or physical servers and to expand system performance by dynamically adding computing resources. The data storage module, as the physical foundation of blockchain technology, defines the ledger data structure and the constituent elements of the blockchain, and is used to ensure the data integrity and security of the blockchain system. The P2P network module is based on a P2P network architecture to achieve decentralized operation and supports the broadcasting, verification and addition of new blocks to the main chain. The consensus processing module is used to manage node voting weights and the block proposal and verification process; The protocol support module provides support for blockchain network communication and operation, including node interconnection, data transmission and interface services; the smart contract module implements smart contract functions based on a microservice architecture, including backtracking management services and backtracking archiving services. The behavior backtracking module encapsulates the blockchain backtracking system and client, which is used to record user behavior by recording the page DOM structure and operation commands, and to compress the recorded data.

[0124] Example 4: Figure 7 A block diagram of an exemplary electronic device suitable for implementing embodiments of the present invention is shown.

[0125] The electronic device may include a central processing unit / microprocessor / main control chip, etc. 4; and a storage medium 5, coupled to the central processing unit / microprocessor / main control chip, etc. 4, and storing computer-executable instructions therein for performing the steps of various methods of embodiments of the present invention when executed by the processor.

[0126] The central processing unit / microprocessor / main control chip, etc., can include, but are not limited to, one or more processors or microprocessors.

[0127] Storage medium 5 may include, but is not limited to, random access memory (RAM), read-only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, computer storage media (e.g., hard disk, floppy disk, solid-state drive, removable disk, CD-ROM, DVD-ROM, Blu-ray disc, etc.).

[0128] In addition, the electronic device may also include (but is not limited to) a data bus 6, an input / output bus / external bus / device bus 7, a display 8, and input / output devices 9 (e.g., keyboard, mouse, speaker, etc.).

[0129] The central processing unit / microprocessor / main control chip, etc. 4 can communicate with external devices (8, 9, etc.) via I / O bus 7 through wired or wireless network (not shown).

[0130] The storage medium 5 may also store at least one computer-executable instruction for performing the steps of various functions and / or methods in the embodiments described herein when the central processing unit / microprocessor / main control chip, etc., 4 is running.

[0131] In one embodiment, the at least one computer-executable instruction may also be compiled into or comprise a software product, wherein one or more computer-executable instructions are executed by a processor to perform the steps of the various functions and / or methods in the embodiments described herein.

[0132] Figure 8 A schematic diagram of a computer-readable storage medium according to an embodiment of the present invention is shown.

[0133] like Figure 8As shown, the non-transitory computer-readable storage medium 11 stores instructions, such as computer-readable instructions 10. When the computer-readable instructions 10 are executed by a processor, the various methods described above can be performed. The non-transitory computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-transitory non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. For example, the non-transitory computer-readable storage medium 11 can be connected to a computing device such as a computer, and then, when the computing device executes the computer-readable instructions 10 stored on the computer-readable storage medium 11, the various methods described above can be performed.

[0134] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] Furthermore, the functional units in the various embodiments of the present invention 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.

[0137] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for executing all or part of the steps of the methods of the various embodiments of this invention through a computer device (which may be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0138] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention 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 the present invention.

Claims

1. A blockchain-based behavior traceability method, characterized in that, Includes the following steps: Before writing a target message into a block, each node in the blockchain network checks whether the target message exists in the node's confirmed hash set, where the confirmed hash set refers to the set of dispatch messages that the node has already broadcast. If it is confirmed through inspection that the target message does not exist in the confirmed hash set, then the target message is added to the block to be generated; If the target message is confirmed to exist in the confirmed hash set, then adding the target message to the block to be generated will be stopped to prevent message duplication.

2. The blockchain-based behavior traceability method as described in claim 1, characterized in that, Before the step of adding the target message to the block to be generated, there are also steps for preparing broadcasts and verification: Any node in the blockchain network acts as a block building node. After completing the block building of the target message, it generates a pre-prepared message and broadcasts it to other nodes in the network. The pre-prepared message includes a view number, a block number, a block hash value, and the target message. Other nodes that receive the pre-prepared message verify the pre-prepared message. The verification includes verifying the legality of the block format, the correctness of the block hash value, the validity of the block signature, and the compliance of the node access permissions. If the verification passes, the process proceeds to the preparation phase; if the verification fails, the consensus process for the current block ends.

3. The blockchain-based behavior traceability method as described in claim 2, characterized in that, Following the step of entering the preparation phase, a step of preparing for message collection is also included: The node that passes the pre-prepared message verification sends a preparation message to other nodes in the network. The preparation message includes the view number, the block number, the block hash value, and the node ID that sent the preparation message. The node continuously collects preparation messages sent by other nodes and determines whether a preset number of valid preparation messages have been collected. If the preset number of valid preparation messages are not collected, the current consensus process ends. If a preset number of valid preparation messages are collected, the allocation phase begins.

4. The blockchain-based behavior traceability method as described in claim 3, characterized in that, The preset number is 2f, where f is the maximum number of malicious nodes that the system can tolerate, and the total number of nodes N in the system satisfies N≥3f+1; The determination of whether a preset number of valid preparation messages have been collected specifically involves determining whether preparation messages have been received from 2f different replica nodes, excluding the current node itself.

5. The blockchain-based behavior traceability method as described in claim 4, characterized in that, Following the step of entering the allocation phase, the process also includes allocation message broadcasting and collection steps: Nodes that meet the preparation phase conditions broadcast a relocation message to the entire network. The relocation message includes the view number, the block number, the hash digest of the target message, and the node ID that sent the relocation message. The node continuously collects allocation messages from the entire network and determines whether it has collected 2f+1 valid allocation messages, including its own. If 2f+1 valid allocation messages, including one's own, are collected, the consensus condition is confirmed, and the process enters the verification phase of writing the message into the block.

6. The blockchain-based behavior traceability method as described in claim 5, characterized in that, The step of checking whether the target message exists in the confirmed hash set of the node specifically includes: Calculate the hash value of the target message to be written; Search the locally stored set of confirmed hashes for a record that has the same hash value as the target message to be written. If the search is successful, it is determined that the target message already exists in the confirmed hash set of that node; If no match is found, it is determined that the target message does not exist in the confirmed hash set of that node.

7. A blockchain-based method for traceable behavior as described in claim 6, characterized in that, The update and maintenance steps for the confirmed hash set include: When a node broadcasts a dispatch message about a certain message to the entire network, it immediately adds the hash value of that message to the local confirmed hash set. Alternatively, when a node determines to reject the allocation confirmation of a certain message, it adds the hash value of the message to the local confirmed hash set and marks it to distinguish between the confirmed and rejected states. If it is determined during the inspection phase that the target message already exists in the confirmed hash set of the node, the node generates and broadcasts a rejection response message containing a duplicate processing prompt to the block building node. The rejection response message contains the hash value and duplicate identifier of the target message. After adding the target message to the block to be generated, it also includes: The block containing the target message is permanently written to the blockchain ledger; Execute the business request corresponding to the target message, and update the status of the business execution result to the local state machine; The business execution results are used to generate a backtracking record, which includes the hash value of the target message, the execution timestamp, and the digital signature of the execution node. The backtracking record is then stored in a preset audit log. The method for storing the backtracking records includes: Merkle tree structure is used to aggregate multiple backtracking records within a preset time window to generate a Merkle root; Merkle root is embedded into the subsequently generated block header to enable rapid verification and tamper-proof backtracking of the historical state of business behavior; The confirmed hash set is managed using a time-based sliding window mechanism, retaining only hash records within a preset time period, or maintaining the set within the consensus period corresponding to the current view number. When the view number is updated, the set is archived or cleared. Before archiving or clearing the confirmed hash set, the node generates a state snapshot of the list of hash values ​​in the current set and synchronizes the state snapshot to at least one backup node in the network to prevent the loss of historical confirmed data due to node failure. In the pre-preparation broadcast and verification steps, the verification of the block signature validity adopts a multi-signature algorithm or an aggregate signature algorithm. The node confirms the identity and legitimacy of all initiating nodes at once by verifying the aggregate signature packet, so as to reduce the computational overhead in the verification process. The dispatch message also includes the expected state hash of the node's execution result of the target message; After determining whether 2f+1 valid allocation messages, including its own, have been collected, a consistency check step is also included, which compares whether the expected state hashes in all collected allocation messages are consistent. If there is a discrepancy, the node with abnormal behavior will be identified, and the inconsistent state will be recorded in the abnormal behavior blacklist, triggering the penalty mechanism for the abnormal node.

8. A blockchain-based behavior traceability system according to any one of claims 1-7, characterized in that, include: The deployment environment module is used to enable flexible deployment based on elastic computing services or physical servers and to expand system performance by dynamically adding computing resources. The data storage module, as the physical foundation of blockchain technology, defines the ledger data structure and the constituent elements of the blockchain, and is used to ensure the data integrity and security of the blockchain system. The P2P network module is based on a P2P network architecture to achieve decentralized operation and supports the broadcasting, verification and addition of new blocks to the main chain. The consensus processing module is used to manage node voting weights and the block proposal and verification process; The protocol support module provides support for blockchain network communication and operation, including node interconnection, data transmission, and interface services; The smart contract module implements smart contract functions based on a microservice architecture, including backtracking management services and backtracking archiving services; The behavior backtracking module encapsulates the blockchain backtracking system and client, which is used to record user behavior by recording the page DOM structure and operation commands, and to compress the recorded data.

9. An electronic device, comprising: At least one memory stores computer-executable instructions non-transitory; At least one processor, configured to run the computer-executable instructions, Wherein, the computer-executable instructions are executed by the processor at runtime, and a blockchain-based behavior traceability method is described in any one of claims 1-7.

10. A computer-readable storage medium, wherein, The computer-readable storage medium stores computer-executable instructions that, when executed by at least one processor, implement a blockchain-based behavior traceability method according to any one of claims 1-7.

Images