Blockchain-based attested letter data processing method and blockchain system

Abstract

The application relates to a blockchain-based method and system for processing inquiry letter data. By setting the request protocol content communicated with the smart contract to include the user account on-chain address and the organization account on-chain address of the organization to which the user belongs, it can be ensured in the account information verification process that the access account of the user matches the identity information written in advance into the blockchain system. By performing the subordination verification between the user and the organization to which the user belongs and the verification of whether the organization has a preset role, the access verification of the relevant personnel with rights and responsibilities in the organization with the preset role is realized, thereby realizing the access verification of the identity authenticity and effectiveness of the user of each request. The architecture is suitable for public chains or alliance chains, and can avoid misoperation, malicious operation and other behaviors of inquiry letter loss of credibility caused by non-rights and responsibilities personnel or non-rights and responsibilities organizations. At the same time, it can also avoid the practical problems of poor mutual recognition of various standard evidence storage conversion.

Description

Technical Field

[0001] This disclosure relates to the fields of finance, blockchain technology, and data processing technology, and in particular to a method and blockchain system for processing confirmation letter data based on blockchain. Background Technology

[0002] In the financial sector, confirmation letters, also known as bank confirmation letters, are written documents issued by auditors (e.g., accountants) of accounting firms to banks in the name of the audited company during the audit process. These documents are used to verify the authenticity, legality, and completeness of the company's bank deposits and loans, investor (shareholder) contributions, guarantees, commitments, letters of credit, and other matters.

[0003] In the typical confirmation process, the accounting firm initiates a confirmation letter (blank or filled out), which is then submitted to the audited company for confirmation and authorization. The letter is then sent to the relevant bank for confirmation and feedback, which is then returned to the accounting firm.

[0004] Currently, there are already some solutions that apply blockchain technology to the processing and storage of confirmation letters. For example, some solutions involve building a blockchain platform that uses accounting firms, audited companies, and banks as ledger nodes on the blockchain, while the blockchain platform is connected to the core institutions of the bank; other solutions involve introducing blockchain technology for the storage of confirmation letters. Summary of the Invention

[0005] During the research and development, the following technical problems were found in the current application of blockchain to the confirmation letter processing: (1) The authenticity and legality of the participants are often not reflected on the chain. Some people may not have the operation authority to perform the corresponding operation, which makes it impossible to perceive the authenticity and legality of users in the confirmation letter data processing process; (2) In the business systems of banking institutions or third parties, the standards for the content items and storage format of the confirmation letter are mostly internal standards of the institution. Therefore, there is a variety of formats, which are difficult to align with the current standard format of the Ministry of Finance.

[0006] To address, or at least partially address, the aforementioned technical problems, embodiments of this disclosure provide a method and blockchain system for processing confirmation letter data based on blockchain.

[0007] In a first aspect, embodiments of this disclosure provide a method for processing confirmation letter data based on blockchain. The method is applied to confirmation processing nodes, where multiple confirmation processing nodes with different processing roles constitute a blockchain system. For each confirmation processing node, the method includes: receiving a user's request to process confirmation letter data, the request carrying the following request information: the user's account on-chain address, the institution's on-chain address, the confirmation letter message content, and confirmation processing content, the confirmation processing content including: a confirmation letter identifier, operation instructions, and an electronic signature; performing smart contract input parameter verification based on the request information; the smart contract input parameter verification includes: verifying whether the user's account on-chain address and the institution's on-chain address are genuine and valid, and whether there is a subordinate relationship between the user and the institution; verifying whether the institution has a preset role for processing the confirmation letter data; verifying whether the confirmation letter message content conforms to a unified standard format; and verifying whether the electronic signature is valid; if the smart contract input parameter verification passes, creating or calling a target smart contract corresponding to the confirmation letter identifier to execute the operation instructions.

[0008] According to embodiments of this disclosure, the method further includes: storing the confirmation processing content and process record information in the target smart contract, and updating the state of the target smart contract; the process record information includes: the digest hash value of the submitted confirmation processing content, the operator's account, the operator's on-chain address, the operator's action, and the operation time.

[0009] According to embodiments of this disclosure, the request information further includes: an encryption / decryption algorithm identifier and an encryption / decryption key index. The method further includes: calling a target encryption / decryption algorithm from an external service or obtaining a target encryption / decryption algorithm from the blockchain system based on the encryption / decryption algorithm identifier; obtaining an encryption / decryption key from the external service or the blockchain system based on the key index; and encrypting the confirmation processing content and process record information to be stored in the target smart contract based on the key and the encryption / decryption algorithm, or decrypting the confirmation processing content and process record information already stored in the target smart contract in ciphertext form.

[0010] According to embodiments of this disclosure, the above-mentioned operation instructions include one or more of the following: initiating a confirmation request instruction, authorizing a confirmation request instruction, responding to a confirmation request instruction, and querying the confirmation status instruction; the above-mentioned confirmation processing content also includes: the hash value of the content of the above-mentioned confirmation letter message; the above-mentioned electronic signature is ciphertext signed with a certificate based on the above-mentioned hash value. When the above-mentioned operation instruction is an initiating confirmation request instruction, the content of the above-mentioned confirmation letter message is a confirmation letter message awaiting authorization; the above-mentioned confirmation processing content also includes: the on-chain address of the auditing party's account, the on-chain address of the audited party's account, and the on-chain address of the financial confirming party's account; the above-mentioned smart contract input parameter verification also includes: verifying whether the on-chain address of the above-mentioned auditing party's account, the on-chain address of the above-mentioned audited party's account, and the on-chain address of the above-mentioned financial confirming party's account are genuine and valid; wherein, verifying whether the above-mentioned user's institution has a preset role for data processing of the above-mentioned confirmation letter includes: verifying whether the on-chain address of the institution's account in the above-mentioned request is consistent with the on-chain address of the above-mentioned auditing party's account. If they are consistent, it is considered that the above-mentioned user's institution has an auditing party role configured, and the auditing party role has the authority to initiate confirmation requests and query the confirmation status.

[0011] According to embodiments of this disclosure, when the above operation instruction is an authorization confirmation instruction, the content of the above confirmation message is the authorized confirmation message; the above smart contract input parameter verification also includes: verifying whether the existing status of the above target smart contract is in the state of initiated confirmation; verifying whether the confirmation message identifier in the above request is consistent with the initiated confirmation message identifier stored in the above target smart contract; verifying whether the auditee account on-chain address stored in the above target smart contract is real and valid; verifying whether the content of the above authorized confirmation message is consistent with the content of the above unauthorized confirmation message stored in the above target smart contract; wherein, verifying whether the above user's organization has a preset role for data processing of the above confirmation message includes: verifying whether the organization account on-chain address in the above request is consistent with the auditee account on-chain address stored in the above target smart contract. If they are consistent, it is considered that the above user's organization has configured an auditee role, and the auditee role has the authority to authorize confirmation and query the confirmation status.

[0012] According to embodiments of this disclosure, when the above operation instruction is a confirmation reply instruction, the content of the above confirmation reply message is the confirmation reply message after the reply; the above smart contract input parameter verification also includes: verifying whether the status of the existing target smart contract is in an authorized confirmation state; verifying whether the confirmation reply identifier in the above request is consistent with the authorized confirmation reply identifier stored in the above target smart contract; verifying whether the on-chain address of the financial confirmer account stored in the above target smart contract is real and valid; verifying whether the content of the above confirmation reply message in response to the above authorized confirmation reply message stored in the above target smart contract meets the preset requirements; wherein, verifying whether the user's institution has a preset role for data processing of the above confirmation reply includes: verifying whether the on-chain address of the institution account in the above request is consistent with the on-chain address of the financial confirmer account stored in the above target smart contract. If they are consistent, it is considered that the user's institution has a financial confirmer role configured, and the financial confirmer role has the authority to reply to confirmation requests and query the confirmation status.

[0013] According to embodiments of this disclosure, the ledger of the blockchain system stores registered user information. For each registered user, the registered user information includes: user account information, trusted electronic signature, user account on-chain address, and the association identifier of the user's affiliated institution. The trusted electronic signature is encrypted text signed by calling a certificate issued by a credible certificate authentication server during user registration. The user account information and the corresponding trusted electronic signature of the registered user are bound and stored in the ledger of the blockchain system, corresponding to a unique user account on-chain address.

[0014] According to embodiments of this disclosure, registered institutions are configured with preset roles for processing data related to the aforementioned confirmation letters; the method further includes: if the smart contract input parameter verification passes, determining the user's operating permissions based on the preset role of the user's institution; determining whether the operating instruction is within the aforementioned operating permissions; if the operating instruction is within the aforementioned operating permissions, creating a target smart contract corresponding to the aforementioned confirmation letter identifier or calling an existing target smart contract to execute the aforementioned operating instruction.

[0015] According to embodiments of this disclosure, verifying whether the aforementioned user account blockchain address and the blockchain address of the institution to which the user belongs are authentic and valid, and whether there is a subordinate relationship between the user and the institution to which the user belongs, includes: querying whether the aforementioned user account blockchain address and the blockchain address of the institution to which the user belongs exist and are valid based on the aforementioned registered user information; if the user account blockchain address and the blockchain address of the institution to which the user belongs exist and are valid, determining whether there is a subordinate relationship between the user and the institution to which the user belongs based on the aforementioned association identifier; verifying whether the aforementioned electronic signature is legal includes: calling the certificate verification service of the certificate authentication server to verify whether the aforementioned electronic signature is legal.

[0016] According to embodiments of this disclosure, the method further includes: receiving a user's registration request, the registration request carrying the following information: registration information, user identity information, and user's affiliated organization information; verifying whether the user identity information is authentic; verifying whether the user's affiliated organization information is authentic and whether it has been registered in the blockchain system; if the user identity information is authentic and the user's affiliated organization information is authentic and registered, verifying whether a subordinate relationship between the user and the user's affiliated organization is established based on the user identity information and the user's affiliated organization information; if the subordinate relationship is established, generating user account information for the user based on the registration information, and generating an association identifier for the user account information belonging to the user's affiliated organization information; calling a certificate issued by a credible certificate authority to generate a trusted electronic signature bound to the user account information; and storing the user account information and the corresponding bound trusted electronic signature in the ledger of the blockchain system to generate a unique user account on-chain address.

[0017] According to embodiments of this disclosure, the aforementioned user's affiliated organization information includes: the organization identifier and the on-chain address of the organization's account; verifying whether the aforementioned user's affiliated organization has registered in the aforementioned blockchain system includes: querying the ledger of the aforementioned blockchain system to see if the aforementioned organization's account on-chain address exists; if the aforementioned organization's account on-chain address exists, determining whether the aforementioned organization identifier matches the information stored in the aforementioned organization's account on-chain address; if the match is successful, it is considered that the aforementioned user's affiliated organization has registered in the aforementioned blockchain system.

[0018] Secondly, embodiments of this disclosure provide a blockchain system. The blockchain system includes a confirmation processing node. The processing roles of the confirmation processing node include at least one of the following: auditor role, auditee role, and financial confirmer role. The confirmation processing node includes a request receiving module, a parameter verification module, and a processing module. The request receiving module is used to receive requests from users to process confirmation letters. The requests carry the following request information: the user's on-chain address, the on-chain address of the user's affiliated institution, the confirmation letter message content, and the confirmation processing content. The confirmation processing content includes: a confirmation letter identifier, an operation instruction, and an electronic signature. The parameter verification module is used to perform smart contract input parameter verification based on the request information. The smart contract input parameter verification includes: verifying whether the user's on-chain address and the affiliated institution's on-chain address are genuine and valid, and whether there is a subordinate relationship between the user and the affiliated institution; verifying whether the affiliated institution has a preset role for processing the confirmation letter; verifying whether the confirmation letter message content conforms to a unified standard format; and verifying whether the electronic signature is legal. The aforementioned processing module is used to create or call the target smart contract corresponding to the aforementioned confirmation letter identifier to execute the aforementioned operation instructions, provided that the input parameters of the aforementioned smart contract have passed the verification.

[0019] Thirdly, embodiments of this disclosure provide an electronic device. The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, communication interface, and memory communicate with each other via the communication bus; the memory stores computer programs; and the processor, when executing the program stored in the memory, implements the blockchain-based confirmation letter data processing method described above.

[0020] Fourthly, embodiments of this disclosure provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the blockchain-based confirmation letter data processing method described above.

[0021] The technical solutions provided by some embodiments of this disclosure have at least some or all of the following advantages:

[0022] By setting the request protocol for communication with smart contracts to include the on-chain address of the user's account and the on-chain address of the institution to which the user belongs, the system can ensure that the user's access account matches the identity information pre-written into the blockchain system during the account information verification process. By performing attribute verification between the user and their institution and verifying whether the institution has a preset role, the system enables access verification for relevant personnel with authority and responsibility within institutions with preset roles. This achieves access verification of the authenticity and validity (excluding cancellation, freezing, and other valid states) of the user's identity for each request. This architecture is adaptable to public or consortium blockchains and can avoid unauthorized or malicious operations by unauthorized personnel or institutions leading to breaches of trust in confirmation requests. Furthermore, by verifying whether the content of the confirmation message conforms to a unified standard format, the system can ensure that the content of the confirmation message for smart contract notarization conforms to the national unified standard format, avoiding the practical problems of poor conversion or mutual recognition between different internal standards of notarization, thus possessing scalability and universality in various scenarios. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0024] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0025] Figure 1A The system architecture of a blockchain-based confirmation letter data processing method applicable to embodiments of this disclosure is illustrated schematically;

[0026] Figure 1B The illustration schematically depicts an execution scenario of a blockchain-based method for processing confirmation letter data applicable to embodiments of this disclosure.

[0027] Figure 2 A flowchart illustrating a method for processing blockchain-based confirmation letter data according to an embodiment of the present disclosure is shown schematically.

[0028] Figure 3 A flowchart illustrating a method for processing blockchain-based confirmation letter data according to another embodiment of this disclosure is shown schematically.

[0029] Figure 4 A flowchart illustrating a method for processing blockchain-based confirmation letter data according to yet another embodiment of this disclosure is shown.

[0030] Figure 5 A flowchart illustrating the implementation of encryption and decryption processing of stored information in a blockchain system according to an embodiment of the present disclosure is shown.

[0031] Figure 6 An example of the request data protocol content for communicating with a smart contract according to an embodiment of this disclosure is illustrated schematically;

[0032] Figure 7 An example of data content stored in a smart contract according to an embodiment of this disclosure is illustrated schematically;

[0033] Figure 8A The illustration schematically shows an implementation flow diagram of a method for processing blockchain-based confirmation letter data according to an embodiment of the present disclosure, which processes a confirmation request.

[0034] Figure 8B The illustration schematically shows an implementation flow diagram of a blockchain-based confirmation letter data processing method for processing authorization confirmation requests according to an embodiment of the present disclosure;

[0035] Figure 8C The illustration schematically shows an implementation flow diagram of a blockchain-based method for processing confirmation request data according to an embodiment of the present disclosure;

[0036] Figure 9 A schematic block diagram of a blockchain system according to embodiments of the present disclosure is shown; and

[0037] Figure 10 A schematic block diagram of an electronic device provided in an embodiment of the present disclosure is shown. Detailed Implementation

[0038] During the research and development, it was found that although the security of the evidence storage process can be achieved by introducing blockchain technology and leveraging its decentralized and tamper-proof characteristics, the current solutions still have the following technical problems: (1) The authenticity and legitimacy of the participants are often not reflected on the chain. Some personnel may not have the necessary operating permissions to perform corresponding operations, resulting in the inability to perceive the authenticity and legitimacy of users in the data processing stage of the confirmation letter; (2) In the business systems of banking institutions or third parties, the standards for the content items and storage formats of the confirmation letter are mostly internal standards of the institutions, resulting in diverse formats that are difficult to align with the current standard formats of the Ministry of Finance. In addition, it was found that in some solutions, due to the lack of credibility of some third-party self-made software and hardware certificates, the encryption methods are non-compliant, making it difficult to confirm whether the content uploaded to the chain is authentic and compliant.

[0039] Describing the use of smart contracts directly without a contextual basis makes it impossible to clearly understand how the entire system operates, and the use of contract functions is very likely to be a false proposition.

[0040] In view of this, embodiments of this disclosure provide a method and blockchain system for processing confirmation letter data based on blockchain. This system enables access verification of the authenticity and validity (non-cancellation, non-freezing, and other valid states) of the user's identity for each request. This architecture is adaptable to public or consortium blockchains and can avoid confirmation letter breaches caused by misoperation or malicious operation by unauthorized personnel or institutions. At the same time, by verifying whether the content of the confirmation letter message conforms to a unified standard format, it can ensure that the content of the confirmation letter message stored in the smart contract conforms to the national unified standard format, thus avoiding the practical problems of poor mutual conversion or recognition between various internal standards of evidence storage. This system has scalability and universality in various scenarios.

[0041] The embodiments of this disclosure clarify the characteristics of the underlying system architecture, laying the environmental foundation for the use of the solutions provided in this disclosure, thus greatly enhancing the practicality and reliability of the solutions provided in this disclosure. While existing solutions introduce blockchain technology, they merely describe how contracts operate without specifying or clearly defining input parameters, making it difficult for the system to be used quickly or correctly in actual use. The data format of the communication protocol provided in the embodiments of this disclosure enhances the openness and convenience of the solutions provided in this disclosure. Furthermore, considering that the authenticity and legitimacy of the participants are often not reflected on the blockchain, the embodiments of this disclosure indirectly address this by relying on the system that calls the blockchain before data is uploaded to the chain, clearly defining the roles of each participant and verifying the data signature of the requester, thus ensuring the legitimacy and authenticity of the data and the data registrant. In addition, by dynamically loading encryption and decryption programs, new data records can use higher-strength encryption algorithms without upgrading the blockchain, ensuring data storage privacy and improving the flexibility of encryption methods. Furthermore, in the embodiments of this disclosure, by adding process records to the data storage, the supervisory and review agency can quickly and accurately obtain the following information: who (operator), when, what action was performed, what the content is, etc.; this provides great convenience for traceability, and due to the decentralized and tamper-proof nature of blockchain, the difficulty of forgery is greatly increased.

[0042] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0043] Figure 1A The system architecture of a blockchain-based confirmation letter data processing method applicable to embodiments of this disclosure is illustrated schematically; Figure 1B The illustration schematically depicts an execution scenario of a blockchain-based confirmation letter data processing method applicable to embodiments of this disclosure.

[0044] Reference Figure 1A As shown, the system architecture 100 of the blockchain-based confirmation letter data processing method applicable to the embodiments of this disclosure includes: confirmation processing node 110, the confirmation processing node 110 having different processing roles, including but not limited to: role B: auditor role; role C: auditee role 103; role D: financial confirmer role 104.

[0045] In some embodiments, the confirmation processing node 110 may be a terminal device (or a client) or a server providing service support to the terminal device. The terminal device is equipped with a confirmation data processing application, which may include the visual network system 111 illustrated in FIG1. ​​Referring to FIG1, the confirmation processing node 110 includes a visual network (web) system (or a data processing application) 111, a database 112, and a blockchain node 113. The visual network system 111 serves as the data processing application of the confirmation processing node 110, and can execute the confirmation processing logic by calling a software development kit (SDK).

[0046] The confirmation processing node 110 is pre-registered in the blockchain system (or described as a blockchain network) as a blockchain node, enabling the visualization network system 111 to call the corresponding business smart contract (e.g., a smart contract for processing confirmation data) during the confirmation data processing process. Figure 1 illustrates this by showing the visualization network system 111 (confirmation processing node 110) calling the smart contract of blockchain node 113 to perform verification, consensus, or ledger operations. The data from the confirmation processing node 110 can be stored locally or in the cloud via database 112, or stored after multi-party consensus based on the ledger of blockchain node 113.

[0047] In the application scenario disclosed herein, based on the aforementioned confirmation processing node 110 including the visual network system 111, the confirmation processing node also has a role A: a platform provider or a regulator. The platform provider is the builder of the aforementioned visual network system, and the regulator is the manager with supervisory responsibilities for the aforementioned confirmation process. The aforementioned regulator and the aforementioned platform provider can be the same party, or they can be two independent institutions. Here, the platform provider or regulator is abbreviated as platform / regulator, and " / " indicates the meaning of "or".

[0048] Reference Figure 1A As shown, the platform party in Role A can initiate operation requests such as system setup and system maintenance to the confirmation processing node 110 through the visual network system 111, and the regulator party in Role A can initiate operation requests to retrieve regulatory data to the confirmation processing node 110 through the visual network system 111.

[0049] In application scenarios involving confirmation processing, refer to... Figure 1A and Figure 1B As shown, the aforementioned role B can initiate a confirmation request to the aforementioned confirmation processing node 110 through the visual network system 111. The aforementioned confirmation processing node 100 executes the blockchain-based confirmation data processing method provided in this embodiment of the disclosure to create a target smart contract to perform the confirmation initiation operation. It can also store confirmation processing content and process record information in the target smart contract and update the state of the aforementioned target smart contract.

[0050] The aforementioned role C can initiate an authorization request to the aforementioned confirmation processing node 110 through the visual network system 111. The aforementioned confirmation processing node 100 executes the blockchain-based confirmation data processing method provided in this embodiment of the disclosure, calls an existing target smart contract to perform the authorization request operation, and updates the corresponding contract state.

[0051] The aforementioned role D can initiate a confirmation request to the aforementioned confirmation processing node 110 through the visual network system 111. The aforementioned confirmation processing node 100 executes the blockchain-based confirmation data processing method provided in this embodiment of the disclosure, calls the existing target smart contract to perform the confirmation operation, and updates the corresponding contract status.

[0052] In the above system architecture, role A is the operator or data supervisor of confirmation processing node 110, and roles B to D are the users of the above confirmation processing node 110. Corresponding to different user roles, the above confirmation processing node executes the corresponding data processing logic when responding to the requests of each user.

[0053] In order to facilitate the implementation of the solution technology, the embodiments of this disclosure list that the above-mentioned visualization network system 111 and the above-mentioned confirmation processing node 110 need to meet one or more of the following characteristics (1) to (12).

[0054] Feature (1) The visualization network system 111 can be deployed in multiple nodes, across data centers and regions, and the various confirmation processing nodes 110 with the visualization network system 111 deployed can communicate with each other and synchronize data.

[0055] Feature (2): The confirmation processing node 110 used by each role is connected to the same public chain or consortium chain.

[0056] Feature (3): The blockchain accessed by the confirmation processing node 110 used by each role is not limited by language or framework type, only need to support the use of smart contract related functions.

[0057] Feature (4): The confirmation processing node 110 used by each role is connected to the same key management service (KMS) 130.

[0058] Feature (5): The confirmation processing node 110 used by each role is connected to the same object storage service (OSS) 140.

[0059] Feature (6) The visual network system 111 of the confirmation processing node 110 is able to communicate with the credible Certificate Authority (CA) service 120.

[0060] Feature (7) The visual network system 111 of the confirmation processing node 110 used by each role is connected to the third-party notification service 150. When the business process changes, it can ensure that the information is delivered to the client of the confirmation processing node of the visual network system 111 corresponding to the current role that caused the change operation or the client of the confirmation processing node 110 corresponding to the other role in a timely and effective manner.

[0061] Feature (8) is that each of the confirmation processing nodes 110 used by each role has the ability to periodically poll the status of a specified contract on the blockchain as compensation for poor communication between the visual network systems 111, and can provide feedback to the visual network system 111 when the confirmation changes.

[0062] Feature (9) When registering, users of the visual network system 111 must generate their account information on the chain and attach ciphertext signed with a certificate issued by a credible CA authority (i.e., the trusted electronic signature described later).

[0063] Feature (10): When a user of the visual network system 111 registers, they will be identified with the information of their affiliated organization, including the identification of the affiliated organization (e.g., the organization name) and the on-chain address of the organization account of the user's affiliated organization on the blockchain. They have no right to modify this information. Only when using an enterprise organization account can they modify the relevant information of their subordinate users.

[0064] Feature (11): When users of the visual network system 111 submit operations such as sending letters, authorizing, and replying, the content or actions submitted must be electronically signed using a certificate issued by a credible CA institution.

[0065] Feature (12), the visualized network system 111 itself or an authoritative third-party institution should provide a service that responds to blockchain oracle callbacks, which supports three business interfaces:

[0066] (a) Receive the encryption / decryption key index used by the parameters and return the corresponding key in KMS;

[0067] (b) Receive the encryption / decryption algorithm identifier of the parameter, and return the corresponding encryption / decryption algorithm code for dynamic loading by the contract for encryption / decryption.

[0068] (c) Receive the data digest hash value and signature data, and return the signature verification result.

[0069] The meanings of the terms used in the embodiments of this disclosure are described below.

[0070] Public blockchain: A blockchain that is public or publicly accessible, with access and writing permissions open to everyone.

[0071] Consortium blockchain: This refers to a blockchain formed by a consortium of organizations, where access and writing permissions are only granted to nodes that have joined the consortium.

[0072] Smart contracts are the core component of blockchain (contract layer). They are event-driven, stateful computer programs that run on a replicable, shared blockchain ledger. They can actively or passively process data, receive, store, and send value, and control and manage various on-chain smart assets.

[0073] Oracles are mechanisms for writing external information into the blockchain, enabling data exchange between the blockchain and the real world. They allow established smart contracts to respond to uncertain external circumstances and are the only way for contracts to exchange data with the outside world; they are the interface between the blockchain and the real world.

[0074] Electronic signature: refers to data contained or attached in electronic form in a data message to identify the signatory and indicate the signatory's approval of the content. In simpler terms, an electronic signature is a digital signature of an electronic document using cryptographic technology; it is not a digital representation of a written signature.

[0075] Hash algorithm (Hash): also known as digest algorithm (Digest), its function is to calculate a fixed-length output digest for any set of input data.

[0076] Extensible Business Reporting Language (XBRL) is an internet-based, cross-platform computer language specifically designed for the preparation, disclosure, and use of financial reports. It is an internationally recognized standard and technology that combines accounting standards with computer language for exchanging unstructured data, particularly financial information. By uniformly identifying and classifying data, it can be directly read and further processed by users or other software, enabling "entry once, use multiple times."

[0077] The first exemplary embodiment of this disclosure provides a method for processing confirmation letter data based on blockchain. The method provided in this embodiment can be applied to... Figure 1A The system architecture 100 consists of confirmation processing nodes, and the aforementioned confirmation processing nodes with different processing roles constitute the blockchain system.

[0078] Figure 2 A flowchart illustrating a method for processing blockchain-based confirmation letter data according to an embodiment of this disclosure is shown schematically.

[0079] Reference Figure 2 As shown, for confirmation processing nodes with various processing roles, the method for processing confirmation letter data based on blockchain provided in this embodiment includes the following steps: S210, S220 and S230.

[0080] In step S210, a user's request to process the confirmation letter is received. The request carries the following request information: the user's account on-chain address (hereinafter referred to as the user account address), the on-chain address of the user's organization's account (hereinafter referred to as the organization account address), the confirmation letter message content, and the confirmation processing content. The confirmation processing content includes: confirmation letter identifier, operation instructions, and electronic signature.

[0081] In the following description, for the sake of simplicity, the on-chain address of the account obtained by pre-registering with the blockchain system will be referred to as the account address.

[0082] The above requests include one or more of the following: initiating a confirmation request, authorizing a confirmation request, responding to a confirmation request, and querying the status of a confirmation request.

[0083] Accordingly, the above operation instructions include one or more of the following: initiating a confirmation request instruction, authorizing a confirmation request instruction, responding to a confirmation request instruction, and querying the confirmation status instruction.

[0084] In the scenario of initiating a confirmation request, the user uploads the confirmation message content conforming to the unified standard format to an electronic device with confirmation processing application software installed (the electronic device corresponding to the confirmation processing node is an example of a terminal device); or, the user uploads the confirmation message content conforming to the unified standard format to an electronic device that provides services for the confirmation processing application software (the electronic device corresponding to the confirmation processing node is an example of a server), and the aforementioned electronic device executes step S210.

[0085] In the scenario of an authorized confirmation request, the user uploads the authorized confirmation message content to an electronic device with confirmation processing application software installed (the electronic device corresponding to the confirmation processing node is an example of a terminal device); or, the user uploads the authorized confirmation message content to an electronic device that provides services for the confirmation processing application software (the electronic device corresponding to the confirmation processing node is an example of a server), and the aforementioned electronic device executes step S210.

[0086] In the scenario of replying to a confirmation request, the user uploads the content of the confirmation message after replying to the electronic device that has the confirmation processing application software installed (the electronic device corresponding to the confirmation processing node is an example of a terminal device); or, the user uploads the content of the confirmation message after replying to the electronic device that provides services for the confirmation processing application software (the electronic device corresponding to the confirmation processing node is an example of a server), and the electronic device executes step S210.

[0087] In one embodiment, the aforementioned electronic signature is an electronic signature of the digest hash value of the content of the aforementioned confirmation message. In implementation scenarios, the electronic signature can be a user signature or an institutional signature; a user may have a unique personal signature, or all users within an institution may share a single institutional signature.

[0088] In step S220, based on the above request information, the smart contract input parameter verification is performed; the smart contract input parameter verification includes: verifying whether the above user account on-chain address and the above organization account on-chain address are genuine and valid and whether there is a subordinate relationship between the above user and the organization to which the user belongs; verifying whether the above user's organization has a preset role for processing the above confirmation letter; verifying whether the content of the above confirmation letter message conforms to a unified standard format; and verifying whether the above electronic signature is legal.

[0089] In system architectures based on public or consortium blockchains, in the aforementioned scenarios, access verification is required to confirm the authenticity and validity of the user's identity initiating the request. Users pre-registered in the blockchain system possess both their on-chain account address and the on-chain address of their affiliated organization. By setting the request protocol for communication with the smart contract to include both the user's on-chain account address and the on-chain address of their affiliated organization, it can be ensured during account information verification that the user's access account matches the identity information (including the user's on-chain account address and the on-chain address of their affiliated organization) pre-written into the blockchain system.

[0090] For example, according to some embodiments of this disclosure, the ledger of the aforementioned blockchain system stores registered user information. For each registered user, the registered user information includes: user account information, a trusted electronic signature, the user account's on-chain address, and an association identifier of the user's affiliated institution; the trusted electronic signature is encrypted text signed by calling a certificate issued by a credible CA server during user registration; the registered user's user account information and the corresponding trusted electronic signature are bound and stored in the ledger of the aforementioned blockchain system, corresponding to a unique user account on-chain address.

[0091] According to embodiments of this disclosure, verifying whether the aforementioned user account blockchain address and the blockchain address of the institution to which the user belongs are authentic and valid, and whether there is a subordinate relationship between the user and the institution to which the user belongs, includes: querying whether the aforementioned user account blockchain address and the blockchain address of the institution to which the user belongs exist and are valid based on the aforementioned registered user information; if the user account blockchain address and the blockchain address of the institution to which the user belongs exist and are valid, determining whether there is a subordinate relationship between the user and the institution to which the user belongs based on the aforementioned association identifier.

[0092] Verifying the validity of the aforementioned electronic signature includes: calling the certificate verification service of the certificate authentication server to verify the validity of the electronic signature. For example, refer to... Figure 1A As shown in the system architecture 100, the validity of the electronic signature in the request can be verified by calling the CA institution service 120.

[0093] The aforementioned valid status refers to a state that is not cancelled or frozen.

[0094] By performing attribute verification between the user and the user's affiliated institution, and verifying whether the user's affiliated institution has a preset role, the system achieves access verification for relevant personnel with authority and responsibility within institutions with preset roles. This enables access verification of the authenticity and validity of the user's identity (excluding cancellation, freezing, and other valid states) for each request. This architecture is adaptable to public or consortium blockchains and can avoid untrustworthy confirmation behavior caused by misoperation or malicious operation by unauthorized personnel or institutions. At the same time, by verifying whether the content of the confirmation message conforms to a unified standard format, it can ensure that the content of the confirmation message for smart contract notarization conforms to the national unified standard format, thus avoiding the practical problems of poor conversion or mutual recognition between notarization standards of various institutions. It has scalability and universality in various scenarios.

[0095] The aforementioned unified standard format is used to define the content items and data storage format under the unified standard. The aforementioned unified standard format is the content items and data storage format that conforms to the current national Ministry of Finance standards, such as the confirmation letter message format using XBRL.

[0096] In one embodiment, each registered user has a trusted electronic signature in the blockchain system's ledger. This trusted electronic signature is encrypted text that is signed by calling a certificate issued by a reputable CA server during user registration. By verifying the electronic signature when a user initiates a request, a dual guarantee of authentic identity is achieved by combining off-chain verification of identity authenticity with on-chain verification of account address authenticity.

[0097] In step S230, if the smart contract input parameter verification passes, a target smart contract corresponding to the confirmation letter identifier is created or invoked to execute the above operation instructions.

[0098] Each target smart contract corresponds one-to-one with a confirmation request identifier. For example, when initiating a confirmation request, a target smart contract C1 is created in the blockchain ledger for confirmation request identifier ID1. Subsequently, when the confirmation processing node receives an authorization confirmation request for confirmation request identifier ID1, the created target smart contract C1 is invoked in step S230 to execute the authorization confirmation instruction. When the confirmation processing node receives a reply confirmation request for confirmation request identifier ID1, the target smart contract C1 after the authorization confirmation is executed is invoked in step S230 to execute the authorization confirmation instruction. The state of the target smart contract corresponding to the confirmation request identifier is continuous and updated synchronously at each stage of the confirmation process.

[0099] Based on steps S210-S230 above, by setting the request protocol content for communication with the smart contract to include the on-chain address of the user's account and the on-chain address of the institution to which the user belongs, it is possible to ensure that the user's access account matches the identity information pre-written into the blockchain system during the account information verification process. By performing attribute verification between the user and the institution to which the user belongs, and verification of whether the institution to which the user belongs has a preset role, access verification is achieved for relevant personnel with authority and responsibility in institutions with preset roles. This enables access verification of the authenticity and validity (non-cancellation, non-freezing, and other valid states) of the user's identity for each request. This architecture is adaptable to public or consortium blockchains and can avoid untrustworthy confirmation behavior caused by misoperation or malicious operation by unauthorized personnel or institutions. At the same time, by verifying whether the content of the confirmation message conforms to a unified standard format, it is possible to ensure that the content of the confirmation message for smart contract notarization conforms to the national unified standard format, thus avoiding the practical problems of poor mutual conversion or recognition between different internal standards of notarization, and has scalability and universality in various scenarios.

[0100] Figure 3 A flowchart illustrating a method for processing blockchain-based confirmation letter data according to another embodiment of this disclosure is shown schematically.

[0101] According to some embodiments of this disclosure, refer to Figure 3 As shown, the method for processing confirmation letter data based on blockchain includes not only the above steps S210 to S230, but also step S310: storing the above confirmation processing content and process record information in the above target smart contract, and updating the state of the above target smart contract.

[0102] The information recorded in the above process includes: the digest hash value of the submitted confirmation processing content, the operator's account, the operator's on-chain address, the operator's action, and the operation time.

[0103] By storing the aforementioned request information and process record information in the target smart contract and updating the state of the target smart contract, on the one hand, storing process record information facilitates supervisory and review agencies to quickly and accurately obtain relevant operational details, greatly improving the convenience of tracing responsibilities. Furthermore, due to the decentralized and tamper-proof nature of blockchain, based on the aforementioned user identity verification, the automatic processing and execution of the smart contract and the storage of corresponding operational processes in the blockchain ledger ensure the authenticity and reliability of the process record information, raising the threshold for data falsification. On the other hand, by storing request information and process record information in the smart contract, changes in the state of the target smart contract are reflected in the data. The smart contract updates itself during operation and is synchronized across all nodes of the blockchain system. This allows for adaptive responses to requests at different processing stages of the confirmation letter. For example, for a request in the authorization confirmation stage, the existing smart contract will only be invoked to execute the corresponding authorization confirmation operation if the process record information in the target smart contract shows that the confirmation letter was successfully submitted (or the target smart contract's status is "confirmation initiated"), and after the relevant smart contract input parameters have been verified. This enables the execution of confirmation letter data processing operations at each stage according to the smart contract's preset legal process, achieving sequential and legal execution of each stage of confirmation letter data processing.

[0104] Figure 4 A flowchart illustrating a method for processing blockchain-based confirmation letter data according to yet another embodiment of this disclosure is shown.

[0105] According to embodiments of this disclosure, registered institutions are configured with preset roles for processing the aforementioned confirmation letters; the blockchain-based confirmation letter data processing method, in addition to including the aforementioned steps S210-S230, or including the aforementioned steps S210-S230 and S310, also includes the following steps: S410 and S420. For simplification, in... Figure 4 Only steps S410 to S420 and step S230 are illustrated. Step S410 is executed after step S220. In this embodiment, step S230 includes step S230a, which is executed if the execution result of step S420 is "yes".

[0106] In step S410, if the smart contract input parameter verification passes, the user's operation permissions are determined according to the preset role of the organization to which the user belongs.

[0107] In step S420, it is determined whether the above operation instruction is within the above operation permissions.

[0108] In step S230a, if the above operation instruction is within the above operation permissions, a target smart contract corresponding to the above confirmation letter identifier is created or an existing target smart contract is invoked to execute the above operation instruction.

[0109] When the execution result of step S420 is "No", the feedback request response fails.

[0110] By pre-assigning corresponding role permissions to the user's organization in the blockchain system, it is helpful to clarify whether each user has access to the corresponding smart contract in the blockchain system during the data processing process, and whether the operation permissions are appropriate for the corresponding role if they have access permissions.

[0111] In some embodiments, including the above-described step S310, since the confirmation processing content and process record information do not involve the content of confirmation letter messages containing the private data of each audited enterprise or bank, the confirmation processing content and process record information can be stored directly without encryption.

[0112] In other embodiments, since the process record information involves on-chain address information, for the purpose of enhancing security, the confirmation processing content and process record information can be encrypted before being stored on the blockchain, and then decrypted and verified for information matching when responding in the future.

[0113] According to embodiments of this disclosure, the requested information further includes: an encryption / decryption algorithm identifier and an encryption / decryption key index. The method further includes: encrypting information to be stored in the blockchain system or decrypting already stored information.

[0114] Figure 5 A flowchart illustrating the implementation of encryption and decryption processing of stored information in a blockchain system according to an embodiment of the present disclosure is shown.

[0115] Reference Figure 5 As shown, the encryption of information to be stored or the decryption of information already stored in the blockchain system includes the following steps: S510, S520 and S530.

[0116] In step S510, based on the encryption / decryption algorithm identifier, the target encryption / decryption algorithm is invoked from an external service or obtained from the blockchain system.

[0117] For example, the target encryption / decryption algorithm can be obtained by calling external services based on an oracle.

[0118] In step S520, the encryption / decryption key is obtained from the external service or the blockchain system according to the key index.

[0119] For example, after the target encryption / decryption algorithm is loaded, the encryption / decryption key can be obtained by calling an external service based on an oracle.

[0120] In step S530, based on the aforementioned key and the aforementioned encryption / decryption algorithm, the aforementioned confirmation processing content and the aforementioned process record information to be stored in the aforementioned target smart contract are encrypted, or the aforementioned confirmation processing content and the aforementioned process record information already stored in the aforementioned target smart contract in ciphertext form are decrypted.

[0121] Based on the above steps S510 to S530, when encrypting and decrypting information stored on the blockchain, some embodiments use the encryption and decryption functions provided by the blockchain system itself to encrypt and decrypt the content of the verification process and the process record information. This process relies on the algorithms supported by the blockchain system itself. In other embodiments, encryption and decryption algorithms and corresponding keys are dynamically loaded by calling external services. This allows for the use of stronger encryption algorithms without upgrading the blockchain, effectively protecting the privacy of data storage and improving the flexibility of encryption methods.

[0122] In the above embodiments, the operation instructions include one or more of the following: initiating a confirmation request instruction, authorizing a confirmation request instruction, responding to a confirmation request instruction, and querying the confirmation status instruction.

[0123] Figure 6 An example of the request data protocol content for communication with a smart contract according to an embodiment of this disclosure is illustrated schematically.

[0124] Reference Figure 6 As shown, in one embodiment, the protocol content for requesting data to communicate with the smart contract is specified. The content format in this embodiment is only an example. In other embodiments, as long as the corresponding data content is carried, the order and position of the content are not limited.

[0125] In this embodiment, the request information includes two parts: header information and content information. Taking an embodiment that requires encryption and decryption of stored information in a smart contract as an example, the header information includes: protocol type, protocol version, confirmation letter identifier, encryption / decryption algorithm identifier, encryption / decryption key index used, operation instruction, initiating organization account address (which may correspond to the on-chain address of the organization account of the user's organization described above), operator account address (which may correspond to the on-chain address of the user account described above), and digest hash value of the submitted content.

[0126] In embodiments where encryption and decryption of stored information in smart contracts are not required, the header information may not include the encryption / decryption algorithm identifier and the index of the encryption / decryption key used.

[0127] The content information varies depending on the different stages of the confirmation process.

[0128] For initiating a confirmation request, the content information includes: the on-chain address of the auditor's account, the on-chain address of the audited party's account, the on-chain address of the financial confirmer's account, the confirmation letter XBRL format message (corresponding to the confirmation letter message content described above), and an electronic signature of the hash value of the confirmation letter message content digest. For simplicity, in... Figure 6 The simplified diagrams represent the auditor's account address, the auditee's account address, and the financial confirmer's account address, respectively.

[0129] For authorization confirmation requests, the content information includes: an authorization confirmation letter in XBRL format and an electronic signature of the authorization confirmation letter in XBRL format.

[0130] For a confirmation reply request, the content information includes: the confirmation reply in XBRL format (also known as the reply XBRL format message) and the electronic signature of the hash value of the reply XBRL format message digest.

[0131] Figure 7 An example of data content stored in a smart contract according to an embodiment of this disclosure is illustrated.

[0132] In the embodiment that includes step S310, the above-mentioned confirmation processing content and process record information are stored in the target smart contract, and the state of the target smart contract is updated.

[0133] In some embodiments, refer to Figure 6 and Figure 7 As shown, the confirmation processing content in the aforementioned request information includes, in addition to: the confirmation letter identifier, operation instructions, and electronic signature, the hash value of the aforementioned confirmation letter message content, and the aforementioned electronic signature is ciphertext signed with a certificate based on the aforementioned hash value. The aforementioned confirmation processing content will be stored in the target smart contract.

[0134] The contract format for storing confirmation processing content and process record information includes: basic information, body text, and process record information.

[0135] Basic information includes: protocol type, protocol version, encryption / decryption algorithm identifier, encryption / decryption key index used, start time, completion time, and business status.

[0136] The main body includes: contract information, initiation content, and reply content.

[0137] The contract information includes: confirmation letter identifier, auditor account address, auditee (e.g., audited company) account address, and financial confirmer (e.g., bank or trusted third-party institution) account address. This contract information can be stored by executing step S310 during the processing of the evidence storage request.

[0138] The content to be initiated includes: the digest hash value of the confirmation message content in XBRL format, the electronic signature of the auditor on the digest hash value of the confirmation message content (the confirmation message content here corresponds to the unauthorized confirmation message described later), and the electronic signature of the auditee on the digest hash value of the confirmation message content (the authorized confirmation message here).

[0139] During the processing of initiating a confirmation request, the digest hash value of the confirmation message content in XBRL format (actually: confirmation message to be authorized) and the electronic signature of the auditor on the digest hash value of the confirmation message content (the confirmation message content here corresponds to the confirmation message to be authorized described later) are stored by executing step S310. The confirmation message content here is the confirmation message to be authorized.

[0140] During the processing of the authorization confirmation request, the digest hash value of the confirmation message content in XBRL format (actually the authorized confirmation message content) and the electronic signature of the auditee on the digest hash value of the confirmation message content (the confirmation message content here corresponds to the authorized confirmation message content described later) are stored by executing step S310. Here, the confirmation message content is the authorized confirmation message content.

[0141] The response includes: a digest hash value of the response message in XBRL format, and the electronic signature of the financial confirmer on the digest hash value of the response message. The response message described here is referred to as the confirmation message content in the aforementioned step S110. During the processing of the response confirmation request, the aforementioned confirmation message content includes the confirmation message following the response.

[0142] While existing solutions incorporate blockchain technology, they merely describe how contracts operate without specifying or clearly defining input parameters, hindering the system's ability to function quickly or correctly in practice. This disclosure enhances the openness and convenience of the solution by providing the data content of the aforementioned communication protocol and offering an exemplary format. Based on the description of the content parameters carried in the request, the execution process of smart contract input parameter verification becomes clearer.

[0143] Figure 8AThe illustration schematically shows an implementation flow diagram of a blockchain-based method for processing confirmation request data according to an embodiment of the present disclosure.

[0144] Reference Figure 8A As shown, the method for processing confirmation request data based on blockchain includes steps S811 to S814.

[0145] In step S811, a confirmation request from the user in response to the confirmation letter is received. This request carries the following information: the user's account on-chain address, the on-chain address of the user's affiliated institution's account, the confirmation letter message content, and the confirmation processing content. The confirmation processing content includes: a confirmation letter identifier, an operation instruction, the hash value of the confirmation letter message content, an electronic signature, the auditor's account on-chain address, the audited party's account on-chain address, and the financial confirmer's account on-chain address. The electronic signature is a ciphertext certificate-signed version of the hash value.

[0146] According to an embodiment of this disclosure, when the above operation instruction is an initiation confirmation instruction, the content of the above confirmation message is a confirmation message to be authorized.

[0147] In step S812, the smart contract input parameter verification is performed based on the request information carried in the confirmation request.

[0148] Combination Figure 6 , Figure 7 and Figure 8A As shown, step S812 can be described with reference to the aforementioned step S220. In addition to verifying whether the above-mentioned user account on-chain address and the above-mentioned institution account on-chain address are genuine and valid and whether there is a subordinate relationship between the above-mentioned user and the institution to which the user belongs, verifying whether the institution to which the user belongs has a preset role for data processing of the above-mentioned confirmation letter, verifying whether the content of the above-mentioned confirmation letter message conforms to a unified standard format, and verifying whether the above-mentioned electronic signature is legal, the above-mentioned smart contract input parameter verification also includes the following verification steps: verifying whether the above-mentioned auditor account on-chain address, the above-mentioned auditee account on-chain address, and the above-mentioned financial confirmer account on-chain address are genuine and valid.

[0149] The process of verifying whether the organization to which the user belongs has a preset role for processing the data in response to the above confirmation letter includes: verifying whether the on-chain address of the organization account in the above request is consistent with the on-chain address of the auditing party account. If they are consistent, it is considered that the organization to which the user belongs has an auditing party role configured, and the auditing party role has the authority to initiate confirmation requests and query the status of confirmation requests.

[0150] In step S813, if the smart contract input parameters pass the verification, the target smart contract is created.

[0151] In step S814, the above-mentioned confirmation processing content and process record information are stored in the target smart contract, and the state of the target smart contract is updated.

[0152] In one specific embodiment, when a user (e.g., the auditor's user) initiates a confirmation request, the confirmation processing node creates a target smart contract corresponding to the confirmation request identifier. After the contract program is loaded, the node sends the data content that conforms to the communication protocol for initiating the confirmation request to the target smart contract, which then executes the data.

[0153] After receiving the smart contract input parameters, verify whether the request information carried in the request meets the conditions for initiating a confirmation query. Specifically, this may include:

[0154] (a1) Determine if the header information is complete, where reference... Figure 6 As shown, the encryption / decryption algorithm identifier and the key index using the encryption / decryption algorithm are not required; they can be included or omitted.

[0155] (b1) Determine if the confirmation request section in the content information is complete; the content information can be referenced... Figure 6 As shown;

[0156] (c1) Verify whether the account address of the initiating institution, the operator, the auditor, the auditee, and the financial confirmer in the verification parameters are real and have not been cancelled;

[0157] (d1) Verify whether the operator's account belongs to the initiating organization (corresponding to verifying whether there is a subordinate relationship between the user and the organization to which the user belongs);

[0158] (e1) Verify whether the account address of the initiating organization is consistent with the account address of the auditor; this step corresponds to the consistency verification between the on-chain address of the organization account and the on-chain address of the aforementioned auditor account, and is used to verify whether the user's organization has a preset role for data processing of the aforementioned confirmation letter.

[0159] (f1) Parse the XBRL message and verify whether the content of the initiated confirmation message conforms to the unified standard format requirements;

[0160] (g1) Verify the authenticity of the electronic signature of the user's request.

[0161] If the validation fails, return a failed request response result directly.

[0162] When the verification passes, create the target smart contract corresponding to the confirmation letter identifier, and store the following content in the target smart contract:

[0163] (C1.1a) Basic information, including: protocol type, protocol version, encryption / decryption algorithm identifier, encryption / decryption key index used, start time and business status, and update the business status to the status of initiated confirmation;

[0164] (C2.1a) Contract information in the main body, including: confirmation letter identifier (unique number), auditor's account address, auditee's account address and financial confirmer's account address;

[0165] (C2.2a) Part of the initiating content of the body includes: the calculated digest hash value of the confirmation message to be authorized, and the electronic signature of the requesting user on the digest hash value by the auditor;

[0166] (C3.1a) Process recording information includes: the digest hash value of the content submitted in the request, the formatted submission content, the operator's account address, the operator's name, the operator's action (e.g., an enumeration value of the action) and the operation time (e.g., the time when the request arrived as described above).

[0167] In some embodiments, after storing the above-mentioned confirmation processing content and process record information in encrypted or unencrypted form in the smart contract, a successful request response result is returned.

[0168] Figure 8B The illustration schematically depicts an implementation flow diagram of a blockchain-based confirmation letter data processing method for processing authorization confirmation requests according to an embodiment of the present disclosure.

[0169] Reference Figure 8B As shown, the process of processing authorization confirmation requests using the blockchain-based confirmation letter data processing method includes steps S821 to S824.

[0170] In step S821, a confirmation request is received from the user in response to the confirmation letter. This request carries the following information: the user's on-chain account address, the on-chain address of the user's organization's on-chain account, the confirmation letter message content, and the confirmation processing content. The confirmation processing content includes: a confirmation letter identifier, an operation instruction, the hash value of the confirmation letter message content, and a digital signature. The digital signature is encrypted text that has been certified by signing the hash value.

[0171] According to an embodiment of this disclosure, when the above operation instruction is an authorization confirmation instruction, the content of the above confirmation message is an authorized confirmation message.

[0172] In step S822, the smart contract input parameter verification is performed based on the request information carried in the authorization confirmation request.

[0173] Combination Figure 6 , Figure 7 and Figure 8BAs shown, step S822 can be described with reference to step S220 above. In addition to verifying whether the user account's on-chain address and the organization's on-chain address are genuine and valid, and whether there is a subordinate relationship between the user and the organization to which the user belongs; verifying whether the organization to which the user belongs has a preset role for processing data related to the confirmation letter; verifying whether the content of the confirmation letter message conforms to a unified standard format; and verifying the legality of the electronic signature, the following verification steps are also included:

[0174] Verify whether the existing target smart contract is in the state of having initiated a confirmation request;

[0175] Verify whether the confirmation letter identifier in the above request is consistent with the initiated confirmation letter identifier (which can also be understood as the submitted confirmation letter identifier) ​​stored in the above target smart contract;

[0176] Verify whether the on-chain address of the auditee's account stored in the aforementioned target smart contract is genuine and valid;

[0177] Verify whether the content of the authorized confirmation message is consistent with the content of the unauthorized confirmation message stored in the target smart contract.

[0178] The process of verifying whether the organization to which the user belongs has a preset role for processing data in response to the above confirmation letter includes: verifying whether the on-chain address of the organization account in the above request is consistent with the on-chain address of the auditee account stored in the above target smart contract. If they are consistent, it is considered that the organization to which the user belongs has been configured with an auditee role, and the auditee role has the authority to authorize confirmation and query the confirmation status.

[0179] Because the request occurs in real time, a real-time verification process is performed to avoid situations where the identity is invalidated at a certain moment but the corresponding operation can still be performed.

[0180] In step S823, if the smart contract input parameters pass the verification, the existing target smart contract is invoked.

[0181] In step S824, the above-mentioned confirmation processing content and process record information are stored in the target smart contract, and the state of the target smart contract is updated.

[0182] In one specific embodiment, when the auditee (e.g., a user of the company being audited) authorizes content initiated by the auditor (e.g., a user of an accounting firm), it sends data content conforming to the authorization in the communication protocol to the target smart contract, which then executes the data.

[0183] After receiving the smart contract input parameters, verify whether the request information carried in the request meets the conditions for authorization confirmation. Specifically, this may include:

[0184] (a2) Determine if the header information is complete, whereby, refer to Figure 6 As shown, the encryption / decryption algorithm identifier and the key index using the encryption / decryption algorithm are not required; they can be included or omitted.

[0185] (b2) Determine if the authorization and verification section in the content information is complete; the content information can be referenced... Figure 6 As shown;

[0186] (c2) Whether the loaded encryption and decryption algorithm can complete the decryption of the stored content. This step is for the case where the stored content is encrypted. This step may not be included in the unencrypted embodiment.

[0187] (d2) Verify whether the confirmation letter identifier in the verification request is consistent with the information stored in the target smart contract (the initiated confirmation letter identifier stored in the target smart contract above);

[0188] (e2) Verify whether the contract status is "confirmation request initiated";

[0189] (f2) Verify whether the account address of the initiating organization and the account address of the operator in the request, as well as the account address of the auditee stored in the target smart contract, are real and valid (not cancelled).

[0190] (g2) Verify whether the account address of the initiating operation organization in the verification request is consistent with the account address of the auditee stored in the target smart contract;

[0191] (h2) Verify whether the operator's account belongs to the auditee;

[0192] (i2) Parse the XBRL message and verify whether the authorized confirmation message conforms to the unified standard format requirements and is consistent with the content items of the confirmation message before authorization.

[0193] (j2) Verify the authenticity of the user's electronic signature, specifically the electronic signature of the operation initiator. The operation initiator can be a role with operation authority or a non-role without operation authority.

[0194] If the validation fails, return a failed request response result directly.

[0195] When the verification passes, the target smart contract corresponding to the confirmation letter identifier is invoked to execute the authorization confirmation instruction, and the following content is stored in the target smart contract:

[0196] (C1.1b) Basic information in the main body, including: updating the business status to authorized confirmation status.

[0197] (C2.1b) The initiating content of the body includes: the calculated hash value of the authorized confirmation message digest, and the electronic signature of the auditee on the hash value of the digest.

[0198] (C3.1b) Process recording information, including: the digest hash value of the content information portion of the request, the operator's account address, the operator's name, the operator's action (e.g., an enumeration value of the action) and the operation time (e.g., the time when the request arrived as described above).

[0199] In some embodiments, after storing the above-mentioned confirmation processing content and process record information in encrypted or unencrypted form in the smart contract, a successful request response result is returned.

[0200] Figure 8C The illustration schematically shows an implementation flow diagram of a blockchain-based method for processing confirmation request data according to an embodiment of the present disclosure.

[0201] Reference Figure 8C As shown, the method for processing confirmation request data based on blockchain includes steps S831 to S834.

[0202] In step S831, a confirmation request from the user in response to the confirmation letter is received. This request carries the following information: the user's on-chain account address, the on-chain address of the user's organization's on-chain account, the confirmation letter message content, and the confirmation processing content. The confirmation processing content includes: a confirmation letter identifier, an operation instruction, the hash value of the confirmation letter message content, and a digital signature. The digital signature is encrypted text that has been certified by signing the hash value.

[0203] According to an embodiment of this disclosure, when the above operation instruction is a confirmation reply instruction, the content of the above confirmation reply message is the confirmation reply message.

[0204] In step S832, the smart contract input parameter verification is performed based on the request information carried in the confirmation request.

[0205] Combination Figure 6 , Figure 7 and Figure 8CAs shown, step S832 can be described with reference to the aforementioned step S220. In addition to verifying whether the user account's on-chain address and the organization's on-chain address are genuine and valid, and whether there is a subordinate relationship between the user and the organization to which the user belongs; verifying whether the organization to which the user belongs has a preset role for processing data related to the confirmation letter; verifying whether the content of the confirmation letter message conforms to a unified standard format; and verifying the legality of the electronic signature, the following verification steps are also included:

[0206] Verify whether the existing target smart contract is in the authorized verification state;

[0207] Verify whether the confirmation letter identifier in the above request is consistent with the authorized confirmation letter identifier stored in the target smart contract above;

[0208] Verify whether the on-chain address of the financial certifier account stored in the aforementioned target smart contract is authentic and valid;

[0209] Verify whether the content of the confirmation message following the above reply, in response to the above authorized confirmation message stored in the above target smart contract, meets the preset requirements.

[0210] The process of verifying whether the institution to which the user belongs has a preset role for processing the data in response to the above confirmation letter includes: verifying whether the on-chain address of the institution's account in the above request is consistent with the on-chain address of the financial confirmer's account stored in the above target smart contract. If they are consistent, it is considered that the institution to which the user belongs has a financial confirmer role configured, and the financial confirmer role has the authority to reply to the confirmation letter and query the confirmation status.

[0211] In step S833, if the smart contract input parameters pass the verification, the existing target smart contract is invoked.

[0212] In step S834, the above-mentioned confirmation processing content and process record information are stored in the target smart contract, and the state of the target smart contract is updated.

[0213] In one specific embodiment, after receiving the request, the financial certifier (e.g., a bank) completes the reply and, upon confirming the reply, sends the data content conforming to the communication protocol for initiating the confirmation reply to the target smart contract, which then executes the reply.

[0214] After receiving the smart contract input parameters, verify whether the request information carried in the request meets the conditions for a confirmation reply. Specifically, this may include:

[0215] (a3) Determine if the header information is complete, whereby referencing Figure 6As shown, the encryption / decryption algorithm identifier and the key index using the encryption / decryption algorithm are not required; they can be included or omitted.

[0216] (b3) Determine if the response and confirmation section in the content information is complete; the content information can be referenced... Figure 6 As shown;

[0217] (c3) Whether the loaded encryption and decryption algorithm can decrypt the stored content; this step is for the case where the stored content is encrypted. This step may not be included in the embodiment where the content is not encrypted.

[0218] (d3) Verify whether the confirmation letter identifier in the verification request is consistent with the information stored in the target smart contract (the initiated confirmation letter identifier stored in the target smart contract above);

[0219] (e3) Verify whether the contract status is in the authorized confirmation state;

[0220] (f3) Verify whether the account address of the initiating institution and the account address of the operator in the request, as well as the account address of the financial confirmer stored in the target smart contract, are real and valid (not cancelled).

[0221] (g3) Verify whether the account address of the initiating institution in the verification request is consistent with the account address of the financial confirmer stored in the target smart contract; this step is used to verify whether the user's institution has a preset role for processing the data in response to the above confirmation letter.

[0222] (h3) Verify whether the operator's account belongs to the financial verification party;

[0223] (i3) Parse the XBRL message and verify whether the content of the reply confirmation meets the requirements;

[0224] (j3) Verify the authenticity of the user's electronic signature.

[0225] If the validation fails, return a failed request response result directly.

[0226] When the verification passes, the target smart contract corresponding to the confirmation letter identifier is invoked to execute the reply confirmation instruction, and the following content is stored in the target smart contract:

[0227] (C1.1c) Basic information in the body of the text, including: updating the business status to the status of having responded to the inquiry;

[0228] (C2.1c) The initiating content of the body includes: calculating the digest hash value of the confirmation message after the reply, and the electronic signature of the digest hash value;

[0229] (C3.1c) Process recording information, including: the digest hash value of the content information portion of the request, the operator's account address, the operator's name, the operator's action (e.g., an enumeration value of the action) and the operation time (e.g., the time when the request arrived as described above).

[0230] Note that once the target smart contract successfully responds to the confirmation request, it enters the final state and can no longer be modified.

[0231] According to other embodiments of this disclosure, based on the above embodiments, the method for processing blockchain-based confirmation letter data further includes the following pre-registration step:

[0232] The system receives user registration requests, which carry the following information: registration information, user identity information, and information about the user's affiliated organization.

[0233] Verify the authenticity of the above user identity information;

[0234] Verify whether the information about the organization to which the user belongs is authentic and whether the user has registered in the aforementioned blockchain system;

[0235] After verifying that the above user identity information is true and that the above user's affiliated organization information is true and that the user has registered, the subordinate relationship between the user and the user's affiliated organization is verified based on the above user identity information and the above user's affiliated organization information.

[0236] If the affiliation relationship is verified, user account information of the above user is generated based on the above registration information, and an association identifier belonging to the organization information of the above user account information is generated for the above user account information.

[0237] The system calls upon a certificate issued by a reputable certificate authority to generate a trusted electronic signature bound to the aforementioned user account information; the user account information and the corresponding trusted electronic signature are stored in the ledger of the aforementioned blockchain system to generate a unique on-chain address for the user account.

[0238] For example, the subordinate relationship can be verified by using the preset list information of registered nodes. The preset list information also includes user permission information.

[0239] According to embodiments of this disclosure, the aforementioned user's affiliated organization information includes: the organization identifier of the user's affiliated organization (e.g., organization account information, organization name, etc.) and the organization account's on-chain address.

[0240] Verifying whether the organization to which the aforementioned user belongs has registered in the aforementioned blockchain system includes: querying the ledger of the aforementioned blockchain system to see if the on-chain address of the aforementioned organization's account exists; if the on-chain address of the aforementioned organization's account exists, determining whether the aforementioned organization's identifier matches the information stored in the on-chain address of the aforementioned organization's account; if the match is successful, it is considered that the organization to which the aforementioned user belongs has registered in the aforementioned blockchain system.

[0241] Because some third-party self-made software and hardware certificates lack credibility, the encryption methods are non-compliant, making it difficult to verify the authenticity and compliance of the content uploaded to the blockchain. The embodiments disclosed in this disclosure call a certificate issued by a credible certificate authority during user registration to generate a trusted electronic signature bound to the user's account information and store it in the blockchain ledger, generating a unique on-chain address for the user account. At each stage of the confirmation letter processing (such as initiating confirmation, authorizing confirmation, and responding to confirmation), the user needs to verify the electronic signature based on this trusted electronic signature. In this way, the reliability of certificate authorization is achieved off-chain, and the use and verification of certificates on the blockchain are combined, improving the authenticity, reliability, and compliance of the data stored in the blockchain ledger.

[0242] A second exemplary embodiment of this disclosure provides a blockchain system.

[0243] Figure 9 A schematic block diagram of a blockchain system according to an embodiment of the present disclosure is shown.

[0244] Reference Figure 9 As shown in the embodiments of this disclosure, the blockchain system 900 includes: a confirmation processing node 910. The processing roles of the above-mentioned confirmation processing node include at least one of the following: an auditor role, an auditee role, and a financial confirmer role.

[0245] The aforementioned confirmation processing node 910 includes: a request receiving module 911, a parameter verification module 912, and a processing module 913.

[0246] The aforementioned request receiving module 911 is used to receive user requests for data processing of confirmation letters. The requests carry the following request information: the user account's on-chain address, the on-chain address of the institution's account to which the user belongs, the content of the confirmation letter message, and the confirmation processing content. The confirmation processing content includes: confirmation letter identifier, operation instructions, and electronic signature.

[0247] The parameter verification module 912 is used to perform smart contract input parameter verification according to the above request information; the smart contract input parameter verification includes: verifying whether the above user account on-chain address and the above institution account on-chain address are real and valid and whether there is a subordinate relationship between the above user and the institution to which the user belongs; verifying whether the institution to which the user belongs has a preset role for data processing of the above confirmation letter; verifying whether the content of the above confirmation letter message conforms to a unified standard format; and verifying whether the above electronic signature is legal.

[0248] The aforementioned processing module 913 is used to create or call the target smart contract corresponding to the aforementioned confirmation letter identifier to execute the aforementioned operation instructions when the aforementioned smart contract input parameter verification passes.

[0249] The aforementioned confirmation processing node 910 may also include functional modules corresponding to more detailed steps or other steps for implementing the method described in the first embodiment above. These can be understood with reference to the first embodiment and will not be repeated here.

[0250] Any of the above-mentioned request receiving module 911, parameter verification module 912, and processing module 913 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. At least one of the request receiving module 911, parameter verification module 912, and processing module 913 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging the circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the request receiving module 911, parameter verification module 912, and processing module 913 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0251] A third exemplary embodiment of this disclosure provides an electronic device.

[0252] Figure 10 A schematic block diagram of an electronic device provided in an embodiment of the present disclosure is shown.

[0253] Reference Figure 10As shown, the electronic device 1000 provided in this embodiment includes a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004. The processor 1001, the communication interface 1002, and the memory 1003 communicate with each other through the communication bus 1004. The memory 1003 is used to store computer programs. When the processor 1001 executes the program stored in the memory, it implements the blockchain-based confirmation letter data processing method described above.

[0254] A fourth exemplary embodiment of this disclosure also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program that, when executed by a processor, implements the blockchain-based confirmation letter data processing method described above.

[0255] The computer-readable storage medium may be included in the device / apparatus described in the above embodiments; or it may exist independently and not assembled into the device / apparatus. The computer-readable storage medium carries one or more programs that, when executed, implement the method according to the embodiments of this disclosure.

[0256] According to embodiments of this disclosure, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including, but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0257] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0258] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for processing confirmation letter data based on blockchain, characterized in that, Applied to confirmation processing nodes, a blockchain system comprises multiple confirmation processing nodes with different processing roles. For each confirmation processing node, the method includes: The system receives a user's request to process a confirmation letter. The request carries the following information: the user's on-chain account address, the on-chain address of the user's organization's on-chain account, the confirmation letter message content, and the confirmation processing content. The confirmation processing content includes: a confirmation letter identifier, the hash value of the confirmation letter message content, an operation instruction, and a digital signature. The operation instruction includes one or more of the following: initiating a confirmation instruction, authorizing a confirmation instruction, responding to a confirmation instruction, and querying the confirmation status instruction. The digital signature is ciphertext that has been signed with a certificate based on the hash value. Based on the request information, perform smart contract input parameter verification; the smart contract input parameter verification includes: verifying whether the user account on-chain address and the organization account on-chain address are real and valid and whether there is a subordinate relationship between the user and the organization to which the user belongs; verifying whether the organization to which the user belongs has a preset role for data processing of the confirmation letter; verifying whether the content of the confirmation letter message conforms to a unified standard format; and verifying whether the electronic signature is legal. If the smart contract input parameters pass the verification, a target smart contract corresponding to the confirmation letter identifier is created or invoked to execute the operation instructions.

2. The method according to claim 1, characterized in that, Also includes: The confirmation processing content and process record information are stored in the target smart contract, and the state of the target smart contract is updated. The process record information includes: the digest hash value of the submitted confirmation processing content, the operator's account, the operator's on-chain address, the operator's action, and the operation time.

3. The method according to claim 2, characterized in that, The request information also includes: encryption / decryption algorithm identifier and encryption / decryption key index; The method further includes: Based on the encryption / decryption algorithm identifier, the target encryption / decryption algorithm is invoked from an external service or obtained from the blockchain system. Based on the key index, obtain the encryption / decryption key from the external service or the blockchain system; Based on the key and the encryption / decryption algorithm, the confirmation processing content and the process record information to be stored in the target smart contract are encrypted, or the confirmation processing content and the process record information already stored in the target smart contract in ciphertext form are decrypted.

4. The method according to claim 2, characterized in that, When the operation instruction is to initiate a confirmation instruction, the content of the confirmation message is a confirmation message to be authorized; the confirmation processing content also includes: the on-chain address of the auditor's account, the on-chain address of the auditee's account, and the on-chain address of the financial confirmer's account; The smart contract input parameter verification also includes: verifying whether the on-chain address of the auditor's account, the on-chain address of the audited party's account, and the on-chain address of the financial confirmer's account are genuine and valid; wherein, verifying whether the user's institution has a preset role for processing data in the confirmation letter includes: verifying whether the on-chain address of the institution's account in the request is consistent with the on-chain address of the auditor's account. If they are consistent, it is considered that the user's institution has an auditor role configured, and the auditor role has the authority to initiate confirmation requests and query the confirmation status.

5. The method according to claim 4, characterized in that, When the operation instruction is an authorization confirmation instruction, the content of the confirmation message is the authorized confirmation message; The smart contract input parameter verification also includes: verifying whether the existing target smart contract is in a state of initiated confirmation; verifying whether the confirmation letter identifier in the request is consistent with the initiated confirmation letter identifier stored in the target smart contract; verifying whether the auditee account on-chain address stored in the target smart contract is genuine and valid; verifying whether the content of the authorized confirmation letter message is consistent with the content of the pending authorization confirmation letter message stored in the target smart contract; wherein, verifying whether the user's organization has a preset role for data processing of the confirmation letter includes: verifying whether the organization account on-chain address in the request is consistent with the auditee account on-chain address stored in the target smart contract. If they are consistent, it is considered that the user's organization has an auditee role configured, and the auditee role has the authority to authorize confirmation and query the confirmation status.

6. The method according to claim 5, characterized in that, When the operation instruction is a confirmation reply instruction, the content of the confirmation reply message is the confirmation reply message after the reply. The smart contract input parameter verification also includes: verifying whether the existing target smart contract is in an authorized confirmation state; verifying whether the confirmation letter identifier in the request is consistent with the authorized confirmation letter identifier stored in the target smart contract; verifying whether the on-chain address of the financial confirmer account stored in the target smart contract is genuine and valid; verifying whether the content of the reply confirmation letter message responding to the authorized confirmation letter message stored in the target smart contract meets the preset requirements; wherein, verifying whether the user's institution has a preset role for processing the confirmation letter includes: verifying whether the on-chain address of the institution's account in the request is consistent with the on-chain address of the financial confirmer account stored in the target smart contract. If they are consistent, it is considered that the user's institution has a financial confirmer role configured, and the financial confirmer role has the authority to reply to confirmation requests and query the confirmation status.

7. The method according to claim 1, characterized in that, The ledger of the blockchain system stores registered user information. For each registered user, the registered user information includes: user account information, trusted electronic signature, user account on-chain address, and the association identifier of the user's affiliated institution. The trusted electronic signature is an encrypted document that is signed by calling a certificate issued by a credible certificate authentication server during user registration. The registered user's account information and corresponding trusted electronic signature are bound and stored in the ledger of the blockchain system, corresponding to a unique on-chain address for the user account.

8. The method according to claim 1 or 7, characterized in that, Registered organizations are configured with pre-defined roles for processing data related to the confirmation letters; the method further includes: If the smart contract input parameters pass the verification, the user's operation permissions are determined according to the preset role of the user's organization. Determine whether the operation instruction is within the specified operation permissions; If the operation instruction is within the scope of the operation authority, a target smart contract corresponding to the confirmation letter identifier is created or an existing target smart contract is invoked to execute the operation instruction.

9. The method according to claim 7, characterized in that, Verifying the authenticity and validity of the user account's blockchain address and the organization's blockchain address, and confirming the subordinate relationship between the user and the organization, includes: Based on the registered user information, query whether the blockchain address of the user account and the blockchain address of the organization to which the user belongs exist and are valid; If the user account's on-chain address and the organization's on-chain address are both present and valid, determine whether there is a subordinate relationship between the user and the organization to which the user belongs based on the association identifier. Verifying the validity of the electronic signature includes: Call the certificate verification service of the certificate authentication server to verify whether the electronic signature is valid.

10. The method according to claim 1 or 7, characterized in that, Also includes: The system receives a user's registration request, which carries the following information: registration information, user identity information, and information about the organization to which the user belongs; Verify whether the user's identity information is authentic; Verify whether the user's affiliated organization information is authentic and whether the user has registered in the blockchain system; If the user's identity information and the user's affiliated organization information are verified to be true and registered, then the subordinate relationship between the user and the user's affiliated organization is verified based on the user's identity information and the user's affiliated organization information. If the affiliation relationship is verified to be valid, user account information of the user is generated based on the registration information, and an association identifier belonging to the organization information to which the user belongs is generated for the user account information. The system invokes a certificate issued by a reputable certificate authority to generate a trusted electronic signature bound to the user account information. The user account information and the corresponding bound trusted electronic signature are stored in the ledger of the blockchain system to generate a unique on-chain address for the user account.

11. The method according to claim 10, characterized in that, The user's affiliated organization information includes: the organization identifier and the organization account's on-chain address; Verifying whether the user's affiliated organization has registered in the blockchain system includes: Check the ledger of the blockchain system to see if the on-chain address of the institution's account exists. If the on-chain address of the organization account exists, determine whether the organization identifier matches the information stored in the on-chain address of the organization account; If a match is successful, it is considered that the user's organization has been registered in the blockchain system.

12. A blockchain system, characterized in that, include: The confirmation processing node has at least one of the following roles: auditor, auditee, and financial confirmer. The confirmation processing node includes: a request receiving module, a parameter verification module, and a processing module; The request receiving module is used to receive user requests for data processing of confirmation letters. The request carries the following request information: the user's account on-chain address, the on-chain address of the user's organization's account, the confirmation letter message content, and the confirmation processing content. The confirmation processing content includes: a confirmation letter identifier, the hash value of the confirmation letter message content, an operation instruction, and an electronic signature. The operation instruction includes one or more of the following: initiating a confirmation instruction, authorizing a confirmation instruction, responding to a confirmation instruction, and querying the confirmation status instruction. The electronic signature is ciphertext signed with a certificate based on the hash value. The parameter verification module is used to perform smart contract input parameter verification according to the request information; the smart contract input parameter verification includes: verifying whether the user account on-chain address and the organization account on-chain address are real and valid and whether there is a subordinate relationship between the user and the organization to which the user belongs; verifying whether the organization to which the user belongs has a preset role for data processing of the confirmation letter; verifying whether the content of the confirmation letter message conforms to a unified standard format; and verifying whether the electronic signature is legal. The processing module is used to create or call the target smart contract corresponding to the confirmation letter identifier to execute the operation instruction when the input parameters of the smart contract pass the verification.

13. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-11.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-11.

Images