ethereum
EIP-1459: Node Discovery via DNS
https://eips.ethereum.org/EIPS/eip-1459
This issue is for discussion of the DNS-based discovery mechanism.
While working on the go implementation of the EIP, I realized that it might be better to split the 'link' tree from the 'enr' tree. This is better because clients want to track all the links, but don't necessarily want to download the entire tree to find them all.
Having all the links is important to make the web-of-trust work: the client starts with a single 'main' tree and discovers additional trees through links. When a link is deleted from the main tree, the client should stop following the linked tree.
Note to myself: the plan for creating up-to-date lists is to resolve records through the DHT before generating the tree. The code that does this should check whether there are any changes to record content. If the record found in DHT has identical content but a higher sequence number, it's better to include the older record in the tree to avoid pointless updates.
What weight is on the "always available" part of rationale?
At Status.im we've been exploring different ways of distributing bootnodes' information, and DNS was one of the options, but we're assuming adversary environments, where ISPs are not our friends. It quickly became obvious that in public places (airports, shopping malls, public wifis, etc), DNS is often blocked on transport layer and only Access Point's own DNS server is permitted to use. For the scenarios where the government is actively trying to shut down the service, DNS is a an extremely easy target to control due to its hierarchical nature.
I know our use case is a bit different, but adding it to discussion anyway.
By "always available", I meant that DNS is widely deployed and you'll always have a name server within reach. That doesn't say the name server will be good. It's worth noting that the server can't modify the node list because it's signed. It can censor it, but any form of network communication can be censored.
What weight is on the "always available" part of rationale?
At Status.im we've been exploring different ways of distributing bootnodes' information, and DNS was one of the options, but we're assuming adversary environments, where ISPs are not our friends. It quickly became obvious that in public places (airports, shopping malls, public wifis, etc), DNS is often blocked on transport layer and only Access Point's own DNS server is permitted to use. For the scenarios where the government is actively trying to shut down the service, DNS is a an extremely easy target to control due to its hierarchical nature.
I know our use case is a bit different, but adding it to discussion anyway.
Is ENS a viable alternative?
I am very interesting at the DNS discovery, but the module seems a little complicate. Can you specify some scenario of dns discovery service? what's the fallback option when connectivity to the discovery DHT is unavailable as explained at https://geth.ethereum.org/docs/developers/dns-discovery-setup ? if we supply an api such as get_all_nodes or get_random_node by the fullnode, this is very simple. Is there some advantage? Thank you very much.
@317787106 We have two separate peer discovery mechanisms right now: (1) the DHT (2) the DNS discovery. Both of them can be used to find peers to connect to. The DNS discovery is the 'fallback' in case the connection to DHT cannot be established.
The API idea get_all_nodes you are suggesting would not work so well, because every node would need to ask this API for nodes in the beginning. We use the DNS instead because it is easier to scale and easier to provide this 'common endpoint'.