How to deal with asynchronous operation because of the delay blockchain ? How does the blockchain perform under high concurrency? how to deal with the mutually exclusive variable?
2 Answers
The blockchain itself is effectively single-threaded: Transactions are executed one by one, and the state of the previous transaction has been altered if it is then referenced by the next transaction. So for example if you want to assign an incrementing ID to a series of records, you can be confident that ultimately each ID will only be assigned to one record.
The problem is that when you send a transaction, not only do you not know in advance in what order it will happen relative to other transactions, you don't know immediately afterwards either, because the block that just processed it may be orphaned and replaced by a block that took transactions in a different order. So in our ID example, you might create a record by sending a transaction from your Javascript code, see it get an ID, then come back later and find that the ID you thought had been assigned to your record now belongs to a different record.
The upshot is that things that require a strict ordering need to be managed inside the blockchain, which is always ultimately consistent with itself, and you can't assume immediate consistency with respect to external systems.
-
As you said, the ID example. It seems the blockchain could not be asynchronous. Commented Aug 24, 2016 at 5:54
-
The blockchain is asynchronous in relation to external processes; there's no guarantee about when or even if a transaction will be processed and in what order it will be included. Internally, it is entirely synchronous. Each transaction execution finishes before any other transaction is executed. Commented Sep 23, 2016 at 17:13
-
and what about mining threads? when you run multiple mining threads concurrently, how does it affect the state?– NulikCommented Dec 9, 2017 at 17:40
There is no concurrency on the blockchain. The transactions are ordered by the node that authors the block according to the order in which that node received the transactions.
So in a case that might seem like a race condition, e.g. a token exchange, where many orders might by placed within the block time and according to state values such as price seen at the previous block, many transactions might simply get invalidated because that price gets adjusted on a first come first serve basis into the TX pool.
-
3The transactions can be ordered in the block by the miner in any way it likes, not necessarily in the order they're received. Most miners will order them by gas price (if they're running the vanilla implementation of Geth), but the implementation is really up to them. (See ethereum.stackexchange.com/questions/6107/…) Commented Aug 24, 2016 at 13:42