Taiko 🛠 Introduction to Taiko: Using Ethereum-equivalence for ZK-EVM superpowers

foreign [Music] hey everyone so um we are from Taiko my name's Dave I work on developer experience and this is brecht our big brain um uh so yeah Welcome to our our Workshop we're going to be talking about uh Taiko which is uh ethereum equivalent ZK roll up and uh we'll be giving a little bit of like a workshop on building a Dap as well uh give an overview of the bounties that we have and then also like give some insights onto like some cool things that you can build um yep so yeah like I said uh we'll just go over the bounties talk a little bit about Tycho ideas and then uh code base walkthrough um yeah so these are the different bounties that we have we have over 20 000 uh dollars in Bounty prizes that you can uh win so um we have best apps it's just like a smart contract adapt that you can develop uh infrastructure improvements some some interesting MAV stuff ZK Zone uh where you can work on some uh interesting ZK stuff uh protocol economics this would be like a kind of a no code Bounty and if you're if you're interested in like economics and like uh kind of dynamic systems I guess this would be a fun one um ethereum public goods um we find this one particularly exciting if you can do something that's just uh better for the whole space that would be really great and finally just a fun Bounty uh where you just can do whatever you want or I think is interesting all right so um uh what is Tycho um so basically um like I said it's an ethereum equivalent ZK roll-up and if you look at this graph here you can see uh we have a few uh these two axes uh like decentralized and centralized and ethereum equivalent and one that diverges from ethereum equivalence a bit more um and we're at the extremes of both of these axes where we're fully decentralized in terms of like proposing blocks and also proving blocks and then also where ethereum equivalent in the sense that we don't make any changes to like the ethereum stack even more like peripheral things uh we essentially uh don't really change anything to make it easier to generate proofs um yeah another word for this is a type 1 zkevm if you're familiar with it um it's also L1 sequenced um if you're familiar with Justin Drake he made like a post about something called a based roll-up which is using the L1 to do the sequencing so when you propose blocks um to create the Taiko chain we just rely on ethereum to do the sequencing um we're fully open source and MIT licensed it's a community project I think we have like uh 30 contributors on our uh mono repository on GitHub um and I think we have like over like 50 000 members on our Discord so we really like try to keep everything open and let everybody just you know help contribute we really like that um and yeah as I said fully permissionless block proposing improving the only reason I said permissionless here instead of decentralized is because um um because in regards to proving maybe the decentralization doesn't matter as much as it being permissionless um but I won't go into too much length about that now um Okay cool so next I'll just give like a run through of like how what the stages look like for the chain right like as as the chain is is moving on like what are the kind of steps that happen so yeah first you see here we have like these users um of the roll up and they submit uh transactions to the the mempool and everyone is able to run a node right you can just go to our GitHub repo and you can spin up a Docker image and run a node so they're all running this node it's a fork of uh uh of guest which is execution client and um basically those nodes can run as a block proposer it's just like a environment variable you can enable it and then after uh your proposer you just look through the transactions in the mempool and you can propose a block to um the contract that we have deployed on L1 um and yeah basically um at the time a block is proposed I think I kind of show this in the next slide we can already like build the roll up State like right after we've posted that transaction data um and that's because like um we have a really well-defined validity rules that we derive from the ethereum yellow paper um and and we do those validity checks to be able to compute the next state for the roll up um so you don't have to wait for approved for anything like that at the at the moment a block is proposed the chain can progress um so yeah that's how we kind of derive the roll-up state um yeah so in terms of proving blocks you see here I have like these three colors like blue is like proposed and you can just like keep proposing blocks and sequence and then um in green uh you can see um is is when um you can prove a block right and really what that is is just proving one uh state to to another state it's like proving that transition um but the reason why there's also this verified state is because it's assuming that the state transition um that you're proving is like has a valid parent or a verified parent so um the first block the Genesis block is already implied to be um to be valid because it's the first one so um it's only when all of the parent blocks have also been proven that we can consider a block as verified um yeah so you propose blocks people go around um and also this this block proving it can be done in parallel yeah yeah exactly that's that's a good question like so the next slide is like boom yellow yeah so yeah exactly um okay cool that's a great question um okay yeah so you can do all this in parallel and then like at the moment that they're all proven uh to Genesis they're all verified um okay now I'm gonna give it to brecht and he's gonna talk a little bit about like um some things to think about as they relate to our bounties um so yeah hey everyone um so yeah I'm going to go over the bounties like pretty quickly that's like there's like a lot of detail that you could could go into but um but yeah that's like yeah there's like quite a lot of bounties oops all right I'm I'm a bit smaller yes uh so yeah there's like a lot of like different bounties and okay to go into detail for all of them would be like uh quite difficult so I'm gonna be like pretty quickly describe uh some of the bounties uh give some extra detail but if you're interested in in them like yeah please contact team members and they will give you some more information afterwards um so yeah one of the first one is kind of like infrastructure improvements where we kind of like the goal is to just like improve the usability of of our chain and so there's a couple of possible uh tasks you could work on um one is for example the nft bridge so we created an error C20 uh token Bridge ourselves and then it Bridge ourselves um so you could depend on that uh as like a sample of your NFC bridge but yeah our bridging is kind of like very flexible so you can basically write your own bridging smartcraft just by depending on like this L1 Black Block hash that we bring available to L2 and so our RS into 20 implementation is like one of them that you could use but basically you can do whatever you want to to make this bridge um the other one is also like bridging related um So currently we use markup the Visa three check in in our smart contracts and the yeah the the positive thing about that is kind of like yeah we also like a type one equivalence and so this makes sure that we can actually reuse a lot of code that other Bridges already used to do that and but the downside is that it's quite expensive because the miracle Patricia treat proof is like quite big and also the verification costs in the smart contact is also like uh pretty significant and so we we can try to optimize it by instead of doing doing it in a smart contract we just wrapped the miracle 3 uh more competition check in in a CK circuit and then we just have to verify this circuit plus a small proof and so we kind of like balanced out the the proof size uh like the data size compared to like the the computational cost and on R2 the competition cost is kind of less significant than the data cost um yeah and the other two ones is kind of like more uh UI related um so one of them is like yeah we have like a L2 block Explorer and currently it doesn't like add some of the ziki stuff to it so for example it doesn't show you if kind of like a block is proven if it's a better fight and so it would be great if users can actually um yeah see that as well on the Black Expo um another one is that I get we we want as many people as possible to be able to run the proposal uh it's it's kind of like necessary for like the decentralization of our block production is also necessary for some of the decoration of our uh proving um so it's it's important that it's as easy as possible for everybody to run a note if they want to and the other one is kind of like the general like block like protocol proposing improvements and so here the goal is mainly to improve the efficiency of proposing blocks um and so yeah one of the first tasks is kind of like improving the block proposing cost estimation and so the difference is here like we we really try to be as much as possible to like like it here but the difference between L2 and L2 and ll1 and nl2 is that proposing a block on L1 is completely free it doesn't matter like how much data it costs like how big a block is in terms of like data and things like that and for now too this doesn't matter because we actually have to publish the data on the L1 and the costs for some of these resources that we use on it here there's also like time dependent um and so that's kind of like one of the more challenging things it's kind of like okay proposers want to put blocks on rl2 but uh yeah they still want to make a profit so they have to have like a good strategy to do that and support example transaction data needs to be included on ethereum for us and so that that takes data on the L1 blockchain that cause gas and so that needs to be taking account if they want to be profitable and the one thing is also like what they've mentioned is like we have like a base sequencer and so we kind of like depend on the other one to do our sequencing um but yeah if we have like no extra mechanism on top of that that means that money proposes with some blocks at the same time and that would mean that many transactions would actually fail and like waste gas because like yeah many blocks would like many proposals would submit the same block and they will include the same transactions and obviously that would be like very in uh like inefficient um so the way that we can improve that is to integrate with light spots which allows us to the proposes to select okay include my block only when it's like successful and then all other rocks will not be included but that's great because yeah they don't want to be included if another one uh the null browser is faster than um the other does is kind of like more exotic so one of the things is that Taiko protocol allows is kind of like these shared sequencers because the our current protocol is kind of like already fallen tolerant so that means that a shared sequencer does not need to have like the full State available of all the l2s and because it's okay for us for a sequencer to include the transaction this is actually invalid um so the protocol is skip over it it's kind of like inefficient so you want to avoid it but we can fully support that out of the box and the other one is also like a similar to that uh so for the base sequencer we kind of like want to use flashbots to include like for the browsers to include in the in our L2 blockchain the other one is like yeah if we have an L2 then there's also like math to be exploited on the L2 and so being able to also have like this map boost availability uh on the L2 is like a very useful for proposals to make money and like optimize for that um and the last one I'm going to talk about is like the protocol and economics um so yeah the goal here is that the economics need to be like simple and and robust and so like there's like two main fees that need to be paid one is if a proposal submits a block then he needs to buy uh blocks it's similar to like the ethereum uh eip1559 the other one is that if you create a block the there's also like an extra zero knowledge proof generation costs a suit associated with it and so that's the two main fees that need to be paid and for the for the EIP 1559 on the proposed side it's very similar to like the ethereum one but there's like a couple of differences for example instead of like having a fixed block time uh there's like new principle down on our R2 and also like it depends like the L1 mechanism depends on like this uh variable block size uh which we also don't want to support because it's less efficient um and like the final one is like the the the proof uh proof um so the proof is generally paid by the proposal um but it doesn't have to it kind of like depends on the magnetism there um so yeah there's some some ideas on yeah how the program pick could be paid um so one of them is kind of like a race uh where like the first that's submitted is actually gets a reward and for the the auction Beast is kind of like depending on how much the proof wants to be and uh how long the proof generation costs uh like takes uh well we will not and the final one is also like an interesting one where the like approve of State mechanism where the where the uh sorry where the the account effect depends on how much each proverb gets elected thank you sticks or something like that and so then we can just uh use like statistics to give some of them uh the like depending on how much is ticked we can actually assign blocks to them but yeah that's it okay cool um yeah a lot of fun stuff there um oh crap uh all right we're good um all right so yeah the next one is just going to be like me uh using uh open source tool that I made which is called dap slaps so basically the idea is that you can just uh in one click bootstrap your dap um and I know there's a few variants of these but I tried to make it uh fairly unique um so um in this in this in the technology that's used like it uses svelt it's a monorepo configured with Foundry um and uses a lot of like kind of the latest tooling to give a really frictionless uh developer experience and uh yeah basically the idea is like just want to help so that you don't have to waste too much time like trying to like build your dap and just get uh get moving on like writing smart contracts or doing something like more fun um so yeah you can scan this QR code if you want to check it out but aside from that I'm basically just going to like you know emulate what you would be if you're using this tool and like just set up adapt with it um yep so let's see here okay so uh this is the repo um this is the button um yeah so you just connect your GitHub let's call this blah blah blah blah so yeah it'll deploy it like on versel um and the only thing is you need is this like one environment variable which is like a web 3 modal project ID um I'm gonna get one online I think it's uh let's see here I think while it connects cloud okay all right yeah so you just create a new project here um and then it'll give you like an API key uh I'll just copy this and I'll add this and then okay technically two clicks I guess all right this might be like a little bit awkward silence just because uh it needs to like build um I don't think it'll take too long though let's see if it uh see if it cloned the repo at least on my profile oh there we go okay so all right as I'm waiting for this to build I'll just like clone the repo and then like maybe we can see it locally um so you can just like follow these steps they should be like very fairly clear in the readme um yeah so I'll just go through this maybe increase my font size okay so just cloning this and then what are the next steps um yeah it doesn't like clone the sub modules so you have to like uh do this uh one uh forage install um see here oops so CD into the directory uh do this Forge install um if you need to install Foundry there's like a link to it here it's like fairly simple it's I think it's just like a curl command um and then yeah you can just run this setup script um and this will just install the node packages and also install the forge dependencies um okay so next step would be like generating this uh bip 39 mnemonic and you don't have to do this but I just kind of recommend this if you're hacking because you might want like multiple accounts like multiple addresses so and you don't want to like use like your main one so you can just create like a bib39 mnemonic and uh use that and basically you can use this as an input if you're not familiar with Foundry you can run like a local ethereum node and you can just send in the bip39 mnemonic that you generate here and it'll just bootstrap the network with these accounts and give them all like a bunch of eth um so yeah I'll just create that [Music] um and then we'll set that in the environment file there's a single environment file uh we'll just put this here okay Source the environment file and then I think that's it yeah okay so I have I have three Windows here uh the reason for that is because uh we'll use one window to start the local Anvil chain we'll do another one just to like I don't know um do random terminal stuff and then the last one will just be like running the front end of the app um is this done yet okay cool so this is done so like I said you literally just need to do that like two clicks I guess and then um you can go and like um it'll be deployed so you'll just have a fully functioning dap that you can use um this doesn't use like any like weird it's like very minimal like I don't didn't put like any CSS or anything like that it's like a single file you can just rip it out and just use HTML and it's like it's just very minimal um so yeah um this is the this is the DAP but we'll get back to working on it locally um okay so I sourced the environment file now I'll just follow these three steps for these three Windows I'll start the local Anvil change with the bip39 mnemonic and you can see here that like it gives you all of these um accounts that you can use along with your private keys so you can just like take any of these uh these private keys and you can just like import them in the metamask um so that you can like use it in your application um I guess I'll just do that as well okay cool I don't know why it says Supply youth but um all right so I started the local animal chain that's good now we can interact with that uh the second thing I'll do is like I'll run this script it's a deployment script just to deploy like a kind of a dummy smart contract uh to that local Anvil chain and also it uses like wag me to generate all of the uh the types so it's like fully type safe when you like interact with the contracts um values required for fork URL or okay so it's probably because I need to go in here yeah I didn't Source my environment file so I think that was the issue um okay cool yeah so this is just compiling the dummy smart contract I'll go through the folder structure too so you can like kind of see but this just um compiled and deployed the contract I think we should have gotten a receipt yeah this is like a transaction receipt here um Okay cool so now we'll just start like the front end of the of the application uh all right we can visit it on localhost um yeah this is the application and let's see does this work okay cool so it says like I'll just show what the the contract looks like so basically like I said it's a mono repo like one of the folders has all the foundry configuration the other folder is a spelled front end um so in the contracts folder like we can look at the contract I just deployed it just said like Hello World here and the cool thing that like this has integrated is like if I update this um actually yeah if I update this and then I redeploy the contract right um it'll just like update uh the contract address which is used by the front end and like now you can see here's like the new message right so like hopefully this can give you like really rapid development you'll need to like change contract addresses or anything like that um it'll just like update all like reactively um okay so also I want to show here okay yeah so like I said there's this Source contract folder there's obviously like a test folder if you want to like write unit tests while you're hacking but that would be kind of weird um there's this um uh this is the deployment script you can see here this is where it's deriving that mnemonic um yeah creates a smart contract um this broadcast uh folder has some uh like metadata from doing the the deployment um huh okay cool yeah so this is just like you can just like interact with a contract here um yeah so it's pretty simple it's just a it's just a dumb like uh dumb uh smart contract I don't have enough support eth okay um but yeah I'll show one other thing really quick I guess I only have four minutes here and I want to be able to answer questions too so like uh we we have one page where we integrate the Tycho signal service so Breck talked about that a little bit uh it's really because our protocols like ethereum equivalent and we just use like uh Merkel Patricia tree for the state like we can just send arbitrary messages using Merkle proofs and the signal service is a contract that we like exposed where you can uh do that Miracle proof verification easily so if you want to do that thing like build the nft bridge or do some something related to cross-chain messaging then you can just use this as an example on how to interact with the signal service um okay cool um so let's go back to the slides um yeah so yeah big thanks to everyone for like coming here and like listening uh uh I think this is I think that Taiko is going to be like a really interesting thing if you don't have too many ideas for the hackathon uh we actually have like 20 people here uh in Tokyo which is pretty crazy and I know that we're all like really willing to just talk about anything so if you don't like know what you want to build like it's like there's a whole playground of things you can do like whether it's like economics building adapt like doing something that's like not even really web3 related and writing some scripts to run a node like I think we'd all be down just like stop by our booth like we'd love to talk to you about anything and help you build um yeah so I guess now like uh does anyone have any questions my RuneScape username it's a doctor Super Fresh I I so for a block proposers for Tyco is it just like first come first serve for whatever hits the smart contract first on the L1 yeah anyone can propose blocks at any time but it's up to the L1 to decide like how those are included or when they're included they decide to like pick up that proposed block up to like the L1 validator or like the whoever's proposing that all one block exactly exactly yeah that makes sense yeah what do you view as the most important trade-offs to optimize for economically in the system Brad do you want to go for that one and hit it maybe a better like what maybe like one of the most challenging things you've encountered so far well we kind of like want to narrow the problem down as much as possible so what we do is not change anything to the ATM program itself uh but we yeah instead we have to really optimize our circuits analogical knowledge proof generation as much as possible because yeah if it's too long then transacting costs would go up which would obviously be a bad thing um so the trade-off here is gonna affect you trade in some of the efficiency for like a full compatibility for equivalents and so it's even easier for developers to develop on but then we have to do our job to yeah make it as efficient as possible okay great thanks questions on the um blog finality uh Taiko block finality is that instant we have to wait for confirmation it's instant as in when the block is purposed and it's included in ethereum Block uh the it's fine last um so that means that the the financial order is fixed everybody knows what the pre-state and the post state will be uh it's just like that the information like the post state of that block is simply not known yet by smart contracts but anybody that's running a note and is just looking at the data as it comes in in the roll up smart compact you can execute that those transactions know the both seats so they know exactly what the state is and once it's in the small contract that means that it cannot be changed anymore so once it's there it's fully finalized can only be changed everybody knows the state except smart contracts and smart contracts that's why we need the zero launch proof um so zero knowledge proof is there because we will also want to let smart contacts know what the lead is supposed to do this without having this marker itself execute all those transactions so I guess in in practice we don't have to wait for any confirmation no no you don't have to so it is it's just for it's just for bridging where like a smart contract needs to know what the L2 state is otherwise everybody else knows directly when the block is proposed to what the what the latest state is so they don't evaluate sorry another questions uh do you do you support the oh we have plans to support the Privacy programming feature as in Leo or you know I mean not not on our layer too so if you want privacy you'll have to run it as an L3 honor also well some sorry but it's time cool thank you yeah thanks everyone [Applause]