Litepaper

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 groundbreaking 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, various other Layer 1 (L1) and Layer 2 (L2) solutions have emerged. Most of the new L1 and L2 blockchain solutions have introduced various experiments using different consensus mechanisms, unique virtual machine technologies, or proof mechanisms. 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.

Most of the existing L1 solutions introduce only minor improvements on the EVM or set out to build a completely new virtual machine, which leads to huge problems in terms of adoption, tooling, and portability of existing products. On the other hand, 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 blockchain can double 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 leads to extreme inefficiencies and complicates asset transfers. Developers face increased complexity as they navigate varying protocols and standards without a clear solution on-site. This fragmentation also undermines composability, making it difficult to integrate and interact with various decentralized applications seamlessly.

An alternative approach to overcoming Ethereum's throughput limitations involves creating a new type of EVM chain designed explicitly for high throughput, real-time speed, and low costs. This requires a purpose-built system that addresses the primary bottlenecks of blockchain: fast finality, computational performance, low datastore size, and high data read / write speeds. By focusing on these key areas, it is possible to develop an EVM-based chain 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-throughput and low-latency EVM solution specifically engineered to meet the demands of the next decade. 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.

A key issue with any currently available EVM solution is the limited blockspace that ultimately limits the chain's throughput. Blockspace, measured in gas, is typically constrained, with most chains 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.

Blockspace can be increased by adjusting block gas limit and target. However, increasing these parameters 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 block production logic are the primary bottlenecks for any EVM-based chain scalability. These bottlenecks (discussed below) are state roots, transaction execution, consensus, and datastore issues like state growth, history growth, and data access.

Most of the current blockchains fall under two categories: either being an L1 or being an L2. L1s own both consensus and execution of transactions, while L2s mostly just own execution and proof generation and are heavily dependent on L1 for security, bridging, forking, and finality.

Most of the L1s have an inherent limit on how fast blocks can be produced, as block production requires consensus. Consensus usually means validating data on hundreds or even thousands of nodes. This means that this data has to be distributed all around the globe, and there are physical limits on how fast this can happen.

Most of the current L2s execute everything through a centralized sequencer and then produce proofs of execution that are later posted on some decentralized L1 like Ethereum. However, proof production can be pretty slow and compute-intensive when using ZK-powered technologies or impose significant security issues and finality overhead when using optimistic fraud proofs. Also, using multisig-controlled L1 smart contracts for bridging mostly reverts decentralization gains and robs chain users of the ability to implement any social fork (one of the core benefits of blockchain technologies). Finally, the usage of a centralized sequencer imposes huge liveness issues. While inherently a single block production leader is not an issue, the way it's being used in traditional L2 architectures means the whole network can go down in case of a single point of failure.

Heiko introduces a new and unique solution: an EVM chain with outsourced consensus. This means it can do centralized block production like an L2 but with decentralized validation like an L1. This combo allows us to get the best of both worlds: extreme performance, decentralization, sovereignty, and liveness while neither L1s nor L2s can achieve this combo.

Heiko's architecture can be split into two main parts: execution and consensus.

The unique aspect here is that both parts are running as two separate chains. Execution chain running a rearchitected and performance-tailored EVM execution client. It uses a centralized sequencer that produces blocks without any inherent consensus limitations. However, decentralization, liveness, and censorship resistance are still ensured by using a consensus chain.

While consensus chain is not a new concept, the unique aspect of Heiko is that it uses DA layer as its consensus chain without any extra L1.

While the execution chain is running a single sequencer, nodes use it only for faster block production, and finality always comes from the consensus chain. The sequencer always must post transactions to the consensus (DA) layer. However, even if the sequencer fails its duty to post the transaction batch, users can still post transactions directly to the consensus layer, and their transactions will get included by all the network nodes. This means sequencer is not able to censor any transactions. This property also means that even if the sequencer is down, people can still post transactions to the consensus layer, and they would still be included by the Heiko nodes, a unique property that enables unstoppable liveness. All of this is enforced by a consensus layer chain running a significantly decentralized consensus.

Decoupling from any other L1 smart contracts and not having any enshrined bridges means Heiko's community is sovereign and independent to update and fork without any multisig permission just like any other L1. Even the consensus layer can be changed if the majority of the node runners agree to do so. This is a huge benefit compared to L2 chains where any social fork without multisig approval would result in losing all bridged value.

The execution chain is responsible for producing new blocks by both pulling data from the sequencer and consensus chain. It's fully EVM compatible but introduces a bunch of new changes that enable this unparalleled performance. These changes are the key performance-unlocking solutions that make Heiko hundreds of times faster than any other EVM chain.

The major issue in any current EVM-based chain is state root production. State root is a field in a block header that represents the whole state of a blockchain at a given moment in time. In order to produce state root, one has to hash all the global state together; this includes hashing all global account balances and smart contract states. This is an incredible amount of data that has to be hashed for each single block. Even worse, as the blockchain state keeps growing, so does the state root computation time. While there are some ways to optimize it, it's just not a sustainable scheme for high-throughput chains.

Heiko Hash solves this by introducing a new lightweight hashing scheme. It uses an additive hashing technique that allows hashing only the delta - only the changes that happened in a single block instead of the whole global state. This solves multiple problems. First, the state growth impact is no longer an issue as global state size no longer impacts state hashing time as it uses only the delta. Next, access and retrieval of huge amounts of global state from the database is no longer needed as all the data that's needed is already in memory after EVM execution is done. Finally, this allows removing Merkle Patricia Trie (MPT) structure that's used for state roots and a simple key-value store can be used instead. This simpler way of storing data once again has an incredibly positive impact on data read and write speeds and also reduces database size significantly.

In summary, this lightweight hashing scheme does not merely improve, but actually completely eliminates the biggest EVM block production bottleneck.

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.

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.

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.

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 is partially solved by Heiko Hash, but can be improved even more by implementing the measures described below.

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.

In straightforward language, this EIP suggests implementing historical data expiration, which means that after a certain network-defined period (call it N), any data that has not been accessed for N amount 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.

Alongside, Heiko implements other EIPs, including:

Another item on Heiko's 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 (described in the section above), Heiko can also parallelize state access. This means that if accessing one piece of information takes time Tn and fetching another piece of information takes time Tn+1, and Tn+1 has a longer duration, our algorithm would fetch all data within the duration of Tn+1. In the current EVM implementation, the time taken is Tn + Tn+1 + ... + Tn+m where m is the number of data access calls per block.

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.

The speed of blockchains is constrained by the slowest component in their technical stack. By addressing multiple bottlenecks, as mentioned previously, Heiko anticipates achieving block times of 100ms. 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.

Heiko innovates on critical execution layer challenges by addressing blockchain state and computation-related issues. These advancements enable a system that can handle > 100k TPS with low cost and 100ms block times. With these improvements, Heiko aims to push the boundaries of what is possible on EVM, offering users a radically different efficiency, better user experience and significantly lower coststs.