Fuel LabsIntroducing Fuel Season 1 (FS-1) and Phase 2 Genesis Drop
Today marks the conclusion of Phase 2 and with it the Fuel Points Program. We want to thank all participants who helped bootstrap Ignition, and now turn our focus to building Fuel into a fully integrated liquidity hub. As we mark the end of the Fuel Points program, we are excited to unveil two initiatives: Phase 2 of the Genesis Drop and the start of Fuel Season 1 (FS-1).Genesis Drop: Phase 2 - 150,000,000 FUEL1.5% of FUEL total supply.Rewards for participation in Phase 2 of the Points Progra...
Fuel LabsAnnouncing Phase 2 of the Fuel Points Program
We are excited to announce the final phase in the Fuel Points Program, now live with Fuel Ignition. With Phase 2, you can continue earning points while supporting the growth of the Fuel ecosystem. With Phase 2 of Fuel Points, we’re ensuring that the network grows in a way that is positive sum for points program participants, the Fuel ecosystem projects and the broader Fuel community. Qualifying users can participate in the program, while earning rewards for meaningfully engaging with the ecos...
Fuel LabsSway: The Next-Generation Language for Smart Contracts
As blockchain applications become more complex, there is a strong need for safe and smart contract languages. Many platforms today rely on languages and virtual machines (VMs) that weren't originally designed to handle the unique constraints and requirements of blockchain execution. It’s no secret that the architectural decisions made in 2014 for Solidity and the EVM now show clear signs of age. Among these is their susceptibility to vulnerabilities that make writing secure Ethereum smar...
Fuel Ignition is a high-performance Ethereum L2.
Fuel LabsIntroducing Fuel Season 1 (FS-1) and Phase 2 Genesis Drop
Today marks the conclusion of Phase 2 and with it the Fuel Points Program. We want to thank all participants who helped bootstrap Ignition, and now turn our focus to building Fuel into a fully integrated liquidity hub. As we mark the end of the Fuel Points program, we are excited to unveil two initiatives: Phase 2 of the Genesis Drop and the start of Fuel Season 1 (FS-1).Genesis Drop: Phase 2 - 150,000,000 FUEL1.5% of FUEL total supply.Rewards for participation in Phase 2 of the Points Progra...
Fuel LabsAnnouncing Phase 2 of the Fuel Points Program
We are excited to announce the final phase in the Fuel Points Program, now live with Fuel Ignition. With Phase 2, you can continue earning points while supporting the growth of the Fuel ecosystem. With Phase 2 of Fuel Points, we’re ensuring that the network grows in a way that is positive sum for points program participants, the Fuel ecosystem projects and the broader Fuel community. Qualifying users can participate in the program, while earning rewards for meaningfully engaging with the ecos...
Fuel LabsSway: The Next-Generation Language for Smart Contracts
As blockchain applications become more complex, there is a strong need for safe and smart contract languages. Many platforms today rely on languages and virtual machines (VMs) that weren't originally designed to handle the unique constraints and requirements of blockchain execution. It’s no secret that the architectural decisions made in 2014 for Solidity and the EVM now show clear signs of age. Among these is their susceptibility to vulnerabilities that make writing secure Ethereum smar...
Fuel Ignition is a high-performance Ethereum L2.
Share Dialog
Share Dialog
Subscribe to Fuel Labs
Subscribe to Fuel Labs
>2.8K subscribers
>2.8K subscribers
This is Part I of a multi-part series by Fuel Labs that covers topics related to scalability and execution on Ethereum. This series aims to provide comprehensive insights into the challenges associated with enhancing Ethereum's performance and capacity, as well as the current solutions working to make it more efficient and scalable for widespread adoption.
Ethereum's architecture comprises several layers, each playing a crucial role in the network's operation. Among these layers, the execution layer is particularly significant. Transaction processing, smart contract execution, and maintenance of a consistent and secure state are all done on the execution layer. However, this layer is often a bottleneck that limits the overall performance and scalability of the Ethereum network.
Execution refers to the computation required to execute transactions and perform state changes on the blockchain. This computation often involves validating transactions by checking their signatures and token balances, and executing the on-chain logic necessary to update the state. State changes occur when full nodes update their copy of the ledger to reflect new token transfers, smart contract code updates, and data storage changes.
The primary functions of the execution layer include:
Transaction Processing: Validating and executing transactions sent by users.
Smart Contract Execution: Running the code of smart contracts, which are self-executing contracts where the terms of the agreement are directly written into code.
State Management: Maintaining the state of the blockchain, including account balances, smart contract states, and other essential data. Ethereum's state management is particularly challenging due to its complex state tree, but innovations like Verkle trees, which optimize state storage by enabling smaller and more efficient data proofs, are in the works to address this. Meanwhile, other blockchains like Solana, despite having no global state tree, have also grappled with state management issues.
The goal of scalability is to enhance performance by increasing transaction speed (faster finality) and transaction throughput (higher number of transactions per second). People often think of performance in terms of TPS, or transactions per second. In reality, scalability refers to the number of computations per second a blockchain can handle as transactions can vary in complexity and resource demands. Ethereum uses "gas" to measure the computations required to execute transactions and smart contracts. The challenge in scaling the execution layer lies in increasing the number of computations per second without significantly raising the hardware requirements for individual full nodes that validate transactions in blocks. Efficiently solving this problem is crucial for enhancing the throughput and performance of blockchain networks.
To fully understand why scalability needs to be considered computationally, it’s important to look more closely at how transactions are processed on Ethereum. When a user initiates a transaction on Ethereum, the transaction goes through several steps before being finalized. Here's a simplified overview of this process:
Transaction Initiation: An Externally Owned Account (EOA) or a smart contract owner initiates a transaction by creating a signed JSON-RPC request. This request includes details such as the recipient address, amount of Ether (if any) to transfer, data to include (if interacting with a contract), gas limit, and other transaction parameters.
Digital Signature Verification: Nodes on the Ethereum network first verify the digital signature of the transaction to confirm its authenticity and ensure it has not been tampered with during transmission.
Nonce Check: The network checks the nonce of the sender's account to ensure that the transaction is sequential and prevents replay attacks. The nonce is incremented with each transaction sent from an account.
Gas Calculation: Gas is a unit used to measure computational effort and is necessary to execute transactions and smart contracts. The transaction specifies a gas limit, which is the maximum amount of gas the sender is willing to use for that transaction. Gas fees are paid in Ether and cover the cost of computation and storage on the Ethereum network.
Transaction Broadcast: Once validated, the transaction is broadcasted to all nodes in the Ethereum peer-to-peer network. Nodes receive the transaction and begin the process of including it in a block for validation.
Block Creation: Validators in Ethereum's Proof of Stake (PoS) consensus mechanism validate and propose a new block, incorporating batches of validated transactions, including the most recently initiated one.
Block Validation: Other nodes also verifying the correctness of transactions, checking signatures, confirming available funds, and ensuring no double-spending occurs.
State Update: When a block is valid, each node updates its local copy of the Ethereum blockchain with the new state changes from the transactions in that block. This means updating account balances, contract storage, and other important data. Ethereum keeps a global Merkle tree, which consolidates all state data by organizing it into a hierarchical structure where each block's state is hashed and linked, ultimately leading to a single root hash. This gives us a single, tidy state root that allows light clients to verify the integrity of specific transactions or pieces of data without needing to download the entire blockchain.
Although the execution layer is central to Ethereum's functionality, it is also a significant bottleneck to the number of computations Ethereum can handle at any given time. Data availability (DA) was a critical issue, but solutions such as EIP-4844, which introduced temporary "blobs" of data that are far cheaper to store than regular Ethereum transactions, have largely mitigated these challenges. By enhancing data distribution and off-chain storage, innovations like the EIP-4844 have shifted the focus to the execution layer as the primary obstacle to Ethereum's scalability.
Several factors contribute to the execution bottleneck in Ethereum.
Latency is the time delay from when a transaction is submitted to when it is confirmed and included in the blockchain. High latency can lead to slower transaction confirmations, longer wait times for users, and delays in the execution of smart contracts. The primary latency bottlenecks include:
Block Time and Confirmation Latency: Ethereum's average block time, currently around 12 seconds, imposes a minimum latency for transaction confirmations. If a transaction is included in the next block, the average wait time is approximately half the block time, or 6 seconds. If transaction volume is low, latency can increase as transactions wait longer to be included in a block.
Blockchain Synchronization (Consensus): Nodes in the Ethereum network must reach consensus on the validity of each block. This process can introduce latency as nodes verify transactions, validate blocks, and synchronize with the network state. Variability in block propagation times also contributes to latency.
Throughput directly is the network's capacity to efficiently process and handle large volumes of transactions within a given timeframe. Higher throughput means the network can handle more transactions per second. The throughput bottlenecks include:
Single-Threaded Execution: The Ethereum Virtual Machine (EVM) processes transactions one at a time in a single-threaded manner. This means transactions cannot be parallelized, limiting how many can be processed simultaneously.
Wasteful Execution: The EVM uses 256-bit words and a stack-based approach instead of registers. This design choice leads to inefficient use of computational resources, increasing the time and energy needed for executing contracts.
State Management: Ethereum maintains a large, deeply nested state tree with 256 levels. Every time a key-value pair is updated, 256 updates must be made to the database. This extensive updating process significantly slows down the network.
Gas Metering Overhead: While gas metering is intended to prevent excessive resource use and avoid the halting problem, tracking every operation adds significant overhead. This overhead contributes to slower transaction processing.
Node Capacity Limits: Ethereum nodes have practical limits on their processing and storage capacities. When transaction processing demands exceed these limits, nodes struggle to keep up, leading to delays in block validation and propagation.
State Growth: As the number of transactions increases, so does the state of the blockchain. This growth requires more storage and makes state verification and access more time-consuming, further slowing down the network.
Performance issues stemming from the execution layer manifest in various ways, affecting both the scalability of the network and the user experience. Here are some examples:
Network Congestion: During periods of high demand, such as popular TGEs or NFT drops, the number of transactions can overwhelm the network, leading to congestion. This results in longer confirmation times and higher gas fees as users compete to have their transactions processed.
High Gas Fees: When the network is congested, gas fees can skyrocket, making it prohibitively expensive for users to perform even simple transactions. This limits the accessibility and usability of the network.
Scalability Challenges: The limited throughput of the EVM hinders Ethereum's ability to scale effectively. As the number of users and decentralized applications (dApps) grows, the network struggles to accommodate the increased load without significant performance degradation.
The execution bottleneck has tangible effects on both end-users and developers, influencing the broader Ethereum ecosystem in significant ways.
High gas fees during peak times make it costly for users to interact with the network, whether it is to send ETH, participate in DeFi protocols, or mint NFTs. Network congestion can lead to delayed transaction confirmations, causing frustration and inconvenience for users who expect real-time interactions. These high costs and delays reduce the overall usability of the network, deterring potential users and limiting the growth of the ecosystem.
From a developer's perspective, the need to optimize smart contracts to minimize gas usage adds complexity and time to the development process. They also need to contend with optimizing infrastructure, often through third-party providers such as node services (e.g., Infura). This can be an even bigger hurdle than solely optimizing smart contracts. Building scalable dApps on Ethereum is further complicated by the network's limited throughput, often requiring developers to implement off-chain solutions or layer 2 scaling techniques for better performance.
The CryptoKitties NFT craze in late 2017 was a pivotal moment that demonstrated just how congested the network could get. The surge in transactions from users breeding and trading virtual cats led to significant network delays. At its peak, CryptoKitties was responsible for nearly 16% of all transactions on the Ethereum network, causing some transactions to be delayed for hours or even days. According to a Coindesk article, at one point there were around 30,000 transactions that were stuck and waiting to be processed.
The DeFi Summer of 2020 marked another period of significant network congestion. The rapid adoption of dApps such as Uniswap and Compound resulted in a substantial increase in network activity. These factors, among others, led to a high demand for on-chain space and a consequent surge in gas fees, with thousands of ETH spent daily on transaction costs.
The NFT boom from 2021 to 2022 further highlighted Ethereum's scalability issues. High-profile NFT drops and auctions, like the Otherside NFT launch by Yuga Labs, drew thousands of participants, pushing gas fees through the roof. The average gas fee on the day of the Otherside mint exceeded $400 per transaction.
Beyond niche activities like NFT trading and DeFi speculation, high costs and delays can also undermine the user experience of dApps, reducing engagement and retention. Several blockchain projects have been forced either to migrate to other blockchains or shut down altogether. For instance, UniLogin, which aimed to simplify user logins to ETH-based applications—a critical function for mainstream adoption—had to cease operations because escalating gas fees rendered it financially unsustainable, costing over $130 per sign-up at times. Additionally, Publish0x, a platform where users can earn crypto for creating and reading content, had to delay payouts and switch to monthly disbursements due to the high costs. For Ethereum to scale effectively to real-world applications in finance, supply chain management, and decentralized identity among others, it must address these scalability issues to support broader adoption.
The real-world implications of execution bottlenecks are far-reaching, affecting both users and developers. High gas fees, network congestion, and scalability constraints hinder the growth and usability of the Ethereum ecosystem. Addressing these challenges requires innovation and improvements to the execution layer.
In Part II, we will look into the importance of innovating the execution layer for Ethereum's future. We’ll take a close look at current limitations of the EVM, potential solutions, and benefits of evolving beyond the traditional execution model.
Recommended Readings:
Explained: Ethereum’s Scalability Problems and Growing Backlash
This is Part I of a multi-part series by Fuel Labs that covers topics related to scalability and execution on Ethereum. This series aims to provide comprehensive insights into the challenges associated with enhancing Ethereum's performance and capacity, as well as the current solutions working to make it more efficient and scalable for widespread adoption.
Ethereum's architecture comprises several layers, each playing a crucial role in the network's operation. Among these layers, the execution layer is particularly significant. Transaction processing, smart contract execution, and maintenance of a consistent and secure state are all done on the execution layer. However, this layer is often a bottleneck that limits the overall performance and scalability of the Ethereum network.
Execution refers to the computation required to execute transactions and perform state changes on the blockchain. This computation often involves validating transactions by checking their signatures and token balances, and executing the on-chain logic necessary to update the state. State changes occur when full nodes update their copy of the ledger to reflect new token transfers, smart contract code updates, and data storage changes.
The primary functions of the execution layer include:
Transaction Processing: Validating and executing transactions sent by users.
Smart Contract Execution: Running the code of smart contracts, which are self-executing contracts where the terms of the agreement are directly written into code.
State Management: Maintaining the state of the blockchain, including account balances, smart contract states, and other essential data. Ethereum's state management is particularly challenging due to its complex state tree, but innovations like Verkle trees, which optimize state storage by enabling smaller and more efficient data proofs, are in the works to address this. Meanwhile, other blockchains like Solana, despite having no global state tree, have also grappled with state management issues.
The goal of scalability is to enhance performance by increasing transaction speed (faster finality) and transaction throughput (higher number of transactions per second). People often think of performance in terms of TPS, or transactions per second. In reality, scalability refers to the number of computations per second a blockchain can handle as transactions can vary in complexity and resource demands. Ethereum uses "gas" to measure the computations required to execute transactions and smart contracts. The challenge in scaling the execution layer lies in increasing the number of computations per second without significantly raising the hardware requirements for individual full nodes that validate transactions in blocks. Efficiently solving this problem is crucial for enhancing the throughput and performance of blockchain networks.
To fully understand why scalability needs to be considered computationally, it’s important to look more closely at how transactions are processed on Ethereum. When a user initiates a transaction on Ethereum, the transaction goes through several steps before being finalized. Here's a simplified overview of this process:
Transaction Initiation: An Externally Owned Account (EOA) or a smart contract owner initiates a transaction by creating a signed JSON-RPC request. This request includes details such as the recipient address, amount of Ether (if any) to transfer, data to include (if interacting with a contract), gas limit, and other transaction parameters.
Digital Signature Verification: Nodes on the Ethereum network first verify the digital signature of the transaction to confirm its authenticity and ensure it has not been tampered with during transmission.
Nonce Check: The network checks the nonce of the sender's account to ensure that the transaction is sequential and prevents replay attacks. The nonce is incremented with each transaction sent from an account.
Gas Calculation: Gas is a unit used to measure computational effort and is necessary to execute transactions and smart contracts. The transaction specifies a gas limit, which is the maximum amount of gas the sender is willing to use for that transaction. Gas fees are paid in Ether and cover the cost of computation and storage on the Ethereum network.
Transaction Broadcast: Once validated, the transaction is broadcasted to all nodes in the Ethereum peer-to-peer network. Nodes receive the transaction and begin the process of including it in a block for validation.
Block Creation: Validators in Ethereum's Proof of Stake (PoS) consensus mechanism validate and propose a new block, incorporating batches of validated transactions, including the most recently initiated one.
Block Validation: Other nodes also verifying the correctness of transactions, checking signatures, confirming available funds, and ensuring no double-spending occurs.
State Update: When a block is valid, each node updates its local copy of the Ethereum blockchain with the new state changes from the transactions in that block. This means updating account balances, contract storage, and other important data. Ethereum keeps a global Merkle tree, which consolidates all state data by organizing it into a hierarchical structure where each block's state is hashed and linked, ultimately leading to a single root hash. This gives us a single, tidy state root that allows light clients to verify the integrity of specific transactions or pieces of data without needing to download the entire blockchain.
Although the execution layer is central to Ethereum's functionality, it is also a significant bottleneck to the number of computations Ethereum can handle at any given time. Data availability (DA) was a critical issue, but solutions such as EIP-4844, which introduced temporary "blobs" of data that are far cheaper to store than regular Ethereum transactions, have largely mitigated these challenges. By enhancing data distribution and off-chain storage, innovations like the EIP-4844 have shifted the focus to the execution layer as the primary obstacle to Ethereum's scalability.
Several factors contribute to the execution bottleneck in Ethereum.
Latency is the time delay from when a transaction is submitted to when it is confirmed and included in the blockchain. High latency can lead to slower transaction confirmations, longer wait times for users, and delays in the execution of smart contracts. The primary latency bottlenecks include:
Block Time and Confirmation Latency: Ethereum's average block time, currently around 12 seconds, imposes a minimum latency for transaction confirmations. If a transaction is included in the next block, the average wait time is approximately half the block time, or 6 seconds. If transaction volume is low, latency can increase as transactions wait longer to be included in a block.
Blockchain Synchronization (Consensus): Nodes in the Ethereum network must reach consensus on the validity of each block. This process can introduce latency as nodes verify transactions, validate blocks, and synchronize with the network state. Variability in block propagation times also contributes to latency.
Throughput directly is the network's capacity to efficiently process and handle large volumes of transactions within a given timeframe. Higher throughput means the network can handle more transactions per second. The throughput bottlenecks include:
Single-Threaded Execution: The Ethereum Virtual Machine (EVM) processes transactions one at a time in a single-threaded manner. This means transactions cannot be parallelized, limiting how many can be processed simultaneously.
Wasteful Execution: The EVM uses 256-bit words and a stack-based approach instead of registers. This design choice leads to inefficient use of computational resources, increasing the time and energy needed for executing contracts.
State Management: Ethereum maintains a large, deeply nested state tree with 256 levels. Every time a key-value pair is updated, 256 updates must be made to the database. This extensive updating process significantly slows down the network.
Gas Metering Overhead: While gas metering is intended to prevent excessive resource use and avoid the halting problem, tracking every operation adds significant overhead. This overhead contributes to slower transaction processing.
Node Capacity Limits: Ethereum nodes have practical limits on their processing and storage capacities. When transaction processing demands exceed these limits, nodes struggle to keep up, leading to delays in block validation and propagation.
State Growth: As the number of transactions increases, so does the state of the blockchain. This growth requires more storage and makes state verification and access more time-consuming, further slowing down the network.
Performance issues stemming from the execution layer manifest in various ways, affecting both the scalability of the network and the user experience. Here are some examples:
Network Congestion: During periods of high demand, such as popular TGEs or NFT drops, the number of transactions can overwhelm the network, leading to congestion. This results in longer confirmation times and higher gas fees as users compete to have their transactions processed.
High Gas Fees: When the network is congested, gas fees can skyrocket, making it prohibitively expensive for users to perform even simple transactions. This limits the accessibility and usability of the network.
Scalability Challenges: The limited throughput of the EVM hinders Ethereum's ability to scale effectively. As the number of users and decentralized applications (dApps) grows, the network struggles to accommodate the increased load without significant performance degradation.
The execution bottleneck has tangible effects on both end-users and developers, influencing the broader Ethereum ecosystem in significant ways.
High gas fees during peak times make it costly for users to interact with the network, whether it is to send ETH, participate in DeFi protocols, or mint NFTs. Network congestion can lead to delayed transaction confirmations, causing frustration and inconvenience for users who expect real-time interactions. These high costs and delays reduce the overall usability of the network, deterring potential users and limiting the growth of the ecosystem.
From a developer's perspective, the need to optimize smart contracts to minimize gas usage adds complexity and time to the development process. They also need to contend with optimizing infrastructure, often through third-party providers such as node services (e.g., Infura). This can be an even bigger hurdle than solely optimizing smart contracts. Building scalable dApps on Ethereum is further complicated by the network's limited throughput, often requiring developers to implement off-chain solutions or layer 2 scaling techniques for better performance.
The CryptoKitties NFT craze in late 2017 was a pivotal moment that demonstrated just how congested the network could get. The surge in transactions from users breeding and trading virtual cats led to significant network delays. At its peak, CryptoKitties was responsible for nearly 16% of all transactions on the Ethereum network, causing some transactions to be delayed for hours or even days. According to a Coindesk article, at one point there were around 30,000 transactions that were stuck and waiting to be processed.
The DeFi Summer of 2020 marked another period of significant network congestion. The rapid adoption of dApps such as Uniswap and Compound resulted in a substantial increase in network activity. These factors, among others, led to a high demand for on-chain space and a consequent surge in gas fees, with thousands of ETH spent daily on transaction costs.
The NFT boom from 2021 to 2022 further highlighted Ethereum's scalability issues. High-profile NFT drops and auctions, like the Otherside NFT launch by Yuga Labs, drew thousands of participants, pushing gas fees through the roof. The average gas fee on the day of the Otherside mint exceeded $400 per transaction.
Beyond niche activities like NFT trading and DeFi speculation, high costs and delays can also undermine the user experience of dApps, reducing engagement and retention. Several blockchain projects have been forced either to migrate to other blockchains or shut down altogether. For instance, UniLogin, which aimed to simplify user logins to ETH-based applications—a critical function for mainstream adoption—had to cease operations because escalating gas fees rendered it financially unsustainable, costing over $130 per sign-up at times. Additionally, Publish0x, a platform where users can earn crypto for creating and reading content, had to delay payouts and switch to monthly disbursements due to the high costs. For Ethereum to scale effectively to real-world applications in finance, supply chain management, and decentralized identity among others, it must address these scalability issues to support broader adoption.
The real-world implications of execution bottlenecks are far-reaching, affecting both users and developers. High gas fees, network congestion, and scalability constraints hinder the growth and usability of the Ethereum ecosystem. Addressing these challenges requires innovation and improvements to the execution layer.
In Part II, we will look into the importance of innovating the execution layer for Ethereum's future. We’ll take a close look at current limitations of the EVM, potential solutions, and benefits of evolving beyond the traditional execution model.
Recommended Readings:
Explained: Ethereum’s Scalability Problems and Growing Backlash
Transaction Confirmation: Once a transaction is included in a block and that block is added to the blockchain, the transaction is considered confirmed. Confirmation indicates that the transaction is irreversible and has been accepted by the Ethereum network.
Final Execution and Contract Interaction: For transactions interacting with smart contracts, the contract's code is executed according to the input data provided in the transaction. This execution may involve updating the contract's internal state variables, emitting events, or triggering further transactions.
Transaction Receipt: A transaction receipt is generated and can be inspected to confirm details such as the amount of gas used, block number where the transaction was included, and any logs produced during contract execution.
Transaction Confirmation: Once a transaction is included in a block and that block is added to the blockchain, the transaction is considered confirmed. Confirmation indicates that the transaction is irreversible and has been accepted by the Ethereum network.
Final Execution and Contract Interaction: For transactions interacting with smart contracts, the contract's code is executed according to the input data provided in the transaction. This execution may involve updating the contract's internal state variables, emitting events, or triggering further transactions.
Transaction Receipt: A transaction receipt is generated and can be inspected to confirm details such as the amount of gas used, block number where the transaction was included, and any logs produced during contract execution.
No activity yet