Geth light mode look back configuration feature request

[sidhujag]

Great work guys! I’m doing a trustless bridge to eth from the Syscoin blockchain which is forked from Bitcoin.

I use geth light mode to grab headers and a relayer which feeds syscoin with tx merkle roots for my merkle proof to verify spv transactions on the way back to syscoin from ethereum. For performance I only need to really keep about 100k blocks (you should move over the bridge within this time once you burn funds). Also because I noticed that geth seemed to download only a few months of headers but I now have learned that is because of the checkpoints at the time of release cycles.

Since my consensus code depends on geth light mode via the relayer it would be great to have a deterministic way to know I should have geth synced to at least X blocks regardless of checkpoints.

The request is to allow geth light to sync back from the tip X blocks where X is defined via config. Therefor I wouldn’t be reliant on checkpoints.

I also assume you don’t use very recent blocks as checkpoints for security reasons. Do you have an internal process around what the min amount of blocks to put the checkpoint back from the tip at the time? 1 month of blocks seems like what you have been using. Is this process followed every release? I still prefer having a config so I can set it and therefor not have to sync more than I need.

Thanks for reading!

[karalabe]

Our checkpoints are a bit smarter. We don't hard code a starting header, rather a Merkle root of all the previous headers since genesis. This means that even though we only sync from some arbitrarily recent hard coded point in time, all past headers can still be retrieved and proven.

I.e The CHT's goal is both to sync fast and to prove past headers.

[sidhujag]

@karalabe

ok but I need some deterministic way to retrieve those headers in light mode so the process remains trustless. Although its great that the node won't lie about state likely it would still be awesome if we can define you know that we only need X amount of blocks to sync up so it doesn't take longer and longer to sync, also when an upgrade happens to CHT's then we still want to look back a minimum amount... likely X > Y where X is the amount of blocks back the CHT enforces nodes to download and Y is the minimum amount we need around in consensus to verify spv proofs so this setting won't actually affect the security domain around smart CHT's but will force nodes to download a bit more in times of upgrades.

How would I grab previous headers that have not been downloaded and check say a receipt root and transaction root? I would need a merkle path to the root and thus provide all siblings which I also don't have.

[karalabe]

You can actually "just retrieve" them. As far as I know, if a header is missing (under the CHT), the client will just pull it from the network and ensure it's correct by also implicitly proving it against the CHT.

But cc @zsfelfoldi @rjl493456442 just in case.

[rjl493456442]

@sidhujag Regarding the CHT, we have a PR #19543 to update the CHT with the help of smart contract. So that we can update it as soon as possible, instead of waiting for the release cycles. But the minimal headers for clients to sync is 32768. If you want to sync the chain with top of 1024 headers(for example), probably we need some customization.

And if you want to look back some block headers which below the CHT, all you need to do is to "retrieve" them. Since all past headers are covered by CHT, so that we can verify the correctness of headers without sacrificing the security guarantee.

[sidhujag]

Would be nice if it were a configuration for that 32768, I have 40000 in my code as the amount of headers to rely on coming from Geth after playing around with light mode, I guess I was pretty close, but if I can set it to a number I'd prefer 60 or 80k as the minimum.

[zsfelfoldi]

@sidhujag you cannot configure the CHT frequency. In theory you could still download and verify more headers but as @karalabe and @rjl493456442 said you don't really need it. Any header from the entire history can be obtained on demand in a trustless and transparent way. Here is a description of our data structure used for checkpointing:
https://github.com/ethereum/devp2p/blob/master/caps/les.md#canonical-hash-trie
This is basically a Merkle tree of all block hashes and Geth light client retrieves them with Merkle proofs if they are not already downloaded.
Honestly I don't believe that downloading headers from an earlier point is a feature that many users would need but if you want to try it you can modify the starting block here:
https://github.com/ethereum/go-ethereum/blob/master/light/lightchain.go#L474
You can start header syncing from any block between 0 and the currently calculated CHT head.

[sidhujag]

@zsfelfoldi
I would like to avoid forking Geth as its under heavy development, more things to manage. I didn't ask to configure the CHT frequency all I asked was that if "the minimal headers for clients to sync is 32768" can be modified to any number which forces the node to download that many headers by default. I definitely can use that feature as my consensus code depends on it.

Thanks!