Smart Contract Deployment on Mantle with Lib EVM

and as you can see from the the theme it is we're at a beef Ranch that's why it is a slide is themed and that's an animal farm and welcome to the workshop zero to Heroes a smart contract if you have any uh questions please feel free to interrupt me at any point and uh we'll now begin we've got 30 minutes we're good we're good yay hooray um so this is kind of the agenda we have today we'll talk a little bit of banto which is sponsoring me to be here a little bit of what is the evm the current state of developer tools your Foundry hard hat truffle ape works the various smart programming smart contract programming languages and if time permits we can check out more advanced topics and our tooling such as fuzzing or proxy contracts uh can you guys hear me yes good great perfect so who am I I'm a lib evm these are my socials I am currently a developer relations at mantle if you like to talk more about mantle feel free to uh just come and ask me questions after the talk but I'm an engineer at heart so what is mantle uh I don't want to show too much but the tldr it's an evm compatible scaling stack for ethereum and so we're trying to bring the good parts of ethereum and make it better so why evm compatible we would like to leverage existing tooling and the community and we want to build on the shoulders of giants so we want to be able to use the existing infrastructure like metamask we want to be able to use the existing tooling like a truffle hard hat Foundry the existing programming languages like uh solidity Viper you'll have and we don't want to keep Reinventing the wheel we want to we want the we want to be able to absorb the existing community and also a lot of these things take a lot of time and effort and we thought it would be better to just inherit them rather than compete against them so build with them instead of against them so these days there's three standard toolings out there if you would like to get started with a smart contract uh development the recommended one is Foundry from Paradigm and if you like JavaScript I would recommend hot hat but if you like the python syntax I would recommend ape works and now Foundry is a little bit more new new it's written in Rust so things are a lot more quicker whereas hot hat is a lot more familiar for those of you who've been in the JavaScript ecosystem however you have to write JavaScript to test your contracts found you you can just test them in solidity whereas ape works and and hot hat you have to write the various languages such as python or JavaScript to test the logic of your smart contracts which might not be ideal as there is a lot of context switching between them and we'll go a little bit overview about the smart contract languages we have the most widely used today's solidity which I'll be checking it out I'll be going through a very brief overview on things if you are an Optimizer who likes to gas golf or who really likes get who really likes to get close to the bare metal Huff is a good alternative if you like the python syntax or if you do a lot of math heavy operations Viper will be the recommended Choice such as curve however do we want that it is not very extensible because due to limited language support um half is also not recommended to be used in production actually simply because it is not it is very hard to get audited and it's very hard to find the logic it's very hard to visualize the logic control flows but at the end of the day they all compile down to evm byte code so it doesn't really matter as they are just a form of abstraction and with that being said let's check out a live demo so in the live demo we'll be going through a couple of topics um mainly the keywords in the smart contracts as well how to deploy your own erc20 token so right now I'm using Foundry so you can can you guys see the screen is it zoomed in enough perfect so usually how this would work is that you have you you would start your repository with Forge in it however Because the Internet is quite limited here today I decided to just go ahead and initialize everything in case uh in case the Internet isn't too kind with me I just need some water one second so in the solidity programming languages there's a lot of Primitives one of The Primitives is a un 256 and if you guys are curious what that means it just means I can store a really big number that is 256 bits long unsigned meaning it goes from zero to 256 bits it doesn't account for negatives if you were to do int 256 it'll be a negative number you can go from negative to positive but your range will be halved so these are like there's like special keywords such as un256 and you can also make this number public meaning this number is accessible externally or you can and and behind the scenes I'll show you what actually happens behind the scenes in the solidity program language keep in mind this only happens in solitary version I think 0.4 and above so not all versions of solidity will have this but if you're using modern tooling it should have it by default so the public keyword makes your number public but what it does behind the scenes is that it actually creates a new function called number uh or get number because we can't we can't have a collision in keywords which returns un256 and that just Returns the number so behind the scenes if you type out public this is what it actually it actually does now but since we already have this public keyword we don't have to recreate this function we'll just make it a lot more convenient cool we can also mutate the number like these variables are mutated by default for you for those of you guys who are coming from the JavaScript world this should be very familiar you can call Dot set number and you can override the number that is currently being stored in this contract so this uh this contract counter has a couple examples um you have a setup and you can increment the number and let's uh let's see how we can test it out so this is Foundry by the way when you initialize it I just realized I didn't went through it it would set up a couple folders you have the test folder the source folder the script folder and the library the library is where all the uh exists where you uh libraries where you import existing contracts such as open Zeppelin exe20 if you uh where you can immediately create a erc20 token which we'll be doing later on today Foundry also has this really cool thing called scripts where you can write scripts in solidity which is actually not supported anywhere else outside of Foundry this is very useful when you're testing solidity contracts because you don't have to keep context switching from one code to another however this is this tool is also Foundry specific so you have to use The Foundry Tooling in order for in order for you to use it but we probably won't dive into this category today so let's see how we can interact with this script and usually you would interact with it in the test folder so we have this contract called counter tests which is going to test our counter object so again this counter object all it does is that it has a number you can store the number you can read the number and you can increment the number and so how we would do this in counter tests is that we Define our counter object we create a new counter we initialize the counter to be zero which is in the setup process so think of this as a function that you run before every every time you initialize the contract and we'll test the increment of the number and we'll test setting the number so if we increment it from zero to one the number in the counter should be equal to one so that assertions should be true by default or we can also test setting the number to some arbitrary value X of which The Foundry uh framework will automatically fuzz this for us meaning it will test various numbers from zero between zero to two quadrillion whatever the maximum number is in 256 bits and it will make sure that that assertion that the number is equal to X and so we can run Forge tests to test this out we compile the project and now both tests pass so increment we have successfully tested increment and we have successfully tested the number so that's oops that's how you would Set uh let me drag this back that's how that's how you would test smart contracts and solidity now solidity and most smart smart contract programming languages have a special keyword and we'll be going through some of those special keywords with you today such as uh function get keywords public we have these things called message.sender TX dot origin block DOT number and block Dot timestamp so these are smart contract specific things which I'll go through in a second which you won't be finding anywhere else other than other than ethereum or any ethereum like language ethereum like environment so cool let's check out the difference between message.sender and and TX origin so let's get message sender return message dot sender they're both addresses if you're wondering and what message dot sender implies is that it's asking hey who sent who called this function so who called the get message sender function whereas TX origin also returns an address is I assume everyone's here is familiar with addresses a little bit all right cool and we can return tx.origin and so what the difference between TX origin and message sender is that TX origin Returns the originator of the transaction whereas message dot sender Returns the address of whoever who called the contract and we'll make this a little bit more concrete Let's uh let's run some tests tests keywords let's make this a function call test keywords and we can actually log stuff out in um in boundary with the log address keyword but you have to inherit from the test functionality again this setup should be default when you initialize your Foundry project so we can try and log an address for example message dot sender and just make sure that this works Forge test but since this test will pass and we want to be extremely verbose we would give it three V's test vvv which means very very verbose in my opinion um I'm sure georgius would disagree and as we can see we have logged out an address here and if I remember correctly I can log out a string with the address message.

cender counter test nope should I dive into it yes we have a lot of time it might as well as maybe not the DS test all right it's okay I'll just log a string message dot sender counter test and that's the message sender for counter.tests but if we emit the address for counter dot get message sender it will actually be different counter object as you can see even though we're both getting message dot sender message dot sender in the test file is different from the message.sender in the counter file and that the reason why is because we the counter test file is actually calling the counter contract so in theory if I logged out the address of this contract which is the counter test it would be the same as the message sender for the for the counter object when we call get message sender and let's uh let's let's test it out address of counter tests and as we can see the address of the counter test is 0xfa something something which is also the message dot sender for the counter object again this is because the counter test file is calling counter dot get message sender and that is why the two addresses are the same however if we check the TX dot origin of counter it would be it will be the same as the message dot sender as the counter test and let's check that out oh TX dot origin counter yeah TX origin whoop and boom TX dot origin is the same as the message dot sender from the counter and that is because the originator of this whole transaction actually created and calls counter test which is the TX dot origin so that is the message dot sender for counter test and which is in fact a TX dot origin for all for every instance so if we get the TX dot origin of this contract it will be the same as everything else and we can test it out so yeah those are like some of the keywords you can find in solidity message just keep in mind like these the little nuances between message.sender and tx.origin now a little hack that a lot of smart contract developers use to ensure that the sender of the transaction is a human and by human I mean an eoa or externally owned account meaning it's not a smart contract account that oftentimes they would put in this keyword this requirement where the TX dot origin is equal to the message sender which just basically means that your contract the caller can't be a smart contract and that way you can't bought do perform the botting bonding actions for example determine a number that your contract is going to predict in the future because you can get all the data from the smart contract anyway this is how a lot of spark contracts make sure that the color of the the user of their application is not a bot if you're wondering now we also have some keywords such as block dot hash which just Returns the hash of the block and that returns to a byte study tool which is in fact just a un256 packaged nicely block dot hash and we can check this out log edit blog bytes 32 nope hash block hash was it is it a function these days I don't remember oh block hash block.

number yes that's how you get it cool and it's zero because we're in a test environment so we haven't initialized anything so that's how you get the hash of the current block and if you would like to get the block number you can log you into 56. oh oh you in log you and you can log out the block number which is one so those are like some application specific keywords in solidity cool all right uh what else what else we got 10 minutes let's uh let's try and make our own token here our own erc20 and it'll be extremely simple all we do is import from the open Zeppelin contracts slash token slash erc20 slash esc20. soul and now if we just do this my token is erc20 give it a name uh super token and then just name it super and delete everything else and you have just created yourself an erc20 token that fits all the specifications very very cool very very easy uh let's try and test this I'll just keep this here a little bit longer so you guys can see how easy it is to make a simple token okay great our audience size just doubled I um hooray welcome so this is how you make a super simple token and we can now test it because we renamed it to my token we have to change it here to my token public counter but we'll just call it token and we'll set up a new token and this is how you make a new token very easy you just inherit from all the standard erc20 contracts oh great our audience size just quadrupled amazing thank you yes you you missed the best part which is the cow themed slides because we are in a beef range so everything's a animal theme but you know yes it is very cute but uh we're almost almost done I think we got like nine more minutes but anyway this is the token you can make a new token and you can test the functionality of the token that's token public and again this token inherits from all the it fits the erc20 specifications so if you want anything like uh let's see if the internet works okay so what that means is that it fits the ese20 token standard you have all these functions it has the name it has the symbol let me see you can you guys see it yes it has decimals it has total Supply blah blah blah bounce off transfer these are mutable functions by the way that mutate State transfer form just from inheriting from this erc20 contract and we can check it out right now amid log string token.name and notice that I didn't Define any anything in here everything is inherited from the erc20 contract this is in fact in my opinion very lame because I'm I'm not a big fan of Opera object oriented programming languages but here we are but these are the tools we have okay great we we we will log out the name of the contract super token and as you can see we never Define the function name but we can still call it we also have stuff like symbol which is just super as we have defined here but there's no way to Mint any token right now so we need to actually create a function uh uh owner Mint or like the magic mint which takes an address a and then means some amount B 256 B to some user and there's actually an internal internal function called mint where you can mint the contracts mint the tokens to address a with amount B and so for example right now uh right now the I my token I don't have any token it should return as zero but if I mint myself some tokens for example token dot mint address this I'll mint myself 100 tokens now the E18 is just saying that I want to put this to I want to give it 18 decimals that's just the standard a lot of token standards a lot of tokens such as die rap eaters or use 18 decimals to represent decimals don't ask me why it's 18 I I have no idea but we should have 100 tokens in our balance right now oh token dot oh it's magic mint yep magic mint and yes now we have uh 100 E18 tokens just from inheriting a contract and creating a fancy function called Magic mint we have now created a a token that is mintable for anyone which I do not recommend so generally what happens is that you would put a require where the message dot sender is some address for example 0x42 and if it doesn't pass then this whole function reverts and we can check it out in this case it just reverts so you have like a owner gated Min function so I think uh yeah that's how you make a token in erc20 land and I just realized that we're running out of time we're running out of time and I would have loved to dive deeper into more advanced toolings such as slitter and fuzzing and proxy contracts but I will give the next speaker five minutes to prepare and thanks and Q a and happy deployment to your smart contracts those are my socials if you want to check it out please do check out mantle.xyz we have a lot of Grants prizes to support anyone who wants to deploy on our Network we are a layer 2 optimistic Layer Two that is evm compatible again lots of Grants so thanks and if you have any questions feel free to chase after me after this talk thank you very much