Taiko 🛠 Introduction to Taiko + Ethereum dapp speedrun with SvelteKit and Foundry

foreign [Applause] [Music] hackathon my name is Lisa and I'm happy to introduce you to tanko Taco is a fully decentralized guitar of equivalent ZK roll up that is a type 1G evm and let's quickly Define what all that mean what all that means so a roll up is another two scaling solution that that batches multiple transactions of cheap and submit them to a separate chain in a single transaction for example to ethereum so it batches multiple transactions and submits in a separate transaction one single introduction that's why it's a scaling solution and the sticker lab is just a roll up that uses zero knowledge proofs also often called validity Pros when we say ethereum equivalent that means that there are no changes to the way a third of clients execute byte code and store data that is tariko uses the set has functions the same state trees transaction trees pre-compiled contracts and other inconsidered Logics and it will inherit future ethereum upgrades further and decentralized in the roll-up context means that both proposals and provers are decentralized that is no single party is able to control all transaction ordering or be solidly responsible for proven blocks so where we are today in December we released a l41 test net and in Mars that is very very soon we are releasing Alpha 2 testnet so we have here tenko consists of three parties that is a ZK evm and a layer to client and the protocol and today right now we will learn a bit about the take protocol let's go um Layer Two solution roll up bundles some transactions uh in a block and then this block goes through three stages block proposition block validation and block verification let's start with block proposition take a client determines the transaction sequence in the block so it um gathers something reduction and order them in the block and proposes this block to the ethereum node many blocks are proposed uh in parallel and pending in the ethereal mempool however for unverified blocks technical supports a limited amount of slots on the theorem we contained and reuse this slot let's suggest we have 10 000 to 140 slots and reuse that that is for a block uh number 10 240. uh the block number two uh 10 240 takes the slot ten thousand two hundred forty and after that the block number and 10 241 takes the first plot takes the same slot with the first block took and so it's kind of a swing and that means that after the first 10 240 block were used the work proposity will be minimized as storages are being reused proposing proposed block consists of metadata and list of transactions and metadata is specified according to um delivery yellow paper um and what is interesting about that that metadata is accessible by evm by the Italian virtual machine that is accessible for anyone while the transaction list uh is not and the transaction list will be executed on layer 2 only and that's a big core idea of product in fact Perico clived proposes a block using Taiko L1 contract client communicates with a term layer 1 executes executes two reductions builds new States updates the miracle trees on-demand shares the weakness with the proofer and can be run by anyone an ethereum node determining the final block order on layer 1. that is when the block is proposed by tele its parent test is not specified meaning that the final block order is fully up to the ethereum node after block proposition we have blocked validation this check is executed by Techo L1 contract and we have a set of formal rules that a proposed block should pass to to become valid the validation rules for a block include the following so the first criteria the transaction list is rlp decodable into a list of transactions ROP decodable is a standard for data transfer between nodes in a space speaking panel done for tutorial number two is about the number of transactions in the block is no larger than the maximum number of transactions in the table block minus one and this -1 this is minus the first transaction in the block but if the end culture is actually and we will talk about it later the culture number three is that the sum of all transactions gas limit is no larger than a technical blocks maximum gas unit beside the gas limit for this first results in the block the angle transaction then if the block is valid title client the Lord's speech proposed block and convert it into real technical layer to block and it is abandoned to the tiger chain block list so in fact when the block is propelled it is not a real Block it's just a bunch of transactions need some metadata and what it is checked to be valid take a client converting into a real takeover tool block so when they say conversion to a real take layer to block it means that after being downloaded the block is decoded into a list of transactions and take a client validate each transaction and generate a trace log for each transaction but approver to use it as witness data and ballot transactions are packed into the layer to block as in valid transactions are dropped and for transactions validation rules include the following the transaction signature is valid nouns is correct and the sender's valve is no less than the intrinsic gas and electrician gas is divided in yellow in the term yellow beta take a layer 2 block consists of an current transaction and just a list of transactions and this and current transaction is always the first transaction in the block and this Anchor's reaction contains all necessary data that is not covered by the detail evm itself so while a ZK exam covers signature validity proof for each transaction date proof the deliverable 3 and the execution flow that is given the right inputs one will get the right outputs with very high probability the accurate reduction holds 256 hashes of the latest blocks that are not a part of Miracle 3 and their two chain ID a bit more details about a valid and invalid transactions and it introduction is invalid it doesn't make the blocking value the invalid transaction is kept in the block however Taiko client supports an option to run in valid transaction to generate a trace for proof by and furthermore even an empty block is a valid block and still needs to be proven final stage lock verification the proverb generates zero knowledge proof and submits this proof directly to the terminal but it submits it through the take client and take a client provides the proofer with the weakness data for zero knowledge proof generation there is no specific uh ordering for proof generation so people can submit a proof for any block of Select before being verified the block should be checked for being valid and its parent hash transaction should be verified and right after that the block is immediately verified that the probe is immediately generated uh and if the block is invalid that is how it works today if the block is invalid instead of converting it into a real particular to block tenko client creates a temporary block with the only transaction inside indirect block and the proverb generate the ballot proof for this temporary but with the next protocol upgrade days will change and we won't have any temporary blocks anymore and with the next protocol upgrade approval integrate a proof that verified a block is either valid or a blocks transaction list is invalid so that's the short story of Telecom protocol all right everyone uh welcome to this Workshop my name is Steven from Tycho um today we're going to Speed Run build an ethereum app um which has some nice attack included so it has a spelled Kit app um the abis and contract addresses are automatically generated and fully typed with wagme um it has a web 3 modal connect button using wagme core and it has a Foundry configured as well so the whole project is a mono repo setup with kin pm and it's configured for it to be easy to work on any uh layer too as well so yeah let's get right into it um to get to this repo you can just scan this QR code and it should take you there so otherwise the repo link is here github.com forward slash this uh okay yeah so you're just gonna click this blue button for deploy connect your GitHub account and creates a repository name to the app you need to set one environment variable um you can just get this from wallet connect this is for the connect button you need this project ID is out of here and after clicking deploy you should have an app that's fully functional uh and it'll it'll be deployed so yeah let's take a look at this repo so we can work on it locally a little bit so first thing we need to do is clone the repo so I'll just clone it then we need to CD into it foreign then we need to do this Forge install command um then we need to run this setup script this will just copy the environment variables and install node dependencies then we need to set two environment files or two environment variables the mnemonic phrase and the web through metal project ID so you can generate a mnemonic phrase here it's also inside of the environment variables which I'll just open right now yeah you can see the link right here so yeah you can just generate some mnemonic um it'll create a string of some some words that map to wallet addresses I already have one and yeah just uh yeah I'll just show it I don't really care it only has a little bit of that um okay so copy that I'll use this mnemonic just share the if you take it um I'll get the what the wallet connect ID I'll put it right here all right Google so yeah that's the full setup just setting those two environment variables and now we can start the local development environment so it says we need three development windows and you need to make sure to Source your environment so I'll go ahead and do that let's see here one two three um I'll Source the environment variables APK there's two environment files one for each for Foundry one for um that's a front end So Okay cool so these two windows the first one will start um and all these commands are just available right here I just know them so I won't prefer to it but first we'll start a local ethereum uh node um or local ethereum chain rather so um this is Anvil it's supported by Foundry and now I just created this um I started this Anvil chain locally with these um 10 accounts and these 10 accounts are all populated with eth and these accounts were derived from that mnemonic that I passed in so what you can do is you can take any of these accounts and you can just take the private key and you can go to uh you can just go to metamask and you can import the the private key um so you can use it on your front end all right so after starting the local Anvil chain we can start the web app and then after that we can let's just see what happens first I think it might not work or have have it test near it we will have an error if I click that okay cool so we need to deploy a contract to this chain that we started um because it doesn't have one deployed yet so we have a script for that um it's just like so and now if you read a message I need a connective Foundry Network um so now if you read a message it says hello world right here and if I actually open up that contract um right here and I change it to hello world ASDF block um if I deploy this uh new contract and I read the message you'll see it's automatically updated so it's not just the contract that all of the abis and types and ways to interact with the contract on the front end are automatically generated as well excuse me um so that works with this like wag mean generate command so let's see here yeah so we have a contract we can interact with it we can send we can write a new message to this contract it's just a dummy contract that has a message and you can change the message uh now it gets updated to this new message um yeah so that's how you deploy smart contracts in our local chain you connect to that local chain through your front end and you automatically have all of your apis and types no Imports or copy pasting needed that's all being done in this whack me config TS file where we declare a deployment this food deployment and we just pick up the contract address um from the the logs of deploying the contract so let's try to see a little bit more about how this flow works by just creating another contract so I'll go to this contracts folder in the mono repo I'll create it this will just be called bar.soul um it's going to be like exactly the same as food.

soul except I'll change the message to just say bar and yeah let's write a unit test for it as well um just to show how that works it'll also be the same there's like this unit test from Foo we'll put it in here we'll just rename food to bar um yeah that's about right um uncomment this bar um let's run a test to see if this actually compiles says what is Source bar.soul um probably because I didn't name this contract correctly um so now if we run the tests assert failed it says the message should be hello world but we're expecting it to be far so we will just go ahead and change that oops and then now the test should passed okay test this past um so we just wrote a unit test we just wrote a smart contract let's deploy this smart contract um so what we'll do is we'll do this same we'll have to look at how this deploy works so if you look at the command um you'll see we run a script called deploy and we deploy that to an RPC URL which is Foundry um and then we generate the types so like we can easily deploy to other chains too and and maybe we'll show that but if I go in and I look at this script this deploy script I'll deploy another contract now which is the bar contract that we just created um and it's going to look very similar obviously um so we're going to deploy bar um basically the deployer of the smart contract is the first key in the mnemonic that you generated so we'll just use the the the artificial eat inside of the local Anvil chain to deploy the contract so here this is just straight solidity we'll just create a new bar smart contract and yeah let's deploy this so now this will deploy both of them again um says what the heck is bar okay it's this thing um okay cool all right all right so now they've both been generated and the last thing we need to do is inside of our Acme config which is inside of the app folder of the mono repo we need to declare that deployment for bar so I will just um create that um so we're going to call it bar that uh the contract of this for this chain is going to be um The Foundry Trinity and we just need to import this Json file which is an artifact of the log um run latest Json oh actually so the way this is configured is like now there are two if you look at the broadcast deploy logs in this run latest Json you'll see that two were deployed this Foo contract at this bar one the bar one is the second transaction so um it's a little bit of a finicky um setup for this um you don't have to do it this way but I think it's easier so um if you're just continually continually deploying your contracts and testing updates um but what we can do is we have this bar Json now and we can take that as the second transaction from the logs um and basically anytime you redeploy a contract there's run latest Json will get updated the contract it'll pull the contract address so that on your front end you're using the new contract if you don't want to do it this way then after you deploy you can just see what the contract address is and you can just directly copy and paste that in here which is how the whack me documentation um shows it I just think this is a little bit more of a reactive light um Okay cool so we deploy the smart contract um we might need to generate the types again I'm not sure but we'll just do it anyways um because we just changed the swag me config and now we should be able to use this bar contract okay so how do we use that let's um let's go into our app folder let's find the component um for this first page that we saw um and inside this component you'll see we obviously get the flu API the Food address let's do the same thing but we'll get the bar API um and as you can see and like as we've said it's just all automatically generated so now I have the bar API and the bar address so what I can do is I'll just uh how do I want to do this yeah I'll just um yeah I'll just use the bar uh I won't duplicate it I'll just use the the bar ebi in the bar address so it changes the bar API change this to Bar address I think that's everything is there like if it was only up here okay so now this we're going to use the um bar contract and our front then so the way that we can test that is bar was initialized with with this thing bar right here right so will it say bar yeah it says bar Okay cool so now we can update this smart contract and um maybe okay cool and now we just updated the state of this bar contract that we just deployed so just to hammer at home we can literally just update this to something else we can go ahead go down here we can deploy the contract um it'll know what the new address is of the deployed contract all the apis and everything will be typed and now if we read the contract it says this crazy thing that we just put in there okay so we wrote a unit test we showed how you can deploy it to your local chain now if you wanted to pull it to another change like uh another chain like let's say Tyco for example um I think I have that go set here yeah we have this uh hackathon RPC so if I want to just deploy this to Tycho um I literally just changed the typo or it could change this to optimism or it could change this to scroll or I could change it to base um you get the point it's like um it's just easy to deploy like essentially anywhere um okay tiger doesn't have this eip1559 enabled so I need to do send the transaction in like legacy mode I think I'm supposed to put this over here this is just deploying the bar contract to Tycho um all right it's not gonna be as fast as the local chain but um yeah it'll deploy it okay so now just for full coverage we showed how we can write a unit test and write a smart contract how we can add that smart contract into our deployment script by just initializing it like this um and how our front end um automatically knows the configuration to interact with that smart contract um and we updated that so let's see here is there anything else to talk about it is supposed to be a speed run um all right yeah so yeah that's the basic directory structure for Foundry it's just script source and test if we look inside of the packages folder um like I said the main thing is that wagme config file which is kind of like declares your smart contract configuration so your front end can use it um yeah it's pretty straightforward uh I mean that that's about it you can just start building smart contracts and start consuming them in your front end um and yeah that's about it uh spelled has very good documentation so I won't go into how to build on it but it's very very simple so I don't think you'll have trouble with it um and we have these stores that you can use so if you need to access the wagney client or a provider or anything like that from within any kind of file you can just go in and you can just do like an import uh let's say providers uh from stores here yeah and then you can access it um you need you can access that store like maybe you can do something like this and then you can do it yeah I think you can access this store by Chain ID and then yeah let's do get balanced do we need a provided address all right yeah let's do balance of this dress all right we need to wait for it I guess Foundry get balance yeah this is an async function so okay so let's just do like async function get balanced here um and then we'll just call this I mean the main point is that you can just access this Provider from like anywhere um but we'll do it anyways uh const balance is equal to that okay balance and take a two string I don't know if it does okay um and then on Mount of the component uh Channel maybe doesn't know what on Mount is oh yeah I think this is important for the wrong place it's probably just supposed to be from like there maybe okay cool and here's our balance okay anyways so you can use the stores to um to access like Global State um let's talk about the next part of this app which is this signal service tab over here um so basically um Tycho has some really elegant properties just because it's ethereum equivalent so one of those is the ability to like build a bridge on top of the protocol so the bridge is built on top of this very simple signal surface but um let's just show how it works and I think it'll make sense so step one it says here connect the sepolia network and then what we can do is we can store some signal on sepolia so that's just writing some data to a Smart contract called signal service that we have deployed and support and anybody can use that so I'll just send this signal from my address um and basically after I send that signal the thing is is Tycho and the base chain like ethereum or whatever uh keep track of the respective block ashes and because block hashes look the same on Tycho because tycho's blocks look the same as ethereum blocks um it supports Merkle proofs so what we can do essentially is we sent a signal to this base chain sepolia um and now we can ask some sepolia node to generate a Merkle proof they're just prove to me that I I sent this message somewhere inside of the state or I store this out of the state and I can take that proof and I can verify it on Tycho I can actually make a call to Tycho to verify that Miracle proof and they can check if that message is received on the base chain um just by checking the um its hatches because it keeps track of the hashes of the other chain so this is a signal that I haven't sent before so it'll save signal received as false and here is one that I have sent before um so it will save signal received is true um and yeah you'll have to wait about like five minutes like it'll take five minutes before this one returns true because um the time in which like we're deriving blocks under the L2 is configured at like five minutes currently it's a configurable variable but we just set it that way so we don't burn through too much eth uh so pull your eighth um and yeah so um we're really hoping you can build on top of this you could actually build a bridge yourself on top of the signal service so um yeah it's it's I think it's a really cool solution for like cross chain messaging and there there are some cool app ideas here especially um Bridges um okay yeah so we went through the application we showed how easy it is to deploy contracts and work with them and yeah it's uh that's really it that's really that simple I guess um and yeah if you need any help at all uh please just reach out to us on the Discord um we'll definitely be happy to help with like anything that you're trying to build you can reach out to me directly my name's Steve as I was saying if you want as well um and yeah happy hacks I'm looking forward to some cool projects here's the repo URL again and yeah and thank you very much