Discover How Social Recovery Works For Account Abstraction Wallets

Portkey Verifier Leverages Human Social Connections to Simplify Account Recovery

Web3 and blockchain technology have the transformative potential to reshape fundamental aspects of the digital landscape. By introducing decentralised, trustless, and transparent systems, they empower individuals and communities to take control of their digital interactions. Web3 promises to replace intermediaries with smart contracts and decentralised applications, fostering greater peer-to-peer collaboration and reducing reliance on centralised authorities.

With its potential to revolutionise finance, supply chains, digital rights management, and more, Web3 and blockchain technology establish themselves as the fundamental cornerstones of a more equitable, democratic, and efficient digital future.

Nevertheless, it’s crucial to acknowledge that while our expectations for the technology are high, perfection has yet to be achieved. Ongoing challenges related to security and usability remain significant barriers to widespread adoption.

The Dilemma of Security and Usability with EOA

Externally owned accounts (EOAs) are the most common type of accounts on blockchains, and private keys control them. Users must keep their private keys safe and secure to access their assets. However, it’s not uncommon for users to lose their private keys and, consequently, their entire accounts in Web3.

Security and usability often conflict. Solutions that enhance security often make wallets more challenging to use. For example, hardware storage is more secure than a hot wallet that stores the private key in the app. However, it requires a user to connect an additional device to the wallet app, and users need to back up their accounts by writing 12 or 24-word seed phrases. The downside is that it’s less convenient, creates more burden on users, and sacrifices the user experience. While MPC wallets offer an alternative for securing private keys, the solution often involves intricate set-up and configurations, rendering it less accessible to the average individual.

A Novel Approach: Social Recovery

To make Web3 accessible to the masses, we must address these challenges. In this article, we will explore Portkey’s innovative concept of social recovery, which aims to balance security and usability for abstracted accounts on aelf. We’ll also explain the role of Portkey Verifiers and how they help realise the social recovery mechanism.

What is Portkey

Portkey is the first account abstraction (AA) wallet on aelf to feature a decentralised identity (DID) solution. It introduces a social recovery mechanism, allowing Web3 accounts to be protected by existing Web2 accounts. This approach streamlines users’ transition from Web2 to Web3 and removes the need to memorise seed phrases typically used by EOAs. Portkey addresses the fundamental dilemma of balancing security and usability by eliminating this hurdle.

How Does Social Recovery Work?

Overcoming the Limitation of EOAs

First, we must understand the limitations of EOAs, where each address is tied to one private-public key pair. This is solved by using abstracted accounts governed by code and allowing customised logic.

Implementing Social Recovery

Through the smart contract used by AA wallets, we can encode social recovery rules. The social recovery mechanism involves the concept of “guardian” — Web2 accounts such as those of one’s family and friends — which serves to validate the account owner’s real-world identity.

When logging in, guardians receive requests to approve the action. The operation can only be performed with approval from a specific share of the total guardians assigned to the account. This mechanism leverages human social connections, which are more intuitive than random seed phrases. As a result, it eases the burden of safeguarding accounts. The following diagram offers an overview of the components involved to realise social recovery for Portkey’s wallet.

Portkey Verifier

We will delve further into the Portkey verifiers, which are critical in the approval process linked with social recovery. These verifiers provide different verification methods like Email, SMS OTP, Google, or Apple. Users have the flexibility to choose the preferred verifiers for each guardian, empowering them to customise the level of their wallet’s decentralisation and security. Let’s explore the specific scenarios in which verifiers come into play.

Registration

When a user enters the application without an account, they must create an AA account. This involves selecting an initial guardian from four types: Email, Phone Number, Apple Account, or Google Account.

Registration using Email / Phone Number

The following sequence diagram captures the registration process flow using email or phone number as the guardian type.

1 . Choose verifier

After choosing the guardian type, the user is then prompted to select a verifier for guardian verification.

2 . Request for verification

A guardian is configured correctly when an email or phone number is paired successfully with a corresponding verifier. To complete the setup, the user initiates an initial verification request. This process mirrors the familiar steps taken when creating a Web2 account but is executed via the decentralised verifier. Upon receiving the request, the verifier will send a code to the email or phone number.

3 . Complete verification

A subsequent message containing the user’s input for the verification code is sent. The verifier checks this code to ensure it is correct, confirming that the user can be reached via the associated email address or phone number. Once the verification is completed, the guardian is valid.

4 . Register an abstracted account on aelf chain

Once verification is successful, the verifier issues a cryptographically verifiable proof. The user’s email or phone number and the selected verifier will be registered as the guardian for the created abstracted account. Another detail included in the registration is the manager’s info created by the device. It is used for handling regular operations on behalf of the account. Essentially, it signs the transactions.

Registration using Apple / Google

The following sequence diagrams capture the registration process flow using a Google or Apple account as the guardian type.

1 . Authentication via Apple / Google account

If the user chooses Apple or Google as their initial guardian type, the user will be sent to the respective login page for Apple or Google authentication.

They then need to log in with their Apple or Google credentials to proceed.

2 . Choose verifier

Once login is successful, an identity token will be issued by Apple or Google. Users would be redirected to the application with the token and prompted to choose a verifier.

3 . Verify identity token

The identity token is then sent to the selected verifier to verify its validity.

4 . Register an abstracted account on aelf chain

Once verification is successful, the verifier will issue a cryptographically verifiable proof. The user’s Apple or Google ID and the selected verifier will be registered as the guardian for the created abstracted account.

Adding More Guardians

After completing the registration process, the user’s account is protected by a designated guardian. For enhanced security, the user has the option to add additional guardians. Like registration, the new guardian must be accompanied by valid verification proof, and the approval process follows the same verification procedures previously outlined.

Since an existing guardian already safeguards the account, approval must be obtained from the user and the guardian before adding new guardians. All additional guardians will require approval from the user and the account’s existing guardians.

Social Recovery / Login

On Portkey, social recovery is implemented for users to log into their accounts. A user can log into his account via his guardians. The following diagrams show how the flow works. Every account needs a login guardian as the identifier of the AA account. The user needs to provide the info of this login guardian so that the AA account info can be retrieved. One piece of important information required is the list of guardians. The user needs approval from a certain number of guardians to log into their Portkey account.

Like other operations mentioned above, this approval process follows the same verification procedures. Once the required approvals are obtained, a transaction can be executed in the AA contract on the aelf blockchain. This operation will register a newly created manager (a random private key securely stored on the device) in the AA account.

Social Recovery Rule

Let’s explain a bit about the social recovery rule. While users are able to customise their social recovery rules, there’s a default one provided by Portkey. According to the default rule, if the number of guardians added to the account is 3 or less, all guardians must approve the login process to succeed. If 4 or more guardians are configured for the account, three-fifths of the total plus one will be needed.

For example, if 4 guardians are added, 3 are required to approve. If 5 guardians are added, 4 are required to approve. With the approval from the quorum of guardians, the managers can be removed and added, hence achieving the account’s recovery.