Information processing method and apparatus, program product, and electronic device

Abstract

This invention discloses an information processing method, apparatus, program product, and electronic device, relating to the field of fintech or other related fields. The information processing method includes: upon receiving a wealth management purchase request initiated by a client, performing a security check on the purchase request; if the security check passes, constructing a transaction data body based on the purchase request, and performing consensus processing on the transaction data body using a Byzantine algorithm; and upon completion of consensus processing, generating blocks based on the transaction data body using preset nodes. This invention solves the technical problem in related technologies where the inability to accurately generate transaction data bodies leads to the inability to effectively trace the wealth management purchase process.

Description

Technical Field

[0001] This invention relates to the field of financial technology, and more specifically, to an information processing method and apparatus, program product, and electronic device. Background Technology

[0002] With the rapid development of internet finance, the online sales scale of bank wealth management products has continued to expand, and customers completing the purchase of financial products such as funds, insurance, and precious metals through mobile banking clients has become the mainstream model. In order to meet the compliance requirements of financial regulatory agencies for the sales process to be "traceable, verifiable, and accountable," financial institutions generally use front-end screenshot technology to visually record the entire process of customers purchasing wealth management products, forming a "wealth management traceability document."

[0003] In related technologies, screenshots are typically triggered at key points (such as clicking to purchase or reading a risk disclosure statement) by listening to user interface operation events. These screenshots are then combined with metadata such as timestamps and user IDs to generate a unique identifier file, enabling simultaneous display of front-end and back-end operations and recording of activity traces.

[0004] However, the above-mentioned retrospective scheme has the following problems: (1) The retrospective process can only capture static images within the current viewport, and cannot fully collect long pages and scrolling content, resulting in a high omission rate; (2) The system has no awareness, retry, or fault tolerance mechanism for situations such as screenshot failure, network interruption, and device abnormality. Once the retrospective generation fails, the data is permanently lost, reducing the reliability of the retrospective system; (3) The retrospective file adopts a centralized storage architecture and is independently saved in units of single transactions. It cannot aggregate and query historical records by customer dimension, and is limited by storage costs and compliance cycles, making it difficult to meet the regulatory trend of "permanent evidence storage" in the financial industry; (4) There is a lack of a credible third-party verification mechanism. When disputes occur between customers and banks, the operation records held by both parties are difficult to trust and recognize each other. Regulatory audits need to retrieve logs from multiple systems one by one, which is inefficient and costly.

[0005] There is currently no effective solution to the above problems. Summary of the Invention

[0006] This invention provides an information processing method, apparatus, program product, and electronic device to at least solve the technical problem in related technologies where the inability to accurately generate transaction data leads to the inability to effectively trace the financial purchase process.

[0007] According to one aspect of the present invention, an information processing method is provided, comprising: upon receiving a financial purchase request initiated by a client, performing a security check on the financial purchase request; if the security check on the financial purchase request passes, constructing a transaction data body based on the financial purchase request; performing consensus processing on the transaction data body using a Byzantine algorithm; and if the consensus processing is completed, generating a block based on the transaction data body using preset nodes, wherein the block is used to backtrack the financial purchase process corresponding to the financial purchase request.

[0008] Furthermore, the wealth management purchase request includes: product code, amount, and user signature. The steps for security checks on the wealth management purchase request include: verifying the user signature using a preset public key, where the preset public key is the public key associated with the user account logged in on the client; if the user signature verification is successful, performing risk control checks on the product code and amount based on the user account's account permissions; if the risk control check passes, determining that the security check on the wealth management purchase request has passed.

[0009] Furthermore, the steps for constructing the transaction data body based on the wealth management purchase request include: listening for scrolling events and, upon detecting a scrolling event, taking screenshots of the client's interface at preset time intervals. Each screenshot is associated with a page structure tree and scrolling position metadata, which includes at least an operation timestamp. The page structure tree of each screenshot is hashed to obtain a fragment hash value. All fragment hash values ​​are arranged in chronological order to form leaf nodes, and the parent node of every two leaf nodes is calculated layer by layer upwards to generate a Merkle tree structure. The user identifier initiating the wealth management purchase request and the initiation timestamp are used as the root node of the Merkle tree structure to construct the transaction data body.

[0010] Furthermore, before using the Byzantine algorithm to process the transaction data for consensus, the process includes: obtaining the historical consensus success rate and historical response speed of each node on the blockchain; determining the credit value of the node based on the historical consensus success rate and historical response speed; identifying nodes with a credit value greater than a preset credit threshold as consensus nodes; and using a round-robin mechanism to determine the master node from all consensus nodes.

[0011] Furthermore, the steps for consensus processing of the transaction data body using the Byzantine algorithm include: sending the transaction data body to the master node; the master node constructing broadcast information based on the transaction data body and broadcasting the broadcast information to each consensus node, wherein each consensus node verifies the broadcast information and signs it after receiving it, and returns the obtained consensus node signature to the master node; if the number of consensus node signatures received by the master node is greater than a preset number, the consensus processing is determined to be complete, wherein the preset number is determined based on the total number of consensus nodes; if the number of consensus node signatures received by the master node is less than or equal to the preset number, the consensus processing is determined to be failed, and the consensus processing is restarted until the consensus processing is complete.

[0012] Furthermore, the step of generating blocks using preset nodes based on transaction data includes: determining the computation time for each consensus node to calculate a random number based on the transaction data; determining the consensus node with the minimum computation time as the preset node; obtaining the hash of the last block on the blockchain; and generating a block using the preset node based on the hash of the last block, the transaction data, the signatures of all consensus nodes, and the random number.

[0013] Furthermore, after generating blocks using preset nodes based on transaction data, the process also includes: upon receiving a backtracking request, locating the blockchain based on the timestamp and user identifier contained in the backtracking request to obtain the block to be backtracked; constructing a proof path based on the transaction data contained in the block to be backtracked, and obtaining the signatures of all consensus nodes; and, if the proof path and the signatures of all consensus nodes are verified, backtracking the financial purchase process based on the transaction data.

[0014] According to another aspect of the present invention, an information processing apparatus is also provided, comprising: an inspection unit, configured to perform a security check on a financial purchase request initiated by a client upon receiving such a request; a construction unit, configured to construct a transaction data body based on the financial purchase request if the security check on the financial purchase request passes; a processing unit, configured to perform consensus processing on the transaction data body using a Byzantine algorithm; and a generation unit, configured to generate blocks based on the transaction data body using preset nodes after the consensus processing is completed, wherein the blocks are used to backtrack the financial purchase process corresponding to the financial purchase request.

[0015] Furthermore, the wealth management purchase request includes: product code, amount, and user signature. The inspection unit includes: a first verification module, used to verify the user signature using a preset public key, wherein the preset public key is the public key associated with the user account logged in on the client; a first inspection module, used to perform risk control checks on the product code and amount based on the user account's account permissions if the user signature verification is successful; and a first confirmation module, used to confirm that the security check of the wealth management purchase request has passed if the risk control check has passed.

[0016] Furthermore, the construction unit includes: a first listening module, used to listen for scrolling events and, upon detecting a scrolling event, take screenshots of the client's interface at preset time intervals, wherein the screenshots are associated with a page structure tree and scrolling position metadata, the scrolling position metadata including at least an operation timestamp; a first encoding module, used to hash-encode the page structure tree of each screenshot to obtain the fragment hash value of the screenshot; a first generation module, used to construct leaf nodes from all fragment hash values ​​in chronological order, and calculate the parent node of every two leaf nodes layer by layer upwards to generate a Merkle tree structure; and a first construction module, used to construct the transaction data body by using the user identifier and the initiation timestamp of the financial purchase request as the root node of the Merkle tree structure.

[0017] Furthermore, the information processing device also includes: a first acquisition module, used to acquire the historical consensus success rate and historical response speed of each node on the blockchain before performing consensus processing on the transaction data using the Byzantine algorithm; a second determination module, used to determine the credit value of a node based on the historical consensus success rate and historical response speed; a third determination module, used to determine nodes with credit values ​​greater than a preset credit threshold as consensus nodes; and a fourth determination module, used to determine the master node from all consensus nodes using a round-robin mechanism.

[0018] Furthermore, the processing unit includes: a first sending module for sending the transaction data body to the master node; a first broadcasting module for constructing broadcast information based on the transaction data body through the master node and broadcasting the broadcast information to each consensus node, wherein each consensus node verifies the broadcast information and signs it after receiving it, and returns the obtained consensus node signature to the master node; a fifth determining module for determining that consensus processing is complete when the number of consensus node signatures received by the master node is greater than a preset number, wherein the preset number is determined based on the number of all consensus nodes; and a sixth determining module for determining that consensus processing has failed and restarting consensus processing when the number of consensus node signatures received by the master node is less than or equal to the preset number, until consensus processing is complete.

[0019] Furthermore, the generation unit includes: a seventh determining module, used to determine the computation time for each consensus node to calculate a random number based on the transaction data body; an eighth determining module, used to determine the consensus node indicated by the minimum computation time as the preset node; a second obtaining module, used to obtain the hash of the last block on the blockchain; and a second generation module, used to generate a block using the preset node, based on the hash of the last block, the transaction data body, the signatures of all consensus nodes, and the random number.

[0020] Furthermore, the information processing device also includes: a first positioning module, used to locate the blockchain based on the timestamp and user identifier contained in the backtracking request after generating a block using preset nodes based on the transaction data body, and obtain the block to be backtracked; a second construction module, used to construct a proof path based on the transaction data body contained in the block to be backtracked, and obtain the signatures of all consensus nodes; and a first backtracking module, used to backtrack the financial purchase process based on the transaction data body after verifying the proof path and the signatures of all consensus nodes.

[0021] According to another aspect of the present invention, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described information processing methods.

[0022] According to another aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement any of the above-described information processing methods.

[0023] In this invention, upon receiving a financial purchase request initiated by a client, a security check is performed on the financial purchase request. If the security check passes, a transaction data body is constructed based on the financial purchase request, and a Byzantine algorithm is used to process the transaction data body for consensus. Once the consensus process is complete, a block is generated based on the transaction data body using preset nodes. This solves the technical problem in related technologies where the transaction data body cannot be accurately generated, resulting in the inability to effectively trace back the financial purchase process.

[0024] In this invention, a transaction data body is constructed based on the financial purchase request that has passed the security check. By combining the Byzantine fault tolerance algorithm, multi-node consensus is achieved to ensure that even if some nodes are abnormal, a consistent record can still be reached. After the consensus is completed, a block containing complete transaction information is generated by a preset node. This makes the key operations and risk disclosure content of the financial purchase process permanently, distributedly, and tamper-proofly stored, providing a verifiable and traceable legal evidence chain for subsequent customer-level backtracking. This achieves the technical effect of ensuring that the entire financial purchase operation process is unforgeable and non-repudiable. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0026] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing an information processing method is shown.

[0027] Figure 2 This is a flowchart of the information processing method according to Embodiment 1 of the present invention;

[0028] Figure 3 This is a schematic diagram of an optional financial management retrospective process based on Byzantine algorithm and blockchain technology according to an embodiment of the present invention;

[0029] Figure 4 This is a schematic diagram of an optional information processing apparatus according to an embodiment of the present invention;

[0030] Figure 5 This is a structural block diagram of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., used in this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] It should be noted that all related information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) collected and involved in this invention are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, and necessary measures have been taken to ensure compliance with public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface. After receiving consent from the aforementioned user or organization, the relevant information is obtained. If the user chooses to refuse, the process proceeds to an expert decision-making process.

[0034] This invention proposes a financial management retrospective method based on Byzantine algorithm and blockchain technology, which can collect screenshots of users' operations during the purchase of financial products without their knowledge, i.e., retrospective. It can be applied to different scenarios, such as the purchase and redemption process of funds, insurance, heavy metals, etc., as well as the transaction process that needs to be preserved on-site.

[0035] This invention uses Byzantine algorithm and blockchain technology to improve customer experience, reduce labor costs, and enhance the effectiveness and stability of visualized backtracking. It enables full coverage of mobile banking sales with no blind spots in backtracking, and is an atomic function that can effectively serve multiple scenarios, such as backtracking scenarios for online purchases of funds, deposits, insurance, and precious metals.

[0036] The present invention will now be described in detail with reference to various embodiments.

[0037] Example 1

[0038] According to an embodiment of this application, an embodiment of an information processing method is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0039] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing an information processing method is shown. Figure 1 As shown, computer terminal 10 (or mobile device) may include one or more ( Figure 1 The processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions may also be included. In addition, it may include: a display, a keyboard, a cursor control device, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera, wherein the network interface can be connected to wired and / or wireless networks. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0040] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0041] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the information processing method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the above-mentioned information processing method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0042] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0043] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0044] Under the aforementioned operating environment, this application provides the following: Figure 2 The information processing method shown. Figure 2 This is a flowchart of the information processing method according to Embodiment 1 of the present invention, as follows: Figure 2 As shown, the method includes the following steps:

[0045] Step S201: Upon receiving a financial purchase request initiated by the client, perform a security check on the financial purchase request.

[0046] In this embodiment of the invention, when a user purchases a wealth management product through a client (such as a mobile banking application), if the user initiates a wealth management purchase request through the client, the system gateway can receive the request and perform security checks on it. For example, it can call the hardware security module to verify the validity of the user's private key signature and confirm the authenticity of the identity; compare whether the user's risk assessment level matches the product's risk level; query whether the customer's cumulative purchase amount and transaction frequency exceed the limit; and detect whether the terminal device is in a secure operating environment.

[0047] Here, the wealth management purchase request includes the user's digital signature, product code, transaction amount, and timestamp.

[0048] Step S202: If the security check of the wealth management purchase request passes, construct the transaction data body based on the wealth management purchase request.

[0049] In this embodiment of the invention, the request information that has passed the security check is encapsulated into a structured JSON (JavaScript Object Notation) format transaction data body according to a preset data structure. The data body includes fields such as tx_id (unique transaction identifier), user_addr (user public key hash value), product_code (financial product code), amount (transaction amount), user_signature (user signature), and prev_tx_hash (the hash of the user's previous transaction). Among these, user_addr is a de-identified on-chain address generated by hashing the user's public key, ensuring that the identity cannot be traced back.

[0050] Step S203: The Byzantine Fault Tolerance algorithm is used to perform consensus processing on the transaction data.

[0051] In this embodiment of the invention, a Byzantine fault-tolerant algorithm (such as PBFT (Practical Byzantine Fault Tolerance)) is employed. The master node packages the transaction data into a pre-prepared message and broadcasts it to a pre-defined consensus node cluster (including consensus nodes from banking systems, wealth management subsidiaries, custodian banks, and regulatory agencies). Each consensus node independently verifies the legality of the transaction, signs it, and returns a response to the client. Consensus is considered complete only when at least 2f+1 responses are returned (where f is the allowed number of failed nodes). For example, when the total number of consensus nodes is 7, a maximum of 2 nodes can be allowed to fail. In this way, strong consistency confirmation of transactions can be achieved in a decentralized environment, avoiding single points of failure or tampering, and forming a consensus result with evidentiary force.

[0052] Step S204: After consensus processing is completed, a block is generated based on the transaction data body using a preset node. The block is used to trace back the financial purchase process corresponding to the financial purchase request.

[0053] In this embodiment of the invention, after consensus is reached, a preset node (a consensus node selected through a competition mechanism) writes the confirmed transaction data body into a new block. The block structure includes a block header (containing the hash of the previous block, timestamp, Merkle root, and state root) and a block body (transaction list). The block header is confirmed by digital signatures from at least 2f+1 consensus nodes. After the block is generated, it is synchronized to the verification nodes and light nodes through a distributed ledger. The light nodes only store the Merkle path of the user's own transactions. This block permanently records the key behaviors and states of the financial purchase process. Its immutability and timestamp binding characteristics ensure that the authenticity, integrity, and timing of the operations can be verified during subsequent backtracking, realizing an auditable and verifiable backtracking function.

[0054] In summary, a transaction data body is constructed based on the financial purchase request that has passed the security check. By combining the Byzantine fault tolerance algorithm to achieve multi-node consensus, it is ensured that even if some nodes are abnormal, a consistent record can still be reached. After the consensus is completed, a block containing complete transaction information is generated by the preset node. This makes the key operations and risk disclosure content of the financial purchase process permanently, distributedly and tamper-proofly stored. It provides a verifiable and traceable legal evidence chain for subsequent customer-level backtracking, thereby achieving the technical effect of unforgeable and non-repudiable underlying protection for the entire financial purchase operation process.

[0055] Optionally, the wealth management purchase request includes: product code, amount, and user signature. To improve the accuracy of security checks on wealth management purchase requests, the information processing method provided in Embodiment 1 of this application uses a preset public key to verify the user signature. The preset public key is the public key associated with the user account logged in on the client. If the user signature verification is successful, a risk control check is performed on the product code and amount based on the user account's account permissions. If the risk control check passes, the security check on the wealth management purchase request is determined to have passed.

[0056] In this embodiment of the invention, upon receiving a wealth management purchase request submitted by a client, the system extracts the user signature (i.e., an asymmetric signature) carried in the request and retrieves the preset public key bound to the account from the bank's key management system based on the user account identifier attached to the request. This preset public key is the public key portion of a public key pair generated by the hardware security module when the user first activates the wealth management service. Its private key is stored in segments in the mobile phone's security chip and the bank's encryption device. The public key, after hashing, is registered in the system as the user's on-chain address (user_addr) for identity binding. The system uses this preset public key to perform a signature verification algorithm on the user signature, verifying whether the signature was generated by the corresponding private key and has not been tampered with.

[0057] Here, the default public key refers to the asymmetric public key that is registered with the system and uniquely bound to the user's account, used for identity authentication. The user signature refers to the encrypted value generated by digitally signing the transaction data digest with the user's private key, used to prove the non-repudiation of the transaction.

[0058] After the user's signature verification is successful, the system reads the account permission information registered in the bank's system, including risk tolerance level, single / daily cumulative purchase limit, etc. By comparing whether the product code (product_code) in the request belongs to the product category that the account is allowed to purchase, it determines whether the transaction amount (amount) exceeds the limit set by the account permission and performs risk control checks.

[0059] After completing user signature verification and risk control checks, the overall security check is deemed passed only when both checks return a pass result, allowing entry into the transaction data body construction stage.

[0060] In this embodiment, by using a linkage mechanism of preset public key verification, account permission risk control and compliance verification, accurate identity authentication and risk control of wealth management purchase requests are achieved, ensuring that only legally authorized parties that meet regulatory requirements can enter the blockchain consensus and notarization process, thereby improving the credibility and compliance of the transaction initiator.

[0061] To improve the accuracy of constructing the transaction data body, the information processing method provided in Embodiment 1 of this application listens for scrolling events and, upon detecting a scrolling event, takes screenshots of the client's interface at preset time intervals. Each screenshot is associated with a page structure tree and scrolling position metadata, which includes at least an operation timestamp. The page structure tree of each screenshot is hashed to obtain a fragment hash value. All fragment hash values ​​are arranged in chronological order to form leaf nodes, and the parent node of every two leaf nodes is calculated layer by layer upwards to generate a Merkle tree structure. The user identifier initiating the financial purchase request and the initiation timestamp are used as the root node of the Merkle tree structure to construct the transaction data body.

[0062] In this embodiment of the invention, the client registers a DOM (Document Object Model) or view layer scroll event listener through the front-end framework. When the user scrolls through a financial recommendation page, risk disclosure statement, or product details page, a screenshot mechanism is triggered. The interface image of the currently visible area is automatically captured at preset time intervals (e.g., 200 milliseconds), and the DOM structure tree of the current page (including the tags, attributes, text content, and hierarchical relationships of all nodes) and scroll position metadata are collected simultaneously. The "operation timestamp" in the scroll position metadata is a system-generated timestamp accurate to milliseconds, used to identify the specific moment the screenshot occurred.

[0063] Here, scroll events refer to vertical or horizontal page scrolling actions triggered by user touch or gestures. The page structure tree is the DOM serialization structure generated by the front-end rendering engine, used to completely recreate the interface layout. Scroll position metadata is structured information recorded alongside the screenshot, describing the current viewport scroll offset (scrollY) and timestamp.

[0064] For each screenshot, the associated page structure tree is encoded using a hash algorithm. The input is a serialized JSON string of the structure tree (containing metadata such as node type, attributes, text, hierarchy, and scroll position). The output is a fixed-length hash value, called a "fragment hash value." Here, the fragment hash value refers to a cryptographic digest uniquely generated from the page structure and scrolling state corresponding to a single screenshot. It is collision-resistant and irreversible; any subtle interface differences (such as text position or button state) will cause a significant change in the hash value.

[0065] All shard hash values ​​are sorted in ascending order of operation timestamps and used as leaf nodes of the Merkle tree. Then, a hash algorithm is used to concatenate the hash values ​​of each pair of adjacent leaf nodes and hash them again to generate the hash of their parent node. This process is recursively repeated layer by layer until a unique root node is generated, resulting in the Merkle tree structure. Here, the Merkle tree structure is a binary hash tree structure, where the leaf nodes are shard hash values, the internal nodes are combined digests of the hash values ​​of their child nodes, and the root node is a unique digest of the entire tree.

[0066] The user identifier and the timestamp of the wealth management purchase request are used as metadata and encapsulated together with the hash value of the Merkle tree root node into the fields of the transaction data body to form a complete transaction data body.

[0067] Here, the user identifier is an anonymized on-chain address used to uniquely associate user identity with traceability evidence. The initiation timestamp is a precise timestamp generated by the server when the transaction request enters the system, ensuring a cross-verifiable timeline anchor with the screenshot time series.

[0068] In this embodiment, by listening to scrolling events, taking screenshots in segments, and constructing hash codes and Merkle trees, all user actions on the dynamic interface during the financial purchase process are transformed into a verifiable, traceable, and tamper-proof cryptographic evidence chain, which is strongly bound to the user's identity and the time of transaction initiation, thus achieving a comprehensive and high-fidelity backtracking record of the entire financial purchase process.

[0069] To improve the accuracy of determining consensus nodes and master nodes, in the information processing method provided in Embodiment 1 of this application, before using the Byzantine algorithm to process the transaction data body for consensus, the historical consensus success rate and historical response speed of each node on the blockchain are obtained; based on the historical consensus success rate and historical response speed, the credit value of the node is determined; nodes with a credit value greater than a preset credit threshold are determined as consensus nodes; and a polling mechanism is used to determine the master node from all consensus nodes.

[0070] In this embodiment of the invention, a monitoring module deployed on each blockchain node (including nodes from banking systems, wealth management subsidiaries, custodian banks, and regulatory agencies) continuously collects the behavior logs of each node in past consensus cycles. This logs calculate the total number of consensus rounds participated in and the number of times the three-stage process of pre-preparation—preparation—commit was successfully completed, resulting in a "historical consensus success rate." Simultaneously, the average processing latency from receiving the pre-preparation message to returning a response message is recorded as the "historical response speed." Here, the historical consensus success rate refers to the proportion of times a node successfully completes the consensus process in the past N consensus cycles out of its total participation, used to measure its reliability. The historical response speed refers to the average time a node takes to respond to messages in the consensus process, measured in milliseconds, used to measure its processing efficiency.

[0071] Based on a pre-defined dynamic credit scoring mechanism, the historical consensus success rate and historical response speed of each node are weighted and calculated. For example, the credit score = 0.6 × historical consensus success rate + 0.3 × historical response speed + 0.1 × resource contribution coefficient (such as bandwidth and storage capacity). The historical response speed is linearly normalized to ensure it is on the same order of magnitude as the consensus success rate. The resource contribution coefficient is estimated from hardware resource indicators (such as CPU utilization and disk capacity) actively reported by the node.

[0072] Here, the credit value is a dynamic score that comprehensively reflects the node's credibility and service performance, ranging from 0 to 100, and is used to characterize the node's reputation level in the consensus cluster.

[0073] A preset credit threshold is set, such as 75 points (based on the minimum reliability requirements of consensus nodes in the financial system). Only nodes with a credit value consistently above this threshold are included in the consensus node pool. If a node's credit value falls below the threshold for three consecutive periods due to timeout, invalid signature, or response delay, it is automatically downgraded to a validator node and no longer participates in block packaging.

[0074] The master node for this round of consensus is determined by taking the modulo of the current block height (block_height) and the total number of consensus nodes. The master node number is calculated as block_height mod N, where N is the number of nodes in the current consensus node pool. At the start of each consensus round, the master node is responsible for collecting transactions, generating pre-prepared messages, and broadcasting them. Its election is based entirely on block height order, without relying on node identity, IP (address), or priority, thus avoiding centralization.

[0075] In this embodiment, a dynamic credit scoring model is constructed based on historical consensus success rate and response speed. Combined with credit threshold screening and polling master node election mechanism, adaptive admission of consensus nodes and fair rotation of master nodes are realized. This effectively improves the consensus cluster's ability to resist malicious behavior, service stability and decentralization. It ensures that under the high security requirements of financial grade, the system can still continuously, reliably and auditably complete transaction consensus and backtracking data on the chain.

[0076] To improve the accuracy of consensus processing of transaction data, in the information processing method provided in Embodiment 1 of this application, the transaction data is sent to the master node; the master node constructs broadcast information based on the transaction data and broadcasts the broadcast information to each consensus node. Each consensus node verifies and signs the broadcast information upon receiving it, and returns the resulting consensus node signature to the master node. If the number of consensus node signatures received by the master node is greater than a preset number, consensus processing is determined to be complete, where the preset number is determined based on the total number of consensus nodes. If the number of consensus node signatures received by the master node is less than or equal to the preset number, consensus processing is determined to have failed, and consensus processing is restarted until consensus processing is complete.

[0077] In this embodiment of the invention, after completing the security check of the wealth management purchase request, the client transmits a transaction data body, encapsulating the user identifier, product code, amount, Merkle root hash, and user signature, to the master node of the current round through a secure communication channel. The master node is a node dynamically selected from the consensus node pool according to a polling mechanism, and its identity is authenticated by a digital certificate.

[0078] After receiving the transaction data body, the master node generates a PRE-PREPARE message, which includes the current view number, block height, hash digest of the transaction data body, and timestamp. The master node digitally signs the message header using its private key. Then, the master node broadcasts the PRE-PREPARE message to all consensus nodes. Upon receiving the broadcast information, each consensus node performs verification, including: (1) verifying the validity of the master node's signature to confirm its legitimacy; (2) verifying the integrity of the transaction data body's format and the compliance of the Merkle root hash; and (3) checking whether the user's signature and account permissions have passed the pre-security check. After successful verification, each consensus node generates a PRE-PREPARE message using its own private key and returns the signature result to the master node.

[0079] A preset consensus threshold is set to 2f+1, where f is the maximum number of Byzantine nodes the system can tolerate. If the total number of consensus nodes is N, then f = floor((N-1) / 3), so the preset number is 2×floor((N-1) / 3)+1. When the number of verified valid consensus node signatures received by the master node exceeds this threshold, a legal majority consensus is determined to have been reached, and the process enters the commit phase and generates the final block.

[0080] If the master node does not receive a sufficient number of valid signatures within a preset timeout window (e.g., 3 seconds), it determines that the consensus process has not reached a quorum, and the consensus process fails. At this point, the master node will abort the current round, trigger the view change mechanism, broadcast a VIEW-CHANGE message to all nodes, start a new round of master node election, and rebroadcast the transaction data body to the new master node, repeating the above pre-preparation-preparation-commit process until the preset number of signatures is met.

[0081] In this embodiment, distributed and highly fault-tolerant consensus processing of financial transaction data is achieved through master node coordination, multi-node signature verification, and a threshold determination mechanism based on Byzantine fault tolerance theory. This ensures that the system can still reliably complete transaction confirmation and signature aggregation even when some nodes fail or exhibit abnormal behavior. This provides underlying consensus guarantees for the immutability, consistency, and auditability of backtracking data in the blockchain ledger, significantly improving the stability and credibility of the financial-grade backtracking system.

[0082] To improve the accuracy of block generation, in the information processing method provided in Embodiment 1 of this application, the calculation time for each consensus node to calculate a random number based on the transaction data body is determined; the consensus node with the minimum calculation time is determined as the preset node; the hash of the last block on the blockchain is obtained; and the preset node is used to generate a block based on the hash of the last block, the transaction data body, the signatures of all consensus nodes, and the random number.

[0083] In this embodiment of the invention, after completing the three-stage consensus process (pre-preparation → preparation → submission) and receiving a preset number of consensus node signatures, each consensus node initiates a proof-of-work-based random number calculation task. Using the hash value of the transaction data body, the hash of the previous block, the current view number, and the set of all consensus node signatures as input, an iterative hash operation is performed using a hash algorithm to find a random number that meets a preset difficulty target (e.g., leading zeros ≥ 16). Each node independently executes this calculation process and records the real-time computation time from initiation to finding the random number, reporting this data to the master node via a local monitoring module.

[0084] Here, random numbers refer to the numbers used in the proof-of-work mechanism to meet the difficulty target, and their uniqueness and unpredictability guarantee the immutability of block generation.

[0085] Collect the computation time of random numbers reported by all consensus nodes, and select the consensus node with the smallest computation time as the "preset node". If multiple nodes have the same and smallest computation time, a unique node is selected according to the lexicographical order of the node ID. Here, the preset node refers to the consensus node designated to construct and submit the final block in the current block generation cycle. Its identity is determined by computational efficiency and is not statically assigned.

[0086] The blockchain reads the block header information of the latest confirmed block (i.e., the previous block) from the locally maintained blockchain ledger and extracts its "hash" field. This hash is generated by hashing all fields of the previous block header (including version number, previous block hash, Merkle root, timestamp, difficulty target, and random number) and is used for chain anchoring. Here, the hash refers to the unique identifier value calculated from the previous block header using a cryptographic hash function. It is irreversible and collision-resistant, and is the core structure for the continuity and tamper-proof nature of the blockchain.

[0087] The system uses preset nodes to encapsulate the hash of the last block, the transaction data body, the signatures of all consensus nodes, and the random number into a new block structure. For example, the "hash of the last block" is filled into the prev_block_hash field of the block header, the set of transaction data bodies is calculated using a Merkle tree root and filled into the tx_root field, the set of signatures of all consensus nodes is sorted by node ID and encoded into the consensus_signatures field, the calculated random number is filled into the nonce field, and then the block version, timestamp, state root (state_root) and other fields are filled in completely. Finally, the entire block header is hashed to generate the hash of the current block.

[0088] In this embodiment, by introducing a preset node selection mechanism based on computation time competition, and combining it with preceding block hashes, consensus signatures, and proof-of-work, the block generation process is decentralized, verifiable, and tamper-resistant. This not only preserves the Byzantine fault-tolerant consensus's guarantee of transaction consistency, but also enhances the fair allocation of block packaging rights and the system's resistance to attacks through the proof-of-work mechanism, ensuring that the backtracking ledger can still maintain chain integrity, non-forgeability, and continuous traceability in high-concurrency financial transaction scenarios.

[0089] To achieve accurate backtracking, in the information processing method provided in Embodiment 1 of this application, after generating a block based on the transaction data body using preset nodes, upon receiving a backtracking request, the blockchain is located based on the timestamp and user identifier contained in the backtracking request to obtain the block to be backtracked; based on the transaction data body contained in the block to be backtracked, a proof path is constructed and the signatures of all consensus nodes are obtained; if the proof path and the signatures of all consensus nodes are verified as passed, the backtracking of the financial purchase process is performed based on the transaction data body.

[0090] In this embodiment of the invention, when a user or regulatory agency initiates a backtracking request, a query instruction containing a specific timestamp and the user's on-chain address (user identifier) ​​is received. A multi-dimensional search is performed in the blockchain ledger through the indexing service. First, the user's exclusive user chain is located based on the user identifier. Then, the block range of the time point is determined in the global chain by combining the timestamp. Finally, the last block corresponding to the snapshot at the end of the day is locked as the "block to be backtracked".

[0091] Extract the state root of the day and the leaf node of the user's holdings in the state tree from the block to be backtracked. Based on the hierarchical structure of the Merkle tree, collect the hash values ​​of all sibling nodes on the path from the leaf node to the state root from bottom to top to form the Merkle proof path. At the same time, extract the set jointly signed by 2f+1 consensus nodes from the block header.

[0092] Perform dual verification on the client or audit terminal: First, based on the hash values ​​of sibling nodes in the proof path, reconstruct the Merkle tree layer by layer, calculate its root hash, and compare it with the state_root field in the block to be backtracked to confirm that the data has not been tampered with; Second, verify whether the number of valid signatures in the set of joint signatures reaches 2f+1, and whether the signer's identity is verified by the certificate chain to confirm that the block has obtained legal consensus; After the verification is passed, based on the transaction data body associated in the block to be backtracked, restore the sequence of all financial operations of the user before the target time point, including subscription, redemption, dividend reinvestment, etc., and reconstruct the operation interface by combining the front-end screenshot metadata (DOM tree, scrollY position) to achieve complete backtracking.

[0093] In this embodiment, a lightweight, highly secure, and independently verifiable financial retrospective process is achieved through a collaborative mechanism of block positioning based on timestamps and user identifiers, Merkel proof path construction, and consensus signature verification. This allows users or third parties to confirm the authenticity of historical operations without accessing the entire blockchain, effectively solving the problems of traditional retrospective systems that rely on centralized storage, are prone to data tampering, and have high auditing costs. This significantly improves the credibility, auditability, and compliance of the financial retrospective system.

[0094] Figure 3 This is a schematic diagram of an optional financial tracking process based on the Byzantine algorithm and blockchain technology according to an embodiment of the present invention, such as... Figure 3 As shown, the user first initiates a wealth management subscription request (including product code, amount, and user signature). The mobile banking gateway performs identity verification and risk control checks. After verification and checks are passed, a transaction data body is constructed and pre-prepare is performed to various consensus nodes. These consensus nodes include: consensus nodes represented by the banking system (bank), consensus nodes represented by the wealth management subsidiary (wealth management), and consensus nodes represented by the regulatory agency (regulatory). Each consensus node broadcasts a prepare message and mutually broadcasts confirmations, then commits a message. If consensus is reached, a block is generated, containing: transaction data, a set of consensus node signatures, the hash of the previous block, and a timestamp. A confirmation result is then returned to the user, and the block is simultaneously synchronized to the audit node (read-only) in real-time / near real-time. If the user initiates a backtracking request (to query holdings on a specific day) through the user's client, the block can be located, an SPV (Simplified Payment Verification) proof can be generated, and the proof and data can be returned. The user locally verifies the Merkle tree path and signature to ensure the data is authentic and has not been tampered with.

[0095] The information processing method provided in this application constructs a transaction data body based on a financial purchase request that has passed security checks. It combines a Byzantine fault-tolerant algorithm to achieve multi-node consensus, ensuring that even if some nodes are abnormal, a consistent record can still be reached. After consensus is achieved, a block containing complete transaction information is generated by a preset node. This ensures that the key operations and risk disclosure content of the financial purchase process are permanently, distributed, and tamper-proofly stored, providing a verifiable and traceable legal evidence chain for subsequent customer-level backtracking. This achieves the technical effect of providing an unforgeable and non-repudiable underlying guarantee for the entire financial purchase operation process.

[0096] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0097] Example 2

[0098] This application also provides an information processing apparatus. It should be noted that the information processing apparatus of this application can be used to execute the information processing method provided in this application. The information processing apparatus provided in this application will be described below.

[0099] According to an embodiment of this application, an apparatus for implementing the above-described information processing method is also provided. Figure 4 This is a schematic diagram of an optional information processing apparatus according to an embodiment of the present invention, such as... Figure 4 As shown, the information processing device may include: an inspection unit 40, a construction unit 41, a processing unit 42, and a generation unit 43.

[0100] The inspection unit 40 is used to perform a security check on the financial purchase request when it receives a financial purchase request initiated by the client.

[0101] Construction unit 41 is used to construct a transaction data body based on the wealth management purchase request after the security check of the wealth management purchase request has passed;

[0102] Processing unit 42 is used to perform consensus processing on the transaction data body using the Byzantine algorithm;

[0103] The generation unit 43 is used to generate blocks based on the transaction data body and using preset nodes after consensus processing is completed. The blocks are used to trace back the financial purchase process corresponding to the financial purchase request.

[0104] The information processing device provided in this application embodiment constructs a transaction data body based on the financial purchase request that has passed the security check. It combines the Byzantine fault tolerance algorithm to achieve multi-node consensus, ensuring that even if some nodes are abnormal, a consistent record can still be reached. After the consensus is completed, a block containing complete transaction information is generated by a preset node, so that the key operations and risk disclosure content of the financial purchase process are permanently, distributed and tamper-proofly stored. This provides a verifiable and traceable legal evidence chain for subsequent customer-level backtracking, thereby achieving the technical effect of unforgeable and non-repudiable underlying protection for the entire financial purchase operation process.

[0105] Optionally, the wealth management purchase request includes: product code, amount, and user signature. The inspection unit includes: a first verification module, used to verify the user signature using a preset public key, wherein the preset public key is the public key associated with the user account logged in on the client; a first inspection module, used to perform risk control checks on the product code and amount based on the user account's account permissions if the user signature verification is successful; and a first confirmation module, used to confirm that the security check of the wealth management purchase request has passed if the risk control check has passed.

[0106] Optionally, the construction unit includes: a first listening module, used to listen for scrolling events and, upon detecting a scrolling event, take screenshots of the client's interface at preset time intervals, wherein the screenshots are associated with a page structure tree and scroll position metadata, and the scroll position metadata includes at least an operation timestamp; a first encoding module, used to perform hash encoding on the page structure tree of each screenshot to obtain the fragment hash value of the screenshot; a first generation module, used to construct leaf nodes from all fragment hash values ​​in chronological order, and calculate the parent node of every two leaf nodes layer by layer upwards to generate a Merkle tree structure; and a first construction module, used to construct the transaction data body by using the user identifier and the initiation timestamp of the financial purchase request as the root node of the Merkle tree structure.

[0107] Optionally, the information processing device further includes: a first acquisition module, used to acquire the historical consensus success rate and historical response speed of each node on the blockchain before performing consensus processing on the transaction data using the Byzantine algorithm; a second determination module, used to determine the credit value of a node based on the historical consensus success rate and historical response speed; a third determination module, used to determine nodes with credit values ​​greater than a preset credit threshold as consensus nodes; and a fourth determination module, used to determine the master node from all consensus nodes using a round-robin mechanism.

[0108] Optionally, the processing unit includes: a first sending module for sending the transaction data body to the master node; a first broadcasting module for constructing broadcast information based on the transaction data body through the master node and broadcasting the broadcast information to each consensus node, wherein each consensus node verifies the broadcast information and signs it after receiving it, and returns the obtained consensus node signature to the master node; a fifth determining module for determining that consensus processing is complete when the number of consensus node signatures received by the master node is greater than a preset number, wherein the preset number is determined based on the number of all consensus nodes; and a sixth determining module for determining that consensus processing has failed and restarting consensus processing when the number of consensus node signatures received by the master node is less than or equal to the preset number, until consensus processing is complete.

[0109] Optionally, the generation unit includes: a seventh determining module, used to determine the computation time for each consensus node to calculate a random number based on the transaction data body; an eighth determining module, used to determine the consensus node indicated by the minimum computation time as the preset node; a second obtaining module, used to obtain the hash of the last block on the blockchain; and a second generation module, used to generate a block using the preset node, based on the hash of the last block, the transaction data body, the signatures of all consensus nodes, and the random number.

[0110] Optionally, the information processing device further includes: a first positioning module, used to locate the blockchain based on the timestamp and user identifier contained in the backtracking request after generating a block using preset nodes based on the transaction data body, and obtain the block to be backtracked; a second construction module, used to construct a proof path based on the transaction data body contained in the block to be backtracked, and obtain the signatures of all consensus nodes; and a first backtracking module, used to backtrack the financial purchase process based on the transaction data body after verifying the proof path and the signatures of all consensus nodes.

[0111] The aforementioned information processing device may further include a processor and a memory. The aforementioned checking unit 40, building unit 41, processing unit 42, generating unit 43, etc., are all stored in the memory as program units, and the processor executes the aforementioned program units stored in the memory to realize the corresponding functions.

[0112] The aforementioned processor contains a kernel, which retrieves the corresponding program units from memory. One or more kernels can be configured, and by adjusting kernel parameters, blocks can be generated based on the transaction data using preset nodes after consensus processing is complete.

[0113] The aforementioned memory may include non-permanent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0114] It should be noted that the inspection unit 40, construction unit 41, processing unit 42, and generation unit 43 mentioned above correspond to steps S201 to S204 in Embodiment 1. The instances and application scenarios implemented by the above units and corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0115] Example 3

[0116] Embodiments of this application may provide an electronic device. Figure 5 This is a structural block diagram of an electronic device according to an embodiment of the present invention. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0117] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the information processing method and apparatus in this application embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby realizing the aforementioned information processing method. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0118] The processor can access information and applications stored in memory via a transmission device to execute the following steps: upon receiving a financial purchase request initiated by a client, perform a security check on the financial purchase request; if the security check on the financial purchase request passes, construct a transaction data body based on the financial purchase request; perform consensus processing on the transaction data body using the Byzantine algorithm; if the consensus processing is completed, generate blocks based on the transaction data body using preset nodes, wherein the blocks are used to trace back the financial purchase process corresponding to the financial purchase request.

[0119] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: verifying the user signature using a preset public key, where the preset public key is the public key associated with the user account logged in on the client; if the user signature verification is successful, performing risk control checks on the product code and amount based on the user account's account permissions; if the risk control check passes, confirming that the security check of the wealth management purchase request has passed.

[0120] The processor can access information and applications stored in memory via a transmission device to perform the following steps: listen for scrolling events, and upon detecting a scrolling event, take screenshots of the client's interface at preset time intervals. Each screenshot is associated with a page structure tree and scroll position metadata, which includes at least an operation timestamp. The page structure tree for each screenshot is hashed to obtain a fragment hash value. All fragment hash values ​​are arranged in chronological order to form leaf nodes, and the parent node of every two leaf nodes is calculated layer by layer upwards to generate a Merkle tree structure. The user identifier and the timestamp of the user initiating the financial purchase request are used as the root node of the Merkle tree structure to construct the transaction data body.

[0121] The processor can access the information and applications stored in the memory via the transmission device to perform the following steps: obtain the historical consensus success rate and historical response speed of each node on the blockchain; determine the credit value of the node based on the historical consensus success rate and historical response speed; identify nodes with credit values ​​greater than a preset credit threshold as consensus nodes; and determine the master node from all consensus nodes using a round-robin mechanism.

[0122] The processor can access information and applications stored in memory via a transmission device to execute the following steps: sending the transaction data body to the master node; the master node constructs broadcast information based on the transaction data body and broadcasts the broadcast information to each consensus node, wherein each consensus node verifies and signs the broadcast information upon receiving it, and returns the obtained consensus node signature to the master node; if the number of consensus node signatures received by the master node is greater than a preset number, the consensus processing is determined to be complete, wherein the preset number is determined based on the total number of consensus nodes; if the number of consensus node signatures received by the master node is less than or equal to the preset number, the consensus processing is determined to be failed, and the consensus processing is restarted until the consensus processing is complete.

[0123] The processor can access the information and application stored in the memory via the transmission device to perform the following steps: determine the computation time for each consensus node to calculate a random number based on the transaction data body; determine the consensus node with the minimum computation time as the preset node; obtain the hash of the last block on the blockchain; and generate a block using the preset node, based on the hash of the last block, the transaction data body, the signatures of all consensus nodes, and the random number.

[0124] The processor can invoke information and applications stored in the memory through the transmission device to perform the following steps: upon receiving a backtracking request, locate the blockchain based on the timestamp and user identifier contained in the backtracking request to obtain the block to be backtracked; construct a proof path based on the transaction data body contained in the block to be backtracked, and obtain the signatures of all consensus nodes; if the proof path and the signatures of all consensus nodes are verified, backtrack the financial purchase process based on the transaction data body.

[0125] This application provides an information processing solution. By constructing a transaction data body based on financial purchase requests that have passed security checks, and combining it with a Byzantine fault-tolerant algorithm to achieve multi-node consensus, it ensures that even if some nodes malfunction, a consistent record can still be reached. After consensus is achieved, a block containing complete transaction information is generated by a preset node. This ensures that key operations and risk disclosures in the financial purchase process are permanently, distributed, and tamper-proofly stored, providing a verifiable and traceable legal evidence chain for subsequent customer-level backtracking. This achieves the technical effect of providing an unforgeable and non-repudiable underlying guarantee for the entire financial purchase process.

[0126] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be terminal devices such as smartphones, tablets, PDAs, and mobile internet devices (MIDs). Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0127] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0128] Example 4

[0129] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the information processing method provided in Embodiment 1.

[0130] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0131] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing steps of an information processing method.

[0132] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0133] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, 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 displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical 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 this application 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 application, 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 to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

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

Claims

1. An information processing method, characterized in that, include: Upon receiving a financial purchase request from a client, a security check is performed on the financial purchase request; If the security check on the investment purchase request passes, a transaction data body is constructed based on the investment purchase request; The Byzantine Fault Tolerance algorithm is used to perform consensus processing on the transaction data body. Once consensus processing is complete, a block is generated based on the transaction data body using preset nodes. The block is used to trace back the investment purchase process corresponding to the investment purchase request.

2. The information processing method according to claim 1, characterized in that, The investment purchase request includes: product code, amount, and user signature. The steps for performing a security check on the investment purchase request include: The user signature is verified using a preset public key, wherein the preset public key is the public key associated with the user account logged in by the client; If the user signature verification is successful, risk control checks are performed on the product code and the amount based on the user account's account permissions. If the risk control check passes, the security check on the financial purchase request is confirmed to have passed.

3. The information processing method according to claim 1, characterized in that, The steps for constructing a transaction data body based on the aforementioned investment purchase request include: The system listens for scroll events and, upon detecting a scroll event, takes screenshots of the client's interface at preset time intervals. The screenshots are associated with a page structure tree and scroll position metadata, and the scroll position metadata includes at least an operation timestamp. The page structure tree of each screenshot is hashed to obtain the fragment hash value of the screenshot; All the fragmented hash values ​​are arranged in chronological order to form leaf nodes, and the parent node of every two leaf nodes is calculated layer by layer upwards to generate a Merkle tree structure; The user identifier that initiated the wealth management purchase request and the initiation timestamp are used as the root node of the Merkle tree structure to construct the transaction data body.

4. The information processing method according to claim 1, characterized in that, Before performing consensus processing on the transaction data body using the Byzantine algorithm, the following steps are also included: Obtain the historical consensus success rate and historical response speed of each node on the blockchain; The credit value of the node is determined based on the historical consensus success rate and the historical response speed. The nodes whose credit values ​​are greater than a preset credit threshold are identified as consensus nodes; A polling mechanism is used to determine the master node from all the consensus nodes.

5. The information processing method according to claim 1, characterized in that, The steps for consensus processing of the transaction data using the Byzantine Fault Tolerance (BFT) algorithm include: Send the transaction data body to the master node; The master node constructs broadcast information based on the transaction data body and broadcasts the broadcast information to each consensus node. Each consensus node verifies the broadcast information and signs it after receiving it, and returns the obtained consensus node signature to the master node. If the number of consensus node signatures received by the master node is greater than a preset number, the consensus process is determined to be complete, wherein the preset number is determined based on the total number of all consensus nodes. If the number of consensus node signatures received by the master node is less than or equal to the preset number, the consensus processing is determined to have failed, and the consensus processing is restarted until the consensus processing is completed.

6. The information processing method according to claim 1, characterized in that, Based on the transaction data body, the step of generating blocks using preset nodes includes: Determine the computation time for each consensus node to calculate a random number based on the transaction data body; The consensus node indicated by the minimum computation time is determined as the preset node; Obtain the hash of the last block on the blockchain; Using the preset node, the block is generated based on the hash of the last block, the transaction data body, the signatures of all consensus nodes, and the random number.

7. The information processing method according to claim 1, characterized in that, After generating blocks using preset nodes based on the transaction data body, the process further includes: Upon receiving a backtracking request, the blockchain is located based on the timestamp and user identifier contained in the backtracking request to obtain the block to be backtracked; Based on the transaction data body contained in the block to be traced back, a proof path is constructed and the signatures of all consensus nodes are obtained; If the proof path and all consensus node signatures are verified, the financial purchase process is traced back based on the transaction data.

8. An information processing device, characterized in that, include: The inspection unit is used to perform a security check on the financial purchase request when it receives a financial purchase request initiated by the client. The construction unit is used to construct a transaction data body based on the financial purchase request, provided that the security check on the financial purchase request passes. The processing unit is used to perform consensus processing on the transaction data body using the Byzantine algorithm; The generation unit is used to generate blocks based on the transaction data body using preset nodes after consensus processing is completed. The blocks are used to backtrack the investment purchase process corresponding to the investment purchase request.

9. A computer program product, characterized in that, The method includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the information processing method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the information processing method according to any one of claims 1 to 7.

Images