Personalized postscript and abstract method and system

Abstract

The application relates to a personalized note and abstract method and system, relates to a blockchain application technology, and can be applied to the financial field and other fields.The method comprises the following steps: calling a member service through an SDK to obtain an identity certificate of a merchant with a specified note and abstract function; generating transaction proposal data through a note and abstract strategy according to the identity certificate and to-be-processed data; providing the transaction proposal data to a backing node in a blockchain network for backing strategy simulation; comparing the simulation result fed back by the backing node with the note and abstract result in the transaction proposal data, combining all transaction data in the to-be-processed data to generate business data according to a comparison result, and providing the business data to a sorting node in the blockchain network; performing consensus sorting processing on the transaction data in the business data through the sorting node and generating corresponding blocks; checking each piece of transaction data in the blocks through a submission node in the blockchain network; and adding the blocks to the blockchain network according to a checking result.

Description

Technical Field

[0001] This application relates to blockchain application technology, which can be applied to the financial sector and other fields, and in particular to a method and system for personalized notes and summaries. Background Technology

[0002] To improve customer satisfaction with the bank's acquiring system, the banking sector has proposed displaying personalized remarks and summary information on merchant invoicing and revenue / expense separation reports to facilitate business verification. Current technology stores these personalized remarks and summary information in a heterogeneous table within the merchant profile cluster of the acquiring application. However, due to the decoupling of the acquired application's distributed nodes and cluster splitting, with plans to migrate merchant invoicing-related data to the merchant clearing group, the existing solution is unsuitable for the post-cluster migration scenario.

[0003] The existing device has four main drawbacks. First, because the acquiring application is divided into different clusters, the distributed platform's processing efficiency is improved through cluster decoupling. However, since the existing RPC interfaces are located in the AC, NAC, and IPS clusters, the current device cannot synchronously support the merchant clearing cluster (MEC cluster)'s need to retrieve personalized remarks and summary information. Second, personalized remarks and summary information is stored in heterogeneous file tables, and there is no dedicated table for storing this information, which does not meet the specification requirement of designing different maintenance tables for different business scenarios. Third, the existing technology involves cross-cluster calls to MAMP-related heterogeneous file tables from AC, NAC, and IPS, increasing resource consumption and hindering subsequent maintenance. This application adopts a Kafka synchronization mechanism plus a fallback approach to synchronize relevant data from the clearing group to the AC, NAC, IPS, MC, and MEC groups, and then uses local service calls to retrieve relevant personalized remarks and summary information. This reduces resource consumption and uses the Kafka mechanism to solve the problem of non-real-time data synchronization across clusters. Fourth, since the personalized notes and summary information displayed is customer-oriented, ensuring the accuracy of the relevant information is crucial. Existing technologies store the relevant personalized notes and summary information in a distributed database, which poses a risk of data being maliciously tampered with. Summary of the Invention

[0004] The purpose of this application is to provide a method and system for personalized comments and summaries. It uses the Hyperledger blockchain framework to build a personalized comment and summary device, and uses smart contracts to realize the processes of merchant-submitted information preprocessing, rule assembly, and merchant return of personalized information and summaries. It also strictly controls user query and transaction-related permissions according to different merchants, and provides a decentralized personalized comment and summary device.

[0005] To achieve the above objectives, the personalized remarks and digest method provided in this application specifically includes: obtaining the merchant's identity certificate for specified remarks and digest functions by calling member services through an SDK; generating transaction proposal data based on the identity certificate and the data to be processed using a remarks and digest strategy; providing the transaction proposal data to endorsement nodes in the blockchain network for endorsement strategy simulation; comparing the consistency between the simulation results fed back by the endorsement nodes and the remarks and digest results in the transaction proposal data; combining all transaction data in the data to be processed to generate business data based on the comparison results; providing the business data to sorting nodes in the blockchain network; performing consensus sorting processing on the transaction data in the business data through the sorting nodes and generating corresponding blocks; verifying each transaction data in the block through submission nodes in the blockchain network; and adding the block to the blockchain network based on the verification results.

[0006] In the above personalized remarks and summary method, optionally, generating transaction proposal data based on the identity certificate and the data to be processed through the remarks and summary strategy includes: retrieving the corresponding execution logic in the remarks and summary strategy according to the processing type of the transaction data in the data to be processed; obtaining parameter information based on the execution logic and the data to be processed; and obtaining transaction proposal data based on the parameter information and the execution logic.

[0007] Optionally, in the above personalized postscript and summary method, the method further includes: the endorsing node obtaining postscript and summary identifiers based on the received transaction proposal data, and obtaining corresponding postscript and summary types based on the postscript and summary identifiers; retrieving corresponding postscript and summary data from the business data based on the postscript and summary types; concatenating corresponding postscript and summary information based on the postscript and summary information and the calling parameters; and generating corresponding simulation results based on the postscript and summary information.

[0008] In the above personalized remarks and summary methods, optionally, retrieving the corresponding remarks and summary data from the business data according to the remarks and summary types includes: obtaining pre-stored calling parameters according to the remarks and summary types; retrieving corresponding field information from the business data according to the calling parameters; and obtaining the remarks and summary data according to the field information.

[0009] Optionally, in the above personalized remarks and summary method, adding the block to the blockchain network based on the verification result further includes: dividing multiple consensus nodes in the blockchain network into multiple target node groups based on node attributes and transaction region information; filtering all consensus nodes under the same target node group based on the node information of the current node, and adding the block to the corresponding consensus node through an asynchronous consensus algorithm.

[0010] Optionally, in the above personalized remarks and summary method, the method further includes: synchronizing the remarks and summary results of the MAMP cluster to multiple business clusters associated with the bank acquiring application through a Kafka producer deployed on the MAMP cluster; and generating a unique index based on the synchronized updated remarks and summary results, and updating the locally stored remarks and summary results through the unique index.

[0011] In the above personalized remarks and summary method, optionally, updating the locally stored remarks and summary results through the unique index includes: generating a corresponding remarks and summary result update file based on the remarks and summary results of the MAMP cluster; sending the file from the MAMP file server to a predetermined file server via point-to-point file transfer; reading the remarks and summary result update file from the predetermined file server; matching the remarks and summary results of multiple business clusters associated with the bank acquiring application through the unique index; and updating the remarks and summary results of multiple business clusters associated with the bank acquiring application based on the matching results.

[0012] This application also provides a personalized postscript and summary system, comprising: a client, an endorsement node, a sorting node, and a submission node; the client obtains the identity certificate of a merchant with specified postscript and summary functions by calling a member service through an SDK, generates transaction proposal data based on the identity certificate and the data to be processed using postscript and summary strategies, and provides the transaction proposal data to the endorsement node in the blockchain network; and compares the consistency of the simulation results fed back by the endorsement node with the postscript and summary results in the transaction proposal data, combines all transaction data in the data to be processed to generate business data based on the comparison results, and provides it to the sorting node in the blockchain network; the endorsement node simulates the endorsement strategy based on the received transaction proposal data to generate simulation results and feeds them back to the client; the sorting node performs consensus sorting processing on the transaction data in the business data and generates corresponding blocks; the submission node verifies each transaction data in the block, and adds the block to the blockchain network based on the verification results.

[0013] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0014] This application also provides a computer-readable storage medium storing a computer program that performs the above-described methods.

[0015] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0016] The beneficial technical effects of this application are as follows: It employs the Hyperledger blockchain framework, with different transacting parties, merchants, and banks located in different channels. Only users with the relevant private keys have the authority to implement personalized remarks and summaries set by merchants, greatly improving the security of user data. Related business functions are implemented by writing corresponding user chaincode, which involves determining whether remarks and summaries are involved, identifying the processing type, input preprocessing, and rule assembly. Furthermore, an improved asynchronous consensus mechanism is used to ensure that data is recorded in the blockchain in order of transaction time, while simultaneously ensuring that the relevant information recorded by all non-faulty nodes on the chain is consistent and guaranteeing system operating efficiency. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. In the drawings:

[0018] Figure 1 A flowchart illustrating a personalized remarks and summary method provided in an embodiment of this application;

[0019] Figure 2 This is a schematic diagram of a transaction proposal data acquisition process provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of an endorsement simulation process provided in an embodiment of this application;

[0021] Figure 4 A schematic diagram illustrating the update process of the remarks and summary results provided in an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of the structure of a personalized remarks and summary system provided in an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] The following will describe in detail the implementation methods of this application with reference to the accompanying drawings and embodiments, so as to fully understand how this application uses technical means to solve technical problems and achieve technical effects, and to implement it accordingly. It should be noted that, as long as there is no conflict, the various embodiments and features in each embodiment of this application can be combined with each other, and the resulting technical solutions are all within the protection scope of this application.

[0025] Furthermore, 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.

[0026] Please refer to Figure 1 As shown, the personalized remarks and summary methods provided in this application specifically include:

[0027] S101 obtains the merchant's identity certificate for the specified remarks and summary functions by calling the member service through the SDK;

[0028] S102 generates transaction proposal data based on the identity certificate and the data to be processed through a postscript and summary strategy, and provides the transaction proposal data to the endorsement nodes in the blockchain network for endorsement strategy simulation.

[0029] S103 compares the consistency of the simulation results fed back by the endorsement node with the remarks and summary results in the transaction proposal data, and combines all the transaction data in the data to be processed to generate business data based on the comparison results, and provides it to the sorting node in the blockchain network.

[0030] S104 uses the sorting node to perform consensus sorting on the transaction data in the business data and generate corresponding blocks. The submitting node in the blockchain network verifies each transaction data in the block and adds the block to the blockchain network based on the verification results.

[0031] In the above embodiments, the personalized remarks and summary method mainly applies the Hyperledger blockchain framework. The Hyperledger blockchain framework has modules that can be directly plugged in and enabled, are independent of each other, and have different functions, making it suitable for the business requirements of personalized remarks and summaries in this application. Furthermore, the most important reason why the Hyperledger blockchain framework is suitable for this business context is that it provides the function of establishing channels, allowing participants to create a separate ledger for each transaction. Only participants in the same channel will have access to that channel's ledger, while other participants not in this channel will not see this ledger. This channel isolation technology brings higher security. Therefore, in the above embodiments of this application, the personalized remarks and summary method uses merchant IDs as a dimension. Different customers have an independent merchant ID, and the personalized remarks and summary requirements of different merchants are located in different channels. This channel isolation technology improves overall security. The Hyperledger blockchain framework is divided into a network layer, a core layer, and an interface layer. The core layer consists of three parts: member services, blockchain services, and chaincode services. The interface layer calls information such as identity, ledger, transactions, and smart contracts through interfaces and events. The network layer is responsible for the implementation of the P2P network, ensuring the consistency of the distributed storage of the blockchain.

[0032] Before the advent of blockchain, businesses relied on distributed personalized message and summary devices to meet the personalized message and summary report display needs of key acquiring business scenarios such as merchant accounting and revenue / expense separation. The biggest drawback of this approach is that the centralized mechanism increases the risk of malicious tampering with personalized message and summary displays. To address this issue, this application utilizes the Hyperledger blockchain framework to build a personalized message and summary device, enhancing system security, ensuring accurate report display, and achieving a blockchain system with tamper-proof, secure, and reliable characteristics.

[0033] When transactions are conducted through POS terminals, API interfaces, and EPAY channels, relevant data files are first maintained in the personalized templates and personalized summary interfaces of the merchant operation platform. After receiving transaction requests from POS terminals, API interfaces, and EPAY channels, the acquiring application, depending on the specific business scenario (merchant payment (batch deduction), fee deduction, return payment (non-netting), customized services, and merchant payment (real-time)), triggers a smart contract in the Hyperledger blockchain framework to return the corresponding personalized message fields, which are then displayed in relevant reports. Merchant payment (batch deduction) refers to the scenario where transactions are processed on the same day and funds are transferred to merchants in batches at the end of the following day; the relevant report is the Merchant Payment Details Report. Fee deduction applies to all acquiring transactions involving commission collection; the relevant report is the Commission Fee Display Report. Return deduction (non-netting) addresses business scenarios where returns are deducted in non-netting business situations such as revenue and expense separation. In these scenarios, the merchant returns the refund to the customer via the original payment method. The relevant reports are those related to revenue and expense separation return cashback. Customized services are for merchants with specific comment requirements, regardless of the business scenario (whether it's merchant receipts, fee deductions, revenue and expense separation, etc.). The designated reports will display the personalized comment information set by the merchant. Merchant receipts (real-time) address business scenarios where transactions are recorded for the merchant in real-time. The relevant reports are the merchant receipt details reports. In summary business scenarios, different business scenarios are considered (summary business involves clearing receipts (batch), clearing receipts (real-time), fee deductions (revenue and expense separation), non-netting return deductions, and netting return deductions (returns exceeding consumption)). Clearing receipts (batch) and clearing receipts (real-time) are consistent with the above-mentioned merchant receipts (batch deductions) and merchant receipts (real-time) business scenarios, and will not be elaborated upon here. Fee deduction (revenue and expenditure separation) refers to the business scenario of fee deduction under the revenue and expenditure separation scenario. Revenue and expenditure separation means that when a customer makes a related transaction and the merchant records it, the deducted commission and revenue are displayed separately in the financial statements. Non-netted return deduction and netted return deduction (returns exceed consumption) refer to the business scenarios where returns occur in the netted return and non-netted return business scenarios. Among them, netted return means that within a certain refund period, the acquiring transaction is deducted from the merchant and returned to the customer through the original payment method, and the bank refunds the transaction commission income.The main differences between remarks and summaries lie in two aspects. First, remarks display more comprehensive information, typically including fixed values, transaction date, commission amount, transaction amount, and personalized configuration items 1-10. Summaries, on the other hand, generally display a summary of the transaction, which is less detailed. Summary types typically include fixed values, merchant ID and payment category, ICBC order number (last 20 digits), merchant order number (last 20 digits), commission + merchant ID, commission + merchant ID + payment category, refund + merchant ID, refund + merchant ID + payment category, and merchant refund transaction number (last 20 digits). Second, their purposes differ. Bank remarks provide notes and explanations regarding the purpose of the transfer, while bank summaries are special identifiers added by users to uniquely identify transactions, facilitating quicker identification by customers.

[0034] Please refer to Figure 2 As shown, in one embodiment of this application, generating transaction proposal data based on the identity certificate and the data to be processed using a postscript and summary strategy includes:

[0035] S201 retrieves the corresponding execution logic from the remarks and summary strategies based on the processing type of the transaction data in the data to be processed;

[0036] S202 Obtains parameter information based on the execution logic and the data to be processed;

[0037] S203 obtains transaction proposal data based on the parameter information and the execution logic.

[0038] Specifically, in practice, the application client initiates a transaction proposal to the blockchain network through the SDK. The transaction proposal sends the following information to the endorsing node: the contract identifier to be invoked in this transaction (whether it involves comments and digests, determining the processing type (selecting comments or digests), input preprocessing, and rule assembly), contract methods (selecting specific rules for assembling personalized comments and digests based on different comment and digest types), parameter information (such as merchant ID, bank order number, transaction amount, commission amount, etc.), and client signature (uniquely identifying business and customer information).

[0039] Please refer to this again. Figure 3 As shown, the method further includes:

[0040] The endorsing node in S301 obtains the appendix and summary identifiers based on the received transaction proposal data, and obtains the corresponding appendix and summary types based on the appendix and summary identifiers;

[0041] S302 retrieves the corresponding postscript and summary data from the business data according to the postscript and summary types;

[0042] S303 concatenates the corresponding postscript and summary information with the calling parameters, and generates the corresponding simulation result based on the postscript and summary information.

[0043] Specifically, in practice, after receiving a transaction proposal, the endorsing node (referring to the peer node) verifies the signature (which can uniquely identify the business and customer information) and confirms whether the submitter has the authority to execute the operation. At the same time, it simulates the execution of the smart contract according to the endorsement strategy (whether it involves comments and summaries, determines the processing type, input preprocessing and rule assembly, and other related smart contracts), and returns the result and its respective CA certificate signature to the application client.

[0044] Subsequently, after receiving the information from the endorsing nodes, the application client determines whether the proposal results are consistent and whether the specified endorsement strategy is followed. If there are insufficient endorsements, processing is aborted; otherwise, the application client packages the data together to form a transaction, signs it, and sends it to the ordering role (Order node). The ordering role performs consensus ordering on the received transactions, and then packages a batch of transactions together to generate a new block according to the block generation strategy, sending it to the committing node (Peer node). After receiving the block, the committing node verifies each transaction in the block, checks whether the inputs and outputs that the transaction depends on conform to the current state of the blockchain, appends the block to its local blockchain, and modifies the world state (the latest value of all keys).

[0045] In one embodiment of this application, the identity authentication step in the above-mentioned personalized remarks and summary method mainly applies the MSP module of the Hyperledger blockchain framework, and its specific authentication process is as follows:

[0046] 1. Manage User IDs (Management mechanism for all user IDs authorized to access personalized comments and summary features)

[0047] 2. Verify nodes that want to join the network: Each node that wants to join the network must provide its valid and legitimate MSP information.

[0048] 3. Provide credentials for transactions initiated by clients: Data transmission between nodes (Client, Peer, Orderer) requires verification of the signatures of each node.

[0049] The logical structure of the MSP can be found here. Figure 4As shown, RCA refers to the Root CA, and this folder contains a list of self-signed X.509 certificates issued by the Root CA for self-signing and signing intermediate CA certificates. ICA refers to the Intermediate CA, containing a list of certificates issued by the Root CA. OU refers to an Organizational Unit, containing a list of organizational units whose members are considered part of the organization represented by this MSP. B refers to Administrator, and this folder contains a list of identifiers defining roles with the administrator role in this organization. For standard MSP types, this list should contain one or more X.509 certificates. ReCA refers to Revoked Certificate, storing information about revoked participants. Business user accounts that have exited the personalized remarks and digest functions should be in the revoked certificate list and cannot use related functions. SCA refers to the Signing Certificate, the signing certificate of the endorsing node in the transaction proposal response. This folder is required for the local MSP, and the node must have only one X.509 certificate. KeyStore refers to the Private Key, and this folder is defined for the local MSP of Peer or Orderer nodes and contains the node's signing key. This key is cryptographically matched against the signing certificates contained in the SCA folder and used to sign data. This folder is required for the local MSP and must contain only one private key. TLS Root CA: Contains a list of self-signed X.509 certificates from root CAs trusted by the organization for TLS communication. This folder must contain at least one TLS root CA X.509 certificate. TLS Intermediate CA: Stores a list of intermediate certificates issued by the TLS root CA.

[0050] In one embodiment of this application, retrieving the corresponding postscript and summary data from the business data according to the postscript and summary type includes: obtaining pre-stored calling parameters according to the postscript and summary type; retrieving corresponding field information from the business data according to the calling parameters; and obtaining postscript and summary data according to the field information.

[0051] Specifically, the personalized remarks and summaries generated by the endorsing nodes and smart contracts mainly involve four processes: whether remarks and summaries are involved, determining the processing type, input preprocessing, and rule assembly. When the client triggers transaction processes such as merchant receipt and revenue / expense separation, the four processes of the smart contract are triggered sequentially.

[0052] Whether or not a message or summary is involved refers to determining whether the merchant involved in the merchant accounting and revenue / expense separation business process has set up a personalized message and summary identifier in the acquiring merchant operation platform. If the relevant identifier is set, the smart contract for determining the processing type is executed; otherwise, the subsequent business processing flow for merchant accounting and revenue / expense separation is executed.

[0053] Determining the processing type refers to whether the merchants involved in the business of separating revenue and expenditure have only a need for personalized remarks reports, only a need for personalized summary reports, or a need for both personalized remarks reports and personalized summary reports.

[0054] Input preprocessing involves selecting different input parameters for different message and summary business types, which then serve as the input parameters for the smart contract that assembles the personalized message and summary information. For example, for a business type of merchant accounting with revenue and expense separation, the message type is fixed value + commission amount + transaction amount + personalized configuration 1. In the input preprocessing process, the corresponding message and summary rules are first determined for each merchant based on different business scenarios (merchant accounting, revenue and expense separation, etc.). As mentioned above, the message rule is fixed value + commission amount + transaction amount + personalized configuration 1. For fields like commission amount and transaction amount, these are sent to the smart contract from the transaction side, and the commission amount and transaction amount are selected from the various inputs sent by the transaction side. For information such as fixed value and personalized configuration 1, relevant information is obtained from the personalized information table based on the specific merchant. For the message business scenario, the message rules and the selected inputs are summarized, and the rule assembly smart contract is triggered. For business types such as merchant invoicing with revenue and expenditure separation, and summary types such as commission + merchant number + invoicing category, the above summary fields can be filtered from the many inputs sent by the transaction side. Then, the summary rules are sent up to summarize the selected inputs, which also triggers the rule assembly smart contract.

[0055] Remark types include fixed values, transaction date, commission rebate amount, transaction amount, and personalized information configuration items 1-10. Summary types include fixed values, merchant ID, merchant ID and invoice category, ICBC order number (last 20 digits), merchant order number (last 20 digits), commission rebate + merchant ID, commission rebate + merchant ID + invoice category, refund + merchant ID, refund + merchant ID + invoice category, and merchant refund serial number (last 20 digits). The input preprocessing smart contract selects inputs from the transaction side and retrieves relevant data from the personalized information table according to the fields required by the rules.

[0056] Rule-based smart contracts, as the name suggests, assemble data according to specified rules based on the input remarks and summaries, and ultimately output personalized remarks and summaries for display in reports. After processing by the personalized remarks and summaries blockchain generation system, the returned personalized remarks and summaries serve as input for the system's report application, and are then processed and printed on the reports.

[0057] In one embodiment of this application, the personalized remarks and summary method simultaneously introduces a Kafka + fallback mechanism to synchronize personalized remarks and summary information from the MAMP cluster to the AC, NAC, IPS, MC, and MEC clusters. This ensures that merchants deployed in the Merchant Clearing Group (MEC) can obtain personalized remarks and summary information in real time for their billing and revenue / expense separation processes. Specifically, given that the data related to personalized remarks and summaries is stored in the MAMP cluster of the acquiring application, and the blockchain technology used subsequently is mainly applied to acquiring business scenarios such as merchant billing and revenue / expense separation to obtain personalized remarks and summary information, and since the information obtained using cross-chain technology is deployed in the MEC cluster, synchronizing personalized remarks and summary information from the MAMP cluster to the MEC cluster in real time across clusters becomes the most important problem to be solved in this application. This application adopts a Kafka + fallback mechanism to synchronize personalized templates and information tables.

[0058] In one embodiment of this application, the method further includes: synchronously updating the remarks and summary results of the MAMP cluster to multiple business clusters associated with the bank acquiring application via a Kafka producer deployed on the MAMP cluster; and generating a unique index based on the synchronously updated remarks and summary results via the unique index, and updating the locally stored remarks and summary results using the unique index. Further details can be found in the following documentation. Figure 4 As shown, the postscript and summary results of updating local inventory through the unique index include:

[0059] S401 generates corresponding update files for comments and summary results based on the comments and summary results of the MAMP cluster;

[0060] S402 sends files from the MAMP file server to a designated file server via point-to-point file transfer.

[0061] S403 reads the comments and summary results from the pre-defined file server to update the file, and matches the comments and summary results of multiple business clusters associated with the bank acquiring application using a unique index;

[0062] S404 updates the remarks and summary results of multiple business clusters associated with the bank acquiring application based on the matching results.

[0063] In practice, because the acquiring application plans to migrate key business functions such as merchant accounting and revenue / expense separation to the merchant clearing cluster, most transactions are still deployed on the acquiring application's AC, NAC, and IPS clusters. The AC cluster is the online cluster, primarily for online transactions. The NAC cluster is the core cluster, primarily for core transaction scenarios such as bank card acquiring, entrusted payment, POS points, and UnionPay acquiring. The IPS cluster is the aggregated payment cluster, primarily for aggregated transaction scenarios (such as WeChat Pay, Alipay, etc.). The plan is to uniformly migrate relevant transactions from the AC, NAC, and IPS clusters to the MEC cluster. Since the migration plan is progressing smoothly, this application requires real-time synchronization of personalized remarks and summary data from the MAMP cluster to the aforementioned four clusters: AC, NAC, IPS, and MEC.

[0064] To achieve the above functionality, the plan is to deploy Kafka producers on MAMP, and consumers on AC, NAC, IPS, and MEC to enable real-time synchronization of personalized remarks and summary information. No additional development is required for the producers; they only need to configure DRP to synchronize database updates. After configuring the relevant DRP parameters, the database will automatically update and send Kafka information. For personalized information and template data maintained in real-time by the merchant operations platform, the Kafka producers deployed on the MAMP cluster will synchronize data to the four clusters (AC, NAC, IPS, and MEC) in real time.

[0065] Kafka consumers deployed on AC, NAC, IPS, and MEC clusters will update the existing data for personalized remarks and summary data based on unique indexes. If data with the same unique index exists, the existing data will be updated; otherwise, the data will be newly maintained in the personalized information and template tables of the AC, NAC, IPS, and MEC clusters.

[0066] Due to the potential for data loss caused by the accumulation of Kafka transactions during peak acquiring periods, some personalized remarks and summary information cannot be updated in a timely manner. To address this issue, this application employs an end-of-day batch backup mechanism to update the personalized remarks and summary information with data loss to the personalized information and template tables of the AC, NAC, IPS, and MEC clusters on the same day.

[0067] The principle is as follows: For MAMP clusters with personalized remarks and summary information updated to the current timestamp, a personalized remarks and summary update file is generated from the MAMP cluster's personalized remarks and summary table. This file is then transferred from the MAMP file server to the SAES file server via point-to-point file transfer. The personalized remarks and summary update file sent to the SAES file server is then read, and a unique index is used to match the personalized information template tables of the AC, NAC, IPS, and MEC clusters. If duplicate indexes exist, the standby field FLAG1 is updated to indicate successful reconciliation. If no duplicate indexes are found, the relevant data is inserted into the personalized information template tables of the AC, NAC, IPS, and MEC clusters.

[0068] In one embodiment of this application, adding the block to the blockchain network based on the verification result further includes: dividing multiple consensus nodes in the blockchain network into multiple target node groups based on node attributes and transaction region information; filtering all consensus nodes under the same target node group based on the node information of the current node; and adding the block to the corresponding consensus node through an asynchronous consensus algorithm.

[0069] Specifically, in a blockchain network, transactions written by different participants must be written to the ledger sequentially in the order they are generated. How to achieve consistency among all nodes for the same proposal or value in a distributed environment is a problem that blockchain technology must consider and solve. To achieve this, the transaction order must be correctly established, and methods for handling tampering or malicious submissions of transactions must be included.

[0070] Consensus algorithms are typically used to ensure consistency in distributed systems. In computer science, they are processes used to achieve consistency on a single data value between distributed processes or systems. Consensus algorithms aim to achieve reliability among multiple unreliable nodes in a network, and solving the consensus problem is crucial in distributed computing and multi-agent systems. Consensus algorithms must satisfy two properties to guarantee consistency among nodes: safety and liveness. Safety means that each node guarantees the same input sequence and produces the same output result on each node. When nodes receive the same series of transactions, the same state change will occur on each node; the algorithm must produce the same result as the system's execution on each node. Liveness refers to the fact that, under normal communication conditions, each non-faulty node will eventually receive every committed transaction.

[0071] To ensure transaction consistency across all nodes in personalized message and summary-related transactions, and to guarantee consistent execution results across nodes, this application employs an asynchronous consensus algorithm based on the Hyperledger blockchain framework, making it suitable for the normal operation of personalized message and summary transactions. For asynchronous consensus algorithms, efficiently implementing an asynchronous Byzantine fault-tolerant consensus algorithm has become an important research direction. How to design an efficient implementation of an asynchronous Byzantine fault-tolerant consensus algorithm has always been a crucial research topic in cryptography and distributed systems. The asynchronous consensus algorithm used in this application is an improvement upon the Honey Badger algorithm, reducing blockchain consensus latency and significantly increasing transaction throughput. Due to the large number of acquiring merchants requiring personalized messages and summaries, achieving accurate consensus and ensuring precise data synchronization to the chain for merchants located in different channels presents a significant challenge for this device. To address this issue, multiple target node groups are formed based on transactions from different regions and node attributes. Each target node group can contain multiple target nodes, and target nodes within the same group generally need to have consistent node attributes. Node attributes include one or more of the following: node state attributes, node function attributes, and node status attributes. Node state attributes can be understood as the operational status attributes of a blockchain node, such as memory capacity and CPU utilization. Node function attributes can be understood as the type of functions a blockchain node performs or the work content of the blockchain node; generally, based on different functions, they are divided into endorsement nodes, peer nodes, commit nodes, and orderer nodes. Node status attributes can be understood as the status or responsibility attributes undertaken by the blockchain; blockchain nodes can be divided into control nodes and non-control nodes based on different status attributes. In this application, based on different acquiring regions and different types of node attributes, multiple target node groups are divided. Consensus nodes are then determined from different target node groups based on the consensus election results, where the consensus election results use a unique identifier consisting of a region code + node attribute type + detailed distinction to determine the elected consensus node. For each target node group, only a small number of nodes will be elected as consensus nodes, while the majority of nodes are non-consensus nodes. For nodes elected as consensus nodes in the target node group, the node executes an asynchronous consensus algorithm (the asynchronous consensus algorithm used in this application is an improvement on the Honey Badger algorithm, which improves the blockchain consensus latency and significantly increases transaction throughput) and obtains a consensus block. The target node uses a verifiable random function to generate random numbers and proof information for the consensus block, stores the random numbers and proof information in the consensus block, and then outputs the consensus block. For non-consensus nodes in the target node group, the target node receives the consensus block output by the consensus node, ensuring that personalized remarks and summary information based on the Hyperledger blockchain framework are maintained and synchronized to the entire blockchain system according to the merchant's usage information.

[0072] Please refer to Figure 5 As shown, this application also provides a personalized postscript and summary system, which includes: a client, an endorsement node, a sorting node, and a submission node; the client obtains the identity certificate of the merchant with specified postscript and summary functions by calling the member service through the SDK, generates transaction proposal data according to the identity certificate and the data to be processed through the postscript and summary strategy, and provides the transaction proposal data to the endorsement node in the blockchain network; and compares the consistency between the simulation results fed back by the endorsement node and the postscript and summary results in the transaction proposal data, combines all transaction data in the data to be processed to generate business data according to the comparison result, and provides it to the sorting node in the blockchain network; the endorsement node simulates the endorsement strategy according to the received transaction proposal data to generate simulation results and feeds them back to the client; the sorting node performs consensus sorting processing on the transaction data in the business data and generates corresponding blocks; the submission node verifies each transaction data in the block, and adds the block to the blockchain network according to the verification result.

[0073] Based on the aforementioned personalized comments and summary system, the actual process for adding comments and summaries to transaction information is as follows:

[0074] 1. The application client (merchant billing, revenue and expenditure separation and other acquiring business transaction entry points) calls member services through the SDK to register and obtain identity certificates that allow the call to personalized remarks and summary smart contracts.

[0075] 2. The application client initiates a transaction proposal to the blockchain network through the SDK. The transaction proposal sends the following information to the endorsing node: the smart contract identifier to be called in this transaction (whether it involves comments and digests in order of execution, determining the processing type (selecting comments or digests), input preprocessing, and rule assembly of related smart contracts), contract methods (the specific implementation logic of the smart contract methods), parameter information (the required input items for calling the corresponding smart contract and the flags sent to uniquely identify the smart contract), and client signature (an identifier that identifies which transaction channel the client is in and a tag to verify identity).

[0076] 3. After receiving the transaction signature, the endorsing node verifies the signature and confirms whether the submitter has the right to execute the operation. At the same time, it simulates the execution of the smart contract according to the endorsement strategy and returns the result and its respective CA signature to the application client.

[0077] 4. After receiving the information returned by the endorsement node, the application client (business scenarios such as merchant accounting and revenue and expenditure separation) determines whether the proposal result is consistent and whether it is executed in accordance with the specified endorsement strategy. The application client packages the data together to form a transaction, signs it, and sends it to the sorting role.

[0078] 5. The sorting role performs consensus sorting on the received transactions, and finally packages a batch of transactions together according to the block generation strategy to generate a new block and send it to the committing node.

[0079] 6. After receiving a block, the committing node will verify each transaction in the block, check whether the inputs and outputs that the transaction depends on are consistent with the current state of the blockchain, and then append the block to the local blockchain and modify the world state.

[0080] The beneficial technical effects of this application are as follows: It employs the Hyperledger blockchain framework, with different transacting parties, merchants, and banks located in different channels. Only users with the relevant private keys have the authority to implement personalized remarks and summaries set by merchants, greatly improving the security of user data. Related business functions are implemented by writing corresponding user chaincode, which involves determining whether remarks and summaries are involved, identifying the processing type, input preprocessing, and rule assembly. Furthermore, an improved asynchronous consensus mechanism is used to ensure that data is recorded in the blockchain in order of transaction time, while simultaneously ensuring that the relevant information recorded by all non-faulty nodes on the chain is consistent and guaranteeing system operating efficiency.

[0081] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0082] This application also provides a computer-readable storage medium storing a computer program that performs the above-described methods.

[0083] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0084] like Figure 6 As shown, the electronic device 600 may also include: a communication module 110, an input unit 120, an audio processing unit 130, a display 160, and a power supply 170. It is worth noting that the electronic device 600 does not necessarily need to include these components. Figure 6 All components shown; in addition, the electronic device 600 may also include Figure 6 For components not shown, please refer to existing technologies.

[0085] like Figure 6 As shown, the central processing unit 100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device. The central processing unit 100 receives inputs and controls the operation of various components of the electronic device 600.

[0086] The memory 140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 100 may execute the program stored in the memory 140 to perform information storage or processing, etc.

[0087] Input unit 120 provides input to central processing unit 100. Input unit 120 may be, for example, a keypad or touch input device. Power supply 170 provides power to electronic device 600. Display 160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0088] The memory 140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 140 can also be some other type of device. The memory 140 includes a buffer memory 141 (sometimes referred to as a buffer). The memory 140 may include an application / function storage unit 142 for storing application programs and function programs or processes for executing the operation of the electronic device 600 via the central processing unit 100.

[0089] The memory 140 may also include a data storage unit (data 143) for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit (driver 144) of the memory 140 may include various drivers for the electronic device's communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0090] The communication module 110 is a transmitter / receiver 110 that transmits and receives signals via antenna 111. The communication module (transmitter / receiver) 110 is coupled to the central processing unit 100 to provide input signals and receive output signals, which can be the same as in a conventional mobile communication terminal.

[0091] Based on different communication technologies, multiple communication modules 110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide audio output via the speaker 131 and receive audio input from the microphone 132, thereby enabling typical telecommunications functions. The audio processor 130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 130 is coupled to a central processing unit 100, enabling on-device recording via the microphone 132 and on-device playback of stored audio via the speaker 131.

[0092] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for personalized comments and summaries, characterized in that, The method, applied to scenarios involving bank merchant invoicing and revenue / expense separation, includes: The SDK is used to call the member service to obtain the merchant's identity certificate for the specified remarks and summary functions; Based on the identity certificate and the data to be processed, transaction proposal data is generated through a postscript and summary strategy. The transaction proposal data is then provided to the endorsement nodes in the blockchain network for endorsement strategy simulation. The endorsing node obtains postscript and summary identifiers based on the received transaction proposal data, and obtains corresponding postscript and summary types based on the postscript and summary identifiers; it obtains pre-stored calling parameters based on the postscript and summary types; it retrieves corresponding field information from the data to be processed based on the calling parameters, and obtains postscript and summary data based on the field information; it concatenates the corresponding postscript and summary information based on the postscript and summary data and the calling parameters, and generates the corresponding simulation result based on the postscript and summary information. The simulation results fed back by the endorsement node are compared with the remarks and summary results in the transaction proposal data. Based on the comparison results, all transaction data in the data to be processed are combined to generate business data and provided to the sorting node in the blockchain network. The sorting node performs consensus sorting on the transaction data in the business data and generates corresponding blocks. The submitting node in the blockchain network verifies each transaction in the block and adds the block to the blockchain network based on the verification results. The Kafka producer deployed on the MAMP cluster synchronizes and updates the MAMP cluster's comments and summary results to multiple business clusters associated with the bank acquiring application. Kafka consumers deployed on multiple business clusters associated with the bank acquiring application generate unique indexes based on synchronously updated comments and summary results; Generate corresponding update files for comments and summaries based on the comments and summary results of the MAMP cluster; Files are transferred from the MAMP file server to a designated file server via peer-to-peer file transfer. The file is updated by reading the comments and summary results from the pre-defined file server and matching the comments and summary results of multiple business clusters associated with the bank acquiring application using a unique index. Update the remarks and summary results of multiple business clusters associated with the bank acquiring application based on the matching results; The process of generating transaction proposal data based on the identity certificate and the data to be processed using a postscript and summary strategy includes: retrieving the corresponding execution logic in the postscript and summary strategy according to the processing type of the transaction data in the data to be processed; obtaining parameter information based on the execution logic and the data to be processed; and generating transaction proposal data based on the parameter information and the execution logic.

2. The personalized remarks and summary method according to claim 1, characterized in that, Adding the block to the blockchain network based on the verification result also includes: Based on node attributes and transaction region information, multiple consensus nodes in the blockchain network are divided into multiple target node groups; Based on the node information of the current node, all consensus nodes under the same target node group are obtained through filtering, and the block is then sent to the corresponding consensus node through an asynchronous consensus algorithm to join the blockchain network.

3. A personalized postscript and summary system, characterized in that, The system is applied to the business scenarios of bank merchant invoicing and revenue and expenditure separation. It includes: client, endorsement node, sorting node and submission node. The client obtains the identity certificate of the merchant with specified postscript and digest functions by calling the member service through the SDK, and generates transaction proposal data according to the identity certificate and the data to be processed through the postscript and digest strategy. The transaction proposal data is provided to the endorsement node in the blockchain network. Furthermore, the simulation results fed back by the endorsement node are compared with the remarks and summary results in the transaction proposal data. Based on the comparison results, all transaction data in the data to be processed are combined to generate business data and provided to the sorting node in the blockchain network. The endorsing node simulates the endorsement strategy based on the received transaction proposal data, generates simulation results, and feeds them back to the client. The endorsing node obtains a postscript and summary identifier based on the received transaction proposal data, and obtains the corresponding postscript and summary type based on the postscript and summary identifier; obtains pre-stored calling parameters based on the postscript and summary type; retrieves the corresponding field information from the data to be processed based on the calling parameters, and obtains postscript and summary data based on the field information; concatenates the corresponding postscript and summary information based on the postscript and summary data and the calling parameters, and generates the corresponding simulation result based on the postscript and summary information. The sorting node performs consensus sorting on the transaction data in the business data and generates corresponding blocks. The submitting node verifies each transaction in the block and adds the block to the blockchain network based on the verification results. The client synchronizes and updates the comments and summary results of the MAMP cluster to multiple business clusters associated with the bank acquiring application through the Kafka producer deployed on the MAMP cluster. Kafka consumers deployed on multiple business clusters associated with the bank acquiring application generate unique indexes based on synchronously updated comments and summary results; and generate corresponding comment and summary result update files based on the comments and summary results of the MAMP cluster. Files are transferred from the MAMP file server to a designated file server via peer-to-peer file transfer. Read the comments and summary results from the pre-defined file server to update the file; match the comments and summary results of multiple business clusters associated with the bank acquiring application using a unique index; update the comments and summary results of multiple business clusters associated with the bank acquiring application based on the matching results. The process of generating transaction proposal data based on the identity certificate and the data to be processed using a postscript and summary strategy includes: retrieving the corresponding execution logic in the postscript and summary strategy according to the processing type of the transaction data in the data to be processed; obtaining parameter information based on the execution logic and the data to be processed; and generating transaction proposal data based on the parameter information and the execution logic.

4. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 2.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that enables a computer to execute the method of any one of claims 1 to 2.

Images