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.

[topointon-jump]

If a transaction includes a key twice, does it get charged for the write lock once or twice?

[apfitzge]

Clarified below - account key values are not considered for transaction-cost calculation, just the number of write locks requested.
Transactions violating the constraints are treated the same as "fee-only" transactions are currently for the cost-model.

[andrii-kl]

This one looks really powerful.
By turning strict account-resolution errors into runtime failures with fees, it effectively closes one of the biggest gaps that enables cheap transaction spam.

It means every submitted transaction even if it fails due to invalid lookups or stale nonces will still pay and advance state, introducing a real economic floor.
That’s exactly what’s missing today and what makes large-scale durable-nonce flooding so cheap.

[ptaffet-jump]

This is definitely a corner case, but we should probably specify it: if the fee payer and nonce accounts are duplicates of each other, does the write lock cost get applied once or twice?

Once makes more sense, but requires an extra check. Twice is more natural from an implementation perspective. I think either is fine, but it just needs to be specified.

[apfitzge]

Sorry for (very) slow response! If the nonce & fee-payer are the same acct, write lock costs are applied once, as is the case today. Nonce is just a reference to an acct index like any other, so this feels the most straight-forward imo.

[apfitzge]

3fb21b1 LMK if this added sentence is clear.

[simd-bot]

Hey @apfitzge, this PR has been inactive for 60 days and is now marked as stale.

If you're still working on this, please comment below to let us know. Otherwise, this PR will be automatically closed in 7 days.

To keep this PR active, simply leave a comment explaining the current status or any blockers you're facing.

[simd-bot]

Hey @apfitzge, this PR has been automatically closed due to inactivity.

The PR was marked as stale 7 days ago and there was no response from the author.

If you'd like to continue working on this, feel free to reopen the PR and leave a comment with an update on its status.