Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Relativize genesis block #119

Merged
merged 5 commits into from
Apr 9, 2024
Merged

Conversation

aszepieniec
Copy link
Contributor

  • Make Block::genesis_block take Network as a parameter. Every network has its own genesis block.
  • Hardcode the timestamp of the genesis block for all Network variants except RegTest.
  • Timestamp for RegTest is 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 calls Block::genesis_block twice and on opposite sides of a round point in time. This happens with very small but nonzero probability.
  • Add variants Beta and Main to enum Network.
  • Harmonize timestamps: now use Timestamp for consensus-critical timestamps.

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.
@dan-da
Copy link
Collaborator

dan-da commented Apr 2, 2024

why not hard-code regtest genesis-block timestamp also?

@aszepieniec
Copy link
Contributor Author

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.

@dan-da
Copy link
Collaborator

dan-da commented Apr 9, 2024

@aszepieniec I merged master into your branch so we can get this merged soon.

@dan-da
Copy link
Collaborator

dan-da commented Apr 9, 2024

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.

@dan-da dan-da merged commit 8f31ff5 into master Apr 9, 2024
3 checks passed
@dan-da
Copy link
Collaborator

dan-da commented Apr 25, 2024

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 Block from neptune-core model, and so is able to call Block::genesis_block() directly in order to determine the genesis block hash, which is then output as hex and embedded in an html link. When a user clicks on that link, the explorer makes an RPC call to neptune-core to lookup the (genesis) block by digest. The rpc call returns a not-found because neptune-core generated a different regtest genesis block than the block-explorer.

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.

https://bitcoin.stackexchange.com/questions/122778/is-the-regtest-genesis-hash-always-the-same-or-not

so, for your consideration...

@dan-da
Copy link
Collaborator

dan-da commented Apr 25, 2024

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants