Timelocked Account

[MCarlomagno]

Summary

We recently had some conversations about a potential implementation of a Timelocked Multisig (authorized transactions can be executed after some delay). We can achieve this feature using private state manager in combination with existing multisig templates.

Process

1. When a user configures a multisig account in PSM, the user specifies the timelock in number of blocks.
2. When a user proposes a new transaction, the PSM will load the current block number from the network and assign it as the proposed_at attribute for that transaction
3. After all requierd signatures were collected, if some user wants to execute the transaction, the PSM will load the current block from the netwoek and check if proposed_at + timelock > current_block.
   3.a. If false -> the PSM will throw unauthorized error.
   3.b. if true -> the PSM will sign and return the signature for authentication.

Sequence diagram

sequenceDiagram
    participant U as User
    participant P as PSM Server
    participant N as Miden Network

    U->>P: Configure multisig (timelock = X blocks)
    Note over P: Persist timelock with account metadata

    U->>P: Push delta proposal
    P->>N: Query current block
    N-->>P: block = B₀
    Note over P: proposal.proposed_at = B₀

    loop Collect signatures
        U->>P: Sign proposal
    end

    U->>P: Execute proposal
    P->>N: Query current block
    N-->>P: block = B₁
    alt B₁ < proposed_at + timelock
        P-->>U: Error (timelock not yet satisfied)
    else B₁ ≥ proposed_at + timelock
        Note over P: Authorized to proceed
        P-->>U: Ack signature for execution
    end

Loading

[MCarlomagno]

@bobbinth I'm wondering if this is what you were envisioning or I misinterpreted it?

[MCarlomagno]

@bobbinth From the conversation we had today, I have identified 2 use cases that we want to cover here:

• Account state recovery
• Challenge periods for cases where the main key was compromised

So considering this, I have reframed the idea into this

1 Recoverable State

Setup

Multisig 2/3 with signers:

• Primary key: day-to-day signer
• Secondary key: held offline/securely
• PSM key

Miden Auth

All transactions require 2 signatures,

• All regular transactions will use the primary key + PSM key for authentication.
• In case the user lost the state and/or the primary key, the user will use the recovery key to get access to the state, and to change the primary key (using PSM + secondary key as signers).
• in the case the PSM becomes unavailable/malicious, the user will use the primary + secondary key to submit transactions and optionally to configure a new PSM.

2 PSM "Delayed Mode"

Multisig with 2 thresholds and required PSM signature.

• High threshold: H/N
• Low threshold: L/N (L < H)

Ways of submission:

• When "Low" threshold was reached, the PSM won't acknowledge (sign) the transaction until some "challenge period" has passed (e.g. 50 blocks). Once the period has passed, the user can request the ack from the PSM.
• If High threshold was reached, the PSM signs inmediately.

Case: Setup of a solo-account with security window

Multisig with 2 signers + PSM - H = 2, L = 1, Window: N blocks

Process:

1. User configures the Account in PSM with "Delayed Mode", H = 2 and L = 1.
2. The only way to get the PSM acknowledgement (signature) is by proposing a transaction in PSM (using coordinator).
3. Since the proposed transaction reached L signatures (1, the proposer signature) the delay period starts to run.
4. At any point in the future, a cosigner can try to get the acknowledgement.
   5.a. If 200 blocks have passed since 3. then the PSM returns the acknowledgement (signature) and the user can submit on-chain
   5.b. Else, the PSM throws an error.
   5.c. If any other cosginer challenges the proposed transaction, the tx gets cancelled.

[onurinanc]

In your previous comments, I've supposed that you asked for propose_transaction instead of propose_key_rotation but what you were saying that instead of having a storage map of proposed_key_rotation, having a proposed_transactions for each transaction. So, I was looking for a way to propose_transaction but yes, we should be restricting for arbitrary transactions for that case.

I think key rotation, large transfers, and configuration changes such as update_spending_limit, set_thresholds would be the options for proposals.

So, for each timelocked procedures we need to have proposals such as

• propose_key_rotation
• propose_update_spending_limit
• propose_large_transfer

But maybe there is another way to get around this?
I don't think there is an obvious way to do this:

We either need to have a kernel level helper such as:

# Input: [PROC_ROOT, arg_0, arg_1, arg_2]
# Output: [TX_SUMMARY]
proc.simulate_tx
end

Or, we would somehow need PSM to simulate the key rotation and make the proposal such as create a tx_summary by executing the transaction script below and provide it to the propose_key_rotation,

begin
    update_signers_and_thresholds
end

I would prefer to have it in the kernel level if somehow possible. How could we do that? It would be something like an event

In addition to this, I think we need separate the two cases:

• 2-of-2 + PSM (primary/secondary keys + PSM)
• 3-of-5 + PSM
  since with the timelocked operations, the needs would change:

Let's think about the scenario we have for 2-of-2 + PSM:

1. Lost (but uncompromised) - no one has access to the account (solution: 1 + PSM + timelock)
2. Stolen (~ compromised and lost), e.g. someone steals the only copy of your seed phrase. (solution: needs a verification mechanism)
3. Compromised - both the attacker and the user have access to the account (solution: 2 + PSM)

We can have the PROC_ROOT_MAP as follows:
(multisig::update_signers_and_thresholds, 2)
(multisig::propose_key_rotation, 1)

OR

TX_SUMMARY_HASH |-> [num_signatures, can_execute_after, expires_at, 0]

We can also implement this using the above as @bobbinth mentioned, n can cancel proposed with n

Let's think about the scenario we have for m-of-5 + PSM:

1. Lost one-of-m key: use (multisig::update_signers_and_thresholds, 4) for key rotation
2. Compromised one-of-m key: use (multisig::update_signers_and_thresholds, 4) for key rotation
3. Lost two-of-m key: since having the threshold of 4 is not possible, use (multisig::propose_key_rotation, 3) (timelocked) -> if cancel is needed (multisig::cancel_key_rotation, 3)
4. Compromised two-of-key: this is a bit trickier since there are some scenarios here:

• in case of there is no additional malicious party inside m-of-n: (multisig::propose_key_rotation, 3) still works
• in case of there is one additional malicious party inside m-of-n: (multisig::cancel_key_rotation, 3) + (multisig::update_signers_and_thresholds, 4) protects the account
• in case of there is two additional malicious party inside: then, probably FIFO unless there is an additional delay for (multisig::update_signers_and_thresholds, 4) and use social recovery mechanism like an email login

[bobbinth]

We either need to have a kernel level helper such as:

# Input: [PROC_ROOT, arg_0, arg_1, arg_2]
# Output: [TX_SUMMARY]
proc.simulate_tx
end

Or, we would somehow need PSM to simulate the key rotation and make the proposal such as create a tx_summary by executing the transaction script below and provide it to the propose_key_rotation,

I agree that doing it in the kernel is the better option - but I don't think we need to simulate a transaction exactly. There are two potential ways to do it:

The first approach is to make a change and the roll it back immediately inside the procedure. For example, in propose_key_rotation we could do the following:

1. Update the storage slot with the new key and save the old key somewhere in memory.
2. Ask the kernel to build a transaction summary and insert this summary into the proposed_transactions map. One potentially complicating aspect here is the need to update the nonce - but maybe we can allow building transaction summaries with a user-provided nonce.
3. Update the storage slot with the old key - this will roll back the changes made in the firs step.
4. Then, in the auth procedure we detect that propose_key_rotation and validate the required signatures
   a. We may also want to check here that the only think that was updated during the transaction was the proposed_transactions map.

In the end, we end up with the transaction summary for updating the storage slot containing the key. Though, this summary would include any other actions performed during the transaction up to this point (which may or may not be a bad thing).

The second approach would require the ability to "roll back" the transaction, and could work as follows:

1. The user calls propose_key_rotation. The procedure performs the actual key rotation.
2. Then, in the auth procedure, we check if propose_key_rotation was called. If so:
   a. We compute the TX summary and save it to memory.
   b. We call the rollback_tx procedure in the kernel to roll back any actions performed during the transaction. For the account state, this should be simple; for output notes should be simple as well; but I'm not sure what to do with the input notes in this case.
   c. We validate the required signatures and insert the TX summary into the proposed_transactions map.

Both of these approaches has pros and cons and some open question. It is also possible there are other approaches. cc @PhilippGackstatter in case he as any thoughts on this.

[onurinanc]

One potentially complicating aspect here is the need to update the nonce - but maybe we can allow building transaction summaries with a user-provided nonce.

For this approach, is this planned to add to the protocol? If yes, what would be the timeline

We call the rollback_tx procedure in the kernel to roll back any actions performed during the transaction.

Or, if we are going to have the rollback_tx approach, when this will be added to the kernel so that we can start implementing timelocked accounts?

[bobbinth]

Neither of these is implemented and we haven't discussed timelines yet. Once we pick the approach, I think the actual implementation could happen relatively quickly (e.g., within a week). Could create an issue for this in miden-base? We can figure out which approach makes the most sense there.

[onurinanc]

Done here: 0xMiden/protocol#2211

[partylikeits1983]

This change could actually “kill two birds with one stone”:

1. Add the “timelock” functionality described above.
2. Add an expiration window to signed TransactionSummary values on the multisig.

Related issue: 0xMiden/protocol#2000

We could extend TransactionSummary like this:

struct TransactionSummary {
    // ...
    valid_block_height_begin: Felt,
    valid_block_height_end: Felt,
    // ...
}

Here, valid_block_height_begin is the block height at which the TransactionSummary becomes valid, and valid_block_height_end is the block height after which the TransactionSummary is no longer valid.

[MCarlomagno]

I was actually thinking on proposing something similar when started working on this idea, I'm wondering who defines the validity window in the TransactionSummary? because in the case of PSM, that should be something enforced on-chain, meaning that is not something that can be "made up" by the clients, then the valid_block_height_begin and valid_block_height_end must be values generated by the on-chain MASM code

[bobbinth]

I'm still thinking that this data could be encoded into the salt field of transaction summary (e.g., as a single field element since block numbers are guaranteed to be in u32 range). Then, the format of tx summary doesn't need to change and we don't need to introduce fields that may not be relevant in all situations.

In terms of who defines the validity, it would have to be done in the account itself. For example, let's say we had something like prepare_rotate_signer procedure. This procedure would create a tx summary according to the rules it defines (e.g., setting validity window to current_block + 1 day..current_block + 2 days), and then would save the summary into the storage map.

Then, once executing a transaction with this summary becomes possible, we'd execute a transaction that invokes rotate_signer, and then the auth procedure would verify that:

1. The tx summary for this transaction matches one of the transaction summaries in the map, and
2. The element in the salt of the tx summary is valid in the context of the current block.

I'm skipping some details here, but that's roughly how I see the general flow.

[onurinanc]

Thank you all for participating the discussion above. (@bobbinth @partylikeits1983 and @MCarlomagno )
Related to this issue I have implemented a draft version of single signer timelocked accounts here:

• https://github.com/OpenZeppelin/miden-confidential-contracts/blob/main/masm/auth/timelocked_account.masm
• https://github.com/OpenZeppelin/miden-confidential-contracts/blob/main/tests/auth/timelocked_account.rs

Some features discussed above might be missing for now but I would like to discuss the current capabilities & additional features:

I would like to provide an overview of the current features of the implementation:
We can call the timelocked_account implemented here as Single User (Primary Key + Secondary Key) Timelocked Multisig Account

This account is created by the following setup:

• All regular transactions use either primary key / secondary key + PSM key for authentication. 1-of-2 + PSM
• PSM key rotation doesn't require a timelock and a signature from PSM, but require signatures both from primary key and secondary key 2-of-2
• Updating the either primary/secondary key requires a delay using the propose/execute logic. 1-of-2 + PSM + delay
  • Both primary and secondary keys propose_key_rotation
  • After the delayed block number any of the keys execute_key_rotation, which update_signers executed internally

As I read the discussion above, the following feature is missing:

• cancel_proposed_rotation

The following questions are still open for me:

1. Is it okay that either primary or secondary key sign regular transactions? Should we allow just primary_key to sign the transaction?
2. How can we stop the propose/cancel key rotation loop if the one of the keys are compromised and the actual user get the account back from the adversary?

But if it is signed by 2 keys, then at least 2 keys are required to cancel it.

3. In this case we are talking about the multisig account but not every user have both primary and secondary keys right?

I think the next step will be to implement:

• Multi-user Timelocked Multisig Accounts (for update_signers_and_thresholds)
• Timelock for Spending Actions

[bobbinth]

Thank you, @onurinanc! I think this is very close to what I described in #61 (reply in thread). I think the main difference is that in my description a combination of both user keys can do the rotation immediately. An alternative to this would be that if they key rotation is proposed by 2 keys, 2 keys are required to cancel it. I'm not sure which one would be easier to implement.

I haven't reviewed the code in detail yet, but one thing I wonder is whether we can make some aspects a bit more general. For example, instead of keeping track of "proposed key rotations", could we keep track of "proposed transactions". The map would contain a hash of the proposed transaction with the associated timelock parameters, and then key rotation would be just one of such transactions.

Similarly, cancel_proposed_rotation would be cancel_proposed_transaction and then we'd be able to use it to cancel any of the proposed transactions.

Overall, I think the interface of the component (authentication procedure excluded), could be something like:

• propose_key_rotation
• execute_key_rotation
• cancel_proposed_transaction

[onurinanc]

For example, maybe sending $1000 USD can go through immediately, but sending $1000000 requires a 1-day delay.

Delay Large Transfers: (also specified here by @bobbinth 0xMiden/protocol#2143 (comment)

I would like to go further and discuss this idea.

When I try to implement this inside the authentication component, I see that it’s different from the delay used for key rotation. The reason is that the procedure we call "key rotation" is actually one of the procedures inside the authentication component such as update_signers_and_thresholds or update_signers, or some procedure we define there which provides the key-rotation functionality.

When performing a key rotation update, we can do this by proposing the key rotation, and then, during execute, calling the update_signers procedure defined specifically for key rotation.

However, things get a bit more complicated for the “delay large transfers” part. The reason is that there is no specific procedure inside the authentication component dedicated to transfer operations.

Let’s assume we “embed” the functionality of the P2ID note into the authentication component (for example proc.p2id) and implement this using propose/execute logic. Even if we did that, we still couldn’t prevent an attacker who has taken over the account from creating a P2ID note directly, instead of going through the propose/execute logic.

To me, it seems more reasonable to implement delaying large transfers in the following way using 0xMiden/protocol#1068

With this idea, the callback returned from the faucet could enforce restrictions if the timelock has not yet expired. What do you think about this?

I also think that, instead of introducing a delay for large transfers at the account component level, we could apply the following different security measures independently:

• When a large amount is detected, the threshold level could be raised to the maximum.
• A cooldown could be added, for example requiring that a certain number of blocks has passed since the last large transfer.
  • Alternatively, the cooldown for sending large amounts could be updated after every transaction. (This would be more of an approximation and wouldn’t be refreshed at strict fixed intervals.)
• For large amounts, daily spending limits could be set per faucet_id.

What would be your approach related to delaying large transfer? Do you have any implementation idea in your mind?

[MCarlomagno]

[Off topic] Some pattern I'm starting to see is the idea of creating transaction proposals on-chain as opposed to off-chain (PSM), and I'm wondering if at some point we will want to unify the approach to simplify things?

I think both approaches have pros and cons but if we start to enforce some transactions to be proposed and executed on-chain then maybe makes sense to follow the same pattern in all of them?

Maybe this is not something we will want to solve just yet but bringing it up for future discussions

[mmagician]

if the account does not expose this procedure, our current P2ID (and P2IDE) notes won't work with this account

So while all the above is correct, I don't think receive_asset is relevant to the discussion of delaying transfers out of an account, since we only care about assets moving "account -> note".

[onurinanc]

I think this #61 (reply in thread) would also work for this #61 (reply in thread)

[bobbinth]

[Off topic] Some pattern I'm starting to see is the idea of creating transaction proposals on-chain as opposed to off-chain (PSM), and I'm wondering if at some point we will want to unify the approach to simplify things?

I think both approaches have pros and cons but if we start to enforce some transactions to be proposed and executed on-chain then maybe makes sense to follow the same pattern in all of them?

Maybe this is not something we will want to solve just yet but bringing it up for future discussions

Maybe - but I'm thinking of these as fulfilling two distinct goals:

1. On-chain proposals are there primarily to enforce delayed execution.
2. Off-chain proposals are there primarily for coordination purposes.

Using on-chain proposals for coordination may be tricky because we'd need to put full transaction details on-chain. In the current discussion, the only thing that goes on-chain is the hash of the transaction summary - and so, a separate mechanism would be needed to make sure that the actual details are available to the relevant users.

[MCarlomagno]

yes good point, I was confused by my original idea, we will only store the hash on-chain then it doesn't really compete with the idea of coordinator/PSM

[onurinanc]

@bobbinth Before diving into my questions related to your reply: #61 (reply in thread) I would like to highlight the following:

The reason why the propose/execute logic fits well in Safe Multisig is that, in the EVM, we can propose a function call without actually executing it thanks to calldata. In other words, proposing a transaction does not result in any account state change. This allows the function execution to remain pending inside a proposed (or confirmed) transaction until the required conditions are met.

In Miden, however, in order to create a proposed_transaction, we need to simulate the execution of the function to obtain a TransactionSummary, and then roll back to the original state if we are operating at the account level. Since authentication is handled at the authentication component level, a transaction without a sufficient number of signatures will fail anyway and will not be able to mutate the account state. As a result, we need to roll back and somehow persist the transaction as a proposed_transaction.

If we rely on the TransactionSummary to do this, the summary necessarily contains the account delta that transitions the account from one state to another. This implies that if any state change occurs between the current state and the proposed state, it would result in state loss.

This leads me to the following questions:

Should we lock the account whenever there is at least one entry in the proposed_transaction list?

• If the account is not locked, any incoming or outgoing transfer that occurs in the meantime would be lost.
• If the account is locked, then in the case of a compromised key, where an adversary can continuously create proposals, operations such as rotate_key would no longer be possible for 2 keys. One potential mitigation would be to allow only rotate_key while locking all other operations. However, this might introduce additional edge cases and would require explicitly defining which operations are allowed and which are not, along with a clear policy for managing them.

Before diving deeper into this direction, I am curious whether this problem could instead be addressed by leveraging notes.

As an example, consider the following note script. We could define KEY_ROTATE.masm and configure the note to be sendable with recipient = sender.

proc.verify_unlocked
end

begin
    verify_unlocked
    call.rotate_key
end

For KEY_ROTATE.masm, a rotate_key_timelocked prerequisite could be implemented inside TimelockedWallet (similar to the move_asset_to_note_small idea of @mmagician . We could then configure PROC_THRESHOLD_ROOTS_SLOT with (rotate_key_timelocked, 1), meaning that this note can be consumed with a threshold of 1 for the wallets export rotate_key_timelocked.

However, I am currently stuck on how such a note could be canceled.
If this were a P2IDE, we could simply set sender = recipient and reclaim the assets by checking reclaim_block_height. In this case, however, I am not sure how the note could be revoked or reclaimed. Do you have any ideas on how cancellation could be handled for KEY_ROTATE.masm?

Even if the above were possible, let us now consider a 3-of-5 multisig scenario:
Assume we configure (rotate_key_timelocked, 3), and that the default note creation threshold is also set to 3. This implies that:

• 3 approvers can create the note, and
• 3 approvers can consume the note.

The question then becomes: how can 3 approvers cancel this note within the same account_id?

Cancellation would require signatures, but we can not have the signatures directly to the note itself. To support this properly, it should've been a concept such as AuthenticatedNotes, where, for example, a note’s serial number could be zeroed out (effectively canceled) once a sufficient number of signatures from approvals who know the serial number are provided. This would imply mutating the NoteDB via authentication, which feels conceptually awkward since notes are not inherently authenticated objects.

Another possibility would be to define a CANCEL_NOTE.masm as a WellDefinedNote and include it in TimelockedWallet, enabling usage such as (cancel_proposed_note, 3).

For this to work, CANCEL_NOTE.masm would need a specific property such as anyone with sufficient knowledge could derive the Nullifier, since a note is defined by:

serial_num, script_root, input_commitment, vault_hash

Then, any approver could therefore compute the Nullifier (possibly in the prologoue). The key question then becomes, how can we assign the associated note in the NullifierDB as a non-zero value to cancel it?

Would it be possible, at the kernel level, to introduce a procedure that sets the corresponding note in the NullifierDB to a non-zero value, effectively canceling the note? I think this could be included since only people having the full access to the state can change the nullifier.

Alternatively, is there a way to implement a mechanism directly in the note script itself that allows reverting/cancelling the note?