sdk: evict genesis config

[buffalojoec]

The next SDK eviction before being able to evict RentCollector! (See #3932)

[joncinque]

Looks great overall! Just tiny things

[buffalojoec]

@kevinheavey can you transfer the crate to anza-team if you haven't already?
cc @yihau

[joncinque]

It looks good to me, but there are some test failures that need to be resolved

[buffalojoec]

It looks good to me, but there are some test failures that need to be resolved

Ahh nuts. One of the errors is an easy fix for solana_pubkey::new_rand(), but the other is because of the write method on GenesisConfig. It depends on the type's serde implementation, and since it's a public method, we have to either:

• Break the crate and either put write behind the serde flag or move it as a free function to solana-ledger.
• Don't break the crate and don't offer a serde feature for solana-genesis-config, also requiring the serde feature for all dependent crates in the GenesisConfig type.

EDIT: Acually I just made the serde feature default. Let me know if that works.

[kevinheavey]

Why does the serde feature need to be default?

[buffalojoec]

Why does the serde feature need to be default?

write is a public method, which depends on serde. It won't work without the serde feature enabled, therefore it would need to be tucked under the serde feature as well, which is a breaking change.

[kevinheavey]

But it would be a breaking change to the genesis-config crate which doesn't exist yet? We could just enable the genesis-config serde feature in solana-sdk

[buffalojoec]

But it would be a breaking change to the genesis-config crate which doesn't exist yet?

It's a breaking change to the public API solana_sdk::genesis_config::GenesisConfig::write.

We could just enable the genesis-config serde feature in solana-sdk

Unfortunately the problem isn't in the SDK, but rather tha solana-genesis-config crate itself. The write method uses bincode on itself (GenesisConfig) and therefore depends on the serde implementation of itself. There are a few methods like this actually.

We probably need to just enable serde traits all the time for this type if we don't want to break the API for GenesisConfig. Alternatively, we can define a newGenesisConfig in this new crate, and leave the old one in-tact in the SDK, deprecating it in-place.

[kevinheavey]

Am I understanding correctly that the "breaking change" here is that if someone wants to import GenesisConfig from the new crate and use all the methods as before, they need to activate the serde feature?