SIMD-0192: Relax Transaction Constraints - Account Resolution

[apfitzge]

No description provided.

[ptaffet-jump]

I like the idea!

All account table indices specified in the transaction must be less than the number of active addresses in the address lookup table.

This one gives me a bit of pause because of the potential race between extending an address lookup table and using the new indices. Right now, the warmup is only one slot, which means the following scenario is possible:

1. User extends a table in Transaction A.
2. Transaction A lands in slot x, and the user sees that.
3. The validator switches forks so that slot x+1's parent is not x, and the table extension gets "rolled back"
4. The user submits Transaction B using the new indices
5. Transaction B gets included in slot x+1, marked as a Runtime Transaction Error
6. The user eventually notices that Transaction A didn't confirm and re-sends it.
7. The user can't re-send transaction B because it already landed on chain as a Runtime Transaction Error

This isn't horrible, and the user can deal with it in several ways (resigning and re-sending Transaction B, making Transaction B's recent blockhash slot x, waiting until slot x is optimistically confirmed or rooted).

I just think this case needs to be thought out a bit.

[apfitzge]

I like the idea!

All account table indices specified in the transaction must be less than the number of active addresses in the address lookup table.

This one gives me a bit of pause because of the potential race between extending an address lookup table and using the new indices. Right now, the warmup is only one slot, which means the following scenario is possible:

1. User extends a table in `Transaction A`.

2. `Transaction A` lands in slot `x`, and the user sees that.

3. The validator switches forks so that slot `x+1`'s parent is not `x`, and the table extension gets "rolled back"

4. The user submits `Transaction B` using the new indices

5. `Transaction B` gets included in slot `x+1`, marked as a `Runtime Transaction Error`

6. The user eventually notices that `Transaction A` didn't confirm and re-sends it.

7. The user can't re-send transaction B because it already landed on chain as a `Runtime Transaction Error`

This isn't horrible, and the user can deal with it in several ways (resigning and re-sending Transaction B, making Transaction B's recent blockhash slot x, waiting until slot x is optimistically confirmed or rooted).

I just think this case needs to be thought out a bit.

It's a good point, but I don't view the case as substantially different than the race between any state on Solana wrt fork changes.
If someone places a limit order, and I go to take it, but my tx ends up on a different fork than the original LO, my transaction will fail and I'd have to re-sign to send the same tx again if the LO ends up on the other fork.