status-im / nimbus-eth2

Nim implementation of the Ethereum Beacon Chain
https://nimbus.guide
Other
523 stars 227 forks source link

Single command for beacon node and checkpoint sync. Remove separate command for `trustedNodeSync` #6297

Closed jgresham closed 2 months ago

jgresham commented 4 months ago

Is your feature request related to a problem? Please describe. No just a UX improvement

Describe the solution you'd like No need to run trustedNodeSync as a separate process/command at the beginning. Just run one command like so: <start beacon node as normal> --trusted-node-url=<checkpoint-sync-url>

Describe alternatives you've considered Most other clients support this

Additional context This will help simplify logic for apps that run nodes for users

cmd0s commented 3 months ago

That will be a good improvement. In addition, it will be nice to have API to monitor trustedNodeSync progress.

marmarek commented 2 months ago

I'd prefer to retain separate command (even if standard run would support trusted node sync too). I have a connection to the trusted node via a tunnel that needs to be specifically enabled, which means:

  1. It won't be available on further startup, so using the option for normal startup means I would need to add to add it to standard startup script and then remove after the sync.
  2. I need to know when sync completes to cleanup the tunnel, and it's more convenient to script by simply seeing when the command completes, instead of watching an API (and then triggering service restart anyway - see earlier point).
tersec commented 2 months ago

A general point is that within the weak subjectivity period, a node can trust its own state not to be mislead by arbitrary hostile/malicious input, but if there's an automated mechanism that runs ever startup or similarly which allows effectively rewriting a node's perceived history and puts it outside the safety of this weak subjectivity period, that's a potential attack vector.

We might look at this at some point, but right now, it would fundamentally alter the trust model of a node from only having to trust its own data to every time having to trust some external entity, precisely because the advantage here would be that one does't have to remove the TNS parameters each time.

The T stands for trusted, yes, but part of that is the verification by another node, per what the Nimbus guide suggests, and that's not feasible in an automated way.

We're exploring alternate approaches to this, but as it stands, we're not likely to change this without other circumstances changing.