[dgacmu]

Those transfers would be represented as having dependencies on both accounts they touch, and so would be forced to be ordered.

Transfer(a, b, $50)

And

Transfer(b, c, $50)

Are conflicting operations. They don't commute because of the possibility that b could overdraft. So the programmer would need to list (a, b) as the dependencies of the first transaction and (b, c) as the second. Doing so would prevent concurrent submission of these transactions from being executed on the fast path.

[mjevans]

As I was implying with chains after the toy example, the issue of ordering matters when there's a long sequence of operations that touches many accounts. How easy is it to track all of the buckets touched when for every source there could be a source upstream from any other transaction?

A temporary table could hold that sort of data in a format that makes sense for rolling back the related transactions and then replying them 'on the slow path' (if order matters).