Proposal: Conflict-Resistant Sequence Numbers

[tzakian]

Sequence numbers today provide a simple mechanism to prevent transactions from being replayed — only a single transaction can ever be processed for a given sequence number/account combination. Additionally, the sequence number provides a way of enforcing sequentiality; a sender can send transactions with sequence numbers 0, 1, 2, and 3 to the network in any order since the sender knows that 1 can only be processed after 0, 2 after 1, etc.

However, sequence numbers today present issues due to sequence number lockup: once a transaction at a given sequence number n is chosen, the sending account will block on being able to process other transactions with sequence numbers greater than n until that transaction has been processed. This issue has cropped up in multiple places so far, and in general will be an issue when any off-chain activity related to signing a full transaction is being considered.

In general we have observed a theme here with sequence numbers: they prevent replays, and ensure strict sequentiality, however this “strict sequentiality” presents serious usability issues in off-chain protocols. This proposal would introduce the idea of a Conflict-Resistant Sequence Number (CRSN) that relaxes this strict sequentiality to allow concurrent processing of transactions while also allowing some level of dependency between transactions sent by the same account to be expressed.

CRSNs would work at the account level and would be an opt-in feature. No breaking changes would be needed to Diem data structures as the transaction's sequence_number field can be reused.

[aching]

Sounds good @tzakian, would be happy to be DIP manager for such a proposal.

[tzakian]

Thanks @aching! That sounds great :) Initial DIP PR for this proposal can be found here: #170

[aching]

Draft has been approved. Looking forward to feedback from the community!