feat(standards): Add DelayedExecution (Timelocked Accounts) to AuthMultisigSmart

[onurinanc]

Closes: #3043.

Previously opened a draft PR implementing all features regarding Smart Multisig here: #2973. That PR still relatively big, and we separate the delayed execution logic into this PR.

[PhilippGackstatter]

I left a few questions/comments/nits. Overall, I'm having a hard time wrapping my head around this PR. In particular:

• it seems we have multiple names for the same concept - would be great to unify.
• I find the use of the pending slots hard to follow, and I'm not sure I understand why we need these. I left a question/suggestion to use auth args instead.
• I don't understand why we need the cancel_and_propose functionality when we already have the individual cancel and propose.

[PhilippGackstatter]

Nit: I'd call this TX_SUMMARY_COMMITMENT instead of TX_HASH for accuracy (everywhere it is used in this PR).

[PhilippGackstatter]

Nit: Returning the zeros is unnecessary.

[PhilippGackstatter]

Suggested change

	proc get_propose_expiration_delta
	exec.get_delayed_execution
	# => [min_delay, propose_expiration_delta, 0, 0]
	proc get_propose_expiration_delta
	exec.get_delayed_execution_config
	# => [min_delay, propose_expiration_delta, 0, 0]

Nit: Maybe the current procedure name could be a bit clearer.

[PhilippGackstatter]

I don't understand why we set and then get the delta - this seems redundant. The neq.0 check is already done in tx::update_expiration_block_delta (but it is not documented in a Panics if section - if you don't mind, we could add it in this PR).

So, I think the whole procedure can be removed in favor of calling tx::update_expiration_block_delta directly.

[PhilippGackstatter]

Does this procedure use TX_HASH? If not, can we remove it from the inputs/outputs? I'd also pass in num_verified_signatures but not return it. Caller should dup it.

[PhilippGackstatter]

Is the use of this procedure to communicate to the auth procedure that the current transaction executed a proposed action? It seems like this is intended to be called from a tx script, which is arbitrarily provided by the tx executor.

If so, can we not achieve the same by passing a flag as AUTH_ARGS? And if so, can we get rid of all the pending slots by using this pattern?

[onurinanc]

I think the same pattern needs to stay for propose/cancel, so it might be good keeping execute on the same pattern for symmetry. I'm not sure if removing all the pending slots by using the AUTH_ARGS pattern works.

[PhilippGackstatter]

Is this procedure description accurate? In set_pending_execute we write PENDING_EXECUTE_FLAG and not a HASH, so there is a mismatch.

[PhilippGackstatter]

Is the functionality of this procedure not the same as calling cancel and then propose? Why do we need a single procedure for this?

[onurinanc]

Commented here now: #3043 (comment)

[PhilippGackstatter]

Given that we clear the pending slots as the last step, the tx summary we computed earlier contains the changes to the pending slots. This works in principle, but feels a bit unclean. Mentioning in case this was not intended.

[onurinanc]

Update:

Now that #3383 binds the reference block commitment and the expiration block delta into the signed transaction summary, the delayed-execution flow needs a small design change. This comment explains why and proposes a change in the design.

Before #3383, the transaction summary commitment was:

TX_SUMMARY_COMMITMENT = hash(account_delta, input_notes, output_notes, user_params)

It was independent of the reference block. After #3383 it also binds the block and expiration:

TX_SUMMARY_COMMITMENT = hash(account_delta, input_notes, output_notes, BLOCK_COMMITMENT, expiration_delta, user_params)

A delayed transaction is proposed at one block and executed later, at a different block, and the delayed-execution flow currently keys a proposal on the transaction summary commitment and recomputes that same commitment at execute time to look the proposal.

With the change binding block into the commitment, the value computed at propose time, never equals the value computed at execute time, so the lookup fails and the timelock and consume step never runs.

Proposed design:

We can keep the TX_SUMMARY_COMMITMENT exactly as #3383 defines it for signature verification, and introduce a second, block-independent commitment that identifies what the transaction does, used only as the proposal key:

ACTION_COMMITMENT = hash(account_delta, input_notes, output_notes, user_params)
                    # i.e. the tx summary with BLOCK_COMMITMENT and expiration_delta are zero

The reference block and expiration are execution context, not part of the transaction's intent, so excluding them is both necessary so that propose and execute agree on the commitment. The account delta, input and output notes, and user parameters constitutes ACTION_COMMITMENT, so the action's identity is still works.

At execute time the auth procedure computes both commitments from the same summary: the full one for signature verification, and the action commitment to match the proposal. To make this happen:

• Add a hash_action_commitment helper that hashes the six summary words with the block commitment and expiration delta zeroed out, so the result identifies what a transaction does, independent of when it runs.
• Derive both commitments from the same summary: look up proposals by the action commitment (is_tx_proposed, assert_and_consume_proposal), and keep verifying signatures against the full tx-summary commitment.
• multisig_smart/delayed_execution.masm: proposals are now stored under the action commitment, and that's what cosigners sign.
• TransactionSummary::action_commitment() in miden-protocol as the Rust equivalent, so proposers and tests derive the same value as the MASM helper.

Note on signatures:

Because signature verification stays over the block bounded summary, the execute transaction verifies fresh signatures over its own summary, while the proposal is authorized by signatures over the action commitment. So the proposal and the execution are authorized independently: the proposal proves "this action was scheduled and the timelock started", the execution proves "the approvers authorize this specific run now". This is a deliberate change from the earlier "sign once, reuse the same signature at propose and execute" idea, which only worked while the summary was block-independent. It means the following:

• At propose time → the action commitment is signed.
• At execute time → the full transaction summary is signed.

Any feedback on this design? @bobbinth @PhilippGackstatter @mmagician

[PhilippGackstatter]

Thanks for the updated proposal!

A delayed transaction is proposed at one block and executed later, at a different block

Does this necessarily have to be the case, or is it even desirable?

As mentioned in #3210 (comment):

Contrary to intuition, committing to the block also doesn't force multiple in-flight multisig transactions to be executed in the same order in which they were created. That is, if tx A with ref block 5 is created before tx B with ref block 10, then it is actually allowed and possible to execute B first and then A.

So, I think there is no protocol reason why we'd need to propose at one block and execute at a different block.

Additionally, if the multisig tx involves FPI calls, then what the proposal tx against ref block X signs are the FPI calls against the account states in block X. If we later change the reference block, the foreign account states may have changed and return different values, and the signature would be stale. From this perspective, it seems desirable to use the same ref block during proposal and execution, because it guarantees the action/effects portion of the tx summary does not change.

I can also see the counterargument to this: Re-signing at execution time means we can use a newer ref block and execute against newer foreign account state. However, by its nature, delayed execution, due to the inherent delay, authorizes an action that shouldn't require the newest blockchain state, else it would be the wrong mechanism.

For completeness, there is also the fee-related concern mentioned in #3210 (comment), but I think we'll solve this separately in #3358.

• At propose time → the action commitment is signed.
• At execute time → the full transaction summary is signed.

In my mind, it's a UX feature that we can use the same signature for proposing and executing, as signing a proposal itself already signals the approval for its execution (at least for some timeframe - signing a block commitment + expiration delta does this directly at the signature level).

To summarize, I think the design space allows for the old and the new model. I think the main differences are:

• old/curent model: uses the proposed, likely older foreign account state, but requires signing just once per approver.
• new model: uses the newest foreign account state, but requires signing twice per approver.

For fee-computation purposes, a newer ref block is always preferable, but due to the signing delay for multisigs in general, I think we need a separate general mechanism here, and so I'm not sure that it should be the deciding factor.

Given the above, I still prefer the old model due to the UX benefits.

[onurinanc]

Does this necessarily have to be the case, or is it even desirable?

I do think it is necessary. In the same ref block model, how do we enforce that min_delay has elapsed when the execute tx references an old block? Since the timelock reads the timestamp of the ref block, execute necessarily references a newer block, this changes the full summary and makes an action commitment mandatory for matching.

Actually, a single signature per approver can be achieved without requiring the same ref block, we sign the action commitment at propose time, and at execute time we verify that same signature against the action commitment as well. The ref blocks would still differ, but since the signed message stays the same, the same signature can be reused.

The problem is that this brings #3210 back. If we only sign the action commitment, the signed message no longer binds the reference block commitment or the expiration delta .

Since the execute block isn't known at propose time, the only way to keep the block and expiration bound is to verify the full summary at execute time. For delayed txs, do you think reduced binding is acceptable?

[PhilippGackstatter]

Since the timelock reads the timestamp of the ref block, execute necessarily references a newer block, this changes the full summary and makes an action commitment mandatory for matching.

Ah, true. We require a newer ref block to enforce the delay.

a single signature per approver can be achieved without requiring the same ref block, we sign the action commitment at propose time, and at execute time we verify that same signature against the action commitment as well.

&

The problem is that this brings #3210 back.

I think even when we sign the "action commitment" at propose time and the tx summary at execution time, we have the "reorganization and cross-network ambiguity" described in #3210, because an action commitment doesn't bind the ref block or the chain's identity.

So, I guess the most secure option is to avoid the single signature per approver and require signing at execution time from everyone involved. That way, actual execution is bound to a specific ref block and chain identity. That's the proposal you made originally.

I think reduced binding may be acceptable, but I'm not 100% convinced, and so I would err on the side of caution. We can always ship a "multisig smart 2.0" at a later point that improves such aspects.

One note on the naming: Since the "action commitment" commits to the outcome of a tx, but doesn't care how that outcome was achieved (e.g. it doesn't bind the tx script), I think transaction effects - focussing on the effects/outcome - would be a better term than "action", which focusses on the actions that were executed in a transaction. Transaction effects is also a standard term in other chains, so I think this fits well.

Two notes regarding the implementation:

• For now, I'd keep this TransactionEffects type in the multisig code rather than move it next to tx summary, mainly because a user accidentally using it can reintroduce M-08: Signed Transaction Summary Does Not Bind Expiration or Reference Block Commitment #3210.
• Since native_account::compute_delta_commitment is pretty expensive, it would be good to only invoke it once (when building both the effects and summary during execution).

[partylikeits1983]

It looks like a merge issue has caused this PR to show a much larger diff than the feature itself. @onurinanc could you please take a look and update the branch so the diff contains only the intended changes?