Ensure macro blocks adhere to the block separation time of 1s

[sisou]

This fixes #3296.

Pull request checklist

• All tests pass. The project builds and runs.
• I have resolved any merge conflicts.
• I have resolved all clippy and rustfmt warnings.

[sisou]

Devnet Release Scenario run: https://github.com/nimiq/core-rs-albatross/actions/runs/14704410843

[jsdanielh]

Shouldn't we add a check for this in verify_macro_block_proposal?

[sisou]

No that would make it non-backward compatible. The beauty of this change is that old and new nodes will accept it (I think). Adding that check would make it a hard-fork.

[jsdanielh]

No that would make it non-backward compatible. The beauty of this change is that old and new nodes will accept it (I think). Adding that check would make it a hard-fork.

Mmm, then we could check for an acceptable range. Otherwise, we could accept any value there that could make the opposite effect.

[hrxi]

Have you tested that this has the desired effect? By what mechanism does this introduce a one second delay?

Is it by making the next micro block producer wait two block separation times? Is the macro block not accepted/produced for another second due to this header change?

[sisou]

I have not verified it. Would we worth a private testnet run to see if it works.

I believe it produces the macro block directly (there's no waiting loop there like we have for the micro blocks) and then the next micro block waits 2 block times.

If that's really how it works, can you please check if there is a limit for what the macro block timestamp can be in a proposal? Can it be set to 1 year in the future?

[nibhar]

I was looking into this again, and I believe this to be the actual easiest and smallest addition that can be made to make honest nodes adhere to the 1 second separation time floor.

No that would make it non-backward compatible. The beauty of this change is that old and new nodes will accept it (I think). Adding that check would make it a hard-fork.

Mmm, then we could check for an acceptable range. Otherwise, we could accept any value there that could make the opposite effect.

This is already in effect. Timestamps within TIMESTAMP_MAX_DRIFT are acceptable, and thus max(parent+1s, now()) is an acceptable value. There is also little incentive other than malice to do this, as there is a batch delay penalty. Putting this into validation is a hard fork and I don't think it is needed. Could be folded into a future hard fork as a nice to have maybe.

I believe it produces the macro block directly (there's no waiting loop there like we have for the micro blocks) and then the next micro block waits 2 block times.

That would be my assessment as well

If that's really how it works, can you please check if there is a limit for what the macro block timestamp can be in a proposal? Can it be set to 1 year in the future?

There is a TIMESTAMP_MAX_DRIFT constant that dictates this, but only for wall clock, as we do not have a network clock. currently this is 10 minutes which admittedly, is not exactly small, but also not huge either.

If there are no objections I will resurrect this PR and add a regression test to it.

[linear]

T404-170