[NEAR Series] #2: NEAR’s FastAuth, A Game Changer for Blockchain Mass Adoption

Minwoo Nam | researcher of CURG| 01082249606nmw@gmail.com

Contents

[NEAR Series] #1: NEAR’s BOS, An Operating System for the Open Web

[NEAR Series] #2: NEAR’s FastAuth, A Game Changer for Blockchain Mass Adoption

TL; DR

FastAuth is an SDK that improves user experience by allowing users who previously found it difficult to create a wallet to easily use DApp services via email.

It offers social login features (enabling login via email registration, fingerprint, Facebook ID, etc.) and provides the ability to recover wallet keys via email.

In addition, the presence of the Relayer and FunctionCall key (a gas fee prepayment feature) allows users to use DApp services even without NEAR.

Through this, users can approach NEAR’s DApp services more easily and have a different experience without the distinction between Web3 and Web2.

In May 2023, a technology called FastAuth was newly launched by NEAR Protocol. In this article, we will take a closer look at NEAR’s FastAuth.

Current Problems in the Web3 Market

The current Web3 market is becoming increasingly entrenched due to an inconvenient user experience (UX) that tends to favor existing users. In other words, it’s “difficult” to use. One of the reasons it’s difficult is the process of creating a wallet.

Traditional Web2 users could easily log in with just an email and password. However, to use Web3 services, users need to install a wallet extension and memorize 12 mnemonic keys. They have to manually input these 12 words and then enter a password to create a wallet.

The following provides a summary of the challenges associated with Web3 onboarding, in terms of login and registration.

• There is a barrier to entry from the process of creating a MetaMask.
• The MetaMask wallet address is made up of a 32-character hash value like 0xasdasfasd123121…, which is impossible to remember.
• The mnemonic key obtained when creating MetaMask is also difficult to remember, and the private key is also composed of a hash value like 0xasdasfasd123121…
• If you lose the mnemonic key and private key, it is impossible to recover the assets. And to use the service, the user must pay the fee, not the platform.

Solutions for Improving User Experience (UX)

In the blockchain market, various solutions are emerging to solve these problems and improve UX.

Source: NEAR Protocol

Source: Biconomy

Source: Safe

Notable examples include FastAuth from NEAR Protocol and Biconomy and Safe in the ETH market.

NEAR’s Game Changer for Blockchain Mass Adoption: FastAuth

What is FastAuth?

FastAuth, created by NEAR, is a protocol that makes the user experience in the blockchain world easier. This protocol provides an onboarding process and account recovery process similar to Web2, making it easier for users to operate DApps. Also, this protocol is based on the NEAR protocol. The good news is that this protocol is expected to be open source, so developers can integrate it into their DApps.

FastAuth has introduced a new type of transaction, meta transactions, based on the ETH Improvement Proposal (EIP) standard ERC-2771. This transaction allows a third party to pay the gas fee on behalf of the user, solving one of the significant problems new users face in the blockchain world.

Features

• Social login (login possible with email registration, fingerprint, face ID, etc.)
• You can recover your wallet using the same process as the existing password recovery method.
• You can use DApps without gas fees through a relayer.
• You can log in and register immediately without installing an extension.

Therefore, through FastAuth’s account abstraction, users can log in with an email, and they don’t have to worry about managing private keys or paying transaction costs.

Let’s look at each feature technically.

NEAR WALLET

The key management of the NEAR Protocol wallet is completely different from that of the ETH wallet.

Implicit Accounts

Implicit accounts are similar to traditional Bitcoin/ETH accounts. These accounts are defined by a 64-character address, which corresponds to a unique ED25519 key pair.

An example of an account created with an ED25519 key pair and an implicit account when referred to can be:

The public key base58: BGCCDDHfysuuVnaNVtEhhqeT4k9Muyem3Kpgq2U1m9HX

Refers to the implicit account: 98793cd91a3f870fb126f66285808c7e094afcfc4eda8a970f6648cdf0dbd6de

Named Accounts

You can create short top-level accounts (less than 32 characters).
Long (32 characters or more) top-level accounts can be created by anyone.

• An account can only create sub-accounts directly below itself.
• Anyone can create a long top-level account (e.g., a very long account name with 32 characters). e.g) alice.near , alice.bob.near

NEAR WALLET KEY

NEAR’s keys consist of Full Access Keys and Function Call keys.

Full Access Keys

Full Access Keys are created as a new ED25519 key pair consisting of a private key and a public key. The private key is a random 32-byte number, and the public key is derived from the private key using an elliptic curve multiplication, a one-way function that is easy to calculate but difficult to reverse. The private key is kept secret and used to sign transactions, while the public key is shared publicly and used by others to verify signatures.

In simple terms, it’s like a combination of a Private Key and a Public Key in ETH.

Private Key + Public Key = Full Access Key

Permission: It has all the permission over the account, similar to having administrator rights in an operating system

Features

• Create sub-accounts
• Delete account (Sub-accounts each have a unique key, so they cannot be deleted)
• Add or delete Access Keys
• Deploy smart contracts within the account
• Call any contract method
• Transfer NEAR Ⓝ

Function Call Keys

Function Call Keys are ED25519 key pairs, but they are associated with additional metadata that restricts their use. This metadata includes the contract ID, method name, and allowance.
Function Call Keys issue a signature key according to the purpose, and only perform signatures for specific functions. The functions and permissions that can be signed by the key are limited, minimizing the risk of asset theft, and it is also possible for the user to generate and sign transactions without a wallet using this.

In simple terms, it’s a key created from Full Access Keys + Metadata (data that allows access only to specific functions).

Permission: It has permission to call specific functions without requiring the use of NEAR Ⓝ.

Metadata:

1. receiver_id: The contract that the key allows to call. You cannot call another contract using this key. (The account ID of the contract that the key can call)
2. method_names: The name of the function inside the contract that can be called with this key. If omitted, all functions are called. (Specific function that the key can call)
3. allowance: If you call without attaching NEARⓃ, the key only allows the call of the visible function. (The maximum amount of NEAR tokens that the key can use as gas fees)

So far, we have looked at how NEAR manages keys. Next, let’s look at how to log in and register with this key.

Social Login, Registration

Source: NEAR Protocol

Source: NEAR Protocol

Detail

1. The user sends a key creation request through FastAuth.
2. The wallet creation code is executed in the SDK corresponding to FastAuth.
3. Now the user enters the email and the name of the account used in name.near.
4. In addition, authenticate with fingerprints, face ID, other additional passwords, etc.
5. After the user’s verification is completed, the private key obtained above is stored on the device. (It’s not Full Access Keys.)
6. The wallet is created and a verification message is sent to the email entered at the time of creation.
7. After verifying from the email, create Full Access Keys + Private Key stored on the device together.
8. The wallet has been created.

Usually, signatures are often signed with a Private Key, but in the case of FastAuth signatures, the signature is performed by calculating the Pass key (Private Key) of the user’s device and the MPC (multi-party computation) on the NEAR server.

*This means that the private key is distributed and stored.

Let’s take a clearer and simpler look at the flow described above.

Actual Wallet Creation Process

There are three simple definitions of account creation. FastAuth is a seamless UX because it is very similar to the way Web2 creates accounts.

1. Enter email and password = Enter email and account name (slightly different, right?)
2. Enter authentication methods stored on the device (same)
3. Verify after sending an email (same)

You can see the same thing except that the password is the account name.

You can try to register as a member on the site below.

https://near.org/

The above said that it is impossible to recover if you lose your private key in the metamask. NEAR’s FastAuth, on the other hand, is easy to recover with email authentication.

Key Recovery Steps in FastAuth

Source: NEAR Protocol Youtube / Account Recovery with NEAR’s Fast Auth

The key recovery steps for FastAuth are as follows.

1. User loses key
2. FastAuth sends an authentication code to the email address registered when the account was created.
3. The key recovery process is initiated
4. The decryption of keys encrypted with recovered keys takes place.
5. The key can be replaced by initializing it.

Similarly, let’s compare it to Web2.

1. Email Authentication
2. Password reset, which is equivalent to key initialization in FastAuth.
3. Re-entering the password, which is similar to re-entering the key in FastAuth.

Next, let’s discuss Relayer, a feature that allows users to use DApps without worrying about gas fees.

Technologies that enable the use of the service at no charge (Non-GasFee)

In the case of FastAuth, two technologies allow users to send transactions (requests) without gas costs.

• FunctionCall Keys
• Meta Transaction(Relayer)

Let’s take a look at the process of making payments using Function Calls

As mentioned above, the payment account gives the user Function Call Keys, allowing the user to use the DApp services corresponding to the action without gas charges.

The process is as follows.

1. Account1, which sponsors DApp’s Gas Fee, grants Function Call Keys to users
2. User takes action corresponding to Function Call Keys
3. DApp side sends transaction corresponding to a user action to the blockchain network * At this time, DApp pays Gas-Fee

Now let’s take a closer look at the payment process with Meta Transaction and Relayer.

Meta Transaction is simply a form of putting actual transaction information within a transaction so that it can be signed on behalf of off-chain.

First, let’s define each player and start.

• User (Alice): Request Sender
• Relayer: Third-Party Paying Friend
• DelegateAction: Meta code recognizable by paying friends
• Another friend: the person who receives the reques

1. The user (Alice) creates and signs information about what to do and who signs it in the Delegate Action.
2. The user then sends the signed Delegate Action to a third party called the Relayer. This is done off-chain.
3. The relayer wraps the Delegate Action in the transaction and submits it to the blockchain. The relayer is the signatory to this transaction and therefore pays for the gas. If the token balance is attached to the internal action, it will also be paid by the Relayer.
4. In the blockchain, the signed delegate action inside the transaction is converted into an action receipt with the same signed delegate action in the shard of the Relayer.
5. This receipt will be delivered from you (Alice) to another friend.
6. This friend uncompresses the signed delegate action and uses valid nonces, etc. to verify that the user has signed it.
7. If all checks are successful, a new action receipt containing the internal action as the body is sent to the recipient, and the action is executed.

This allows users to execute transactions without paying for gas. The gas cost is borne by the Relayer. Relayers can provide services free of charge or charge you through other means.

Limitations of the Relayer

• Cost: The Relayer must pay for the gas for the transactions it relays. These costs must be charged to the user, covered by the DApp, or otherwise
• Central: Relay models can be implemented in a decentralized manner, but there is a risk of being centralized if a small number of relayers dominate the market. This could potentially lead to censorship or other problems
• Complexity: Implementing a relay model adds complexity to the system. Additional infrastructure and management are required, and additional points of failure can occur.
• Security: Like third-party services, there is a risk that malicious or corrupted Relayers can act in harmful ways, such as censoring transactions or attempting to steal user data.

More information can be found at the link below.
[NEP-366](https://github.com/near/NEPs/pull/366)

Comparison of AA (Account Abstraction) and FastAuth

Account Abstraction (AA) certainly provides social login services and pays for gas fees, but there are differences. Let’s briefly compare NEAR’s FastAuth, Biconomy, and Safe, which are currently representative.

From the perspective of whether they support gas fee payment solutions, personal key recovery services, social login, and multi-chain

Payment Solutions

FastAuth supports payments through Function Call Keys and Relayers. Safe, Biconomy supports payments through Relayers and Paymaster.

Key Recovery

FastAuth supports recovery services via email. Safe supports recovery services through MultiSig, which means users can recover keys by multiple accounts. and Biconomy supports personal key recovery through Web3Auth , ParticleAuth.

Social Login

FastAuth enables users to log in using their email addresses. On the other hand, both Safe and Biconomy provide support for social login services via Web3Auth. However, Biconomy demonstrates more comprehensive support for ParticleAuth.

Multi-chain Services: Currently, FastAuth only supports NEAR, while Biconomy and Safe support EVM-based tokens.

You can check at a glance through the table below.

For more details about Web3Auth and ParticleAuth, please refer to the link below.
What is Web3Auth? | Documentation
https://docs.particle.network/developers/faq

Next Action of FastAuth

• Expanding the functionality of Relayer and FastAuth beyond near.org as additional gateways
• Additional MPC decentralization (Applying private key MPC through FastAuth)
• Multi-chain compatibility
• Two-factor authentication

Conclusion

We’ve taken a look at FastAuth, introduced by NEAR, to solve the entry barriers for not only existing Web3 users but also Web2 users.
To solve the problem, many players are introducing UX improvement services, and there are currently payment solutions on ETH, such as registering a Paymaster Contract or paying for gas through Relayer.
NEAR supports both through its wallet structure and Relayer, and its efforts to improve the UX of DApps in the future stand out. They’re also working on social login and private key recovery. However, the centralization issues and cost, complexity, and security issues of Relayer mentioned earlier remain…

Reference

NEP-366: Meta transactions by ilblackdragon · Pull Request #366 · near/NEPs: https://github.com/near/NEPs/pull/366

Account Model | NEAR Documentation: https://docs.near.org/concepts/basics/accounts/model

Access Keys | NEAR Documentation: https://docs.near.org/docs/concepts/account#access-keys

Guide to Nearcore Development: https://near.github.io/nearcore/docs/

Key Management and Security | Documentation: https://web3auth.io/docs/

How to Relay Gasless Meta-Transactions — OpenZeppelin Docs:
https://docs.near.org/concepts/basics/accounts/model

Overview and Implementation Cases of Meta Transactions:
https://medium.com/luniverse/%EB%A9%94%ED%83%80-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B0%9C%EC%9A%94-%EB%B0%8F-%EA%B5%AC%ED%98%84-%EC%82%AC%EB%A1%80-93a131b8e5be