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

[compatible] Stop txn/network after slot feature #14516

Merged
merged 39 commits into from
Jan 31, 2024

Conversation

joaosreis
Copy link
Member

@joaosreis joaosreis commented Nov 5, 2023

TL;DR implements RFC #14138

This PR introduces two new optional compile-time configuration parameters, slot_tx_end and slot_chain_end. These define, respectively, the slot at which the node will stop producing/validating non-empty blocks (defined as being blocks that produce an empty staged ledger diff), and the slop at which the node stops producing/accepting any blocks at all. This is a feature part of the hard-fork mechanism.

Summary of changes:

  • Add optional slot-tx-end parameter to CLI.
  • BP always uses an empty set of transactions to produce blocks after the slot-tx-end slot instead of fetching them from the transaction pool.
  • The RPC function for sending user commands rejects commands after the slot-tx-end slot.
  • The node doesn't try to add incoming transactions to the network pool after the slot-tx-end slot.
  • The transaction pool drops all transactions when the slot-tx-end slot is reached.

Some unit tests (specifically, for the transaction pool) were added. The complete set of expected behaviors was demonstrated in a sandbox network.

Merge PRs to other branches:

@joaosreis joaosreis force-pushed the joaosreis/hf-stop-txn-after-slot-compatible branch from e54c02f to f096e48 Compare November 5, 2023 22:21
@joaosreis joaosreis changed the title Stop txn/network after slot feature [compatible] [compatible] Stop txn/network after slot feature Dec 20, 2023
@joaosreis joaosreis force-pushed the joaosreis/hf-stop-txn-after-slot-compatible branch from d98b47f to 5ac8a89 Compare December 20, 2023 09:54
@joaosreis joaosreis force-pushed the joaosreis/hf-stop-txn-after-slot-compatible branch from 5ac8a89 to da70971 Compare December 20, 2023 10:09
@joaosreis joaosreis self-assigned this Dec 21, 2023
@joaosreis
Copy link
Member Author

!ci-nightly-me

@georgeee
Copy link
Member

There will be a configuration parameter set at compile-time that will define the slot at which the node will stop processing transactions.
The previous configuration cannot be overridable at runtime, by design, as this compromises the safety of the daemon software.

Does this excerpt from RFC mean that there should be no option to set the two parameters via CLI flag?

CC @mrmr1993 @nholland94

@nholland94
Copy link
Member

@georgeee Yes, there should not be a CLI flag. We did align in the RFC discussion to allow a runtime configuration override for integration testing purposes, which can be left undocumented.

@joaosreis joaosreis added the P0 Urgent label Jan 18, 2024
ok_if_true msg
( Mina_numbers.Global_slot.(
of_uint32 block.slot_since_genesis < slot_tx_end)
|| block.command_transaction_count = 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: I'd put conjunction group into braces for clarity (not necessary, but required me to remember operator precedence to be sure it works)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I certainly agree. It just turns out the formatter doesn't let me keep them :)

src/lib/network_pool/indexed_pool.ml Outdated Show resolved Hide resolved
match Map.find t.all_by_sender fee_payer with
| None ->
(* nothing queued for this sender *)
match slot_tx_end with
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest to flatten this code a little bit.

Something like the following would fit nicely:

let%bind () = 
Result.ok_if_true ~error:After_slot_tx_end @@
Option.value_map ~f:Global_slot.(fun slot_tx_end' ->
current_global_slot >= slot_tx_end') ~default:true slot_tx_end in

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO for George: re-review the code of the function after flattening (now changes are inflated by increase of layerness)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good suggestion. In this case, the slot comparison condition needs to be inverted. Before it was the condition where it would fail, now it should be the condition where it should proceed.

(of_time_exn ~constants:consensus_constants
(Block_time.now time_controller) ))
in
match slot_tx_end with
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please flatten this code as suggested above

end

module Rejected = struct
[%%versioned
module Stable = struct
[@@@no_toplevel_latest_type]

module V2 = struct
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for future: discuss on how this affects berkeley versioning types (whould we bump some types' versions there too?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the first time I'm updating versioned types, so I'm unsure on how this would affect
berkeley types.
Regardless, this PR has merge conflicts with berkeley and develop, so we need to merge this feature into there as well. We can then upgrade these types there. Does this solve the issue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for sure. This is the way to proceed. My main point was that if we add a new numbered type here (V2) which existed in different form in berkeley, we probably should make sure to use V3 in berkeley. I.e. if types between compatible and berkeley differ, berkeley should be +1 from compatible. That said, if you will find an existing V3 in berkeley for a type that is V2 in compatible, it's safe to change this type right away without introducing a new number.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

berkeley and develop are expected to have the same types, so once you remake this change against berkeley, there should be no problem with preparing a PR against develop.

assert_pool_txs independent_cmds' ;
Deferred.unit )

let%test_unit "transactions added after slot_tx_end are rejected" =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
let%test_unit "transactions added after slot_tx_end are rejected" =
let%test_unit "transactions added at slot_tx_end are rejected" =

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add a test case for "after"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It surely doesn't hurt.

@joaosreis
Copy link
Member Author

@georgeee please give a look at the changes I just pushed.

@joaosreis
Copy link
Member Author

!ci-build-me

@georgeee
Copy link
Member

!ci-build-me

@joaosreis
Copy link
Member Author

!ci-build-me

@georgeee georgeee dismissed nholland94’s stale review January 31, 2024 19:52

Nathan delegated this PR to me

@georgeee georgeee merged commit 46a00e9 into compatible Jan 31, 2024
16 checks passed
@georgeee georgeee deleted the joaosreis/hf-stop-txn-after-slot-compatible branch January 31, 2024 19:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants