ssvlabs / ssv-spec

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Remove future msg handling

alonmuroch opened this issue · comments

Post merge of ssvlabs/SIPs#28 we do not need to handle future messages anymore.
Remove:

  • future message container
  • future_msg.go
  • if c.isFutureMessage(msg) from processMessage
  • c.UponFutureMsg

should we remove it?
A future msg maybe can happen if let say I didn't receive a duty yet from my unsynced or latent beacon node?

Maybe a future decided msg should stop older instances

Future message was to prevent a case in which a node is stuck on some old height (pre SIP10) and doesn't know it.
If it received f+1 future messages it will try to sync to the highest height.

Now with SIP10, it doesn't really need it.
Even if it got stuck, the next duty it can still start...

We used to have an open question whether future decided should stop an instance.
The answer should be no. Only the duty scheduler does this.

Regarding the case where a message is wrongly considered a future message due to eth2 syncing, from the spec PoV it is still a future message and the user has to ensure the beacon node is synced. Impl can decide differently.

Regarding the casewhere a message is wrongly considered a future message due to missing pre-con messages, #186 should take care of that.

FYI, @moshe-blox and @y0sher