Account Commitments - Issues and Improvements

[GabrielePicco]

Discussion

During our discussion, we identified cases where the atomicity of committed accounts could be compromised:

• TX1 (internally requests the commit of A and B)
• TX2 (internally requests the commit of B and C)

TX1 and TX2 are executed in the same slot. Commit(A, B) fails, while Commit(B, C) succeeds. This breaks the commitment atomicity of TX1, where B is committed, but A is not (as we currently commit the account state at the end of the slot).

• A similar situation could occur across slots.

Discussed Solution

The discussed solution includes:

1. Creating a pipeline queue of commits that sends commits in parallel with a progressive index.
2. Only accepting a commitment (on the delegation program side) if the index is exactly what we expect.

Outcomes

The current implementation handles the happy path and is currently good enough for standard client integration.

• Implementation of this solution is likely to occur after BK, once commit/undelegate and value reconciliation are completed.

Participants

@thlorenz @crypto-vincent @GabrielePicco

[GabrielePicco]

Closing as we now have an issue for this discussion