Sequence number increment should not fail

[lxfind]

If we allow sequence number increment to fail, this could create two problems:

1. We could be violating the invariant where some mutable objects must be written in the temporary store after an order execution.
2. We could be prone to DDos attack (by keep using the MAX sequence number gas object)

We should assume it cannot overflow.
To enforce this, we could consider freeze the object when its sequence number reaches MAX.

[oxade]

Agree, increment failing will have bad side effects. I like the direction this is going.
++
This is more of a brainstorm:
I think this freezing at overflow is a worthwhile solution.
However can you think of any scenario where this could be catastrophic for user?
Also if an object freezes mid-transaction due to overflow, how do we properly surface this?
Since we have some level of determinism, can we predict that a transaction might cause an object to freeze, and provide some kind of warning early on?

[sblackshear]

Nice, happy to see these unwraps go away.

We could be prone to DDos attack (by keep using the MAX sequence number gas object)

Another thing we could consider is rejecting a tx with any object inputs whose sequence number is MAX. I think we can do this very early on, basically at the same time we check the balance of the gas object today.

[oxade]

Nice, happy to see these unwraps go away.

We could be prone to DDos attack (by keep using the MAX sequence number gas object)

Another thing we could consider is rejecting a tx with any object inputs whose sequence number is MAX. I think we can do this very early on, basically at the same time we check the balance of the gas object today.

Right. Very simple but sufficient solution for now.

[kchalkias]

Another thing we could consider is rejecting a tx with any object inputs whose sequence number is MAX. I think we can do this very early on, basically at the same time we check the balance of the gas object today.

Also agree with @sblackshear, that's the easiest fail-fast workaround.