All section keys total size?

Just looking to do a bit of a sanity check…

How big will the entire history of membership be?

Any network operation is signed by a set of elders. Checking for a valid signature requires checking the key used to do it really was part of the network (might be a very old key). How easy will it be to do these sorts of checks?

The relevant data structure is SectionAuthorityProvider (SAP) specified in section_authority_provider.rs#L63

Every time elders change there will be a new SAP between 240 to 272 bytes (is this correct?):

pub struct SectionAuthorityProvider {
    // N bits, up to 256 bits, 32 bytes
    prefix: Prefix,

    // 5-of-7 gives 5 coefficients of 48 bytes each, 240 bytes
    public_key_set: PublicKeySet,

    // Not included in the history
    elders: BTreeSet<Peer>,

    // Not included in the history
    members: BTreeSet<NodeState>,

    // Not included in the history?
    membership_gen: Generation,
}

This will be signed by the previous elders, which is presumably a 48 byte public key and 96 byte signature, taking the total size per elder change event between 384 to 416 bytes (maybe don’t need the previous public key, it’s part of the prior SAP?).

I estimate the full history of these keys/events won’t ever get more than about 10 GiB but wanted to see what others think and whether there’s any other info I’m missing from the above.

Calcs for full size of history:

  • Prefix length 20 gives about 1M current sections
  • which is about 2M total sections for all history
  • Assuming on average 3 elder changes per section before split gives about 6M total elder changes.
  • 416 bytes to store each change event × 6M changes is about 2.4 GiB

Main reason for caring is nodes hopefully can easily keep the entire history locally so can look up keys for old signatures on old operations without needing to do network GET requests for old SAP data. It looks like this will be easily done, probably in RAM but at worst lookup by local disk.

Any faults in the logic here? Could it be an order of magnitude larger or smaller? Is it ok if the full history can’t easily be stored locally?

16 Likes

I cannot see any. However, we don’t need to save SAPs just the actual pub key signed by the previous key. So the total size will be limited to the list of

But also held in a tree format to cover all sections. (i.e. a PrefixMap type container, cc @yogesh who is working in there right now)

6 Likes

None at all really. IIRC, we did this calc back when we replaced PARSEC with the current consensus model and came down to the conclusion that we could hold on to the history if needed(though a few things might’ve changed by now, the size largely remains the same).

5 Likes