fix: preload kzg settings to prevent it from happening during block submission

[prestwich]

Preload kzg during bin initialization

[prestwich]

• fix: preload kzg settings to prevent it from happening during block submission #208 👈 (View in Graphite)
• thing: thing thing the thing #205 : 2 other dependent PRs (#206 , #207 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[rymcol]

Preface: not a rust expert, but just noting that I worry that an async version of this, if a call to _settings is made on the main thread could lazy init and create a race between the two. Perhaps it's worth a main thread call once and ensuring k8s readiness expires after we guarantee the initializations?

[prestwich]

so this is handled in the underlying c_kzg library, which uses a synchronization primitive to prevent this from happening

fn ethereum_kzg_settings_inner(precompute: u64) -> &'static Arc<KzgSettings> {
    static DEFAULT: OnceBox<Arc<KzgSettings>> = OnceBox::new();
    DEFAULT.get_or_init(|| {
        let settings = KzgSettings::load_trusted_setup(
            ETH_G1_MONOMIAL_POINTS,
            ETH_G1_LAGRANGE_POINTS,
            ETH_G2_MONOMIAL_POINTS,
            precompute,
        )
        .expect("failed to load default trusted setup");
        Box::new(Arc::new(settings))
    })
}

the OnceBox handles thread synchronization, allows only 1 entrant to the initialization. While initialization is occurring, threads trying to access the contents are blocked until it completes. No race condition allowed

[prestwich]

code ref is here
https://github.com/ethereum/c-kzg-4844/blob/v2.1.1/bindings/rust/src/ethereum_kzg_settings/mod.rs#L26-L37

[prestwich]

oooh interesting, they explicitly use race

https://docs.rs/once_cell/latest/once_cell/race/index.html

[prestwich]

🙄

[prestwich]

on review, i am not concerned about this race and here's why:

• we know that this process takes ~3 seconds
• slot times are 12 seconds
• the kzg build will not be invoked until the final 3 seconds of a slot
• so this race will occur IFF all conditions hold
  • the builder is booted inside a slot that it controls
  • the builder is booted in the last half of the slot (as the 3s stretch started by init would have to last until the 3s in build, ie. initializtation is i the last 6 seconds of the slot)
  • the builder produces a block in that slot
    • this means the builder would have had to receive a header for the previous block
    • the builder will not receive a header from the WS subscription until the next block AFTER it boots
• therefore there is no situation in which the builder boots in the last 6 seconds of a slot AND builds a block for that slot