feat: Relativize genesis block #119
Conversation
Add variants `Beta` and `Main`. Add member function `launch_date` which is fixed for all but `RegTest` and for `RegTest` rounds now down to a block of 10 minutes.
Introduces a new struct, `Timestamp`, for consensus-critical timestamps. `Timestamp` is a wrapper around a `BFieldElement` which counts the number of milliseconds elapsed since the Unix epoch. Closes #117.
Deconvolutes tests.
|
why not hard-code regtest genesis-block timestamp also? |
You might be able to find a configuration along those lines that works. It's not impossible, just difficult. The challenge is to find the right timestamp to set it to. If it is in the future, tests will fail because you shouldn't be able to send and receive future blocks. If it is in the past, the automatically updated network parameters (right now only difficulty) are updated with respect to a unrealistically large and unfixed block interval. |
|
@aszepieniec I merged master into your branch so we can get this merged soon. |
|
lgtm. Definitely a win to have a proper Timestamp type. I'm seeing some errors validating newly mined blocks, but those were already happening, so this PR doesn't seem to blame. I'm going to merge now as-is. |
|
With regards to regtest having a non-fixed timestamp, yesterday I encountered a real-world issue with this. In building a block explorer, the explorer needs to work with any network. I initially added a config option for this. The explorer has access to Given this issue, I worked around it by querying neptune-core at startup to obtain the genesis block digest, and that works fine. However, coming from bitcoin and other blockchains I find this surprising behavior and don't feel like it should be necessary. Generally "crypto" apps can rely on genesis blocks being immutable and known to all. It's also a bit of a footgun because if i had tested only with networks alpha and testnet, I would not have caught the issue and the block-explorer would have a serious bug with respect to regtest. To ensure I am correct on this point, I reviewed the bitcoin chainparams code. I was still a little unsure, so I asked about it on stackexchange and bitcoin devs answered that indeed regtest genesis block is fixed in code and hash will always be the same. so, for your consideration... |
Are we doing something fundamentally different from bitcoin with the difficulty adjustment? it doesn't seem to be a problem there. hmm, I guess we are. As I recall, bitcoin does somehow keep difficulty artificially low for regtest so that new blocks can be found easily, and they have a dedicated rpc call for generating blocks. here's a description: https://bitcointalk.org/index.php?topic=5268794.0 |
Block::genesis_blocktakeNetworkas a parameter. Every network has its own genesis block.Networkvariants exceptRegTest.RegTestis now but rounded down to the prior round point of 10 minutes. This may cause tests to fail, in particular if the test in question callsBlock::genesis_blocktwice and on opposite sides of a round point in time. This happens with very small but nonzero probability.BetaandMainto enumNetwork.Timestampfor consensus-critical timestamps.