search

threefoldfoundation / tfchain

Official implementation of the ThreeFold blockchain
https://explorer.threefoldtoken.com
Apache License 2.0
13 stars 7 forks source link

ensure tfchaind is fully synced with the ETH network prior to starting #247

Closed GlenDC closed 5 years ago

GlenDC commented 5 years ago

When using the --ethvalidation flag, the tfchain daemon will not only connect to the tfchain network, but also to the matching Ethereum network (in light-mode). This is used for the validation of ERC20 CoinCreation transactions (a feature added as part of story https://github.com/threefoldtech/home/issues/56).

Currently the tfchaind doesn't wait for syncing, meaning that if you enable it for the first time it will take you at least a couple of minutes before you are fully synced with the latest block (headers only). Until that is done, you might not be able to validate proper as the desired block might not be found yet. Therefore we should probably wait a couple of minutes (or as long as is needed for syncing to the latest at that time), similar to how tfchain by itself also waits a bit while syncing at startup.

LeeSmet commented 5 years ago

It would seem that in light client mode, untill we are synced, all calls (to other peers) fail with the error "no suitable peers available", defined here. If you can confirm that this is the case, we could make a function loop until it no longer gets this error (or do a dummy call which repeats until this error goes away) to detect sync state

GlenDC commented 5 years ago

That would have to be with a call that for sure goes to a peer without failing first in a local check already. For the validator module for example we try to fetch a block from a peer, however it will already fail prior to even calling a peer for it, as it won't find the header for that block hash in the local DB, and therefore returning in a block not found error instead.

Also not the biggest fan of this approach, but if nothing else this might be indeed a solution that can help us for now.

LeeSmet commented 5 years ago

It would seem that peers are accepted as soon as the node has been in sync at least once, e.g. after a downtime and subsequent restart the error is only triggered if there is legitimately not a single peer, which might happen even after previous calls already succeeded, so I guess this is also not an option

GlenDC commented 5 years ago

I think I have found a clean solution, will post in a couple of minutes to tell if it is true.

GlenDC commented 5 years ago

Closed by 9f287da in merged PR #250.