SIMD-0242: Static Nonce Account Only

[apfitzge]

No description provided.

[apfitzge]

This is a necessary precursor for #192

[t-nelson]

pretty sure supporting this in the first place was an unintentional oversight

[apfitzge]

pretty sure supporting this in the first place was an unintentional oversight

Yeah. Think just a natural consequence of adding the two features independently, there was no special consideration for how the two should interact.

[jstarry]

Must be strictly less than the number of static accounts if we are talking about an index.

[jstarry]

This still needs to be updated

[apfitzge]

b94401d

[jstarry]

Can you explain further why the relaxation cannot happen in this case? It's not too obvious I think. My understanding is that if we attempt to process a durable nonce transaction that uses an invalid lookup, we wouldn't be able to include the transaction because the nonce is not advanceable and therefore there wouldn't be a way to ensure that it would only be processable once. This is a blocker to implementing the other proposal which aims to allow including any transaction which has an invalid lookup into a block.

[2501babe]

it also sort of resolves a catch-22: if all bad lookups get processed, and all bad nonces get discarded, and lookup happens first, does that mean bad nonces get processed? but to process it you need a nonce

a failed nonce lookup should be the same as a nonexistent nonce, for any sane definition of nonce validation. and we still need to validate nonces (and blockhashes for blockhash transactions) to process an alt lookup failure even for a lookup failure for a transation with a static nonce. processing requires a new nonce state to be written, so the only possible way we could "process" a failure to resolve a nonce from an alt would be to pretend its a blockhash transaction and skip blockhash validation for it

a simpler solution would just be to clarify in simd192 that failed nonce lookup == failed nonce validation. but im inclined to support simd242 because im in favor of restricting nonces in this way (and several others)

[t-nelson]

i think it makes sense to elaborate the motivation so these details are explicit

[jstarry]

We also need the recent blockhashes sysvar to be static 💀

[jstarry]

And we should explicitly state what happens if you append a bunch of lookup accounts to the advance nonce ix 💀

[apfitzge]

3328140

[jstarry]

Wait actually we don't need this change. We would never process the actual advance nonce ix for a tx with invalid lookups, we advance the nonce in the runtime. So only the nonce needs to be static. Let's revert 3328140

[t-nelson]

did we drop the in-program verify+advance?

[apfitzge]

so we never actually need the recent blockhashes sysvar to advance the nonce; but if the transaction would otherwise have succeeded, not having that account as an input would make it fail on the nonce ix processing?

That seems extremely odd, but probably not relevant to this SIMD

[jstarry]

Yes, not having the recent blockhashes sysvar as an account input would make it fail the nonce ix processing in the SVM. But if nonce ix processing fails in the SVM, the runtime takes over and manually advances the nonce since the runtime obviously has access to the latest blockhash and therefore knows what the next durable nonce should be.

[t-nelson]

signers are already required to be statically specified?

[apfitzge]

Right, signers are already required to be static.

[jstarry]

Still need to revert 3328140

[t-nelson]

this ready for fd review?

[apfitzge]

reached out to Tom for fd review. for some reason github won't let me request his review

[topointon-jump]

I support making these simpler, just have one question about where the check itself should go.

[topointon-jump]

Just curious - why is this check not in the SVM transaction sanitization, instead of the block builder? This might make sense from an API perspective, and so that users are charged for submitting these invalid transactions.

[apfitzge]

it could be done in SVM, really anywhere before we get to actually publishing a block.
Likely the best place to do that is as early as possible though, since without loading the nonce account to determine if its valid or not we cannot charge fees.

[apfitzge]

@topointon-jump, as discussed elsewhere, agave will implement feature-gated checks in the runtime to check the new constraint and fail the transaction.

This detail is implementation specific, which iirc we should avoid in proposals, so making a comment here for your records. Agave's runtime will mark these transactions with a specific error, which should enable frankendancer to use it w/ minimal changes.

[apfitzge]

@jstarry or @t-nelson, do you have any remaining comments? if not, would appreciate an approval so we can close this and begin implementation.

[apfitzge]

@Benhawkins18 approval has been received from anza (@jstarry) and firedancer (@topointon-jump). Can we merge, or initiate "final comment" period for this proposal?