You are viewing a single comment's thread from:

RE: How to Process 100M Transfers / Second on a Single Blockchain

in #blockchain8 years ago (edited)

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).

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)

Sort:  

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).

This! Amazon could have an account and dozens of people may want to pay at the same time, especially during Christmas session!

They can have multiple accounts.

That sounds more than a hack than a solution.
Would it be not troublesome for the merchant and the customers to care about that?