Note: Descriptions are shown in the official language in which they were submitted.
A Method of State Synchronization for Complex Smart Contracts Based on Stage
Buckets
Technical Field
100011
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
100021
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.
100031
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.
100041
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
CA 2995177 2018-02-14
100061
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 -
101 1352-256543-KB/TT
CA 2995177 2018-02-14
[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.
100121
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 -
1011152-256541-KB TT
CA 2995177 2018-02-14
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".
100151
In an exemplary embodiment, the transaction of step (I) is sent from a
transaction
block chain.
100161
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,
100171
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.
100181
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.
100191
The "waste bucket" in step (8) is caused by a long-term inability to reach
consensus
in a bucket.
100201
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.
100211
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 -
1152-256541-KB IT
CA 2995177 2018-02-14
blockchain creates a new phase bucket for this sTx and waits for state
statistics that can never be
completed.
100221
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.
100231
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 -
1011152-256541-KB TT
CA 2995177 2018-02-14
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 -
1011352-256543-KWTT
CA 2995177 2018-02-14
[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 -
1011152-256541-KB TT
CA 2995177 2018-02-14
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 -
1011352-256543-K13/TT
CA 2995177 2018-02-14
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 -
011352-256543-KB/IT
CA 2995177 2018-02-14
100581
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:
100591
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.
100611
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.
100621
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.
100631
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 -
1011152-256541-KB TT
CA 2995177 2018-02-14
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 -
1011 352-256543-KB/TT
CA 2995177 2018-02-14
100691
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;
100731
Node B: in the progress of Phase a, has not yet sent state transaction
information to
the state blockchain;
100741
Node C: has completed stage a, b, and is currently in stage c, sTx (a), sTx
(b) have
been sent to the state blockchain;
100751
Node D: Stage a is done, stage b is in progress, sTx (a) has been sent to the
state
blockchain.
100761
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.
LEGAL 28652067 1 - 12 -
1011352-256543-K13/TT
CA 2995177 2018-02-14
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/;
100801
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 -
1011352-256543-KB TT
CA 2995177 2018-02-14
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.
100861
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 -
1011152-256543-KB/TT
CA 2995177 2018-02-14
