Daily MOVE: Multi-signature V2 Enhancement

This AIP proposes to enhance Multi-Signature V2 in the following ways:

(1) Limit the maximum number of pending transactions.

(2) Introduction of batch operation function.

(3) Implicitly voting on transaction execution.

Macro overview

This AIP proposal adds enhancements to multi-signature V2 through the following features:

1. Limit the maximum number of pending transactions. This is achieved by introducing a parallel new constant MAX_PENDING_TRANSACTIONS in the MultiSign V2 Accounts module, which is set to 20. If the number of pending transactions exceeds this limit, the contract will not accept any new transaction proposals until the number of pending transactions drops below the limit. This is to prevent the pending transaction queue from being overloaded with too many pending transactions, thus effectively mitigating the risk of a denial of service attack (DoS) (as described in aptos-labs/aptos-core#8411).

2. Introduction of the batch operation feature. This feature allows multi-signature account owners to execute multiple actions in a single batch operation. This is done by introducing new public entry functions vote_transactions and execute_rejected_transactions in the MultiSign V2 Account module. This feature is suitable for atomically executing multiple transactions, which improves availability, reduces the number of transactions, saves Gas fees, and is effective against potential DoS attacks (as described in aptos-labs/aptos-core#8411).

3. Implicitly vote on transaction execution. This feature allows the owner of a multi-signature account to implicitly vote on transaction execution. Multi-signature transaction execution first implicitly approves the transaction, while execute_rejected_transaction first implicitly rejects the transaction. Implicit voting is not a new concept, as transactions are already implicitly voted on to approve when they are created. This modification reduces the number of transactions required in a multi-signature V2 user flow, which improves availability and saves Gas fees. This feature addresses the user experience issue described here: https://github.com/aptos-labs/aptos-core/issues/11011.

affect (usually adversely)

Multi-signature accounts cannot have more than 20 pending transactions, but this limit should be sufficient for most practical use cases. If some multi-signature accounts already have more than 20 pending transactions, they can still continue to vote and (decline to) execute transactions as before. However, they cannot have new transaction proposals unless the number of pending transactions drops below the limit.

The batch operations feature and the implicit voting feature are backward compatible with existing Multi-Signature V2 implementations. Existing Multi-Signature V2 users can continue to use their existing workflow. The new features are optional and will benefit users by simplifying the user process and saving Gas.

Specification and realization details

The specifications for limiting the maximum number of pending transactions are as follows:

ԷThe maximum number of pending transactions is limited to 20 by introducing a new constant MAX_PENDING_TRANSACTIONS in the Multi-Signature Accounts module. if the number of pending transactions exceeds this limit, the contract will not accept any new transaction proposals until the number of pending transactions drops below the limit.

ԷIf some accounts already have more than 20 pending trades, they can still continue to vote and (decline to) execute trades as before. However, they cannot have new trade proposals unless the number of pending trades drops below the limit.

The newly introduced batch operation functionality in the Multi-Signature Accounts module is as follows:

Էpublic entry fun vote_transactions(owner: &signer, multisig_account:address, starting_sequence_number: u64, final_sequence_number: u64, approved: bool)

Here, the entry function allows the owner of multisig_account to approve (approved = true) or reject (approved = false) multiple transactions in the range starting_sequence_number to final_sequence_number.

Էpublic entry fun execute_rejected_transactions(owner: &signer, multisig_account: address, final_sequence_number: u64)

This entry function allows the owner of multisig_account to execute rejected transactions up to final_sequence_number.

The specification for implicitly voting on transactions is as follows:

ԷWhen an owner executes a multi-signature transaction, he/she will automatically implicitly indicate that he/she is in favor of the transaction. If the owner has previously voted against the transaction, his/her vote will be updated to favorable. If there has not been a previous vote in favor of this transaction, the implicit vote behavior will automatically change the vote to yes, and the corresponding VoteEvent event will be triggered.

ԷWhen the owner runs execute_rejected_transactions, it implicitly votes to reject the transaction. If the owner has already voted to approve the transaction, the vote is updated to reject the transaction. If there has not been an implicit vote for rejection, the implicit vote changes the vote to rejection, which issues the appropriate VoteEvent.

ԷAdded view function public fun can_execute(owner: address,multisig_account:address, sequence_number: u64): bool to check if the owner can execute the next transaction of multisig_account, taking into account implicit voting. account's next transaction, taking implicit voting into account.

ԷA view function public fun can_reject(owner: address,multisig_account:address, sequence_number: u64): bool is introduced, the purpose of which is to determine whether the owner has the permission to reject, in consideration of implicit voting, the multisig_account's next transaction.

reference implementation

Էaptos-labs/aptos-core#12241

Էaptos-labs/aptos-core#11941

beta (software)

The reference implementation includes unit tests covering end-to-end scenarios. These scenarios will be tested on devnet and testnet.

security consideration

This AIP addresses the security issues described in aptos-labs/aptos-core#8411.

Recommended deployment schedule

This feature will be part of the v1.11 release.

For more details, please refer to AIP-77 (https://github.com/ALCOVE-LAB/Aptos-Docs/blob/main/AIP/aip-77.md)

We have translated the Chinese version of the official English documentation for your reference.