This was originally published on Medium.

When the first iPhone came out, it had limited functionality so there was a software called Cydia to “jailbreak” and download extra apps outside of the AppStore. Apps such as Camcorder and the flashlight were used to bypass the operating system. It allowed for composability and let the developers/users build and access what is really possible.

I came across Account Abstraction (AA) after playing with the Starkware/Cairo ecosystem. When I created my first wallet on ArgentX and Bravos, I deployed a contract account which was confusing at first but interesting. It made me think of Cydia and the composability of web3 accounts. This led me to a deeper dive.

Currently, in Ethereum, there are two types of accounts: Externally Owned Account (EOA) and Smart Contracts. EOAs are controlled by the user’s private key and smart contracts perform actions based on their code. However, users of the past few years have realized the challenges with EOAs.

1. Users must have ETH to pay for gas from an EOA.

2. If you lose your private key, your funds are lost forever.

3. Seed phrases are terrible UX.

4. Phishing attempts via links and social engineering

These challenges are difficult for both new and existing users so, over the past few years, Vitalik and many others have discussed means to improve this through AA.

AA decouples the relationship between the EOAs and smart contracts and abstracts them to just smart contracts. The new flow will enable smart contract wallets to perform composable actions. AA will allow for wallets/users to perform:

Social Recovery: Users can assign 2 or more guardians to recover their wallets. They vouch for you and then you are given access to your account. A web2 example is WeChat and Argent for web3.

Improved security: Similar to social recovery, multi-signature management (with n+1) signers like Gnosis Safe, will help accounts be more secure. I.e If you have 3 signers and set 2 minimum, this adds extra security and steps to the movement of funds.

Atomic/batch user operations: Batch the calls to call multiple functions (i.e approve and swap a token in the same tx). There are implications for higher gas costs though.

Custom Signature Schemes: The current signing of ECDSA is a good standard over time, wallets, users and protocols may want to upgrade or use other signature schemes such as BLS and Schnorr.

Paymasters: As part of EIP-4337, a paymaster can be delegated to pay for the transaction. This could unlock the sponsoring of gas fees for the first n number of transactions, pay in another currency apart from ETH, onboard users through a debit/credit card on-ramp, and more.

These new features and possibilities jailbreak the current way EOAs operate and unlock the doors to better security and UX patterns. We will be able to see creative implementations of signing, batch calls, and paymaster actions.

A great write-up on the history of AA can be found here by Ismael Darwish from Nethermind.

The Ethereum ecosystem has been thinking about AA for a long time and the above diagram + history by Ismael Darwish illustrates the progression.

• EIP-86: Introduce smart contracts as “forwarding contracts” and accept transactions from an “entryPoint” address. It was not implemented due to core protocol change requirements.

• EIP-1014: Advancing EIP-86 with the proposition of CREATE2 opcode. This allowed interactions to be made with addresses that do not exist yet on-chain but can be relied upon in the future. This was merged in 2018.

• EIP-2938: Smart contracts identified as smart contract wallets would accept AA-type transactions. Required various core protocol changes and it was not implemented.

• EIP-3074: In 2020, the introduction of two new opcodes: AUTH and AUTHCALL. When used together, they allow a smart contract to send a transaction on behalf of an EOA. Some security risk/debates so it was not implemented.

This timeline indicates that the AA progression has not happened overnight and a lot of thought has gone into how to improve and create this implementation.

In September 2021, Vitailk, OpenGSN, and Nethermind proposed EIP-4337 — Account Abstraction via Entry Point Contract specifications. The EIP caters to AA without needing core protocol changes.

This is achieved by:

1. Sending UserOperation objects through the specific mempool.

2. Packaged into a single transaction via a Bundler who will be rewarded. This then calls an entryPoint contract for verification

3. If all is successful, it is included in a block.

Within the Bundle Transaction, an entryPoint smart contract is called which verifies the userOperations and then executes upon them. This can be further extended with the Paymaster who pays for X amount of stake for the bundled transaction.

This is quite a mouthful so for those interested, the original EIP spec can be found here.

L2 networks have the opportunity to rebuild their systems from the core which is a great benefit and explore AA. Networks such as ZKSync and Starkware, have natively built AA into the core. This means more native UX and security experiences. Below are some statements from their documentation that explains their approach toward AA.

On ZkSync:

Accounts in zkSync 2.0 can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract.

The design in spirit is similar to the EIP4337. For the simplicity of the implementation, some features from the original standard are removed and will be added later on to the testnet.

On Starknet:

A user can define what they want their account to “be”. For many users, an account contract will perform a signature check and then call the destination

The implication of having AA natively built into the network allows users to natively understand all accounts are smart contracts. This is an easier learning curve compared to Ethereum’s: EOA + Smart Contract + EIP-4337.

AA is not new but it is exciting. Being able to build these Cydia-like features on top of contract accounts will jailbreak new possibilities. There is still no definite answer that Ethereum will take but there seem to be a few future scenarios where:

1. EIP-4337 is widely adopted and we push towards a universal standard. Have yet to see many exchanges on Ethereum.

2. Native-built AA on L2 networks such as ZkSync and Starkware will push it for better adoption and people are onboarded easily here.

3. A hybrid approach where people are onboarded to L2s and then use ETH L1s.

Will be interesting to see the future of smart contract accounts and see web3 Cydia jailbreaking unfold.

Looking to start writing more and deciding between substack or Mirror but please stay subscribed to stay updated!

subscribe://

This was originally published on Medium.

When the first iPhone came out, it had limited functionality so there was a software called Cydia to “jailbreak” and download extra apps outside of the AppStore. Apps such as Camcorder and the flashlight were used to bypass the operating system. It allowed for composability and let the developers/users build and access what is really possible.

I came across Account Abstraction (AA) after playing with the Starkware/Cairo ecosystem. When I created my first wallet on ArgentX and Bravos, I deployed a contract account which was confusing at first but interesting. It made me think of Cydia and the composability of web3 accounts. This led me to a deeper dive.

Currently, in Ethereum, there are two types of accounts: Externally Owned Account (EOA) and Smart Contracts. EOAs are controlled by the user’s private key and smart contracts perform actions based on their code. However, users of the past few years have realized the challenges with EOAs.

1. Users must have ETH to pay for gas from an EOA.

2. If you lose your private key, your funds are lost forever.

3. Seed phrases are terrible UX.

4. Phishing attempts via links and social engineering

These challenges are difficult for both new and existing users so, over the past few years, Vitalik and many others have discussed means to improve this through AA.

AA decouples the relationship between the EOAs and smart contracts and abstracts them to just smart contracts. The new flow will enable smart contract wallets to perform composable actions. AA will allow for wallets/users to perform:

Social Recovery: Users can assign 2 or more guardians to recover their wallets. They vouch for you and then you are given access to your account. A web2 example is WeChat and Argent for web3.

Improved security: Similar to social recovery, multi-signature management (with n+1) signers like Gnosis Safe, will help accounts be more secure. I.e If you have 3 signers and set 2 minimum, this adds extra security and steps to the movement of funds.

Atomic/batch user operations: Batch the calls to call multiple functions (i.e approve and swap a token in the same tx). There are implications for higher gas costs though.

Custom Signature Schemes: The current signing of ECDSA is a good standard over time, wallets, users and protocols may want to upgrade or use other signature schemes such as BLS and Schnorr.

Paymasters: As part of EIP-4337, a paymaster can be delegated to pay for the transaction. This could unlock the sponsoring of gas fees for the first n number of transactions, pay in another currency apart from ETH, onboard users through a debit/credit card on-ramp, and more.

These new features and possibilities jailbreak the current way EOAs operate and unlock the doors to better security and UX patterns. We will be able to see creative implementations of signing, batch calls, and paymaster actions.

A great write-up on the history of AA can be found here by Ismael Darwish from Nethermind.

The Ethereum ecosystem has been thinking about AA for a long time and the above diagram + history by Ismael Darwish illustrates the progression.

• EIP-86: Introduce smart contracts as “forwarding contracts” and accept transactions from an “entryPoint” address. It was not implemented due to core protocol change requirements.

• EIP-1014: Advancing EIP-86 with the proposition of CREATE2 opcode. This allowed interactions to be made with addresses that do not exist yet on-chain but can be relied upon in the future. This was merged in 2018.

• EIP-2938: Smart contracts identified as smart contract wallets would accept AA-type transactions. Required various core protocol changes and it was not implemented.

• EIP-3074: In 2020, the introduction of two new opcodes: AUTH and AUTHCALL. When used together, they allow a smart contract to send a transaction on behalf of an EOA. Some security risk/debates so it was not implemented.

This timeline indicates that the AA progression has not happened overnight and a lot of thought has gone into how to improve and create this implementation.

In September 2021, Vitailk, OpenGSN, and Nethermind proposed EIP-4337 — Account Abstraction via Entry Point Contract specifications. The EIP caters to AA without needing core protocol changes.

This is achieved by:

1. Sending UserOperation objects through the specific mempool.

2. Packaged into a single transaction via a Bundler who will be rewarded. This then calls an entryPoint contract for verification

3. If all is successful, it is included in a block.

Within the Bundle Transaction, an entryPoint smart contract is called which verifies the userOperations and then executes upon them. This can be further extended with the Paymaster who pays for X amount of stake for the bundled transaction.

This is quite a mouthful so for those interested, the original EIP spec can be found here.

L2 networks have the opportunity to rebuild their systems from the core which is a great benefit and explore AA. Networks such as ZKSync and Starkware, have natively built AA into the core. This means more native UX and security experiences. Below are some statements from their documentation that explains their approach toward AA.

On ZkSync:

Accounts in zkSync 2.0 can initiate transactions, like an EOA, but can also have arbitrary logic implemented in them, like a smart contract.

The design in spirit is similar to the EIP4337. For the simplicity of the implementation, some features from the original standard are removed and will be added later on to the testnet.

On Starknet:

A user can define what they want their account to “be”. For many users, an account contract will perform a signature check and then call the destination

The implication of having AA natively built into the network allows users to natively understand all accounts are smart contracts. This is an easier learning curve compared to Ethereum’s: EOA + Smart Contract + EIP-4337.

AA is not new but it is exciting. Being able to build these Cydia-like features on top of contract accounts will jailbreak new possibilities. There is still no definite answer that Ethereum will take but there seem to be a few future scenarios where:

1. EIP-4337 is widely adopted and we push towards a universal standard. Have yet to see many exchanges on Ethereum.

2. Native-built AA on L2 networks such as ZkSync and Starkware will push it for better adoption and people are onboarded easily here.

3. A hybrid approach where people are onboarded to L2s and then use ETH L1s.

Will be interesting to see the future of smart contract accounts and see web3 Cydia jailbreaking unfold.

Looking to start writing more and deciding between substack or Mirror but please stay subscribed to stay updated!

subscribe://