You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As with the current proposed change 31872905167c5205f92a670af6a5b2f2ae1e1626, a buffer should be introduced only for the upper bound. If introduced for the lower bound, timestamps cannot be guaranteed to monotonically increase.
My slight concern is, if the buffer for the upper bound is too large compared to the block period, it might damage the soundness of the election:
As an extreme example, suppose that a leader with an outstandingly advanced system time created a block in the previous round, and most validators barely approved the block thanks to the large buffer. In this case, other leaders in the current round might not be able to create timestamps that meet the lower bound, which means view changes will be repeated until the same amount of time as the buffer has elapsed or the same leader as in the previous round is elected
My slight concern is, if the buffer for the upper bound is too large compared to the block period, it might damage the soundness of the election:
As an extreme example, suppose that a leader with an outstandingly advanced system time created a block in the previous round, and most validators barely approved the block thanks to the large buffer. In this case, other leaders in the current round might not be able to create timestamps that meet the lower bound, which means view changes will be repeated until the same amount of time as the buffer has elapsed or the same leader as in the previous round is elected
Originally posted by @s8sato in #4928 (comment)
The text was updated successfully, but these errors were encountered: