A timer-based anti-deadlock proposal for de-MLS

Logos
1

Hey, here is a proposal for addressing the deadlock risk in de-MLS.

Problem:
In the current design of de-MLS, we originally had a single epoch steward responsible for committing. With the updated design, other stewards can also commit, which already reduces the deadlock risk but doesn’t fully eliminate it. The issue appears when no one commits for a long time, even if all stewards have the right to commit. This is especially problematic in small consensus type groups, where group changes can remain frozen for extended periods.
So we need a mechanism to prevent deadlock under the assumption that we have at least 2n/3 active and online members for finalizing consensus.

Proposal: timer-based anti-deadlock proposal

  • Every member maintains a local timer.
  • A threshold duration is defined in the config file.
  • The timer for each member resets whenever a commit is successfully observed.
  • If the threshold time is exceeded, a high-priority emergency proposal is triggered after t buffer seconds to ensure other parties can get the same result
  • If the deadlock is real, we expect at least 2n/3 members to get the same result and emergency proposal returns YES, which allows any member to commit (even if not a steward) and restore liveness.

notes:

Since we are in the p2p settings, delays are common, so each timer can reset to different real times. This reality should not be a blocker in this proposal since the timer alert member should wait for t more seconds.

Another point is that after every member can commit, the peers can get a high volume of repeated commits. For this, we suggest filtering commit section

Emergency proposals that result in NO must incur a peer-score penalty. Even if the timer is alerted with a valid network issue for a specific member, the proposal is returned NO, and the member gets a low peer score. For this scenario, we may consider using a custom fast and light sync mechanism to ask other members whether to get the commit message or not. Otherwise, malicious actors could abuse emergency commits.

All thoughts and questions are welcome.