Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Enhanced Multisig Pallet to System chains #74
base: main
Are you sure you want to change the base?
Add Enhanced Multisig Pallet to System chains #74
Changes from 10 commits
738ab02
d1a60e7
be71d1e
0511eb1
8e1fdb3
6df6b8b
0901367
4c8f8e0
e83f04c
7d89c18
f72feb1
6cd9f8e
4ab8d0f
0fa55ab
ff36f57
1e8cd39
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we really need this? looks like it is for refund deposit when the multisig is destroyed. the easy solution is to refund it to the signer that triggers the removal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoever created the multisig might be not in the signers list and even if they're one of the signers, anyone from the signers can dispatch/cancel the final call. That's why it's better to return it to the original creator.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point of deposit is to create incentive for people to free up unused resources.
In this case, it is very possible that the creator is not the one with ability to remove the multisig. If the deposit is returned to the creator, it creates a misaligned incentive. Why should I as the current controller of the mulisig remove it to have the creator, which is someone else, to receive the deposit? There are zero incentives for the people with ability to free the resources. So it should be the one triggering the removal taking the deposit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it common practice though for someone to deposit and another to get their deposit back? I understand the incentive part but having someone else take my deposit if I created the account seems a bit unfair. Maybe have part of the deposit returned to the person executing the deletion process and another part to the original creator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the original creator have to explicitly transfer the ownership of the multisig so there is nothing unfair. the multisig itself must already worth something more than deposit so the value of deposit won’t change anything
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would also be great to see more realistic storage benchmark of both implementations of multisig pallet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That means I need to implement it and implement the benchmark and then compare them. I'll do this for sure if I got the green light to proceed with the RFC. As this is an RFC to illustrate the importance and the overall design I think this back of the envelop calculation should be enough unless you see something fundamentally wrong with my calculations. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be great addition to have a better functional comparison to the stateless pallet instead of a generic statement. Are there use cases where you believe stateless is better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question. I don't have any use case in my mind that the stateless is better TBH. Stateful can do all what the stateless do with added functionality, fine tuned control and clearer API. Do you have a case in mind?
I thought the RFC itself is an enough comparison to make it clear by reaching this point. Do you suggest explaining it again like in overview and motivation sections or add something else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does compatible mean here? Can existing stateless users migrate to stateful without losing the multisig address? How would the process look like?
Also, why (or why not) replace the existing pallet with stateful? Keeping two pallets with same functionality might add more confusion to the end users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compatible in this section means that it's not a breaking change and no other pallets will have issues if this is deployed.
It's possible in theory yes. I'd rather offload this to users though. Once the new pallet is ready they can create a new account and move fund if needed. The incentive is easier/extensible multisig account to deal with.
I agree. I think having the stateful will make it easier for users to use after knowing the enhanced functionalities and they'll start using the new one but maybe that's not enough. What do you suggest here? I think first get the sentiment about the stateful multisig, deploy and then we can later see the usage on-chain and decide to migrate and kill the older one or not.