[feature] change multi-sig n-of-m requirements for community wallets
Closed this issue · 1 comments
Is your feature request related to a problem? Please describe.
The current multi-sig setup of 3/5 (n of m) may be limiting due to the requirement for signers from different ancestral lineages. This constraint could potentially hinder the efficient and flexible operation of community wallets, especially in situations where quick decisions or actions are necessary.
Describe the solution you'd like
I propose two potential solutions to address this issue:
- Decrease the multi-sig participants from 3/5 to 2/3 to streamline decision-making processes and enhance operational efficiency.
- Utilize the first children of the root ancestry trees to potentially double the number of options for community wallets to use as signers. This approach would expand the pool of eligible signers while adhering to the diversity requirement of different ancestral lineages.
Describe alternatives you've considered
Another alternative could be to implement a dynamic multi-sig requirement that adjusts based on the context of the transaction or decision being made. For example, less critical actions could require a simpler 2/3 sign-off, while more significant decisions could maintain the current 3/5 structure.
Additional context
This task is ideal for someone looking to get involved with the codebase and contribute to the project. It's a great opportunity to hack away at a task that could significantly impact the flexibility and efficiency of our community wallet operations. Open to other ideas and suggestions to improve our multi-sig approach.
The relevant code logic for the multi-sig configuration can be found in the community_wallet.move file within the 0L Network Community's Libra framework repository:
Helpful modules for understanding the ancestral lineage and multi-action voting mechanism include:
NOTE: Concerns Around Decreasing Sybil Resistance
Decreasing the multi-sig requirement raises valid concerns regarding sybil resistance. To mitigate potential risks, any changes to the multi-sig configuration should be treated as a "sacred cow," a parameter fundamental to the principles of the community that should be exceedingly difficult to alter. This approach ensures that any modifications to critical parameters, including those related to sybil resistance, undergo rigorous scrutiny and consensus. The sacred cow mechanism is detailed in the sacred cows file.
TL;DR for Sacred Cow:
Parameters that are core to the community's principles should be challenging to change, even if technically they might be a simple one-liner in code or a single transaction. These parameters should be regarded as "sacred cows," necessitating a major effort for any modification to ensure the community's foundational values are preserved.
Resolved. Added in release 6.9.6