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

Decrease block time threshold #1232

Closed
shargon opened this issue Nov 12, 2019 · 5 comments · Fixed by #1233
Closed

Decrease block time threshold #1232

shargon opened this issue Nov 12, 2019 · 5 comments · Fixed by #1233
Labels
discussion Initial issue state - proposed but not yet accepted

Comments

@shargon
Copy link
Member

shargon commented Nov 12, 2019

Summary
Currently the threshold for PrepareRequest is 10 minutes, if a malicious CN propuse a block that come from the near future (10 minutes more), it will be accepted. Next blocks will be proposed by the others trusted CN from the future too

Block.Timestamp = Math.Max(TimeProvider.Current.UtcNow.ToTimestampMS(), PrevHeader.Timestamp + 1);

So next round, this malicious CN could propose another block, and step by step move the chain to the future

For 7 CN this should be the scenario (CN1 malicious one):

First round:

  • CN-1 (Real Time 00:00:00 , BlockTime 00:10:00)
  • CN-2 (Real Time 00:00:15 , BlockTime 00:10:01)
  • CN-3 (Real Time 00:00:30 , BlockTime 00:10:02)
  • CN-4 (Real Time 00:00:45 , BlockTime 00:10:03)
  • CN-5 (Real Time 00:01:00 , BlockTime 00:10:04)
  • CN-6 (Real Time 00:01:15 , BlockTime 00:10:05)
  • CN-7 (Real Time 00:01:30 , BlockTime 00:10:06)

Second round

  • CN-1 (Real Time 00:01:45 , BlockTime 00:20:06)

Do you have any solution you want to propose?
Reduce the threshold to 1 or 2 minutes.

Where in the software does this update applies to?

  • Consensus
@shargon shargon added the discussion Initial issue state - proposed but not yet accepted label Nov 12, 2019
@shargon shargon added the bug Used to tag confirmed bugs label Nov 12, 2019
@shargon shargon changed the title Decrease the time threshold Decrease block time threshold Nov 12, 2019
@shargon
Copy link
Member Author

shargon commented Nov 12, 2019

Maybe the formula should be related to the number of verificators and the time per block, what do you think? @neo-project/core @neo-project/ngd-shanghai @erikzhang

@vncoelho
Copy link
Member

@shargon, for me this is expected. Not a bug.

If this happens, NEO holders should vote against.

@shargon
Copy link
Member Author

shargon commented Nov 12, 2019

A malicious CN can send the chain to 2020 in 2019, this is not expected.

If this happens, NEO holders should vote against.

Vote is not a solution, the protocol must protect the network if is possible.

@lock9
Copy link
Contributor

lock9 commented Nov 12, 2019

Isn't this one kind of metric that we can use to judge node health?
This can be one metric, and time that he was the speaker and did not submit a block on time can also be a metric. What do you guys think?

I agree that we should not let nodes create blocks too much in the future.

@shargon
Copy link
Member Author

shargon commented Nov 13, 2019

But what do you propose, watch and monitoring the CN in order to force a vote if this happens?

@shargon shargon removed the bug Used to tag confirmed bugs label Nov 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Initial issue state - proposed but not yet accepted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants