Assign Ed25519 precompile to native loader

[deanmlittle]

No description provided.

[simd-bot]

Hello deanmlittle! 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, sakridge, or bw-solana
• At least one approval from an Firedancer team member: ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd

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

[t-nelson]

i don't think this is necessary. it's only testnet. i'd far prefer to just rewrite the account on the next testnet restart than carry a testnet-only feature gate around. the inconsistencies in cluster feature sets have already been enough trouble historically

[topointon-jump]

I think this is a good approach. For consistency's sake we should activate this feature on all networks, even it it will have no effect on devnet/mainnet.

[deanmlittle]

i don't think this is necessary. it's only testnet. i'd far prefer to just rewrite the account on the next testnet restart than carry a testnet-only feature gate around. the inconsistencies in cluster feature sets have already been enough trouble historically

Up to you ser. Just doing what I can to try make things less broken. Seems everyone I've asked is cool with it now. If this makes it into 3.1.0, I think it's worth it. If it doesn't, I think your approach is better. Having to wait for a whole release cycle to fix testnet is an unacceptable delay imo.

[jstarry]

As written, the SIMD feature gate can be activated on all clusters. It's also quite simple so I would be in favor of backporting the implementation to v3.1. @t-nelson thoughts?

[buffalojoec]

Lgtm, I think the all-cluster activation method makes sense, too.

[buffalojoec]

I don't think the code snippet is valuable here. The spec should be agnostic anyway.

[simd-bot]

Thanks, topointon-jump!

⚠️ Status: Cannot merge yet

• Missing approval from: Anza (t-nelson, sakridge, or bw-solana)

[t-nelson]

As written, the SIMD feature gate can be activated on all clusters. It's also quite simple so I would be in favor of backporting the implementation to v3.1. @t-nelson thoughts?

that's all good and well, but why? why waste all this time on testnet? we can just ram it in. who cares?

[jstarry]

that's all good and well, but why? why waste all this time on testnet? we can just ram it in. who cares?

I'd rather not use "hacks" to fix any cluster, including testnet. Using ledger tool to patch a cluster snapshot is pretty heavy handed for something trivial to fix via feature gate. And the fix via feature gate is simple enough to not waste much time.

[t-nelson]

i would rather not no-op hard fork mainnet beta under any circumstances

anza-xyz/agave#9352

[jstarry]

i would rather not no-op hard fork mainnet beta under any circumstances

I don't really mind doing that.

But your snapshot change looks fine to me too. It's not too different to how we deactivate features on testnet. Let's do that instead of a feature gate.

[t-nelson]

yeah it's the same class of activity as "deactivate feature gate" or "forced destake" imo. if this was any other cluster i'd be more hestitant, but testnet is here for validator client dev convenience and a feature gate is not convenient