michael

sounds like a good idea!

I don't like the idea of a new service within the validator that tries to keep this list updated. Instead we only need a couple primitives: 1. New solana-validator command-line...

> I do not want to inflate `validator/src/main.rs` too much, so maybe `validator/src/lib.rs`? Yep that seems great. Putting it in `lib.rs` will also make it easier to add to `solana-test-validator`...

The trick here is the allowed log units is not a part of consensus, for example RPC nodes may wish to configure this value higher than a staked validator. Perhaps...

I do like the idea of making the log limit per-instruction!

Hey have you considered how to handle the helper functions in the clap-utils crate? Examples include ` input_validators::is_parsable()` and `input_parsers::pubkey_of()`. We can't simply flip these over to use clap 3...

> By downstream users, do you mean those mentioned in build-downstream-projects.sh or there are some which are probably not known to us and we cannot break them? That's a start...

This gate is on the schedule at https://github.com/solana-labs/solana/wiki/Feature-Gate-Activation-Schedule, and is the 25th (if I counted right) feature gate in the 1.14 release line. So best case, it'll be activated 25...

This feature is still on the master branch, will ship in the v1.16 release line. When this reaches mainnet depends on how quickly the validators choose to adopt the v1.14...

> In Pyth's case, we have an expensive aggregation operation that needs to be performed once per slot. Most price update transactions use very few CUs, except for the one...