Skip to content

Native: move MillisecondsPerBlock setting to native Policy#3895

Merged
NGDAdmin merged 8 commits intomasterfrom
policy-blocktime
Apr 16, 2025
Merged

Native: move MillisecondsPerBlock setting to native Policy#3895
NGDAdmin merged 8 commits intomasterfrom
policy-blocktime

Conversation

@AnnaShaleva
Copy link
Member

Description

Move MillisecondsPerBlock protocol configuration setting to native Policy contract.

Type of change

  • New feature (non-breaking change which adds functionality)

How Has This Been Tested?

  • Check_SetMSPerBlock unit-test

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
@AnnaShaleva
Copy link
Member Author

@shargon, your latest reviewcomments from #3622 are fixed/answered. Please, review one more time and raise conversations in this PR if something is not correct.

cschuchardt88
cschuchardt88 previously approved these changes Apr 11, 2025
@AnnaShaleva AnnaShaleva requested a review from shargon April 11, 2025 19:18
Jim8y
Jim8y previously approved these changes Apr 12, 2025
/// <param name="snapshot">The snapshot used to read data.</param>
/// <returns>The block generation time in milliseconds.</returns>
[ContractMethod(Hardfork.HF_Echidna, CpuFee = 1 << 15, RequiredCallFlags = CallFlags.ReadStates)]
public uint GetMSPerBlock(IReadOnlyStore snapshot)
Copy link
Contributor

Choose a reason for hiding this comment

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

GetMillisecondsPerBlock and SetMillisecondsPerBlock are better.
Abbreviation is not good idea.

Copy link
Member

Choose a reason for hiding this comment

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

Or getTimePerBlock

Copy link
Member

Choose a reason for hiding this comment

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

agreed

Copy link
Member Author

@AnnaShaleva AnnaShaleva Apr 14, 2025

Choose a reason for hiding this comment

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

Or getTimePerBlock

The problem with getTimePerBlock is that it returns an integer and this integer is not the number of seconds (which is a default unit when we're talking about the time). So it's not clear to the end user what is the unit of the time.

That's why we changed it from GetTimePerBlock to GetMSPerBlock in nspcc-dev/neo-go#3835 (comment).

GetMillisecondsPerBlock and SetMillisecondsPerBlock are better.

From the code prospective I agree, but it's the native contract method, and originally I picked shorter name because it will cost less GAS to invoke GetMSPerBlock (just shorter transaction script).

So given these arguments, do you still want to change this name?

Copy link
Member Author

Choose a reason for hiding this comment

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

OK, there's not a large diff in GAS price, let's use GetMillisecondsPerBlock and SetMillisecondsPerBlock.

@Jim8y Jim8y requested a review from shargon April 12, 2025 11:26
/// <summary>
/// The event name for the block generation time changed.
/// </summary>
private const string MSPerBlockChangedEventName = "MSPerBlockChanged";
Copy link
Member

Choose a reason for hiding this comment

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

Also change here, "TimePerBlockChanged" or even better "ConsensusTimePerBlockChanged"

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 name must be kept in accordance with the getter/setter name, so we firstly need to agree on #3895 (comment).

{
TimeSpan nextDelay = expected_delay - (TimeProvider.Current.UtcNow - clock_started)
+ TimeSpan.FromMilliseconds(maxDelayInBlockTimes * neoSystem.Settings.MillisecondsPerBlock / (double)context.M);
+ TimeSpan.FromMilliseconds(maxDelayInBlockTimes * context.TimePerBlock.TotalMilliseconds / (double)context.M);
Copy link
Member

@vncoelho vncoelho Apr 12, 2025

Choose a reason for hiding this comment

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

Later we need to improve this formula as @superboyiii said.

This requires larger extend by factor when block times are slower because the NETWORK P2P delay did not change (it is the same for both cases).
Here we have a parameter that was initially set based on the network delay, that was calibrated for 15s block.

Let's keep this in mind @shargon @AnnaShaleva @Jim8y @roman-khimov

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's a separate issue that needs careful evaluation, so it won't be done in the current PR.

Copy link
Member

@vncoelho vncoelho left a comment

Choose a reason for hiding this comment

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

looks all good! Just some minor changes and ready to go

@Jim8y Jim8y requested review from Wi1l-B0t and vncoelho April 12, 2025 13:41
@Jim8y Jim8y added the Critical Issues (bugs) that need to be fixed ASAP label Apr 12, 2025
@vncoelho
Copy link
Member

@Jim8y pay attention to my previous comments, I have just reviewed O.o

@shargon
Copy link
Member

shargon commented Apr 13, 2025

#3895 (comment) please check it

No functional changes, fix
#3895 (comment).

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
@AnnaShaleva AnnaShaleva dismissed stale reviews from cschuchardt88 and Jim8y via 8e5e213 April 14, 2025 10:35
@AnnaShaleva
Copy link
Member Author

@shargon, @vncoelho @Wi1l-B0t please, check conversations and review one more time.

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
@vncoelho
Copy link
Member

@AnnaShaleva good that you fixed RPC, nice catch @shargon

I think it is ready

@Wi1l-B0t
Copy link
Contributor

LGTM

@NGDAdmin NGDAdmin merged commit 66717c9 into master Apr 16, 2025
7 checks passed
@NGDAdmin NGDAdmin deleted the policy-blocktime branch April 16, 2025 03:08
Jim8y added a commit to Jim8y/neo that referenced this pull request Apr 17, 2025
* master:
  DBFTPlugin: include consensus time into block interval (neo-project#3900)
  Isolate unit tests (neo-project#3904)
  Use DateTime.UtcNow (neo-project#3902)
  Update workflow (neo-project#3901)
  optimize: show state more readable (neo-project#3899)
  Optimize KeyedCollectionSlim (neo-project#3877)
  Native: move MillisecondsPerBlock setting to native Policy (neo-project#3895)
  optimize: history command support (neo-project#3892)
  Ensure that view interops can't be changed outside (neo-project#3812)
cschuchardt88 added a commit to cschuchardt88/neo that referenced this pull request Jun 8, 2025
…ct#3895)

* docs: add missing hardforks to the node configuration doc

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>

* Native: move MillisecondsPerBlock setting to native Policy

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>

* Native: rename [get,set]MSPerBlock to [get,set]MillisecondsPerBlock

No functional changes, fix
neo-project#3895 (comment).

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>

* RpcServer: include dynamic block time into getversion response

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>

---------

Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Co-authored-by: Jimmy <jinghui@wayne.edu>
Co-authored-by: Christopher Schuchardt <cschuchardt88@gmail.com>
Co-authored-by: NGD Admin <154295625+NGDAdmin@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Core Critical Issues (bugs) that need to be fixed ASAP Hardfork Ready to Merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants