Discussion
Epoch Steward and DoS Concerns
Q: Does the role of the epoch steward create denial-of-service risks similar to block proposers?
A: The steward role is different because it operates within a group, and only members with the group key can see proposals. This makes DoS less of a concern than in open, permissionless networks. For very large groups (e.g., 50k members), attacks become more plausible, and privacy-preserving methods like secret elections may be needed. However, heavy methods can reduce efficiency, so the focus is on lightweight solutions. Backup stewards are also seen as an important safeguard in case the active steward becomes inactive, censored, or attacked.
Consensus Approaches and Efficiency
Q: What consensus mechanisms are suitable while keeping MLS efficient?
A: Several were discussed. Event-based consensus avoids strict time dependencies. Gossip-based “virtual voting” spreads proposals quickly and scales close to log-n efficiency. Avalanche-style protocols can be leaderless or leader-based and provide efficient, lightweight global consensus. The overall direction favors lightweight, leaderless consensus, since heavy PBFT-like approaches would harm efficiency. Open questions remain around message ordering in decentralized settings, with hashgraph-style methods mentioned as possible solutions.
Proposal Aggregation in de-MLS
Q: How are proposals aggregated, and are there limits?
A: Multiple voting proposals in the same epoch must be combined into a single commit, since each commit finalizes an epoch. However, not all proposals can be bundled together. For example, “remove” and “join” proposals may be grouped separately. Experiments show bundling is limited because commit messages depend on user key material, which creates conflicts when incompatible proposals are combined.
Voting Rules and Supermajority
Q: How are voting rules defined, and why is a two-thirds majority required?
A: The RFC is consensus-agnostic, allowing flexibility as long as finalization happens within the epoch. The two-thirds rule comes from hashgraph: it allows the system to tolerate up to one-third malicious participants. Because votes are tied to cryptographic hashes, conflicting votes (e.g., a peer voting both “yes” and “no”) can be detected and removed, keeping results consistent.
Safeguards Around Key Packages
Q: What protections exist against misuse of key packages?
A: Key packages are signed and expected to have short expiration times, making replay attacks difficult. Linking key packages more closely to account-based signatures (such as wallets) is seen as a future improvement. A potential risk is stewards reusing old key packages to impersonate users. Federated systems mitigate this with authentication services, but if those are compromised, the safeguard weakens. Enforcing freshness and short lifetimes for key packages helps prevent misuse.
Storage Considerations
Q: How is storage handled for proposals and key packages?
A: Local storage can handle users who go offline temporarily, but unlimited recovery isn’t practical in peer-to-peer systems. Decentralized options like IPFS or Codex could provide longer-term encrypted storage. The suggestion was made to define storage interfaces in RFCs abstractly, leaving specific implementations (local vs. decentralized) to downstream specs like chat SDKs, so different systems can choose what fits best.