We do a little learning
0xhubman.ethAccount Abstraction - Part 2
Welcome back to part 2 of the Account Abstraction (AA)! Last post we covered the concept of AA, the benefits of AA, and the infrastructure needed to utilize SCAs in the manner proposed by ERC-4337. This week we'll take a look under the hood and discuss how ERC-4337's components actually interact with each other to make AA a reality. You'll remember that every transaction that occurs on Ethereum currently requires an EOA to initiate the transaction (by signing the transaction with a private ke...
0xhubman.ethStablecoins
For this post, we'll be diving into one of the crypto industry's most popular use cases - stablecoins. As of November 2023, USDT and USDC, the two biggest stablecoins by market cap, have a combined market cap of ~$110 billion within the crypto industry's entire $1.48 trillion market cap. However, this rise in popularity of stablecoins has not come without its controversies. If you've spent any amount of time following or participating in the crypto industry, you've no doubt seen the barrage o...
0xhubman.ethNostr
Tired of the Twitter/X drama? Don't know what the heck Mastodon is or how to use it? Do you like ostriches? Well then there is a protocol for you! In this post, we'll actually be veering off the blockchain-specific beaten path and delving into an exciting protocol that can best be described as crypto-adjacent - the Nostr protocol! Nostr (short for Notes and Other Stuff Transmitted by Relays) is an exciting protocol that aims to be a fully fleshed out decentralized social network and so much m...
0xhubman.ethAccount Abstraction - Part 2
Welcome back to part 2 of the Account Abstraction (AA)! Last post we covered the concept of AA, the benefits of AA, and the infrastructure needed to utilize SCAs in the manner proposed by ERC-4337. This week we'll take a look under the hood and discuss how ERC-4337's components actually interact with each other to make AA a reality. You'll remember that every transaction that occurs on Ethereum currently requires an EOA to initiate the transaction (by signing the transaction with a private ke...
0xhubman.ethStablecoins
For this post, we'll be diving into one of the crypto industry's most popular use cases - stablecoins. As of November 2023, USDT and USDC, the two biggest stablecoins by market cap, have a combined market cap of ~$110 billion within the crypto industry's entire $1.48 trillion market cap. However, this rise in popularity of stablecoins has not come without its controversies. If you've spent any amount of time following or participating in the crypto industry, you've no doubt seen the barrage o...
0xhubman.ethNostr
Tired of the Twitter/X drama? Don't know what the heck Mastodon is or how to use it? Do you like ostriches? Well then there is a protocol for you! In this post, we'll actually be veering off the blockchain-specific beaten path and delving into an exciting protocol that can best be described as crypto-adjacent - the Nostr protocol! Nostr (short for Notes and Other Stuff Transmitted by Relays) is an exciting protocol that aims to be a fully fleshed out decentralized social network and so much m...
We do a little learning
Share Dialog
Share Dialog
Subscribe to 0xhubman.eth
Subscribe to 0xhubman.eth
After much anticipation, the Account Abstraction (AA) primer post is here! AA is a hot topic within the Ethereum developer community and has been touted as one of the improvements that will help onboard the next wave of users to the Ethereum ecosystem. AA, as proposed by ERC-4337, can be defined as allowing users to use smart contract wallets (SCAs) containing arbitrary verification logic (i.e., programmable instructions) as their primary wallet instead of utilizing EOAs with a private key. So what does that mean in English? Let's look at a few examples below to help illustrate this definition.
If you've read a previous post, you'll remember that EOAs are the primary wallets used within the Ethereum ecosystem. EOAs revolve around the use of a private key. The private key to an EOA can be thought of as root access. The private key lets you have full control of the EOA, but if you lose the private key then the wallet becomes locked forever.
Enter AA with SCAs: Users do not need to rely on a singular all powerful private key. Instead their wallet can be pre-programmed with logic via the smart contract code. This method of transaction execution unlocks a whole new realm of possibilities for UX, such as:
Only allowing certain users to execute transactions from the wallet (helping avoid hacks)
Setting up transactions that occur on a pre-determined basis that do not require user input each time (i.e., auto-pay)
Only allow funds to be transferred to certain whitelisted addresses (this is currently possible with some wallet providers, but the logic lives at the wallet provider level, not the wallet itself)
Only allow certain assets to be transferred from the wallet (i.e., you have permission to transfer ETH but not your precious CryptoPunk)
Allow third-parties to sponsor transaction costs for certain SCAs
So that all sounds great, right? But how do all these new exciting use cases work under the hood? Excellent question! The infrastructure for AA, as outlined by ERC-4337, can be broken down into the following distinct components:
User Operations
Users with a SCA start the process by creating a User Operation (UserOp). UserOps are considered meta-transactions that represent a user's intent. They do not follow the format of a traditional transaction submitted for execution (since it is not coming from an EOA) and instead contain a set of instructions for the user's intent and additional metadata needed to execute the eventual smart contract function. Intents can be thought of as specifying what the final outcome of the UserOp should be (i.e., swap ETH for USDC). Traditional transactions are much more granular as they cover every step of the process to reach the final outcome (i.e., approve ETH for swapping, send ETH to Uniswap router, send back USDC).
Bundlers
Bundlers are EOAs that monitor off-chain/alternative mempools containing UserOps and bundle multiple UserOps together to form and initiate a singular standard transaction. These bundlers front the gas costs for these transactions consisting of UserOps.
EntryPoint
The EntryPoint smart contract is the central piece of this infrastructure, as this smart contract receives the transactions from the Bundlers, verifies the validity of the transactions and then forwards the various UserOps to the corresponding individual users' SCAs to execute
Paymaster
A Paymaster is a smart contract that oversees the implementation of gas payment policies for the entity that deployed the Paymaster (such as companies like Coinbase, Uniswap Labs, OpenSea, etc). These policies can cover what currency the transaction fees is paid with (i.e., users can pay with USDC instead of ETH) and by whom (i.e., the entity sponsors the transaction fee for users). This removes the requirement for every user to hold the blockchain's native gas token. Paymasters can be considered an optional piece of infrastructure given users could also just pay for their own gas.
Aggregator
An Aggregator is a smart contract that implements a signature scheme to support aggregation of multiple different signatures. The aggregator is another optional piece of infrastructure which helps save on gas costs by bundling multiple different wallet signatures together to execute multiple transactions at once.
After all that, this seems like a good stopping point. We'll save the nitty gritty of how all these components interact with each other for the next post.
Until next time!
After much anticipation, the Account Abstraction (AA) primer post is here! AA is a hot topic within the Ethereum developer community and has been touted as one of the improvements that will help onboard the next wave of users to the Ethereum ecosystem. AA, as proposed by ERC-4337, can be defined as allowing users to use smart contract wallets (SCAs) containing arbitrary verification logic (i.e., programmable instructions) as their primary wallet instead of utilizing EOAs with a private key. So what does that mean in English? Let's look at a few examples below to help illustrate this definition.
If you've read a previous post, you'll remember that EOAs are the primary wallets used within the Ethereum ecosystem. EOAs revolve around the use of a private key. The private key to an EOA can be thought of as root access. The private key lets you have full control of the EOA, but if you lose the private key then the wallet becomes locked forever.
Enter AA with SCAs: Users do not need to rely on a singular all powerful private key. Instead their wallet can be pre-programmed with logic via the smart contract code. This method of transaction execution unlocks a whole new realm of possibilities for UX, such as:
Only allowing certain users to execute transactions from the wallet (helping avoid hacks)
Setting up transactions that occur on a pre-determined basis that do not require user input each time (i.e., auto-pay)
Only allow funds to be transferred to certain whitelisted addresses (this is currently possible with some wallet providers, but the logic lives at the wallet provider level, not the wallet itself)
Only allow certain assets to be transferred from the wallet (i.e., you have permission to transfer ETH but not your precious CryptoPunk)
Allow third-parties to sponsor transaction costs for certain SCAs
So that all sounds great, right? But how do all these new exciting use cases work under the hood? Excellent question! The infrastructure for AA, as outlined by ERC-4337, can be broken down into the following distinct components:
User Operations
Users with a SCA start the process by creating a User Operation (UserOp). UserOps are considered meta-transactions that represent a user's intent. They do not follow the format of a traditional transaction submitted for execution (since it is not coming from an EOA) and instead contain a set of instructions for the user's intent and additional metadata needed to execute the eventual smart contract function. Intents can be thought of as specifying what the final outcome of the UserOp should be (i.e., swap ETH for USDC). Traditional transactions are much more granular as they cover every step of the process to reach the final outcome (i.e., approve ETH for swapping, send ETH to Uniswap router, send back USDC).
Bundlers
Bundlers are EOAs that monitor off-chain/alternative mempools containing UserOps and bundle multiple UserOps together to form and initiate a singular standard transaction. These bundlers front the gas costs for these transactions consisting of UserOps.
EntryPoint
The EntryPoint smart contract is the central piece of this infrastructure, as this smart contract receives the transactions from the Bundlers, verifies the validity of the transactions and then forwards the various UserOps to the corresponding individual users' SCAs to execute
Paymaster
A Paymaster is a smart contract that oversees the implementation of gas payment policies for the entity that deployed the Paymaster (such as companies like Coinbase, Uniswap Labs, OpenSea, etc). These policies can cover what currency the transaction fees is paid with (i.e., users can pay with USDC instead of ETH) and by whom (i.e., the entity sponsors the transaction fee for users). This removes the requirement for every user to hold the blockchain's native gas token. Paymasters can be considered an optional piece of infrastructure given users could also just pay for their own gas.
Aggregator
An Aggregator is a smart contract that implements a signature scheme to support aggregation of multiple different signatures. The aggregator is another optional piece of infrastructure which helps save on gas costs by bundling multiple different wallet signatures together to execute multiple transactions at once.
After all that, this seems like a good stopping point. We'll save the nitty gritty of how all these components interact with each other for the next post.
Until next time!
<100 subscribers
<100 subscribers
No activity yet