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
Subscribe to 0xhubman.eth
Subscribe to 0xhubman.eth
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
For this post, we'll be bringing it back to the very basics of Ethereum and discussing the importance of EIPs and ERCs! These proposal frameworks might often be overlooked or taken for granted by a casual participant of the Ethereum ecosystem, but they play a critical role in the continued development and longevity of Ethereum. For those who are unfamiliar, EIP stands for Ethereum Improvement Proposals and ERC stands for Ethereum Request for Comment. As alluded to in their names, both of these proposal frameworks pertain to the improvement and standardization of various aspects of Ethereum and laid the foundation to enable the flourishing ecosystem that many users enjoy today. However, these proposals differ in their subject matter:
EIPs encompass improvements at the protocol level, such as technical specifications, protocol upgrades, and best practices
ERCs encompass improvements at the application level, such as providing guidelines for how tokens and smart contracts should behave
Back during Ethereum's infancy, the Ethereum developer community took inspiration for proposal frameworks from the working groups of the 1960s who created improvement methodologies, such as RFCs (Request For Comments), to help standardize various Internet protocols. Given Ethereum's ambition to be the world's decentralized internet of money, this framework adoption comes as no surprise. Additionally, much like RFCs, anyone is free to submit an EIP or ERC for review. However, before formal submission and tracking, the author must first engage in thorough discussion and reach majority consensus with the wider developer community on Ethereum Magicians or Ethereum Research. In more recent news, up until recently both EIPs and ERCs shared a common GitHub repo where the Ethereum developer community could discuss and debate the various proposals submitted for feedback. However, after ongoing conversations for years, EIPs and ERCs now have separate repos to help better facilitate faster review periods and feature implementations. Now with that context given, let's take a deeper dive into both of these proposal frameworks to fully understand the benefit they provide Ethereum!
As mentioned above, EIPs (which take their name inspiration from BIPs, Bitcoin Improvement Proposals) deal with improvements at the protocol level of Ethereum. As stated in the EIP repo "the goal of the EIP project is to standardize and provide high-quality documentation for Ethereum itself and conventions built upon it". The secret sauce that makes EIPs so incredibly useful is the standardized format all EIPs must adhere to be formally recognized and facilitate discussion. Two EIP subject matters and goals could be vastly different, but they all share a common template that allows the readers to quickly digest the purpose of the proposal and provide feedback. As such, all successful EIPs share the following components:
Preamble: RFC style header containing metadata about the EIP, title, short description, and author details
Abstract: Human-readable summary of the proposal
Motivation: Explain why the existing protocol is inadequate to address the problem the proposal solves
Specification: The technical specifications that describe the syntax and semantics of any new features. Needs to be detailed enough to allow for implementation in any Ethereum client
Rational: Fleshes out the specification by describing what motivated the design and why particular design decisions were made
Security Considerations: Discusses the security implications and considerations relevant to the proposal
Given EIPs can cover an immense array of topics within the Ethereum protocol, EIPs are categorized by the list below:
Core (C-EIPs): Proposals that change the Ethereum protocol itself, including updates to the consensus rules or fundamental changes to how the network operates. Often requires a hard fork to be implemented
Networking (NET-EIPs): Proposals that focus on improving the network layer of Ethereum, such as changes to how nodes communication or how the network handles various aspects, such as peer discovery
Interface (I-EIPs): Proposals related to improvements in user interfaces and user experience, such as wallets, browser extensions, or other tools used to interact with the network.
Meta (META-EIPs): Proposals that discuss or address processes, guidelines or best practices for managing and dealing with other EIPs
Informational (INFO-EIPs): No changes proposed, but instead provide information, guidelines, or educational resources related to Ethereum
Withdrawn EIPs: Proposals that were initially put forward but later withdrawn by their authors
Final (FINAL-EIPs): Proposals that have completed the EIP process and have been implemented in the Ethereum network
So in summary, the EIP framework serves to help foster open discussion, consensus building, and decentralized decision making in a standardized format when it comes to changes related to the Ethereum network.
As mentioned above, ERCs deal with improvements at the application level of Ethereum. ERCs can cover a wide variety of topics, but are most commonly associated with smart contract and token standards, with popular examples being ERC-20 for fungible tokens and ERC-721 & ERC-1155 for non-fungible tokens. As such, one of the main goals of ERCs is to ensure interoperability and compatibility between different tokens and smart contracts within the wider Ethereum ecosystem, given the decentralized and trustless nature of many of the ecosystem's components.
To help illustrate the need for this standardization, a similar example to consider is electrical plugs and outlets we use every day. Whenever you buy a new charger for your device or appliance for your house, do you need to pour over the technical details to ensure the plug will be compatible with the outlets in your home? No - there is a technical standard in place for all electrical plugs and outlets in the United States to ensure consumers have confidence that the plugs and outlets will be compatible. ERCs serve the same purpose, so users within the Ethereum ecosystem have confidence that tokens and smart contracts will behave as intended, and developers can focus on higher priority items instead of learning and integrating 100 different token standards when building a dApp. Additionally, taking the plug and outlet comparison one step further, only plugs and outlets within the United States share a common standard, while plugs and outlets in Europe and Australia adhere to different standards. This mirrors the fact that ERCs only encompass standards within the Ethereum (and EVM-compatible) ecosystem, while other blockchains like Solana and Bitcoin utilize different standards.
Now to provide an example of what an ERC looks like in practice, we'll examine the ERC-20 standard. As part of the ERC-20 standard, there are 6 mandatory functions a token's smart contract are required to have:
totalSupply: When this limit is reached, the smart contract will refuse to create any additional tokens
balanceOf: Returns the token balance of a specific address
transfer: Transfers tokens from the smart contract to a specific address
transferFrom: Transfers tokens between two specified addresses
approve: Verifies that the smart contract can send a certain amount of tokens to a specific address
allowance: Verifies that a specific address has a high enough balance to send a certain amount of tokens to another address
Additionally, there are 3 optional functions a token's smart contract can perform as well:
name: Returns the name of the token
symbol: Returns the symbol of the token
decimals: Returns the divisibility of the token
Lastly, there are 2 required events (these are different from functions) a token's smart contract must emit when interacting with as well:
Transfer: Event is triggered when tokens are transferred
Approval: Event is triggered when the approval function is called
For those of you who are avid proposal enthusiasts and/or standardization enjoyoooors, below are some additional resources to peruse at your leisure.
Until next time!
For this post, we'll be bringing it back to the very basics of Ethereum and discussing the importance of EIPs and ERCs! These proposal frameworks might often be overlooked or taken for granted by a casual participant of the Ethereum ecosystem, but they play a critical role in the continued development and longevity of Ethereum. For those who are unfamiliar, EIP stands for Ethereum Improvement Proposals and ERC stands for Ethereum Request for Comment. As alluded to in their names, both of these proposal frameworks pertain to the improvement and standardization of various aspects of Ethereum and laid the foundation to enable the flourishing ecosystem that many users enjoy today. However, these proposals differ in their subject matter:
EIPs encompass improvements at the protocol level, such as technical specifications, protocol upgrades, and best practices
ERCs encompass improvements at the application level, such as providing guidelines for how tokens and smart contracts should behave
Back during Ethereum's infancy, the Ethereum developer community took inspiration for proposal frameworks from the working groups of the 1960s who created improvement methodologies, such as RFCs (Request For Comments), to help standardize various Internet protocols. Given Ethereum's ambition to be the world's decentralized internet of money, this framework adoption comes as no surprise. Additionally, much like RFCs, anyone is free to submit an EIP or ERC for review. However, before formal submission and tracking, the author must first engage in thorough discussion and reach majority consensus with the wider developer community on Ethereum Magicians or Ethereum Research. In more recent news, up until recently both EIPs and ERCs shared a common GitHub repo where the Ethereum developer community could discuss and debate the various proposals submitted for feedback. However, after ongoing conversations for years, EIPs and ERCs now have separate repos to help better facilitate faster review periods and feature implementations. Now with that context given, let's take a deeper dive into both of these proposal frameworks to fully understand the benefit they provide Ethereum!
As mentioned above, EIPs (which take their name inspiration from BIPs, Bitcoin Improvement Proposals) deal with improvements at the protocol level of Ethereum. As stated in the EIP repo "the goal of the EIP project is to standardize and provide high-quality documentation for Ethereum itself and conventions built upon it". The secret sauce that makes EIPs so incredibly useful is the standardized format all EIPs must adhere to be formally recognized and facilitate discussion. Two EIP subject matters and goals could be vastly different, but they all share a common template that allows the readers to quickly digest the purpose of the proposal and provide feedback. As such, all successful EIPs share the following components:
Preamble: RFC style header containing metadata about the EIP, title, short description, and author details
Abstract: Human-readable summary of the proposal
Motivation: Explain why the existing protocol is inadequate to address the problem the proposal solves
Specification: The technical specifications that describe the syntax and semantics of any new features. Needs to be detailed enough to allow for implementation in any Ethereum client
Rational: Fleshes out the specification by describing what motivated the design and why particular design decisions were made
Security Considerations: Discusses the security implications and considerations relevant to the proposal
Given EIPs can cover an immense array of topics within the Ethereum protocol, EIPs are categorized by the list below:
Core (C-EIPs): Proposals that change the Ethereum protocol itself, including updates to the consensus rules or fundamental changes to how the network operates. Often requires a hard fork to be implemented
Networking (NET-EIPs): Proposals that focus on improving the network layer of Ethereum, such as changes to how nodes communication or how the network handles various aspects, such as peer discovery
Interface (I-EIPs): Proposals related to improvements in user interfaces and user experience, such as wallets, browser extensions, or other tools used to interact with the network.
Meta (META-EIPs): Proposals that discuss or address processes, guidelines or best practices for managing and dealing with other EIPs
Informational (INFO-EIPs): No changes proposed, but instead provide information, guidelines, or educational resources related to Ethereum
Withdrawn EIPs: Proposals that were initially put forward but later withdrawn by their authors
Final (FINAL-EIPs): Proposals that have completed the EIP process and have been implemented in the Ethereum network
So in summary, the EIP framework serves to help foster open discussion, consensus building, and decentralized decision making in a standardized format when it comes to changes related to the Ethereum network.
As mentioned above, ERCs deal with improvements at the application level of Ethereum. ERCs can cover a wide variety of topics, but are most commonly associated with smart contract and token standards, with popular examples being ERC-20 for fungible tokens and ERC-721 & ERC-1155 for non-fungible tokens. As such, one of the main goals of ERCs is to ensure interoperability and compatibility between different tokens and smart contracts within the wider Ethereum ecosystem, given the decentralized and trustless nature of many of the ecosystem's components.
To help illustrate the need for this standardization, a similar example to consider is electrical plugs and outlets we use every day. Whenever you buy a new charger for your device or appliance for your house, do you need to pour over the technical details to ensure the plug will be compatible with the outlets in your home? No - there is a technical standard in place for all electrical plugs and outlets in the United States to ensure consumers have confidence that the plugs and outlets will be compatible. ERCs serve the same purpose, so users within the Ethereum ecosystem have confidence that tokens and smart contracts will behave as intended, and developers can focus on higher priority items instead of learning and integrating 100 different token standards when building a dApp. Additionally, taking the plug and outlet comparison one step further, only plugs and outlets within the United States share a common standard, while plugs and outlets in Europe and Australia adhere to different standards. This mirrors the fact that ERCs only encompass standards within the Ethereum (and EVM-compatible) ecosystem, while other blockchains like Solana and Bitcoin utilize different standards.
Now to provide an example of what an ERC looks like in practice, we'll examine the ERC-20 standard. As part of the ERC-20 standard, there are 6 mandatory functions a token's smart contract are required to have:
totalSupply: When this limit is reached, the smart contract will refuse to create any additional tokens
balanceOf: Returns the token balance of a specific address
transfer: Transfers tokens from the smart contract to a specific address
transferFrom: Transfers tokens between two specified addresses
approve: Verifies that the smart contract can send a certain amount of tokens to a specific address
allowance: Verifies that a specific address has a high enough balance to send a certain amount of tokens to another address
Additionally, there are 3 optional functions a token's smart contract can perform as well:
name: Returns the name of the token
symbol: Returns the symbol of the token
decimals: Returns the divisibility of the token
Lastly, there are 2 required events (these are different from functions) a token's smart contract must emit when interacting with as well:
Transfer: Event is triggered when tokens are transferred
Approval: Event is triggered when the approval function is called
For those of you who are avid proposal enthusiasts and/or standardization enjoyoooors, below are some additional resources to peruse at your leisure.
Until next time!
No activity yet