Multiple signature standard
Posted: Fri Nov 29, 2024 3:32 pm
It's a huge pain to ask users for many signatures if we want them to agree to multiple things.
I hope most of the things will be possible to be done with intents someday, not making the user go through the pain of managing transactions for their own account in their own wallet – it's a pain to make sure nothing reverts, you have enough gas token (or to bridge the native token to the used network), gas estimation, nonce management, etc. The user should just tell the app what to do for casual operations.
In some situations the user may be performing several actions at once (for example if they want to sign multiple permits for a settler contract to take funds from their account and swap them into a token their swap intent determined). We should have a way for the user to make just one signature (one decision, one click) while seeing all the actions (or just types of actions if there are a lot of actions and the user should be fine knowing only the type) the user is asked to make by the app.
One solution is embedding this logic in the wallet and standardize asking for multiple signatures. The wallet can just sign multiple things. But it seems wallets are not eager to implement this. Also, the endgame will be the most efficient solution – and verifying multiple signatures is rather expensive.
A solution I think could work is to sign a merkle root hash of all signed messages, and then have a contract (single deployment per network) to which the intent filler would send the signature as the first step when filling intents, the contract verifies the signature and with the right merkle node hashes, we can provide proof of all or a subset of the messages signed, to be included in the main signature. Then these hashes are saved in transient storage. The domain separator logic can also be optionally outsourced to be verified within that contract, and then the transient storage mapping from message hashes to whether they're signed would have more dimensions.
Integrating contracts, instead of using ecrecover, could just ask that infrastructure contract if the message from a user is denoted as signed in the transient storage. The per-intent cost of that is really low.
Am I re-inventing the wheel? Is there any EIP that is trying to standardize multi-signatures? Should I be aware of any existing solution? Do you agree with the solution suggested? Would you suggest any features to the proposed infrastructure contract?
I hope most of the things will be possible to be done with intents someday, not making the user go through the pain of managing transactions for their own account in their own wallet – it's a pain to make sure nothing reverts, you have enough gas token (or to bridge the native token to the used network), gas estimation, nonce management, etc. The user should just tell the app what to do for casual operations.
In some situations the user may be performing several actions at once (for example if they want to sign multiple permits for a settler contract to take funds from their account and swap them into a token their swap intent determined). We should have a way for the user to make just one signature (one decision, one click) while seeing all the actions (or just types of actions if there are a lot of actions and the user should be fine knowing only the type) the user is asked to make by the app.
One solution is embedding this logic in the wallet and standardize asking for multiple signatures. The wallet can just sign multiple things. But it seems wallets are not eager to implement this. Also, the endgame will be the most efficient solution – and verifying multiple signatures is rather expensive.
A solution I think could work is to sign a merkle root hash of all signed messages, and then have a contract (single deployment per network) to which the intent filler would send the signature as the first step when filling intents, the contract verifies the signature and with the right merkle node hashes, we can provide proof of all or a subset of the messages signed, to be included in the main signature. Then these hashes are saved in transient storage. The domain separator logic can also be optionally outsourced to be verified within that contract, and then the transient storage mapping from message hashes to whether they're signed would have more dimensions.
Integrating contracts, instead of using ecrecover, could just ask that infrastructure contract if the message from a user is denoted as signed in the transient storage. The per-intent cost of that is really low.
Am I re-inventing the wheel? Is there any EIP that is trying to standardize multi-signatures? Should I be aware of any existing solution? Do you agree with the solution suggested? Would you suggest any features to the proposed infrastructure contract?