Search

Search for projects by name

Taiko logoTaiko

Badges

About

Taiko is an Ethereum-equivalent Optimistic Rollup on the Ethereum network. In the future it aims to add zkVerifier making it a hybrid, optimistic-zk construction. Taiko combines based sequencing and a contestation mechanism with multi-proofs.


Value Locked
$313.77 M15.3%
Canonically Bridged
$122.12 M
Externally Bridged
$191.65 M
Natively Minted
$0.00

  • Tokens
  • Daily UOPS
    22.8247.9%
  • 30D ops count
    109.35 M

  • Stage
    Stage 0
  • Type
    Optimistic Rollup
  • Purpose
    Universal
  • Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    Taiko is an Ethereum-equivalent Optimistic Rollup on the Ethereum network. In the future it aims to add zkVerifier making it a hybrid, optimistic-zk construction. Taiko combines based sequencing and a contestation mechanism with multi-proofs.


    Recategorisation

    179d
    10h
    24m
    43s

    The project will be classified as "Other" due to its specific risks that set it apart from the standard classifications.

    The project will move to Others because:

    The proof system isn't fully functional

    Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.

    Learn more about the recategorisation here.

    Value Locked
    Canonical
    External
    Native
    Activity
    Taiko
    Ethereum
    Onchain costs
    Calldata
    Blobs
    Compute
    Overhead
    Milestones & Incidents

    Taiko Based Sequencing Upgrade

    2024 Jun 6th

    Proposing blocks on Taiko is now permissionless.

    Learn more

    TKO Token Airdrop

    2024 Jun 5th

    TKO token launches.

    Learn more
    Risk summary
    Risk analysis
    Sequencer failureState validationData availabilityExit windowProposer failure

    Sequencer failure

    Self sequence

    The system uses a based (or L1-sequenced) rollup sequencing mechanism. Users can propose L2 blocks directly on the Taiko L1 contract. The TaikoAdmin multisig can pause block proposals without delay.

    State validation

    Multi-proofs

    A multi-tier proof system is used. The tiers are SGX, ZK (RISC0, SP1), Minority Guardian, and Guardian (highest tier). A higher tier proof can challenge a lower one within the challenge period. The system allows for an invalid state to be finalized by compromised Guardians (the highest tier) and does not enforce ZK proofs.

    Data availability

    Onchain

    All of the data needed for proof construction is published on Ethereum L1.

    Exit window

    None

    There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

    Proposer failure

    Self propose

    Provers can examine the proposed blocks on the TaikoL1 contract, and generate SGX proofs for them. Currently, any prover providing a valid SGX attestation can register a SGX instance and create proofs for proposed blocks.

    Rollup stage
    TaikoTaiko is a
    Stage 0
    Optimistic Rollup.

    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.
    Technology

    Multi-tier proof system

    Taiko uses a multi-tier proof system to validate state transitions. There are five tiers: The SGX tier, two ZK tiers with RISC0 and SP1 verifiers, the 1/8 Guardian tier and the 6/8 Guardian tier (from lowest to highest). Since the Guardian tiers are the highest, validity proofs can generally be overwritten by a single Guardian. Consequently, there is no way to force the RISC0 or SP1 tiers.

    When proposing a batch (containing one or multiple L2 blocks), the proposer is assigned the designated prover role for that batch and is required to deposit a liveness bond (125.0 TAIKO) as a commitment to prove the batch, which will be returned once the batch is proven. The default (lowest) SGX tier has a proving window of 5h, during which only the designated prover can submit the proof for the batch. Once elapsed, proving is open to everyone able to submit SGX proofs and a validity bond. The two ZK tiers have a proving window of 7h.

    After the proof is submitted and during its 4h cooldown window, anyone can contest the batch by submitting a contest bond. Provers have to submit a validity bond as a commitment to win a potential contest. A validity bond is TAIKO 150.0 for SGX vs 225.0 for ZK tiers, while a contest bond is TAIKO 984.375 for SGX vs. 1476.5625 for the two ZK tiers. For the Minority guardian tier, validity and contest bonds are set to 225.0 TAIKO and 1476.5625 TAIKO, respectively.

    It is not required to provide a proof for the batch to submit a contestation. When someone contests, a higher level tier has to step in to prove the contested batch. Decision of the highest tier (currently the 6/8 Guardian) is considered final. If no one challenges the original SGX proof, it finalizes after 4h (the cooldown window).

    • Funds can be stolen if a malicious block is proven by a compromised SGX instance or approved by Guardians.

    1. MainnetTierRouter.sol - Etherscan source code, tier ids
    2. TaikoL1.sol - Etherscan source code, liveness bond

    All data required for proofs is published on chain

    All the data that is used to construct the system state is published on chain in the form of blobs. This ensures that it will be available for enough time.

    Operator

    The system uses a based sequencing mechanism

    The system uses a based (or L1-sequenced) sequencing mechanism. Anyone can sequence Taiko L2 blocks by proposing them directly on the TaikoL1 contract. The proposer of a block is assigned the designated prover role, and will be the only entity allowed to provide a proof for the block during the initial proving window. Currently, proving a block requires the block proposer to run an SGX instance. Proposing a block also requires depositing a liveness bond as a commitment to proving the block. Unless the block proposer proves the block within the proving window, it will forfeit its liveness bond to the TaikoL1 smart contract.

    1. TaikoL1.sol - Etherscan source code, proposeBlock function

    Users can force any transaction

    The system is designed to allow users to propose L2 blocks directly on L1. Note that this would require the user to run an SGX instance to prove the block, or forfeit the liveness bond of 125.0 TAIKO. The TaikoAdmin multisig can pause block proposals without delay.

    Withdrawals

    Regular exit

    The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

    Permissions

    The system uses the following set of permissioned addresses:

    TaikoAdmin 0x9CBe…9C7F

    A Gnosis Safe with 3 / 4 threshold. Currently also designated as the Security Council. Can upgrade proxies without delay, remove SGX attestation certificates, pause block proposals and block proving, among other permissions.

    Those are the participants of the TaikoAdmin.

    Guardians can prove blocks on the highest tier. Guardians are selected by the TaikoAdmin multisig. Acts as a 6/8 multisig.

    Minority guardians can prove blocks on the second highest tier. Guardians are selected by the TaikoAdmin multisig. Acts as a 1/8 multisig.

    ChainWatchdog 0xE3D7…43aC

    The chain watchdog role can pause proving of blocks.

    SequencerBlockOne 0xd8dA…6045

    The authorized sequencer (in Taiko called “proposer”) of block one, hardcoded to vitalik.eth address.

    Smart contracts
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    The system consists of the following smart contracts on the host chain (Ethereum):

    This contract provides functionalities for sequencing, proving, and verifying batches.

    Can be upgraded by:

    Upgrade delay: No delay

    This contract manages the rollup addresses list, allowing to set the address for a specific chainId-name pair.

    Can be upgraded by:

    Upgrade delay: No delay

    MainnetTierRouter 0x394E…35b0

    Contract managing and routing the multi-tier proof system.

    Can be upgraded by:

    Upgrade delay: No delay

    Verifier contract for SGX proven batches.

    Can be upgraded by:

    Upgrade delay: No delay

    Verifier contract for ZK-proven batches.

    Can be upgraded by:

    Upgrade delay: No delay

    Verifier contract for ZK-proven batches.

    Can be upgraded by:

    Upgrade delay: No delay

    Verifier contract for batches proven by Guardian multisig minority.

    Can be upgraded by:

    Upgrade delay: No delay

    Verifier contract for Guardian multisig proven batches.

    Can be upgraded by:

    Upgrade delay: No delay

    A contract that holds TAIKO token and acts as a Taiko Labs owned proposer and prover proxy. This contract relays proveBlock calls to the TaikoL1 contract so that msg.sender doesn’t need to hold any TKO. There are several instances of this contract operated by different entities.

    Can be upgraded by:

    Upgrade delay: No delay

    The SignalService contract serves as cross-chain message passing system. It defines methods for sending and verifying signals with merkle proofs.

    Can be upgraded by:

    Upgrade delay: No delay

    Contract managing SGX attestation certificates.

    Can be upgraded by:

    Upgrade delay: No delay

    Taiko’s native token. Used for block proposal rewards, proving bonds and rewards, and contesting bonds.

    Can be upgraded by:

    Upgrade delay: No delay

    Shared bridge for Taiko chains for bridged ETH. This contract stores the following tokens: ETH.

    Can be upgraded by:

    Upgrade delay: No delay

    Shared vault for Taiko chains for bridged ERC20 tokens. This contract can store any token.

    Can be upgraded by:

    Upgrade delay: No delay

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).