Preconfirmation (feat. Taiko): Make Ethereum Fast for the First Time!

Key Takeaways

• Taiko is a base rollup-based Layer 2 network aimed at full interoperability with Ethereum and decentralization of the sequencer. To address the issue of delayed final confirmation of transactions in the rollup mechanism, it has introduced the concept of “Preconfirmation”. Preconfirmation aims to improve user experience by pre-assuring users of transaction inclusion and order, thus mitigating inefficiencies in the rollup finalization process.

• In the based preconfirmation model, L1 validators provide transaction outcome guarantees to users. Preconfirmers stake deposits and follow slashing policies, enhancing the reliability of the system. L2 projects like Taiko seek to establish reliable transaction finality through preconfirmation, creating a more convenient environment for services like DeFi, where real-time confirmation is critical.

• Several projects are currently participating in the formation of a preconfirmation ecosystem. This technological advancement is expected to enhance the efficiency of the Ethereum L2 ecosystem, strengthen interoperability with Ethereum, and contribute to the overall expansion of the ecosystem.

Taiko is steadily progressing toward its ultimate goal of becoming a true L2 solution for Ethereum. To achieve this, Taiko has prioritized maintaining full interoperability with Ethereum, decentralizing its sequencer, and fully supporting builders. Notably, Taiko enables full interoperability with Ethereum through a based rollup structure while also allowing anyone to participate as a sequencer, thus achieving decentralization of the sequencer. However, despite the advantages of based rollups, they still retain some inefficiencies inherent to the fundamental structure of rollups.

This article will explain preconfirmation, which rollups, as an essential component of the L2 technology stack, must prepare for as the next step, using Taiko as a case study.

1. Current Issues with L2 Efficiency

As the L2 ecosystem expands, numerous projects have emerged, along with new concepts and technology stacks. However, despite these advancements, there remain persistent inefficiencies that L2 has yet to resolve. Efficiency improvements are particularly needed in areas that directly impact user experience.

1.1 Fundamental Limitations of Rollups - Inefficient Transaction Finality Process

L2 achieves scalability through rollups that rely on L1 platforms like Ethereum for data availability and transaction processing. However, rollups face an inherent limitation: while they can handle transaction ordering and execution independently, all other processes must wait until finalization is confirmed on L1.

This structure ensures security and data immutability by directly leveraging L1’s block generation and data availability. However, the reliance on L1 for finalization often results in slow transaction processing and limited real-time confirmation from a user’s perspective.

Additionally, many L2 sequencers and validator nodes are currently centralized. This centralization can lead to inefficiencies, such as long transaction finality times and operational interruptions, causing delays in transaction processing and confirmation on some rollups.

1.2 Emergence of the Preconfirmation Concept

The concept of preconfirmation emerged as a solution to the inefficiencies in transaction finality within L2 networks. Preconfirmation provides an intermediary confirmation process that allows users to experience faster transaction finality, alleviating the delays and inefficiencies often seen in rollup mechanisms.

1.2.1 What Problems Was It Designed to Solve?

Inefficiencies in rollups have persisted, especially in providing certainty for users after submitting transactions to L2. Centralized L2 sequencers often cannot guarantee when a transaction will be included on L1, leaving users uncertain about the order and outcome of their transactions. For example, users must often wait pointlessly for their transactions to be included on L1, and if transactions are not ordered as expected or yield unfavorable results, users may face financial losses from transactions that have already been executed.

This issue is particularly challenging in highly volatile markets where users rely on arbitrage or DeFi services. Delays or changes in transaction order due to these inefficiencies may lead to missed opportunities. Even regular users processing standard transactions may lack confidence in how and when their transactions will be finalized on L1, raising concerns about blockchain reliability and ease of use.

Preconfirmation thus aims to address these limitations, particularly for users who are most affected by rollup inefficiencies, by providing a more seamless and reliable transaction experience.

1.2.2 How Does It Aim to Solve the Problem?

Preconfirmation provides a technical solution that guarantees users the inclusion, order, and execution of their transactions. It achieves this by offering users a “soft guarantee” through a centralized L2 sequencer, which issues a preconfirmation receipt as an assurance of eventual L1 inclusion.

The main advantage of preconfirmation through soft guarantees is improved user experience. Users can receive an immediate confirmation receipt upon submitting a transaction, assuring them that their transaction will be included on L1 as anticipated. This reduces uncertainty for users, especially those performing time-sensitive trades like arbitrage, enabling them to react quickly.

Furthermore, preconfirmation strengthens trust between users and the L2 system. As users gain confidence that their transactions will be processed safely through soft guarantees, the overall utilization of the L2 ecosystem can increase. Preconfirmation thus plays a critical role in enhancing the efficiency of rollups and making transaction processing more user-friendly.

1.2.3 Is This the “Endgame” for Preconfirmation?

However, this form of preconfirmation faces its own challenges. Although soft guarantees from a centralized sequencer improve the user experience by assuring the expected order and outcome, they rely on trust in the sequencer. Without legal or technical enforcement, users must depend on the sequencer’s reliability. This reliance leaves open the possibility that transactions may not be included in the correct order or may not make it to L1 at all, potentially failing to provide the solid guarantee users seek.

2. Based Preconfirmation (feat. Taiko)

Efforts to address the limitations of existing preconfirmation models for Ethereum L2s and achieve a true "endgame" for transaction speed improvements have led to the introduction of a new approach: "Based Preconfirmation." Originally proposed by Justin Drake, this concept is specifically optimized for based rollups. To illustrate, we’ll examine Taiko, an L2 solution aiming to leverage the strengths of based rollups, as an example.

Taiko is deeply invested in implementing based preconfirmation because it aligns with the core characteristics of based rollups. Should based preconfirmation become well-established within Taiko’s framework, it would significantly enhance the user experience by minimizing transaction finality delays. This would also enable a variety of previously dormant services to function effectively on Taiko, prompting continuous research into this concept within the network.

To better understand based preconfirmation, let’s first revisit some of the key features that define Taiko.

2.1 Taiko as a Based Rollup

As the chapter title suggests, Taiko embodies the characteristics of a based rollup. Not only does Taiko achieve complete interoperability with Ethereum’s infrastructure, but it also aims to fully align with Ethereum’s security mechanisms. Taiko employs a based rollup model, which means it lacks a centralized sequencer and instead relies on Ethereum’s validators to also serve as its sequencers, handling transaction and block sequencing.

With this based rollup model, Taiko’s sequencers are the same entities that propose blocks on Ethereum. This setup brings particular responsibilities and incentives, such as Ethereum’s Maximal Extractable Value (MEV) rewards and the benefits of holding a sequencer role. Consequently, if any issues arise from L2 sequencing on Taiko, these sequencers are naturally accountable due to their stake in Ethereum, setting Taiko apart from other Ethereum L2s in terms of operational responsibility.

Notably, Taiko’s based rollup is structured as a Based Contestable Rollup (BCR), which fosters healthy competition. This design encourages decentralization and ensures that anyone can participate, making the system fair and transparent by allowing for open and permissionless operation.

2.2 Based Preconfirmation for Based Rollups

So, what does a preconfirmation model specifically tailored for based rollups look like? The answer lies in "Based Preconfirmation," which aims to replace traditional soft guarantees with verifiable assurances directly on L1.

Based Preconfirmation provides a system where certain L1 validators voluntarily participate in offering preconfirmation services. Acting as sequencers, these validators provide users with a verifiable prediction of the rollup transaction outcome. This approach allows users to receive a credible guarantee of transaction inclusion and order, grounded in L1, enhancing trust and reliability in the rollup process.

Justin Drake, who first introduced the concept of Based Preconfirmation, proposed that a specific role, the "Preconfer," could provide users with a signed guarantee for transaction order and execution status. To ensure their commitment, each Preconfer must post a certain amount of collateral. If they fail to uphold their guarantee regarding transaction order or execution state, they face a penalty called "slashing," in which they lose part or all of their collateral. Slashing, commonly used in services like Ethereum’s Proof-of-Stake staking, prevents malicious or negligent behavior and fosters trust between Preconfers and users in Based Preconfirmation.

Two situations can lead to slashing penalties for Preconfers:

• Liveness Faults: These occur if the Preconfer, for any reason, fails to include a user’s preconfirmed transaction on-chain. Since liveness faults may not always be intentional, the penalty is relatively mild. Unintentional failures could stem from network issues or disruptions in the L1 or L2 blockchain, preventing transactions from being included on-chain. To protect honest Preconfers from undue punishment, the penalty amount for liveness faults is set through mutual agreement between the user and the Preconfer.

• Safety Faults: These incur harsher penalties and occur when a preconfirmed transaction does get included on-chain, but with a different outcome than the original user request. Since this misalignment is entirely the Preconfer’s responsibility, safety faults typically result in the full forfeiture of the Preconfer’s deposit, regardless of intent, as no other party is accountable.

To become a Preconfer in Based Preconfirmation, a node—assuming it is an L1 block proposer—must agree to these slashing conditions and post the required collateral. Once approved, the Preconfer can begin offering preconfirmation services to users and earn fees in return.

This fee structure provides significant convenience for users, allowing them to bypass the inherent delays in rollup transaction finality. For example, users who request a preconfirmed transaction through their wallet can receive an immediate confirmation receipt from the Preconfer, securing the transaction’s order and content with greater certainty.

By participating in Based Preconfirmation, Preconfers gain additional revenue opportunities through fees, making this model attractive to sequencers within based rollups. This design not only enhances user experience but also strengthens the overall L2 ecosystem by providing a reliable and efficient transaction finality process.

So, why do users pay fees to Preconfers for preconfirmation?

This essentially ties back to the core purpose of preconfirmation itself. Users are willing to pay for preconfirmation because it offers them greater convenience by addressing a fundamental limitation of rollups—the inefficiency in the transaction finality process.

For example, consider a user submitting a preconfirmed transaction via a personal wallet on an L2 blockchain. While standard transactions await final confirmation, the user who requests preconfirmation receives an immediate guarantee from the Preconfer, allowing them to complete the transaction without delay. This user may even see a reassuring green checkmark in their wallet, indicating the transaction’s success.

Another example is in DeFi services. When a user performs a token swap on an L2 DeFi platform, they can use preconfirmation to secure a transaction related to the swap. Normally, there may be a delay between the quoted exchange rate or fees and the actual finalized transaction, leading to discrepancies. However, preconfirmation ensures a fast and efficient transaction finality process, reducing the potential mismatch between expected and actual swap conditions, thus offering users a more reliable service.

These examples benefit both developers, who can provide more precise services, and users, who enjoy a more convenient experience. This dynamic not only supports the expansion of the L2 ecosystem but also contributes to the broader L1 ecosystem growth. Furthermore, for sequencers in based rollups, the additional income from preconfirmation fees offers a compelling revenue model, addressing one of the traditional weaknesses of based rollups and making it an attractive option for sequencers.

2.3 Challenges of Based Preconfirmation

Based Preconfirmation remains an area of active research for rollup-based Layer 2 (L2) projects like Taiko, as it offers a clear solution to enhance L2 performance and scalability while maintaining decentralization. However, despite its potential benefits, Based Preconfirmation faces several challenges that need to be addressed for broader adoption.

First, users may lack absolute certainty about the inclusion of their transactions at the time Preconfers submit them to a block. While Preconfers post collateral as a guarantee, there is still no complete solution to external disruptions that may prevent transaction inclusion. In particular, if a transaction carries a value higher than the Preconfer’s posted collateral, there remains a risk that the Preconfer could abuse their role by selectively including or excluding certain transactions.

Another challenge involves the profitability of Based Preconfirmation. The primary revenue source for Preconfers is the preconfirmation fee collected from users. However, if there is a lack of diversity among Preconfers or insufficient participation, monopolistic tendencies could arise, potentially allowing Preconfers to impose higher fees on users. This could make fast and efficient transactions more costly for users, potentially hindering the healthy growth of the preconfirmation ecosystem.

Since Based Preconfirmation is relatively new, having been introduced only about a year ago, it may take additional time to become the "master key" for maximizing the speed and efficiency of rollup-based L2 solutions. Nonetheless, with rollups now solidly established as a core component of Ethereum scalability, the exploration of preconfirmation as a means to further improve performance marks an important step forward in the evolution of L2s.

Taiko, in particular, has taken significant steps toward implementing Based Preconfirmation, with contributions from partners like Taiko Gwyneth, Nethermind, Chainbound, Limechain, Primev, and Espresso. These collaborations aim to shape the next phase of L2 evolution, with more details to be explored in the following chapter.

3. Supplychain of Preconfirmation - Flow Chart Focus

In this chapter, we will explore which projects are actively engaged in researching and advancing preconfirmation within the rollup-based L2 ecosystem. Since this ecosystem is still in its early stages, a flow chart will be used to provide a clearer understanding of the preconfirmation process.

3.1 Preconfirmation Flow Chart

First, let me introduce the preconfirmation flow chart. Preconfirmation is a process where L1 and L2 must operate cohesively, involving multiple roles with specific responsibilities, making it quite complex. Thus, I prepared this flow chart to provide an easy overview of the process. Note that this flow chart was created for smooth explanation purposes, so it does not distinguish between rollup and based-rollup but serves as a fundamental-level flow chart.

Before following the flow of the flow chart, let’s look at each role and its functions:

• User: An individual using the L1 or L2 network, creating and submitting transactions. If a user desires a preconfirmed transaction, they write the transaction and send it to the preconferrer.

• Preconferrer: Responsible for preconfirmation of transactions during the preconfirmation process. The preconferrer reviews the proposed transaction to verify its validity, providing a preconfirmation guarantee. Through this, users can receive a quick assurance of the transaction's final status before its final settlement. Nodes without preconferrer qualification act as Non-Preconf Actors, handling general transactions rather than preconfirmed ones, similar to standard validators.

• L1 Validator: Responsible for final verification of transactions and blocks on the L1 network. Once data is submitted by the preconferrer, the L1 Validator ultimately verifies it and records it on the L1 blockchain, ensuring the integrity of the transaction and compliance with consensus rules.

• Preconfirmation Challenge Manager: Handles any disputes or challenges that arise in the preconfirmation process, investigating issues and taking appropriate actions. This role helps maintain the reliability and integrity of the preconfirmation process.

Now, let’s look at the preconfirmation flow chart in order:

1. The user sends a transaction request to the preconferrer within the preconfirmation actor.

2. The preconferrer reviews the transaction and sends back a preconfirmation, effectively a guarantee that the transaction will be included in the L1 block, allowing the user to preliminarily secure final confirmation.

3. The preconferrer sends the transaction data that should be included in the L1 block to the L1 Validator. This data can be in the form of individual transaction data or rolled-up data processed by the sequencer on L2.

4. The L1 Validator includes the transaction data or rolled-up data in the L1 block.

5. After a certain period, the finality of the L1 block containing the transaction data or rolled-up data is confirmed.

6. The user can optionally check the finality result through the L1 node and use this information, if needed, for any preconfirmation challenges.

If a condition violation occurs, such as the user’s transaction not being properly included on L1, the preconferrer may face penalties like slashing or freezing of its deposit, imposed by the Preconfirmation Challenge Manager.

3.2 Related Projects

Let’s take a closer look at the specific projects actively participating in the preconfirmation ecosystem, along with their associated roles within the flow chart. While these projects are aligned with certain roles in the flow chart for explanatory purposes, the actual roles they perform may vary slightly. Therefore, this overview is intended to provide a foundational understanding and should be considered as a general guide. The projects are listed in alphabetical order within each category for clarity.

3.2.1 Preconfer Validators

• Astria: Astria is a project aiming to replace centralized sequencers with a decentralized sequencer network shared across multiple rollups. This setup allows rollups to benefit from enhanced censorship resistance, fast block finality, and seamless cross-rollup interactions. To achieve quick block finality, Astria supports preconfirmation functionality, enabling rollups to offer rapid transaction confirmation and censorship resistance, ultimately improving user experience.

• Bolt by Chainbound: Bolt is a preconfirmation protocol developed by Chainbound, providing Ethereum users with near-instant transaction confirmations. Bolt operates on untrusted participation and economic collateral and is compatible with the current MEV-Boost PBS pipeline, offering new revenue opportunities for proposers. The primary feature, L1 preconfirmation, enhances user experience by providing immediate finality for basic transactions like transfers and approvals. This system shifts transaction inclusion responsibility from centralized block builders to proposers, improving censorship resistance. Bolt also establishes a trustless system via economically collateralized proposer registration and is designed to support various contract types flexibly.

• Espresso System: Espresso System is a protocol designed to enhance interoperability across blockchain ecosystems. It utilizes a Byzantine Fault Tolerant (BFT) consensus protocol called HotShot, enabling rapid finalization of transaction order and data across multiple chains. Espresso System comprises the Espresso Network and Espresso Marketplace, which together provide fast transaction finality and efficient interoperability, aiming to improve scalability and security within the blockchain ecosystem.

• Ethgas: Ethgas is a marketplace for trading block space, with transaction matching managed centrally while on-chain processes are handled through smart contracts. Ethgas offers two main features: inclusion preconfirmation, which guarantees transaction inclusion within a specified gas limit, and execution preconfirmation, which ensures the transaction reaches a specific state or outcome. Ethgas aims to protect transaction privacy in block space trading and operates with a goal of neutrality.

• Luban: Luban is developing a decentralized sequencing layer to connect transaction data between the Ethereum network and rollup chains. This sequencing layer is designed as a decentralized system that separates proposal and execution roles. Luban’s preconfirmation feature enhances reliability by ensuring transaction executability before inclusion on the Ethereum network, helping to optimize factors like transaction fees, gas prices, and MEV across the block space.

• Primev: Primev is developing an MEV commit network that integrates preconfirmation with MEV, creating a peer-to-peer network where MEV intermediaries can collaborate efficiently and reliably. This network logs commitments for Ethereum transaction execution and applies reward or penalty mechanisms for providers, allowing MEV participants to set specific execution conditions for their transactions. Block builders and validators can then commit to these conditions. Primev ensures transaction preconfirmation, providing rapid transaction processing for users. Additionally, based on EIP-4337, it supports flexible preconfirmation and gas fee options for any transaction type, enhancing user experience.

• Puffer Unifi: Puffer Unifi’s Actively Validated Services (AVS) is a solution built on EigenLayer to address preconfirmation challenges in the Ethereum ecosystem, particularly within based rollups. Puffer Unifi AVS leverages EigenLayer’s restaking functionality to create a preconfirmation participation mechanism aimed at improving transaction finality efficiency. As based rollups grow, there will be increasing demand for reliable preconfirmation providers, and Puffer Unifi AVS aims to fulfill this role. Its ultimate goal is to implement preconfirmation without altering core protocols, thereby contributing to the sustainable growth of the Ethereum ecosystem alongside EigenLayer.

• Skate: Skate’s preconfirmation AVS leverages restaked assets on EigenLayer to ensure economic security for all cross-chain operations. The AVS verifies the bundled data and information needed for users to complete cross-chain transactions, which is then signed and prepared for execution by the Skate relayer. Through this process, Skate AVS preconfirms data, enhancing the reliability and efficiency of cross-chain transactions.

• Spire: Spire’s Based Stack is an Ethereum-based rollup framework that enables developers to build and operate application-specific chains (app chains). This framework allows app chains to interact directly with Ethereum and customize sequencing methods, supporting features like cross-chain swaps and improving user experience through preconfirmation. It supports various execution environments, ensures app chain sequencing revenue, and maintains compatibility with traditional shared sequencers. Provided as open source, the Based Stack offers developers all necessary tools and resources to build and manage app chains, promoting app chain development and interoperability within the Ethereum ecosystem.

• Taiko Gwyneth: Taiko Gwyneth is a rollup design under development by Taiko, classified as a based rollup. It aims for full interoperability with Ethereum and manages transaction sequencing directly on Ethereum. This approach leverages Ethereum’s security and decentralization while providing high throughput and rapid finality. Currently, Taiko operates proposers to assist with block creation and is exploring preconfirmation mechanisms to promote profitable block production within the community. This mechanism aims to optimize block timing and data publishing efficiency. Taiko is collaborating with projects like Nethermind and Gattaca to achieve these objectives.

3.2.2 L1 Validator

• Chorus One: Chorus One is a project offering validation services and infrastructure for blockchain networks, operating staking services across various protocols to enhance network stability and security. As an L1 validator, it verifies transactions and produces blocks, boosting network reliability and efficiency. Recently, Chorus One has shown significant interest in preconfirmation, even hosting related events at Devcon 2024.

3.2.3 Research

• Nethermind: Nethermind develops Ethereum clients and tools, focusing on blockchain performance and stability improvements. By introducing optimization technologies, Nethermind works to increase transaction throughput on the Ethereum network. They produce ongoing research on preconfirmation and recently submitted a proposal to Taiko’s grant program to fast-track preconfirmation on the Taiko mainnet. This proposal expands on Nethermind’s RFP-001 project, with the goal of deploying preconfirmation infrastructure in two phases. Phase 1 introduces preconfirmation to a limited group of authorized participants, with plans to gradually expand its application in Phase 2.

4. Looking Ahead

Taiko and various rollup-based L2 projects, regardless of whether they are based rollups, are striving to improve the inefficient transaction finality processes typical of traditional rollups. By introducing the concept of preconfirmation, they are establishing an intermediary assurance system that allows users to confirm transactions more quickly and reliably. Through this approach, these projects are continuously researching ways to enhance user experience and trust.

Taiko, in particular, is leveraging its status as a based rollup L2 to implement based preconfirmation, ensuring full Ethereum interoperability and decentralization while providing users with fast and reliable transaction finality guarantees. Through this approach, Taiko aims to enhance the transaction processing speed and reliability of rollups, making a significant improvement in user experience.

However, several rollup teams, including Ed Felten from Arbitrum, have pointed out that there is still a lack of middleware capable of fully guaranteeing preconfirmation. This highlights ongoing challenges with the maturity of preconfirmation technology and profitability issues for Preconfers, which still need to be resolved.

As mentioned in this article, various projects and players are entering the preconfirmation arena, each bringing unique ideas to improve the performance and efficiency of Ethereum L2. This aligns with a broader trend of optimizing system concepts after their initial implementation. I believe this phase—an essential part of system evolution—is a very positive development currently taking place within the L2 ecosystem.

Improved user convenience through preconfirmation could have a substantial impact on speed- and efficiency-focused sectors like DeFi and gaming. Additionally, enhanced performance of Ethereum L2s through preconfirmation may help rebuild Ethereum’s connection with previously fragmented and distant components. This performance boost could allow more type-1 Ethereum L2s to integrate closely with Ethereum, leveraging benefits that were previously unattainable due to speed limitations. Such developments would likely have a profound impact on the entire Ethereum ecosystem.

Preconfirmation is still an unexplored frontier—a rugged, unpaved path filled with challenges. Yet, pioneers like Taiko and others are pressing forward, focused solely on enhancing user convenience. Creating something new is never easy, but as a supporter of the Ethereum and Ethereum L2 ecosystems, I offer heartfelt applause and encouragement for their dedication. With this sentiment, I conclude this discussion on preconfirmation.