go/worker/storage: Transition storage sync to P2P

[kostko]

TODO

• Go over storage sync metrics and consider adding some more metrics.

[kostko]

Task linked: CU-1zfn2j9 Transition storage sync protocol to libp2p

[codecov]

Codecov Report

Merging #4459 (eaf491f) into master (cb18563) will decrease coverage by 0.03%.
The diff coverage is 74.23%.

@@            Coverage Diff             @@
##           master    #4459      +/-   ##
==========================================
- Coverage   68.83%   68.80%   -0.04%     
==========================================
  Files         415      423       +8     
  Lines       46799    47241     +442     
==========================================
+ Hits        32214    32502     +288     
- Misses      10625    10740     +115     
- Partials     3960     3999      +39     

Impacted Files	Coverage Δ
go/registry/api/api.go	58.48% <ø> (ø)
go/worker/common/p2p/rpc/types.go	0.00% <0.00%> (ø)
go/worker/storage/committee/utils.go	92.30% <ø> (ø)
...n/crypto/signature/signers/memory/memory_signer.go	57.14% <40.00%> (-4.68%)	⬇️
...ommon/crypto/signature/signers/file/file_signer.go	60.74% <65.21%> (+3.59%)	⬆️
go/worker/storage/committee/checkpoint_sync.go	65.27% <65.62%> (-11.16%)	⬇️
go/worker/common/p2p/peermgmt.go	78.29% <68.00%> (-5.13%)	⬇️
go/worker/common/p2p/p2p.go	67.00% <69.69%> (-1.54%)	⬇️
go/worker/storage/committee/node.go	76.49% <72.72%> (+0.65%)	⬆️
go/worker/common/p2p/rpc/client.go	75.78% <75.78%> (ø)
... and 47 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5041b59...eaf491f. Read the comment docs.

[Yawning]

So this doesn't propagate errors? Does it need to?

[Yawning]

The more I think about this, the more I am incredibly against exposing the actual private key to handle libp2p's garbage bullshit. Instead I propose something like this:

// In the signature package.

// StaticEntropyProvider is the interface implemented by signers that support providing
// persistent static entropy that is entirely independent from a keypair.
type StaticEntropyProvider interface {
  // StaticEntropy returns PrivateKeySize bytes of cryptographic entropy that
  // is independent from the Signer's private key.  The value of this entropy
  // is constant for the lifespan of the signer's underlying key pair.
  StaticEntropy() []byte
}

When initializing the file signer, load (or generate) cryptographic entropy and persist it to libp2p_is_dumb.pem or something, and use that instead of exposing the private key.

[kostko]

Agreed, that sounds like a better solution, especially given that the only use case for this is to generate the QUIC reset key.

[Yawning]

Agreed, that sounds like a better solution, especially given that the only use case for this is to generate the QUIC reset key.

We are pretty good about separating concerns and using different keys for basically everything, but deriving stuff like that off a signing key makes my tinfoil hat crinkle, even if the derivation procedure looks "ok".

[kostko]

@Yawning I just pushed a version that uses the static entropy provider, please take a look.

[ptrus]

So a peer failing all requests quickly, will have a similar (slightly worse) score than an average node returning all correct results? Hm, I guess that does make sense, since if the peer is failing quickly that's not really all that bad, as not a lot of time is spent on it.

Maybe the penalty part for failing could have an additional constant factor? But I have no reason to suggest anything other than 1.

[Yawning]

@Yawning I just pushed a version that uses the static entropy provider, please take a look.

That looks about like how I would do it.