P2P Optimizations

[KPrasch]

Porter Network Request Lifecycle

A recap of Porter's network requests chronologically:

• GET /sample
• Porter Samples
  • RPC Call to getActiveStakingProviders get list of n eth addresses
  • block_until_number_of_nodes_is == n else (10s timeout):
    • Fetch Certificate
    • /public_information
  • If sampled is known (10s timeout):
    • Fetch Certificate
    • GET /ping
  • If not known:
    • Get another value from Pool
• Porter responds to GET Request to /sample

Optimization Ideas

Cheaper

• [x] Extend timeouts (#2908 )
• [ ] Min/Max Porter samples
• [x] Optimistic TLS certificate caching (#2908)
• [x] Optimizing the worker pool (#2908 - flexible pool size, short circuit worker stop when sufficient successes)
• [ ] Caching of active stakers for sampling (#2913) One other thought I had was, a slower aspect of Porter is generating the staking reservoir used for sampling i.e. calling out to the PREApplication to get the current active staking providers - perhaps the result of that call can be cached for some amount of time - it probably doesn't change significantly over shorter spurts of time
• [ ] Option to skip liveliness check (Porter)?
• [ ] Cache node liveliness We can think about a cached list of nodes (probably a fixed size) that we've already checked, and bias the list by usage (this should probabilistically be correlated to stake size). Something like track number of times a node is returned from sampling, and then add it to the cache it after some number of times used. Therefore, for subsequent sampling if we encounter a node in that cached list we can just use it without verifying it. However, the question becomes the size of that list, what timeframe is considered "fresh", how often do we cycle through that list in the backgrounds to re-verify the nodes (the bigger the list, the trickier this becomes)

More Expensive

• [ ] Use a formal concurrency library