Support for pass-through transactions

[mmagician]

As described in this client issue, there are a few obstacles to creating pass-through transactions (tx's which don't modify account state, prev. referred to by me as in-flight transactions) right now in the client's sanity checks, but also in the kernel.

The summary is as follows:

1. We determine if the account is new by its nonce (nonce == 0 is a new account)
2. If it's new, we set INITIAL_ACCOUNT_COMMITMENT to EMPTY_WORD
3. The first transaction computes the actual commitment of the account (even if the tx doesn't touch the account state, it will end up with a non-empty final commitment)
4. First transactions works fine, at the end of which the global account state now contains the real commitment of the account.
5. But nonce hasn't changed
6. So the second transaction we issue starts again with INITIAL_ACCOUNT_COMMITMENT = EMPTY_WORD
7. And block building fails because of the local vs. global mismatch

There are at least three options:

Increment account nonce after the auth procedure if nonce == 0

As the headline says: if the auth procedure of the first executed transaction hasn't bumped the nonce (e.g. a certain configuration of AuthRpoFalcon512Acl), then we force the increment.

While this is the simplest approach, it does have the downside of complicating the user docs: we now have to explain a very particular edge case of why the auth procedure might not have the expected effect (but only in the very first tx).
I'm not a fan of this edge-case complexity.

Always increment account nonce if not incremented in the auth procedure

This is a variation of the first approach, where we always increment the account nonce whenever a transaction is executed against it.
Despite it being a state-changing transactions, it's more of a kernel-dictated-change, rather than a user defined one.
If we do this, we might as well completely hide incr_nonce procedure from users, and simply always call it.

Re-define what we mean by new Account; allow zero nonces for existing accounts

Rather than checking nonce == 0, the most reliable check is "is this account already onchain".
Unfortunately, the Account by itself doesn't currently have enough info for this, so Account::is_new() wouldn't work. We could hack this by checking if seed is present (since the client actually erases the seed after it applies the first tx update).

So assuming we can somehow figure out how to properly check is_new(), it would mean we provide the correct INITIAL_ACCOUNT_COMMITMENT for tx creation.
We could then remove the following check from the prologue (process_account_data procedure, account-exists conditional branch)

# assert the nonce of an existing account is non-zero
exec.memory::get_account_nonce neq.0 // <---------- we would now allow zero nonces for existing accounts
assert.err=ERR_PROLOGUE_EXISTING_ACCOUNT_MUST_HAVE_NON_ZERO_NONCE

This last approach effectively means we would allow zero nonces for existing accounts.

[PhilippGackstatter]

Always increment account nonce if not incremented in the auth procedure

I'm not sure the second option is really an option. I think it would mean that any user can create a transaction against any account and produce a non-empty account delta. Everyone can do this without needing authentication. So now you can, generally, mutate the state of any account. I think this can be abused to prevent access to accounts. E.g. you want to publish a transaction against your account going from state A to B, and I can try to frontrun a transaction that's going from A to C instead. If my transaction gets in first, yours will be invalidated and you have to reissue it.

Increment account nonce after the auth procedure if nonce == 0

I believe the above concerns do not apply in this case, because it only applies to account-creating transactions. So no matter whether the auth procedure incremented the nonce or the kernel did it, the end result and therefore commitments to deltas and account state are the same. The only difference may be that the signed delta commitment is different (e.g. it may sign nonce_delta 0 if the kernel increments it later), but that's probably not an issue.

Just as a side note: If we go ahead with #1879, then any account that has non-empty storage before or after the account-creating transaction would be required to increment the nonce. This is a stricter requirement than it is now, since the initial delta is often empty in the current architecture. Just something to keep in mind while we think through solutions here. This does probably not apply to an anonymizer account, since it probably has empty storage throughout its lifetime - so there are still cases where the nonce could actually be 0.

Re-define what we mean by new Account; allow zero nonces for existing accounts

I think this would generally work. I believe the transaction kernel should be unaffected except for the removal of the exec.memory::get_account_nonce neq.0 check. As for handling the Rust side, I'm not sure yet what the best approach would be. This affects at least a few places:

• Deciding in TransactionExecutor whether to execute an account-creating transaction or not.
• Validating the seed in an (Partial)Account (see validate_account_seed).
• Whether or not to remove the seed as part of Account::apply_delta.

Before thinking about solutions to this, I wonder if it isn't simpler to just require that account-creating transaction increment the nonce. In particular, if we end up having account create procedures (#1663) checking that they have incremented the nonce would be fairly easy. This is very similar to the other options, with the difference that an account create procedure would have to explicitly increment the nonce and the tx kernel would only check that if memory::get_init_nonce == 0 { memory::get_account_nonce eq.1 } (pseudo code) after the create procedure has executed. This would be more explicit to users rather than automatically done by the kernel. That has its own weirdness - probably raising the question why it isn't done automatically, but we can't seem to have it all 😅.

Overall, I think I'd be fine with this last solution but also with the nonce check removal option if we can find a good way to handle the Rust side.

Btw. when I read in-flight transaction, I'm thinking of a transaction that is not yet committed to the chain state (basically how miden-node defines in-flight). I wonder if there are better names: non-mutating, note-only, or pass-through transactions maybe?

[mmagician]

I agree, once we decide that a create procedure is needed, this would nicely solve the outlined issue, too.

---

pass-through transactions

I like this name! Thanks, I changed the title and description

[bobbinth]

As mentioned offline, I think my preference here would be to enforce that after auth procedure is executed the nonce must be non-zero. This means that in the first transaction that gets executed, the auth procedure would need to increment the nonce. This, in turn, means that depending on the specifics of the account, the auth procedure may need to handle the first transaction differently from other transactions.

For example, for contracts like basic wallet, or counter contract, auth procedure would be "uniform" (i.e., the same auth procedure regardless of what the value of nonce is). But for contracts like multisig or any "pass-through" contract, auth procedure would need to execute one logic when nonce == 0 and another logic when nonce != 0. The logic for nonce == 0 would be kind of like "contract deployment logic" which we may want to handle in some special way.

One potential approach to handling this is to allow users to specify deployment procedures optionally and then automatically "merge" auth and deployment procedure into the auth procedure. In MASM this could look something like this:

#! This is the authentication procedure specified via the @auth attribute
@auth
export.foo
    ...
end

#! This is the deployment procedure specified via the @constructor attribute
@constructor
export.bar
    ...
end

When this gets deployed into an account, the actual auth procedure would look something like:

export.auth
    exec.account::get_nonce eq.0
    if.true
        exec.bar
    else
        exec.foo
    end
end

If an authentication component does not specify @constructor procedure, then the @auth procedure just becomes the authentication procedure (i.e., defining @constructor procedure is optional).

In a way, having this separation becomes kind of just "syntactic sugar" because we can do this already just in a slightly less ergonomic way. But it may still be useful to have this.

If we go this way, we probably should implement something like #1736 first.

[PhilippGackstatter]

As mentioned offline, I think my preference here would be to enforce that after auth procedure is executed the nonce must be non-zero.

Agreed 👍

One potential approach to handling this is to allow users to specify deployment procedures optionally and then automatically "merge" auth and deployment procedure into the auth procedure.

I think that's a good approach to keep the protocol side simple. It still introduces create and auth procedure as concepts for the end user, but maybe that's fine.

I guess we could have automatic merge strategies like:

• if auth and create procedures are present, then on nonce == 0 create runs and auth otherwise.
• if an auth procedure is present but no create procedure, the auth procedure always runs.

This approach could also be a nice way for users to extend auth procedures. For instance, they could provide their own create procedure to a standard multisig auth procedure, and the AccountAuthComponent would merge these into the overall protocol-level auth procedure.

[bobbinth]

I guess we could have automatic merge strategies like:

• if auth and create procedures are present, then on nonce == 0 create runs and auth otherwise.
• if an auth procedure is present but no create procedure, the auth procedure always runs.

This approach could also be a nice way for users to extend auth procedures. For instance, they could provide their own create procedure to a standard multisig auth procedure, and the AccountAuthComponent would merge these into the overall protocol-level auth procedure.

Yes, that's how I was thinking about it too. The main complication here, I think, is that the way we currently infer which components are present in the account won't quite work (we do this based on matching procedure roots, but for the "merged" auth procedure the root won't match the original auth/deploy procedures. But maybe there is a good solution to this and also, it think we'll need to figure out how to handle such things for #1956.

[mmagician]

The changes to be addressed as part of this issue are then:

• force a non-zero nonce after the execution of the auth procedure

And the changes to be addressed as part of #1663:

• introduce annotations for create and auth procedures
• merging of the two procedures if create is present
• protocol still only aware of a single auth procedure

I'd say that the other issue is less of a priority, because as mentioned somewhere here, we have manual workarounds by writing it into the auth procedure. I've placed it into v0.13, whereas this issue here is easy and can stay in v0.12.

[PhilippGackstatter]

Before we implement this, should we conclude #1879 (comment) as well? These issues are somewhat dependent.

[partylikeits1983]

Tangentially related, this PR adds functionality to allow for "in-flight" / "pass-through" filling of complimentary SWAP notes.

This might give some inspiration on how pass-through notes could be created. It might be possible without having to add any new procedures on the basic wallet. Essentially it might be possible to create a network / public basic wallet, and then anyone could execute pass through txs against the account.