A blockchain transaction-based trusted application implementation method

Abstract

The application discloses a kind of based on blockchain transaction credible application implementation method, belong to blockchain technical field, including making online transaction digital trust system, in combination with the characteristics of "initiation-right confirmation-evidence storage" multi-party consensus, symmetric / asymmetric encryption algorithm, digital signature verification, password envelope, tamper-proofing, construct third party transaction certification service platform, form online transaction digital trust system, solve the technical problems of multi-party transaction trust, data security and data privacy, the application realizes a new consensus mechanism, each transaction needs transaction cooperation each party to be right before chain, to ensure that the transaction data of chain is accurate, real, reliable, greatly alleviate and reduce the invalid data or error data that may appear in actual business process and the chain caused various problems;Realize the multiple security protection mechanism of transaction associated accessory.

Description

Technical Field

[0001] This invention belongs to the field of blockchain technology, and in particular relates to a method for implementing trusted applications based on blockchain transactions. Background Technology

[0002] As another technological innovation following cloud computing, big data, and mobile internet, blockchain technology is a decentralized computing paradigm that uses distributed node consensus algorithms to verify, store, and update data. It possesses characteristics such as decentralization, traceability, and immutability, attracting widespread attention across various industries. Naturally, the application of blockchain technology helps to effectively solve the trust issues of online transaction systems.

[0003] It is precisely because of the immutable nature of blockchain technology that prominent problems arise in practical use, such as transaction data (some transactions may be invalid before being recorded on the chain, or data that is erroneous due to other reasons) being unable to be recalled or modified once recorded on the chain.

[0004] Given that blockchain, as a distributed ledger technology, stores complete blockchain data locally on multiple nodes (or even all nodes), and considering the limitations of blockchain block size, large files such as transaction attachments are generally not directly uploaded to the blockchain; instead, only relevant summary information is uploaded. Therefore, how to effectively store, protect, and ensure the trustworthiness of original electronic vouchers such as invoices, orders, and receipts that cannot be directly uploaded to the blockchain during the transaction process requires careful consideration and exploration.

[0005] As a decentralized and trustless technology, blockchain requires further design considerations to achieve data sharing, openness, and transparency in multi-party collaboration while simultaneously protecting the privacy of critical and sensitive data. In fact, transactions and balances in many blockchain systems are visible to the entire network. To effectively control data visibility, cryptographic techniques are often introduced, combined with off-chain security governance strategies. Summary of the Invention

[0006] The purpose of this invention is to provide a method for implementing trusted applications based on blockchain transactions, which solves the technical problems of trust in multi-party transactions, data security, and data privacy.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: a method for implementing a trusted application based on blockchain transactions, comprising the following steps:

[0008] Step 1: Set up a central server cluster and deploy an interface for applying to upload transaction data to the blockchain within the central server cluster. The interface is used to receive and verify applications to upload transaction data to the blockchain submitted by the business system.

[0009] Step 2: A data caching module is set up in the central server cluster. The data caching module caches transaction data, generates multiple random passwords for each party's user based on the transaction data, and sends the authorization link and random passwords to each party involved in the transaction.

[0010] Step 3: All users open the received confirmation link, view the on-chain content, enter a random password, and complete the secondary confirmation of transaction rights;

[0011] After all collaborating users involved in the transaction have entered the correct random password to complete the secondary confirmation, the central server cluster calls a unified standard on-chain smart contract to encrypt the transaction data using cryptographic envelope technology before uploading it to the blockchain; if any user fails to complete the confirmation of rights, the transaction data will not be uploaded to the blockchain.

[0012] Step 4: After the transaction data is successfully uploaded to the blockchain, the corresponding receiving interface provided by the business system requesting the blockchain upload is used to send the blockchain transaction hash and the password of the password envelope back to the original business system that requested the blockchain upload. At the same time, the central server cluster sends the password of the envelope to all users involved in the transaction, ensuring that the blockchain transaction hash and password of the password envelope are only spread within a limited range of the parties involved in the transaction.

[0013] When parties to a transaction want to view the complete on-chain transaction information, they must pass the correct on-chain transaction hash value and password envelope password through the interface, and call the unified standard off-chain smart contract in order to obtain the decrypted transaction data from the chain.

[0014] Preferably, the transaction data includes user information of the parties involved in the transaction collaboration, transaction details, and related signed original electronic voucher attachments.

[0015] Preferably, the central server cluster integrates a third-party distributed framework. The third-party distributed framework is used to build a distributed file evidence storage system and restricts access permissions through multiple levels such as network policies, service configurations, and application APIs, limiting I / O access to only the interfaces provided by the central server cluster.

[0016] Preferably, when performing steps 2 and 3, a distributed file evidence storage system is built in the central server cluster, that is, providing standard file signature verification interface, ZIP file upload interface, ZIP file download interface and ZIP file hash verification interface;

[0017] After the original electronic voucher file is signed and verified, it is encrypted, compressed into ZIP format, and uploaded to the distributed file storage system for storage. The system also returns a random and unique ZIP file FileID, file access password, and original electronic voucher file decompression password.

[0018] The encrypted ZIP file must be downloaded via the download interface using the ZIP file's FileID and file access password; and users need to use the decompression password to decompress the ZIP file in order to view the original electronic certificate file.

[0019] Preferably, when performing step 3, the basic transaction information, ZIP file FileID, file access password, original electronic certificate file decompression password, file digest, and file anti-tampering hash value are encrypted using cryptographic envelope technology and then uploaded to the blockchain.

[0020] Preferably, when uploading transaction data to the blockchain application interface, the transaction data upload application interface supports uploading and sending multiple attachments, and the requester needs to sign each attachment using a private key;

[0021] After receiving the transaction data, the data caching module verifies the signature of the uploaded attachments using the requester's public key. After the rights of all parties involved in the transaction are confirmed, a pre-set decompression password is randomly generated, and multiple attachments associated with the transaction are encrypted and compressed into a ZIP file.

[0022] Preferably, in step 4, the API of the distributed file storage system is called to download the compressed transaction certificate attachment ZIP package using the FileID and file access password included in the decrypted transaction record; the original electronic certificate file decompression password obtained on-chain is used to decompress the ZIP package, thereby viewing the original transaction electronic certificate attachment.

[0023] This invention discloses a blockchain-based trusted application implementation method that solves the technical problems of trust, data security, and data privacy in multi-party transactions. The invention implements a novel consensus mechanism where each transaction requires joint confirmation of rights by all parties involved before being recorded on the blockchain, ensuring the accuracy, authenticity, and reliability of the recorded transaction data. This significantly alleviates and reduces various problems caused by the recording of invalid or erroneous data during actual business operations. The invention also implements a secure, reliable, and protected distributed file storage system for encrypting and storing electronic voucher attachments related to transaction documents. Through a defined API interface, a ZIP file FileID and file access password are provided for downloading the stored file; a decompression password is required to decompress the ZIP file and view the original electronic voucher attachment content; and file hash verification and signature verification functions are provided to ensure the authenticity and reliability of the files. This invention implements multiple security protection mechanisms for transaction-related attachments, using cryptographic envelopes to protect sensitive transaction information and private data, thereby achieving the goal of ensuring that transaction information is only publicly shared among a limited number of collaborating parties. Attached Figure Description

[0024] Figure 1 This is a flowchart of the present invention;

[0025] Figure 2 This is a logic diagram of the transaction data on-chaining of the present invention;

[0026] Figure 3 This is a logic diagram for viewing transaction data on the blockchain according to the present invention. Detailed Implementation

[0027] Depend on Figures 1-3 The method for implementing a trusted application based on blockchain transactions, as shown, includes the following steps:

[0028] Step 1: Set up a central server cluster and deploy an interface for applying to upload transaction data to the blockchain within the central server cluster. The interface is used to receive and verify applications to upload transaction data to the blockchain submitted by the business system.

[0029] The transaction data includes user information of all parties involved in the transaction, transaction details, and related signed original electronic voucher attachments.

[0030] In this embodiment, transaction data also includes, but is not limited to, orders, invoices, and receipts.

[0031] The central server cluster integrates a third-party distributed framework, which in this embodiment may be FastDFS, but is not limited to. The third-party distributed framework is used to build a distributed file storage system and restricts access permissions to multiple levels, such as network policies, service configurations, and application APIs, so that I / O access can only be performed through the interfaces provided by the central server cluster.

[0032] In this embodiment, the encrypted ZIP package is uploaded to the distributed file storage system to obtain the uploaded ZIP file FileID, and a random file access password, file digest, and file anti-tampering hash value are generated.

[0033] The ZIP file's FileID, file access password, original electronic voucher file decompression password, file digest, and file anti-tampering hash value are associated with the transaction data and encrypted together and uploaded to the blockchain.

[0034] Authorized business systems or users need to use the ZIP file's FileID and file access password to call a dedicated API interface to download the ZIP file; after downloading the ZIP file, the ZIP package needs to be opened with the decompression password to view the original transaction voucher attachments.

[0035] This application also provides a file hash verification function to ensure that the ZIP file has not been tampered with; and a file signature verification function to verify the authenticity and validity of each original credential attachment in the ZIP package (the underlying interface uses the public key of the transaction data submitter to complete the signature verification).

[0036] After receiving the transaction data, the data caching module verifies the signature of the uploaded attachments using the requester's public key. After the rights of all parties involved in the transaction are confirmed, a pre-set decompression password is randomly generated, and multiple attachments associated with the transaction are encrypted and compressed into a ZIP file.

[0037] When applying for the transaction data upload to the blockchain, the application interface supports uploading and sending multiple attachments. The requester needs to sign each attachment using a private key.

[0038] In this embodiment, the central server cluster can adopt a B / S architecture web service to implement the function of the method of the present invention. Based on existing blockchain and smart contract technologies, it combines third-party distributed file systems, symmetric / asymmetric encryption algorithms, digital signature verification, and cryptographic envelope technology, and integrates SMS gateways, WeChat interfaces, email services, etc. It also provides service interfaces including but not limited to protocols or technologies such as Socket, HTTP, and WebService.

[0039] Step 2: A data caching module is set up in the central server cluster. The data caching module caches transaction data, generates multiple random passwords for each party's user based on the transaction data, and sends the authorization link and random passwords to each party involved in the transaction.

[0040] In this embodiment, the authorization link and random password are sent to all users via SMS, WeChat, or email.

[0041] The central server cluster maintains the mobile phone number, WeChat ID, or email address from which all users can receive confirmation information via SMS, and the sending channel is optional.

[0042] Step 3: All users open the received confirmation link, view the on-chain content, enter a random password, and complete the secondary confirmation of transaction rights;

[0043] Users open the received link, view the on-chain content, enter the random password for confirmation, and complete the transaction confirmation;

[0044] After all collaborating users involved in the transaction have entered the correct random password to complete the secondary confirmation, the central server cluster calls a unified standard on-chain smart contract to encrypt the transaction data using cryptographic envelope technology before uploading it to the blockchain; if any user fails to complete the confirmation of rights, the transaction data will not be uploaded to the blockchain.

[0045] In step 3, the basic transaction information, ZIP file FileID, file access password, original electronic certificate file decompression password, file digest, and file anti-tampering hash value are encrypted using cryptographic envelope technology and then uploaded to the blockchain.

[0046] When performing steps 2 and 3, a distributed file storage system is built in the central server cluster, which provides standard file signature verification interface, ZIP file upload interface, ZIP file download interface and ZIP file hash verification interface.

[0047] After the original electronic voucher file is signed and verified, it is encrypted, compressed into ZIP format, and uploaded to the distributed file storage system for storage. The system also returns a random and unique ZIP file FileID, file access password, and original electronic voucher file decompression password.

[0048] The encrypted ZIP file must be downloaded via the download interface using the ZIP file's FileID and file access password; and users need to use the decompression password to decompress the ZIP file in order to view the original electronic certificate file.

[0049] Step 4: After the transaction data is successfully uploaded to the blockchain, the corresponding receiving interface provided by the business system requesting the blockchain upload is used to send the blockchain transaction hash and the password of the password envelope back to the original business system that requested the blockchain upload. At the same time, the central server cluster sends the password of the envelope to all users involved in the transaction, ensuring that the blockchain transaction hash and password of the password envelope are only spread within a limited range of the parties involved in the transaction.

[0050] When parties to a transaction want to view the complete on-chain transaction information, they must pass the correct on-chain transaction hash value and password envelope password through the interface, and call the unified standard off-chain smart contract in order to obtain the decrypted transaction data from the chain.

[0051] In step 4, the API of the distributed file storage system is called to download the compressed transaction certificate attachment ZIP package using the FileID and file access password included in the decrypted transaction record. The original electronic certificate file decompression password obtained on the chain is used to decompress the ZIP package, thereby viewing the original transaction electronic certificate attachment. This solves the problem of security and confidentiality of sensitive information and privacy data on a transparent, shared, and open blockchain.

[0052] The following is the specific process of this embodiment:

[0053] Step S1: Receive and verify the application to upload transaction data from the business system to the blockchain;

[0054] In this embodiment, a standardized interface needs to be developed and implemented in advance to receive transaction data. It should be noted that the transaction data includes basic transaction information and original electronic voucher attachments, etc.

[0055] like Figure 2As shown, data validation rules need to be preset in the interface to verify the integrity and accuracy of transaction data, and to verify the signatures of original attachments. If the validation fails, an error message should be sent to the business system.

[0056] Step S2: Temporarily store transaction data and generate a transaction confirmation link and password.

[0057] After the on-chain application data verification is passed, the transaction data is temporarily stored on the disk. Simultaneously, a secondary confirmation link is generated for the temporary storage record of this transaction's on-chain application, along with multiple random confirmation passwords for the two or more users involved in the transaction. Furthermore, technologies or APIs such as SMS gateways, WeChat Open Platform, and email services are integrated to send the confirmation link address and the unique confirmation passwords for the transaction's related users to the relevant users via SMS or email.

[0058] Step S3: All parties involved in the transaction use their passwords to conduct a second confirmation of ownership of the transaction data submitted for this on-chain application.

[0059] The parties involved in the transaction open the confirmation link in the received SMS or email, enter the confirmation password, and complete the confirmation action for this transaction, thus reaching a consensus.

[0060] It should be noted that, as Figure 2 As shown, all parties involved in the transaction must complete the confirmation of rights before the on-chain workflow can continue to be executed; otherwise, it will continue to wait for other related parties to submit confirmation of rights.

[0061] Step S4: Randomly generate a preset password and encrypt and compress all atomic electronic certificate attachments associated with the transaction in this on-chain application into a ZIP package format.

[0062] The pre-set password is used by all parties involved in subsequent transactions to download the ZIP package and extract the original electronic voucher attachment.

[0063] Step S5: Build a distributed file storage system, upload the encrypted transaction attachment ZIP package, and return the ZIP file's FileID, file access password, etc.

[0064] It can integrate with third-party distributed frameworks (such as, but not limited to, FastDFS) to implement a distributed file storage system. Access permissions are restricted through multiple layers, including network policies, service configurations, and application APIs, limiting I / O access to only the API interfaces provided by this invention. The encrypted ZIP package is uploaded to the distributed file storage system, obtaining the uploaded ZIP file's FileID, and generating a random file access password, file digest, and file anti-tampering hash value.

[0065] Step S6: Generate a password envelope to encrypt the transaction data.

[0066] A cryptographic envelope technique is used to generate a random key to encrypt the transaction data to be uploaded to the blockchain, thereby obtaining the encrypted transaction data to be uploaded to the blockchain.

[0067] It should be noted that the encrypted transaction data includes: basic transaction information, the FileID of the encrypted and compressed ZIP file of the original electronic transaction certificate, the access password for the evidence file, the decompression password of the ZIP file, and the hash value of the ZIP file.

[0068] Step S7: Invoke the on-chain smart contract to upload the transaction data encrypted using cryptographic envelope technology to the blockchain.

[0069] Develop a standardized smart contract for storing encrypted transaction data on the blockchain. The underlying logic code calls this smart contract to store the encrypted transaction data on the blockchain.

[0070] Step S8: The callback source requests the on-chain feedback interface of the on-chain business system, providing feedback information such as the on-chain transaction hash value and the password of the password envelope; it also supports pushing feedback data via SMS, WeChat, email, etc., and the on-chain process is complete.

[0071] According to one embodiment of the present invention, the business system that needs to connect to the on-chain application interface needs to implement the corresponding on-chain feedback interface and provide the feedback interface address, which is maintained in the underlying configuration table of the present invention.

[0072] After a smart contract call to the blockchain is successful, the system automatically calls back to the feedback interface address of the corresponding blockchain application system. The feedback interface then sends the transaction's primary key ID or unique document number, the blockchain transaction hash value, and the password in the password envelope to the original blockchain application system. Optional push notifications via SMS, WeChat, and email are also supported.

[0073] Step S9: The business system inputs the on-chain transaction hash and the password envelope password, and calls the transaction data viewing API.

[0074] Provide an API for viewing off-chain transaction data, which business systems can call to obtain the final decrypted, complete on-chain transaction data.

[0075] It should be noted that, as Figure 3 As shown, this step marks the beginning of viewing transaction data on-chain. The data access interface provided by this invention verifies the hash value of the on-chain transaction and the password in the password envelope; if the verification fails, an error message is returned.

[0076] Step S10: Call the off-chain smart contract to obtain the encrypted transaction data on the chain.

[0077] Develop a standardized, universal smart contract for off-chain transaction data. This smart contract is invoked by passing the on-chain transaction hash value as a parameter to the underlying logic code, thereby obtaining the original on-chain transaction data record encrypted using cryptographic envelope technology.

[0078] Step S11: Use the envelope password to automatically decrypt the password envelope and obtain the decrypted on-chain transaction data.

[0079] The backend of the central server cluster decrypts the encrypted transaction data sent to the blockchain in step S10 based on the password envelope passed to the data viewing interface API in step S9.

[0080] The API response message for viewing transaction data off-chain will provide the decrypted on-chain transaction data to the business system that requested the off-chain request. The decrypted transaction data includes: basic transaction information, the FileID of the encrypted and compressed ZIP file of the original electronic voucher, the access password for the evidence file, the decompression password for the ZIP file, and the hash value of the ZIP file. Steps S9 to S11 form a closed-loop call for an off-chain request.

[0081] Step S12: Use the FileID of the transaction evidence ZIP file and the file access password to call the download interface of the distributed file evidence system to obtain the ZIP compressed file.

[0082] The distributed file evidence storage system module provides an interface for downloading evidence storage files. The caller needs to pass in the correctly matched FileID of the evidence storage ZIP file and the file access password to download the encrypted and compressed ZIP file of the original electronic certificate of the transaction.

[0083] The distributed file evidence storage system module of the present invention also provides a ZIP file hash verification function, which is used to calculate the ZIP file hash value so as to compare it with the file hash value stored on the blockchain, thereby ensuring that the ZIP file is authentic, valid and has not been tampered with.

[0084] Step S13: Use the decompression password to decompress the ZIP compressed file and obtain the original transaction electronic voucher attachment.

[0085] The ZIP file downloaded from the distributed file storage system module is an encrypted compressed package. It needs to be decompressed using the decompression password generated in step S4 of the data uplink process and obtained in step S11 of the downlink process to obtain the original transaction electronic certificate attachment.

[0086] The distributed document storage system module of the present invention also provides a document signature verification function to verify the authenticity and credibility of the original electronic transaction certificate attachments.

[0087] This invention aims to provide a method and apparatus for implementing trusted applications based on blockchain transactions, creating an online transaction digital trust system. By combining multi-party consensus of "initiation-rights confirmation-proof storage", symmetric / asymmetric encryption algorithms, digital signature verification, cryptographic envelopes, anti-tampering features, etc., a third-party transaction authentication service platform is constructed to form an online transaction digital trust system.

[0088] This invention extends the original blockchain consensus mechanism by introducing a secondary confirmation mechanism before on-chain verification, which first confirms rights and then stores evidence on the chain.

[0089] This invention implements a novel on-chain mechanism based on multi-party consensus, encompassing "initiation-rights confirmation-proofing." It extends the existing blockchain consensus on-chain mechanism by introducing a secondary confirmation mechanism before on-chain storage, confirming rights before storing evidence, effectively avoiding the complex issues of potentially invalid or erroneous transaction data being uploaded to the blockchain in real-world business scenarios. According to the embodiment, the combination of a secure and reliable dedicated distributed file evidence storage system and cryptographic envelope technology effectively solves the practical problem of large files being unsuitable for direct on-chain storage, while also achieving effective protection of sensitive information and privacy data in on-chain transactions. Ultimately, this forms a complete solution for an online transaction digital trust system.

[0090] This invention constructs a secure and reliable dedicated distributed file storage system: providing a series of standard interfaces for file signature verification, ZIP file upload, ZIP file download, and ZIP file hash verification; after the original electronic voucher file of a transaction passes signature verification, it is encrypted and compressed into a ZIP format and uploaded to the distributed file storage system for storage, and a random and unique ZIP file FileID, file access password, and original electronic voucher file decompression password are returned; the encrypted and compressed ZIP file must be downloaded by calling the download interface using the ZIP file FileID and file access password; and users need to use the decompression password to decompress the ZIP file in order to view the original electronic voucher file, thus realizing a multi-layered protection mechanism for transaction attachments.

[0091] This invention ensures that before transaction data is uploaded to the blockchain, multiple parties involved in the transaction confirm their rights, and then the data is stored and uploaded to the blockchain. The original electronic voucher attachments involved in the transaction are encrypted and compressed into ZIP format and stored in a dedicated distributed file storage system. The ZIP file's FileID, file access password, original electronic voucher file decompression password, file digest, and file anti-tampering hash value, along with the basic transaction information, are encrypted together using cryptographic envelope technology before being uploaded to the blockchain. This solves the problem of large attachments being unsuitable for direct blockchain storage, fully and rationally utilizes blockchain technology to address file security and trust issues, and uses cryptographic envelopes to protect sensitive information and privacy data in on-chain transactions.

[0092] This invention discloses a blockchain-based trusted application implementation method that solves the technical problems of trust, data security, and data privacy in multi-party transactions. The invention implements a novel consensus mechanism where each transaction requires joint confirmation of rights by all parties involved before being recorded on the blockchain, ensuring the accuracy, authenticity, and reliability of the recorded transaction data. This significantly alleviates and reduces various problems caused by the recording of invalid or erroneous data during actual business operations. The invention also implements a secure, reliable, and protected distributed file storage system for encrypting and storing electronic voucher attachments related to transaction documents. Through a defined API interface, a ZIP file FileID and file access password are provided for downloading the stored file; a decompression password is required to decompress the ZIP file and view the original electronic voucher attachment content; and file hash verification and signature verification functions are provided to ensure the authenticity and reliability of the files. This invention implements multiple security protection mechanisms for transaction-related attachments, using cryptographic envelopes to protect sensitive transaction information and private data, thereby achieving the goal of ensuring that transaction information is only publicly shared among a limited number of collaborating parties.

Claims

1. A method for implementing a trusted application based on blockchain transactions, characterized in that: Includes the following steps: Step 1: Set up a central server cluster and deploy an interface for applying to upload transaction data to the blockchain within the central server cluster. The interface is used to receive and verify applications to upload transaction data to the blockchain submitted by the business system. Step 2: A data caching module is set up in the central server cluster. The data caching module caches transaction data, generates multiple random passwords for each party's user based on the transaction data, and sends the authorization link and random passwords to each party involved in the transaction. Step 3: All users open the received confirmation link, view the on-chain content, enter a random password, and complete the secondary confirmation of transaction rights; After all collaborating users involved in the transaction have entered the correct random password to complete the secondary confirmation, the central server cluster calls a unified standard on-chain smart contract to encrypt the transaction data using cryptographic envelope technology before uploading it to the blockchain; if any user fails to complete the confirmation of rights, the transaction data will not be uploaded to the blockchain. Step 4: After the transaction data is successfully uploaded to the blockchain, the corresponding receiving interface provided by the business system requesting the blockchain upload is used to send the blockchain transaction hash and the password of the password envelope back to the original business system that requested the blockchain upload. At the same time, the central server cluster sends the password of the envelope to all users involved in the transaction, ensuring that the blockchain transaction hash and password of the password envelope are only spread within a limited range of the parties involved in the transaction. When parties to a transaction want to view the complete on-chain transaction information, they must pass the correct on-chain transaction hash value and password envelope password through the interface, and call the unified standard off-chain smart contract in order to obtain the decrypted transaction data from the chain.

2. The method for implementing a trusted application based on blockchain transactions as described in claim 1, characterized in that: The transaction data includes user information of all parties involved in the transaction, transaction details, and related signed original electronic voucher attachments.

3. The method for implementing a trusted application based on blockchain transactions as described in claim 1, characterized in that: The central server cluster integrates a third-party distributed framework, which is used to build a distributed file storage system. It restricts access permissions through multiple levels, including network policies, service configurations, and application APIs, limiting I / O access to only the interfaces provided by the central server cluster.

4. The method for implementing a trusted application based on blockchain transactions as described in claim 3, characterized in that: When performing steps 2 and 3, a distributed file storage system is built in the central server cluster, which provides standard file signature verification interface, ZIP file upload interface, ZIP file download interface and ZIP file hash verification interface. After the original electronic voucher file is signed and verified, it is encrypted, compressed into ZIP format, and uploaded to the distributed file storage system for storage. The system also returns a random and unique ZIP file FileID, file access password, and original electronic voucher file decompression password. The encrypted and compressed ZIP file must be downloaded by calling the download interface using the ZIP file's FileID and file access password. Furthermore, users need to use the decompression password to decompress the ZIP file in order to view the original electronic certificate file.

5. The method for implementing a trusted application based on blockchain transactions as described in claim 4, characterized in that: In step 3, the basic transaction information, ZIP file FileID, file access password, original electronic certificate file decompression password, file digest, and file anti-tampering hash value are encrypted using cryptographic envelope technology and then uploaded to the blockchain.

6. The method for implementing a trusted application based on blockchain transactions as described in claim 3, characterized in that: When applying for the transaction data upload to the blockchain, the application interface supports uploading and sending multiple attachments. The requester needs to sign each attachment using a private key. After receiving the transaction data, the data caching module verifies the signature of the uploaded attachments using the requester's public key. After the rights of all parties involved in the transaction are confirmed, a pre-set decompression password is randomly generated, and multiple attachments associated with the transaction are encrypted and compressed into a ZIP file.

7. The method for implementing a trusted application based on blockchain transactions as described in claim 3, characterized in that: In step 4, the API of the distributed file storage system is called to download the compressed transaction certificate attachment ZIP package using the FileID and file access password included in the decrypted transaction record; the original electronic certificate file decompression password obtained on the chain is used to decompress the ZIP package, thereby viewing the original transaction electronic certificate attachment.

Images