-
Notifications
You must be signed in to change notification settings - Fork 86
Development Plan for P2P Component
There are some distinct capabilities that are needed:
Bootstrap from (one or more of)
- Well known DNS / IP addresses shipped with release
- (post Shelly) use roots from stakepool registration certificates
[ chain based knowledge of published IP / names for stakeholders is a medium term goal - it needs operational decentralisation to work]
Needed for IOHK, stakepools & exchanges to create deployment architectures within a DMZ environment. Note that such fixed peers will be used as hot peers
- configuration of list of known peers by DNS/IP addresses
- ability to mark configured peers as gossip shareable or not
- ability to ensure that these are the only addresses and no more are discovered either by gossip or bootstrap mechanisms
Node can contact one of its warm/hot peers and request a number (think 20 - tbc) of its peers. Should not include duplicate entries Remote peer can be reported requesting peer of that set Peer set returned should be “fixed” for a given requesting peer
There is a security hazard here - should multiple requests (to the same peer - when that peer has not changed its set of peers) return the same collection of addresses or a new random selection Suggestion is that a peer should seed a random number generator on the basis of requesting peer “address”, and use that for selection. If the returned set was not of this fixed-random form then a malicious peer would only need to request a relatively small number of times to extract the totality of the connected peer’s peers. It is clear that a number of malicious peers could collaborate - but this approach requires them to engage in such development work. The remote peer should return peers from the union of the cold, warm and hot sets. Adversaries have to do more work - not just in the collaboration - but as the returned set contains cold peers - any attempt to “performance eclipse” (assuming remote peer had adequate bearer level DDoS protection in place) all those peers would require substantially more resources.
is this a seperate mini-protocol with a seperate version number? So that a busy node, when connected to and offered both the “full” set of protocols and this “simple” protocol can make the choice of the simple one - fulful the request and then close the connection. This gives the receiving node to gracefully degrade its functionality when loaded. It should be also part of the “full” set of protocols, so that warm/hot peers can be queried as part of their existing association.
- code review to identify modules that will need to change / those that will remain same
- decide shared peer pool (with cold/warm/hot mutators) or individual pools with messages moving peers between pools
- instantiate a simple peer exchange protocol
- deploy with simplistic promotion / demotion policy - but not allow total reliance on such
- embed the promotion / demotion policy from other strand of work
- check against real world deployment