Implement Distinct RNG Sequences

[sangbida]

Overview

This PR introduces a deterministic yet unique random number generation system for the Lightning Network simulation. Each NetworkGraphView now maintains a base seed, while individual nodes receive their own RNG instances derived from this base seed and salted with their public keys. This ensures consistent but varied behavior across the network while preserving reproducibility.

Changes

• Added seed field to MutRng struct
• Implemented salted method that creates node-specific RNGs by combining the original seed with the node's public key
• Updated random_activity_nodes to use salted RNGs for each node

[sangbida]

Would appreciate thoughts on this approach to salting

[carlaKC]

I asked the ai gods and they suggested just using a straight-up hash:

let mut hasher = DefaultHasher::new();
source.pubkey.hash(&mut hasher);
let salt = hasher.finish();

Since we only care about determinism here (not about salt that provides good entropy), I don't think it matters much which approach we use provided they yield distinct values per pubkey.

[sangbida]

Ah okay, we don't care to salt the base seed, right? As in, it's okay for the rng to be something like: Self(Arc::new(StdMutex::new(ChaCha8Rng::seed_from_u64(salt)))) or do we want to do something like base_seed ^ salt

[carlaKC]

I think that we do want to include the base seed here just so that there's an option for folks to run with different, fixed seeds? If we just use pubkey, we'll only ever get one set of payments per pubkey, vs if we include the base seed we can change it (while keeping it deterministic)

[sangbida]

Took another stab at this one, in this case I just concatenated the seed with the pubkey and hashed that, which should still give us different but deterministic payments

[carlaKC]

Great start on this!

[carlaKC]

Storing this so that we can split up rng = new() and rng.salted isn't very appealing to me - if we only need a field to instantiate the object, maybe we're instantiating it wrong.

I think it would be okay to have:

• new: as is, used to create MutRng
• get_salted_seed(u64, pubkey) => u64: a helper to generate the seed

The caller is responsible for setting up their own saltyseed and then calling new, but I think that's fine

[carlaKC]

nit: unnecessary comment (the code is so simple it's self-documenting IMO)

[carlaKC]

I asked the ai gods and they suggested just using a straight-up hash:

let mut hasher = DefaultHasher::new();
source.pubkey.hash(&mut hasher);
let salt = hasher.finish();

Since we only care about determinism here (not about salt that provides good entropy), I don't think it matters much which approach we use provided they yield distinct values per pubkey.

[carlaKC]

While it seems a bit deranged to use random values in a test about determinism, I think we can use get_random_keypair here to get different pubkeys on each run.

It should never fail for valid pubkeys, so we're basically fuzzing this incredibly slowly.

[sangbida]

Ah thanks for this! I was looking for a function like this! I was going to use this but didn't want to unecessarily add to Cargo.toml.

[carlaKC]

Ah, we already have our RNG in SimulationConfig which is why we need salted, got it!

Let's do a refactor commit before this one that provides the seed in SimulationConfig and then we can set up our own RNGs however we like internally. The caller already just passes in the seed and lets us handle it so I think it's fine to change.

[sangbida]

Just to clarify we want to remove seeded_rng from the SimulationCfg and replace it with the seed, then generate the rng inside random_acitivity_nodes?

[carlaKC]

Yeah that's what I was thinking - that way we've got the seed available to create our salted RNGs and don't need to store it in the RNG itself.

[carlaKC]

I don't think that this does what we want in the case where seed is None? In this case we want totally random behavior, and this will always seed with pubkey + 0 because of the unwrap.

I think that some good options here would be:

1. Move all this abstraction into the new function of MutRng

pub fn new(seed_opt: Option<(u64, Option<Pubkey>)>) -> Self

We'd invoke this differently based on use-case:

let base_seed = self.cfg.seed.map(|s| Some((s, None)));
base_rng = new(self.cfg.seed, None);

let seed_material = self.cfg.seed.map(|s| Some((s, Some(&node_info.pubkey))));
salted_rng = new(seed_material)

2. Match on presence of seed

let salted_rng = if let Some(s) = self.cfg.seed {
   MutRng::new(None)
} else {
  MutRng::salted(&node_info.pubkey, s)
}

I think that I prefer (1), but open to other approaches.

[sangbida]

I gave this another go by consolidating the salted functionality into new.

[carlaKC]

One last comment here - really close!

[carlaKC]

I would prefer to go with the nested options for seed_opt / pubkey because there is no valid case where you provide a pubkey but not a seed.

The handling isn't so bad if we get fancy with matching:

 pub fn new(seed_opt: Option<(u64, Option<&PublicKey>)>) -> Self {
        let seed = match seed_opt {
            Some(( seed, Some(pubkey) )) => {
                let mut hasher = DefaultHasher::new();
                let mut combined = pk.serialize().to_vec();
                combined.extend_from_slice(&seed.to_le_bytes());
                combined.hash(&mut hasher);
                hasher.finish()
            },
            Some(( seed, None )) => seed,
            None =>  rand::random(),
        }

        Self(Arc::new(StdMutex::new(ChaCha8Rng::seed_from_u64(seed))))
}