CN114979244B - Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture - Google Patents

Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture Download PDF

Info

Publication number
CN114979244B
CN114979244B CN202210475744.3A CN202210475744A CN114979244B CN 114979244 B CN114979244 B CN 114979244B CN 202210475744 A CN202210475744 A CN 202210475744A CN 114979244 B CN114979244 B CN 114979244B
Authority
CN
China
Prior art keywords
chain
transaction
transfer
user
layer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210475744.3A
Other languages
Chinese (zh)
Other versions
CN114979244A (en
Inventor
冷静文
李照冬
过敏意
陈�全
李超
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Jiaotong University
Original Assignee
Shanghai Jiaotong University
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Jiaotong University filed Critical Shanghai Jiaotong University
Priority to CN202210475744.3A priority Critical patent/CN114979244B/en
Publication of CN114979244A publication Critical patent/CN114979244A/en
Application granted granted Critical
Publication of CN114979244B publication Critical patent/CN114979244B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The invention provides a hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture, which comprises the following components: the application layer presents information of the blockchain transaction to the user through a front-end page; the SDK layer is used for providing a chain code function call interface; the chain code layer is used for expanding the hash time locking interface; the chain code API layer is used for configuring a native chain code API and a cryptography primitive API; the application layer, the SDK layer, the chain code layer and the chain code API layer cooperate and interact to realize: asset locking is achieved in a transfer mode at each HTLC cross-chain transaction; after the account book is submitted to the transfer in the asset locking stage, the content of the account book is verified; after the HTLC cross-chain transaction is completed, a range proof of the balance of the user is generated for the supervisor to audit the validity of the transfer based on the range proof of the balance of the user. The invention combines HTLC and cryptography technology, which not only can realize cross-chain transaction, but also can realize privacy protection and supervision of transaction.

Description

Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture
Technical Field
The invention relates to the technical field of blockchain, in particular to the technical field of blockchain multi-chain transaction.
Background
With the deep development and wide application of the blockchain technology, the requirements of blockchain cross chains are increasing, and the problems of blockchain privacy disclosure and the necessity of privacy protection are also attracting more attention along with the development of the blockchain technology. How to design a scheme of trusted transaction in a multi-chain transaction scene, support to establish a mutual trust mechanism in the multi-chain transaction environment, and realize abnormal transaction supervision and transaction data security protection is a subject to be researched urgently.
The existing blockchain multi-chain transaction solution mainly has two problems: on one hand, the schemes lack privacy protection on transaction data, so that business data or enterprise secrets are easy to reveal, and the rights and interests of transaction participants are damaged; on the other hand, the schemes neglect the trust problem in the transaction process, lack of reasonable supervision on the transaction process, and enable the malicious user to be unable to carry out effective identity tracing and accountability when the malicious user initiates wrong transaction behavior.
One solution in the prior art is based on a basic hash time locking contract (Hashed Time Lock Contract, HTLC), which is an intelligent contract for cross-chain asset exchange transaction, which constructs the relationship of mutual restriction and cross dependence between transaction parties through a hash lock and a time lock, realizes cross-chain business interaction and ensures the atomicity of the cross-chain transaction, but lacks privacy protection on transaction data and cannot supervise the cross-chain transaction.
Another solution of the prior art is blockchain privacy protection technology represented by cryptocurrency such as door currencies. The technology mainly conceals the identities of a transaction sender and a transaction receiver through a cryptography technology and conceals the transaction amount. But this technique is not suitable for cross-chain transactions and lacks transaction policing functionality.
Disclosure of Invention
In view of the above-mentioned drawbacks of the prior art, an object of the present invention is to provide a multi-chain trusted transaction BaaS service platform architecture based on a hash time locking protocol, which can implement both cross-chain transactions and privacy protection and supervision of cross-chain transactions.
To achieve the above and other related objects, the present invention provides a hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture, comprising: the application layer is an application program of the user and presents information of the blockchain transaction to the user through a front-end page; the SDK layer is used for providing a chain code function call interface for the user application program and the blockchain network, so that the application program accesses the blockchain network through the SDK layer, calls the chain code and obtains a chain code execution result; the chain code layer is used for expanding the hash time locking interface and adding a calling flow of the cryptographic primitive API; the chain code API layer is used for configuring a native chain code API and a cryptography primitive API; the application layer, the SDK layer, the chain code layer and the chain code API layer cooperate and interact to realize: asset locking is achieved in a transfer mode at each HTLC cross-chain transaction; after the account book is submitted to the transfer, verifying the content of the account book; after the HTLC cross-chain transaction is completed, generating a range proof of the balance of the user for the supervisor to audit the validity of the transfer based on the range proof of the balance of the user.
In one embodiment of the invention, the effecting asset locking in a transfer manner comprises: in the present asset locking phase, the sender of the in-chain asset directly transfers the receiver.
In an embodiment of the invention, the implementing asset locking by transfer further includes: in the asset unlocking phase, the receiver confirms the transfer in the asset locking phase to determine whether the sender correctly completes the transfer.
In one embodiment of the invention, the transfer conceals transaction participants.
In one embodiment of the present invention, after the transfer in the asset locking phase is submitted to the ledger, the verification of the contents of the ledger comprises: in the HTLC cross-chain process, a chain code method Lock is called to Lock the asset; calling a cryptographic primitive API ZkPutState for calculating promise and tokens, and adding transfer transaction ciphertext into an account book; and calling a cryptography primitive API ZkVerifyOne for verifying the transfer transaction ciphertext, and verifying the transfer transaction ciphertext on the account book so as to ensure the correctness of the transfer transaction ciphertext.
In one embodiment of the invention, the adding the transfer transaction to the ledger includes: in the HTLC cross-chain process, each transaction node adds the transfer transaction in a local ledger.
In one embodiment of the present invention, after adding the transfer transaction to the ledger, further comprising: the ledger issues notifications to the user application to cause the user application to automatically invoke the cryptographic primitive API ZkVerifyOne to respond to the notifications.
In one embodiment of the present invention, the generating the range certificate of the balance of the user for the supervisor to audit the validity of the transfer based on the range certificate of the balance of the user after the HTLC cross-chain transaction is completed comprises: after HTLC cross-chain transaction is completed, a chain code method Withdraw is called to unlock the asset; after each user receives the supervision notice of the supervision party, the cryptographic primitive API ZkAudio is called, the current balance range evidence and the extraction evidence of the expenditure party are generated, the transaction amount range evidence and the extraction evidence of other parties are generated, and the supervision party can audit the validity of the transfer ciphertext based on the balance range evidence of each user.
In one embodiment of the invention, the transfer is recorded in the form of a two-dimensional ledger of two dimensions { trade, organization }; initializing balance of each organization in a promised form by a first line in the two-dimensional account book, and recording ciphertext information of one transfer by each other line; each column in the two-dimensional ledger records corresponding transaction information organized in the transfer.
In one embodiment of the invention, the supervisor invokes the cryptographic primitive API ZkVerifyTwo to audit the validity of the transfer.
In an embodiment of the present invention, the chain code method Lock and the chain code method Withdraw are configured in a chain code layer; the cryptographic primitive API ZkPutState, the cryptographic primitive API ZkVerifyOne, the cryptographic primitive API ZkVerifytwo, the cryptographic primitive API ZkAudit is configured in the chain code API layer.
To achieve the above and other related objects, the present invention also provides an electronic device including a memory for storing a computer program; a processor for running the computer program to implement a hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture as described above.
As described above, the hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture of the present invention has the following beneficial effects:
the invention innovates on the basic HTLC, combines the HTLC with the cryptography technology, encrypts the transaction content in the blockchain cross-chain transaction process, conceals the identity of the transaction participants and effectively supervises the transaction content, establishes a mutual trust mechanism in a multi-chain transaction environment, not only realizes the cross-chain transaction, but also realizes the privacy protection and supervision of the transaction, and realizes the abnormal transaction supervision and the safety protection of transaction data.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a diagram of a multi-chain trusted transaction BaaS service platform architecture based on a hash time-locking protocol in one embodiment of the present application;
FIG. 2 is a cross-chain transaction flow diagram of a hash time locking contract underlying a hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture in the prior art;
fig. 3 is a schematic diagram of a specific implementation process of a multi-chain trusted transaction BaaS service platform architecture based on a hash time locking protocol according to an embodiment of the present application.
Detailed Description
Other advantages and effects of the present invention will become apparent to those skilled in the art from the following disclosure, which describes the embodiments of the present invention with reference to specific examples. The invention may be practiced or carried out in other embodiments that depart from the specific details, and the details of the present description may be modified or varied from the spirit and scope of the present invention. It should be noted that the following embodiments and features in the embodiments may be combined with each other without conflict.
Aiming at the current increasing blockchain cross-chain demand and transaction privacy protection demand, the embodiment aims to provide a multi-chain trusted transaction BaaS service platform architecture based on a hash time locking protocol, which not only can realize cross-chain transaction, but also can realize privacy protection and supervision of the cross-chain transaction.
The embodiment realizes the privacy protection and supervision of the cross-chain transaction through the cryptography technology. According to the embodiment, a single asset exchange cross-chain transaction is split into two asset transfer chain internal sub-transactions, asset locking in a hash time locking protocol is realized by adopting a direct transfer mode, and atomicity of the cross-chain transaction is ensured through cooperation of a Haxi lock and a time lock; in addition, the present embodiment uses cryptography techniques to ensure privacy and manageability of in-chain transfers: the method comprises the steps of hiding contents in a cross-chain transaction by using a Pedersen promise based on an elliptic curve, recording transaction ciphertexts of all members by using an account book in a two-dimensional form to confuse identities of transaction participants, and verifying the transaction ciphertexts by using a zero knowledge proof technology to ensure validity of the transaction.
The principle and implementation of the hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture of the present invention will be described in detail below, so that those skilled in the art can understand the hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture of the present invention without creative effort.
Example 1
As shown in fig. 1, the present embodiment provides a multi-chain trusted transaction BaaS service platform architecture based on a hash time locking protocol, which includes: the application layer is an application program of the user and presents information of the blockchain transaction to the user through a front-end page; the SDK layer is used for providing a chain code function call interface for the user application program and the blockchain network, so that the application program accesses the blockchain network through the SDK layer, calls the chain code and obtains a chain code execution result; the chain code layer is used for expanding the hash time locking interface and adding a calling flow of the cryptographic primitive API; the chain code API layer is used for configuring a native chain code API and a cryptography primitive API; the application layer, the SDK layer, the chain code layer and the chain code API layer cooperate and interact to realize:
asset locking is achieved in a transfer mode at each HTLC cross-chain transaction; after the account book is submitted to the transfer, verifying the content of the account book; after the HTLC cross-chain transaction is completed, generating a range proof of the balance of the user for the supervisor to audit the validity of the transfer based on the range proof of the balance of the user.
Fig. 1 is a diagram of a multi-chain trusted transaction BaaS service platform architecture based on a hash time locking protocol, and the architecture is divided into 4 layers: an application layer, an SDK layer, a chain code layer and a chain code API layer.
1) Application layer: the layer is a user application program, and the layer presents detailed information of the user blockchain transaction to the user through a front-end page.
2) SDK layer: the layer is an interface for the user application program to interact with the blockchain network, and the user application program can access the blockchain network, call the chain code and acquire the execution result of the chain code through the SDK layer.
3) Chain code layer: the layer is an intelligent contract layer in the blockchain network, and a user can write business transaction logic required by intelligent contract realization. In the embodiment, a basic hash time locking contract is expanded at the layer, and a call flow for a cryptographic primitive API is added.
4) Chain code API layer: the layer includes a native chain code API and a cryptographic primitive API.
The native chain code API is a native API provided by the blockchain platform Fabric for a user to write intelligent contracts, and comprises common APIs such as a PutState interface for writing an account book, a GetState interface for reading the account book and the like.
The cryptographic primitive API is a part added outside the native chain code API in this embodiment, and is used to calculate cryptographic primitives such as homomorphic promise and zero knowledge proof, so as to encrypt and verify the account transaction content. The cryptographic primitive API includes ZkPutState for calculating the petersen commitment and token, zkuudit for generating a range proof of the current balance (transaction amount) of the spending party (other party), and a disjunctive proof, zkuverifyone for constructing a zero knowledge proof using the petersen commitment and token to verify the transaction ciphertext using the range proof and disjunctive proof, zkuverifytwo.
1. The application layer calls Lock of the chain code layer through the SDK, and the Lock calls ZkPutState of the chain code API layer to complete asset locking in a transfer mode;
2. after the transfer in the asset locking stage is submitted to an account book, the account book informs an SDK, and the SDK calls a ZkVerifyOne of a chain code API layer to verify the account book content;
3. after HTLC cross-chain transaction is completed, the application layer generates a range proof through the ZKAudit of the SDK calling chain code API layer, and the supervisor completes audit through the ZkVerifyTwo verification range proof of the SDK calling chain code API layer.
The following describes the multi-chain trusted transaction BaaS service platform architecture based on the hash time locking protocol in detail.
In this embodiment, asset locking is achieved in a transfer manner each time an HTLC cross-chain transaction occurs.
Fig. 2 is an original cross-chain transaction flow of HTLC, which is essentially a smart contract-based time-limited payment mechanism. It is mainly composed of two parts:
1) Ha Xisuo: the Hash lock is a pair of Hash original images R and a Hash value H, and satisfies H=hash (R); the asset may be locked using a hash value and the locked asset may only be unlocked using the original image to which the hash value corresponds.
2) Time lock: the time lock is the maximum time limit T allowed by unlocking the locked asset, and if the locked asset cannot be unlocked by using the correct original image R within the specified time limit, the locked asset is automatically unlocked and returned to the locking party.
The Haxi lock and the time lock construct double guarantee of the cross-chain transaction, so that an asset sender and a receiver are in a mutually restricted relation when in transaction, all occurrence or non-occurrence of sub-transactions in the cross-chain transaction are ensured, and the atomicity of the whole cross-chain transaction is finally realized; and the whole cross-chain process does not need trusted third party participation, and only needs to be carried out by both transaction parties.
Fig. 2 is a theoretical description of HTLC cross-chain flow, but when an actual asset interaction scheme is constructed, a certain improvement needs to be made on the original HTLC cross-chain scheme to ensure the practicability and safety of the scheme.
The improvement of the original HTLC cross-chain flow in the embodiment is mainly in two aspects: on one hand, the embodiment realizes HTLC in a one-step transfer mode, and reduces accounting times as much as possible while ensuring the atomicity of cross-chain transactions; on the other hand, the embodiment combines the HTLC cross-chain process with the cryptographic primitive API in the chain code API layer, and realizes encrypting the transaction content, hiding the identity of the transaction participant and effectively supervising the transaction content in the blockchain cross-chain transaction process by calling the cryptographic primitive API in the HTLC cross-chain process.
Specifically, in the present embodiment, the implementing asset locking by way of transfer includes: in the asset locking stage, the sender of the on-chain asset directly transfers accounts to the receiver, and simultaneously stores Ha Xisuo H and a time lock T in an account book; in the asset unlocking stage, the receiving party confirms the transfer in the asset locking stage by using the hash image R, on one hand, the receiving party determines whether the transfer is correctly completed in the asset locking stage or not, and on the other hand, the receiving party determines whether the receiving party provides the hash image R paired with the hash value H or not in a specified time.
That is, in the present embodiment, the manner of "one-step transfer" is adopted. In the asset locking phase of this embodiment, the sender of the on-chain asset directly transfers the receiver; in the asset unlocking stage, the receiver only needs to confirm the transfer in the asset locking stage to determine whether the sender correctly completes the transfer, the whole cross-chain process does not need intermediate accounts to transfer the asset, 2 transfers are needed, and the fewer transfer times can effectively reduce the additional cost introduced by the follow-up single transfer privacy protection through the cryptology primitive.
In this embodiment, the transfer hides the transaction participants, and the transfer is recorded in the form of a two-dimensional account book of { transaction, organization }; initializing balance of each organization in a promised form by a first line in the two-dimensional account book, and recording ciphertext information of one transfer by each other line; each column in the two-dimensional ledger records corresponding transaction information organized in the transfer.
I.e., the present embodiment transfers are recorded in two dimensions { trade, organization }. Table 1 shows a two-dimensional ledger structure adopted in the present embodiment, which is called a two-dimensional ledger.
TABLE 1
Wherein r is ij Is the random number that is input when calculating the commitment and token for the j-th organization in the i-th transaction.
As shown in table 1, the first line (transaction ID 0) in the ledger initializes the balance of each organization in the form of petersen commitment, and each remaining line records ciphertext information of one transfer, wherein the petersen commitment is used to hide a specific transaction amount in the transfer, and cryptographic primitives such as tokens, scope certificates, extraction certificates and the like are used to realize verification and supervision of the transfer; each column in the ledger records the corresponding transaction information organized in the transfer, all columns in the two-dimensional ledger cover all organizations in the blockchain network, so that each transfer record needs to generate corresponding cryptography primitives (Pedersen promise, tokens, scope certificates, disjunctive certificates and the like) for all organizations, which introduces a certain computational expense, but hides the transaction participants, namely, can not know which organizations participate in a transfer by observing the information in the ledger.
The two-dimensional ledger stores cryptographic primitives corresponding to each organization in each transaction, which can be used to construct zero knowledge proofs to verify transfer information on the ledger. Table 2 shows the zero knowledge proof involved in this example.
TABLE 2
The cryptographic primitive APIs employed in this embodiment are shown in table 3, and this part of the APIs are in the chain code API layer. The cryptographic primitive API can implement privacy protection and supervision on single-chain transfer transactions, but is not applicable to a multi-chain transaction environment, and the present embodiment compensates for this drawback by combining the cryptographic primitive API with HTLC cross-chain flow.
TABLE 3 cryptographic API
The chain code API in Table 3 may enable privacy protection and transaction supervision of single chain internal transfers. When transfer occurs, the payoff party calls ZkPutState, calculates petersen commitments, tokens for each organization, and saves to the ledger. For example, organization 1 is an asset spending party, organization 2 and organization 4 are asset recipients, in transaction 1, organization 1 transfers 20 assets to organization 2, and 50 assets to organization 4; organization 1 calls ZkPutState to record the transfer in the ledger, calculates petersen commitment and tokens for itself and organization 2, organization 3, organization 4, respectively, and for the organization participating in the transaction (organization 1, organization 2, organization 4), the value of the commitment is equal to the transaction amount; for the transaction independent party (organization 3), the committed value is 0. After the ZkPutState is called by the organization 1 and flows such as sequencing, submitting and the like of the Fabric bottom layer, the account book copies of nodes of each organization record the transfer, at the moment, each organization can call ZkVerifyOne, and the balance verification and the promise correctness verification of the money amount of the transfer are completed according to Pedersen promise and tokens in the account book copies. When the supervisor needs to supervise the transfer, organization 1 needs to call ZkAudio as the expenditure party, generate a range proof and a disjunct proof of the transfer for each organization, and generate a range proof of balance, namely an asset proof in table 2, for the expenditure party (organization 1); for the other organizations (organization 2, organization 3, organization 4), a range proof of transaction amount is generated, i.e. the amount proof in table 2; the disjunctive proof is used for ensuring that the input of the generated range proof is correct, namely, the input is consistent with the promise recorded on the account book, and the spending party is prevented from using a false value to generate the range proof to deceive the supervisor; after the scope proof and the disjunctive proof are saved to the ledger, the supervisor or other organization may invoke the zkverifywwo to verify the scope proof and disjunctive proof.
As described above, the chain code API in table 3 may implement privacy protection and supervision of single-chain internal transfer, and in this embodiment, the chain code API in table 3 is combined with the hash time locking protocol, thereby further implementing privacy protection and supervision of cross-chain transactions.
Combining the HTLC cross-chain flow with the cryptographic primitive APIs in the chain code API layer is specifically described below in connection with fig. 3 by invoking the cryptographic primitive APIs in the HTLC cross-chain flow. The flow of the black bold line part in fig. 3 is an implementation of the original HTLC at the chain code layer, which is the core part in the HTLC cross-chain flow, which guarantees the atomicity of the cross-chain transaction. The gray part of the flow is the cryptographic primitive API call flow of the chain code API layer added in the embodiment based on the original HTLC, and the privacy protection and supervision of the whole cross-chain transaction are realized by performing privacy protection and supervision on the single-chain transfer in the asset locking stage. In HTLC cross-chain flow, cryptographic primitive APIs are invoked mainly in three phases: the first stage is when the user calls Lock to complete asset locking, the second stage is after the user calls Lock to complete asset locking, and the third stage is after the user calls Withdraw to complete asset unlocking.
In this embodiment, asset locking is achieved in a transfer manner each time an HTLC cross-chain transaction occurs.
In this embodiment, the implementing asset locking by way of transfer at each HTLC cross-chain transaction includes: and calling a chain code method Lock to Lock the asset, calling a lower-layer cryptographic primitive API ZkPutState in the chain code method Lock, and adding transfer transaction in an account book.
In this embodiment, after the transfer is submitted to the ledger, the content of the ledger is verified.
In this embodiment, after the transfer in the asset locking phase is submitted to the ledger, the verification of the content of the ledger includes: in the HTLC cross-chain process, a chain code method Lock is called to Lock the asset; calling a cryptographic primitive API ZkPutState for calculating promise and tokens in a chain code method Lock, and adding transfer transaction ciphertext in an account book; and calling a cryptography primitive API ZkVerifyOne for verifying the ciphertext of the transfer transaction, and verifying the ciphertext of the transfer transaction on the account book so as to ensure the correctness of the transfer transaction.
Wherein, in this embodiment, the adding the transfer transaction in the ledger includes: in the HTLC cross-chain process, each transaction node adds the transfer transaction in a local ledger.
In this embodiment, after adding the transfer transaction to the ledger, it further includes: the ledger issues notifications to the user application to cause the user application to automatically invoke the cryptographic primitive API ZkVerifyOne to respond to the notifications.
Asset redemption is a common type of cross-chain transaction that refers to the simultaneous alteration of the holders of portions of the assets on both chains, and maintaining the total number of assets on the respective chains unchanged. For example, 1 bitlock that user Alice tries to exchange with 14.5387 ETHs of user Bob (22 nd day at 2022), after the transaction is completed, 1 bitlock originally held by Alice is changed to Bob, and 14.5387 ETHs originally held by Bob are changed to Alice, and the total number of assets on both the Bitcoin and ethernet blockchains does not change due to this asset exchange. It can be seen that the asset redemption includes two sub-transactions, namely, the change of the asset holder on one chain and the change of the asset holder on the other chain, and whether one asset redemption is successful or not depends on whether both sub-transactions can be successfully performed; if the asset holder on one chain is successfully changed while the asset holder on the other chain is unchanged, then both parties involved in the transaction must have one benefit and one is compromised. Therefore, the atomicity of the cross-chain transaction needs to be ensured, namely, the sub transactions on different blockchains either all occur or all do not occur after the cross-chain transaction is completed; if a sub-transaction on one chain is successfully executed and a sub-transaction on the other chain fails, a mechanism is also required to cancel the successfully executed sub-transaction, rolling back the entire system state to the initial state before the start of the cross-chain transaction.
Ensuring atomicity of cross-chain transactions is a great technical difficulty in cross-chain technology. The Hash time locking protocol constructs the relationship of mutual restriction and cross dependence between the two transaction parties, and ensures the atomicity of the cross-chain transaction while realizing the cross-chain service interaction. The embodiment adopts a Lock chain code method for asset locking, and the Lock method directly realizes transfer on one chain by calling ZkPutState; in addition, the Withdraw chain code method is used for unlocking the asset, and logic judgment of the Hash lock and the time lock in the Hash time locking protocol is realized in the Withdraw method so as to determine whether an asset retriever qualifies for retrieving the asset; if not, the stub DelState, the native chain code API, is called to cancel the transfer in the asset lock phase of the ledger.
The Lock, withdraw method is a hash time lock contract (Hashed time lock contract, HTLC) interface, and Audit, verifyOne, verifyTwo is the encapsulation of the corresponding chain code API in table 2 implemented in the chain code of Fabric. The two sides of the cross-chain asset exchange alternately call the chain code methods to complete the whole cross-chain process, as shown in figure 3.
Assuming that user a and user B attempt to complete cross-chain asset redemption through the multi-chain trusted transaction BaaS service platform, user a and user B only need to invoke the chain code method Lock through the flow in fig. 3 through the client application.
Wherein the flow of the black part is the corresponding step of the basic HTLC, and the part ensures the atomicity of the cross-chain transaction; the gray part of the flow is the cryptographic primitive API call flow of the chain code API layer added in the embodiment based on the original HTLC, and the privacy protection and supervision of the whole cross-chain transaction are realized by performing privacy protection and supervision on the single-chain transfer in the asset locking stage.
As shown in fig. 3, after the user invokes Lock to complete the asset Lock, user a and user B respectively invoke ZkVerifyOne. Taking the example that the user A calls the Lock method, the Lock method calls ZkPutState, one transfer transaction is added in the account book of the local node of the user A, and other nodes in the system can add the transfer transaction in the local account books through the consensus process so as to ensure the global consistency of the account books; the account book sends a notification to a user application program after the account book is added to the account book, the user application program can automatically call ZkVerifyOne to respond to the notification, and ZkVerifyOne can verify the ciphertext of the account book to ensure the correctness of the account transfer. Taking fig. 3 as an example, after the user B invokes Lock to Lock the asset, the local account book copy of the user a will add the corresponding transfer record, and meanwhile, the account book sends notification to the respective clients, and after the clients of the user a receive the notification, the clients invoke ZkVerifyOne to complete verification of the transfer.
In this embodiment, after the HTLC cross-chain transaction is completed, a range proof of the user's balance is generated for the supervisor to audit the validity of the transfer based on the range proof of the user's balance.
Specifically, in this embodiment, the generating, after the HTLC cross-chain transaction is completed, the range certificate of the balance of the user, so that the supervisor can audit the validity of the transfer based on the range certificate of the balance of the user, includes: after HTLC cross-chain transaction is completed, a chain code method Withdraw is called to unlock the asset; after each user receives the supervision notice of the supervision party, the cryptographic primitive API ZkAudio is called, the range evidence and the disjunct evidence of the current balance of the expenditure party are generated, the range evidence and the disjunct evidence of the transaction amount of other parties are generated, and the supervision party can audit the validity of the transfer ciphertext based on the range evidence and the disjunct evidence of each user.
In this embodiment, the supervisor calls the cryptographic primitive API ZkVerifyTwo to audit the validity of the transfer.
Assuming that user a and user B attempt to complete cross-chain asset redemption through the multi-chain trusted transaction BaaS service platform, user a and user B only need to invoke the chain code method widthwart through the flow in fig. 3 through the client application.
As shown in fig. 3, after the user invokes the Withdraw to unlock the asset, the supervision is sent to the user a and the user B, and the user a and the user B respond to the supervision process. When the supervisor tries to audit whether the user A and the user B have enough balances to finish the exchange of the assets, a supervision notice is sent to the user A and the user B; user a and user B need to make the supervisor believe that they have sufficient balances to fulfill the resource redemption without exposing specific balance values, so that user a and user B respectively invoke zkuodit to generate a range proof of the respective balances as a response to the supervision notification; the supervisor judges whether the user A and the user B have enough balances or not by respectively verifying the range certificates generated by the user A and the user B, so as to audit (1) whether the transfer added to the account book in two stages is effective or not; the supervision party monitors the whole cross-chain by respectively auditing two transfers, namely, only if the user A and the user B simultaneously audit by the supervision party, namely (1) when two transfers added to the account book in two stages are simultaneously effective, the whole cross-chain transaction is effective.
In this embodiment, the chain code method Lock and the chain code method Withdraw are configured in a chain code layer; the cryptographic primitive API ZkPutState, the cryptographic primitive API ZkVerifyOne, the cryptographic primitive API ZkAudit is configured in the chain code API layer.
Therefore, in this embodiment, the present embodiment innovates on the basic hash time locking protocol, combines it with the cryptography technology, and encrypts the transaction content, conceals the identity of the transaction participant and effectively manages the transaction content in the blockchain cross-chain transaction process, establishes a mutually trusted mechanism in the multi-chain transaction environment, and realizes abnormal transaction management and security protection of transaction data.
As can be seen from the above, the embodiment forms a multi-chain trusted transaction BaaS service platform architecture based on a hash time locking protocol, the architecture is innovated on the basic hash time locking protocol, and is combined with cryptography technology, and by encrypting transaction contents in a blockchain cross-chain transaction process, hiding identities of transaction participants and effectively supervising the transaction contents, a mutually trusted mechanism is established in a multi-chain transaction environment, so that abnormal transaction supervision and security protection of transaction data are realized.
In summary, the invention innovates on the basic HTLC, combines the HTLC with the cryptography technology, encrypts the transaction content, conceals the identity of the transaction participants and effectively supervises the transaction content in the blockchain cross-chain transaction process, establishes a mutual trust mechanism in a multi-chain transaction environment, not only can realize the cross-chain transaction, but also can realize privacy protection and supervision of the transaction, and realizes abnormal transaction supervision and security protection of transaction data. Therefore, the invention effectively overcomes various defects in the prior art and has high industrial utilization value.
The above embodiments are merely illustrative of the principles of the present invention and its effectiveness, and are not intended to limit the invention. Modifications and variations may be made to the above-described embodiments by those skilled in the art without departing from the spirit and scope of the invention. Accordingly, it is intended that all equivalent modifications and variations of the invention be covered by the claims of this invention, which are within the skill of those skilled in the art, be included within the spirit and scope of this invention.

Claims (10)

1. The utility model provides a hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture which is characterized in that: comprising the following steps:
the application layer is an application program of the user and presents information of the blockchain transaction to the user through a front-end page;
the SDK layer is used for providing a chain code function call interface for the user application program and the blockchain network, so that the application program accesses the blockchain network through the SDK layer, calls the chain code and obtains a chain code execution result;
the chain code layer is used for expanding the hash time locking interface and adding a calling flow of the cryptographic primitive API;
the chain code API layer is used for configuring a native chain code API and a cryptography primitive API;
the application layer, the SDK layer, the chain code layer and the chain code API layer cooperate and interact to realize:
asset locking is achieved in a transfer mode at each HTLC cross-chain transaction;
after the account book is submitted to the transfer, verifying the content of the account book;
after the HTLC cross-chain transaction is completed, generating a range proof of the balance of the user for the supervisor to audit the validity of the transfer based on the range proof of the balance of the user.
2. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 1, wherein: the effecting asset locking in a transfer manner includes:
in the asset locking phase, the sender of the on-chain asset directly transfers the receiver.
3. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 2, wherein: the effecting asset locking in a transfer manner further comprises:
in the asset unlocking phase, the receiver confirms the transfer in the asset locking phase to determine whether the sender correctly completes the transfer.
4. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 3, wherein: the transfer conceals the transaction participants.
5. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 1, wherein: after the transfer in the asset locking stage is submitted to an account book, the content verification of the account book comprises the following steps:
in the HTLC cross-chain process, a chain code method Lock is called to Lock the asset;
calling a cryptographic primitive API ZkPutState for calculating promise and tokens in a chain code method Lock, and adding transfer transaction ciphertext in an account book;
and calling a cryptography primitive API ZkVerifyOne for verifying the ciphertext of the transfer transaction, and verifying the ciphertext of the transfer transaction on the account book so as to ensure the correctness of the transfer transaction.
6. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 5, wherein: after adding the transfer transaction in the ledger, further comprising: the ledger issues notifications to the user application to cause the user application to automatically invoke the cryptographic primitive API ZkVerifyOne to respond to the notifications.
7. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 5, wherein: after the HTLC cross-chain transaction is completed, generating a range proof of the balance of the user for the supervisor to audit the validity of the transfer based on the range proof of the balance of the user, including:
after HTLC cross-chain transaction is completed, a chain code method Withdraw is called to unlock the asset;
after each user receives the supervision notice of the supervision party, the cryptographic primitive API ZkAudio is called, and a transaction balance range proof and a disjunctive proof are generated so that the supervision party can audit the validity of the transfer ciphertext based on the balance range proof of each user.
8. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of any one of claims 2 to 7, wherein: the transfer is recorded in the form of a two-dimensional account book of two dimensions { trade, organization }; initializing balance of each organization in a promised form by a first line in the two-dimensional account book, and recording ciphertext information of one transfer by each other line; each column in the two-dimensional ledger records corresponding transaction information organized in the transfer.
9. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 7, wherein: the supervisor calls the cryptographic primitive API ZkVerifyTwo to audit the validity of the transfer.
10. The hash time locking protocol based multi-chain trusted transaction BaaS service platform architecture of claim 7, wherein: the chain code method Lock and the chain code method Withdraw are configured on a chain code layer; the cryptographic primitive API ZkPutState, the cryptographic primitive API ZkVerifyOne, the cryptographic primitive API zkverifywwo, and the cryptographic primitive API zkaudiot are configured in a chain code API layer.
CN202210475744.3A 2022-04-29 2022-04-29 Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture Active CN114979244B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210475744.3A CN114979244B (en) 2022-04-29 2022-04-29 Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210475744.3A CN114979244B (en) 2022-04-29 2022-04-29 Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture

Publications (2)

Publication Number Publication Date
CN114979244A CN114979244A (en) 2022-08-30
CN114979244B true CN114979244B (en) 2023-12-22

Family

ID=82980027

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210475744.3A Active CN114979244B (en) 2022-04-29 2022-04-29 Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture

Country Status (1)

Country Link
CN (1) CN114979244B (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115801864B (en) * 2022-10-25 2024-06-04 苏州浪潮智能科技有限公司 Method, system, device and storage medium for controlling resource locking time

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108810137A (en) * 2018-06-11 2018-11-13 西安纸贵互联网科技有限公司 A kind of alliance's block catenary system
CN113269545A (en) * 2021-05-26 2021-08-17 杭州云象网络技术有限公司 Hash time locking method and system based on cloud cross-chain transfer protocol
CN113538150A (en) * 2021-07-28 2021-10-22 浙江数秦科技有限公司 Block chain asset cross-chain transaction method
CN114240409A (en) * 2021-10-29 2022-03-25 上海对外经贸大学 Cross-chain asset interaction method based on improved Hash time lock

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG10202006466YA (en) * 2020-07-03 2021-05-28 Alipay Labs Singapore Pte Ltd Managing transactions in multiple blockchain networks
CN114078007A (en) * 2020-08-19 2022-02-22 富泰华工业（深圳）有限公司 Transaction method and device based on block chain and readable storage medium

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108810137A (en) * 2018-06-11 2018-11-13 西安纸贵互联网科技有限公司 A kind of alliance's block catenary system
CN113269545A (en) * 2021-05-26 2021-08-17 杭州云象网络技术有限公司 Hash time locking method and system based on cloud cross-chain transfer protocol
CN113538150A (en) * 2021-07-28 2021-10-22 浙江数秦科技有限公司 Block chain asset cross-chain transaction method
CN114240409A (en) * 2021-10-29 2022-03-25 上海对外经贸大学 Cross-chain asset interaction method based on improved Hash time lock

Also Published As

Publication number Publication date
CN114979244A (en) 2022-08-30

Similar Documents

Publication Publication Date Title
US11429962B2 (en) Recovering encrypted transaction information in blockchain confidential transactions
CN111480315B (en) Computer-implemented systems and methods for authorizing blockchain transactions using low-entropy passwords
JP7116090B2 (en) Computer-implemented system and method for time-release encryption on blockchain networks
Puddu et al. $\mu $ chain: How to Forget without Hard Forks
JP6871380B2 (en) Information protection systems and methods
Bentov et al. How to use bitcoin to design fair protocols
JP6880255B2 (en) Blockchain confidential transaction management
Lee et al. A Survey on Security and Privacy in Blockchain-based Central Bank Digital Currencies.
JP2020517169A (en) Secure blockchain-based consensus
JP2021532466A (en) Computer-enhanced methods, computer systems, and cryptocurrency depository to enable secure escrowing and storage of cryptocurrencies.
Yadav Blockchain security
CN115296838B (en) Block chain-based data sharing method, system and storage medium
US20200204338A1 (en) Securing public key cryptographic algorithms
US20200202349A1 (en) Multiple asset transactions
US20200202344A1 (en) Private asset transactions
CN111523892B (en) Block chain cross-chain transaction method and device
Ingole et al. Blockchain technology in cloud computing: A systematic review
CN114979244B (en) Hash time locking protocol-based multi-chain trusted transaction BaaS service platform architecture
CN115913513A (en) Distributed credible data transaction method, system and device supporting privacy protection
Hoenisch et al. Lightswap: an atomic swap does not require timeouts at both blockchains
Espel et al. Proposal for protocol on a quorum blockchain with zero knowledge
Noam et al. Realizing privacy aspects in blockchain networks
Moreno-Sanchez et al. Silentwhispers: Enforcing security and privacy in decentralized credit networks
CN113656829A (en) Medical data security sharing method based on lattice code and alliance chain
Wadhwa et al. Data Independent Order Policy Enforcement: Limitations and Solutions

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant