The objective of this thread is to explain the need for ECDSA (secp256k1) signatures in Anoma/Juvix in the context of the EVM protocol adapter (PA) prototype and to find a minimal working solution in the short term.
Context
As noted in the Crpytography team meeting 2025-02-13, we want to
Problem
The Juvix/Anoma backend uses a different cryptogrxaphic scheme than the EVM
- Anoma uses Ed25519 signatures
- Ethereum uses ECDSA (secp256k1) signatures
This poses a problem if we want to have correspondences between resources and EVM state that involves identities, e.g., is owned.
For example, we want to be able to wrap and unwrap tokens. Wrapping works as follows:
The PA receives an RM transaction containing an FFI call field in which Alice sends 2 ETH to a wrapper contract. A wrapper resource being part of the transaction checks that a corresponding ETH resource with a matching quantity and with Alice’s public key as the owner is part of the transaction action.
However, since the cryptographic schemes are different, the public key from the FFI call field is associated with a different private key on Anoma that Alice doesn’t know. Accordingly, she doesn’t own and cannot consume the resource.
Potential Solutions
I believe this problem is solved by the identity Architecture, i.e., by creating a compositional identity holding both private keys.
However, we don’t have an implementation of the identity architecture yet and this isn’t part of the product requirements for v0.2 (old, new).
To still achieve
Align protocol adapter RM with RM in specs v0.2 + FFI calls
there could be two solutions
- Implement ECDSA secp256k1 in Anoma/Juvix and temporarily replace Ed25519
- Implement ECDSA secp256k1 and compositional identities in Anoma/Juvix.
Both would allow Alice to consume her resource on Anoma.
However, for 2.), I still don’t understand how the unwrapping of an ERC20 resource owned by a compositional identity would work.
How does the protocol adapter decide to which address it sends the unwrapped tokens to?