Controversial rollups offer a compromise that allows application chains to start with a more economical configuration while maintaining the flexibility to incrementally enhance security measures without making major changes to existing infrastructure.
Original title: "** Based Contestable Rollup (BCR): A configurable, multi-proof rollup design****"
Written by: Daniel Wang
Compilation: BlockBeats
*Editor’s note: Written by Taiko’s co-founder and CEO Daniel Wang, this article delves into an architecture based on the controversial Rollup (BCR), an innovative design for Ethereum Rollup. The article not only analyzes the advantages and disadvantages of BCR, but also explains how it can become the most ideal design framework for Ethereum Rollup. Ethereum co-founder Vitalik Buterin also gave an in-depth discussion of BCR-related concepts at this month’s themed Twitter Space event, further confirming the timeliness and relevance of these ideas. *
What makes Taiko unique
First, let’s understand what differentiates Taiko from its competitors:
- Permissionless and Decentralization: Taiko is a basic rollup, the first of its kind among competitors. It does not have a centralized sequencer and instead relies on Ethereum validators to sort transactions and blocks.
- Frictionless developer experience: Taiko uses the Ethereum equivalent ZK-EVM (Type 1 ZK-EVM) to achieve execution-level compatibility with Ethereum, essentially providing “Ethereum at scale”.
- Highly configurable and future-proof: As a controversial rollup, Taiko allows appchains to define their own proof systems and adopt newer, more efficient proofs of validity as technology advances, without the need to modify Taiko’s core protocol.
Now, let’s explore why it makes the most sense for Taiko to adopt a dispute mechanism.
The credibility of the proof
"34,469 lines of code can’t be error-free forever. —Vitalik Buterin on the ZK-EVM code
Taiko’s key consideration for adopting a controversial rollup and multi-proof structure is the reasonable suspicion that Zero-Knowledge Proof (ZKP) cannot be wrong. Given that software complexity often increases the likelihood of vulnerabilities – as shown by OpenSSL’s Heartbleed (2014) and Linux kernel’s gross negligence (2003), which went undetected for long periods of time, Taiko takes a cautious approach.
As a fast-moving technology, ZKP is error-prone. Centralized rollups can tolerate some risks, but Taiko cannot. Taiko is committed to full decentralization and permissionless and looks forward to relinquishing control of the Taiko network in the future. Therefore, Taiko’s initial design assumption was that any proof could be a safety hazard in the absence of years of proven practice. That’s why Taiko needs a dispute mechanism.
Basic Debatable Rollup (BCR)
A basic contestable rollup is a type of rollup that has controversial characteristics and uses basic ordering. To illustrate how disputes work within the Taiko framework, consider the following examples:
- Alice proposes a new block.
- Bob submits proof for state transitions H1→H2, where H1 is the parent hash,
H2 is the hash of the new block. Bob placed a validity margin of 10,000 TKO. His proof then went into a cooling-off period.
- Bob’s proposed state transition and accompanying attestation are publicly visible.
- Cindy noticed that Bob’s conversion was wrong and thought it should be H1→H3 instead of H1→H2. Cindy challenged Bob’s proof by submitting her 10,000 TKO dispute Margin during the cooling-off period, but she did not provide alternative proof or clearly indicate the correct conversion.
This controversial conversion now awaits a new, higher-level proof. Bob and any other certifier will have the opportunity to provide this proof.
Scenario 1:
- David provided Level 3 proof of H1→H2, confirming Bob’s original claims. David is rewarded with 2,500 TKO to become a current attester and pays a validity margin of 20,000 TKO.
- Cindy lost her entire dispute Margin.
- Bob receives his 10,000 TKO validity Margin and 2,500 TKO reward.
- David’s proof initiates a new cooling-off period.
Scenario 2:
- David provided a Level 3 proof of H1→H4 showing that Bob’s conversion was wrong. David was awarded 2,500 TKO and secured his place with a validity margin of 20,000 TKO.
- Cindy gets back her 10,000 TKO dispute margin and an additional 2,500 TKO reward.
- Bob’s validity Margin is forfeited.
- A new cooling-off period begins and is used to verify new proofs.
Every proof in Taiko except the top layer requires the original prover to pay a validity margin in Taiko Tokens. This proof enters a cooling-down window during which it can be disputed by others, who do not need to provide any fraud/validity proof, but must pay a dispute margin in Taiko Tokens. If there is a dispute, a higher level of attestation is required to resolve the dispute before the Block can be verified.
- If the contestant wins: The contestant withdraws the disputed Margin and receives 1/4 of the original prover’s validity Margin. The new referee receives 1/4 of the original referee’s validity Margin as a proof fee, and the remaining 1/2 is forfeited.
- If the original prover wins: The original prover withdraws the validity Margin and receives 1/4 of the disputed Margin as a reward. The new certifier (possibly the original certifier) receives 1/4 of the disputed margin, and the remaining 1/2 is forfeited.
The new prover must also pay a validity margin according to the rules of the new tier, unless they provide the highest level of proof (in which case the state transition is considered final and no further challenge is allowed).
It is worth noting that the dispute/proof game assumes the correct parent block hash. If the parent block hash is incorrect, the winning conversion will not be used for block validation, and the prover will completely lose their validity margin.
Repeated arguments and proofs extend the time it takes to validate a block. Each new round introduces its own validation and cooldown window. However, since disputes involve economic interests and the loser’s losses are decisive, they are unlikely to occur frequently. In addition, the validity and dispute margin of higher-tier proofs are significantly greater than lower-tier proofs. As the game progresses several rounds, the associated costs rise dramatically, further dampening pointless arguments.
One potential drawback of this design is that it economically discourages the submission of invalid but verifiable proofs, which makes it more challenging to find vulnerabilities. However, one may question whether it is wise to use the entire Blockchain as a motivator to find vulnerabilities. Other mechanisms could be used to encourage the reporting of such vulnerabilities. For example, offering handsome rewards to those who identify invalid but verifiable proofs may be a better approach than jeopardizing a user’s assets.
![]()
Multi-factor authentication system
Multi-factor verification is a core feature of Taiko’s BCR architecture, allowing each level to use its own attestation system. While ranking these systems by credibility may seem subjective, it is theoretically possible to construct more reliable proofs than other systems.
For example, Taiko can create a comprehensive validator C, which combines the proofs of A and B validators. C considers a state transition to be proven only when both A and B prove that the transition is valid. While this increases costs, it also enhances security. One limitation of this approach is that C-type synthetic proofs rely on the successful generation of subproofs from A and B. If A or B has an error, it will be problematic to generate a reliable C type proof.
In practice, multi-factor authentication levels are often configured subjectively. For example, it is reasonable to assume that SGX validators are more trustworthy than Optimistic validators who lack actual evidence. ZK validators are arguably more secure than SGX validators, and hybrid SGX+ZK validators rank even higher.
If the ZK attestation system ultimately proves to be universally secure, the contestability rollup can be configured to use this single level, effectively transitioning to the legacy, non-contestable ZK-rollup.
In the context of Taiko’s controversial rollup design, multi-factor validation has a dual function: vertically, it supports a layer-based architecture, and horizontally, it allows multiple sub-validators to be combined into a synthetic validator with a low probability of false positives.
Validator availability
One potential flaw in controversy design is the lack of active high-level validators, especially when controversy is rare. To maintain an available pool of advanced validators, Taiko has introduced a mechanism that randomly assigns the minimum required level to each new block. Block is inversely proportional to the hierarchy of that level; for example, only 5% of Blocks may require SGX+ZKP, while 20% require ZKP, and most of the remaining only require SGX. This ensures that ZK provers always have a job, keeping them engaged and profitable.
For arguable rollups, an attack vector is the submission of capital-intensive proofs with the goal of exhausting high-level proof resources. Although such an attack may slow down the block finalization and proposal rate, it is unlikely to threaten the overall security of the chain. This is because community Nodes can collectively challenge invalid proofs by placing disputed margins. Importantly, disputers do not need to provide any proof themselves, while attackers must provide on-chain verifiable proofs for each block. Generating false but verifiable proofs can be more challenging and less cost-effective than generating correct proofs.
If a higher-level proof is suddenly needed, financial incentives attract new validators. Specifically, receiving 1/4 of the validity and dispute Margin may be more profitable than regular proof fees. For example, given the greater financial risk involved, ZK validators working across multiple platforms may switch to processing highly profitable blocks.
Dynamic configuration adjustments
One advantage of Taiko’s arguable design is its adaptability. As the cost of high-level attestation drop, the system can dynamically adjust the proportion of Block that require ZK attestation without impacting existing Block or requiring protocol upgrades.
For example, an extreme case could start with 100% optimistic proofs and then switch or gradually transition to 100% ZK proofs required to minimize on-chain finalization time. This allows scaling rollups, L2, or L3 built on top of the Taiko stack to evolve from technologies like Optimistic Rollup to ZK-Rollup, providing tremendous flexibility in optimizing security and economic incentives.
Cost vs. security trade-offs
In the world of rollup technology, concerns about the impact of game theory are understandable. However, the introduction of a dispute layer does not necessarily mean that rollups are dropped in security. There is no difference in security between a traditional rollup that uses a fixed ZK prover and a controversial rollup that uses the same validator as the base layer.
ZK-Rollup provides greater security, but in the short term, the associated costs may not be sustainable for apps with millions of users per day. As Vitalik puts it, "If a user had previously paid $1, it would have been easier to pay for $0.10. 」
Over the next few years, most ZK-Rollups will remain financially impractical for high-volume appchains. Faced with this situation, many appchains may prioritize cost efficiency over enhanced security. Even if ZK proof costs are expected to drop, this may not be enough to entice appchains to fully switch from a more economical but centralized solution to ZK-Rollup.
Controversial rollups offer a compromise that allows application chains to start with a more economical configuration while maintaining the flexibility to incrementally enhance security measures without making major changes to existing infrastructure.
![]()
Guardian validators
Guardian validators are Multisigers who collectively act as the upper echelons of the attestation hierarchy for the first few years after launch. The specific purpose of these guardian validators is to serve as a safety net for addressing vulnerabilities in the early stage of the attestation system. Importantly, these daemon validators exist outside of the core protocol and can be removed from the hierarchical attestation configuration. They cannot influence the ordering of transactions or blocks. As the system matures and other validators prove their reliability, these guardian prover roles can be phased out.
While alternative mechanisms like DAO voting can manage flawed validators, this approach requires a longer cooldown window to complete the governance process. This is not suitable for quickly addressing critical vulnerabilities, unlike adding or removing features, which can withstand a longer decentralization governance process.
In the initial stages of rollup deployment, especially in pursuit of the goal of decentralization, guardian validators are crucial. Unlike centralized rollups, where the chain can be suspended or changed by its administrators, guardian validators provide a layer of security that can address bugs or vulnerabilities without disrupting the decentralization nature of the network.
Next Testnet
Taiko is currently fine-tuning the new design and the Rollup contract codebase. When completed, this will be deployed as Taiko’s Alpha-6 Testnet with a four-layer attestation system. The percentages in the following diagram represent the probability that a block needs a given layer as its lowest proof level.
![]()
In the upcoming A6 Testnet, Taiko will adopt a 24-hour cooling-off period for all tiers.
Finally, Taiko’s main goal is for arguable rollups to combine the advantages of Optimistic Rollups and ZK-Rollups. If you are interested in the practical application of this innovative design, you can join the Taiko community for more updates.
