Improving l1 to l2 messaging API

[benesjan]

Background

In Oxide we don't really use the secret hash when depositing to L2 — it's set to a constant value everywhere. That's because we want the message to contain a recipient. So instead we have a recipient_hash computed offchain as:

recipient_hash = hash(secret, recipient)

This recipient_hash is then part of the message content preimage.

The secret in the recipient hash essentially just acts as randomness, hiding the recipient from preimage attacks.

Nice properties

• Message security matches note security. The recipient in the message is the same thing as the note owner — it's no longer only the secret that "owns" the message.
• Someone else can claim a message on your behalf (e.g. a relayer). This doesn't seem that relevant anymore since Oxide's lazy claiming approach deprecates it, but mentioning it here for completeness.

The problem

This has a very bad property for Oxide: with a constant secret, anyone can see when a recipient spends the message (broken nullifier unlinkability).

pub fn compute_l1_to_l2_message_nullifier(message_hash: Field, secret: Field) -> Field {
    poseidon2_hash_with_separator([message_hash, secret], DOM_SEP__MESSAGE_NULLIFIER)
}

We could work around this by not using Aztec.nr's process_l1_to_l2_message, but I'd rather refactor fix the core API issue.

Possible solutions

Solution 1 — Drop the secret hash altogether.
Expect the contract calling Inbox to handle it, then provide standardized deposit and claim utils in both Solidity and Aztec.nr.

Solution 2 — Replace secret_hash with salted_recipient_hash.
Do this in the Inbox contract and everywhere else, then modify compute_l1_to_l2_message_nullifier to use the recipient's nhk instead of the secret.

My take

I think Solution 1 is better: with the utils we get basically equivalent devex without enshrining a specific derivation scheme in the L1 contracts.

The reason why we have not done it as I propose in the first place is because the API is just very old (it's from a time when we didn't even have a proper Aztec.nr). Now the API is overfitted and pushes devs towards bad security model of "secret" owning a message.

Then if devs try to do it properly and have the recipient in the content then if they use the constant secret approach we have in oxide they are likely to shoot themselves in the food as the standard process_l1_to_l2_message functionality of Aztec.nr expects real secret on the input for the message nullifier to not be linkable.

Opinions?