Gossipsub Hardening: Staked PeerIDs

[whyrusleeping]

As part of our effort to improve the security of our gossip layer, the gossipsub team has put forward an initial request that we allow users to associate peer IDs with their accounts, so that we can use peerID associated funds as an anti sybil mechanism. There are a number of ways to do this, so we should have some discussion around the possibilities here.

Proposal 1: Add an arbitrary key value store interface to normal account actors (This is already a highly requested feature, and is likely to be implemented anyways). Designate the key "peerID" or "libp2p" as a field that should contain your nodes peer ID. Clients should then track all accounts with a peer ID registered, and weight those peer IDs using the account balance and peer ID from a lookback, only applying the score if the peer ID now matches the peer ID from N blocks ago, and the account balance has remained the same (we could make this more secure by making the score be contingent on the actual nonce of the account, to ensure no funds or ID changes have happened recently).

Implementation impact: minimal

Proposal 2: Add the abitrary key value store still, but have users lock up funds in a multisig contract with their account as the only signer. As long as X funds are still locked up for Y blocks, the peer ID that is set on the account owning the multisig should receive a score. This proposal is easier to avoid abuse, we can ensure the funds are locked up for some time, instead of having to rely on looking back in the chain, we have a guarantee that funds are locked.

Implementation impact: roughly the same as above

Proposal 3: Implement a separate actor specifically for locking up funds for specific peer IDs. This lets us implement exactly the logic we need for this, but introduces a lot of application specific logic i'd like to avoid. And the mechanisms involved are less reuseable.

Implementation impact: medium

[whyrusleeping]

This all gets much more secure if you start burning funds, but thats quite a severe jump to make. I'm not convinced that its necessary yet

[vyzo]

A recommendation here would be to start with a negative application specific score when there are no locked up funds; this way an attacker won't be able to even get in the mesh without locking up funds.

[whyrusleeping]

@vyzo the issue there is that this makes the lives of normal users much harder

[vyzo]

They should still be able to publish transactions and receive messages through gossip.

[whyrusleeping]

@vyzo what would the actual impact of a peer having a negative score in the mesh be?

[vyzo]

All negative score peers are pruned from the mesh; they will only get messages through gossip and flood publishing. The negative score penalty for unstaked participation should be above the gossipThreshold. Regardless, with the gossip factor set at .25 they have very high probability of receiving all messages if they have a few connections to mesh peers (albeit with gossip latency).

[whyrusleeping]

What would happen if all peers in your mesh had negative scores?

[vyzo]

they would all get pruned and you would look for new peers (that have non-negative score) to graft.

[whyrusleeping]

And if all peers had negative scores for some reason? would the mesh then just kinda disintegrate?

[vyzo]

yes, it would fall back to gossip propagation.