Set hard fork config slot and timestamp properly #18028

cjjdespres · 2025-10-29T01:06:53Z

The hard fork global slot since genesis and the hard fork timestamp are now set according to the stop slots and the hard fork genesis slot delta, if those components of the daemon config have been set. If they have not, then the slot and timestamp of the hard fork block itself are used as a fallback.

The forkConfig graphql query still does not set the genesis timestamp in the config it returns, just to keep its behaviour unchanged for now. I think it may end up being more convenient to have the daemon set the timestamp itself when it can; if so, the forkConfig output can probably be changed to include the timestamp. I think the hard fork test(s) would have to be adjusted slightly if we were to do that.

The hard fork global slot since genesis and the hard fork timestamp are now set according to the stop slots and the hard fork genesis slot delta, if those components of the daemon config have been set. If they have not, then the slot and timestamp of the hard fork block itself are used as a fallback.

cjjdespres · 2025-10-29T01:07:06Z

!ci-bypass-changelog

cjjdespres · 2025-10-29T01:07:13Z

!ci-build-me

cjjdespres · 2025-10-29T01:09:48Z

src/lib/mina_lib/mina_lib.ml

+  let global_slot_since_hard_fork_to_genesis
+      ~(constraint_constants : Genesis_constants.Constraint_constants.t)
+      global_slot =
+    (* Convert the global slot to a span of slots since the current hard fork *)
+    let global_slot_span =
+      global_slot |> Mina_numbers.Global_slot_since_hard_fork.to_uint32
+      |> Mina_numbers.Global_slot_span.of_uint32
+    in
+    (* Retrieve the global slot since genesis of the genesis of the current
+       chain *)
+    let current_genesis_global_slot =
+      constraint_constants.fork
+      |> Option.value_map ~default:Mina_numbers.Global_slot_since_genesis.zero
+           ~f:(fun fork -> fork.global_slot_since_genesis)
+    in
+    (* Add the slot span to the current chain's genesis slot to get the desired quantity *)
+    Mina_numbers.Global_slot_since_genesis.add current_genesis_global_slot
+      global_slot_span


I think this calculation is correct, but I couldn't find an existing method to do it.

I'm suprised there's no such helpers elsewhere.

Was going to suggest we put this into module Global_slot_since_hardfork. But there could be some circular dependency issue(or maybe not?).

Could we put a comment in that module indicating there's a conversion implementation here?

I guess also a comment here this is noted in module Global_slot_since_hardfork.

glyh

LGTM overall.

src/lib/mina_lib/mina_lib.ml

glyh · 2025-10-29T03:13:45Z

src/lib/mina_lib/mina_lib.ml

-    ; block_timestamp : Block_time.t
    }

+  (** The genesis state timestamp string is the timestamp of the start of the


Suggest:
Replace

the timestamp of the start of the [global_slot] of the hard fork

with

the timestamp of the start of the epoch of the [global_slot]

I don't think anything implementation-wise here is related to HF, although it's probably used in that context.

Also I'd suggest rename the input from global_slot -> global_slot_since_hard_fork just so I don't need to look at type annotations.

It is actually the start of the slot itself, not the epoch or anything like that. I think a "slot" is technically the entire 3 minute time interval. A lot of the code only deals with the start of it, though; the block producer always schedules blocks to be produced at the start of the slot, and sets the block timestamp equal to the start of the slot too.

glyh · 2025-10-29T03:16:57Z

src/lib/mina_lib/mina_lib.ml

+  let global_slot_since_hard_fork_to_genesis
+      ~(constraint_constants : Genesis_constants.Constraint_constants.t)
+      global_slot =
+    (* Convert the global slot to a span of slots since the current hard fork *)
+    let global_slot_span =
+      global_slot |> Mina_numbers.Global_slot_since_hard_fork.to_uint32
+      |> Mina_numbers.Global_slot_span.of_uint32
+    in
+    (* Retrieve the global slot since genesis of the genesis of the current
+       chain *)
+    let current_genesis_global_slot =
+      constraint_constants.fork
+      |> Option.value_map ~default:Mina_numbers.Global_slot_since_genesis.zero
+           ~f:(fun fork -> fork.global_slot_since_genesis)
+    in
+    (* Add the slot span to the current chain's genesis slot to get the desired quantity *)
+    Mina_numbers.Global_slot_since_genesis.add current_genesis_global_slot
+      global_slot_span


I'm suprised there's no such helpers elsewhere.

glyh · 2025-10-29T03:20:49Z

src/lib/mina_lib/mina_lib.ml

+  let global_slot_since_hard_fork_to_genesis
+      ~(constraint_constants : Genesis_constants.Constraint_constants.t)
+      global_slot =
+    (* Convert the global slot to a span of slots since the current hard fork *)
+    let global_slot_span =
+      global_slot |> Mina_numbers.Global_slot_since_hard_fork.to_uint32
+      |> Mina_numbers.Global_slot_span.of_uint32
+    in
+    (* Retrieve the global slot since genesis of the genesis of the current
+       chain *)
+    let current_genesis_global_slot =
+      constraint_constants.fork
+      |> Option.value_map ~default:Mina_numbers.Global_slot_since_genesis.zero
+           ~f:(fun fork -> fork.global_slot_since_genesis)
+    in
+    (* Add the slot span to the current chain's genesis slot to get the desired quantity *)
+    Mina_numbers.Global_slot_since_genesis.add current_genesis_global_slot
+      global_slot_span


Was going to suggest we put this into module Global_slot_since_hardfork. But there could be some circular dependency issue(or maybe not?).

Could we put a comment in that module indicating there's a conversion implementation here?

I guess also a comment here this is noted in module Global_slot_since_hardfork.

glyh · 2025-10-29T03:28:38Z

src/lib/mina_lib/mina_lib.ml

    let global_slot_since_genesis =
-      Mina_block.consensus_state block
-      |> Consensus.Data.Consensus_state.global_slot_since_genesis
+      global_slot_since_hard_fork_to_genesis


It's a bit weird here. In consensus state we're tracking slot both since genesis and since hard fork. I wonder why.

Is this just a misdesign, or on purpose?

That would affect our attitude on the helper doing conversion of slot since hf -> slot since genesis.

The Global_slot_since_genesis name is maybe a bit misleading. It's supposed to track the slot number starting from the genesis of the very first chain (the one before Berkeley), and it's always supposed to go up, never down. The Global_slot_since_hard_fork gets reset whenever there's a hard fork.

That's my understanding, anyway.

So the proof.fork.global_slot_since_genesis in the daemon.json lets you know that the new chain is starting at that particular "absolute" slot.

That's why I think the equality

global_slot_since_genesis = global_slot_since_hard_fork + proof.fork.global_slot_since_genesis

is justified.

glyh · 2025-10-29T03:28:59Z

src/lib/mina_lib/mina_lib.mli

 val best_chain_block_by_state_hash :
  t -> State_hash.t -> Transition_frontier.Breadcrumb.t Or_error.t

-val best_chain_block_before_stop_slot :


glyh · 2025-10-29T03:30:21Z

src/lib/runtime_config/runtime_config.ml

+let hard_fork_genesis_slot_delta t =
+  let open Option.Let_syntax in
+  let%bind daemon = t.daemon in
+  let%map delta = daemon.hard_fork_genesis_slot_delta in


I was going to suggest we change t.daemon.hard_fork_genesis_slot_delta type to be Global_slot_span.t so this conversion is not needed every time we need this value.

However it seems there's some obscure json conversion there. I guess we can add a note there for follow-up if there's ever going to be refactor around there.

We could probably add the stop slots and genesis delta to the main Mina_lib.Config as well (except as their real types). Then the daemon could just parse them once at startup and store those values.

Yes, but it's nit and requires quite a bit of refactoring, so just some idea for later.

cjjdespres · 2025-10-30T19:23:22Z

!ci-build-me

cjjdespres · 2025-10-31T17:12:25Z

!ci-build-me

cjjdespres · 2025-10-31T17:17:49Z

The commit 3a5ed3a I pushed calculates the hard fork global slot since genesis a little differently. It does exactly what Consensus_state.update does when it updates the global slot since hard fork and global slot since genesis:

mina/src/lib/consensus/proof_of_stake.ml

Line 1851 in e8e5f9e

let update ~(constants : Constants.t)

Basically the method calculates the right global slot since genesis by pretending that we transitioned from the hard fork block's slot to the scheduled genesis slot.

I think the other way was also probably fine, but this is more obviously correct in my opinion.

glyh · 2025-11-04T00:04:11Z

Oh, I think I've checked again and forgot to comment this lgtm after the follow up commits, sorry

cjjdespres requested a review from a team as a code owner October 29, 2025 01:06

cjjdespres commented Oct 29, 2025

View reviewed changes

glyh approved these changes Oct 29, 2025

View reviewed changes

Clarify docs for scheduled hard fork genesis slot

c1419ed

Simulate consensus update for genesis global slot

3a5ed3a

cjjdespres merged commit b973ce9 into compatible Nov 3, 2025
66 checks passed

cjjdespres deleted the cjjdespres/set-auto-hard-fork-genesis-correctly branch November 3, 2025 17:37

Set hard fork config slot and timestamp properly #18028

Set hard fork config slot and timestamp properly #18028

Uh oh!

Conversation

cjjdespres commented Oct 29, 2025

Uh oh!

cjjdespres commented Oct 29, 2025

Uh oh!

cjjdespres commented Oct 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

glyh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cjjdespres commented Oct 30, 2025

Uh oh!

cjjdespres commented Oct 31, 2025

Uh oh!

cjjdespres commented Oct 31, 2025

Uh oh!

Uh oh!

glyh commented Nov 4, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants