CN112396427B - Cross-chain interchange operation method for general scenes - Google Patents
Cross-chain interchange operation method for general scenes Download PDFInfo
- Publication number
- CN112396427B CN112396427B CN202110065638.3A CN202110065638A CN112396427B CN 112396427 B CN112396427 B CN 112396427B CN 202110065638 A CN202110065638 A CN 202110065638A CN 112396427 B CN112396427 B CN 112396427B
- Authority
- CN
- China
- Prior art keywords
- transaction
- chain
- ctx
- contract
- interchange
- 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
Links
- 238000000034 method Methods 0.000 title claims abstract description 112
- 230000007246 mechanism Effects 0.000 claims abstract description 10
- 239000003999 initiator Substances 0.000 claims abstract description 5
- 238000013507 mapping Methods 0.000 claims abstract description 5
- 230000000977 initiatory effect Effects 0.000 claims abstract description 4
- 230000005540 biological transmission Effects 0.000 claims description 37
- 238000012545 processing Methods 0.000 claims description 7
- 238000012795 verification Methods 0.000 claims description 7
- 230000001960 triggered effect Effects 0.000 claims description 6
- 238000004088 simulation Methods 0.000 claims description 4
- 238000004458 analytical method Methods 0.000 claims description 3
- 238000006243 chemical reaction Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 8
- 238000012546 transfer Methods 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 208000033986 Device capturing issue Diseases 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
Images
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/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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- 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/405—Establishing or using transaction specific rules
-
- 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
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Abstract
The invention provides a cross-chain interchange operation method facing a general scene, wherein participants of the cross-chain interchange operation comprise an initiator and a receiver, and related blockchains comprise a sending chain for initiating a request and a receiving chain for receiving the request. According to the invention, a third party responsible for verifying the existence of the transaction and responsible for data format conversion is not required to be introduced between the cross-chain interchange participants, the cross-chain account of the participant and the consensus node of the chain where the participant is located directly verify the existence and the output result of the signature transaction, and the original authority management and consensus mechanism of the sending chain and the receiving chain is followed. The invention is based on the locking, unlocking and executing mechanism of the 'conditional execution' operation established by the mapping relation between the signature transaction and the WorldState world state access, and can enable any contract method under the general scene to be called and participate in cross-chain interchange with the 'conditional execution' operation through the signature transaction.
Description
Technical Field
The invention relates to the technical field of block chain crossing, in particular to a method for realizing multiple-party atomicity cross-chain interchange operation between more than two chains.
Background
A Hash Time locking contract, in English, HTLC (Hash Time Lock Contract), is a cross-link method proposed in a lightning network, which enables two parties participating in a transaction to Lock assets on two different links by using an agreed Hash value on the basis of an intelligent contract, and if the two parties input an original image with a correct Hash value in a specified Time, asset exchange is realized through atomic operation on the two links. The limitations of this approach are: the method is only suitable for a single scene of asset exchange, wherein the methods such as asset locking, unlocking and conditional execution are not suitable for a general scene of any contract method cross-chain interchange operation;
the main limitations and problems of the existing other cross-chain methods include:
1) in the aspect of solving the atomicity of cross-chain interchange operation in a general scene, the existing method requires that a method participating in cross-chain calling can be subjected to 'rollback' or 'inverse operation', and in practical application, most scenes are difficult to meet (for example, a transfer contract method, insufficient balance when the 'rollback' is needed, or a contract method is bound with a delivery behavior under a wire, and the like);
2) in the aspect of solving the problem of block-out certification of the cross-chain operation, a centralized and trusted cross-chain operation existence verifier is introduced, and on the one hand, the access control and consensus mechanism of the chain can be damaged. On the other hand, the verifying party is not a cross-chain interchange participant, and once an unexpected result appears, a tracing mechanism is lacked;
3) when the existing method is used for solving the data exchange between heterogeneous chains, heterogeneous signature transactions, cross-chain requests and the like are converted into an intermediate format through an off-chain adaptation mechanism. Because the cross-chain interchange participants indirectly analyze the operation content through the third party adapter, the security intensity is reduced.
Disclosure of Invention
The present application provides a method for a universal scenario-oriented cross-chain interchange operation to solve one or more of the above-mentioned technical problems,
the technical scheme adopted by the application is as follows:
a cross-chain interchange operation method facing to a general scene is provided, wherein participants of the cross-chain interchange operation comprise an initiator and a receiver, and the block chain comprises a sending chain for initiating a request and a receiving chain for receiving the request;
step 1, deploying a contract rsc containing a contract method participating in an interchanging operation r _ oper in a receiving chain, and deploying a contract ssc containing a contract method participating in an interchanging operation s _ oper in a sending chain;
step 2, a sender and a receiver participating in cross-chain interchange operation respectively register accounts sa and sb on a sending chain, and register accounts ra and rb on a receiving chain; the registered account has the authority to call interchange operation and obtain block data related to the account;
step 3, a retrieval interface for the block data is provided on the receiving chain, transaction retrieval and a transaction block-out certificate are provided for the consensus node on the sending chain, and the consensus node on the sending chain can acquire and verify transaction content and the block-out certificate according to the transaction ID on the receiving chain;
step 4, the registered account sa constructs and submits the transaction ctx of the conditional execution operation in a transmission chain, the execution condition ctx.commit of the transaction ctx is specified as a block of the transaction including the execution operation r _ oper in a receiving chain, the operation ctx.oper to be executed is specified as the execution operation s _ oper, the registered account sb is specified as a receiving party account ctx.receiver, and the unlocking method of the contract csc of the conditional execution transaction by the registered account sb calls the specified unlocking condition ctx.unlock;
and step 5, after the register account sb obtains the transaction ctx block of the conditional execution operation related to the account from the transaction ctx receiving party account ctx.
Further, in step 1, before deploying, in the transmission chain, a contract ssc containing a contract method participating in an interchange operation s _ oper, the method further includes:
data structure definition of the transmit chain: adding an execution condition commit, an unlocking condition unlock, an unlocking block height amplified, a receiving chain ID and a receiving party account receiver in a signature transaction tx data item of a sending chain, wherein when the execution condition commit is not null, the signature transaction tx is a transaction ctx containing a conditional execution operation;
contract container enhancement of the transmit chain: for the transaction ctx of the conditional execution operation, a contract container of a transmission chain is based on a mapping relation between a contract method and world state WorldState read-write operation, and a method for performing simulation pre-execution on transaction sets with mutual influence is adopted to provide locking, unlocking and executing mechanisms for the conditional execution operation;
the contract csc for executing the transaction under the processing condition is deployed in the transmission chain, and specifically comprises the following steps: the contract csc of the conditional execution transaction includes a conditional unlocking method csc.unlock, an overdue unlocking method csc.expire, and an execution method csc.commit for the conditional execution operation.
Further, in step 2, the registering an account has an authority to obtain block data related to the account, which specifically includes:
in the step 2, the registering an account has a right to acquire and complete the interchange operation, which specifically includes:
the registered account has the authority of obtaining the block data of the block chain;
the registered account sa has the right to invoke a contract method to execute an operation s _ oper and a contract csc to invoke the conditional execution transaction through a signature transaction rtx on a transmission chain;
the registered account sb has the right to invoke the contract csc of the conditional execution transaction through the signature transaction rtx on the transmission chain;
the register account ra has the right to execute the operation r _ oper by calling a contract method through the signature transaction rtx on a receiving chain;
wherein the executing operation s _ oper and the executing operation r _ oper are a pair of atomicity interchange operations.
Further, in step 4, the specifying an unlocking condition ctx. unlock specifically includes: when the registered account sb submits an unlocking signature transaction stx _ unlock out block in the send chain, or when the send chain block height extended reaches ctx.
Further, in the step 5, before the receiving side analyzes the cross-chain interchange request and decides whether to accept the interchange request, the method further includes: the sending chain consensus node verifies the authority of the registered account sa on the execution operation s _ oper, a contract container of the sending chain consensus node performs pre-execution to obtain a key value set of a world state WorldState related to the execution operation s _ oper, and associates a transaction ctx of the conditional execution operation with the key value set to complete locking of the execution operation s _ oper, and when a subsequent common signature transaction is performed, an invalid signature transaction out block which causes locking of the execution operation s _ oper is excluded, and the subsequent pre-performed signature transaction comprises the common signature transaction and the conditional execution signature transaction.
Further, in the step 5, the executing the corresponding operation according to the decision result specifically includes:
if the receiver is willing to accept the interchange operation request, the registered account rb constructs and submits a signature transaction rtx _ accept containing the execution operation r _ oper in a receiving chain according to the execution condition ctx.commit of the sender; the receiving chain common identification node verifies the authority of the registered account rb on the execution operation r _ oper, after the verification is passed, a signature transaction rtx is issued, and the execution operation r _ oper is executed;
after the register account rb of the receiver receives the transaction ctx block-out event of the conditional execution operation, a csc.commit method is called through the register account sb on the sending chain and through the signature transaction stx _ commit, the incoming parameters are ctx.txid and rtx.txid, and the conditional execution operation s _ oper in the signature transaction of the sending chain is triggered;
the sending chain common identification node requests transaction content and block-out certification from a receiving chain according to a receiving chain ID (ctx.targetChain) and an incoming parameter rtx.txId, after the transaction content and the block-out certification are obtained, the sending chain common identification node verifies whether a signature transaction rtx _ accept meets ctx.commit requirements, if yes, the signature transaction stx _ commit is carried out, the transaction ctx of the conditional execution operation is removed from the related key value of the transaction ctx of the conditional execution operation, the execution operation s _ oper is executed, and the cross-chain interchange operation is completed.
Further, in the step 5, the executing corresponding operation according to the decision result specifically includes:
and if the receiver does not want to accept the interchange operation request, on the transmission chain, according to an unlocking method ctx. unlock required by the transmitter, constructing and submitting an unlocking signature transaction stx _ unlock through the registered account sb, calling the conditional unlocking method csc. unlock, after the transmission chain consensus node verifies that the block is passed and output, triggering an unlocking operation in the transaction ctx of the conditional execution operation of the transmission chain by a contract container, removing the transaction ctx of the conditional execution operation from the key value related to the transaction ctx of the conditional execution operation to complete unlocking, and canceling the cross-chain interchange operation.
Further, in the step 5, the executing corresponding operation according to the decision result specifically includes:
when the height of the transmission chain block is already reached or exceeds the height of the unlocking block, and the transmission chain does not block any valid signature transaction stx _ commit or unlocking signature transaction stx _ unlock, the receiver is confirmed not to ignore the interchange operation request;
if the receiving party disregards the interchange operation request, the registered account sa constructs and submits a signed transaction stx _ expire, after the signed transaction stx _ expire is verified by the sending chain consensus node, the contract container unlocks the transaction ctx of the conditional execution operation, the transaction ctx of the conditional execution operation is removed from the key value related to the transaction ctx of the conditional execution operation to complete the unlocking, and the cross-chain interchange operation is cancelled;
further, under the condition that the signature transaction rtx _ accept is verified to meet the ctx.commit requirement, when the transmission chain and the reception chain are heterogeneous chains, the transmission chain consensus node is internally provided with the analysis implementation for the reception chain signature transaction and the presence certificate.
Through the embodiment of the application, the following technical effects can be obtained:
1) the present invention is no longer limited to asset interchange scenarios relative to the HTLC approach. The operation participating in the cross-chain interchange can be any contract method call of more than two chains;
2) the atomicity exchange achieved by the present invention does not require a contract method to support rollback. The locking, unlocking and executing mechanism of the 'conditional execution' operation is automatically carried out in the contract container based on the mapping relation between the signature transaction and the WorldState access, and is suitable for most block chain systems adopting the WorldState world state;
3) according to the invention, a third party responsible for verifying the existence of the transaction and responsible for data format conversion is not required to be introduced between the cross-chain interchange participants, the cross-chain account of the participant and the consensus node of the chain where the participant is located directly verify the existence and the output result of the signature transaction, and the original authority management and consensus mechanism of a sending chain and a receiving chain is followed;
4) when the operation on the receiving chain for cross-chain interchange also adopts 'conditional execution' transaction, the receiving chain in the invention can be used as the sending chain of the next receiving chain to become the connection link of the multi-hop cross-chain interchange operation, and so on, the invention is also suitable for the cross-chain interchange operation of more than two chains.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and those skilled in the art can also obtain other drawings according to the drawings without inventive labor.
FIG. 1 is a schematic flow chart of a cross-chain interchange operation method according to the present invention;
FIG. 2 is a cross-chain interchange flow diagram of the present invention;
FIG. 3 is a block diagram illustrating a cross-chain interchange operation method according to the present invention;
FIG. 4 is a schematic diagram illustrating indirect effects of signature transactions according to the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
Before describing the technical solution of the present invention in detail, the term convention used in the present invention is first introduced as follows:
marking: the ID is the identification, the ID in the invention can be generated by adopting a universal unique identification code (uuid) method, and the uniqueness is still kept in a cross-link environment;
contract: i.e. intelligent contracts, which may be loaded and executed by a blockchain contract container, contracts have a unique identity, contracts contain methods for signature transaction invocation, and contract methods read and write external states through interfaces provided by the contract container. "operation" in the present invention refers to invoking a contract method through a signature transaction;
contract Context (Contract Context): the context environment of execution of the contract method comprises signature transaction for calling the contract method, and API interface for accessing block data and world State world State;
world State: the world state is provided for a contract code access interface by a contract container context, and a Key-Value Key Value pair for persistent reading and writing is supported;
signature: the signature in the invention comprises an account identifier and a digital signature, wherein the digital signature is realized by using the technology in the field of public key encryption and is used for identifying digital information; the account identification is used for extracting the digital certificate of the signer from the associated transaction so as to verify the digital signature of the signer;
signature transaction: structured data containing a signature of a transaction initiator represents an authorized behavior of a signer, and a called contract method and a calling parameter are specified in signature transaction;
"conditional execution" signature transaction: signature transactions with data items such as execution and unlocking conditions, wherein the transactions represent authorized behaviors of a signer under the condition that execution conditions are met, a call of a specified contract method in the condition execution signature transaction is called as a condition execution operation, and the operation is not executed immediately after a transaction block is output but is locked;
signature transaction pre-execution: the contract container opens up a temporary World State State space as a context for transaction execution, executes the transaction and returns a result, and pre-execution will obtain the return result same with formal execution but will not change the actual World State State. Pre-execution is used for consensus nodes to agree on state changes resulting from executing signature transactions before formalizing out blocks.
Fig. 1 is a main flow diagram of a cross-chain interchange operation method of the present invention, and fig. 2 is a cross-chain interchange flow diagram of the present invention. The participants of the cross-chain interchange operation comprise an initiator A and a receiver B, and the involved blockchain comprises a sending chain S for initiating a request and a receiving chain R for receiving the request.
Step 1, a contract rsc containing a contract method participating in an interchanging operation r _ oper is deployed in a receiving chain, a contract ssc containing a contract method participating in an interchanging operation s _ oper is deployed in a sending chain, and a contract csc used for processing conditional execution transaction is deployed;
in step 1, the deploying, in the transmission chain, a contract ssc including a contract method participating in an interchange operation s _ operator specifically includes: adding an execution condition commit, an unlocking condition unlock, an unlocking block height amplified, a receiving chain ID and a receiving party account receiver in a signature transaction tx data item of a sending chain, wherein when the execution condition commit is not null, the signature transaction tx is a transaction ctx containing a conditional execution operation; for the transaction ctx of the conditional execution operation, a contract container of a transmission chain is based on a mapping relation between a contract method and world state WorldState read-write operation, and a method for performing simulation pre-execution on transaction sets with mutual influence is adopted to provide locking, unlocking and executing mechanisms for the conditional execution operation;
in step 1, the deploying a contract csc for processing a conditional execution transaction specifically includes: the contract csc of the conditional execution transaction comprises a conditional unlocking method csc.unlock, an overdue unlocking method csc.expire and an execution method csc.commit for the conditional execution operation;
step 2, a sender and a receiver participating in cross-chain interchange operation respectively register accounts sa and sb on a sending chain, and register accounts ra and rb on a receiving chain; the registered account has the authority to obtain the block data related to the account;
in step 2, the registering the account has an authority to obtain the block data related to the account, which specifically includes:
the registered account sa has the right to invoke a contract method to execute an operation s _ oper and a contract csc to invoke the conditional execution transaction through a signature transaction rtx on a transmission chain;
the registered account sb has the right to invoke the contract csc of the conditional execution transaction through the signature transaction rtx on the transmission chain;
the register account ra has the right to execute the operation r _ oper by calling a contract method through the signature transaction rtx on a receiving chain;
the executing operation s _ oper and the executing operation r _ oper are a pair of atomicity interchange operations;
step 3, a retrieval interface for the block data is provided on the receiving chain, transaction retrieval and a transaction block-out certification are provided for the consensus node on the sending chain, and the consensus node on the sending chain can acquire and verify transaction contents according to the transaction ID on the receiving chain;
step 4, the registered account sa constructs and submits the transaction ctx of the conditional execution operation in a sending chain, the execution condition ctx.commit of the transaction ctx is specified as a block of the transaction including the execution operation r _ oper in a receiving chain, the operation ctx.oper to be executed is specified as the execution operation s _ oper, the registered account sb is specified as a receiving party account ctx.receiver, and the unlocking method of the contract csc of the conditional execution transaction by the registered account sb is specified as an unlocking condition ctx.unlock;
in the step 4, the specifying of the unlocking condition ctx.unlock specifically includes: when the registered account sb submits an unlocking signature transaction stx _ unlock out block in a transmission chain, or when the block height of the transmission chain is extended to ctx. extended;
and step 5, after the register account sb obtains the transaction ctx block of the conditional execution operation related to the account from the transaction ctx receiving party account ctx.
In the step 5, before the receiving side analyzes the cross-chain interchange request and decides whether to accept the interchange request, the method further includes: verifying the authority of the registered account sa on the execution operation s _ oper, pre-executing by a contract container to obtain a key value set of a world status related to the execution operation s _ oper, and associating a transaction ctx of the conditional execution operation with the key value set to complete the locking of the execution operation s _ oper, and excluding a signature transaction out block causing the locking of the execution operation s _ oper to be invalid when a signature transaction is subsequently pre-executed;
executing corresponding operation according to the decision result, specifically comprising:
1) if the receiver is willing to accept the interchange operation request, the registered account rb constructs and submits a signature transaction rtx _ accept containing the execution operation r _ oper in a receiving chain according to the execution condition ctx.commit of the sender; the receiving chain common identification node verifies the authority of the registered account rb on the execution operation r _ oper, after the verification is passed, a signature transaction rtx is issued, and the execution operation r _ oper is executed;
after the register account rb of the receiver receives the transaction ctx block-out event of the conditional execution operation, a csc.commit method is called through the register account sb on the sending chain and through the signature transaction stx _ commit, the incoming parameters are ctx.txid and rtx.txid, and the conditional execution operation s _ oper in the signature transaction of the sending chain is triggered;
the sending chain consensus node requests transaction content and block-out certification from a receiving chain according to a receiving chain ID (ctx.targetChain) and an incoming parameter rtx.txId, after the transaction content and the block-out certification are obtained, the sending chain consensus node verifies whether a signature transaction rtx _ accept meets ctx.commit requirements, if yes, the signature transaction stx _ commit is carried out, the transaction ctx of the conditional execution operation is removed from a related key value of the transaction ctx of the conditional execution operation, the execution operation s _ oper is executed, the cross-chain interchange operation is completed, and step 9 is executed;
under the condition that the signature transaction rtx _ accept is verified to meet the ctx.commit requirement, when a sending chain and a receiving chain are heterogeneous chains, the sending chain consensus node is internally provided with the analysis implementation of the receiving chain signature transaction and the existence certification;
2) if the receiver does not want to accept the interchange operation request, on the transmission chain, according to an unlocking method ctx. unlock required by the transmitter, constructing and submitting an unlocking signature transaction stx _ unlock through the registered account sb, calling the conditional unlocking method csc. unlock, after the transmission chain consensus node verifies that a block is passed and output, triggering an unlocking operation in the transaction ctx of the conditional execution operation of the transmission chain by a contract container, removing the transaction ctx of the conditional execution operation from the key value related to the transaction ctx of the conditional execution operation to complete unlocking, and canceling cross-chain interchange operation;
3) when the height of the transmission chain block is already reached or exceeds the height of the unlocking block, and the transmission chain does not block any valid signature transaction stx _ commit or unlocking signature transaction stx _ unlock, the receiver is confirmed not to ignore the interchange operation request;
if the receiving party disregards the interchange operation request, the registered account sa constructs and submits a signed transaction stx _ exception, after the signed transaction stx _ exception is verified to pass through the sending chain consensus node, the contract container unlocks the transaction ctx of the conditional execution operation, the transaction ctx of the conditional execution operation is removed from the key value related to the transaction ctx of the conditional execution operation to complete the unlocking, and the cross-chain interchange operation is cancelled.
Fig. 3 is a schematic diagram illustrating a Block structure of the cross-chain interchange operation method of the present invention, wherein previous Block hashes defined by Block blocks form a tandem connection, so as to ensure the integrity of Block chain contents. HashOfBlock defined by the Block guarantees the content integrity of the current Block, and the signature signBlock of the Block-out consensus node guarantees the legality of the Block. transactions are a series of Transaction transactions sequences contained in Block, and the contents of the transactions include contract methods (cId, method) and method parameters (args) specified and called by the Transaction signer signCaller.
In the above step 1, in the signature transaction tx data item of the transmission chain, the execution condition commit, the unlocking condition unlock, the unlocking block height expire, the receiving chain ID, and the receiving party account receiver are added, which makes the "conditional execution" signature transaction more than the conventional signature transaction by the following data items:
l commit: submitting an execution condition, namely signature transaction on the other chain, wherein tm _ local and signature of the signature transaction signCaller are null, and an account rb on a receiving chain is specified through signCaller.eID, namely only allowing a receiving party to submit execution;
l unlock: an unlocking condition, wherein the cId and the method are used for designating calling of a sending chain csc.unlock method, the tm _ local and signature of the signature transaction signCaller are null, and an account sb on the sending chain is designated by signCaller.eID, namely only the receiving party is allowed to unlock.
l amplified: the expired time interval is locked, measured as the height of the block after the block where ctx is located.
l targetChain: receive chain ID
l receiver: account of receiver
Locking and unlocking of 'conditional execution' signature transactions
In the contract method logic called by the signature transaction, an API provided by a context (ContractContext) provided by a contract container can read and write the world state of WorldState, and by taking a contract method for transferring as an example, the following contract methods are defined:
def transfer(c: ContractContext, from:String, to:String, amount:Int) ={
val dfrom = c.api.getState(from).asInstanceOf[Int]
if(dfrom < amount)
throw ContractException ("insufficient balance")
c.api.setState(from,dfrom - amount)
var dto = c.api.getState(to).asInstanceOf[Int]
c.api.setState(to,dto + amount)}
Where c represents the contract context, from represents the sender account, to represents the recipient account, and amount represents the transfer amount;
and (3) when the contract logic executes/pre-executes in the contract container, the contract logic forms read-write instructions of sequential access to WorldState, and FIG. 4 is a schematic diagram of indirect influence of signature transaction in the invention. When there is an intersection of accesses to the WorldState key value by the contract logic called by the signed transaction, a write operation to a transaction may cause other signed transactions to throw an exception and be invalid. For example: the write setState (K4, V4) of the conventional signature transaction tx _ m to K4 may cause the "conditional execute" signature transaction ctx _1, ctx _ n dependent on the value of K4 to throw an exception.
Assuming that ctx _1 out-block is before tx _ m or before tx _ m in the same block, when the consensus node verifies ctx _1 through pre-execution, contract logic can execute normally (balance is sufficient for example in transfer), so ctx _1 out-block and lock normally, but if tx _ m also goes out during ctx _1 lock, resulting in lock failure of ctx _1 (balance is insufficient after tx _ m is executed), the receiver still mistakenly regards ctx _1 lock as valid, and initiates swap operation r _ op in the receiving chain, as a result, r _ op execution succeeds, but s _ op commits execution and the swap atomicity is destroyed due to failure of throwing exception. Further generalizing the effects caused by reading and writing the same key value is as follows:
writing a key value may cause the operation of reading the key value to be invalid;
l reading the key value does not cause the write key value to be invalid;
l reading the key value does not cause the read key value to be invalid;
l writing a key value does not cause the written key value to be invalid;
the above example shows that one of the key issues in achieving atomicity is that the interplay between signature transactions must be considered to ensure that such an impact does not cause the locked "conditional execution" transaction to fail. Therefore, the invention adopts a method of carrying out simulation pre-execution aiming at the locked 'conditional execution' transaction, evaluates whether the influence of writing key value operation on reading the same key value operation can cause the latter to be invalid, and ensures that any signature transaction causing the failure of the 'conditional execution' transaction in the locked state is not commonly recognized to accept the block. The specific method comprises the following steps:
in a contract container of a consensus node: a. returning a set of related read and write WorldState key values when pre-executing the signature transaction by enhancing the WorldState access API provided in the contract container context; b. a "conditional execution" transaction set that establishes a lock state associated with each WorldState key value when the "conditional execution" transaction goes out of the block lock, including "conditional execution" transactions that write and read the key value; c. the two are superposed, and the 'conditional execution' transaction set of the locking state related to the 'conditional execution' transaction set can be returned through pre-executing the signature transaction.
Given the uncertainty of the "conditional execution" transaction commit execution (commit) opportunity, the "conditional execution" transaction set may commit execution in any order, thus requiring emulation of every possible order. When a 'conditional execution' transaction is pre-verified in the block proposal stage, the transaction is added to a 'conditional execution' transaction set corresponding to each WorldState key value related to the transaction (including the transaction set influenced by writing the key value and the transaction set influenced by reading the key value), and then the transaction is pre-executed in each possible sequence for each transaction set. Otherwise, if the verification passes and the block is output, the verification passes and the block is kept in a 'conditional execution' transaction set corresponding to the WorldState key value, and the conditional transaction enters a locking state as a target set for subsequent transaction verification.
When a conventional transaction is pre-verified in the block proposal stage, the sequence of the transaction is necessarily before the current locked 'conditional execution' transaction, so the verification method is as follows: the transaction is placed at the head of a 'conditional execution' transaction set corresponding to each WorldState key value related to the transaction (the transaction is influenced by the written key value), other transactions except the transaction are pre-executed in each possible sequence, and if any exception occurs, the normal transaction to be verified is judged to cause the locked 'conditional execution' transaction to be abnormal and not pass.
When the signature transaction succeeds in invoking an unlocking (unlock) or committing (commit) method of the csc contract for the specified 'conditional execution' transaction ctx, the signature transaction is invoked to enable the ctx to be abnormal from the 'conditional execution' transaction set corresponding to all WorldState key values, and the signature transaction exits from a locking state.
The above measures ensure that any signature transaction of new blocks can not destroy the effectiveness of locked operation during the locking period of the 'conditional execution' transaction, and guarantee is provided for atomicity of cross-chain interchange. The key code of step 1a is as follows, data items kset _ read, kset _ write and operation of recording read-write related key value set are added in a WorldState access interface provided by a contract context, and the following contract method interface classes are defined:
class ShimAPI(cId: String) { ...
val kset _ read = Set [ Key ] ()// read-related Key-value Set
val kset _ write = Set [ Key ] ()// write-related Key value Set
def setState(key: Key, value: Value): Unit = {
Add/key write set
put(key, value) }
def getState(key: Key): Value= {
Add (key)// key value join read set
get(key) } ...}
For a conditional execution transaction set which establishes a locking state related to each WorldState key value when a conditional execution transaction block is locked, the conditional execution transaction set in the locking state related to each WorldState key value is provided through global data items kmap _ read and kmap _ write, and the method for obtaining the signature transaction related conditional execution transaction set, locking and unlocking the conditional execution transaction related to the step 2 and the step 3 is also included, and the following global method classes are defined:
object ShimAPI {
type Key=String
type Value=Array[Byte]
val kmap _ read = Map [ Key, Set [ Transaction ] ] ()// related Transaction Set of read Key values
val kmap _ write = Map [ Key, Set [ Transaction ] ] ()// related Transaction Set of write Key values
def load Tx (tid: String) = (Transaction, Long) = {.. }// load and return the specified signature Transaction, tid: specified signature Transaction ID, block height of Transaction
def load RemoteTX (TargetChain: String, tid: String) (Transaction, Proof) = {.. }// through a block data retrieval API provided by a receiving chain, obtaining an outgoing block signature Transaction and a Transaction outgoing block certificate on the receiving chain, targetChain: receiving chain ID, tid: signature Transaction ID on the receiving chain
def getKeySet (t: Transaction): (Set [ Key ] ) = {. the// based on enhanced WorldState access API in contract context, related Key value Set for Transaction reading and writing is obtained through pre-execution
def getBlock height (), Long = {
def getLockedTexRead (Key: Key): Option [ Set [ Transaction ] ] = { kmap _ read.get (Key) }// get read specified Key value of the associated "conditional execution" signature Transaction Set, where Key represents the specified Key value
def getLockedTxWrite(key:Key):Option[Set[Transaction]]={kmap_write.get(key)}
V/obtaining a related "conditional execution" signed transaction set written to a specified key, where key represents the specified key
For the related 'conditional execution' signature transaction set for obtaining the designated transaction, if the designated transaction is a conventional transaction, only returning the conditional execution transaction set influenced by the written key value; if the designated transaction is a conditional execution transaction, returning a set of conditional execution transactions affected by the write key value and affected by the read key value, wherein t represents the designated transaction;
def getRelatedTx(t:Transaction):Set[Transaction] = {
val （ks_read,ks_write） = getKeySet(t)
val stx = Set[Transaction]()
if (t.commit) {// if conditional execution trade
val ki1 = ks_write.intersect(kmap_read.keySet)
ki1.foreach(x => stx.++(getLockedTxRead(x)))
val ki2 = ks_read.intersect(kmap_write.keySet)
ki2.foreach(x => stx.++(getLockedTxWrite(x)))
}else{
val ki = ks_write.intersect(kmap_read.keySet)
ki.foreach(x => stx.++(getLockedTxRead(x)))
}
stx
}
Locking a specified "conditional execution" transaction operation is achieved by a contract method in which tid represents a "conditional execution" transaction ID to be locked;
def lockTx(tid:String) ={
val t = loadTx(tid)
val (ks_read,ks_write) = getKeySet(t)
ks_read.foreach { x =>
val ts = getLockedTxRead(x).getOrElse(Set[Transaction]())
ts.add(t)}
ks_write.foreach { x =>
val ts = getLockedTxWrite(x).getOrElse(Set[Transaction]())
ts.add(t)} }
unlocking a designated "conditional execution" transaction is achieved by a contract method in which tid represents a "conditional execution" transaction ID to be unlocked;
def unlockTx( tid:String) ={
val t = loadTx(tid)
val (ks_read,ks_write) = getKeySet(t)
val ki_read = ks_read.intersect(kmap_read.keySet)
ki_read.foreach { x =>
val tr = getLockedTxRead(x)
if(!tr.isEmpty) tr.get.remove(t)
}
val ki_write = ks_write.intersect(kmap_read.keySet)
ki_write.foreach { x =>
val tw = getLockedTxWrite(x)
if(!tw.isEmpty) tw.get.remove(t)
}
}
}
in the technical scheme of the invention, for the contract containing the cross-chain interchange operation, a contract ssc including an execution operation s _ oper (cross-chain interchange operation) in the conditional execution signature transaction is deployed on a sending chain, and a contract rsc including an execution operation r _ oper (cross-chain interchange operation) in the conditional execution signature transaction is deployed on a receiving chain, and for the contract method and parameters of the contract ssc and the contract rsc, the contract method and parameters can be in any form which participates in cross-chain double recognition, when the method and the parameter are applied to an asset exchange scene similar to HTLC, the ssc contains accounts sa and sb of both parties on the sending chain, and rsc contains accounts ra and rb of both parties on the receiving chain.
In the technical scheme of the invention, a contract csc (shown below) for processing the 'conditional execution' transaction is deployed on a transmission chain, the contract comprises contract methods for commit execution (commit), conditional unlock (unlock) and expire unlock (expire), a receiving party uses a receiving chain to exit a block transaction txId, and the triggering of the 'conditional execution' transaction execution is realized by the following contract methods, wherein ctxId represents the 'conditional execution' transaction ID to be triggered, and txId represents the receiving chain exit block transaction txId:
class ContractAssetsTPL extends IContract{...
def commit(c: ContractContext, ctxId:String, txId:String): ActionResult={
val (ctx,blockHeight) = ShimAPI.loadTx(ctxId)
VerifyProof embeds parsing of receive chain signature transactions and presence attestation when the receive chain is heterogeneous
val (rtx,proof) = ShimAPI.loadRemoteTx(ctx.targetChain,txId)
if(!verifyProof(proof))
throw ContractException ("out Block Presence proof of validation failed, commit execution failed!")
if(rtx.method!= ctx.method || rtx.args!= ctx.args)
throw ContractException ("not satisfied execution conditions, commit execution failed!")
...
ShimAPI.unlockTx(ctxId)
}
In the technical scheme of the invention, a receiver refuses an interchange request, and the unlocking of the 'conditional execution' transaction is realized by a contract method, wherein ctxId represents a 'conditional execution' transaction ID to be triggered;
def unlock(c: ContractContext, ctxId:String): ActionResult={
val (ctx,blockHeight) = ShimAPI.loadTx(ctxId)
if(c.t.signCaller.eId != ctx.notify)
throw ContractException ("non-recipient call, unlock failure!")
...
ShimAPI.unlockTx(ctxId)
}
In the technical scheme of the invention, a sender uses a block outlet height, and unlocking the 'conditional execution' transaction is realized by a contract method, wherein ctxId represents a 'conditional execution' transaction ID to be triggered;
def expire(c: ContractContext, ctxId:String): ActionResult={
val (ctx,blockHeight) = ShimAPI.loadTx(ctxId)
if(ShimAPI.getBlockHeight() - blockHeight < ctx.expired)
throw ContractException ("not reached expired Block height, unlock failed!")
...
ShimAPI.unlockTx(ctxId)
}
}
In some embodiments, part or all of the computer program may be loaded and/or installed onto the device via ROM. When being loaded and executed, may carry out one or more of the steps of the method described above.
The functions described above in this disclosure may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a load programmable logic device (CPLD), and the like.
Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
Further, while operations are depicted in a particular order, this should be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Claims (5)
1. A cross-chain interchange operation method facing a general scene is characterized in that the participants of the cross-chain interchange operation comprise an initiator and a receiver, and a block chain comprises a sending chain for initiating a request and a receiving chain for receiving the request;
step 1, deploying a contract rsc containing a contract method participating in an interchanging operation r _ oper in a receiving chain, and deploying a contract ssc containing a contract method participating in an interchanging operation s _ oper in a sending chain;
in step 1, before the deploying, in the transmission chain, a contract ssc containing a contract method participating in an interchange operation s _ oper, the method includes:
the contract csc for executing the transaction under the processing condition is deployed in the transmission chain, and specifically comprises the following steps: the contract csc of the conditional execution transaction comprises a conditional unlocking method csc.unlock, an overdue unlocking method csc.expire and an execution method csc.commit for the conditional execution operation;
step 2, a sender and a receiver participating in cross-chain interchange operation respectively register accounts sa and sb on a sending chain, and register accounts ra and rb on a receiving chain; the registered account has the authority to call interchange operation and obtain block data related to the account;
step 3, a retrieval interface for the block data is provided on the receiving chain, transaction retrieval and a transaction block-out certificate are provided for the consensus node on the sending chain, and the consensus node on the sending chain can acquire and verify transaction content and the block-out certificate according to the transaction ID on the receiving chain;
step 4, the registered account sa constructs and submits a transaction ctx of conditional execution operation in a transmission chain, the execution condition ctx.commit of the transaction ctx is specified as a block of the transaction including the interchange operation r _ oper in a receiving chain, the operation ctx.oper to be executed is specified as the interchange operation s _ oper, the registered account sb is specified as a receiving party account ctx.receiver, and the unlocking method of the contract csc of the registered account sb for the conditional execution transaction is specified as ctx.receiver invoking an unlocking condition ctx.unlock;
step 5, after the register account sb obtains the transaction ctx output block of the conditional execution operation related to the account from the transaction ctx receiving party account ctx.receiver, the receiving party analyzes the cross-chain interchange operation request and decides whether to accept the interchange operation request, and executes the corresponding operation according to the decision result;
in the step 5, the executing the corresponding operation according to the decision result specifically includes:
if the receiver is willing to accept the interchange operation request, the register account rb constructs and submits a signature transaction rtx _ accept containing the interchange operation r _ oper in a receiving chain according to the sender execution condition ctx.commit; the receiving chain common identification node verifies the authority of the registered account rb on the interchange operation r _ oper, after the verification is passed, a signature transaction rtx is taken out, and the interchange operation r _ oper is executed;
after the register account rb of the receiver receives the transaction ctx block-out event of the conditional execution operation, a csc.commit method is called through the register account sb on the sending chain and through the signature transaction stx _ commit, the incoming parameters are ctx.txid and rtx.txid, and the interchange operation s _ oper in the conditional execution signature transaction of the sending chain is triggered;
the sending chain common-identification node requests transaction content and block-out certification from a receiving chain according to a receiving chain ID (ctx.targetChain) and an incoming parameter rtx.txId, after the transaction content and the block-out certification are obtained, the sending chain common-identification node verifies whether a signature transaction rtx _ accept meets ctx.commit requirements or not, if yes, the signature transaction stx _ commit is carried out, the transaction ctx of the conditional execution operation is removed from a transaction ctx related key value of the conditional execution operation, the interchange operation s _ oper is executed, and the cross-chain interchange operation is completed;
if the receiver does not want to accept the interchange operation request, on the transmission chain, according to an unlocking method ctx. unlock required by the transmitter, constructing and submitting an unlocking signature transaction stx _ unlock through the registered account sb, calling the conditional unlocking method csc. unlock, after the transmission chain consensus node verifies that a block is passed and output, triggering an unlocking operation in the transaction ctx of the conditional execution operation of the transmission chain by a contract container, removing the transaction ctx of the conditional execution operation from the key value related to the transaction ctx of the conditional execution operation to complete unlocking, and canceling cross-chain interchange operation;
when the block height of the transmission chain, extended, has reached or exceeded the unlocked block height, ctx. extended, and the transmission chain has not blocked any valid signature transaction stx _ commit or unlocked signature transaction stx _ unlock, it is confirmed that the receiver disregards the interchange operation request;
if the receiving party disregards the interchange operation request, the registered account sa constructs and submits a signed transaction stx _ expire, after the signed transaction stx _ expire is verified by the sending chain consensus node, the contract container unlocks the transaction ctx of the conditional execution operation, the transaction ctx of the conditional execution operation is removed from the key value related to the transaction ctx of the conditional execution operation to complete the unlocking, and the cross-chain interchange operation is cancelled;
under the condition that the signature transaction rtx _ accept is verified to meet the ctx.commit requirement, when a sending chain and a receiving chain are heterogeneous chains, the sending chain consensus node is internally provided with the analysis implementation of the receiving chain signature transaction and the existence certification.
2. The method according to claim 1, wherein in step 1, before said deploying, in a sending chain, a contract ssc containing contract methods participating in an interchange operation s _ oper, further comprises: data structure definition of the transmit chain: adding an execution condition commit, an unlocking condition unlock, an unlocking block height amplified, a receiving chain ID and a receiving party account receiver in a signature transaction tx data item of a sending chain, wherein when the execution condition commit is not null, the signature transaction tx is a transaction ctx containing a conditional execution operation;
contract container enhancement of the transmit chain: for the transaction ctx of the conditional execution operation, a contract container of a transmission chain is based on a mapping relation between a contract method and world state WorldState read-write operation, and a method for performing simulation pre-execution on transaction sets with mutual influence is adopted, so that a locking, unlocking and executing mechanism for the conditional execution operation is provided.
3. The method of claim 1,
in the step 2, the registering an account has a right to acquire and complete the interchange operation, which specifically includes:
the registered account has the authority of obtaining the block data of the block chain;
the registered account sa has the right to invoke a contract method on a transmission chain through the signature transaction rtx to execute an interchange operation s _ oper and a contract csc to invoke the conditional execution transaction;
the registered account sb has the right to invoke the contract csc of the conditional execution transaction through the signature transaction rtx on the transmission chain;
the register account ra has the right to call a contract method through the signature transaction rtx to execute the interchange operation r _ oper on a receiving chain;
wherein the interchange operation s _ oper and the interchange operation r _ oper are a pair of atomic interchange operations.
4. The method for cross-chain interchange operation according to claim 1, wherein in step 4, the specifying an unlocking condition ctx. unlock specifically includes: when the registered account sb submits an unlocking signature transaction stx _ unlock out block in the send chain, or when the send chain block height extended reaches ctx.
5. The method for cross-chain interchange operation according to claim 1, wherein in step 5, before the receiver analyzes the cross-chain interchange operation request and decides whether to accept the interchange operation request, the method further comprises: the sending chain consensus node verifies the authority of the registered account sa on the interchange operation s _ oper, a contract container of the sending chain consensus node performs pre-execution to obtain a key value set of a world state WorldState related to the interchange operation s _ oper, and associates a transaction ctx of the conditional execution operation with the key value set to complete locking of the interchange operation s _ oper, and when signature transaction is performed subsequently, invalid signature transaction outgoing blocks which cause locking of the interchange operation s _ oper are excluded, and the signature transaction performed subsequently comprises a common signature transaction and a conditional execution signature transaction.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110065638.3A CN112396427B (en) | 2021-01-19 | 2021-01-19 | Cross-chain interchange operation method for general scenes |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110065638.3A CN112396427B (en) | 2021-01-19 | 2021-01-19 | Cross-chain interchange operation method for general scenes |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112396427A CN112396427A (en) | 2021-02-23 |
| CN112396427B true CN112396427B (en) | 2021-04-23 |
Family
ID=74625353
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110065638.3A Active CN112396427B (en) | 2021-01-19 | 2021-01-19 | Cross-chain interchange operation method for general scenes |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112396427B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112598524B (en) * | 2021-02-26 | 2021-06-22 | 北京全息智信科技有限公司 | Processing method and device for conditional block chain transaction and electronic equipment |
| TWI769738B (en) * | 2021-03-12 | 2022-07-01 | 帳聯網路科技股份有限公司 | Asset cross-chain exchanging system based on threshold signature scheme and method thereof |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109146448A (en) * | 2018-07-13 | 2019-01-04 | 杭州复杂美科技有限公司 | Across chain assets transfer method, equipment and storage medium |
| CN110020860A (en) * | 2019-04-09 | 2019-07-16 | 湖南天河国云科技有限公司 | Across the chain assets transfer method of one kind, system and computer readable storage medium |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111787072B (en) * | 2018-04-03 | 2023-02-28 | 创新先进技术有限公司 | Cross-block-chain interaction method, device, system and electronic equipment |
| CN112217683B (en) * | 2020-11-02 | 2023-10-17 | 西安链融科技有限公司 | Cross-heterogeneous chain data reachability processing method, system, medium, equipment and terminal |
| CN112235423B (en) * | 2020-12-11 | 2021-08-10 | 腾讯科技（深圳）有限公司 | Cross-chain transaction processing method and device, electronic equipment and storage medium |
| CN112235110B (en) * | 2020-12-14 | 2021-03-23 | 支付宝(杭州)信息技术有限公司 | Cross-chain service processing method and device of block chain and electronic equipment |
-
2021
- 2021-01-19 CN CN202110065638.3A patent/CN112396427B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109146448A (en) * | 2018-07-13 | 2019-01-04 | 杭州复杂美科技有限公司 | Across chain assets transfer method, equipment and storage medium |
| CN110020860A (en) * | 2019-04-09 | 2019-07-16 | 湖南天河国云科技有限公司 | Across the chain assets transfer method of one kind, system and computer readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112396427A (en) | 2021-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108881187B (en) | Cross-link data transmission method and device suitable for permission link scene | |
| JP7250771B2 (en) | Concurrent state machine processing using blockchain | |
| US20230360036A1 (en) | Blockchain-implemented method and system for access control on remote internet-enabled resources | |
| CN110310205B (en) | Block chain data monitoring method, device, equipment and medium | |
| CN112396427B (en) | Cross-chain interchange operation method for general scenes | |
| CN111383114A (en) | Asset information management method and device based on block chain | |
| WO2022105600A1 (en) | Blockchain cross-chain transaction method and apparatus based on internet-of-things | |
| US11403281B2 (en) | Parallel blockchain processing | |
| CN111402033A (en) | Asset information management method and device based on block chain | |
| CN112907244B (en) | Block chain-based data processing method, device, equipment and readable storage medium | |
| CN112597240B (en) | Federal learning data processing method and system based on alliance chain | |
| CN112215709A (en) | Block chain based bill extraction digital circulation method and device and electronic equipment | |
| CN114090683A (en) | Intelligent contract management method, equipment and storage medium based on alliance administration | |
| CN112269838B (en) | Blockchain-based supervision method and device, electronic equipment and storage medium | |
| CN113362068A (en) | Method for verifying block chain state transfer by light node | |
| CN112037062B (en) | Transaction consensus method, device, electronic equipment and readable storage medium | |
| CN113987598A (en) | Block migration method and device | |
| CN114491662A (en) | Block chain-based data asset auditing method, system and equipment | |
| CN115829731A (en) | Transaction information processing method and device | |
| CN112927075A (en) | Processing method and device for cross-chain transaction, electronic equipment and readable storage medium | |
| CN111738855A (en) | Intelligent contract management method and device | |
| CN111369246A (en) | Calling authentication method and device of intelligent contract, electronic equipment and storage medium | |
| CN111222991A (en) | Method and system for crossing chains between block chains | |
| CN113313584B (en) | Service processing method and processing device | |
| Lisi et al. | Automated responsible disclosure of security vulnerabilities |
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 | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20210223 Assignee: Zhong kjia speed (Beijing) Information Technology Co.,Ltd. Assignor: BEIJING LIANQI TECHNOLOGY Co.,Ltd. Contract record no.: X2021110000022 Denomination of invention: A cross chain interchange operation method for general scenarios Granted publication date: 20210423 License type: Common License Record date: 20210708 |
|
| EE01 | Entry into force of recordation of patent licensing contract | ||
| EE01 | Entry into force of recordation of patent licensing contract | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20210223 Assignee: Guangzhou Zhongke Yide Technology Co.,Ltd. Assignor: BEIJING LIANQI TECHNOLOGY Co.,Ltd. Contract record no.: X2021110000050 Denomination of invention: A cross chain exchange operation method for general scene Granted publication date: 20210423 License type: Common License Record date: 20211126 |
|
| EE01 | Entry into force of recordation of patent licensing contract | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20210223 Assignee: Zhongke Huizhi (Guangdong) Information Technology Co.,Ltd. Assignor: BEIJING LIANQI TECHNOLOGY Co.,Ltd. Contract record no.: X2023110000065 Denomination of invention: A Cross Chain Interchange Operation Method for General Scenarios Granted publication date: 20210423 License type: Common License Record date: 20230523 |
|
| EE01 | Entry into force of recordation of patent licensing contract | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20210223 Assignee: Zhongke Zhicheng (Guangzhou) Information Technology Co.,Ltd. Assignor: BEIJING LIANQI TECHNOLOGY Co.,Ltd. Contract record no.: X2024110000022 Denomination of invention: A Cross Chain Interchange Operation Method for Universal Scenarios Granted publication date: 20210423 License type: Common License Record date: 20240320 |