This project has released weekly updates since 2023.05.22.
ENS is a leading DID solution with the following characteristics.
Easy to remember and can be resolved into the blockchain address
Support multichain including Bitcoin, Dogcoin, etc
Various records including ADDRESSES
, CONTENT
, TEXT RECORD
, etc
Integrated by a large number of applications
Namewrapper is an elegant permission mechanism and makes all ENS domains become ERC-1155 NFTs.
However, ENS domain are mainly used as DID for offchain domain resolution while onchain operations are based on the resolved address instead of the ENS domain. Therefore, the resolved address is the real onchain ID.
Can we have a real ENS Ethereum account as our onchain ID?
Obviously, if account abstraction can be organically combined with ENS, then this problem can be solved. Everything will also become wonderful.
The ENS domain becomes a real ID both offchain and onchain
Just transfer ownership in the ENS APP, the account can be handed over automatically. Especially considering the features of SBT, EOA cannot achieve this. Also, ENS itself has a complete and flexible permission mechanism for setting the resolving address, which can meet the needs of the organizations.
Since the ENS domain is a ERC-1155 NFT, you can manage your account by operating the NFT.
After the launch of ENS Namewrapper, ENS has built-in flexible permission mechanism called fuse
. Therefore, the developer does not need to implement similar mechanism in the ENSAA account and can reuse the built-in permission mechanism of ENS.
ENSAA introduces more possibilities for recovery and security of the account. The various information on ENS is a potential source of account recovery and risk control. For example,
When the private key of the Ethereum address is lost, users can choose the private key of the Dogcoin address to continue using the ENSAA account, similar to the idea of the Ethereum client diversity.
For some high-risk operations on the account, verification can be achieved through multiple signatures of private keys in multiple chains.
According the rule of the fuse
, you can recover the ENSAccount
by its parant ens domain. For example,
ENSAccount
of staff.company.eth
by company.eth
.ENS also records social information (such as Twitter), providing the possibility of introducing social recovery and the keyless account.
Currently, ERC-4337 is a relatively mature account abstraction solution. At first glance, the developer only need to access ENS information during the ERC-4337 validation loop to achieve ENSAA's goals.
However, in order to prevent bundlers from being attacked, ERC-4337 restricts the account behavior during the ERC-4337 validation loop. One of the constraints is that account validation can only access storage associated with the account. Due to the fact that ENS information is stored outside of the account, this approach becomes infeasible.
This project innovatively solved this problem and achieved ENSAA that meets the ERC-4337 specification.
The basic idea is as follows
ENS domain name uses custom AAResolver
to record ENS information
When the information recorded by AAResolver
changes, callback the relevant ENSAccount
for sync.
Finally, The ERC-4337 validation loop of ENSAccount
only requires accessing ENSAccount
's own storage for verification.
However, forcing ENS domain to use custom AAResolver
is not feasible. Once the ENS domain switches to other Resolver
, the binding link of ENSDomain <-> AAResolver <-> ENSAccount
will be broken.
Therefore, this project introduces the fuses
mechanism of the ENS Namewrapper. When creating an ENSAccount
, ENSAccountFactory
will check the fuses of the ENS domain to ensure that once ENSAccount
is deployed, the ENS domain cannot switch to other Resolver
. Of course, the expiry of the ENS domain will also be considered to ensure the binding link of ENSDomain <-> AAResolver <-> ENSAccount
.
To be continued ...
The motivation of ERC-6551 is similar to ENSAA.
ERC-6551 cannot work properly under the framework of ERC-4337
ownerOf
method of ENS NFT is not allowed.ENSAA is more closely integrated with ENS and tries to utilize the permission mechanism of ENS and the information binding to the ENS
ENSAA can support ERC-6551 in the same time.