SIMD-0602: Disallow Nonce Account as Program ID

[2501babe]

fingers crossed this is the final protocol change we need to cleanly implement ALT relaxation

i considered adding "require nonce accounts be 80 bytes" in here but decided this should stand alone because we need it and we can do qol things separately

[simd-bot]

Hello 2501babe! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here.

This PR requires the following approvals before it can be merged:

• At least one approval from a Anza team member: t-nelson, steviez, or bw-solana
• At least one approval from an Firedancer team member: ptaffet-jump, topointon-jump, 0x0ece, lidatong, ripatel-fd, or rexicon226

Once all requirements are met, you can merge this PR by commenting /merge.

[2501babe]

cc @apfitzge @bw-solana @topointon-jump @mjain-jump

[apfitzge]

Another alternative is that we remove lock demotion entirely. I'd had some initial discussions with Tom & Phillip about doing that just as a means to simplify the protocol (it should have never existed).

It seems that change would accomplish the same goal of unblocking 192, but by simplification rather than an additional special-case.

Maybe we revive that discussion and actually prioritize it?

[2501babe]

65f238a added this to alternatives considered as well as some remarks on reserved keys. if we remove program id demotion it would also unblock ALT relaxation yes. im not sure how long we would need to discuss it or how complex it would be, one advantage of this proposal is the whole impl is two new boolean checks in get_durable_nonce()

the only relevant half of demotion ALT relaxation cares about is program id demotion (really, only the loaderv3 execption to it). i think removing program id demotion is totally fine since it doesnt really accomplish anything. i do worry about the consequences if we remove reserved key demotion though, because it does fully protect what it aims to protect, is relatively more simple, and guards accounts that are used omnipresently (tbh i think we should add token to it)

[apfitzge]

Yeah I think the token case adds to the argument for moving this out of consensus tbh. Scheduler can just reject, or allow them with the assumption of failure to change such immutable programs.

It being under consensus actively makes it harder to widen the scope to include token in that protective class.

[2501babe]

after some discussion we concluded we cant remove write-lock demotion from consensus at this time, but may be able to after alpenglow

[2501babe]

i was meditating on what a true gateless workaround to unblock ALT relaxation would look like and i think this would do it:

• write-lock the nonce if requested writable regardless of program id demotion. no consensus change, just for proper dispatch
• use requested writable for runtime nonce validation, a slightly looser constraint. this layer has not been meaningful for consensus since we started single-batching replay
• if nonce is a program id and loaderv3 is not a static key, load the ALT in svm. do not error if invalid, if valid check for loaderv3 in resolved keys to determine true writable nature of nonce
• svm nonce validation, adding a proper writable check. this now behaves in line with current consensus
• svm fee-payer validation, unchanged
• at this point we are free to process transactions as fee-only. load and validate the ALT for real according to all SIMD-0192 rules

(plus all the right magic with reserved keys, but that part is not a problem)

the new workaround design is actually less bad than my old one, which is what made me throw in the towel and open this SIMD. previously i had been imagining more like:

• weaken nonce validation to allow unclear-writable through past the svm nonce checks
• fee-payer validation
• ALT validation and catch the weird nonce case here to discard, mixing our nonce discard and ALT fee-only code

so id still prefer this SIMD to minimize error surface, but i think i can call it a medium-firm blocker instead of a hard blocker on ALT relaxation

[topointon-jump]

I'm sure this has been discussed, but what do we think about incentivising people to use txnv1 over the old transaction format?

[2501babe]

im definitely for aggressively pushing people toward txv1 by whatever means, but im not sure if there is a timeline for completely removing txv0, which is what we would need to moot ALT relaxation

[MaxResnick]

I'm sure this has been discussed, but what do we think about incentivising people to use txnv1 over the old transaction format?

+1 for sure. The hope is we could do something similar to SIMD 571 where we just set the prio fees to 0

[2501babe]

after reviewing the options for removing program id demotion, i am more confident this SIMD is the right thing to do to unblock ALT relaxation. in fact, ALT relaxation makes program id demotion easier to remove after the fact, because we wont need to demote when resolving on ingress and then force resanitization across the epoch boundary we activate in

also it would churn across all three repos because demotion is inherent in every transaction type constructor. so we would need to add a feature bool to LegacyMessage, SanitizedMessage, LoadedMessage, CachedMessage, and SanitizedTransaction, or add a mutable un-demote function to them. since several of these dont compute the property off the message, but cache it internally

on the other hand this SIMD is basically trivial. when we determine the nonce pubkey after failing to find a valid blockhash, we check if the pubkey is a program id, and discard the transaction if so. we dont need to check reserved keys (until SIMD-0297...) because we will necessarily fail the nonce account state checks from any reserved key

removing reserved keys is not possible and unrelated to this SIMD, to ALT relaxation, or to removing program id demotion. it would require a deeper change like restricting what accounts can be credited lamports. actually maybe instead of "these keys are magic for consensus, mungle writablity" we could have a post-execution rule "accounts owned by native / sysvar / loaderv1 / loaderv2 are functionally sol incinerators." then we burn transfers into them and can unconditionally read-lock a magic list of keys with the list being not in consensus. anyway... not related to this

[bw-solana]

couple small things. Looks pretty good to me

[bw-solana]

nit: I think we should spell out what "used as a program ID" means. Something like:

"If the nonce-account index, as identified by instruction 0, equals the program ID index of any transaction instruction, the transaction is protocol-invalid"

[2501babe]

8e70926 i elaborated more on what all is going on, and clarified "is also used as a program ID by any instruction on the transaction." im not sure how bringing account indexes in would make it clearer. if "used" is a problem im not sure if there is a better verb for "it is the program id"... i had to pare back a few attempts at sentences that ended up sounding like "the account that which is designated by the as that which is considered to be therefore art whence thereof" hyper-specific nonsense

[bw-solana]

Might be good to state explicitly that while the order of the above is not strict, they must be checked before other checks such as ALT resolution that would result in fee paying

[2501babe]

8e70926