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
Right now, the finality certificate exchange tries to predict the interval at which GPBFT will make decisions. It then polls peers for certificates whenever it doesn't receive a decision before the predicted interval elapses.
Unfortunately, this means we often end up aligning our predicted interval exactly with the decision interval, polling for certificates even when we won't need them (are about to receive a decision). Instead:
If we aren't following along with GPBFT, we should maintain the current behavior.
If we expect to receive a decision from GPBFT directly, we should delay until twice our predicted interval before polling. Afterwards, we should poll once per predicted interval until we start receiving certificates from GPBFT again.
Motivation: Reduce bandwidth/CPU usage. At the moment, this likely isn't a huge issue because GPBFT itself is much more bandwidth intensive than the certificate exchange protocol. But it's something we should look into eventually.
The text was updated successfully, but these errors were encountered:
Right now, the finality certificate exchange tries to predict the interval at which GPBFT will make decisions. It then polls peers for certificates whenever it doesn't receive a decision before the predicted interval elapses.
Unfortunately, this means we often end up aligning our predicted interval exactly with the decision interval, polling for certificates even when we won't need them (are about to receive a decision). Instead:
Motivation: Reduce bandwidth/CPU usage. At the moment, this likely isn't a huge issue because GPBFT itself is much more bandwidth intensive than the certificate exchange protocol. But it's something we should look into eventually.
The text was updated successfully, but these errors were encountered: