**Taiko** - **research notes for the EPF project**

Website: http://taiko.xyz
Docs: https://taiko.xyz/docs

**Roadmap:**


**Current state of Taiko’s development:**

- Alpha-5 testnet, Jolnir, went live on 19 September 2023. Please see the announcement [here](https://taiko.mirror.xyz/0jc5XA5RVjOUNVdRdGmw9prlsC4deA1XgZJppmXh8rs). Alpha-5 testnet features a new PBS-inspired proposing and proving design.
- Alpha-4 testnet is not supported anymore, and Alpha-3 will be depricated as of 31 Oct 2023.

**Summary:**

Taiko is an Ethereum-equivalent zk-rollup that emulates Ethereum; supports all EVM opcodes and follows a type-1 zkEVM architecture.

Taiko’s design priorities:
1. Ethereum Equivalence: maximum compatibility with Ethereum; Type1 zkEVM, no changes to the Ethereum architecture, whether it be the hash function, state trees, or gas costs. This allows us to reuse execution clients with minimal modification. Taiko supports all hash functions, state tree formats, gas costs, and everything else that today makes Ethereum Ethereum.
2. Proving time: Taiko prioritizes perfect Ethereum equivalence over ZK proof generation speed.
3. Decentralization: Taiko has been emphasizing decentralization in its design since day 1, allowing multiple parties to participate in various network roles, including proposers, provers, and node runners to ensure censorship resistance and create a robust network.

**Protocol data**

[**Dashboards and block explorer for Alpha-5 testnet**](https://explorer.jolnir.taiko.xyz/stats) (The below data is reflecting the status on 1 Oct 2023, approx 2 weeks after the launch.)
- Avg block time: 3.5 sec
- Total unique proposers: 2,882
- Total unique provers: 845
- Avg proof time: 3min 24sec
- Max. proof window: 90 min

For period 19 Sep - 1 Oct 2023:
- Total transactions: ~1.8M
- Total blocks: ~297K
- Total wallet addresses: 346K
- Avg # of txs per block: ~6 txs

[**Dashboard on Alpha-4**](https://data.zkpool.io/public/dashboards/Aebs8y0nZ9w20wokJeFlIjWsi9DQcTVOzmBDpQXe) (The below data is reflecting the status on 17 Aug 2023.)
- Avg block time (last 100 blocks): 4.15 sec
- Total unique proposers: 5,356
- Total unique provers: 686
- Avg proof time (last 100 blocks): 34.8 sec
- Avg block fee (last 100 blocks): 4.346 TTKO
- Avg proof reward (last 100 blocks): 4.341 TTKO
- Avg # of txs per block (19 Aug 2023): 6.27 txs

**Architecture and protocol overview:**
Sources: https://taiko.mirror.xyz/y_47kIOL5kavvBmG0zVujD2TRztMZt-xgM5d4oqp4_Y and https://taiko.xyz/docs/concepts/overview

- block execution is deterministic once the block is appended to the proposed block list in the TaikoL1 contract. Once registered, the protocol ensures that all block properties are immutable. This makes the block execution *deterministic*: the post-block state can now be calculated by anyone. As such, the block is immediately *verified*. This also ensures that no one knows more about the latest state than anyone else, which would create an unfair advantage.
- block metadata is validated when the block is proposed. The prover has no impact on how the block is executed and what the post-block state is;
- the proof can be generated after the block is checked for validity and its parent block’s state is known
- as all proposed blocks are deterministic, they can be proven in parallel, because all intermediate states between blocks are known and unique. Once a proof is submitted for the block and its parent block, we call the block on-chain verified.

1. Block proposal:
- Anyone can run a Taiko sequencer. It monitors the Taiko network mempool for signed and submitted txs.
- The sequencer determines the tx order in the block.
- When a block is built, the proposing sequencer submits a proposeBlock transaction (block = transaction list + metadata) directly to Ethereum through the TaikoL1 contract. There is no consensus among L2 nodes, but there is some networking between L2 nodes (syncing, sharing transactions, etc.) However, the order of Taiko blocks on Ethereum (L1) is determined by the Ethereum node.
- All Taiko nodes connect to Ethereum nodes and subscribe to Ethereum's block events. When a Taiko block proposal is confirmed, the block is appended to a queue on L1 in a TaikoL1 contract. Taiko nodes can then download these blocks and execute valid transactions in each block. Taiko nodes track which L2 blocks are verified by subscribing to another TaikoL1 event on Ethereum.

2. Block validation:
- The block consists of a transaction list (txList) and metadata. The txList of an L2 block will eventually (when EIP-4844 is live) be part of a blob in the L1 Consensus Layer (CL).
- txList is not directly accessible to L1 contracts. Therefore, a ZKP shall prove that the chosen txList is a slice of the given blob data.
- Block validity criteria that all blocks need to respect: K_maxBobSize, K_BlockMaxTxs, K_BlockMaxGasLimit and config.anchorTxGasLimit
- Once the block is proposed, the Taiko client checks if the block is decoded into a list of transactions
- Taiko client validates each enclosed transaction and generates a tracelog for each transaction for the prover to use as witness data. If a tx is invalid, it will be dropped.
- The first transaction in the Taiko L2 block is always an anchoring transaction, which verifies the 256 hashes of the latest blocks, the L2 chain ID and the EIP-1559 base fee

3. Block proving:
- Anyone can run a prover.
- Proof can be prepared if all valid txs have been executed; and the parent block’s state is known. The proof proves the change in the block state.
- The block can be verified once the parent block is verified; and there is a valid ZKP proving the transition from the parent state to the current block’s state.
- only the first proof will be accepted for any given block transition (fork choice).
- The address receiving the reward is coupled with the proof, preventing it from being stolen by other provers.

**Sequencer design:** (sequencers are called proposers in Taiko)
- I reached out to the Taiko team and got in touch with Lisa over TG, who is a researcher at Taiko, and she provided a lot of super-useful practical insights regarding the sequencer. Kudos to her for all the support.

**Testnet**: Anyone can act as a proposer (sequencer), listen to the L2 mempool, and propose a block anytime, there is no sequencer selection model applied.
- Due to this there might exist txs that are included in multiple proposed blocks. Blocks are picked up as they come and once such a block is proposed by the L1 validator, the txs that were initially present in multiple blocks will automatically be excluded from the other blocks.

**Mainnet**: will be the same as above but also implementing based-sequencing.

- Based sequencing/L1-sequencing: as an Ethereum-equivalent rollup, Taiko can reuse Ethereum L1 validators to drive the sequencing of Taiko blocks, inheriting L1 liveness and decentralization. This is also called "based sequencing", or a "based rollup". More info on this: https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016
- Based sequencing inherits the decentralization of L1 and naturally reuses L1 searcher-builder-proposer infrastructure. L1 searchers and block builders are incentivised to extract rollup MEV by including rollup blocks within their L1 bundles and L1 blocks. This then incentivises L1 proposers to include rollup blocks on the L1.

Details:
- L2 sequencers (proposers) deliver L2 blocks (as bundles) directly to L1 builders (they act like the searchers in the L1 PBS setup). Builders take L2 blocks as regular bundles (similarly as they get L1 bundles from searchers)
- L2 sequencers will earn some MEV (here MEV includes (i) L2 block fees and (ii) MEV from txs reorgs etc.) - this is their motivation to be proposers. In the same manner as on L1, in the chain of searcher >> builder >> proposer, the proposer gets most MEV but searchers still get some share to make profits. It works the same way for L2 sequencers.
- As mentioned anyone can propose a block anytime (there are no time slots on Taiko like on Ethereum the 12-second slots)
- L2 sequencers build blocks and they compete for the most lucrative txs. Multiple blocks are proposed in parallel based on the same L2 mempool. These blocks are sent to the L1 builders as bundles, and it may happen that some transactions are included in multiple bundles proposed by L2 sequencers.
- When the L1 builders choose which L2 block to accept – they run simulations to find the most profitable bundle. If some txs in the L2 block were already taken by another builder and proposed by the Ethereum validator (this means that block already reached finality), then they are not counted in the current bundle anymore but get excluded from it. However the other L2 blocks proposed should still be valuable enough to be selected and included by an L1 builder within negligible time.
- Theoretically it could happen that most of the txs in a proposed L2 block were already included by L1 builders through other L2 blocks, and thus it is not anymore profitable, but this is expected to be a very rare, marginal case.

**Fee structure:**
https://taiko.mirror.xyz/y_47kIOL5kavvBmG0zVujD2TRztMZt-xgM5d4oqp4_Y
L2 tx fee = L2 EIP-1559* base fee + L1 tx fee + prover fee + proposer fee*

L2 EIP-1559 fee = L2 EIP-1559 tip (goes to the proposer) + L2 EIP-1559 base fee (goes to the Taiko DAO).

Once a proposer has collected enough transactions, most probably including and ordering them with the intent to generate a (maxim) profit, they create a block.
- Profit means that for the proposer, the sum of transaction fees (L2 tx fees) from the block is larger than L1 tx fee + prover fee + EIP-1559 base fee.

**Prover economics and prover mechanisms:**
https://community.taiko.xyz/t/taiko-proving-design-overview-grimsvotn-and-eldfell-cases/1014

**1.** Initial approach in **Alpha-3 testnet: First prover wins and gets rewarded only.** This results in many provers “wasting work”, many provers give up => centralization effect
- One proof should be confirmed for one “window.” A “window” is a period of time in which multiple blocks are proposed. Any prover can submit a proof for any amount of blocks at any time.
- There is a target reward, x, that is paid to the prover if they confirm the proof exactly at the target window, t = n. If proven earlier, the reward is lower, if later, reward is higher.
- A target reward is defined based on the historical reward values and is adjusted after each window depending on the proof confirmation time


* Effects:
* To be efficient within this design, a prover should be able to find an optimal trade-off point between (i) confirming the proof as late as possible (to get the higher reward) and (ii) confirming the proof earlier than all other provers.
* to confirm the proof as early as possible is not an optimal strategy for the prover; confirming all proofs as fast as possible decreases the rewards making it unreasonable for provers (but beneficial for users).

**2. Staking-based prover design** - implemented **in Alpha-4 testnet**; more info on Github
- Summary: one prover is pseudo-randomly chosen for each block from a pool which includes the top 32 provers, and assigns it to a proposed block. This designated prover must then submit a valid proof within a set time window for block verification. If the prover fails to submit the proof on time, the prover’s stake will be slashed. Prover exit is possible anytime, with a withdrawal time of one week.
- Prover weight W is calculated based on the stake A and expected reward per gas R. This weight reflects probability to be chosen.
- The current fee per gas F is calculated based on historical values and is supplied by the core protocol.
- Three other parameters unique for each prover; claimed while joining the pool:
1. Amount of Taiko’s TTKO tokens to stake A;
2. The expected reward per gas, R, is limited to (75% – 125%) * F range. If the R claimed by the prover is below or above this range, R will be automatically fixed at 75% * F or 125% * F, respectively;
3. The compute capacity specified by the prover
- If selected, the capacity reduces by one, and
- when the capacity hits zero, the prover will no longer be selected.
- When a block is proven (by them or any other prover), the capacity increases by one, up to the max capacity specified by the prover during staking.
* If fails to prove the block within a specific time window, the prover gets slashed;
* If the prover failed to prove the block or there is no available prover at the moment to be assigned, any prover can jump in and prove the block. Such a block is considered an “open block”;
* If the block was proven, the prover reward is R * gasUsed.
* Due to implementation constraints, the prover pool is limited to 32 provers as of now. As a result, the protocol mandates a minimum of 128 capacity per prover
* UPDATE:
* Minimum capacity has been decreased from 128 to 32 in the beginning of August 2023).
* Also slashing has been adjusted: instead of 0.25% of the total staked amount, it is now proportionate to the capacity as well. E.g.: a prover has set MAX_CAPACITY at 100, the protocol slashes 0.25% * 1/100 of the total staked amount.
* Effects:
* The provers with the highest stakes and the lowest expected rewards have higher chances of being chosen. It encourages multiple provers to be active and ready so that they could prove each others blocks when necessary.
* Challenge: as there are only 32 provers in the prover set for one slot, the design is not totally inclusive, especially when it comes to individual and solo provers. This issue can be mitigated through the secondary proof market (potantially also connecting those with only hardware and those with only tokens, and setting up provers).

A temporary measure: Oracle Prover
- It will not be present on mainnet. (The source document says it is in place on Alpha-3 testnet, however as per roadmap it would be implemented on the beta testnets only.)
- to avoid bugs in the proof generation the oracle prover checks all state transitions (by running a node to run over all transactions in the block) and may override existing state transitions (fork choices) that regular provers have proved. The cool-down window is 5 minutes.
- the oracle prover cannot prove/verify blocks directly and thus cannot change the chain state. Therefore, a regular prover will need to generate a ZKP to prove the overridden fork choice.

**3. PBS-inspired proposing and proving design on Alpha-5 testnet, Jolnir:**
Sources:
https://youtu.be/9LT6B1pgkI8 https://taiko.xyz/docs/concepts/proving and https://taiko.mirror.xyz/0jc5XA5RVjOUNVdRdGmw9prlsC4deA1XgZJppmXh8rs

In order to optimize network efficiency and balancing costs, the **Taiko introduces** **an off-chain proof market**. Proposers, on a per-block basis, actively seek potential proof service providers through this dynamic marketplace. A pivotal component of this setup is the publicly exposed API, providing proposers with the means to query and engage with available proof providers off-chain.

Details on **how to register in the prover market** can be found here: https://taiko.xyz/docs/reference/prover-market-page

In Jolnir, proposers need to acquire a bond from provers to propose a block. Provers need TKO tokens to deposit for the bond.

There are two ways to assign a block to a prover:

1. If you run a Taiko-node as a proposer or prover, your proposer will select your own local prover by default (left side of the below screenshot), and this prover has to provide a bond of 2.5 TKO as assurance for generating the proof
2. proposers can also choose any prover from the open prover market. Proposers send a hash of the L2 block’s transaction list to an open market of provers, who offer a price that they’re willing to provide a bond of 2.5 TKO for (right side of the below screenshot); proposers pay their provers off-chain.


When an agreement is reached concerning the proving fee for a specific block, the chosen proof service provider is then granting a cryptographic signature to the proposer which serves as a binding commitment to deliver the proof within the agreed-upon timeframe.

Provers within this off-chain proof market come in two primary forms: Externally Owned Accounts (EOA) and contracts, often referred to as Prover pools. The reward depends on the proof service provider and the agreement. For EOAs and Prover pools that implement the IERC1271 interface, the reward is disbursed in ETH. However, in cases where providers implement the IProver interface, the prover fee can be ETH, any other ERC20 tokens, or even NFTs, based on the negotiated terms.


In the event of a failure to deliver the proof within the given time, 1/4 of the bond provided, is directed to the actual prover, while the remaining 3/4 are permanently burnt. Conversely, successful and timely proof delivery ensures the return of these tokens to the Prover.
__________________________

**General considerations and overall prover design priorities of Taiko:**
https://community.taiko.xyz/t/decentralized-and-permissionless-proving-design-twitter-spaces-wrap-up/1087

- Permissionless: anyone can join
- Liveness: separating sequencer/prover functions
- Decentralization: large # of provers, geographically distributed, quick recovery after unexpected incidents, ability to differentiate prover pools from individual provers to see network health
- Taiko is looking into decentralizing proof construction: two-level proving - breaking up computation into smaller pieces (secondary provers) and then aggregating (main provers); this lowers necessary computation power
- Simple reward calculation

Possible approaches to prover decentralization:
1. Proof racing: fastest prover wins and gets rewarded only
- issues:
- waste of computational power and
- potential centralization effect
2. Proof mining: challenges (ZKPs) are generated by different provers until a specific condition is met. The fastest gets the right to generate the next proof.
- Issues:
- waste of computational power
3. Staking-based proving: all provers have to put up a stake. A selected algorithm determines who will generate the next proof.
- Issues:
- Incentive to compete against each other is not very high
- Resulting in potential centralization if high staked amount required

**Provers economics**
* Generally, if it is economically profitable to contribute computational power – that is a sufficient criterion for a prover to jump in;
* How profitable proving is for the prover depends on each specific case;
* The proof generation market is pretty early but the assumption is that as long as there is some free computational power in the world, operators are interested in participating in different projects, playing and experimenting with them even though their economics are not as mature and predictable (as, for example, for Bitcoin). Today it’s not about business, it’s more about experiments and exploration.
* The economics of proving is less obvious than what the industry is used to with mining. Furthermore, the economics might be very different for different types of proving systems (e.g., stake-based and proof mining). In some cases, it might be more profitable to focus on one particular network and optimize the software and hardware to be the most efficient in that domain. For other cases, it might be more profitable to provide some sort of service, that is, generating proofs for a specific company or app by agreement (e.g., this might be the case for ZKML).
* It is challenging to find a good trade-off between minimizing proof cost (that affects user transaction fees) and decentralization though both are crucial.

Secondary proof markets and delegation
* Secondary proof markets seem to be a lucrative idea both in terms of contribution to decentralization, low cost for users, and efficient hardware usage for provers. The reasoning for efficiency is that some good matching mechanism can match particular hardware with the most appropriate circuit.
* However, a list of limitations exists today to make secondary proof markets real. Firstly, some rollups use very different proof systems and schemes to construct proof.
* To split up proof generation into parts (e.g., one computes MSM, and another computes FFTs), some sort of standardization is needed. One part that needs standardization is the verify support for particular proof systems (such as Halo2). Another part is circuit description “standardization” that should be machine-readable. That is, it can be explicitly defined from the circuit by a machine what type of proving system is used there. (=nil’ Foundation has been working on that).

**Objective and Metrics in Tokenomics Design of Taiko**
https://github.com/taikoxyz/taiko-mono/blob/alpha-4/packages/protocol/docs/tokenomics_objective_metrics.md

Objectives and goals
* Taiko's goal is to promote cost-efficient proofs, which dramatically decreases Taiko's overall Layer 2 (L2) expenses.

Metrics for tokenomics:

* Native-Token Centric: The tokenomics design should primarily revolve around our native token. An equilibrium should be achieved between proposer fees and prover rewards, aiming to maintain or even slightly decrease the supply of Taiko tokens over time.
* Efficient Use of Proving Resources: If resources are wasted, provers will require higher returns from accepted proofs to offset their losses. This would raise the average cost of proofs.
* Cheaper Proofs over Faster Proofs: While ideally, proofs should be both cost-efficient and fast, cheaper proofs are prioritized by Taiko if two proofs result in the same time delay. In the case of time delays within a specific upper limit, say, one hour, the less expensive proof should also be prioritized. This approach encourages provers to optimize for cost over speed, thus reducing our L2 transaction costs.
* Prover Redundancy/Decentralization: The system should incentivize multiple provers to remain active for block verification.
* No Built-In PoS Reward: To prevent being classified as a security, our tokenomics design should not offer tokens to stakers as rewards. A prover may establish a staking-based reward system allowing token holders to delegate their power, but this should not be considered as part of the protocol’s tokenomics.
* Simplicity in Design: The design should encapsulate core concepts concisely and coherently, allowing for rapid understanding of the fundamental principles. This clarity facilitates efficient formulation of strategies and algorithms by provers.
* Minimal L1 Cost: Tokenomics should strive to minimize the average additional cost per block on its base layer. Provers will likely impose higher fees on L2 to offset this cost, potentially leaving out transactions with lower fees.
* Immediate Proof Submission: Provers should not be required to withhold their proofs and wait offline for the optimal submission moment. The tokenomics should incentivize immediate proof submissions as soon as they are ready. This approach enables the system to accurately capture the actual time taken by each proof, facilitating automatic adjustment of relevant parameters.

**L3s on Taiko**- New flexibility level and Taiko’s approach

* L2 for general purpose scaling, L3 for customized scaling. That is, the scaling mechanism on L3 is different from the scaling mechanism on L2. L2 is a “classic” EVM and L3 is non-EVM (e.g., separating "data" from "proofs" and replacing proofs with a single SNARK per block entirely);
* L2 for trustless scaling, L3 for less-trusted scaling solutions ;
* L2 for general purpose scaling, L3 for compatibility (e.g., Kakarot, a general purpose EVM is emulated on the Starkware EVM);
* L2 for scaling, L3 for customized functions, that is L3 doesn’t attempt to provide "scalability squared” rather it is a layer aimed at a specific function (e.g., privacy).
* An ecosystem of L2s and L3s for permissionless cross-domain operations: a three-layer model allows for an entire sub-ecosystem to exist within a single rollup, enabling cheap cross-domain operations without going through the expensive L1.

As a type-1 (Ethereum-equivalent) ZK-EVM, Taiko allows the same rollup protocol to be deployed on Ethereum or Taiko without requiring any changes in the code. That is, one can deploy Taiko on Ethereum as an L2, or Taiko on Taiko as an L3. Or one can deploy Taiko protocol as multiple L2s, multiple L3s, multiple L4s, etc. limitlessly scaling Ethereum.

* Allows anyone to seamlessly deploy their L2/L3s with minimal costs. Furthermore,
* Taiko's L2 solution can be easily modified to support centralized/permissioned L2/L3s to suit for enterprise's special needs;
* Enjoys using cross-chain messaging functionality that allows users to send arbitrary messages from any Layer 2/3 to any other Taiko Layer 2/3. This follows from the ability for one type-1 to read merkle proofs from another. It combats the downside of having multiple chains and reduces costs even further;
* Offers maximum reusability and simplicity as the L3:L2 relationship maps closely to the L2:L1 relationship thanks to Ethereum-equivalence;
* Downside:
* if L3 block proposing is fully permissionless, transactions will probably stay longer in the L3 mempool before being successfully proposed into a block.

**Gas per tx on L2 and L3** depending on batch interval:
https://vitalik.ca/general/2022/09/17/layer_3.html: