How is Concurrency Handled

Hi, I come from a database background. Was reading the documentation and white papers for libra and it doesn’t seem to contain information about concurrency. How is it handled? This is important because it can have major consequences on performance and documenting it will help libra be more open.

The simplest case would be when two clients call transactions at similar times on different validators.

1 Like

There is really little information about this. I would also like more details. I think it will be implemented on the similarity as Tendermint.

Hi @raxu, I’m happy to explain, but would like to know additional details of your query. For the example you ask about: “when two clients call transactions at similar times on different validators” - I’m assuming that you are referring to two clients sending a transaction for the same account. So let’s say we have account 0x1234 which currently has a sequence number of 7. Two clients submit different transactions with sequence number 7 to different validators. Both validators will attempt to gossip these transactions via shared mempool. Since they are conflicting, other validators will only accept the first one that they receive (unless the gas price is higher on one of them in which case that one will be accepted). So let’s say we had an equal gas price on both and now 50% of the validators have each transaction. Some validator will become the next proposer and propose a new block including one of the two transactions. Even though the transactions conflict, it doesn’t matter that they conflict because one is still in the mempools of the other 50% of validators and one is now proposed in a block. When this proposal comes in, all validators will execute it and likely vote for it because it is indeed a valid transaction - it doesn’t matter that there is a conflicting one in their mempools. Once the txn is executed and committed, it will be pruned from the mempools. Now let’s say that something happens and the second one gets proposed even though the first one had already been proposed. All validators will drop the second transaction because the sequence number has already been used for that account - meaning that this is an invalid transaction to execute, so nothing is stored for the second one even if it were to get proposed (although it likely wouldn’t get proposed by a good validator).