[enhancement] Publish ENR Tree (EIP-1459) for DNS-Based Discovery

[onelapahead]

Thanks for this repository, its been very helpful in running our Base nodes for Mainnet and Sepolia.

However - we were wondering if the Base ecosystem was looking into publishing an ENR tree via DNS such as what Ethereum does: https://github.com/ethereum/discv4-dns-lists. This is based on https://eips.ethereum.org/EIPS/eip-1459.

As I understand it, they use utilities in geth to crawl their nodes for peers, have the peers sign ENR records, maybe there's some weighting of peers by availability and reputation, and they publish those aggregated records into a ENR tree on a CloudFlare hosted DNS domain. More details are here: https://geth.ethereum.org/docs/developers/geth-developer/dns-discovery-setup

This allows for discovery reputable peers much more easily than relying on static, boot nodes in our experience. Polygon recently adopted this to help node runners find reliable peers more quickly: https://forum.polygon.technology/t/introducing-our-new-dns-discovery-for-polygon-pos-faster-smarter-more-connected/19871. Most clients support such DNS based discovery, for example:

• https://docs.nethermind.io/fundamentals/configuration/#network-discoverydns
• https://geth.ethereum.org/docs/developers/geth-developer/dns-discovery-setup#using-dns-trees

Will Base be considering such maintenance of discovery lists and DNS records in the near-term ?

Cheers !

[wearedood]

This is an excellent enhancement that would significantly improve Base node discovery efficiency. I'd like to contribute to implementing this feature.

Implementation Approach

Based on the EIP-1459 specification and the references provided, here's my proposed implementation plan:

1. ENR Tree Generation

// pkg/discovery/enr_tree.go
type ENRTreeBuilder struct {
    nodes     []enode.Node
    domain    string
    signer    crypto.Signer
    ttl       time.Duration
}

func (b *ENRTreeBuilder) BuildTree() (*dnsdisc.Tree, error) {
    // Convert Base nodes to ENR format
    // Build merkle tree structure
    // Sign tree root with private key
    return tree, nil
}

2. DNS Record Management

• Integrate with existing Base infrastructure for DNS management
• Implement automatic tree updates when node set changes
• Add monitoring for DNS propagation and health

3. Configuration Integration

# Add to base node config
discovery:
  dns:
    enabled: true
    domain: "nodes.base.org"
    update_interval: "1h"
    tree_ttl: "24h"

4. Client Integration

• Update node discovery logic to query DNS trees first
• Fallback to existing discovery methods
• Cache DNS results with appropriate TTL

Benefits for Base Ecosystem

1. Faster Bootstrap: New nodes can discover peers immediately via DNS
2. Reduced Load: Less reliance on boot nodes
3. Better Decentralization: Multiple DNS providers can host trees
4. Mobile Friendly: DNS queries work well in restricted networks

Timeline

Given the Builder Rewards contest timeline, I propose:

• Phase 1 (24-48h): Core ENR tree generation logic
• Phase 2 (48-72h): DNS integration and testing
• Phase 3 (72h+): Client-side discovery integration

I'm ready to start implementation immediately. Would the maintainers prefer this as a single large PR or broken into smaller, reviewable chunks?

@onelapahead Thanks for opening this - it's exactly the kind of infrastructure improvement Base needs for better decentralization!

[wearedood]

Supporting ENR Tree Implementation

This is an excellent infrastructure enhancement that would significantly improve Base node discovery efficiency. I'd like to offer support for this implementation.

Documentation & Integration Support

As someone currently working on Docker Compose documentation improvements (issue #536), I see strong synergy between these efforts:

• Containerized Discovery: ENR trees would greatly benefit containerized Base node deployments
• Developer Experience: Faster peer discovery improves local development workflows
• Production Readiness: DNS-based discovery is essential for scalable infrastructure

Proposed Contribution Areas

1. Documentation Support

   • Create comprehensive setup guides for ENR tree configuration
   • Document DNS provider integration steps
   • Provide troubleshooting guides for discovery issues

2. Testing & Validation

   • Help test the implementation across different network environments
   • Validate Docker Compose integration scenarios
   • Document performance improvements and benchmarks

3. Configuration Examples

   • Provide production-ready configuration templates
   • Create examples for different deployment scenarios
   • Integration with existing Base node setups

Implementation Preference

Regarding your question about PR structure - I'd recommend smaller, reviewable chunks for this complex feature:

• Phase 1 PR: Core ENR tree generation logic
• Phase 2 PR: DNS integration and infrastructure
• Phase 3 PR: Client-side discovery integration

This approach allows for:

• Better code review quality
• Easier testing and validation
• Incremental deployment and rollback capability

@wearedood Would you like collaboration on the documentation and testing aspects while you focus on the core implementation? I have experience with Base node operations and can provide comprehensive documentation support.

@onelapahead Thanks for initiating this important infrastructure improvement!

[onelapahead]

@meyer9 - @wearedood looks like AI spam. Hope it doesn't distract / discourage the community from engaging on this thread or others.

If the Base org can do anything to mitigate such spam that'd be appreciated.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.