Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove Kademlia DHT From Prysm #5864

Closed
2 of 3 tasks
nisdas opened this issue May 15, 2020 · 5 comments · Fixed by #6323
Closed
2 of 3 tasks

Remove Kademlia DHT From Prysm #5864

nisdas opened this issue May 15, 2020 · 5 comments · Fixed by #6323
Assignees
Labels
Networking P2P related items Priority: High High priority item

Comments

@nisdas
Copy link
Member

nisdas commented May 15, 2020

💎 Issue

Background

Currently we are running two methods of discovery on Topaz, both kademlia and DiscoveryV5. However running these two methods of discovery can strain the node as it has to maintain two separate dhts. The inital reason we ran kademlia was because our internal infrastructure could support it whereas we did not have a straightforward solution for udp routing in the cluster.

However running kad-dht had brought up some difficult issues for prysm to resolve:
#5663, #5588

In light of the difficulties faced with using kademlia-dht for discovery, it would be better if we could make prysm run only on DiscoveryV5 as this will be the prime method of peer discovery in mainnet.

Description

Tasks Required

  • Update our geth fork to the latest version to be up to date with the upstream branch.
  • Improve discovery searches to allow us to search by certain enr capabilities
  • Have the updated discoveryV5 protocol stable in Topaz before permanently running the network on it.
@nisdas nisdas added Networking P2P related items Priority: High High priority item labels May 15, 2020
@prestonvanloon
Copy link
Member

Do we have any data on how much resource usage is consumed by kademlia?

@prestonvanloon
Copy link
Member

I am wondering if additional discovery could be helpful, maybe we can start with an opt-out feature flag?

@nisdas
Copy link
Member Author

nisdas commented May 20, 2020

Most of the issues with kademlia are to do in the networking layer, with it continuously dialing private addresses and unroutable peers. Kademlia also does not have a way to throttle active discovery, which can cause it to continously dial new peers. Some users have also reported on their routers being overwhelmed due to large amount of connections constantly being opened from it. cc @terencechain

Since DiscoveryV5 is going to be the default method of discovery in mainnet, we should solely focus on it as that is also what other clients will most likely be only supporting. Running kademlia-dht kind of hides any potential issues with discoveryV5 , as a node could peer with another through kad-dht if discoveryV5 has a bug,etc.

@prestonvanloon
Copy link
Member

Sounds good to me. I agree that it doesn't have the flexibility that we need.

@prestonvanloon
Copy link
Member

Can we add a FF to disable kad dht? That could be a good way to introduce this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Networking P2P related items Priority: High High priority item
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants