[Feature request] Make Simulation API easier to use when pubkeys for sender are not available and for crafting signature

[movekevin]

🐛 Feature request

Currently in order to successfully execute a simulation of a tx, user is required to provide:

1. A correct invalid signature to prevent replay. The signature needs to be valid to the point where it's deseriazable (so format has to be right) but it has to be the wrong signature.
2. A correct public key is provided that matches the sender account's auth key
3. A correct sequence number

This is fine if the use case is to simulate before sending the actual transaction with the same exact params. In many cases, a DApp just wants to run the simulation to understand the outcome or to test specific transactions for accounts that they don't have the public keys for.

Proposal

1. We somehow skip checking that the signature is deseriazable at all. It's the cleanest if users don't provide any signatures (valid or not) at all.
2. We relax the requirements for (2) and (3) or skip transaction prologue altogether. For specific checks such as account having enough to pay gas, this is already covered in tx epilogue.

[ghost]

I would like also require a batch transactions simulation.

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove the stale label or comment - otherwise this will be closed in 15 days.

[alnoki]

@davidiw Per our recent in-person discussion the current simulator design prohibits simulation of transactions from a multisig v2 account, which does not have a public key.

@movekevin the checks on account sequence number and gas are also problematic for multisig v2 accounts:

• The Account.sequence_number of a multisig v2 account should always be 0, since it is only the MultisigAccount.sequence_number that gets incremented.
• In most cases a multisig v2 account will not have any gas available, because the gas fee payer is typically an owner who executes transactions via a MultisigTransactionPayload

Additionally, the requirement to include a well-formed but invalid signature is confusing and cumbersome.

Hence per https://github.com/aptos-labs/aptos-core/issues/6862#issue-1607104987 , I suggest removing requirements 1, 2, and 3.

[movekevin]

@alnoki Sorry, not sure if I follow your concern here. The current gas and nonce checks actually apply to the owner who sends the transaction and are not levied against the multisig account. This is the case for both simulation and actual execution of a multisig tx. Is there some other aspect that I missed here? The code for this is here: https://github.com/aptos-labs/aptos-core/blob/main/aptos-move/aptos-vm/src/aptos_vm.rs#L1456

The Account.sequence_number of a multisig v2 account should always be 0, since it is only the MultisigAccount.sequence_number that gets incremented.

We actually can't completely remove the nonce for the multisig account. It's not always correct that the sequence number can be ignored as we do allow an existing account (might or might not have an multi-ed25519 key) to migrate itself to become a multisig account. This is a common use case for old multisig accounts (multi-ed25519 auth key) but can be a powerful use case for normal accounts as well when a protocol team wants to decentralize or make themselves more secure.

[alnoki]

It's not always correct that the sequence number can be ignored as we do allow an existing account (might or might not have an multi-ed25519 key) to migrate itself to become a multisig account

@movekevin thanks for pointing out this possibility that I overlooked

The current gas and nonce checks actually apply to the owner who sends the transaction and are not levied against the multisig account.

I think the core issue here is simulating an arbitrary transaction that requires the &signer of a MultisigAccount, rather than of an individual owner: right now for such a transaction to be simulated it would first have to pass proposal flow and have enough votes to execute, which could lead to a situation of a pending transaction that no one actually wants to execute, but rather was voted on as yes just because the simulation was of interest.

Basically for a multisig there is no way to simulate the outcome of an executed multisig transaction (where the &signer of a MultisigAccount is generated) before proposal flow, even though proposal flow would ideally take place only after a simulation was performed.

[movekevin]

right now for such a transaction to be simulated it would first have to pass proposal flow and have enough votes to execute

Actually on the contrary, if you recall https://github.com/aptos-labs/aptos-core/issues/8304, currently simulation of multisig txs (effectively acting as the multisig signer) only works for proposals that have NOT been created. It doesn't support simulating executing pending multisig txs (those that have already been created and might have gone through proposal flow). Once that ticket is closed, we'll have supported both - simulating txs that have or have not been created.

Let's also take any multisig-specific discussion over to the other ticket so we can keep this one focused on improving the simulation API for non-multisig txs

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove the stale label or comment - otherwise this will be closed in 15 days.