Deriving a reliable multisig account address before its creation

[yeptos]

Currently the 0x1::multisig_account::create function generates a multisig account at an address derived from (i) the bootstrapper's address and (ii) the bootstrapper's account sequence_number. This creates a problem: it is unsafe to rely on the predicted address before the multisig account is created, because the derived address will change once the bootstrapper sends any other transaction, incrementing their sequence_number. This can easily happen by mistake, and once the sequence_number is incremented, there is no way to create a multisig account at the address derived from the previous sequence_number. This poses a risk of losing funds if users send funds to the predicted (but uncreated) multisig address.

To resolve this, there should be a more reliable mechanism for generating a deterministic multisig account address. Specifically the address derivation shouldn't rely on the boostrapper's sequence_number. This could be achieved by a function that can derive the address either from the bootstrapper's address alone, or from a combination of the bootstrapper's address and a user-defined nonce, similar to how resource accounts or objects are created. This will ensure that the multisig account address remains predictable regardless of the bootstrapper's transaction history or the order of transactions.

Possible solutions:

1. Framework to provide an alternative function that creates a multisig account at the address is solely derived from boostrapper address (with an optional seed value passed by caller).
2. User to create a resource account (whose address is deterministic) as a bootstrapper then use the boostrapper to create a multisig account. This reduces chance of mistakenly incrementing a sequence number.
3. Build a permissionless, ownerless module that does 2.

[heliuchuan]

Out of curiosity, in what way might MultiKey not fulfill your use case such that you'd want to opt for MultiSig?

[yeptos]

Hi @heliuchuan, we've explored MultiKey extensively before looking into multisig v2, but we encountered a few practical challenges that led us to opt for a multisig v2 instead. Note that these challenges may be specific to our use case, where we wanted to enable multiple authentication modes for end users, leveraging 1-of-n multisig scheme. I believe MultiKey would work well in more standard scenarios where multiple people are managing a shared account.

A. Firstly, there's an issue with ensuring the consistency of the auth key we construct, which is tied to the nature of the authentication key itself being a cryptographic hash string, essentially pseudorandom bytes. This felt a little precarious, as the slightest error as something like missing a single end byte could potentially result in losing account access. This might be a psychological concern but something we couldn't ignore.

In contrast, the onchain multisig has well defined constraints and invariants for every action, which is enforced by Move which can also be easily verified. This also gives us confidence as it gives us straightforward guarantees about what can happen and what cannot ("this can't go wrong here"). For instance, when we call 0x1::multisig_account::add_owner, we know with certainty that this won't affect the other existing owners' ability to control the multisig account, whereas if you mishandle an auth key and rotate, you might just lose your account. This just feels very different - I feel that one is really in the realm of "engineering" while the other is maybe not

B. Moreover, since in our case the MultiKey auth key would have to be constructed on the frontend (the end user's device), providing a guarantee that certain information about the MultiKey auth key - all of its public keys, their respective auth schemes and the order of the keys .. MUST be preserved somewhere (before making the first tx after key rotation) was another problem we had to solve. I've recently posted a public discussion thread on this #388, as well as offline chats with Greg and Aaron.

C. Finally, another consideration is that a multisig v2 account can still have Ed25519 auth key which is supported by all wallet softwares (Petra etc) while I don't think these wallets will support MultiKey any time soon. Even if they did, I'd be worried if the implementations are all correct. This was also important because we wanted users to be able to use say Petra wallet if they want to, while being able to control their account with Keyless or else with multisig v2.

To me the cryptography itself and the fact that this is even possible feels magical. But from an engineer's pov i guess it gets scary when there's not enough level of confidence which we would have if there's a few more guarantees. I really hope this feedback is helpful to the team!