Also it would bring extra limitations if Alice NEED to receive a big quantity of payments in a short period, for example in the scenario of Alibaba Nov. 11 event ([link](https://www.technologyreview.com/s/602850/big-data-game-changer-alibabas-double-11-event-raises-the-bar-for-online-sales/)).

IMO deposit in parallel should be allowed. And perhaps withdrawals should have higher priority than deposit.

(edit: rate limit should still apply, to determine which account has higher priority to withdraw, but then it should be made into consensus, and the downside is it will cause longer replay time if need to check it during replay(edit 2: seems it's not able to make it into consensus nor able to check during replay, as suggested in the post, a bit more computation while generating block, but less while validating)).

(edit 3: theoretically it's possible to include one withdrawal and many deposits into one block, if the amount of withdrawal is less than the initial balance. However, in a single block, if there are more than one operation on same balance object, no matter they're multiple deposits or one withdrawal and some deposits, it means need to modify that object serially, which will have a negative impact on performance)

But a "strong" account could **delay** (attack) other accounts activity until "they give up", I mean until it makes enough damage  to the network(?)...

Let me get this straight:

* We prevent people from **spending** more than once a block because of **double-spending** during parallel evaluation
* We prevent people from **receiving** more than once a block because of **write-locks** to the object in the database

Correct?