Trent Nelson

can this wait for 1.19? should be able to cut 1.18 in ~1wk if all goes well with mb 1.17 adoption, making this mergeable into master

should we give some of the slower ledger accessors the same treatment? `getSignaturesForAddress`, `getBlock`, `getTransaction`, everything that might fallback to BT?

are there any potential downsides? what is the difference in peak incremental snapshot size at a full snapshot cadence of 50k from the 1-3GB at 25k?

> The SPS implements a priority queue, so if there are multiple outstanding incremental snapshots to package, only the latest will be packaged and the older ones will be dropped....

this is a really huge change set. are there sane places to break it up?

> I agree that this code is messy but I'm not sure that this is the right way to clean it up. I believe the reason that the `lamports_per_signature` is...

```patch -have fewer people yelling on ~twitter~ X +have people on ~twitter~ X yelling about this breaking change instead of another one ```

do we intend to migrate the public clusters to zstd genesis? if so, how are we going to bootstrap?

> I thought there was some code somewhere that created the archive if you didn't have it; either I'm misremembering or that code is not getting hit for some reason....

i think to keep this pr small, let's just support _reading_ zstd compressed genesis archives. we can add generation to `solana-genesis` in a followup. then worry about the if/how to...