Litepaper

Introduction

Within less than a decade, Ethereum has radically transformed the blockchain landscape, introducing the world to the concept of smart contracts and decentralized applications. Ethereum’s programmable blockchain enabled developers to create innovative solutions in areas such as decentralized finance (DeFi), non-fungible tokens (NFTs), stablecoins, and others. Yet despite its ground-breaking potential, Ethereum has faced significant challenges in scalability, with its throughput limited to approximately 15 transactions per second (TPS). This limitation has led to congestion and high transaction fees, hindering the widespread adoption and efficiency of decentralized applications.

To address Ethereum's scalability issues, Layer 2 (L2) solutions, such as rollups, have emerged. L2 solutions operate on top of the Ethereum mainnet, which means that they process transactions on the L2 chain before finalizing them on the main chain. Utilizing this approach has the benefit of increasing transaction throughput at the same time as reducing fees. More recently, the concept of Layer 3 (L3) solutions has been considered as one option to expand scalability further, with additional layers of protocols able to optimize performance and handle specific use cases.

Despite the advantages, the proliferation of numerous L2 and L3 solutions introduces several challenges. Each L2 solution, by default, inherits the limitations of Ethereum, meaning that, individually, they are not capable of supporting significantly higher TPS. For instance, even if an L2 doubles Ethereum's TPS, it would only support approximately 2.6 million transactions daily. This means that it only takes 260,000 users performing ten transactions daily to reach this limit and cause dramatic spikes in fees, negating one of the primary benefits of these scaling solutions. Additionally, the fragmentation of liquidity across different layers can lead to inefficiencies and complicate asset transfers. Developers face increased complexity as they navigate varying protocols and standards. This fragmentation also undermines composability, making it difficult to integrate and interact with various decentralized applications seamlessly. Additionally, relying on multiple layers introduces additional trust assumptions, as users must trust the security and reliability of each intermediary layer.

An alternative approach to overcoming Ethereum's throughput limitations involves creating a specialized Layer 2 solution designed explicitly for high TPS. This requires a purpose-built system that addresses the primary bottlenecks of blockchain execution layer scalability: datastore size and access speed, computational performance, and data availability. By focusing on these key areas, it is possible to develop an L2 solution that not only supports high transaction volumes at cheap prices but also maintains the security and decentralization principles of the blockchain.

We are proud to introduce Heiko, - a high-TPS parallel EVM Layer 2 solution specifically engineered to meet the demands of modern decentralized applications. Heiko provides unparalleled transaction throughput, reduced latency, and greatly enhanced scalability – key benefits required to overcome the arbitrary limits of existing blockchain infrastructure. Heiko aims to deliver a platform that empowers developers and users alike to continue innovating the blockchain ecosystem without being constrained by scalability issues.

Optimistic Rollups vs ZKP

Most current Ethereum Layer 2 solutions are based on either zero-knowledge or optimistic rollups. Zero-knowledge rollups require significant computations both off and on-chain but allow for immediate bridging to and from the L2 chain. Conversely, optimistic rollups necessitate fewer computations both off and on-chain but entail longer off-ramping from L2 to L1, as L2 states only finalize after a few days. During this period, any L2 participant has a window to challenge the state by providing fault proofs (also known as fraud proofs). While ZK rollups inherently offer greater security, optimistic rollups dominate the market in terms of transactions per second (TPS) and total value locked (TVL). Because they are less mathematically intensive, optimistic rollups are thus more scalable and easier to maintain and build upon. This is why Heiko is using optimistic rollup technologies based on the Optimism stack.

Data Store

In every EVM-based blockchain, data can be broadly categorized into two main types: state and history. State data encompasses all the information stored within smart contracts, including their bytecodes and account information. On the other hand, historical data comprises information about all transactions, blocks, and related metadata. While historical data primarily serves the purpose of consensus validation or recalculating historical states, state data is utilized for EVM operations to read and update various on-chain variables. Both state and history growth are controlled by blockspace.

Blockspace

A key issue with any currently available EVM L2 solution is the limited blockspace that ultimately limits the chain's throughput. Blockspace, measured in gas, is typically constrained, with most L2s supporting only around 30-60M gas per block and 2-second block times. While there are outliers that support up to 100M gas, this figure, when translated to transactions per second (TPS), remains relatively low compared to chains like Solana.

Due to limited blockspace, even a slight increase in blockspace demand (whenever blockspace demand exceeds blockspace supply and block gas limit is reached) leads to a dramatic rise in gas prices. This unstable gas fee market and low throughput hampers the growth of economic activity and adversely affects every user on the chain, particularly those not vying for time-sensitive opportunities.

2024-03-26. Base L2: Gas Used vs Base Fee. https://dune.com/queries/3671172/6174278/

Layer 2 solutions, which do not require elaborate consensus mechanisms like the Ethereum Layer 1, can adjust the gas block limit to enable more blockspace. However, increasing this limit is not a straightforward task, as it carries the risk of allowing more transactions than the network can effectively process.

After trying to solve the throughput issue by simply increasing the gas limit, it quickly becomes clear that the EVM and transaction processing logic are the primary bottlenecks for Layer 2 scalability. These bottlenecks (discussed below) include datastore (State growth, History growth, State access), State Root Calculation Parallelization, Parallelization of EVM Transaction Execution, Data availability layer throughput, and EVM interpreter optimization.

State Growth

Blockchain state is the sum of all data related to smart contracts and accounts. The blockspace limits discussed above serve to cap the rate of growth of the blockchain's state. Uncapped growth is unfeasible because an increase in state size necessitates an increase in node disk space. The degree of decentralization aspired to achieve is inversely proportional to the hardware requirements. Ethereum maintains a relatively low state size (approximately 246 GiB at the time of writing), and its low block gas limit enables it to sustain this size for many years to come. Conversely, approaches like Solana's prioritize state growth by sacrificing low disk space requirements, necessitating nodes to run specialized hardware. Different solutions optimize for various network aspects, such as consumer hardware support versus speed.

Nevertheless, as blockchain state size increases, data access and updates become progressively slower. To maintain stable transaction processing speed amidst state growth, one must not only expand disk size but also continuously augment available RAM and CPU cores. While Ethereum's state growth is gradual, these hardware requirements evolve relatively slowly. However, any chain with a radically higher block gas limit would prompt these hardware requirements to escalate rapidly.

To address this challenge, Heiko proposes altering node software to efficiently handle data access and updates even with large state sizes. This can be achieved by implementing the measures described below.

Utilizing a Specialized Database for Data Storage

It is crucial to employ a database specifically tailored for blockchain applications, as conventional databases may not be optimally suited for this purpose. There is an opportunity not only to enhance data access speeds but also to reduce state size by altering how data is indexed and stored. This can be achieved by abandoning the database's internal indexing structure and adopting the EVM's trie structure as a native indexing method. This approach conserves data by eliminating redundant native index data and enhances speeds by eliminating the need to iterate through multiple indexing structures when searching for data.

History growth

Another crucial aspect of blockchain data is a historical state, which comprises all blocks and transactions from the genesis block to the present. Historical data exhibits a higher growth rate and consumes more space than state data, with Ethereum's historical data nearly reaching 1 TiB at the time of writing. Addressing historical state growth can be fully resolved by the EIP-4444, which is among Heiko's top priorities following the initial launch.

However, alongside solving this issue, Heiko implements other EIPs, including:

• EIP-4488. This EIP limits the amount of calldata that can be used in a transaction.

• EIP-7623. This EIP adjusts the pricing of calldata so that transactions with heavy calldata usage are priced more aggressively.

EIP-4444

In straightforward language, this EIP suggests implementing historical data expiration, which means that after a certain network-defined period, data that's older than this period of time would be archived and relocated to another storage area outside of the main storage. This feature is beneficial because it prevents the network from expanding indefinitely and helps maintain storage space by clearing out unused or outdated data. While Heiko will not implement this immediately upon the network's mainnet launch, it needs to be incorporated shortly afterward, especially considering our projections for significant historical growth based on transaction fees and latency.

State Access

Another item on our roadmap is state access parallelization. Currently, each EVM transaction fetches information from the database and subsequently updates that information in a sequential manner. However, by parallelizing the EVM (more on that in another section), Heiko can also parallelize state access. This means that if accessing one piece of information takes time $T_n$ and fetching another piece of information takes time $T_{n+1}$, and $T_{n+1}$ has a longer duration, our algorithm would fetch all data within the duration of $T_{n+1}$. In the current EVM implementation, the time taken is $T_n + T_{n+1} + <...> + T_{n+m}$where $m$ is the number of data access calls per block.

Caching

While the state data continually grows, the size of the actively used state is significantly smaller. This is because many smart contracts, accounts, and their related data are either no longer in use or are used very infrequently. Consider, for instance, a company's treasury multi-sig smart contract versus Uniswap's ETH/USDT pool smart contract on Ethereum. Clearly, the former is seldom utilized, whereas the latter may be updated in almost every block. However, they are currently treated equally in terms of data storage and access.

Heiko implements a smart caching layer that identifies and moves actively used storage variables into RAM. This approach allows us to drastically reduce access times for variables that are frequently accessed. For instance, if accessing one variable in a block occurs $N$ times and Heiko can reduce its access time by $M$, Heiko can potentially save up to $(N-1) * M$ time per block in the worst-case scenario, and $N * M$ in the best case scenario if that variable has already been cached in the previous block.

Hardware

The expansion of state, caching, and parallelization necessitates higher hardware requirements compared to a simple consumer-grade machine. While this could potentially decrease decentralization on Ethereum, it does not adversely affect optimistic Layer 2 solutions. The primary reason for this lies in the capability to prove any faults occurring on L2 through L1 smart contracts. Essentially, this means that a single honest actor running a node could outperform an entire network of malicious nodes. Consequently, there is no imperative for the validator set to be as extensive as Ethereum's, as there is no feasible way for a malicious actor to overpower the honest nodes by running more nodes.

State Root Calculation Parallelization

The state root, or Merkle root, is the hash of all the hashes of transactions within a block in a blockchain network. It is essential for verifying new blocks and state transitions and is mandated by the Ethereum consensus specification for each block. However, optimistic Layer 2 (L2) solutions operate without Ethereum-level consensus and typically only post these state roots to Layer 1 (L1) when closing batch channels. Despite this, L2 block validation may still require these hashes for validation.

Heiko proposes a modification to this mechanism to reduce the frequency of state root calculations and enable them to run in parallel with other block processing logic. This adjustment would streamline the validation process and enhance the efficiency of Layer 2 block validation.

Parallelization of EVM Transaction Execution

A significant bottleneck in EVM-based transaction processing is the algorithm that sequentially picks and processes transactions. This implies that the EVM processing logic does not leverage the multicore computing paradigm, as everything operates on a single thread (CPU core).

Heiko introduces a parallel EVM inspired by the concepts outlined in the Block-STM paper. Essentially, when a new block arrives, all transactions within that block will be distributed to different threads (CPU cores). This approach could potentially lead to an N-fold increase in transaction processing speed, where N represents the number of CPU cores available on the underlying machine.

While some transactions may still need to be processed sequentially due to potential data integrity concerns (such as MEV sandwiches), the overall throughput will see a significant boost, as described in the Block-STM paper.

EVM Interpreter Optimizations

In EVM bytecode execution, instructions are typically processed sequentially through an interpreter, which operates at the VM layer rather than directly through the assembly. This intermediary VM layer introduces overhead, slowing down the processing of transactions. Heiko introduces Ahead-of-Time (AOT) compilation, which precompiles smart contracts into machine code. By bypassing this VM layer, the overhead can be avoided, resulting in a potential doubling of instruction processing speed and yielding significant performance benefits.

Data Availability

In optimistic Layer 2 (L2) solutions, data availability is crucial to ensure that the necessary data for fault proofs is accessible to everyone in a permissionless manner. This data typically consists of compressed transaction blobs.

Initially, many L2s used Ethereum's calldata to post these compressed transactions. However, this approach proved to be costly due to Ethereum pricing it the same as any other transaction. Consequently, several data availability solutions emerged, including Ethereum's own blob storage implementation. However, Ethereum's blob storage has limited throughput, currently supporting only up to 64KB/s. Moreover, this throughput is shared among multiple L2s, further reducing the available bandwidth for individual L2s.

Heiko leverages the Eigen Data Availability Layer for its blob storage needs. Eigen has emerged as one of the prominent projects in the crypto space, with its Active Validated Services being protected by over $15 billion in assets at the time of writing. Eigen's Data Availability mainnet is expected to have an initial throughput of 10MB/s, with plans to support up to 100MB/s in subsequent phases.

Other L2 Components

Heiko's focus is primarily on optimizing the execution layer of the L2 stack, while the other components largely remain unchanged from the current setup on the Optimistic Stack. These components include:

• Governance layer utilizing multisig of multisigs.

• Optimism's Stack smart contracts.

• Optimism node and sequencer part related to settlement and bridging.

Cost Reduction

The operational expenses incurred by L2 rollups contribute to the overall transaction costs and include:

1. Posting state root to L1, which currently costs ~100 000 gas, approximately $1.45, with a gas price of ~5 Gwei as of writing this.

2. Price surges due to the EIP-1559 pricing mechanism, particularly in L2s with low block gas limits and targets.

3. Pricing of blobs, which varies based on supply and demand in Ethereum's blob market.

4. Infrastructure running costs.

5. Revenue sharing with Optimism Collective for sequencer usage.

Heiko aims to reduce these costs through the following measures:

1. Rollups benefit from increased usage, as the cost of posting state roots to L1 remains constant regardless of L2 usage levels. Therefore, higher usage leads to a lower fraction of this cost per transaction for all users.

2. Heiko plans to increase gas availability in each block by at least 100x, ensuring greater resilience against pricing spikes induced by high usage.

3. Eigen Data Availability (DA) offers a more stable and cost-effective solution for blob storage compared to Ethereum's current pricing model, which is expected to become even more favorable as demand for blobs increases.

4. Infrastructure expenses do not increase linearly with usage, meaning higher usage does not necessarily translate to proportionally higher infrastructure costs. This allows for a higher margin between transaction revenue and operational expenses, enabling reductions in transaction costs.

All of the above enable Heiko to lower transaction costs by around 100x.

Speed and Latency

The speed of blockchains is constrained by the slowest component in their technical stack. By addressing multiple bottlenecks, as mentioned previously, Heiko anticipates achieving sub-second block times. Initially, Heiko aims for block times of 500ms, with the potential to further reduce this figure. Consequently, users can expect their transactions to be included in blocks almost instantly, with block inclusion times approaching network latency times. This advancement ushers in a new era of on-chain interactivity, revolutionizing user experiences on the blockchain.

Summary

Heiko innovates on critical execution layer challenges by addressing blockchain state and historical data issues and parallelizing the EVM. These advancements enable a system that can handle ~100k TPS with sub-cent transaction cost and sub-second block times. With these improvements, Heiko aims to push the boundaries of what is possible in Layer 2 solutions, offering users a radically different efficiency, better user experience and significantly lower costs.