Today we’re excited to share that the Taiko alpha-3 testnet, Grímsvötn, is live! This is the next step on the road to a decentralized, Ethereum-equivalent ZK-EVM, and this testnet will be critical in testing much of the network design and components.

Relative to alpha-2, the most prominent changes are:

• New protocol economics design and implementation

• Proposers AND provers are permissionless (alpha-1 had permissionless proposers, alpha-2 had permissionless provers)

• L3 implementation: inception layers

Let’s cut right to it: this testnet focuses on the decentralized part of our decentralized, Ethereum-equivalent ZK-EVM. Or to be more specific, permissionlessness that can tend towards decentralization. The big thing to test here is how proposers and provers interact with each other and with the protocol, driven only by protocol economic incentives.

The other big thing to test is deploying Taiko on top of Taiko as an L3, something we submit is maximally simple owing to the reusability of the type-1 design. We refer to this as “inception layers”.

To jump right in and get to testing, transacting, deploying, or proposing and proving, see the guide:

To learn more about this testnet, please read on.

Primary objectives of this testnet:

• Test the new protocol economics design and implementation, including the new fee/reward model.

• Test the Bridge using partial Merkle proofs to verify signals/messages (a1 and a2 both used full Merkle proofs).

• Test the new oracle prover. Now regular proofs can come before oracle proofs.

• Test proof cooldown (30 minutes suggested).

• Test new ETH deposit using withdrawalsRoot on L2.

• Test inception layers. We will deploy a Taiko L3 in a few weeks.

Some things stay the same:

• Open to all developers to deploy smart contracts. As Taiko aims to be a type-1 ZK-EVM (Ethereum-equivalent), you can use all the Ethereum/Solidity tooling you are familiar with, and deploy your Ethereum smart contracts exactly as is.

• Open to all users who want to use it and play around with some transactions.

• Open to all interested parties to run an L2 node (requisite for being a proposer or prover)

• The L1 environment is the Ethereum testnet Sepolia

• Faucets for requesting sample ERC20 tokens to the Taiko testnet L2. For ETH on L1, you can use existing Sepolia ETH faucets.

• Bridge to move assets between testnet L2 and L1.

• Block explorers to view assets and activity on testnet L2 and Sepolia L1.

• Status page to monitor the network.

Rewards for proposers and provers

To accomplish the goal of testing the new protocol economics design, alpha-3 will be an incentivized testnet towards proposers and provers. We need to test how permissionless proposers and provers act in a mainnet-simulated environment, where they act rationally according to the fees and rewards of the protocol. (Alpha-2 was incentivized only on the prover side). Simulating a mainnet environment with permissionless economic activity is not so simple on a testnet due to the lack of real value assets. We do our best as follows:

Initial TTKO distribution

• When proposing a block, proposers need to pay the protocol in a protocol token. (They also need to pay Ethereum L1 gas fees: SepoliaETH in our testnet’s case). We call this protocol token TTKO (test TKO) in alpha-3. To seed an initial group of potential proposers with this token, we look back to those who performed useful work for the network on alpha-1 and alpha-2 testnets:

  • The top ~2,000 proposers by number of blocks proposed in alpha-1 will each be given some TTKO. Those addresses can be found here.

  • The 195 provers that proved at least one block in alpha-2 will each be given some TTKO. Those addresses can be found here.

  • We will share on our Discord, Community Forum, or Twitter when the TTKO has been distributed to their respective recipients, along with the calculations that determined the amounts. Please stay tuned. At that point, TTKO holders will be able to become proposers on alpha-3! Note: if you earn TTKO by proving alpha-3 blocks (right now, as the chain progresses), you can use it to propose at any time.

Simulating rational network participation

• In order to incentivize potential proposers to propose blocks in a mainnet-like manner, we stipulate two things:

  • To avoid spam proposing blocks (which would hurt provers who must expend real computing resources to prove the queue of blocks), we openly signal that TTKO balance will be among the inputs rewarding network participants come mainnet time. We do not provide more info as to how, because we have not conceived of it.

  • To avoid hoarding of TTKO and bypassing the point of the simulation, we further signal that rational and useful block building and proposing will be among the inputs rewarding network participants come mainnet time. We do not provide a specific formula, because doing so would render any formula a gameable goal (in a testnet environment without natural value spam protection).

  • These countervailing forces hopefully have the outcome of treating TTKO as something you do not want to expend in spam proposing blocks, and treating proposing as something you want to do rationally—basically, what you believe is optimal. Imagining you are a rollup proposer trying to maximize the real L2 fees you earn is the idea. This is our humble attempt to simulate the testing mechanics the network needs.

• In order to incentivize potential provers to prove blocks in a mainnet-like manner, we stipulate:

  • The already mentioned condition of TTKO balance being among the inputs rewarding network participants come mainnet time.

  • Recall that provers earn TTKO from the protocol when submitting valid proofs. So the “job to be done” from a prover (i.e., generating proofs) maps to earning TTKO. (As opposed to for proposers, where the “job to be done” means proposing blocks and paying TTKO, and earning SepETH.)

  • But please do not mistake the above for meaning a rational or optimal strategy means indiscriminately proving blocks to earn TTKO. Provers expend real computing resources when generating the ZKPs. It is thus not riskless that they would recover their real costs (especially if they are not efficient). It is also unknown when they would possibly be able to recover those costs. It is a decision a prover should consider carefully. Note in a mainnet environment with a known protocol token value, the decision becomes apparent, taking into consideration their efficiency and the competition’s.

  • Note the difference from alpha-2, where provers were rewarded in USDC, corresponding to the number of blocks proven.

Hardware requirements for proving

As of now, you can use the same hardware to prove blocks that was used in alpha-2. That was a minimum hardware requirement of: 8 or 16 core CPU; 32 GB memory. If using this hardware, rough benchmarks were: proof generation takes approximately 10 minutes, and if renting a machine with the above specs, would cost approx $0.15 per proof.

Note: this is not representative of what a full ZK-EVM proof will eventually cost as not all circuits are included yet. More circuits are being integrated as we go. Adding more circuit coverage may happen on a rolling basis, or represent an upgrade to an ‘alpha-4’ testnet. Either way, when heavier-duty hardware are required, we’ll make sure to communicate it as much in advance as possible.

Please note, reward or profit considerations (if any) will heavily depend on a variety of factors, and is in no way guaranteed. This holds for proposers, provers, and all network participants. Certain assumptions used may not reflect reality for the duration of the testnet period, protocol flaws can be found, and mainnet timing is uncertain. We reserve the right to adjust the program, with the ultimate goal of testing unprecedented permissionless proposing and proving in a ZK-Rollup. You should only participate if you are keen to help the network test a technical design. Basically, for science.

L3 scaling: inception layers

Inception layers refer to using Taiko as an L2 and deploying the exact codebase as an L3 on top. Given Taiko's Ethereum-equivalence, the L3:L2 relationship maps closely to the L2:L1 relationship, offering maximum reusability and simplicity.

This is needed because a single rollup can only scale Ethereum so far before state bloat becomes a problem. Multiple rollups (L2/L3/L-) are required for Ethereum at great scale. Inception layers (reusing same type-1 codebase) unlock extremely extensible scalability for Ethereum.

Further, Ethereum-equivalence across L2s, L3s, and beyond means inheriting some powerful properties, like built-in arbitrary message passing. This follows from the ability for one type-1 to read Merkle proofs from another. This combats a downside of having multiple chains: fears of fragmentation degrading the UX/DevX. With the different layers (adjacent and atop) easily able to speak to each other using Merkle proofs, a fragmented outcome can be avoided.

Please note, we will only deploy an L3 in a few weeks, but anyone is technically able to do so at any time. You can check the docs to learn how.

For more information on cross-layer message passing and bridging, please read this section of our docs.

For even more information on how we are thinking about making cross-layer communication efficient and robust, please see this research idea.

Timelines and expectations

We loved learning from our past two testnets, and have wasted no time in getting to the next iteration to learn more. We’ve also loved seeing the community participate as users, node/proposer/prover runners, builders, and more. For alpha-3, if all goes well, we expect it to be a longer lived testnet. Future large upgrades (a4+) may indeed be smart contract upgrades vs deprecation and regenesis. This way, we think community builders, Ethereum ecosystem projects, and other partners can deploy and integrate in a steadier state. However, please be aware that in some cases a regenesis may still be required.

Get involved

Once more, here is the testnet hub where you can find documentation, guides, and links to all relevant apps and tools for testnet usage:

Just like the first two times around, besides deploying, using, proposing, and proving, there are plenty of other ways you can get involved and help Taiko improve. Some of these include:

• Providing feedback or share any bugs you come across on this form.

• Create tutorials or other content that can help developers, proposers/provers, and users get started.

• In fact, it is now easier than ever to contribute, because we put everything about this testnet (and much beyond) out in the open! Follow along on our team project board: https://twitter.com/taikoxyz/status/1652810092528685056 and build right alongside us. We are one team!

We will have Community Call #3 on Friday, June 9th at 14:00 UTC on our Discord server, in the stage channel. We will provide some general updates, but hope to spend much more time answering questions and talking testnet. Please ask any questions you would like in this Discord channel in advance, or you can also ask them live. The questions can be testnet-related or general.

Thank you

Thank you to our devoted crew of community contributors from all domains, spanning engineering to education and much more. As you may see from the details in this post, aiming to be permissionless from the beginning means we rely on community participants to a great degree. We could not do this without you. We know the Ethereum ecosystem is full of exciting projects and ideas that you can spend your time and energy on, and we so appreciate you choosing to be part of our effort. We are more motivated than ever to deliver a type-1 ZK-EVM to - and with - the community.

Join us 💗

Explore open positions on our job board.

Follow us 🥁

To stay updated on the latest from Taiko:

• Website: https://taiko.xyz

• Discord: https://discord.gg/taikoxyz

• GitHub: https://github.com/taikoxyz

• Twitter: https://twitter.com/taikoxyz

Contribute

Contribute to Taiko and earn a GitPOAP! You will also be featured as a contributor on our README. Get started with the contributing guide.