Ethereum’s Scalability Challenges

Limitations of Ethereum’s Mainnet

According to Vitalik Buterin’s blockchain trilemma, no blockchain can simultaneously achieve decentralization, security, and scalability. Trade-offs must be made between these three factors. Ethereum has chosen to focus on decentralization and security. It has successfully transitioned from Proof of Work (PoW) to Proof of Stake (PoS) consensus, leading innovation and development within the industry. As a result, it has become the largest public blockchain ecosystem, second only to Bitcoin in terms of decentralization and economic security.

However, despite multiple upgrades, Ethereum’s scalability remains limited. The average block time is 12 seconds, and its transactions per second (TPS) are only around 13. When network activity spikes, congestion occurs, accompanied by high transaction fees, which severely impacts user experience. Ethereum’s scalability issues have become more pronounced as the ecosystem grows with more applications and users. In response, in 2020, Vitalik Buterin officially announced that Ethereum’s future roadmap would focus on Rollups (i.e., Layer 2 solutions) to address the scalability issues of the mainnet.

The Hidden Concerns of Layer 2

Simply put, Layer 2 refers to Ethereum’s computation layer. The principle is to move transaction execution off-chain for computation and then compress multiple transaction results into a single transaction that is sent back to the Ethereum mainnet for validation and final settlement. Through off-chain computation, Layer 2’s TPS can be several times higher than the mainnet. Additionally, because a single transaction returned to the mainnet consolidates multiple transaction details, the validation costs are shared among many users, reducing transaction costs and providing a smoother user experience. This has enabled Layer 2 to handle the substantial traffic and ecosystem load coming from the mainnet.

According to statistics from L2BEAT and Dune, as of the latest data (November 18), the Total Value Locked (TVL) in Layer 2 has reached $4.4 billion, with a total TPS of around 360. Over 90% of Ethereum’s ecosystem transactions are now conducted on Layer 2.

Figure 1: Layer 2 TVL and TPS, Source: L2BEAT

Figure 2: Ethereum Mainnet vs. Layer 2 Transaction Share, Source: Dune

However, currently, there are 52 Layer 2 solutions, including some that have not yet officially launched. The sheer number of Layer 2 projects has led to user fragmentation and liquidity being scattered across different platforms. To compete for users and funds, these platforms consume substantial resources. Users are also required to frequently transfer assets between different Layer 2 solutions, incurring additional transaction costs, while exposing their assets to greater risks during the transfer process.

Moreover, out of the 52 Layer 2 solutions, only 6 meet the first-phase security standards set by L2BEAT. This indicates that most Layer 2 solutions do not inherit Ethereum’s mainnet security adequately, and users’ funds could be frozen in the event of a Layer 2 failure.

(L2BEAT’s three-phase security standards for Layer 2:
Phase 0: The Layer 2 solution operates normally.
Phase 1: The project team relinquishes some control, allowing a certain proportion of external entities to participate, resulting in a higher level of decentralization. Users can decide whether to withdraw their assets.
Phase 2: Full decentralization, where anyone can participate and exit without permission.)

In light of these challenges, Gear Protocol has launched Gear.exe, a non-Layer 2 solution that significantly enhances Ethereum’s computational capacity—by over 1000 times—without sacrificing the security of the Ethereum mainnet, thus achieving a higher level of scalability.

Introduction to Gear.exe

Gear.exe, developed by Gear Protocol, is a decentralized computing network built on Vara Network (a Layer 1 released by Gear Protocol, which will be introduced later). Fully compatible with the Ethereum Virtual Machine (EVM), Gear.exe can be seen as an expansion suite for the Ethereum network. It supports infinitely scalable parallel execution, compensating for Ethereum’s own scalability limitations and delivering a low-latency, low-cost transaction experience. Importantly, Gear.exe is not a blockchain and does not generate its own blocks. Instead, it serves as an infrastructure that provides powerful computational resources, meaning it does not compete with existing Layer 2 solutions for users and funds, thus avoiding further fragmentation of assets.

The benefits brought by integrating Gear.exe include:

• Up to 1000x improvement in computational performance
• Reduction of Gas Fees by 90-99%
• Sub-second latency and fast transaction settlement (limited only by Ethereum mainnet’s block time)
• Web2-like user experience
• Optimized Rust development environment

Thanks to Gear.exe’s powerful computational resources, developers can outsource complex and computationally intensive tasks to Gear.exe, building DApps with intricate features and high computational demands. Use cases include DeFi, GameFi, AI, machine learning, zero-knowledge proofs, and oracles. This increases transaction efficiency, reduces costs, and further optimizes the user experience.

Regarding security, since Gear.exe is not a blockchain and lacks its own consensus protection, it introduces a re-staking protocol called Symbiotic. Through the re-staked ETH, Symbiotic provides sufficient economic security for Gear.exe, preventing malicious actions by validator nodes. This allows Gear.exe to provide an alternative scalability solution, different from Layer 2, that enhances Ethereum’s scalability without compromising decentralization or security while enabling more computation-heavy use cases.

Development History

Gear Protocol was launched in September 2021 as a Substrate-based smart contract platform, specifically designed for parallelized program development with multiple dedicated features, including the Actor Model, permanent memory, and WASM. It supports smart contracts written in various programming languages like Rust, Solidity, C, and C++, making it compatible with multiple blockchains and allowing cross-network deployment without the need to modify the contracts.

(Substrate: A modular development framework that facilitates the integration of multiple specialized blockchains, enhancing scalability.)

Initially, Gear Protocol served the Polkadot ecosystem. At the time, Polkadot’s relay chain did not support the deployment of smart contracts, so developers wishing to connect to the network had to deploy contracts on parachains or create a new blockchain and connect it to Polkadot. Due to the latter’s high cost, most developers chose to deploy DApps on parachains. Gear Protocol, being compatible with different programming languages and offering various infrastructure, became the platform of choice for developers. As a result, it became a hub for DeFi, DAO, NFT, and other DApp types, playing a key role in the Polkadot ecosystem.

In September 2023, Gear Protocol officially launched its independent Layer 1 network, Vara Network, developed based on the Substrate framework. Vara Network integrated all of Gear Protocol’s technologies and features, employing parallelized processes to significantly enhance network performance. It can also be upgraded without forks or downtime, and it focuses on reducing the development barriers for DApps, aiming to create a blockchain network with long-term sustainability through its robust infrastructure.

In October 2024, Gear Protocol launched Gear.exe, aiming to leverage Vara Network’s high-performance advantages to handle complex computational tasks for DApps and address Ethereum’s scalability challenges.

Team Background

Gear Protocol was launched in September 2021. The team comprises core developers from Polkadot and the Substrate blockchain development framework. With extensive experience in Web3, the team brings deep expertise in technology, finance, development, and sales.

Nikolay Volf, Co-founder and CEO, has been involved with Polkadot and Substrate since 2015. While working at the blockchain infrastructure company Parity Technologies, he introduced the first WebAssembly (WASM) smart contract.

Ilya Veller, Co-founder and CFO, has over 20 years of experience in the finance industry. He has held senior sales roles at institutions such as Bank of America, Morgan Stanley, Renaissance Capital, UniCredit, and ITI Capital, raising over $1 billion for various projects.

Aleksandr Bugorkov, Co-founder and CTO, brings extensive technical experience from companies like Lyft, New Relic, and Spotify, where he worked on innovative technology solutions.

Funding Status

In December 2021, Gear Protocol completed a $12 million funding round, led by Blockchange Ventures. Other investors included HashKey Capital, Lemniscap, and Three Arrows Capital.

How Gear.exe Works

Gear.exe supports parallelized programs, and its core technologies are based on several key components:

• Actor Model

In computer programming, an “Actor” is a fundamental computational unit that can send and receive messages. Actors can represent smart contracts or end users. In the Actor Model, the state between actors is kept private and can only be modified or communicated through message passing. This ensures privacy and security for each actor. All processes are asynchronous, meaning they are executed in parallel, enabling multiple tasks to be handled simultaneously without waiting for the result of a previous task.

To illustrate, imagine you are preparing both a steak and a salad. Normally, you would heat the pan and oil first, then while waiting for the pan to heat, you could start washing the vegetables. Once the pan is ready, you return to cook the steak, let it rest, and then go back to prepare the salad. This process is akin to parallel execution, where while one task is waiting for a result, another can be processed, greatly enhancing computational efficiency.

Moreover, to avoid confusion due to multiple messages arriving at the same time, an actor is restricted to handling one request at a time. For instance, if A wants to deposit $10 into an account while B wants to withdraw $5 from the same account at the same time, processing both requests simultaneously could lead to an incorrect account balance. Under the Actor Model, even if requests come in simultaneously, the system will execute them sequentially (e.g., handling A’s request first, then B’s) to ensure that the account balance remains consistent.

• Persistent Memory

Each actor’s state and the required data are stored within its own memory, rather than in external shared storage like hard drives or databases. This greatly reduces the need for API calls to interact with the blockchain, allowing data to be directly accessed from local memory, which reduces latency. Furthermore, the state of each actor is persisted, meaning that even if a smart contract pauses or the system is restarted, the actor’s state can be immediately restored.

Gear Protocol also uses Memory Virtualization technology, which tracks memory access behavior by programs to ensure that only the necessary data is read and saved. This minimizes the waste of computational resources, making the system more efficient.

• WebAssembly (WASM)

WebAssembly (WASM) is an isolated execution environment that allows smart contracts to run efficiently. It supports a wide variety of programming languages, so developers can use familiar development tools to deploy smart contracts on Gear.exe. This significantly reduces the deployment barriers, making it easier for developers to leverage Gear.exe’s computing power without learning new languages or frameworks.

Operation Process of Gear.exe

Figure 3, Gear.exe’s Operation Process, Source: Gear Protocol

Gear.exe provides developers with two main integration methods for interacting with its platform:

1. Native Integration
   In this method, dApps directly invoke the operational procedures of Gear.exe, without needing to send requests to Ethereum. This allows for real-time interaction with the system.

2. Event-based Integration
   In this model, Ethereum smart contracts emit events that trigger Gear.exe operations. When Gear.exe’s validators detect the event, they execute the corresponding process immediately. This enables a fully decentralized integration where Ethereum and Gear.exe can operate seamlessly.

Regardless of the integration method chosen, the operational process follows these steps:

Step-by-Step Process

1. Request Acceptance
   Upon receiving a request, Gear.exe’s validator nodes execute the dApp’s deployed program within the Gear environment. The nodes then sign the final computation result to ensure its validity.

2. Economic Security via Re-staking
   To prevent malicious behavior from the nodes, Gear.exe’s economic security is protected by the Symbiotic re-staking protocol. Additionally, Vara Network’s native token (VARA) staking participants contribute to the security. There are also penalty mechanisms in place to deter dishonest behavior.

3. Pre-confirmation
   After Gear.exe begins processing the request, it sends a pre-confirmation to the user. This pre-confirmation acts as a receipt, containing transaction details such as the sender, recipient, hash value, transaction fee, etc. It assures the user that the transaction will be processed and eventually finalized on Ethereum. The pre-confirmation is essential because the transaction data is still being processed, and the final settlement on Ethereum will take some time. By providing a pre-confirmation, Gear.exe allows dApps to avoid waiting for transaction finalization, delivering a faster user experience.

4. Results Aggregation and Uploading
   Approximately every 8 seconds, the sequencer collects all computational results (which may involve transactions from multiple dApps) and the latest state root. These results are then packed and uploaded to Gear.exe’s smart contract on Ethereum.

5. Updating dApps’ Smart Contracts
   The final transaction results are sent to the respective dApps’ smart contracts, updating their state roots with the latest data.

Key Features of Gear.exe’s Architecture

• Flexibility for Web3 Developers:
  The architecture and integration methods of Gear.exe offer Web3 developers greater flexibility, enabling them to choose between native and event-driven integrations based on their use case.

• Performance and Speed:
  By providing pre-confirmations and processing transactions off-chain, Gear.exe allows dApps to offer a much faster and smoother user experience, as users can immediately interact with the platform without waiting for the full transaction to be finalized on Ethereum.

• Security and Validation:
  The combination of re-staking, validator nodes, and penalty mechanisms ensures that the system is secure and that malicious actions are discouraged. The reliance on Ethereum’s mainnet for final settlement adds an extra layer of security, as Ethereum’s consensus is the final arbiter of the transaction’s legitimacy.

This approach, combining high performance, fast transactions, and robust security features, positions Gear.exe as a valuable tool for Web3 developers seeking to integrate off-chain computation with Ethereum in a scalable and efficient manner.

Comparison between Gear.exe and Layer 2

Both Gear.exe and various Layer 2 solutions aim to improve Ethereum’s scalability, enabling it to accommodate more users and applications. However, there are significant differences in how these two approaches are implemented. This comparison will focus on two critical aspects: security and performance.

Security

Both Gear.exe and Layer 2 solutions move Ethereum’s computation tasks off-chain and then package the transactions back onto the mainnet. This means that a significant portion of the transaction processing occurs off-chain, and it becomes crucial to ensure the security and consistency of the transaction data during off-chain computation to prevent malicious alterations by nodes.

• Layer 2 (e.g., Arbitrum): In Layer 2 solutions like Arbitrum, the computation process is protected by its own network consensus. Transactions are ordered by a centralized sequencer and then uploaded to the mainnet for settlement. Arbitrum uses an Optimistic Proof mechanism with a 7-day challenge period. The system assumes that all uploaded transaction data is correct but provides a window for anyone to challenge the transaction. If a challenge occurs, Ethereum validators are responsible for confirming the validity of the transaction. This design ensures that, even if Arbitrum’s network nodes are malicious, Ethereum can serve as a final line of defense.
• Gear.exe: Gear.exe lacks its own network consensus and instead relies on Symbiotic, which uses re-staked ETH to provide economic security. Transactions are first ordered by a centralized sequencer and then transmitted to the Ethereum mainnet. However, Gear.exe’s current documentation does not specify whether it employs mechanisms such as Optimistic Proofs or Zero-Knowledge Proofs (ZKPs) to verify that the data uploaded to Ethereum is correct. Therefore, the security of Gear.exe heavily relies on Symbiotic’s re-staking protocol. It remains unclear whether the security provided by this re-staking model can fully match Ethereum’s native consensus, as the re-staking mechanism leverages Ethereum’s security via smart contracts, introducing potential systemic risks.

Additionally, both Gear.exe and Layer 2 use a centralized sequencer to order transactions instead of relying on the network’s consensus. While this speeds up the network, it also grants the sequencer and the project team considerable power. In extreme cases, a project team could manipulate the transaction order to favor themselves and reject transactions that are detrimental to their interests. Layer 2 solutions like Arbitrum and Optimism provide an escape mechanism, allowing users to bypass the sequencer and submit transactions directly to the mainnet. However, Gear.exe does not have such a design.

Conclusion on Security:
Compared to Layer 2 solutions, Gear.exe’s security heavily relies on Symbiotic and lacks some countermeasures for extreme cases found in Layer 2 solutions. It is not as mature and well-structured in terms of security. However, Gear.exe may provide more details in future white papers to clarify its security model.

Performance

In terms of performance, Gear.exe and Layer 2 both return pre-confirmed information to users during transaction processing, indicating that the system has accepted the transaction and will process it. This lets users quickly receive initial transaction results and continue other operations without waiting for Ethereum to finalize the block, significantly improving transaction speed and efficiency. Additionally, Gear.exe and Layer 2 use centralized sequencers to order transactions, saving time on consensus formation and compressing multiple transactions into one. This reduces gas fees and allows Ethereum’s blocks to accommodate more transactions.

• Layer 2:
  Layer 2 solutions, such as Arbitrum, offer enhanced performance compared to Ethereum’s base layer by offloading computation. However, Layer 2 still faces some limitations in terms of scalability, as it generally supports linear transaction throughput improvements rather than exponential gains.

• Gear.exe:
  Gear.exe integrates several advanced technologies, such as Actor Model, Persistent Memory, and WebAssembly (WASM), to support parallel execution of tasks. This further optimizes computational efficiency and resource usage. The parallelization of processes allows Gear.exe to potentially provide a significantly higher network performance than Layer 2 solutions. Gear.exe claims that it can achieve 1000 times the computational power of Ethereum’s base layer, but whether this claim can be verified depends on future performance data and testing.

Conclusion on Performance:
While Layer 2 solutions already provide significant performance improvements over Ethereum, Gear.exe could offer even greater network performance due to its support for parallel execution. However, whether it can deliver the claimed 1000-fold improvement remains to be validated through data and real-world testing.

Prospects and Challenges

In simple terms, Gear.exe enhances performance through parallel execution, building on the existing Layer 2 infrastructure and positioning itself as an expansion module for Ethereum rather than a new blockchain. It focuses purely on providing computational services for DApps on other chains, avoiding the problem of asset fragmentation that comes with multiple Layer 2 solutions. In the future, Gear.exe could potentially replace some Layer 2 solutions, bringing Ethereum’s ecosystem back together. Additionally, with its high-performance capabilities, Gear.exe makes Ethereum more competitive against other performance-oriented public chains such as Solana, Sei, Sui, and Aptos.

However, whether Gear.exe’s operational performance and stability can truly meet the claims made remains to be seen. Furthermore, in terms of security, Gear.exe is protected only by Symbiotics and lacks many of the associated measures that existing Layer 2 solutions provide. There are design risks to consider, particularly when compared to the more mature security features of Layer 2 solutions. Security tends to be a higher priority for developers and users, especially considering the many incidents where hackers have stolen assets, including from large centralized exchanges. Given that Gear.exe is a fully code-driven on-chain protocol, its security must be proven to be robust and reliable, particularly in handling situations like downtime. This is an area Gear.exe will need to improve and strengthen to gain more market trust.

Conclusion

With the rise of blockchain technology and modular blockchains, the barrier to creating a Layer 2 has become increasingly lower, with many platforms offering “one-click chain creation” features. As a result, the number of Layer 2 solutions has expanded excessively, leaving Ethereum developers and users uncertain about which to choose. Each Layer 2 requires the creation of its ecosystem, but this merely replicates what other public chains have already gone through, which in some ways hinders innovation of new technologies.

Gear.exe offers a higher performance solution for DApps than Layer 2 and eliminates the need for migrating existing users and funds. By using re-staking for security, it provides a unique alternative for Ethereum’s scalability challenges. While this solution has not yet been widely adopted and must undergo market validation, it undoubtedly introduces fresh possibilities for Ethereum. Gear.exe could offer a more suitable solution for scaling Ethereum, and its future development is worth ongoing attention.