We track the action state at the time of the last transfer processed by the user
in the user's token account to prevent double spends of the transfers.
This means that to process a transfer, a user needs needs to prove that the action
state, for the new transfer they are processing, is an extension of the old
one in the account.
Thus, we need to keep track of the whole history and prove this.
But what if there was an easier way?
Rather than keeping the action state, we can merely keep the index in the action state,
i.e. the length of the action state at the time the transfer was posted (starting at 0 obviously).
When we have a new transfer we want to process,
we need only prove that 1) it's in the action state and 2) its index (calculated by going backwards)
is more than the last index processed, tracked in the user's token account.
Roughly this means we go from proving one long extension and one short extension
to only one short extension and an integer comparison.
The reason the first extension was long and the second short is that
a user will have large gaps in when they do a transfer, but will usually
process a transfer soon after it's been added.
Say we do a transfer in 2023, process it soon-ish, then do another transfer in 2024.
We'd if possible prefer not proving an extension from action state of 2023 to that of 2024.
Relatedly, we can do another optimization.
Rather than having every user do their own proving of the action state, the sequencer can provide their
proof of the action state's length (i.e. index of next transfer to be added).
The user can then prove backwards from this, usually in a single proof since it should be a roughly
short distance if the user processes their transfer soon enough.
We track the action state at the time of the last transfer processed by the user in the user's token account to prevent double spends of the transfers.
This means that to process a transfer, a user needs needs to prove that the action state, for the new transfer they are processing, is an extension of the old one in the account. Thus, we need to keep track of the whole history and prove this.
But what if there was an easier way? Rather than keeping the action state, we can merely keep the index in the action state, i.e. the length of the action state at the time the transfer was posted (starting at 0 obviously).
When we have a new transfer we want to process, we need only prove that 1) it's in the action state and 2) its index (calculated by going backwards) is more than the last index processed, tracked in the user's token account.
Roughly this means we go from proving one long extension and one short extension to only one short extension and an integer comparison. The reason the first extension was long and the second short is that a user will have large gaps in when they do a transfer, but will usually process a transfer soon after it's been added.
Say we do a transfer in 2023, process it soon-ish, then do another transfer in 2024. We'd if possible prefer not proving an extension from action state of 2023 to that of 2024.
Relatedly, we can do another optimization.
Rather than having every user do their own proving of the action state, the sequencer can provide their proof of the action state's length (i.e. index of next transfer to be added). The user can then prove backwards from this, usually in a single proof since it should be a roughly short distance if the user processes their transfer soon enough.