chore: update protocol to rev 3154a3

[mmagician]

Updates all protocol crates to rev 3154a3 and adapts to the following interface changes:

Authentication

• AuthFalcon512Rpo::new(pk) replaced with AuthSingleSig::new(pk, AuthScheme::Falcon512Rpo)
• create_basic_wallet now takes AuthMethod instead of AuthScheme as a paramter

AggLayer (in genesis tests)

• create_existing_bridge_account now requires bridge_admin_id and ger_manager_id (which are created as two BasicWallets)
• create_existing_agglayer_faucet now requires token_supply, origin_token_address, origin_network, scale. Cap max_decimals = 8 (prev. 18 to match Ethereum, but now we enforce max_decimals < 12. We will eventually need to adjust scale and/or max_decimals, but this is WIP in the protocol repo)

[Mirko-von-Leipzig]

If this is such a common pattern, should we maybe make this easier?

impl AuthSingleSig {
    fn falcon_512(pub_key: Falcon512PublicKey) -> Self { ... }
}

Though I don't have enough insight into how these various components play together to really know what the right API is.

[mmagician]

This could work, but IMO it would unnecessarily couple the enum definition to the API of AuthSingleSig:

#[non_exhaustive]
pub enum AuthScheme {
    Falcon512Rpo = FALCON_512_RPO,
    EcdsaK256Keccak = ECDSA_K256_KECCAK,
}

and whenever the enum changes, we'd need to adapt the constructors of AuthSingleSig. It's not a huge deal, but if I were to choose I'd probably avoid this coupling.

[Mirko-von-Leipzig]

But the enum definition is tied to it already? Or why else do you need both the enum and the public key in AuthSingleSig::new(..)? Right now its possible to pass in effectively any value which seems very incorrect.

[mmagician]

Right now its possible to pass in effectively any value which seems very incorrect.

That's a separate question in my mind: are you talking about validating that the passed pub key is consistent with the specified scheme?

This could be achieved with the current interface:

/// Creates a new [`AuthSingleSig`] component with the given `public_key`.
pub fn new(pub_key: PublicKeyCommitment, auth_scheme: AuthScheme) -> Self {
    match auth_scheme {
        // TODO verify that the pk is valid w.r.t. to scheme supplied 
    }
    Self { pub_key, auth_scheme }
    }

or with your suggested interface:

impl AuthSingleSig {
    fn falcon_512(pub_key: Falcon512PublicKey) -> Self {
        // TODO verify that pub key is a valid falcon key
        Self { pub_key, AuthScheme::Falcon512Rpo }
    }
}

having a AuthSingleSig::falcon_512 constructor would be purely for convenience, but unless we decide to add validation, it won't solve "pass in effectively any value which seems very incorrect."

[Mirko-von-Leipzig]

My suggested interface does not require validation because the type already is that type? Which is kind of my point. If a user has t: T, why do we ask them to use new(t.to_string(), t.type()) instead of just taking new_t(t).

Or in other words, we should use types which are already validated instead of doing validation inside of other places. Or taking in vague blobs as an API.

[mmagician]

Oh I see, so instead of using PublicKeyCommitment (which both falcon and ecdsa "reduce into"), you'd require the helper constructors to take the individual scheme's pk (like Falcon512PublicKey, not just a commitment to it).

I think this could work

[Mirko-von-Leipzig]

Yeah :) Because what ends up happening for me, is that "reducing"/From/Into aren't trivially discoverable. And then it takes me a while to figure out how to produce the correct blob from my actual data

[mmagician]

Ok thanks for your patience in explaning :) I'm glad we're on the same page now I created an issue for this

[juan518munoz]

Looks good, thanks!

[juan518munoz]

oops misclicked 😅