Execution & Consensus Client Bootnodes

Just to be clear, we (Lighthouse and I believe all other CLs) retain the list of discovered peers after a restart.

Prysm does not just to clarify, we would discover a new set of peers again on a restart.

On the point brought up in this discussion, in the event of a coordinated censoring event across regions ( where all bootnodes are taken down) a straightforward solution would be to simply share a new list of enrs for nodes to boot from.

Also in the event a node has allowed inbound connections via the firewall then a restart of the client will not cause issues with discovering new peers for the fact they will still receive inbound discovery pings which should allow them to kickstart discovery again. I do not think this is a threat that is unrecoverable from, it is easy enough to startup nodes with a new set of ENRs.

That being said I will ping our infrastructure team on having a greater diversity of operators from which we host our bootnodes from. Also it would be fine to expand our current set of bootnodes which are in our client defaults to add in new entities(not client teams, EF, etc)

2 Likes