CN117527832A - Transaction ordering method and device for blockchain, electronic equipment and storage medium - Google Patents
Transaction ordering method and device for blockchain, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN117527832A CN117527832A CN202410006430.8A CN202410006430A CN117527832A CN 117527832 A CN117527832 A CN 117527832A CN 202410006430 A CN202410006430 A CN 202410006430A CN 117527832 A CN117527832 A CN 117527832A
- Authority
- CN
- China
- Prior art keywords
- target
- ordering
- transaction
- state object
- parameter
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 54
- 238000004590 computer program Methods 0.000 claims description 24
- 238000010586 diagram Methods 0.000 description 16
- 230000008859 change Effects 0.000 description 8
- 230000006870 function Effects 0.000 description 5
- 230000008569 process Effects 0.000 description 5
- 230000000977 initiatory effect Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 238000012163 sequencing technique Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 230000002123 temporal effect Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000012913 prioritisation Methods 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000009472 formulation Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Technology Law (AREA)
- Strategic Management (AREA)
- Marketing (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Economics (AREA)
- Development Economics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application relates to the technical field of blockchains, and provides a blockchain transaction ordering method, a blockchain transaction ordering device, electronic equipment and a storage medium. The method is applied to the consensus node arranged in the block chain, and comprises the following steps: when a target transaction carrying target ordering parameters and sent by a client node of a blockchain is received, determining a target state object designated by the target transaction; wherein the target state object maintains relevant data for the target transaction; and determining the ordering of the target transaction in all the transactions of the specified target state object received by the consensus node according to the target ordering parameter. By adopting the method, the transactions received by the consensus nodes can be flexibly and effectively ordered, so that the business requirements of various transaction execution sequences are met.
Description
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a blockchain transaction ordering method, device, electronic apparatus, and storage medium.
Background
The blockchain belongs to a distributed system, each node of the blockchain is not synchronous in real time, and under the coordination of a consensus algorithm, the final consistency of each node at each stage time point can be ensured, so that the transaction received by the system in a period of time can be submitted and executed by all nodes. However, due to the unsynchronized nature of the network, it is uncertain when these transactions are received by the consensus node, in what order the consensus node submitted and executed the transactions. It can be seen that how to flexibly and effectively sort the transactions received by the consensus node becomes a technical problem that needs to be considered by those skilled in the art.
Disclosure of Invention
In view of this, the embodiments of the present application provide a transaction ordering method, apparatus, electronic device, and storage medium for a blockchain, which can flexibly and effectively order transactions received by a consensus node, so as to meet the business requirements of various transaction execution sequences.
A first aspect of an embodiment of the present application provides a transaction ordering method of a blockchain, applied to a consensus node provided in the blockchain, the method including:
when a target transaction carrying target ordering parameters and sent by a client node of a blockchain is received, determining a target state object designated by the target transaction; wherein the target state object maintains relevant data for the target transaction;
and determining the ordering of the target transaction in all the transactions of the specified target state object received by the consensus node according to the target ordering parameter.
In this embodiment of the present application, when a certain client node of a blockchain initiates a certain target transaction, a target state object specified by the target transaction and a target ordering parameter carried by the target state object may be set, where the target state object maintains relevant data of the target transaction. When the consensus node receives the target transaction, the ranking of the target transaction in all transactions of the specified target state object received by the consensus node can be determined according to the target ranking parameter. By setting in this way, assuming that a certain client node wants to limit the execution sequence of a part of transactions initiated by the client node, it is only necessary to set that the part of transactions all specify the same state object and respectively set corresponding different ordering parameters for each transaction, and then send the part of transactions to the consensus node. After receiving the part of the transactions, the consensus node sorts the transactions according to the sorting parameters carried by each transaction because the consensus node finds that the consensus node designates the same state object, so that the received transactions are flexibly and effectively sorted, and the business requirements of various transaction execution sequences are met.
In one implementation of an embodiment of the present application, determining a target state object specified by a target transaction includes:
determining a user account logged in by a client node;
and determining the state object owned by the user account as a target state object.
In one implementation of the embodiment of the present application, the user account has a plurality of state objects, and the target transaction also carries a state object identifier; determining a state object owned by the user account as a target state object, comprising:
and searching one state object corresponding to the state object identification from a plurality of state objects owned by the user account as a target state object.
In one implementation of the embodiments of the present application, the target state object also maintains ordering parameter variables; determining, based on the target ordering parameters, ordering of the target transaction among all transactions for which the consensus node has received the specified target state object, including:
if the relation between the target ordering parameter and the ordering parameter variable accords with the preset condition, determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter, and updating the numerical value of the ordering parameter variable into the target ordering parameter.
In one implementation manner of the embodiment of the present application, the method further includes:
if the relation between the target ordering parameter and the ordering parameter variable does not accord with the preset condition, the target transaction is refused to be executed, or the ordering of the target transaction is paused.
In one implementation of the embodiments of the present application, the ordering parameter variable includes a plurality of variables of different types; before determining the ordering of the target transaction among all transactions of the specified target state object that have been received by the consensus node according to the target ordering parameter, further comprising:
determining a state index according to the type of the target ordering parameter;
selecting a target variable corresponding to the state index from a plurality of variables of different types;
if the relation between the target ordering parameter and the ordering parameter variable accords with the preset condition, determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter, and updating the numerical value of the ordering parameter variable into the target ordering parameter, wherein the method specifically comprises the following steps:
if the relation between the target ordering parameter and the target variable accords with the preset condition, determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter, and updating the numerical value of the target variable into the target ordering parameter.
In one implementation manner of the embodiment of the present application, the related data is intelligent contract data, and the target ordering parameter is a priority parameter; determining, based on the target ordering parameters, ordering of the target transaction among all transactions for which the consensus node has received the specified target state object, including:
and determining the ordering of the target transaction in all the transactions which are received by the consensus node and are initiated by the user accounts and are assigned with the target state objects according to the priority parameters.
A second aspect of the embodiments of the present application provides a transaction ordering device of a blockchain, applied to a consensus node provided in the blockchain, the device including:
the transaction receiving module is used for determining a target state object designated by a target transaction when receiving the target transaction carrying the target ordering parameters and sent by the client node of the blockchain; wherein the target state object maintains relevant data for the target transaction;
and the transaction ordering module is used for determining the ordering of the target transaction in all the transactions of the specified target state object received by the consensus node according to the target ordering parameter.
A third aspect of the embodiments of the present application provides an electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, the processor implementing the transaction ordering method of the blockchain as provided in the first aspect of the embodiments of the present application when executing the computer program.
A fourth aspect of the embodiments of the present application provides a computer readable storage medium storing a computer program which, when executed by a processor, implements a method of transaction ordering for a blockchain as provided by the first aspect of the embodiments of the present application.
A fifth aspect of the embodiments of the present application provides a computer program product which, when run on an electronic device, causes the electronic device to perform a transaction ordering method of a blockchain as provided by the first aspect of the embodiments of the present application.
It will be appreciated that the advantages of the second to fifth aspects may be found in the relevant description of the first aspect, and are not described here again.
Drawings
FIG. 1 is a schematic diagram of a blockchain system provided in an embodiment of the present application;
FIG. 2 is a flow chart of a transaction ordering method for a blockchain provided in an embodiment of the present application;
FIG. 3 is a state update schematic diagram of a timestamp state object provided by an embodiment of the present application;
FIG. 4 is a schematic diagram of status update of a sequence number status object provided in an embodiment of the present application;
FIG. 5 is a schematic diagram of the relationship of user accounts, transactions and status objects provided by embodiments of the present application;
FIG. 6 is a schematic illustration of the execution of multiple transactions specifying a state object with multiple state indexes provided by an embodiment of the present application;
FIG. 7 is a schematic diagram of operations performed by proxy state objects for performing contract transactions, provided by embodiments of the present application;
FIG. 8 is a schematic diagram of determining transaction prioritization by way of multi-rule indexing provided by an embodiment of the present application;
FIG. 9 is a schematic diagram of a transaction ordering device for a blockchain according to an embodiment of the present application;
fig. 10 is a schematic diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail. In addition, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used merely to distinguish between descriptions and are not to be construed as indicating or implying relative importance.
Because of the asynchronous nature of the network, it is not possible for each client node in the blockchain system to determine when transactions sent to the consensus node are received by the consensus node, and in what order the consensus node submitted and performed the transactions. In order to meet the requirements of different transaction execution scenes, the embodiment of the application provides a transaction ordering method, device, electronic equipment and storage medium of a blockchain, which can flexibly and effectively order transactions received by a consensus node. For more specific technical implementation details of embodiments of the present application, please refer to various embodiments described below.
Fig. 1 is a schematic diagram of a blockchain system provided in an embodiment of the present application, where the blockchain system is provided with a plurality of client nodes and at least one consensus node, and the nodes may be communicatively connected to each other. Each client node can initiate respective transactions, which are sent to the consensus node, which orders the transactions according to a set ordering rule, and finally submits and executes the transactions in sequence. In order to meet the business requirements of various transaction execution sequences, the embodiment of the application provides a transaction ordering method based on a state object, and the method can be applied to any one of consensus nodes arranged in a blockchain system, and specific technical implementation details refer to the method embodiment described below.
Referring to fig. 2, a transaction ordering method for a blockchain according to an embodiment of the present application is shown, including:
201. when receiving a target transaction carrying target ordering parameters sent by a client node of a blockchain, the consensus node determines a target state object designated by the target transaction;
each transaction initiated by each client node of the blockchain system is sent to the consensus node, and the consensus node sorts all received transactions according to a set sorting rule, and then submits and executes the transactions in turn.
Since the embodiment of the application provides a transaction ordering method based on a state object, the state object is described in detail first.
The State objects (State objects) belong to the concept of a Multi-rule State machine MRSM (Multi-Rule State Machine), the State machines of different rules maintaining their State objects of the corresponding rule, i.e. one State Object for each State Object. The state object may be used to maintain data variables associated with transactions, and each time a change occurs to a data variable maintained by the state object, the state object may be considered to have updated state once. The data variables maintained by the state objects can be divided into two main categories, the first category is related data that the transaction needs to operate on, and the second category is ordering parameter variables. In actual operation, the consensus node may build each state machine through the ledger of the blockchain, thereby maintaining each state object.
As one example, the data variables maintained by the state object may also include ledger data for the blockchain, i.e., the data for the blockchain distributed ledger may be maintained by the state object, which may increase the flexibility of manipulating the ledger data.
Under the mechanism of a multi-rule state machine, the state objects can also have different types, and each type of state object corresponds to a rule state machine. The timestamp state object (TemporalState Object) and the sequence number state object (Sequential State Object) are described first below.
For transactions that wish to limit the execution order by time stamp, a time stamp status object may be specified. The timestamp state object may use a B-tree to implement a corresponding state tree, with the corresponding state machine executing transactions by timestamp ordering of the transactions, while rejecting state updates of the transaction attempts that are later in time, the ordering parameter variable maintained by the timestamp state object being a timestamp variable. As shown in fig. 3, a state update diagram of a timestamp state object is shown. In fig. 3, tx1, tx2, and Tx3 are respectively 3 transactions initiated by a client node that specify a certain timestamp state object. ts1 is the timestamp that the client node formulates for transaction Tx1, ts2 is the timestamp that the client node formulates for transaction Tx3, and ts3 is the timestamp that the client node formulates for transaction Tx2, wherein ts1 is earlier than ts2, ts2 is earlier than ts3, i.e., the order in which the client node desires the transactions to be performed is Tx1, tx3, tx2. When the consensus node receives Tx1, tx2 and Tx3, the timestamp variable maintained by the timestamp state object is updated in turn according to the timestamp formulated by each transaction, as shown in fig. 3, the timestamp variable maintained by the timestamp state object is updated in the order of ts1, ts2 and ts3, and each time the timestamp variable is updated, the state of the timestamp state object can be regarded as being updated once.
The use of the timestamp status object can limit the time range in which each transaction is ordered according to the sequence of the timestamps, i.e. determine a legal time range for the transaction to help in de-duplication. However, the use of timestamp state objects does not actually strictly specify the order of execution of transactions. For example, suppose there are three transactions updating the timestamp state object in order, with the specified timestamps being ts1, ts2, ts3, respectively, where ts1< ts2< ts3. Because of the asynchronous distributed system network, the consensus node may execute the transaction of ts1 and the transaction of ts3 when the transaction of ts2 is not received, so that the transaction of ts3 cannot be executed after the transaction of ts2, that is, the execution sequence of the transaction cannot be strictly defined. In general, the physical clocks of the blockchain nodes are different from one another, and simple timestamps are constrained only for the current node without additional protocols unifying the blockchain node physical clocks. For example, the current node caches the transaction within the time range of ts 1-ts 2, compares the newly accepted transaction with the transaction in the cache to judge whether the transaction is repeated, and the transaction exceeding the range is not accepted and the timestamp is considered illegal.
For transactions that wish to force a prescribed order of execution, a sequence number status object may be specified. The sequence number state object maintains a sequence number variable that indicates the current object's execution sequence number and can only accept transactions that set the next sequence number to change its state. As shown in fig. 4, a status update diagram of the serial number status object is shown. In fig. 4, tx1, tx2 and Tx3 are respectively 3 transactions initiated by the client node specifying a certain sequence number status object, seq1 is the sequence number formulated by the client node for transaction Tx1, seq2 is the sequence number formulated by the client node for transaction Tx3, and seq3 is the sequence number formulated by the client node for transaction Tx2, wherein seq1 < seq2 < seq3, i.e. the desired order of execution of the transactions by the client node is Tx1, tx3, tx2. When the consensus node receives Tx1, tx2 and Tx3, the sequence number variable maintained by the sequence number state object is updated in sequence according to the sequence number formulated by each transaction, as shown in fig. 4, the sequence number variable maintained by the sequence number state object is updated in the sequence of seq1, seq2 and seq3, and each time the sequence number variable is updated, the state of the sequence number state object can be regarded as being updated once.
Under the mechanism of a multi-rule state machine, in addition to the timestamp state object and the sequence number state object described above, theoretically, countless types of state objects can be set, and each type of state object corresponds to a rule state machine. In actual operation, the type of the state object may be implemented by an enumerated value, which facilitates the extension of the rule. For example, the type of the state object may be defined by the following code.
struct Transaction {
pub_key: bytes
signature: bytes
object_id: bytes
object_kind: StateObjectKind
...
}
enum StateObjectKind{
Temporal(int64)
Sequential(uint64)
...
}
In this piece of code, stateObjectKind represents the type of state object, where Temporal represents a time-stamped state object, sequential represents a sequence number state object, and in addition, numerous other types of state objects may be defined.
In one implementation of the embodiments of the present application, the state objects may be mutually bound to the user accounts, i.e., each user account may use a respective state object for limiting the execution sequence of the respective initiated transaction. Each user account may have one state object or may have multiple state objects. When a user account has only one state object, then all transactions initiated by the user account can only specify that state object. When a certain user account has a plurality of state objects, the user account can specify that different transactions respectively point to different state objects, so that the execution sequence of only part of the transactions can be limited, and the execution sequence of the different transactions is limited according to different rules.
In order to solve the problem of expansibility, one user account can operate state machines under different rules simultaneously, and initiate transactions of different rules, so that one user account can simultaneously have various different types of state objects, for example, can simultaneously have a timestamp state object and a serial number state object. For a user account having multiple state objects at the same time, when it initiates a transaction, the state object to be operated on is specified first. For example, if the transaction wants to specify a timestamp status object, a timestamp may be set for the transaction, and if the transaction wants to specify a sequence number status object, a sequence number may be set for the transaction.
In creating the state objects, the user accounts to which each state object belongs may be indicated, each state object may belong to one user account, and one user account may have a plurality of state objects of the same type or different types.
As shown in fig. 5, a relationship diagram of user accounts, transactions and status objects is shown. In fig. 5, user account a has timestamp state object 1, timestamp state object 2, sequence number state object 1, sequence number state object 2, and other state objects. The user account may change the state of multiple state objects simultaneously by sending multiple transactions, and may indicate the serial number of a sequence number state object in a transaction to ensure that the single state change is sequential. In addition, because the states of different state objects are independent of each other, for example, timestamp variables maintained by different timestamp state objects are independent of each other, sequence number variables maintained by different sequence number state objects are independent of each other, and sequencing parameter variables maintained by different regular state objects are independent of each other, when a user account initiates a batch of transactions to change the states of a plurality of different state objects simultaneously, the transactions of different target objects can be executed concurrently.
For example, user account A may initiate a transaction to update the state of timestamp state object 1, while also initiating a transaction to update the state of timestamp state object 2, or to update the states of sequence number state object 1 and sequence number state object 2. In addition, user account A may operate the serial number status objects in sequence by way of serial number formulation in the transaction. As shown in fig. 5, the user account a initiates three transactions of the designated serial number state object 1, namely Tx1 carrying serial number seq1, tx2 carrying serial number seq2 and Tx3 carrying serial number seq3, and the execution sequence of the three transactions is Tx1, tx2 and Tx3, so that the execution sequence of Tx1, tx2 and Tx3 is not affected even if the user account a initiates transactions of other state objects in the process. For example, assuming that user account A initiates transactions Tx1 'and Tx2' specifying sequence number state object 2, the order in which the two transactions are performed is Tx1', tx2', but the order in which transactions specifying different state objects are performed is not limited herein. That is, the final transaction execution order may be Tx1- > Tx2- > Tx1'- > Tx3- > Tx2', tx1- > Tx2- > Tx1'- > Tx2' - > Tx3 …, and so on. In general, the execution of transactions specifying different state objects may be parallel, in which case transactions Tx1, tx2, and Tx3 specifying sequence number state object 1, and transactions Tx1 'and Tx2' specifying sequence number state object 2 may be executed concurrently, e.g., tx1'- > Tx2' may be executed by thread 2 while Tx1- > Tx2- > Tx3 is executed by thread 1.
Assuming that a current client node initiates a transaction, called a target transaction, the following describes in detail how the consensus node orders the target transaction after receiving the target transaction.
As described above, the client node may specify a state object specified by the target transaction at the time of initiating the target transaction, the state object being represented by the target state object. For example, the target state object may be a timestamp state object, a sequence number state object, or another type of state object. The target state object typically maintains data related to the target transaction, and the data related to the target state object is updated as the target transaction is executed (e.g., various account amounts related to the target transaction change as it is executed). In addition, the client node needs to formulate a ranking parameter for the target transaction, which is represented by the target ranking parameter, for determining the ranking of the target transaction among all transactions for which the target state object is specified. Specifically, if the target transaction specifies a timestamp state object, the target ordering parameter is a timestamp formulated for the target transaction, if the target transaction specifies a sequence number state object, the target ordering parameter is a sequence number formulated for the target transaction, and so on.
The target transaction initiated by the client node is sent to the consensus node, and after the consensus node receives the target transaction, the state object specified by the target transaction, namely the target state object, is determined.
In one implementation of an embodiment of the present application, determining a target state object specified by a target transaction includes:
(1) Determining a user account logged in by a client node;
(2) And determining the state object owned by the user account as a target state object.
According to the foregoing description, each user account may only have one state object, and for this case, the consensus node only needs to determine the user account logged in to the client node, so as to determine the target state object specified by the target transaction. In actual operation, the consensus node may create and record a state object owned by each user account, and if it is determined that the user account logged in at the client node is user account a, the serial number state object 1 is determined to be the target state object, assuming that the state object owned by the recording user account a is serial number state object 1.
In one implementation of the embodiment of the present application, the user account has a plurality of state objects, and the target transaction also carries a state object identifier; determining a state object owned by the user account as a target state object, comprising:
And searching one state object corresponding to the state object identification from a plurality of state objects owned by the user account as a target state object.
In another embodiment, each user account may have multiple state objects, in which case the target state object cannot be determined from only the logged-in user account information. For example, assuming that user account a owns timestamp state object 1, timestamp state object 2, sequence number state object 1, sequence number state object 2, and other state objects, even if it can be determined that the user account logged in at the client node is user account a, it is still impossible to determine which state object the target state object is in particular that which user account a owns. For this case, the user account of the client node may formulate an identification of the state objects specified in the target transaction, i.e., the state object IDs, each having a respective unique state object identification. In this way, the target transaction carries the state object identifier, and after the consensus node acquires the state object identifier, the consensus node can find out the state object corresponding to the state object identifier from all the state objects owned by the user account A as the target state object.
202. And the consensus node determines the ordering of the target transaction in all the transactions of the specified target state object received by the consensus node according to the target ordering parameter.
After determining the target state object specified by the target transaction, the consensus node can acquire the target ordering parameters carried in the target transaction, and determine the ordering of the target transaction in all transactions of the specified target state object received by the consensus node based on the target ordering parameters. For example, if the target ordering parameter is a timestamp, the consensus node may compare the timestamp with the timestamps of all transactions that the consensus node has received for the specified target state object, ordering the transactions for all specified target state objects, including the target transaction, in the order of the timestamps. If the target ordering parameter is a sequence number, the consensus node may compare the sequence number with the sequence numbers of all transactions that the consensus node has received for the specified target state object, order the transactions for all specified target state objects including the target transaction in the order of sequence numbers, and so on.
In one implementation of the embodiments of the present application, the target state object also maintains ordering parameter variables; determining, based on the target ordering parameters, ordering of the target transaction among all transactions for which the consensus node has received the specified target state object, including:
If the relation between the target ordering parameter and the ordering parameter variable accords with the preset condition, determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter, and updating the numerical value of the ordering parameter variable into the target ordering parameter.
As described above, the state object may maintain a ranking parameter variable, and the type of target ranking parameter formulated by the client node for the target transaction should be the same as the type of ranking parameter variable maintained by the target state variable specified by the target transaction. Therefore, when the consensus node ranks the target transactions, the target ranking parameter and the ranking parameter variable maintained by the target state object can be compared to judge whether the relationship between the target ranking parameter and the ranking parameter variable accords with the preset condition, and when the relationship accords with the preset condition, the ranking of the target transactions in all transactions of the designated target state object received by the consensus node is determined according to the target ranking parameter, and then the numerical value of the ranking parameter variable can be updated into the target ranking parameter, namely the state of the target state object is changed.
In one implementation manner of the embodiment of the present application, the method further includes:
If the relation between the target ordering parameter and the ordering parameter variable does not accord with the preset condition, the target transaction is refused to be executed, or the ordering of the target transaction is paused.
If the relation between the target ordering parameter and the ordering parameter variable is found not to meet the preset condition, the consensus node can refuse to execute the target transaction or suspend the ordering of the target transaction.
As an example, assume that the target ordering parameter is a timestamp ts3, the target state object is a timestamp state object, and the ordering parameter variable maintained by the target state object is a timestamp variable, and the current value of the timestamp variable is ts2. The consensus node determines whether the target ordering parameter ts3 and the ordering parameter variable ts2 meet the condition that ts3 is later than ts2, and if so, determines ordering of the target transaction in all transactions of the specified target state object according to ts3, for example, ordering can be performed according to the sequence of time stamps. Then, the sorting parameter variable maintained by the target state object may be updated immediately, or after waiting for a certain period of time, the sorting parameter variable maintained by the target state object may be updated again, specifically by updating the sorting parameter variable from ts2 to ts3. If the target ranking parameter ts3 and the ranking parameter variable ts2 do not meet the condition that ts3 is later than ts2, the consensus node may refuse to execute the target transaction, indicating that the target transaction may be a repeated transaction with some incorrectly formulated timestamp. The consensus node does not sort the target transactions and can send corresponding prompt information to the client node initiating the target transactions, indicating that the client node can re-timestamp to initiate new transactions.
As another example, assuming the target ordering parameter is sequence number seq3, the target state object is a sequence number state object, and the ordering parameter variable maintained by the target state object is a sequence number variable, and the current value of the sequence number variable is seq2. The consensus node may determine whether the target ordering parameter seq3 is the next sequence number following the ordering parameter variable seq2, and if so, it indicates that the condition is met, and may determine the ordering of the target transaction in all transactions of the specified target state object according to seq3, for example, may order according to the sequence order of the sequence numbers. Then, the sorting parameter variable maintained by the target state object may be updated immediately, or after waiting for a certain period of time, the sorting parameter variable maintained by the target state object may be updated again, specifically by updating the sorting parameter variable from seq2 to seq3. If the target sorting parameter seq3 is not the next sequence number following the sorting parameter variable seq2, a non-compliance is indicated. This can be divided into two cases, (1) seq3 is less than seq2, which means that the target transaction may be a duplicate transaction of some incorrectly-ordered serial number and the consensus node may refuse to execute the target transaction. (2) seq3 is greater than the next sequence number of the next-order parameter variable seq2, which means that the consensus node has received the target transaction that needs to be executed later, and that some other transaction that needs to be executed before the target transaction (which carries the order parameter that is the next sequence number of the next-order parameter variable seq 2) has not been received by the consensus node. For this case, the consensus node may suspend the ordering of the target transaction, for example, the target transaction may be temporarily stored in a certain area, then, after receiving the other transaction and updating the ordering parameter variable, the target ordering parameter seq3 of the target transaction is acquired again and compared with the updated ordering parameter variable, and so on.
In one implementation of the embodiments of the present application, the ordering parameter variable includes a plurality of variables of different types; before determining the ordering of the target transaction among all transactions of the specified target state object that have been received by the consensus node according to the target ordering parameter, further comprising:
(1) Determining a state index according to the type of the target ordering parameter;
(2) And selecting a target variable corresponding to the state index from a plurality of variables of different types.
If the relation between the target ordering parameter and the ordering parameter variable accords with the preset condition, determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter, and updating the numerical value of the ordering parameter variable into the target ordering parameter, wherein the method specifically comprises the following steps:
if the relation between the target ordering parameter and the target variable accords with the preset condition, determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter, and updating the numerical value of the target variable into the target ordering parameter.
The multi-rule State machines may be co-incident, i.e., the same State object may have multiple State indexes (State indexes) in different rule State machines. The client node, upon initiating a transaction, may choose to specify a state index for the different rules, deciding which rule state machine to use to perform the transaction. For example, a state object may have both a timestamp state index (Temporal State Index) and a sequence number state index (Sequential State Index), a user may initiate multiple time-stamped or sequence number-stamped transactions, the sequence number-stamped transactions being performed in strict sequence with the sequence number, the time-stamped transactions being performed in sequence with the sequence of time stamps, and the time-stamped transactions being interleaved in the time-stamped transactions for submission and execution. In this case, the same state object may correspond to a plurality of state machines of different rules, so that the ordering parameter variable it maintains may also include a plurality of variables of different types, for example, one timestamp variable and one sequence number variable may be maintained at the same time. Assuming that the target state object is a state object of this type, the corresponding state index may be determined based on the type of the target ordering parameter, e.g. if the target ordering parameter is a time stamp, the time stamp state index is determined, and if the target ordering parameter is a sequence number, the sequence number state index is determined. According to the state index, a corresponding target variable can be found out from the different types of variables maintained by the target state object, for example, if the state index is a time stamp state index, the time stamp variable is used as the target variable, and if the state index is a serial number state index, the serial number variable is used as the target variable. The target ordering parameter and the target variable are compared in detail later, namely if the relation between the target ordering parameter and the target variable is found to meet the preset condition, the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node is determined according to the target ordering parameter. Then, the sorting parameter variable updated by the target state object is only the target variable (other sorting parameter variables are not updated), that is, the numerical value of the target variable is updated to the target sorting parameter.
As shown in FIG. 6, a diagram of the execution of multiple transactions specifying a state object for which multiple state indexes exist is shown. The state object shown in fig. 6 has two state indexes of a time stamp and a sequence number, the state object is updated by using the sequence number state indexes by the transaction Tx1 and Tx3 initiated by the client node, the state object is updated by using the time stamp state index by the transaction Tx2, and finally the execution sequence of the three transactions can be Tx1- > Tx2- > Tx3, tx1- > Tx3- > Tx2 or Tx2- > Tx1- > Tx3, that is, only the execution of Tx3 after Tx1 is guaranteed. Although these 3 transactions all specify the same state object, only certain state changes need to be guaranteed in order.
In one implementation manner of the embodiment of the present application, the related data is intelligent contract data, and the target ordering parameter is a priority parameter; determining, based on the target ordering parameters, ordering of the target transaction among all transactions for which the consensus node has received the specified target state object, including:
and determining the ordering of the target transaction in all the transactions which are received by the consensus node and are initiated by the user accounts and are assigned with the target state objects according to the priority parameters.
The embodiments of the present application also provide a special type of state object, which may be referred to as a smart contract state object, where the associated data maintained is data of a smart contract, so that each smart contract may be constructed as a smart contract state object. In the intelligent contract scenario, each different user account can operate the same intelligent contract, that is, the operation authority of the intelligent contract state object does not completely belong to the user account for creating the intelligent contract, and all user accounts in the blockchain can operate the state object for storing the intelligent contract data. Thus, the order of execution of all transactions operating the smart contract cannot be specified in the manner of the timestamp state variable or sequence number state variable described previously. Assuming that the target state object specified by the target transaction is an intelligent contract state object, the target ordering parameter formulated by the client node for the target transaction may be a priority parameter, where the priority parameter belongs to an ordering key value, and may specifically be parameters such as a transaction Gas Price or a transaction priority, where transactions of different user accounts compete for executing the order of the transactions by formulating the parameters. After receiving the target transaction, the consensus node determines the ordering of the target transaction in all transactions of the designated target state object (i.e. the intelligent contract state object) initiated by each user account, which the consensus node has received, according to the priority parameter carried by the target transaction. It should be noted that the transactions ordered herein may be transactions initiated by different user accounts, possibly from different client nodes, specifying respective priority parameters, and the consensus node orders the transactions according to the magnitude of the priority parameters, specifying the same smart contract state object.
Since the smart contract state object is not held by any user account alone, each user account can initiate a transaction designating the smart contract state object to update the smart contract data recorded by the smart contract state object, the operation of the smart contract state object is generally not sequentially constrained by a time stamp or a serial number, and the like, and a high-priced mode is generally adopted, so that transactions with higher priority parameters such as Gas Price can be preferentially executed to change the state of the smart contract state object. However, for a single user account, which may have a sequential requirement for operating the same smart contract, to meet this requirement, embodiments of the present application propose the concept of proxy state object (Agential State Object). The proxy state object itself does not belong to a new state object, which may be essentially a time-stamped state object or a serial number state object owned by the user account. In the manner described above, the user account may limit the order of execution of the multiple transactions initiated by itself by specifying a timestamp state object or a sequence number state object. When the user account wants to limit the execution sequence of a plurality of transactions operating the same smart contract, the user account only needs to respectively set a corresponding ordering parameter (such as a timestamp or a serial number) for each transaction, and then enables the transactions to all assign the same timestamp state object or serial number state object, wherein the assigned state object is the proxy state object. As shown in fig. 7, an operation diagram of performing a contract transaction through a proxy state object is shown. Assuming that a user account wants to operate on the same smart contract state object in sequence, a proxy state object may be created, then multiple transactions operating on the smart contract state object may all specify the proxy state object, and ordering parameters for each transaction may be formulated, e.g., 3 transactions Tx1, tx2, and Tx3, with ordering parameters seq1, seq2, and seq3, respectively, are constructed. In this way, the proxy state object can limit the transaction to be submitted and executed according to the sequence of Tx1- > Tx2- > Tx3, namely the effect of sequentially operating the same intelligent contract state object is realized, and in addition, the data change of the intelligent contract state object can be executed through the proxy state object.
To better receive and order transactions sent by the respective client nodes, the consensus node may use a Transaction Pool (Transaction Pool) with a Multi-Rule Index through which the respective transactions are received and ordered. The indexes of the multi-rule index may have different priorities, and in general, transaction attributes under non-state rules, such as transaction Gas Price and transaction priority, have higher sorting priority, that is, transactions with higher transaction Gas Price and transaction priority will be sorted in front, and are preferentially packed and submitted for execution. Transactions employing different state rules (e.g., time stamps or sequence numbers) may typically have the same ordering priority, and if the non-state rules of the transactions are identical in terms of their attributes, FIFO (i.e., first in first out) ordering may be used to order the transactions of the same priority.
FIG. 8 is a schematic diagram of determining transaction prioritization by way of multi-rule indexing. In fig. 8, from top to bottom, the highest priority transactions are seen to have the highest ranking priority, followed by transactions with different state rules of the same ranking priority, such as transactions ranked by time stamp, transactions ranked by sequence number, and so on. And finally, perfecting by utilizing the rule of the FIFO.
Transactions under the same rule are ranked using ranking parameters defined in the rule, e.g., transactions under the timestamp rule are ranked lower in priority for later time stamped transactions, which are packed for submission later, according to the size of the timestamp. Transactions under the sequence number rule are ordered according to the sequence number set by the transaction, and transactions with larger sequence numbers are ordered with lower priority and can be submitted only after transactions with their sequence numbers minus 1 are submitted.
The consensus node may determine the ordering of all received transactions sent by the various client nodes in the manner of the multi-rule index described above, and then package, submit, and execute the transactions in accordance with the ordering.
In this embodiment of the present application, when a certain client node of a blockchain initiates a certain target transaction, a target state object specified by the target transaction and a target ordering parameter carried by the target state object may be set, where the target state object maintains relevant data of the target transaction. When the consensus node receives the target transaction, the ranking of the target transaction in all transactions of the specified target state object received by the consensus node can be determined according to the target ranking parameter. By setting in this way, assuming that a certain client node wants to limit the execution sequence of a part of transactions initiated by the client node, it is only necessary to set that the part of transactions all specify the same state object and respectively set corresponding different ordering parameters for each transaction, and then send the part of transactions to the consensus node. After receiving the part of the transactions, the consensus node sorts the same state objects according to the sorting parameters carried by each transaction as the consensus node finds that the received transactions are all designated by the same state object, so that the received transactions are flexibly and effectively sorted.
In summary, the transaction ordering method provided by the embodiment of the application can meet the business requirements of various transaction execution sequences, is extensible, can make state objects of various ordering rules, and the blockchain system simultaneously supports various transaction ordering rules and corresponding state machine mechanisms of various rules, so that the ordering control of the transactions is very flexible, and the concurrency capability of the transaction execution is improved.
It should be understood that the sequence numbers of the steps in the foregoing embodiments do not mean the order of execution, and the execution order of the processes should be determined by the functions and the internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
The above mainly describes a transaction ordering method of a blockchain, and a transaction ordering device of a blockchain will be described below.
Referring to fig. 9, a transaction ordering device of a blockchain provided in an embodiment of the present application is applied to a common node provided in the blockchain, and includes:
the transaction receiving module 901 is configured to determine a target state object specified by a target transaction when receiving the target transaction carrying the target ordering parameter sent by a client node of the blockchain; wherein the target state object maintains relevant data for the target transaction;
The transaction ordering module 902 is configured to determine, according to the target ordering parameter, an ordering of the target transaction among all transactions that have been received by the consensus node and specify the target state object.
In one implementation of an embodiment of the present application, a transaction receiving module includes:
a user account determining unit, configured to determine a user account logged in by the client node;
and the state object determining unit is used for determining the state object owned by the user account as a target state object.
In one implementation of the embodiment of the present application, the user account has a plurality of state objects, and the target transaction also carries a state object identifier; the state object determination unit includes:
and the state object searching subunit is used for searching one state object corresponding to the state object identifier from a plurality of state objects owned by the user account as a target state object.
In one implementation of the embodiments of the present application, the target state object also maintains ordering parameter variables; the transaction ordering module comprises:
the first transaction ordering unit is used for determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter if the relation between the target ordering parameter and the ordering parameter variable accords with a preset condition, and updating the numerical value of the ordering parameter variable to the target ordering parameter.
In one implementation of an embodiment of the present application, the transaction ordering module further includes:
and the transaction refusing unit is used for refusing to execute the target transaction or suspending the sequencing of the target transaction if the relation between the target sequencing parameter and the sequencing parameter variable does not accord with the preset condition.
In one implementation of the embodiments of the present application, the ordering parameter variable includes a plurality of variables of different types; the transaction ordering module further includes:
the state index determining unit is used for determining a state index according to the type of the target ordering parameter;
the target variable selecting unit is used for selecting a target variable corresponding to the state index from a plurality of variables of different types;
the transaction ordering unit is specifically configured to: if the relation between the target ordering parameter and the target variable accords with the preset condition, determining the ordering of the target transaction in all transactions of the appointed target state object received by the consensus node according to the target ordering parameter, and updating the numerical value of the target variable into the target ordering parameter.
In one implementation manner of the embodiment of the present application, the related data is intelligent contract data, and the target ordering parameter is a priority parameter; the transaction ordering module comprises:
And the second transaction ordering unit is used for determining the ordering of the target transaction in all transactions of the specified target state object initiated by each user account, which are received by the consensus node, according to the priority parameter.
Embodiments of the present application also provide a computer readable storage medium storing a computer program that when executed by a processor implements the blockchain transaction ordering method described in any of the embodiments above.
Embodiments also provide a computer program product which, when run on an electronic device, causes the electronic device to perform a blockchain transaction ordering method as described in any of the embodiments above.
Fig. 10 is a schematic diagram of an electronic device according to an embodiment of the present application. As shown in fig. 10, the electronic device 10 of this embodiment includes: a processor 100, a memory 101 and a computer program 102 stored in the memory 101 and executable on the processor 100. The processor 100, when executing the computer program 102, implements the steps of embodiments of the transaction ordering method for each blockchain described above, such as steps 201 through 202 shown in fig. 2. Alternatively, the processor 100 may implement the functions of the modules/units in the above-described device embodiments when executing the computer program 102, for example, the functions of the modules 901 to 902 shown in fig. 9.
The computer program 102 may be partitioned into one or more modules/units that are stored in the memory 101 and executed by the processor 100 to complete the present application. The one or more modules/units may be a series of computer program instruction segments capable of performing particular functions for describing the execution of the computer program 102 in the electronic device 10.
The processor 100 may be a central processing unit (Central Processing Unit, CPU), other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 101 may be an internal storage unit of the electronic device 10, such as a hard disk or a memory of the electronic device 10. The memory 101 may also be an external storage device of the electronic device 10, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card) or the like, which are provided on the electronic device 10. Further, the memory 101 may also include both internal storage units and external storage devices of the electronic device 10. The memory 101 is used to store the computer program and other programs and data required by the electronic device. The memory 101 may also be used to temporarily store data that has been output or is to be output.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional distribution may be performed by different functional units and modules according to needs, i.e. the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-described functions. The functional units and modules in the embodiment may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.
It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the system embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection via interfaces, devices or units, which may be in electrical, mechanical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purposes of the embodiments of the present application.
In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the present application may implement all or part of the flow of the method of the above embodiment, or may be implemented by a computer program to instruct related hardware, where the computer program may be stored in a computer readable storage medium, and when the computer program is executed by a processor, the computer program may implement the steps of each method embodiment described above. Wherein the computer program comprises computer program code which may be in source code form, object code form, executable file or some intermediate form etc. The computer readable medium may include: any entity or device capable of carrying the computer program code, a recording medium, a U disk, a removable hard disk, a magnetic disk, an optical disk, a computer Memory, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), an electrical carrier signal, a telecommunications signal, a software distribution medium, and so forth. It should be noted that the computer readable medium may include content that is subject to appropriate increases and decreases as required by jurisdictions in which such content is subject to legislation and patent practice, such as in certain jurisdictions in which such content is not included as electrical carrier signals and telecommunication signals.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.
Claims (10)
1. A method for ordering transactions in a blockchain, the method being applied to consensus nodes provided in the blockchain, the method comprising:
when a target transaction carrying target ordering parameters and sent by a client node of the blockchain is received, determining a target state object appointed by the target transaction; wherein the target state object maintains relevant data for the target transaction;
and determining the ordering of the target transaction in all the transactions which are received by the consensus node and specify the target state object according to the target ordering parameter.
2. The method of claim 1, wherein the determining the target state object specified by the target transaction comprises:
Determining a user account logged in by the client node;
and determining the state object owned by the user account as the target state object.
3. The method of claim 2, wherein the user account has a plurality of status objects, the target transaction further carrying a status object identification; the determining the state object owned by the user account as the target state object comprises the following steps:
and searching one state object corresponding to the state object identification from a plurality of state objects owned by the user account as the target state object.
4. A method according to any one of claims 1 to 3, wherein the target state object also maintains a ranking parameter variable; the determining, according to the target ranking parameter, ranking of the target transaction among all transactions received by the consensus node and specifying the target state object includes:
if the relation between the target ordering parameter and the ordering parameter variable accords with a preset condition, determining ordering of the target transaction in all transactions which are received by the consensus node and specify the target state object according to the target ordering parameter, and updating the numerical value of the ordering parameter variable into the target ordering parameter.
5. The method as recited in claim 4, further comprising:
and if the relation between the target ordering parameter and the ordering parameter variable does not accord with a preset condition, refusing to execute the target transaction or suspending ordering of the target transaction.
6. The method of claim 4, wherein the ordering parameter variable comprises a plurality of variables of different types; before determining the ordering of the target transaction among all transactions received by the consensus node that specify the target state object according to the target ordering parameter, further comprising:
determining a state index according to the type of the target ordering parameter;
selecting a target variable corresponding to the state index from the plurality of variables of different types;
if the relation between the target ordering parameter and the ordering parameter variable accords with a preset condition, determining ordering of the target transaction in all transactions which are received by the consensus node and specify the target state object according to the target ordering parameter, and updating the numerical value of the ordering parameter variable into the target ordering parameter, wherein the method specifically comprises the following steps:
if the relation between the target sorting parameter and the target variable accords with a preset condition, determining sorting of the target transaction in all transactions which are received by the consensus node and specify the target state object according to the target sorting parameter, and updating the numerical value of the target variable into the target sorting parameter.
7. The method of claim 1, wherein the related data is smart contract data and the target ordering parameter is a priority parameter; the determining, according to the target ranking parameter, ranking of the target transaction among all transactions received by the consensus node and specifying the target state object includes:
and determining the ordering of the target transaction in all transactions which are initiated by the user accounts and specify the target state object and are received by the consensus node according to the priority parameter.
8. A transaction ordering device for a blockchain, the device being applied to a consensus node provided in the blockchain, the device comprising:
the transaction receiving module is used for determining a target state object appointed by the target transaction when receiving the target transaction carrying the target ordering parameter and sent by the client node of the blockchain; wherein the target state object maintains relevant data for the target transaction;
and the transaction ordering module is used for determining the ordering of the target transaction in all the transactions which are received by the consensus node and specify the target state object according to the target ordering parameter.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the blockchain transaction ordering method of any of claims 1 to 7 when the computer program is executed.
10. A computer readable storage medium storing a computer program, wherein the computer program when executed by a processor implements the blockchain transaction ordering method of any of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410006430.8A CN117527832A (en) | 2024-01-03 | 2024-01-03 | Transaction ordering method and device for blockchain, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410006430.8A CN117527832A (en) | 2024-01-03 | 2024-01-03 | Transaction ordering method and device for blockchain, electronic equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117527832A true CN117527832A (en) | 2024-02-06 |
Family
ID=89749748
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410006430.8A Pending CN117527832A (en) | 2024-01-03 | 2024-01-03 | Transaction ordering method and device for blockchain, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117527832A (en) |
Citations (28)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103282900A (en) * | 2010-10-27 | 2013-09-04 | 苹果公司 | Methods for indexing and searching based on language locale |
| CN106780025A (en) * | 2016-11-30 | 2017-05-31 | 中国银行股份有限公司 | The transfer method of digital asset, apparatus and system in block chain |
| CN108512775A (en) * | 2018-04-16 | 2018-09-07 | 杭州秘猿科技有限公司 | A kind of method and device of sequence transaction queue |
| CN110544095A (en) * | 2019-09-03 | 2019-12-06 | 腾讯科技（深圳）有限公司 | Transaction processing method of block chain network and block chain network |
| CN110915166A (en) * | 2017-07-14 | 2020-03-24 | 微软技术许可有限责任公司 | Block chain |
| CN110933108A (en) * | 2019-09-26 | 2020-03-27 | 腾讯科技（深圳）有限公司 | Data processing method and device based on block chain network, electronic equipment and storage medium |
| CN111008402A (en) * | 2018-10-08 | 2020-04-14 | 国际商业机器公司 | Block chain timestamp protocol |
| CN111241589A (en) * | 2018-11-29 | 2020-06-05 | 华为技术有限公司 | Database system, node and method |
| CN112036848A (en) * | 2020-08-21 | 2020-12-04 | 山东爱城市网信息技术有限公司 | Method for realizing transaction sequence fairness block chain consensus algorithm |
| CN112269423A (en) * | 2020-12-21 | 2021-01-26 | 支付宝(杭州)信息技术有限公司 | Method for locking global clock in blockchain system and blockchain system |
| CN112818014A (en) * | 2020-12-31 | 2021-05-18 | 杭州趣链科技有限公司 | Block chain data analysis method and device and electronic equipment |
| CN112883015A (en) * | 2021-04-23 | 2021-06-01 | 北京中科金财科技股份有限公司 | Block chain data management method, device and storage medium |
| CN113362062A (en) * | 2021-05-21 | 2021-09-07 | 山东大学 | Block chain transaction sorting method, storage medium and equipment |
| CN113537991A (en) * | 2021-09-16 | 2021-10-22 | 中国信息通信研究院 | Cross-chain transaction ordered execution method and cross-chain system |
| CN113656504A (en) * | 2021-08-23 | 2021-11-16 | 武汉科技大学 | Block chain transaction submitting, editing and inquiring method based on time sequence attribute |
| CN113656510A (en) * | 2021-08-26 | 2021-11-16 | 支付宝(杭州)信息技术有限公司 | Method and device for executing transaction in blockchain system |
| CN113743940A (en) * | 2021-11-04 | 2021-12-03 | 支付宝(杭州)信息技术有限公司 | Method for executing transaction in block chain, main node and slave node |
| CN113901138A (en) * | 2021-09-27 | 2022-01-07 | 浪潮云信息技术股份公司 | MuSig 2-based block chain transaction multi-party endorsement method and system |
| CN114036577A (en) * | 2021-11-09 | 2022-02-11 | 南京大学 | Coalition chain-oriented supervision method and supervision digital twin model |
| US20220084128A1 (en) * | 2019-04-16 | 2022-03-17 | Erich Lawson Spangenberg | System and method for providing patent title insurance with centralized and distributed data architectures |
| CN114862589A (en) * | 2022-07-07 | 2022-08-05 | 中国长江三峡集团有限公司 | Transaction data processing method and device based on block chain and electronic equipment |
| CN115170312A (en) * | 2022-07-07 | 2022-10-11 | 中国银行股份有限公司 | Asset state information changing method and device on block chain |
| CN115827773A (en) * | 2022-09-13 | 2023-03-21 | 广州市汇方锐展计算机技术服务有限公司 | Data processing system, and storage medium and method for processing warehousing business documents of data processing system |
| WO2023040453A1 (en) * | 2021-09-15 | 2023-03-23 | 华为技术有限公司 | Transaction information processing method and apparatus |
| CN116361385A (en) * | 2022-09-01 | 2023-06-30 | 矩阵时光数字科技有限公司 | Block chain consensus method and system |
| CN116455974A (en) * | 2023-04-10 | 2023-07-18 | 网易（杭州）网络有限公司 | Transaction caching and ordering method, device, electronic equipment and storage medium |
| US20230245080A1 (en) * | 2020-04-21 | 2023-08-03 | Michael Anderson | Convergent Consensus Method for Distributed Ledger Transaction Processing |
| CN116977067A (en) * | 2023-01-31 | 2023-10-31 | 腾讯科技（深圳）有限公司 | Block chain-based data processing method, device, equipment and readable storage medium |
-
2024
- 2024-01-03 CN CN202410006430.8A patent/CN117527832A/en active Pending
Patent Citations (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103282900A (en) * | 2010-10-27 | 2013-09-04 | 苹果公司 | Methods for indexing and searching based on language locale |
| CN106780025A (en) * | 2016-11-30 | 2017-05-31 | 中国银行股份有限公司 | The transfer method of digital asset, apparatus and system in block chain |
| CN110915166A (en) * | 2017-07-14 | 2020-03-24 | 微软技术许可有限责任公司 | Block chain |
| CN108512775A (en) * | 2018-04-16 | 2018-09-07 | 杭州秘猿科技有限公司 | A kind of method and device of sequence transaction queue |
| CN112868210A (en) * | 2018-10-08 | 2021-05-28 | 国际商业机器公司 | Block chain timestamp protocol |
| CN111008402A (en) * | 2018-10-08 | 2020-04-14 | 国际商业机器公司 | Block chain timestamp protocol |
| CN111241589A (en) * | 2018-11-29 | 2020-06-05 | 华为技术有限公司 | Database system, node and method |
| US20220084128A1 (en) * | 2019-04-16 | 2022-03-17 | Erich Lawson Spangenberg | System and method for providing patent title insurance with centralized and distributed data architectures |
| CN110544095A (en) * | 2019-09-03 | 2019-12-06 | 腾讯科技（深圳）有限公司 | Transaction processing method of block chain network and block chain network |
| CN110933108A (en) * | 2019-09-26 | 2020-03-27 | 腾讯科技（深圳）有限公司 | Data processing method and device based on block chain network, electronic equipment and storage medium |
| US20230245080A1 (en) * | 2020-04-21 | 2023-08-03 | Michael Anderson | Convergent Consensus Method for Distributed Ledger Transaction Processing |
| CN112036848A (en) * | 2020-08-21 | 2020-12-04 | 山东爱城市网信息技术有限公司 | Method for realizing transaction sequence fairness block chain consensus algorithm |
| CN112269423A (en) * | 2020-12-21 | 2021-01-26 | 支付宝(杭州)信息技术有限公司 | Method for locking global clock in blockchain system and blockchain system |
| CN112818014A (en) * | 2020-12-31 | 2021-05-18 | 杭州趣链科技有限公司 | Block chain data analysis method and device and electronic equipment |
| CN112883015A (en) * | 2021-04-23 | 2021-06-01 | 北京中科金财科技股份有限公司 | Block chain data management method, device and storage medium |
| CN113362062A (en) * | 2021-05-21 | 2021-09-07 | 山东大学 | Block chain transaction sorting method, storage medium and equipment |
| CN113656504A (en) * | 2021-08-23 | 2021-11-16 | 武汉科技大学 | Block chain transaction submitting, editing and inquiring method based on time sequence attribute |
| CN113656510A (en) * | 2021-08-26 | 2021-11-16 | 支付宝(杭州)信息技术有限公司 | Method and device for executing transaction in blockchain system |
| WO2023040453A1 (en) * | 2021-09-15 | 2023-03-23 | 华为技术有限公司 | Transaction information processing method and apparatus |
| CN113537991A (en) * | 2021-09-16 | 2021-10-22 | 中国信息通信研究院 | Cross-chain transaction ordered execution method and cross-chain system |
| CN113901138A (en) * | 2021-09-27 | 2022-01-07 | 浪潮云信息技术股份公司 | MuSig 2-based block chain transaction multi-party endorsement method and system |
| CN113743940A (en) * | 2021-11-04 | 2021-12-03 | 支付宝(杭州)信息技术有限公司 | Method for executing transaction in block chain, main node and slave node |
| CN114036577A (en) * | 2021-11-09 | 2022-02-11 | 南京大学 | Coalition chain-oriented supervision method and supervision digital twin model |
| CN114862589A (en) * | 2022-07-07 | 2022-08-05 | 中国长江三峡集团有限公司 | Transaction data processing method and device based on block chain and electronic equipment |
| CN115170312A (en) * | 2022-07-07 | 2022-10-11 | 中国银行股份有限公司 | Asset state information changing method and device on block chain |
| CN116361385A (en) * | 2022-09-01 | 2023-06-30 | 矩阵时光数字科技有限公司 | Block chain consensus method and system |
| CN115827773A (en) * | 2022-09-13 | 2023-03-21 | 广州市汇方锐展计算机技术服务有限公司 | Data processing system, and storage medium and method for processing warehousing business documents of data processing system |
| CN116977067A (en) * | 2023-01-31 | 2023-10-31 | 腾讯科技（深圳）有限公司 | Block chain-based data processing method, device, equipment and readable storage medium |
| CN116455974A (en) * | 2023-04-10 | 2023-07-18 | 网易（杭州）网络有限公司 | Transaction caching and ordering method, device, electronic equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 毕马威: "区块链, 通往未来的机遇", 软件与集成电路, no. 11, 30 November 2018 (2018-11-30), pages 33 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110750341B (en) | Task scheduling method, device, system, terminal equipment and storage medium | |
| WO1991010191A1 (en) | Object oriented distributed processing system | |
| CN111858055B (en) | Task processing method, server and storage medium | |
| CN110033206A (en) | Bill of materials automatic Check method and device | |
| US7698312B2 (en) | Performing recursive database operations | |
| CN106130972B (en) | resource access control method and device | |
| US20140059000A1 (en) | Computer system and parallel distributed processing method | |
| EP0731947B1 (en) | A method and device for extracting data from a group of data | |
| WO2024113996A1 (en) | Optimization method and apparatus for host io processing, device, and nonvolatile readable storage medium | |
| EP3018581A1 (en) | Data staging management system | |
| CN115310906A (en) | Method, device and equipment for establishing picking task and computer readable storage medium | |
| CN117527832A (en) | Transaction ordering method and device for blockchain, electronic equipment and storage medium | |
| CN111259045B (en) | Data processing method, device, server and medium | |
| CN108153260A (en) | A kind of Discrete Intelligence manufacture system control terminal based on internet | |
| CN114238328A (en) | Data paging query method, device, equipment and storage medium | |
| CN114157662A (en) | Cloud platform parameter adaptation method and device, terminal equipment and storage medium | |
| CN111339422A (en) | Recommendation system task management platform, recommendation method and system | |
| CN114547184A (en) | Personnel information synchronization method, terminal device and storage medium | |
| CN103135703B (en) | A kind of method for being used to quickly read Field Replaceable Unit information | |
| CN115210694A (en) | Data transmission method and device | |
| CN112965925B (en) | Communication method, communication device, master equipment and slave equipment | |
| CN111611245B (en) | Method and system for processing data table | |
| CN117608795A (en) | Task processing method and device in preemption mode | |
| CN112860780B (en) | Data export method and device and terminal equipment | |
| US11789922B1 (en) | Admitting for performance ordered operations of atomic transactions across a distributed database |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |