nativesca

README

Account Abstraction Zone

This repository hosts native-scad, the implementation of a Cosmos zone with native CosmWasm contract account. It is a blockchain built using Cosmos SDK and CometBFT and created with Ignite CLI.

What is Account Abstraction?

Account Abstraction (AA) is one of the hottest trends of the blockchain world in early 2023. It is seen as a core technology to help achieve Web3 mass adoption, bridging the gap between Web2 and Web3. So what exactly is it, and how can it help achieve this mass adoption?

Account Abstraction is a proposal to increase flexibility in the management and behavior of Ethereum accounts. Can achieve this by introducing account contracts: special-purpose smart contracts that define and manage a user’s Ethereum account. AA was first proposed by Vitalik Buterin, when he and his colleagues noticed some limitations in Ethereum's Account model.

Currently, Accounts on Ethereum are divided into two types:

• Externally Owned Account (EOA): Ethereum account generated using wallet software (like MetaMask) and managed by a cryptographic pair of public and private keys. An EOA is “active” (it can initiate transactions and pay gas fees for EVM execution). However, it is limited to executing basic operations—like sending Ether or interacting with contracts.

• Contract Account (CA): Ethereum account deployed as a smart contract and controlled by logic written in code (instead of a private key). A contract account is “passive”: it can only send transactions in response to a transaction from an EOA and cannot pay gas fees. It is, however, programmable and can execute arbitrary logic depending on code stored at the address.

So, what are the limitations of this model?

EOA is the main account type of this model. All transactions on Ethereum must be initiated by the EOA. All protocols on Ethereum must be designed to interact with EOAs (While not many dApps support interaction with CAs). However, there is a single-point failure of this account type - the private key.

When creating an EOA on a wallet like Metamask, the wallet will randomly generate a 12 or 24 word English phrase, and then ask the user to record it and keep it in a safe place. This phrase is called a seed phrase. Seed phrases enable users to recover their private keys from the blockchain. They're the private keys presented in a human readable format. Private key/Seed phrase is the only way to access user's EOA account, loss of private key means loss of account and all tokens in that account. In this case, the user has no way to recover, already millions of dollars have been lost or stolen for reasons related to the private key.

EOA’s also pose a problem because as individual accounts, they can only put out single transactions which need to be verified creating gas fees each time.

Ultimately, with an EOA, there is little wiggle room or customization, as users can’t create custom logic to include more signers or authorize different keys to sign on to their accounts. This creates a very limiting scope for transactions. And this lead dApp users to a quite bad UX, and prevents mass Web3 adoption.

Therefore, we need an Account abstraction solution to solve the above problem.

The benefits of Account Abstraction?

With Account Abstraction, you can enjoy programmable access to funds by using a smart contract wallet instead of relying solely on private keys for security. This is possible because your smart account can have custom rules for spending coins and transferring assets.

Smart contract wallets already utilize Account Abstraction and can take advantage of all of its benefits. Here are some of those benefits explained:

• You can create/recover an account without the need of a seed phrase.
• You are able to pay transaction fees in ERC-20 tokens, or even without any fees (Gasless transactions). This means you no longer need ETH (or another chain’s native token) to do anything, which is very important for general crypto adoption.
• You are able to batch transactions. Generally, on Ethereum you cannot perform an action (or complete a transaction) if you have a pending one, and you would need to pay a fee for each transaction. Transaction batching means you can perform multiple transactions (or actions) simultaneously and save on gas fees too.
• Session keys are possible - this means that you do not have to sign in every time for a certain period. This can improve the experience of gaming for example.
• Smart contract wallets allow for you to add or remove signers. This allows a lot more granular control over the security of a wallet than an EOA wallet.

Further benefits include the ability to time delay transactions, to create custom rules (for example, set a spending limit), etc.

Account Abstraction on Cosmos

Currently, Cosmos does not have Account Abstraction. CosmWasm contracts also do not have the ability to initiate transactions. However, there is a positive that the Cosmos SDK already has some good AA material already in it. Batch transaction was achieved as multiple messages in one transaction. Gasless transactions can be done through the Feegrant module. Along with that, with a modular design, developing and integrating a module that enables native CosmWasm contract accounts into a Cosmos chain is much easier than Ethereum's monolithic design.

Architecture

Scope of the first x/nativesca version:

• Allow a Cosmos zone can create CosmWasm contract accounts with the native ability of initializing txns.

Run chain

Quick start with Ignite CLI

ignite chain serve

Run manually

Step 1: Install Nativesca daemon

make install

The nativescad bin file will be located on GO_PATH (default ~/go/bin/)

Step 2: Configuration

Setup the chain ID and keyring backend:

nativescad config chain-id demo
nativescad config keyring-backend test

Step 3: Key setup

nativescad keys add alice
nativescad keys add bob

Step 4: Chain setup

• Initialize the node:

nativescad init test --chain-id demo

This command will initialize the home folder containing necessary components for your chain (default: ~/.nativesca)

• Add Alice and Bob (with an initial balance for each account) to the genesis file:

nativescad add-genesis-account alice 5000000000stake --keyring-backend test
nativescad add-genesis-account bob 5000000000stake --keyring-backend test

• Add an account to the initial validator set

nativescad gentx alice 1000000stake --chain-id demo

• Add the validator transaction to the genesis file:

nativescad collect-gentxs

Step 5: Start chain

nativescad start