filecoin-project / filecoin-project/specs
Gossipsub Hardening: Staked PeerIDs
- Dominant language
- SCSS
- Stars
- 363
- Forks
- 164
- PR merge metrics
- No merged PRs in 30d
Description
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
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by comparing the three proposals in this issue and resolving the open design discussion around account peer IDs, locked funds, and a dedicated actor. No files or tests are named; done means selecting and documenting an agreed approach and its implementation scope.
Written by the indexing model from the issue text.
Assessment
- Domain
- blockchain, distributed-systems, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100