Support special atomic storage operations on keys

[bennetyee]

To avoid excessive read/write and write/write conflicts on account balances, we should have the ability to treat such nodes in the global merkle tree as a non-negative counter to which values are added and subtracted. The only reason for an abort is if a subtraction would result in a negative value.

Details

A CRDT (https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) might work, though might be overkill.

We have transactions within a batch adding and subtracting values to account balances, possibly aborting one (or more) transaction within the batch if their execution would have taken an account balance negative -- relative to the balance at the root used for all batches executing in parallel. In order to serialize batches, we record the net change to all account balances as delta values, and furthermore we need to know the lowest value that account balances might reach as a delta value relative to the starting balance. With a max excursion, we can determine if merging batches in a certain order would result in a serial view where one or more account balances would have been negative.

We have at least three possible design choices:

• remove batches that would cause one or more account balances to go negative, so those transactions are reverted

• look for a permutation of batches that minimizes the number of batches that need to be reverted

• allow account balances to go temporarily negative, as long as the final value after all transactions are merged are non-negative, i.e., free loans are available since the loans are risk-free.

Acceptance Criteria

• A design for how to reduce conflicts for non-negative counters (account balances).