CA2995177A1 - A method of state synchronization for complex smart contracts based on stage buckets - Google Patents
A method of state synchronization for complex smart contracts based on stage buckets Download PDFInfo
- Publication number
- CA2995177A1 CA2995177A1 CA2995177A CA2995177A CA2995177A1 CA 2995177 A1 CA2995177 A1 CA 2995177A1 CA 2995177 A CA2995177 A CA 2995177A CA 2995177 A CA2995177 A CA 2995177A CA 2995177 A1 CA2995177 A1 CA 2995177A1
- Authority
- CA
- Canada
- Prior art keywords
- bucket
- state
- phase
- contract
- nodes
- 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.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
A method of state synchronization for complex smart contract based on phase buckets comprises the following steps: (1) judging state type transaction, determining account address that needs to be updates; (2) generating phase bucket according to state transaction information, and then set a timer for each phase of the bucket; (3) Tally stage bucket status information, and statistics of the number of each type of message; (4) check the results of step (3) to determine whether a bucket has reached consistency. if yes, go to (5), otherwise continue to step (7);
(5) the state is stored in the state blockchain; (6) mark the phase bucket as "agreed", and then delete the bucket for this phase; (7) Check whether the timer of the bucket has expired; if not, skip to step (3); otherwise, continue to step (8) Then delete the bucket at this stage, at this time the bucket is called "waste bucket."
(5) the state is stored in the state blockchain; (6) mark the phase bucket as "agreed", and then delete the bucket for this phase; (7) Check whether the timer of the bucket has expired; if not, skip to step (3); otherwise, continue to step (8) Then delete the bucket at this stage, at this time the bucket is called "waste bucket."
Description
A Method of State Synchronization for Complex Smart Contracts Based on Stage Buckets Technical Field The present application relates generally to blockchain technology, and in particular to a phase-bucket-based method for complex intelligent contract state synchronization in blockchain applications.
Background Art A complex smart contract, is the implementation of a long, complex logic of a contract, usually involving multiple stages. In a blockchain system, a smart contract needs to be deployed on all nodes, and the smart contract requires every node in the system to execute simultaneously at each execution, so that all node states are consistent.
In practice, the environment and capabilities of each node in the blockchain system may be different, and the smart contracts may run at different nodes at different speeds. In addition, the logic is complex and the smart contracts may change the state of the node at any stage of operation.
Existing solutions in the prior art have not yet addressed scenarios involving different node capabilities or environments in relation to smart contract execution. It is thus possible for asynchronous contract execution states to occur and a blockchain system may fail to support execution of complex smart contracts. At the same time, it is difficult to achieve the consistency, integrity and isolation of data when multiple independent nodes execute the contract at the same time. Data synchronization activities at different nodes may interfere with each other.
[0005j It is therefore desirable to have a blockchain system that permits the reliable execution of complex smart contracts.
Summary of Invention LEGAL_28652067.2 - 1 -loll 352-256543-KB/TT
In accordance with an aspect of the present invention, there is provided a phase-bucket-based method for complex smart contract state synchronization that allows for differences in node environments for executing smart contracts and differences in speed when executing the same smart contract. The method comprises (1) determining the status of the type of transaction, to determine the need to update the status of the account address; (2) according to the state of the transaction information, generating buckets, and then setting a timer for each bucket; (3) tallying phase bucket status information, and respectively tallying the number of each type of message; (4) checking the result of step (3) to determine whether a certain bucket has reached an agreement; proceeding to step (5) if agreement has been reached;
otherwise, proceeding to step (7); (5) storing the state information into the state blockchain; (6) marking the bucket as "agreed" and deleting the bucket; (7) checking whether the bucket timer has expired or not (8), continuing to mark the stage bucket as "has timed out", and then deleting the stage bucket, called "waste bucket".
Brief Description of Drawings [0007]
In the figures, which illustrate by way of example only, embodiments of the present invention, [0008]
FIG. 1 is a schematic diagram of a simple account structure according to an exemplary embodiment of the present invention;
[0009]
FIG. 2 is a schematic diagram of the structure of a complex contract account according to an exemplary embodiment of the present invention; and [0010]
FIG. 3 is a schematic diagram of a state synchronization process according to an exemplary embodiment of the present invention.
Description of Embodiments LEGAL_28652067.2 - 2 -[0011]
A description of various embodiments of the present invention is provided.
Specific implementations of exemplary embodiments will be described in detail, with reference to the accompanying drawings. The same reference numerals in the drawings will be used identify the same or similar parts or portions. The drawings are not necessarily drawn to scale.
In this disclosure, the use of the word "a" or -an" when used herein in conjunction with the term -comprising" may mean "one," but it is also consistent with the meaning of "one or more," "at least one- and "one or more than one." Any element expressed in the singular form also encompasses its plural form. Any element expressed in the plural form also encompasses its singular form. The term "plurality" as used herein means more than one, for example, two or more, three or more, four or more, and the like. Directional terms such as "top,"
"bottom,- -upwards," "downwards," "vertically," and "laterally" are used for the purpose of providing relative reference only, and are not intended to suggest any limitations on how any article is to be positioned during use, or to be mounted in an assembly or relative to an environment.
[0013]
The terms -comprising", -having", "including", and "containing", and grammatical variations thereof, are inclusive or open-ended and do not exclude additional, un-recited elements and/or method steps. The term "consisting essentially of' when used herein in connection with a composition, use or method, denotes that additional elements, method steps or both additional elements and method steps may be present, but that these additions do not materially affect the manner in which the recited composition, method, or use functions. The term -consisting of' when used herein in connection with a composition, use, or method, excludes the presence of additional elements and/or method steps.
[0014]
An objective of the present invention is to provide a phase-bucket-based method for complex smart contract state synchronization that allows for differences in node environments for executing smart contracts and differences in speed when executing the same smart contract, comprising the following steps: (1) determine the status of the type of transaction, to determine the need to update the status of the account address; (2) according to the state of the transaction information, generate buckets, and then set a timer for each bucket; (3) tally phase bucket status LEGAL_28652067 1 - 3 -information, and respectively tally the number of each type of message; (4) check the result of step (3) to determine whether a certain bucket has reached an agreement;
proceeding to step (5) if agreement has been reached; otherwise, proceed to step (7); (5)store the state information into the state blockchain; (6) mark the bucket as "agreed" and then delete the bucket; (7) check whether the bucket timer has expired or not (3), otherwise continue to step (8); and (8) mark the stage bucket as "has timed out", and then delete the stage bucket, which is called "waste bucket".
In an exemplary embodiment, the transaction of step (I) is sent from a transaction block chain.
In the exemplary embodiment, the information in step (2) includes the address of the contract account, the total number of times the contract account is triggered to be executed and the account address that needs to be changed, The state statistical information in the phase bucket in step (3) is the classification of the same content information from different nodes of the transaction block chain.
In step (4) the determination of whether a certain bucket has been agreed upon is to determine whether more than two-thirds of the contract execution nodes have the same status.
The "waste bucket" in step (8) is caused by a long-term inability to reach consensus in a bucket.
The waste bucket is generated if, although the nodes in the bucket have collected all the options from every contracts' execution nodes, the total number of the same status messages is less than 2/3 of the total number of nodes and no agreement is reached.
The waste bucket is due to the slow execution of the individual nodes executing the smart contract, when it sends its own status transaction (sTx) to the status block chain, the status block chain has completed the status statistics for that phase, over 2/3 of the nodes have agreed on the state change for this phase and has destroyed the corresponding phase bucket. The state LEGAL 28652067.2 - 4 -blockchain creates a new phase bucket for this sTx and waits for state statistics that can never be completed.
The waste bucket is generated due to some sTx failing to reach the state blockchain, or some nodes failing to send sTx successfully, resulting in less than two-thirds of the total number of nodes executing the contract for a certain stage.
After the waste bucket is generated, the subsequent status of the contract is no longer counted whether it is consistent or not. The source account address of the contract is recorded, as well as the current execution sequential number and the number of times the contract is activated. If the subsequent sTx is the status information of the same execution sequence number of the same contract, it is discarded directly.
[0024]
When individual nodes performing intelligent contracts execute slowly, the system dynamically maintains a status table for the phase buckets that have been confirmed to have reached a consensus and destroyed within a recent period, recording the tag name and the total number of opinions accumulated in the bucket at the time of destruction. If the subsequent sTx corresponding tag name matches the tag name recorded in the table, the sTx is directly discarded and the total number of opinions accumulated under the tag name is incremented by 1. When the total number of opinions cached for a stage bucket reaches the node number of all the nodes executing the contract, that is, all the nodes executing the contract have finished this stage, or when the cache record exceeds a certain time limit, the record is written into the log and then clear it in the table.
[0025]
When some sTx fails to reach the state blockchain, or some nodes fail to successfully send sTx, the system starts a timer each time a bucket is newly created. When a bucket expires after a period of time but the state consensus is not reached, the system will destroy the bucket.
[0026j One exemplary embodiment guarantees the consistent state of nodes performing intelligent contracts by using a "phase bucket" with individual storage on the blockchain, which improves the ability of the blockchain system to support the execution of complex smart LEGAL_28652067 1 - 5 -contracts. It assures the data consistency, uniformity of results, data integrity, and data segregation when multiple nodes execute contracts simultaneously, and data synchronization does not interfere with each other.
100271 Before proceeding with the description of certain specific implementations, some important concepts will now be described.
[0028] I. Account [0029] The smart contract is attached to an account and the structure of the account is described as follows:
[0030] (1) Activation Status: whether the account is activated or not. 0 represents it not activated, 1 represents it activated. If this field is 0, the account cannot send transactions, and ignores all transaction information sent to it except the activation information until it is re-activated;
[0031] (2) create time and update time: Record the time the account was created and the time of last update;
[0032] (3) Contract hash value: For the contract account, this field records the hash value of the contract code associated with the account. Once the account is generated, the value will not change.
[0033] (4) nonce: an integer that records the total number of transactions sent from the account address;
[0034] (5) number: record the number of transactions sent to the account address, record the number of times the contract was activated;
100351 (6) Account Type: Divided into two types, 1 for ordinary contract accounts, 2 for complex contract accounts;
LEGAL 28652067.1 - 6 -[0036] (7) account address: a 20-bit long string, uniquely identify an account in the system using the public key and private key generated by asymmetric encryption technology, and then do md5 hash to public key, take the last 20 characters as address;
100371 (8) Account Cache: Temporary records of temporary data generated during the execution of the contract.
[0038] For simple contracts, it is entirely possible to store the compiled binary data directly on the blockchain for faster loading. However, for complex smart contracts, if the files related to contract execution are directly stored on the blockchain, the block size may be too large.
Therefore, the complex contract only saves the addresses of the relevant files in the account to save space and save the files outside the blockchain. The structure of the account is shown in FIG. 1 and FIG. 2.
[0039] II. Transaction Blockchain and State Blockchain 100401 The transaction blockchain receives information from outside the blockchain system and stores this information in the block, and the execution of the smart contract is done in the nodes of the transaction blockchain.
[00411 State blockchain stores state information and maintains account information. It is responsible for the state synchronization and storage during and after executing smart contracts.
[0042] III. State Transaction [0043] During smart contract execution, when any operation affects the states, each contract execution node sends a status transaction (sTx) to the dedicated blockchain of state storage, for state synchronization. Status transaction (sTx) includes:
100441 (1) Source Address: address of the account that issued the status transaction;
[0045] (2) Public Key of the source account: the last 20 characters of hash value of the public key should be the same as the source address.
LEGAL_28652067 1 - 7 -100461 (3) Execution Information: The execution information of this contract, including the record of how many times this contract is executed;
100471 (4) Object Account Address: the account address whose status be changed;
100481 (5) Status Information: status change information, related to specific areas;
100491 (6) Signature: Use the private key of the source address to sign the digest summary aggregate with the object account address, execution information and status information;
100501 (7) Timestamp: the time the transaction was created.
100511 IV. Phase Bucket 100521 Smart contracts are executed simultaneously on all nodes in the transaction blockchain. Therefore, each node generates a status transaction when the status change operation occurs. In order to summarize and consolidate the status change results of each node, and maintain state blockchain's state consistency, the system establishes a bucket for each stage of the smart contract, each stage may have one or more times of status change.
100531 Complex types of smart contracts usually have long execution cycles and have multiple phases. When deploying and executing on multiple independent nodes simultaneously, there are differences in the execution speed of smart contracts due to the different environments of different nodes in practice. The synchronization of contract execution status becomes difficult.
For example, a smart contract is executed in three phases, a, b, and c, each of which may involve one or more state changes. Suppose that node (i+1) for some reason has just completed execution of phase a when node (i) has competed the execution of phase b, and the local state at this time cannot be synchronized directly, but needs to wait for b phase completion of node (i+1), in the scenario use the phase barrel to reduce the processing latency is very necessary.
100541 The implementation principle of the phase barrel is to regard the phase barrel as a result statistics machine. Each node of the state blockchain receives a state transaction from all nodes involved in the execution of the contract in the blockchain. For each stage of contract LEGAL_28652067 1 - 8 -execution, the transaction blockchain will label the phase barrel with the unique name (for example, "the name of the contract's account + the number of times the contract has been triggered [that is, the total number of times the contract has been executed]
+ the stage label of execution of the contract").
100551 At the first receipt of a new phase status transaction from some transaction blockchain node, the phase bucket is established, and then each time state blockchain nodes receive the status transactions from the nodes of transaction blockchain, the information will be put into the corresponding phase bucket. This shows that the phase bucket is storing the same content information from different nodes of the transaction blockchain. When the number of the same content information in a bucket exceeds 2/3 of the total number of transaction block nodes within a specified time limit, the phase bucket reaches agreement; otherwise, the content of the bucket cannot reach consensus, that is, it becomes a waste bucket.
100561 The introduction of phase buckets solves the problem of state synchronization of concurrent execution of contracts at multiple nodes and improves the ability of blockchain systems to support the execution of complex intelligent contracts. First, the phase buckets ensure data consistency so that uniform results can be obtained when multiple independent nodes execute the contract at the same time. In addition, the phase barrel ensures the integrity of the data. Due to the presence of the phase barrel, the failure of a few nodes does not affect the accuracy and reliability of the data. Thirdly, the bucket ensures the data isolation. As mentioned above, a complex contract usually has a long execution cycle and has multiple phases. The bucket enables correct synchronization among different execution phases of the same contract or different triggered turns of the same contract. In the system, there may be more than one complex contract in execution at the same time, or it may be that different transactions trigger multiple executions of the same contract in different execution rounds, and data synchronizations of different contracts do not interfere with each other.
100571 V. Waste Buckets LEGAL_28652067 1 - 9 -If the opinions in a phase bucket cannot reach consensus after a predetermined period, it will become a waste bucket. Waste buckets cannot help the state synchronization, it should be destroyed in time to avoid wasting resources. There are many reasons for having waste buckets:
First, the votes of all nodes executing the contract have been collected in the bucket, but no agreement has been reached which mean the total number of identical status messages is less than 2/3 of the total number of nodes;
[00601 Second, an individual node executing a smart contract performs slowly and when it sends its own sTx to the state blockchain, the state blockchain has completed state statistics for that phase, i.e., more than 2/3 of the nodes have already made consensus, the status blockchain will create a new bucket for the old sTx and wait for more comings of the out of date status that can never happen.
Third, due to unknown reasons, some sTx fail to reach the state blockchain, or some nodes fail to send sTx successfully, the status statistics of a stage cannot reach more than 2/3 of the total number of nodes executing the contract.
The first case is due to errors, which means that more than 1/3 of the nodes that execute the contract are not in the same state. If so the subsequent states of the contract are no longer counted, just record the source account address and the current execution number (the execution times this contract has been activated), if subsequent sTx has the same execution number of the same contract, it will be discarded directly.
In the second case, the system dynamically maintains a status table for the phase bucket that has been agreed upon in the most recent period. When the phase bucket is destroyed, the tag names of the bucket is recorded in the table and the accumulated opinions. If the subsequent sTx has tag name matches the tag name recorded in the table, discard the sTx directly and increment by one, the count of total number of opinions accumulated under that tag name.
When the total number of opinions accumulated on one stage bucket reaches the total number of LEGAL_28652067 1 - 10 -all nodes executing the contract, that is, all nodes executing the contract have completed this stage or the cache record has exceeded a certain time limit, the record is written to log, and then cleared from the Status Table.
100641 In the third case, the system starts a timer every time a new bucket is created. When a bucket has not reached the same state after a period, the system will destroy the bucket. The reason is that under normal conditions, the execution speed of each node should not differ too much from each other, and therefore, the intervals receiving status confirmation from most nodes for the same phase will not be too long. If it has not been agreed for a long time, it is likely that agreement will not be reached for this stage.
100651 Since the state blockchain does not know how many state changes a specific contract involves in execution, the state blockchain creates a new phase barrel for each emerging phase, as described above, and make statistics on the status consistent. However, if the opinions in the phase barrels cannot be agreed for a long time (that is, the waste barrels are generated), and the proper treatment cannot be done, it will cause enormous waste of resources, causing the system performance to deteriorate or even affect the stability of the system.
Therefore, the above processing mechanism is essential.
[0066] Example [0067] The system in this implementation involves a plurality of nodes, each node deploys the same smart contract, and the smart contract exists as part of the contractual account. Since the information of each node in the block chain system needs to be consistent, for each node in the system the same smart contracts are deployed.
100681 The smart contracts involved in this specific implementation are of a complex type, usually having a long execution cycle, multiple phases, and possibly multiple changes of state, and the system will make a state synchronization at the end of each phase if there is any change of state.
LEGAL_28652067 1 - 11 -It is assumed that there are four nodes A, B, C and D in the transaction blockchain system and four nodes E, F, G and H in the state blockchain. One intelligent contract M is executed in three stages, Respectively, a, b, c, each of which may involve one or more changes in state, intelligent contracts execution on ABCD the four nodes are simultaneously triggered. For each node of ABCD, at the end of each phase. If this phase involves a change of state, the changed state needs to be synchronized to the state blockchain. Therefore, node ABCD needs to send sTx to the state block chain for state synchronization.
[0070]
However, in practice, not only different operating environments exist among different nodes, but the execution speed may also be different. That is, although each of the nodes ABCD begins to execute the smart contract M at the same time, they may not be able to complete a, b , c three stages in the meantime.
[0071]
It is assumed that after the intelligent contract M has been triggered to execute for a period of time, at the moment tithe execution states of the four ABCD nodes are as follows:
[0072]
Node A: Stage a has been executed, stage b is in progress, sTx (a) has been sent to the state blockchain;
Node B: in the progress of Phase a, has not yet sent state transaction information to the state blockchain;
Node C: has completed stage a, b, and is currently in stage c, sTx (a), sTx (b) have been sent to the state blockchain;
Node D: Stage a is done, stage b is in progress, sTx (a) has been sent to the state blockchain.
State transactions are broadcast to each node in the state blockchain, so node EFGH
can receive these state transaction information from the ABCD. Node EFGH
perform the same operations on each node. Take node E as an example. Since there are two types of state information of different phases received at time t/, they are phase a and phase b respectively.
Therefore, there are two phase buckets. At t/ time the phase buckets in node E
are as shown in Table 1:
Table 1 Node E's phase buckets at time t1 Phase bucket of stage a Phase bucket of stage b sTx(a) from node A sTx(b) from node C
sTx(a) from node C
sTx(a) from node D
[0077]
At time a, the same opinions collected in the phase bucket for contract stage a has exceeded 2/3 of the total number of nodes (4 nodes in this example) of the transaction blockchain. It has been agreed that sTx (a) will be written to the state blockchain, according to the strategy described in this article, this stage bucket will be deleted.
[0078]
After a period, arriving at time 12, the execution status of ABCD four nodes are as follows:
[0079]
Node A: has completed stage a, b, stage c is in process, and sTx (b) is sent to the state blockchain after t/;
Node 13: has completed stage a, b and c. After t/, sTx (a), sTx (b) and sTx (c) are also sent to the state blockchain.
100811 Node C: Stage a, b and c are done. After ti, sTx (c) is sent to the state blockchain.
[0082]
Node D: Stage a, b are done, stage c is in process, and sTx (b) is sent to the state blockchain after 11.
100831 At the moment of 12, the phase buckets in node E are shown in Table
Background Art A complex smart contract, is the implementation of a long, complex logic of a contract, usually involving multiple stages. In a blockchain system, a smart contract needs to be deployed on all nodes, and the smart contract requires every node in the system to execute simultaneously at each execution, so that all node states are consistent.
In practice, the environment and capabilities of each node in the blockchain system may be different, and the smart contracts may run at different nodes at different speeds. In addition, the logic is complex and the smart contracts may change the state of the node at any stage of operation.
Existing solutions in the prior art have not yet addressed scenarios involving different node capabilities or environments in relation to smart contract execution. It is thus possible for asynchronous contract execution states to occur and a blockchain system may fail to support execution of complex smart contracts. At the same time, it is difficult to achieve the consistency, integrity and isolation of data when multiple independent nodes execute the contract at the same time. Data synchronization activities at different nodes may interfere with each other.
[0005j It is therefore desirable to have a blockchain system that permits the reliable execution of complex smart contracts.
Summary of Invention LEGAL_28652067.2 - 1 -loll 352-256543-KB/TT
In accordance with an aspect of the present invention, there is provided a phase-bucket-based method for complex smart contract state synchronization that allows for differences in node environments for executing smart contracts and differences in speed when executing the same smart contract. The method comprises (1) determining the status of the type of transaction, to determine the need to update the status of the account address; (2) according to the state of the transaction information, generating buckets, and then setting a timer for each bucket; (3) tallying phase bucket status information, and respectively tallying the number of each type of message; (4) checking the result of step (3) to determine whether a certain bucket has reached an agreement; proceeding to step (5) if agreement has been reached;
otherwise, proceeding to step (7); (5) storing the state information into the state blockchain; (6) marking the bucket as "agreed" and deleting the bucket; (7) checking whether the bucket timer has expired or not (8), continuing to mark the stage bucket as "has timed out", and then deleting the stage bucket, called "waste bucket".
Brief Description of Drawings [0007]
In the figures, which illustrate by way of example only, embodiments of the present invention, [0008]
FIG. 1 is a schematic diagram of a simple account structure according to an exemplary embodiment of the present invention;
[0009]
FIG. 2 is a schematic diagram of the structure of a complex contract account according to an exemplary embodiment of the present invention; and [0010]
FIG. 3 is a schematic diagram of a state synchronization process according to an exemplary embodiment of the present invention.
Description of Embodiments LEGAL_28652067.2 - 2 -[0011]
A description of various embodiments of the present invention is provided.
Specific implementations of exemplary embodiments will be described in detail, with reference to the accompanying drawings. The same reference numerals in the drawings will be used identify the same or similar parts or portions. The drawings are not necessarily drawn to scale.
In this disclosure, the use of the word "a" or -an" when used herein in conjunction with the term -comprising" may mean "one," but it is also consistent with the meaning of "one or more," "at least one- and "one or more than one." Any element expressed in the singular form also encompasses its plural form. Any element expressed in the plural form also encompasses its singular form. The term "plurality" as used herein means more than one, for example, two or more, three or more, four or more, and the like. Directional terms such as "top,"
"bottom,- -upwards," "downwards," "vertically," and "laterally" are used for the purpose of providing relative reference only, and are not intended to suggest any limitations on how any article is to be positioned during use, or to be mounted in an assembly or relative to an environment.
[0013]
The terms -comprising", -having", "including", and "containing", and grammatical variations thereof, are inclusive or open-ended and do not exclude additional, un-recited elements and/or method steps. The term "consisting essentially of' when used herein in connection with a composition, use or method, denotes that additional elements, method steps or both additional elements and method steps may be present, but that these additions do not materially affect the manner in which the recited composition, method, or use functions. The term -consisting of' when used herein in connection with a composition, use, or method, excludes the presence of additional elements and/or method steps.
[0014]
An objective of the present invention is to provide a phase-bucket-based method for complex smart contract state synchronization that allows for differences in node environments for executing smart contracts and differences in speed when executing the same smart contract, comprising the following steps: (1) determine the status of the type of transaction, to determine the need to update the status of the account address; (2) according to the state of the transaction information, generate buckets, and then set a timer for each bucket; (3) tally phase bucket status LEGAL_28652067 1 - 3 -information, and respectively tally the number of each type of message; (4) check the result of step (3) to determine whether a certain bucket has reached an agreement;
proceeding to step (5) if agreement has been reached; otherwise, proceed to step (7); (5)store the state information into the state blockchain; (6) mark the bucket as "agreed" and then delete the bucket; (7) check whether the bucket timer has expired or not (3), otherwise continue to step (8); and (8) mark the stage bucket as "has timed out", and then delete the stage bucket, which is called "waste bucket".
In an exemplary embodiment, the transaction of step (I) is sent from a transaction block chain.
In the exemplary embodiment, the information in step (2) includes the address of the contract account, the total number of times the contract account is triggered to be executed and the account address that needs to be changed, The state statistical information in the phase bucket in step (3) is the classification of the same content information from different nodes of the transaction block chain.
In step (4) the determination of whether a certain bucket has been agreed upon is to determine whether more than two-thirds of the contract execution nodes have the same status.
The "waste bucket" in step (8) is caused by a long-term inability to reach consensus in a bucket.
The waste bucket is generated if, although the nodes in the bucket have collected all the options from every contracts' execution nodes, the total number of the same status messages is less than 2/3 of the total number of nodes and no agreement is reached.
The waste bucket is due to the slow execution of the individual nodes executing the smart contract, when it sends its own status transaction (sTx) to the status block chain, the status block chain has completed the status statistics for that phase, over 2/3 of the nodes have agreed on the state change for this phase and has destroyed the corresponding phase bucket. The state LEGAL 28652067.2 - 4 -blockchain creates a new phase bucket for this sTx and waits for state statistics that can never be completed.
The waste bucket is generated due to some sTx failing to reach the state blockchain, or some nodes failing to send sTx successfully, resulting in less than two-thirds of the total number of nodes executing the contract for a certain stage.
After the waste bucket is generated, the subsequent status of the contract is no longer counted whether it is consistent or not. The source account address of the contract is recorded, as well as the current execution sequential number and the number of times the contract is activated. If the subsequent sTx is the status information of the same execution sequence number of the same contract, it is discarded directly.
[0024]
When individual nodes performing intelligent contracts execute slowly, the system dynamically maintains a status table for the phase buckets that have been confirmed to have reached a consensus and destroyed within a recent period, recording the tag name and the total number of opinions accumulated in the bucket at the time of destruction. If the subsequent sTx corresponding tag name matches the tag name recorded in the table, the sTx is directly discarded and the total number of opinions accumulated under the tag name is incremented by 1. When the total number of opinions cached for a stage bucket reaches the node number of all the nodes executing the contract, that is, all the nodes executing the contract have finished this stage, or when the cache record exceeds a certain time limit, the record is written into the log and then clear it in the table.
[0025]
When some sTx fails to reach the state blockchain, or some nodes fail to successfully send sTx, the system starts a timer each time a bucket is newly created. When a bucket expires after a period of time but the state consensus is not reached, the system will destroy the bucket.
[0026j One exemplary embodiment guarantees the consistent state of nodes performing intelligent contracts by using a "phase bucket" with individual storage on the blockchain, which improves the ability of the blockchain system to support the execution of complex smart LEGAL_28652067 1 - 5 -contracts. It assures the data consistency, uniformity of results, data integrity, and data segregation when multiple nodes execute contracts simultaneously, and data synchronization does not interfere with each other.
100271 Before proceeding with the description of certain specific implementations, some important concepts will now be described.
[0028] I. Account [0029] The smart contract is attached to an account and the structure of the account is described as follows:
[0030] (1) Activation Status: whether the account is activated or not. 0 represents it not activated, 1 represents it activated. If this field is 0, the account cannot send transactions, and ignores all transaction information sent to it except the activation information until it is re-activated;
[0031] (2) create time and update time: Record the time the account was created and the time of last update;
[0032] (3) Contract hash value: For the contract account, this field records the hash value of the contract code associated with the account. Once the account is generated, the value will not change.
[0033] (4) nonce: an integer that records the total number of transactions sent from the account address;
[0034] (5) number: record the number of transactions sent to the account address, record the number of times the contract was activated;
100351 (6) Account Type: Divided into two types, 1 for ordinary contract accounts, 2 for complex contract accounts;
LEGAL 28652067.1 - 6 -[0036] (7) account address: a 20-bit long string, uniquely identify an account in the system using the public key and private key generated by asymmetric encryption technology, and then do md5 hash to public key, take the last 20 characters as address;
100371 (8) Account Cache: Temporary records of temporary data generated during the execution of the contract.
[0038] For simple contracts, it is entirely possible to store the compiled binary data directly on the blockchain for faster loading. However, for complex smart contracts, if the files related to contract execution are directly stored on the blockchain, the block size may be too large.
Therefore, the complex contract only saves the addresses of the relevant files in the account to save space and save the files outside the blockchain. The structure of the account is shown in FIG. 1 and FIG. 2.
[0039] II. Transaction Blockchain and State Blockchain 100401 The transaction blockchain receives information from outside the blockchain system and stores this information in the block, and the execution of the smart contract is done in the nodes of the transaction blockchain.
[00411 State blockchain stores state information and maintains account information. It is responsible for the state synchronization and storage during and after executing smart contracts.
[0042] III. State Transaction [0043] During smart contract execution, when any operation affects the states, each contract execution node sends a status transaction (sTx) to the dedicated blockchain of state storage, for state synchronization. Status transaction (sTx) includes:
100441 (1) Source Address: address of the account that issued the status transaction;
[0045] (2) Public Key of the source account: the last 20 characters of hash value of the public key should be the same as the source address.
LEGAL_28652067 1 - 7 -100461 (3) Execution Information: The execution information of this contract, including the record of how many times this contract is executed;
100471 (4) Object Account Address: the account address whose status be changed;
100481 (5) Status Information: status change information, related to specific areas;
100491 (6) Signature: Use the private key of the source address to sign the digest summary aggregate with the object account address, execution information and status information;
100501 (7) Timestamp: the time the transaction was created.
100511 IV. Phase Bucket 100521 Smart contracts are executed simultaneously on all nodes in the transaction blockchain. Therefore, each node generates a status transaction when the status change operation occurs. In order to summarize and consolidate the status change results of each node, and maintain state blockchain's state consistency, the system establishes a bucket for each stage of the smart contract, each stage may have one or more times of status change.
100531 Complex types of smart contracts usually have long execution cycles and have multiple phases. When deploying and executing on multiple independent nodes simultaneously, there are differences in the execution speed of smart contracts due to the different environments of different nodes in practice. The synchronization of contract execution status becomes difficult.
For example, a smart contract is executed in three phases, a, b, and c, each of which may involve one or more state changes. Suppose that node (i+1) for some reason has just completed execution of phase a when node (i) has competed the execution of phase b, and the local state at this time cannot be synchronized directly, but needs to wait for b phase completion of node (i+1), in the scenario use the phase barrel to reduce the processing latency is very necessary.
100541 The implementation principle of the phase barrel is to regard the phase barrel as a result statistics machine. Each node of the state blockchain receives a state transaction from all nodes involved in the execution of the contract in the blockchain. For each stage of contract LEGAL_28652067 1 - 8 -execution, the transaction blockchain will label the phase barrel with the unique name (for example, "the name of the contract's account + the number of times the contract has been triggered [that is, the total number of times the contract has been executed]
+ the stage label of execution of the contract").
100551 At the first receipt of a new phase status transaction from some transaction blockchain node, the phase bucket is established, and then each time state blockchain nodes receive the status transactions from the nodes of transaction blockchain, the information will be put into the corresponding phase bucket. This shows that the phase bucket is storing the same content information from different nodes of the transaction blockchain. When the number of the same content information in a bucket exceeds 2/3 of the total number of transaction block nodes within a specified time limit, the phase bucket reaches agreement; otherwise, the content of the bucket cannot reach consensus, that is, it becomes a waste bucket.
100561 The introduction of phase buckets solves the problem of state synchronization of concurrent execution of contracts at multiple nodes and improves the ability of blockchain systems to support the execution of complex intelligent contracts. First, the phase buckets ensure data consistency so that uniform results can be obtained when multiple independent nodes execute the contract at the same time. In addition, the phase barrel ensures the integrity of the data. Due to the presence of the phase barrel, the failure of a few nodes does not affect the accuracy and reliability of the data. Thirdly, the bucket ensures the data isolation. As mentioned above, a complex contract usually has a long execution cycle and has multiple phases. The bucket enables correct synchronization among different execution phases of the same contract or different triggered turns of the same contract. In the system, there may be more than one complex contract in execution at the same time, or it may be that different transactions trigger multiple executions of the same contract in different execution rounds, and data synchronizations of different contracts do not interfere with each other.
100571 V. Waste Buckets LEGAL_28652067 1 - 9 -If the opinions in a phase bucket cannot reach consensus after a predetermined period, it will become a waste bucket. Waste buckets cannot help the state synchronization, it should be destroyed in time to avoid wasting resources. There are many reasons for having waste buckets:
First, the votes of all nodes executing the contract have been collected in the bucket, but no agreement has been reached which mean the total number of identical status messages is less than 2/3 of the total number of nodes;
[00601 Second, an individual node executing a smart contract performs slowly and when it sends its own sTx to the state blockchain, the state blockchain has completed state statistics for that phase, i.e., more than 2/3 of the nodes have already made consensus, the status blockchain will create a new bucket for the old sTx and wait for more comings of the out of date status that can never happen.
Third, due to unknown reasons, some sTx fail to reach the state blockchain, or some nodes fail to send sTx successfully, the status statistics of a stage cannot reach more than 2/3 of the total number of nodes executing the contract.
The first case is due to errors, which means that more than 1/3 of the nodes that execute the contract are not in the same state. If so the subsequent states of the contract are no longer counted, just record the source account address and the current execution number (the execution times this contract has been activated), if subsequent sTx has the same execution number of the same contract, it will be discarded directly.
In the second case, the system dynamically maintains a status table for the phase bucket that has been agreed upon in the most recent period. When the phase bucket is destroyed, the tag names of the bucket is recorded in the table and the accumulated opinions. If the subsequent sTx has tag name matches the tag name recorded in the table, discard the sTx directly and increment by one, the count of total number of opinions accumulated under that tag name.
When the total number of opinions accumulated on one stage bucket reaches the total number of LEGAL_28652067 1 - 10 -all nodes executing the contract, that is, all nodes executing the contract have completed this stage or the cache record has exceeded a certain time limit, the record is written to log, and then cleared from the Status Table.
100641 In the third case, the system starts a timer every time a new bucket is created. When a bucket has not reached the same state after a period, the system will destroy the bucket. The reason is that under normal conditions, the execution speed of each node should not differ too much from each other, and therefore, the intervals receiving status confirmation from most nodes for the same phase will not be too long. If it has not been agreed for a long time, it is likely that agreement will not be reached for this stage.
100651 Since the state blockchain does not know how many state changes a specific contract involves in execution, the state blockchain creates a new phase barrel for each emerging phase, as described above, and make statistics on the status consistent. However, if the opinions in the phase barrels cannot be agreed for a long time (that is, the waste barrels are generated), and the proper treatment cannot be done, it will cause enormous waste of resources, causing the system performance to deteriorate or even affect the stability of the system.
Therefore, the above processing mechanism is essential.
[0066] Example [0067] The system in this implementation involves a plurality of nodes, each node deploys the same smart contract, and the smart contract exists as part of the contractual account. Since the information of each node in the block chain system needs to be consistent, for each node in the system the same smart contracts are deployed.
100681 The smart contracts involved in this specific implementation are of a complex type, usually having a long execution cycle, multiple phases, and possibly multiple changes of state, and the system will make a state synchronization at the end of each phase if there is any change of state.
LEGAL_28652067 1 - 11 -It is assumed that there are four nodes A, B, C and D in the transaction blockchain system and four nodes E, F, G and H in the state blockchain. One intelligent contract M is executed in three stages, Respectively, a, b, c, each of which may involve one or more changes in state, intelligent contracts execution on ABCD the four nodes are simultaneously triggered. For each node of ABCD, at the end of each phase. If this phase involves a change of state, the changed state needs to be synchronized to the state blockchain. Therefore, node ABCD needs to send sTx to the state block chain for state synchronization.
[0070]
However, in practice, not only different operating environments exist among different nodes, but the execution speed may also be different. That is, although each of the nodes ABCD begins to execute the smart contract M at the same time, they may not be able to complete a, b , c three stages in the meantime.
[0071]
It is assumed that after the intelligent contract M has been triggered to execute for a period of time, at the moment tithe execution states of the four ABCD nodes are as follows:
[0072]
Node A: Stage a has been executed, stage b is in progress, sTx (a) has been sent to the state blockchain;
Node B: in the progress of Phase a, has not yet sent state transaction information to the state blockchain;
Node C: has completed stage a, b, and is currently in stage c, sTx (a), sTx (b) have been sent to the state blockchain;
Node D: Stage a is done, stage b is in progress, sTx (a) has been sent to the state blockchain.
State transactions are broadcast to each node in the state blockchain, so node EFGH
can receive these state transaction information from the ABCD. Node EFGH
perform the same operations on each node. Take node E as an example. Since there are two types of state information of different phases received at time t/, they are phase a and phase b respectively.
Therefore, there are two phase buckets. At t/ time the phase buckets in node E
are as shown in Table 1:
Table 1 Node E's phase buckets at time t1 Phase bucket of stage a Phase bucket of stage b sTx(a) from node A sTx(b) from node C
sTx(a) from node C
sTx(a) from node D
[0077]
At time a, the same opinions collected in the phase bucket for contract stage a has exceeded 2/3 of the total number of nodes (4 nodes in this example) of the transaction blockchain. It has been agreed that sTx (a) will be written to the state blockchain, according to the strategy described in this article, this stage bucket will be deleted.
[0078]
After a period, arriving at time 12, the execution status of ABCD four nodes are as follows:
[0079]
Node A: has completed stage a, b, stage c is in process, and sTx (b) is sent to the state blockchain after t/;
Node 13: has completed stage a, b and c. After t/, sTx (a), sTx (b) and sTx (c) are also sent to the state blockchain.
100811 Node C: Stage a, b and c are done. After ti, sTx (c) is sent to the state blockchain.
[0082]
Node D: Stage a, b are done, stage c is in process, and sTx (b) is sent to the state blockchain after 11.
100831 At the moment of 12, the phase buckets in node E are shown in Table
2:
LEGAL_28652067 1 - 13 -Table 2, node E stage buckets at time 12 Phase bucket of stage b Phase bucket of stage c sTx(b) from node c sTx(c) from node b sTx(b) from node a sTx(c) from node c sTx(b) from node b sTx(b) from node d [0084]
At time t2, the bucket corresponding to contract stage b has already got the state transactions from node ABCD of the transaction blockchain. If the number of the same opinions in the bucket exceeds 2/3 of the total number of transaction blockchain nodes, the bucket will be deleted, and sTx (b) is written to the state blockchain. The phase bucket corresponding to the contract phase c is still waiting for the state transactions of the nodes A
and D. After a certain period of time the state blockchain will not wait for the synchronization of sTx (c), thus sTx (c) will not be written to the state blockchain, so sTx (c) will not be agreed eventually.
[0085]
FIG. 3 depicts a flowchart of an exemplary process. In step (1), the system analyses the transaction phase, and in step (2) creates a phase bucket and starts a timer. In step (3), the process tallies the information in the phase buckets and in step (4) evaluates if a consensus has been reached. If a consensus has been reached then the process records the phase in SBV in step (5), and then records that consensus has been reached in step (6) before terminating. If a consensus has not been reached in step (4) then the process asks if the timer has expired in step (7) and if so, records that the timer has expired in step (8). The process then terminates.
Having thus described, by way of example only, embodiments of the present invention, it is to be understood that the invention as defined by the appended claims is not to be limited by particular details set forth in the above description of exemplary embodiments as many variations and permutations are possible without departing from the scope of the claims.
LEGAL 28652067.2 - 14 -
LEGAL_28652067 1 - 13 -Table 2, node E stage buckets at time 12 Phase bucket of stage b Phase bucket of stage c sTx(b) from node c sTx(c) from node b sTx(b) from node a sTx(c) from node c sTx(b) from node b sTx(b) from node d [0084]
At time t2, the bucket corresponding to contract stage b has already got the state transactions from node ABCD of the transaction blockchain. If the number of the same opinions in the bucket exceeds 2/3 of the total number of transaction blockchain nodes, the bucket will be deleted, and sTx (b) is written to the state blockchain. The phase bucket corresponding to the contract phase c is still waiting for the state transactions of the nodes A
and D. After a certain period of time the state blockchain will not wait for the synchronization of sTx (c), thus sTx (c) will not be written to the state blockchain, so sTx (c) will not be agreed eventually.
[0085]
FIG. 3 depicts a flowchart of an exemplary process. In step (1), the system analyses the transaction phase, and in step (2) creates a phase bucket and starts a timer. In step (3), the process tallies the information in the phase buckets and in step (4) evaluates if a consensus has been reached. If a consensus has been reached then the process records the phase in SBV in step (5), and then records that consensus has been reached in step (6) before terminating. If a consensus has not been reached in step (4) then the process asks if the timer has expired in step (7) and if so, records that the timer has expired in step (8). The process then terminates.
Having thus described, by way of example only, embodiments of the present invention, it is to be understood that the invention as defined by the appended claims is not to be limited by particular details set forth in the above description of exemplary embodiments as many variations and permutations are possible without departing from the scope of the claims.
LEGAL 28652067.2 - 14 -
Claims (12)
1. A method of state synchronization in a blockchain system executing a complex smart contract based on phase buckets, the method comprising:
(1) determining a status of a transaction of the contract, to determine the need to update a status of an account address associated with the contract;
(2) based on information on the state of the transaction, generating said buckets and setting a timer for each of the buckets;
(3) receiving phase status transactions and storing them in a corresponding one the phase buckets, and tallying the number of status transactions;
(4) checking the result of step (3) to determine if a certain bucket in said phase buckets has reached agreement and if agreement has been reached, proceeding to step (5) but otherwise, continuing to step (7);
(5) storing the status into a status block chain;
(6) marking a stage barrel as "agreed" and deleting the stage barrel;
(7) checking whether the bucket timer has expired and if not, skipping to step (3); and (8) marking the stage of the bucket as "has timed out", and then deleting the stage of the bucket, whereby the deleted bucket is designated -a waste bucket".
(1) determining a status of a transaction of the contract, to determine the need to update a status of an account address associated with the contract;
(2) based on information on the state of the transaction, generating said buckets and setting a timer for each of the buckets;
(3) receiving phase status transactions and storing them in a corresponding one the phase buckets, and tallying the number of status transactions;
(4) checking the result of step (3) to determine if a certain bucket in said phase buckets has reached agreement and if agreement has been reached, proceeding to step (5) but otherwise, continuing to step (7);
(5) storing the status into a status block chain;
(6) marking a stage barrel as "agreed" and deleting the stage barrel;
(7) checking whether the bucket timer has expired and if not, skipping to step (3); and (8) marking the stage of the bucket as "has timed out", and then deleting the stage of the bucket, whereby the deleted bucket is designated -a waste bucket".
2. The method of claim 1, wherein the transaction of step (1) is sent from a transaction block chain.
3. The method of claim 1, wherein the information in the step (2) includes the address of the contractual account, the total number of times the contractual account is triggered to be executed, and the need to change account address.
4. The method of claim 1, wherein the method for synchronizing complex intelligent contract states based on phase barrels is characterized in that step (3) the state information in the statistic phase barrels is the state information of different nodes in the phase barrels from different nodes of the transaction blockchain, the same content information classified.
5. The method of claim 1, the method for synchronizing complex intelligent contract states based on phase bucket is characterized in that: the step (4) of determining whether a phase of the bucket has reached an agreement is to determine whether there are more than 2/3 of the contract execution nodes having the same status.
6. The method of claim 1, wherein step (8) said "waste bucket" is generated by a long-term inability of the opinions to reach consensus among buckets at a certain stage.
7. The method of claim 6, characterized in that the waste bucket is that the nodes in the bucket have collected all the opinions from each contracts execution node, but the total number of the same status messages is less than 2/3 of the total number of nodes so that not reach the agreement.
8. The method of claim 6, characterized in that: the waste bucket is caused by slow execution of an individual node executing an intelligent contract when it sends its own sTx to a state blockchain, the state blockchain has completed the stage of state statistics, more than two-thirds of the nodes have reached a consensus on the status of this stage, and has destroyed the corresponding phase bucket, the state blockchain will create a new bucket for this sTx and wait for status statistics that can never be completed.
9. The method of claim 6, characterized in that: the waste bucket is due to some sTx failing to reach the state blockchain, or some nodes fail to successfully send sTx Resulting the state statistics node number of a phase is less than 2/3 of the total number of nodes in the implementation of the contract.
10. The method of claim 7, characterized in that: after the waste buckets are generated, no longer counting the subsequent states of the contract whether or not they are consistent, recording the source account address and the current execution sequence number of the contract. If the subsequent sTx has the same execution sequence number of the same contract, it is directly discarded.
11. The method of claim 8, characterized in that, when the contract execution speed of some individual nodes is slow, for the phase buckets which have been confirmed to be agreed in the most recent period, the system dynamics maintain a "state table" that records the bucket's tag name in the table when the bucket is destroyed and the total number of opinions accumulated in the bucket at the time of destruction, and if the subsequent sTx corresponding tag name matches the tag name recorded in the table, Discard the sTx and add 1 to the total number of opinions accumulated under the tag name. When the total number of opinions accumulated in a bucket cache record reaches the number of all nodes executing the contract, that is, all nodes executing the contract have already performed this phase, Or the cache record exceeds a certain time limit, the record is written to the log and then cleared in the State Table.
12. The method of claim 9, characterized in that when some sTx fails to reach the state blockchain or some nodes fail to send sTx successfully, When a new bucket is started, a timer is started. When a bucket has not reached the same state with others after a period of time, the system will destroy the bucket.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2995177A CA2995177A1 (en) | 2018-02-14 | 2018-02-14 | A method of state synchronization for complex smart contracts based on stage buckets |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA2995177A CA2995177A1 (en) | 2018-02-14 | 2018-02-14 | A method of state synchronization for complex smart contracts based on stage buckets |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2995177A1 true CA2995177A1 (en) | 2019-08-14 |
Family
ID=68095892
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2995177A Abandoned CA2995177A1 (en) | 2018-02-14 | 2018-02-14 | A method of state synchronization for complex smart contracts based on stage buckets |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2995177A1 (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111008218A (en) * | 2019-12-04 | 2020-04-14 | 福州博泉网络科技有限公司 | Method and system for structured storage of data on block chain |
| CN111813866A (en) * | 2020-07-30 | 2020-10-23 | 河南中盾云安信息科技有限公司 | Improved block chain account book synchronization method |
| EP3989149A4 (en) * | 2019-09-24 | 2023-06-07 | Jingdong Technology Information Technology Co., Ltd. | Method and apparatus for executing smart contract |
| CN117350724A (en) * | 2023-12-04 | 2024-01-05 | 安徽中科晶格技术有限公司 | Intelligent contract operation method, device and storage medium based on account chain |
-
2018
- 2018-02-14 CA CA2995177A patent/CA2995177A1/en not_active Abandoned
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3989149A4 (en) * | 2019-09-24 | 2023-06-07 | Jingdong Technology Information Technology Co., Ltd. | Method and apparatus for executing smart contract |
| CN111008218A (en) * | 2019-12-04 | 2020-04-14 | 福州博泉网络科技有限公司 | Method and system for structured storage of data on block chain |
| CN111008218B (en) * | 2019-12-04 | 2022-05-24 | 福州博泉网络科技有限公司 | Method and system for structured storage of data on block chain |
| CN111813866A (en) * | 2020-07-30 | 2020-10-23 | 河南中盾云安信息科技有限公司 | Improved block chain account book synchronization method |
| CN111813866B (en) * | 2020-07-30 | 2021-03-16 | 河南中盾云安信息科技有限公司 | Improved block chain account book synchronization method |
| CN117350724A (en) * | 2023-12-04 | 2024-01-05 | 安徽中科晶格技术有限公司 | Intelligent contract operation method, device and storage medium based on account chain |
| CN117350724B (en) * | 2023-12-04 | 2024-03-15 | 安徽中科晶格技术有限公司 | Intelligent contract operation method, device and storage medium based on account chain |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106407430B (en) | A kind of intelligent contract state synchronization method of complexity based on stage bucket | |
| CA2995177A1 (en) | A method of state synchronization for complex smart contracts based on stage buckets | |
| CN107577427B (en) | data migration method, device and storage medium for blockchain system | |
| CN109284073B (en) | Data storage method, device, system, server, control node and medium | |
| TWI669620B (en) | Database switching method, server, storage medium, electronic device and product | |
| CN108563502B (en) | Task scheduling method and device | |
| TW201800967A (en) | Method and device for processing distributed streaming data | |
| CN107391634B (en) | Data migration method and device | |
| CN104104717A (en) | Inputting channel data statistical method and device | |
| CN110704438B (en) | Method and device for generating bloom filter in blockchain | |
| CN112383610B (en) | Synchronous processing method and system for block chain state data | |
| WO2021012932A1 (en) | Transaction rollback method and device, database, system, and computer storage medium | |
| CN104794155A (en) | Data loading method, device and system | |
| CN106033322A (en) | Method and device for data storage | |
| WO2015087509A1 (en) | State storage and restoration device, state storage and restoration method, and storage medium | |
| US8224933B2 (en) | Method and apparatus for case-based service composition | |
| CN109471901B (en) | Data synchronization method and device | |
| CN112035418A (en) | Multi-computer room synchronization method, computing device and computer storage medium | |
| CN101833585A (en) | Database server operation control system, method and device | |
| CN110502574B (en) | Cross-system information synchronization method, user equipment, storage medium and device | |
| CN107608662B (en) | MongoDB-based distributed timing system | |
| US20110214130A1 (en) | Data processing system, data processing method, and data processing program | |
| CN109791541B (en) | Log serial number generation method and device and readable storage medium | |
| CN116627775B (en) | Writing optimization method and device for stateful server non-perception function | |
| US11853321B1 (en) | Data replication without in-place tombstones |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |
Effective date: 20201214 |