Stores Actors Data Tree Downloads

Transactions draft

It is fairly straightforward to see that the account modification function is not transactional in the general sense. When it returns success, some removals may not have been applied, and when it returns with an error, some additions may already have been applied.

Within the context of forward-moving data, however, the client may execute a transaction as follows:

  1. The client reads a box, and all associated trees.
  2. The client merges all these trees (and potentially other trees) using a forward merge function. The resulting tree contains all relevant information of all merged trees, and has a higher state.
  3. The client submits the new tree for addition, and all merged trees for removal.

If the addition succeeds, the data has been brought to a higher state. The removals do not need to succeed thereby. If they fail, they will be merged again with the next transaction, but since their relevant information is completely contained in this new state, they have no impact (stability property).

In theory, removal could be skipped altogether. This would make the system perform poorly, however, since old trees would be merged over and over again.