CUSTOMIZED-MULTI-SIG.md

Proposal For Native conditional multi-sig

Aptos account system

The Aptos account system is secure, but also flexible than any other blockchain, such as native key rotation, multi-sig are possible. So it has enormous potential.

We thought we could suggest a new authentication scheme and improve Aptos account experience. (As of a PoC service of On-chain conditional 2FA, please refer the github link)

Native customized multi-sig

As a new authentication method, we propose native customized multi-sig.

What is required to validate transaction in Aptos?

Making signed transaction requires Authenticator and RawTransaction

rawToSigned code

Validator should be able to verify that the signed transaction is correct. So client sdk should pass signed transaction with Authenticator and RawTransaction

• Authenticator: Manage the variables required for verification according to the transaction type

The type of Authenticator used depends on the type of transaction

Authenticator implementation code

• singleSig(TransactionAuthenticatorEd25519): manage public_key and signature derived by Ed25519
• multiSig(TransactionAuthenticatorMultiEd25519): manage public_key and signature derived by MultiEd25519
• multiAgent(TransactionAuthenticatorMultiAgent): manage sender, secondary_signer_addresses and secondary_signers

Basis of a proposal

1. Add new auth scheme in sdk: TransactionAuthenticatorConditionalMulti

Adding new auth scheme on both the client side and the node side is easy in Aptos. It has well structured and clean function interface. They're ready-to-be-added.

we want to implement an account with APTlimit.

So new authenticator(TransactionAuthenticatorConditionalMulti) will be implemented like this.

export class TransactionAuthenticatorConditionalMulti extends TransactionAuthenticator {
  constructor(
    public readonly primary_pubkey: Ed25519PublicKey,
    public readonly primary_signature: Ed25519Signature,
    public readonly secondary_pubkey: Ed25519PublicKey,
    public readonly secondary_signature: Ed25519Signature,
    public readonly apt_limit: number,
    public readonly apt_in_tx: number
  ) {
    super();
  }
  ...
}

• when apt_in_tx <= apt_limit, only check primary_pubkey and primary_signature
• when apt_in_tx > apt_limit, validators also need to check secondary_pubkey and secondary_signature

apt_in_tx can be added in Authenticator. Because Multiagent transaction uses the internal transaction information for authentication.

It means transferred APT in tx can also be used for authentication

2. Add new validating logic in validator

current validating transaction code

we will also implement new validating logic for conditional-multi-sig.

• validating primary_signature and secondary_signature can reuse verification logic used in Ed25519Signature
• if apt_in_tx <= apt_limit, don't need to validate secondary_signature

3. Propose new authentication key format: conditional-multi-sig

In Aptos, Multi-signer authentication key is shown as follows:

auth_key = sha3-256(p_1 | . . . | p_n | K | 0x01)

Similarly, we will propose a new address system

auth_key = sha3-256(primary_pubkey | secondary_pubkey | APT_limit | 0x02)

Impact on Aptos(Move)

Adopting conditional-multi-sig in Aptos-core will open various possibilities in Aptos.

• Conditional-Multi-sig can send transaction without restriction
• Conditional-Multi-sig can be used in DAO, Vault contract, etc ...
• Other account authentication methods can be added in Move contract layer