Taiko

The ZK-EVM proves the correctness of the EVM computations on the rollup with validity proofs.

Taiko can run Ethereum smart contract code as is, zero changes necessary. Developers can migrate their existing Ethereum smart contracts and full dapps to Taiko trivially, or of course implement their new solidity code on Taiko as their first/only environment. Taiko implements a ZK-EVM that supports every EVM opcode, producing a validity proof of the ZK-EVM circuit. Besides perfect compatibility with Ethereum L1 smart contracts and dapps, this also means that all Ethereum and solidity tooling works seamlessly with Taiko, no need to disrupt developers’ workflow whatsoever.

Beyond the benefits of EVM-equivalence, which mostly manifests itself at the application layer, Taiko aims for Ethereum-equivalence, allowing it to make use of existing Ethereum infrastructure, such as execution clients, easily repurposed as Taiko nodes. For instance, the Taiko client is currently based on the battle-hardened Go-Ethereum client. So, not only is the VM perfectly compatible, but the ‘surrounding tissue’ is as well, given Taiko nodes use the same hashing algorithm, signature scheme, and storage data structure as Ethereum. Importantly, Taiko seeks to be Ethereum-equivalent going forward as well; if there are Ethereum protocol updates, Taiko will implement them in our zkEVM to maintain synchronization. Finally, if Taiko creates compelling new directions from our own R&D, we can work to have them implemented on Ethereum, helping the L1.

Taiko nodes get transaction data from Ethereum and execute the transactions on L2, ultimately progressing the state according to the transaction executions. Thus these nodes manage the rollup chain. Currently, the Taiko node is an Ethereum Geth fork.

The Taiko protocol defines and enforces the rollup rules and defines potential participants. The design upholds the core principles of security, decentralization, and permissionlessness.

Smart contracts deployed on Ethereum L1 act as the data availability mechanism and verifier of the ZK-SNARK proofs. A smart contract deployed on Taiko L2 performs certain important protocol functions we explain in our whitepaper.

Below layer-1 is layer-0, the people. Blockchains are built by people, and what these people care about gets baked into the social contract, and into the code and overarching design. As mentioned, here again we seek to have the strongest Ethereum-compatibility.

We have good reason to stick close to the Ethereum example and specification; it is not solely out of mere love for the protocol and the people. It is because it is the only ecosystem that gives us what we care about, and a shot at changing the world for the better, especially for those who need it most. This sounds lofty, but such are the aims of the Ethereum community, and of Taiko.

Anyone who wants to use, build on, or participate in Taiko can do so. This is the case because the transaction fees are cheap and throughput is high; the developer experience is robust and Ethereum dapp migration is seamless; the network is permissionless and reuses Ethereum infrastructure to the fullest extent. You can’t have freedom without access.

Taiko is censorship-resistant and cannot exclude groups or individuals. The rollup is decentralized - relying on Ethereum for data availability and security; and permissionless - allowing any network participant, user, or builder to opt-in. There are no special roles which can censor users/applications/transactions. We are only interested in building credibly neutral, fair systems.

Taiko is fully open-source and community-centric. We build on the shoulders of giants, and cherish contributing back into Ethereum’s technical progress and community. We value community contributions into the project, harnessing the best minds and ideas that are interested in the space. The type of activity Taiko executes and secures mandates transparency.

Taiko’s ZK-Rollup design follows a few principles:

The design should prioritize security above all else.

The design should be simple and focus only on the core ZK-Rollup protocol, not its upgradeability, governance, low-level optimizations, non-core bridging functionality, etc.

The design should not depend on game theory for security. All security assumptions should be directly or indirectly enforced by Ethereum and the protocol. For example, there should be no need to use a Proof-of-Stake-like system to slash participants for bad behavior.

The design should encourage a high degree of decentralization in terms of block proposing and proving. No single party should be able to control all transaction ordering or be solely responsible for proving blocks. Being sufficiently decentralized implies that the protocol should keep working in a reliable manner in adversarial situations.

Anyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants.

The goal is to help Ethereum scale in the best possible way. Ether is used to pay the L2 transaction fees.

The design should stick to the design of Ethereum as closely as possible, not only for compatibility reasons but also for the expectations and demands of users of Ethereum L2 solutions.

Surely you have already seen and heard about other ZK Rollup’s, like Scroll or zkSync, but how is Taiko different and how is Taiko better?

The fundamental difference is that all three mentioned projects have a different type of zkEVM.

Taiko — 1 type (fully Ethereum-equivalent)

Scroll — 2 type (fully EVM-equivalent)

zkSync — Type 3 (almost EVM-equivalent)

Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent. They do not change any part of the Ethereum system to make it easier to generate proofs. They do not replace hashes, state trees, transaction trees, precompiles or any other in-consensus logic, no matter how peripheral.

The bottom line is that the higher the type level, the more difficult it becomes for developers to deploy their products on a specific zkEVM. For example, Uniswap took about a month to deploy in Optimism and Arbitrum and in the case of Taiko, it would be much faster.

Taiko scales Ethereum in a manner that emulates Ethereum as closely as possible - both technically and non-technically. More specifically, Taiko is an Ethereum-equivalent ZK-Rollup, scaling Ethereum by supporting all EVM opcodes in a layer-2 architecture that is decentralized, permissionless, and secure.

The ZK-EVM proves the correctness of the EVM computations on the rollup with validity proofs.

Taiko can run Ethereum smart contract code as is, zero changes necessary. Developers can migrate their existing Ethereum smart contracts and full dapps to Taiko trivially, or of course implement their new solidity code on Taiko as their first/only environment. Taiko implements a ZK-EVM that supports every EVM opcode, producing a validity proof of the ZK-EVM circuit. Besides perfect compatibility with Ethereum L1 smart contracts and dapps, this also means that all Ethereum and solidity tooling works seamlessly with Taiko, no need to disrupt developers’ workflow whatsoever.

Beyond the benefits of EVM-equivalence, which mostly manifests itself at the application layer, Taiko aims for Ethereum-equivalence, allowing it to make use of existing Ethereum infrastructure, such as execution clients, easily repurposed as Taiko nodes. For instance, the Taiko client is currently based on the battle-hardened Go-Ethereum client. So, not only is the VM perfectly compatible, but the ‘surrounding tissue’ is as well, given Taiko nodes use the same hashing algorithm, signature scheme, and storage data structure as Ethereum. Importantly, Taiko seeks to be Ethereum-equivalent going forward as well; if there are Ethereum protocol updates, Taiko will implement them in our zkEVM to maintain synchronization. Finally, if Taiko creates compelling new directions from our own R&D, we can work to have them implemented on Ethereum, helping the L1.

Taiko nodes get transaction data from Ethereum and execute the transactions on L2, ultimately progressing the state according to the transaction executions. Thus these nodes manage the rollup chain. Currently, the Taiko node is an Ethereum Geth fork.

The Taiko protocol defines and enforces the rollup rules and defines potential participants. The design upholds the core principles of security, decentralization, and permissionlessness.

Smart contracts deployed on Ethereum L1 act as the data availability mechanism and verifier of the ZK-SNARK proofs. A smart contract deployed on Taiko L2 performs certain important protocol functions we explain in our whitepaper.

Below layer-1 is layer-0, the people. Blockchains are built by people, and what these people care about gets baked into the social contract, and into the code and overarching design. As mentioned, here again we seek to have the strongest Ethereum-compatibility.

We have good reason to stick close to the Ethereum example and specification; it is not solely out of mere love for the protocol and the people. It is because it is the only ecosystem that gives us what we care about, and a shot at changing the world for the better, especially for those who need it most. This sounds lofty, but such are the aims of the Ethereum community, and of Taiko.

Anyone who wants to use, build on, or participate in Taiko can do so. This is the case because the transaction fees are cheap and throughput is high; the developer experience is robust and Ethereum dapp migration is seamless; the network is permissionless and reuses Ethereum infrastructure to the fullest extent. You can’t have freedom without access.

Taiko is censorship-resistant and cannot exclude groups or individuals. The rollup is decentralized - relying on Ethereum for data availability and security; and permissionless - allowing any network participant, user, or builder to opt-in. There are no special roles which can censor users/applications/transactions. We are only interested in building credibly neutral, fair systems.

Taiko is fully open-source and community-centric. We build on the shoulders of giants, and cherish contributing back into Ethereum’s technical progress and community. We value community contributions into the project, harnessing the best minds and ideas that are interested in the space. The type of activity Taiko executes and secures mandates transparency.

Taiko’s ZK-Rollup design follows a few principles:

The design should prioritize security above all else.

The design should be simple and focus only on the core ZK-Rollup protocol, not its upgradeability, governance, low-level optimizations, non-core bridging functionality, etc.

The design should not depend on game theory for security. All security assumptions should be directly or indirectly enforced by Ethereum and the protocol. For example, there should be no need to use a Proof-of-Stake-like system to slash participants for bad behavior.

The design should encourage a high degree of decentralization in terms of block proposing and proving. No single party should be able to control all transaction ordering or be solely responsible for proving blocks. Being sufficiently decentralized implies that the protocol should keep working in a reliable manner in adversarial situations.

Anyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants.

The goal is to help Ethereum scale in the best possible way. Ether is used to pay the L2 transaction fees.

The design should stick to the design of Ethereum as closely as possible, not only for compatibility reasons but also for the expectations and demands of users of Ethereum L2 solutions.

Surely you have already seen and heard about other ZK Rollup’s, like Scroll or zkSync, but how is Taiko different and how is Taiko better?

The fundamental difference is that all three mentioned projects have a different type of zkEVM.

Taiko — 1 type (fully Ethereum-equivalent)

Scroll — 2 type (fully EVM-equivalent)

zkSync — Type 3 (almost EVM-equivalent)

Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent. They do not change any part of the Ethereum system to make it easier to generate proofs. They do not replace hashes, state trees, transaction trees, precompiles or any other in-consensus logic, no matter how peripheral.

The bottom line is that the higher the type level, the more difficult it becomes for developers to deploy their products on a specific zkEVM. For example, Uniswap took about a month to deploy in Optimism and Arbitrum and in the case of Taiko, it would be much faster.