Liveness of Mir Reconfiguration

[matejpavlovic]

Checklist

• This is not a new feature or an enhancement to the Filecoin protocol. If it is, please open an FIP issue.
• This is not a new feature request. If it is, please file a feature request instead.
• This is not brainstorming ideas. If you have an idea you'd like to discuss, please open a new discussion on the lotus forum and select the category as Ideas.
• I have a specific, actionable, and well motivated improvement to propose.

Lotus component

• lotus daemon - chain sync
• lotus miner - mining and block production
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt)
• lotus miner/market - storage deal
• lotus miner/market - retrieval deal
• lotus miner/market - data transfer
• lotus client
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Improvement Suggestion

There might be a little liveness issue with the current approach to Mir subnet reconfiguration... Under constant and high churn, the nodes might actually never see the same configuration. We only get liveness guarantees here under the assumption that eventually there will be a period of time without changes to the membership that is long enough for a quorum of correct nodes to observe the same configuration.
I think we need to come back to it and implement something more sophisticated to guarantee progress even under constant churn.

First appeared in this discussion.