QnA

Mitum's account abstraction introduces new concepts that might be confusing at first. To clarify these, we will explain frequently misunderstood concepts in a Q&A format.

1. Transaction(Operation) vs UserOperation

2. What is a Proxy Payer?

3. What is an Operation Sender?

4. What is an Alternative Signing?

5. How Are Invalid UserOperation Signatures Handled?

1. Transaction(Operation) vs UserOperation

UserOperation is a specialized operation in the Mitum blockchain that supports Account Abstraction (AA). Compared to a standard operation, it has the following differences:

  1. Signing and Submission

    • Standard Operation: The user signs the operation directly and submits it to the network. The executing entity must pay the transaction fee.

    • UserOperation: Instead of the user signing it directly, an op_sender signs and submits it to the network on behalf of the user.

  2. Fee Payment Method

    • Standard Operation: The executing entity is responsible for covering the transaction fee.

    • UserOperation: The fee can be paid by either a proxy_payer or the op_sender.

  3. Structural Differences

    • Like a standard operation, fact (execution data) and signs (signature information) are included.

    • However, UserOperation has an additional extension field that contains extra information required for account abstraction.

By utilizing UserOperation, the Mitum blockchain enables more flexible and efficient transaction execution through account abstraction.

2. What is a Proxy Payer?

A Proxy Payer is an account that covers the fees for account abstraction operations. It is essentially a contract account(CA), which can have a registered contract model or none at all. In the Mitum network, contract accounts can hold currency, which can be allocated at creation or funded later through transfers.

The Proxy Payer covers the fees for the Sender specified in the Fact of a User Operation.

Therefore, for the Proxy Payer to process the fee payment, the Sender must first be registered as a Recipient of the Proxy Payer. This can be done using the updateRecipient() function, but note that only the contract owner has permission to execute this function.

However, using a proxy payer in userOperation is not required in the current system.

3. What is an Operation Sender?

In Mitum’s account abstraction, the Operation Sender is the entity responsible for signing a user’s User Operation on their behalf and submitting it to the node.

Currently, if a proxy_payer is not specified in UserOperation, the account specified in op_sender is also responsible for covering the transaction fees.

4. What is an Alternative Signing?

In Mitum Account Abstraction, Alternative Signing refers to a signing method that allows a user operation (userOperation) to be considered valid even if the signer is not the direct owner of the private key traditionally associated with the account.

In a typical transaction, signing must be done directly using the private key of the account. However, in Mitum Account Abstraction, users can register DID Authentications in advance to verify the user operation's subject, enabling alternative signing.

A. Asymmetric Key-Based Authentication

  • Users register an asymmetric key-based (e.g., ECDSA) public key in their DID Authentication.

  • This public key allows users to prove their identity in account abstraction operations.

Example - A sample Mitum DID Authentication format (asymmetric key)

{
  "_hint": "mitum-did-asymmetric-key-authentication-v0.0.1",
  "id": "did:mitum:0xF032496440AC975D383C459D6C830186D2C0EaE9fca#auth_key",
  "authType": "EcdsaSecp256k1VerificationKey2019",
  "controller": "did:mitum:0xF032496440AC975D383C459D6C830186D2C0EaE9fca",
  "publicKey": "02bb41168240ca6a2b74f130ba3760204b494fba7381d25bcde601d7c39185df25fpu"
}

The user (0xF0...) can generate a UserOperation using one of their authentication, “did:mitum:0xF0...#auth_key”.

To validate this operation, an alternative signature must be provided using the private key corresponding to the registered public key (02bb...).

B. Social Login / Biometric Authentication

  • Users register a Verifiable Credential in their DID Authentication and specify a verifier’s authentication method for validation.

  • The verificationMethod field in the proof section of userOperation can reference another DID Authentication ID.

  • If the user's authentication (e.g., social login or biometric verification) is valid, the verifier signs the user operation using the private key that corresponds to its registered authentication public key.

  • Ultimately, even when using social login or biometrics, the system must reference an asymmetric key-based DID Authentication for verification.

Example - A sample Mitum DID Authentication format (social login)

{
  "_hint": "mitum-did-social-login-authentication-v0.0.1",
  "id": "did:mitum:0xF032496440AC975D383C459D6C830186D2C0EaE9fca#social_login",
  "authType": "VerifiableCredential",
  "controller": "did:mitum:0xF032496440AC975D383C459D6C830186D2C0EaE9fca",
  "serviceEndpoint": "https://google.com/",
  "proof": {
      "verificationMethod": "did:mitum:0x4526f3D0EdC63D9EaeCD94D56551e0f061CFCa47fca#auth_key"
  }
}

The user (0xF0...) generates a userOperation using their authentication “did:mitum:0xF03...#social_login” and sends it to a verifier (0x45...) along with their authentication proof. The verifier checks whether the user's authentication method (e.g., social login or biometric verification) is valid. If verified, the verifier signs the userOperation using the private key corresponding to its authentication public key, registered under “did:mitum:0x45...#auth_key”.

5. How Are Invalid UserOperation Signatures Handled?

In Mitum's account abstraction, when either the Op sender's signature is invalid or the alternative signature is invalid, the blockchain node reverts the UserOperation and returns different error messages depending on the case.

To distinguish between these cases, the SDK assigns separate error codes, categorized as follows:

Invalid Operation Sender's Signature

  • Error Code: P06D201

  • Blockchain Node Error Message:handle new operation: PreProcess: Invalid signing: threshold; Unknown key found, 02e7...fpu

  • Description: This occurs when the private key used for signing does not match the account address specified in the op_sender field within the settlement section of the UserOperation. This is similar to a standard invalid signature error for regular transactions.

Invalid Alternative Signature

  • Error Code: P06D202

  • Blockchain Node Error Message:

    handle new operation: PreProcess: signature verification

  • Description: This error occurs when the alternative signature in the UserOperation is invalid.

    The blockchain node checks the extension.authentication field and retrieves the authentication_id from the DID-Registry contract specified in the contract field:

    • If the authentication_id follows an asymmetric key-based approach, the signature must be created using a private key that matches the registered public key. Otherwise, the operation fails.

    • If the authentication_id is a Verifiable Credential (VC), the node follows the verificationMethod reference to retrieve another authentication_id. The signature must then be verified against the public key associated with this referenced authentication_id. If the signature does not match, the operation fails.

Previous<UserOpseration>.sign(privateKey)

Last updated