-
Notifications
You must be signed in to change notification settings - Fork 535
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 💯
I've left some minor comments.
Thank you for leaving the chronological description of the changes in the PR, now people can follow along 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, apart from the reviews by Milos 👍
hi @dbrajovic @lazartravica, will this be added as a flag or something like --ibft-difficulty in |
The original idea was just conforming to the spec - no additional benefits other than that. If this gets released after the point the chain cannot be reset for you, we'll probably include a forks-in-time support |
Closing and archiving under |
Description
Originally starting as the idea in (now closed) PR#182, this PR is the third (and final) part of the series, addressing the block difficulty in IBFT. The first two being PR#201 and PR#208.
Essentially, it conforms to the standard described in the original IBFT consensus
Changes include
Breaking changes
The breaking change is introduced here.
A previously running node restarted with this build might still be able to produce blocks, but the danger of it failing to verify headers (during bulk sync) at some point is never absent.
Newly added nodes to the cluster will not be able to move past genesis and can never sync with the chain.
Checklist