| aip | title | author | Status | type | created |
|---|---|---|---|---|---|
113 |
Domain-based Account Abstraction |
igor-aptos, lightmark |
Draft |
Framework |
02/14/2024 |
Domain-based Account Abstraction (Domain AA) extends the existing Account Abstraction (AA) framework on Aptos by enabling authentication based on domains.
This allows registering secondary authentication schemes (as an alterantive to native Ed25519), with identical user experience to it. Rather than having each user register it's own authentication function, Domain AA allows for registering a full domain of addresses to be authenticated with same authentication function. That avoids a need for each account to have a different starting authentication and to need to initialize AA (from it). This allows providing a more flexible and secure way to manage cross-chain signatures. This approach also allows for deterministic account address generation based on the account_identity and function_info of the domain.
How to properly design an domain AA authentication function/module is out of scope.
In Domain AA, authentication is scoped to a domain. You can register an authentication function, which then creates a domain. The authentication logic is not tied to a specific account but instead relies on the domain and account identity. Here's how it works:
- The user provides an
account_identity, which is included in the authentication data (auth_data). - Based on the
account_identityand the associatedfunction_info, the system derives an account address for authentication. - The
function_infoused for authentication must be registered in a global whitelist. - If the authentication data matches the domain’s registered logic, the system authenticates the account and authorizes the transaction.
This domain-scoped approach allows for registering different authentication schemes, as an alternative to Ed25519, enabling more advanced use cases such as cross-chain integration or different authentication schemes.
Currently, registering a new authentication function and domain with it is made to require governance proposal, to make sure more scrutiny is placed on those, as they generate an alternative to native Ed25519. Whether to require governance long term or not, is something to be figured out.
- Enhanced Flexibility: By decoupling authentication from specific account addresses, Domain AA enables domain-specific authentication logic, making it possible to implement complex workflows.
- Cross-chain Compatibility: This method enables seamless cross-chain signature integration, where external accounts can authenticate on Aptos by deriving the correct address from their
account_identityand the domain'sfunction_info. - Scalability: Domains are designed to scale, allowing multiple authentication schemes across different use cases without requiring per-account configuration.
Domain AA introduces the following features:
- Cross-Chain Authentication: The ability to authenticate external accounts from other chains through a domain-specific authentication function, where each domain is associated with a unique signing method.
- Multi-Domain Flexibility: Allows multiple authentication schemes to coexist within different domains, enabling a more granular control over permissions and access rights.
The DomainDispatchableAuthenticator is a resource that manages authentication functions for a specific domain. This resource at @0x1 holds a whitelist of authentication functions that can be used by accounts within the domain.
#[resource_group_member(group = aptos_framework::object::ObjectGroup)]
/// Domain-scoped authenticator that defines how to authenticate accounts in the specified domain.
/// An integral part of Domain Account Abstraction.
enum DomainDispatchableAuthenticator has key {
V1 { auth_functions: BigOrderedMap<FunctionInfo, bool> }
}The sender account address of domain AA is derived based on the account_identity and the function_info for the domain.
#[view]
/// Derives an account address for Domain AA based on the module address, function name, and account identity.
public fun domain_aa_account_address(
module_address: address,
module_name: String,
function_name: String,
account_identity: vector<u8>
): address {
let function_info = function_info::new_function_info_from_address(module_address, module_name, function_name);
let bytes = bcs::to_bytes(&function_info);
bytes.append(bcs::to_bytes(account_identity));
bytes.push_back(DOMAIN_ABSTRACTION_DERIVED_SCHEME);
from_bcs::to_address(hash::sha3_256(bytes))
}Domain AA shares the same flow with normal AA in native code but diverge when it comes to move code. When calling 0x1::account_abstraction::authenticate, if the auth_data is using domain AA,
- The
account_identityin theauth_datais used to derive the account address. - The derived address is checked against the domain’s whitelist to verify if the function_info exists in the domain’s registered functions.
- If the identity matches and the function exists, the account is authenticated by the corresponding function as normal AA.
fun authenticate(
account: signer,
func_info: FunctionInfo,
signing_data: AbstractionAuthData,
): signer acquires DispatchableAuthenticator, DomainDispatchableAuthenticator {
let master_signer_addr = signer::address_of(&account);
if (signing_data.is_domain()) {
let func_infos = &borrow_global<DomainDispatchableAuthenticator>(@aptos_framework).auth_functions;
assert!(func_infos.contains(&func_info), error::not_found(EFUNCTION_INFO_EXISTENCE));
assert!(master_signer_addr == domain_aa_account_address(func_info, signing_data.account_identity()), error::invalid_state(EINCONSISTENT_SIGNER_ADDRESS));
} else {
assert!(using_dispatchable_authenticator(@aptos_framework), error::not_found(EDISPATCHABLE_AUTHENTICATOR_IS_NOT_USED));
let func_infos = &borrow_global<DispatchableAuthenticator>(resource_addr(master_signer_addr)).auth_functions;
assert!(ordered_map::contains(func_infos, &func_info), error::not_found(EFUNCTION_INFO_EXISTENCE));
};
function_info::load_module_from_function(&func_info);
let returned_signer = dispatchable_authenticate(account, signing_data, &func_info);
assert!(master_signer_addr == signer::address_of(&returned_signer), error::invalid_state(EINCONSISTENT_SIGNER_ADDRESS));
returned_signer
}The above PR has smoke test for domain AA.
- Complexity: Managing domains and authentication functions requires clear governance and can introduce additional complexity for both developers and users.
- Gas Limitations: As with the original AA system, complex authentication functions may hit gas limits, which could restrict certain use cases.
- External Dependence: Relying on external signatures and domains for cross-chain interactions means that vulnerabilities in the external systems could affect the security of the Aptos network.
- Cross-chain Signatures: Since this model allows external accounts to authenticate using domain-specific signatures, it is crucial to prevent unauthorized access. Specifically, account_identity should be securely handled to ensure that impersonation is not possible. This is mitigated by using the whitelist mechanism and by ensuring that the derived account address corresponds to the correct identity.
- Governance: The governance process for adding and removing authentication functions in the domain’s whitelist ensures that only authorized signatures are used. Mismanagement of governance could lead to unauthorized functions being added to the whitelist, posing security risks for users using those domains.
Feb 2025
March 2025
March 2025