Helios fails to sync (invalid sync committee period) #388
Comments
|
Yes so the reason for this is that the networking spec defines a maximum number of light client updates you can fetch at once, which Nimbus (the node we use for the consensus rpc that we provide by default) enforces this. This means the maximum age of a checkpoint Helios can fetch is 128 * 27 hours = 144 days. This could be addressed by having Helios make multiple update request calls here. We haven't supported this in the past, since we suggest users start up with a somewhat recent checkpoint (and after first sync, helios caches new checkpoints to use, so as long as clients go online every so often after first sync, you are good). The reason we suggest this is there is a class of attacks known as "long range attacks" or "weak subjectivity attacks" that you become susceptible to if you use very old checkpoint. Fortunately for the light client protocol, these attacks are hard to pull of in practice. It shouldn't be to hard to calculate how many updates you need by finding the expected period (using |
|
Thank you for the explanation @ncitron I did the following changes based on your comments and seems to work, but I am not sure if I could be missing some corner cases. Any place where I could read more on long range attacks/weak subjectivity? It is good for me to understand the potential risks for my intended use. |
|
I think the main change I would make to that is we should provide exactly how many updates we need, rather than just doing the MAX for each time. |
and others
Hello, I am experimenting with Helios and noticed something that I need to understand and may be a bug.
I would like to use Helios to validate historical data, which means that I am interested in running Helios from the oldest checkpoint possible. Moreover, as time goes by, and more checkpoints are created, I will still want to start from that oldest possible checkpoint.
I started then Helios like this (I am testing changes to the code, so I am building the code)
I ran it in that way to trigger Helios to use the BaseConfig checkpoint
which seems to be for this block at slot 8613568 (from Sep-24-2019 07:15:20 PM +UTC) which looks fine. And I know that in theory, I am be able to run with
--checkpointand use that checkpoint later to fix that as a starting one.Now, the issue I have is that Helios fails to sync. This happens at "around" (below is the last update I see validated by Helios in my prints) the point where the finality update has
Here are the normal logs:
If I load a newer checkpoint, I know it works (as I saw recommended in #361) but for my use case this is not ideal. I saw this same issue in Holesky testnet (at a different slot of course as it is a different chain).
My questions are:
Thank you in advance for the responses
The text was updated successfully, but these errors were encountered: