Closed jgresham closed 2 months ago
That will be a good improvement. In addition, it will be nice to have API to monitor trustedNodeSync progress.
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:
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.
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