Your First Core Solidity Smart Contract

Transcript

[music] Hello everyone. Nice to see so many of you here. Today we will um be writing uh core smart uh course smart contract for the first time for probably all of you almost at least. Um quick intro to the language and myself. Uh I I wrote my first smart contract back in 2015. Um this looks like solidity uh and it was solidity but a lot has happened since then as well. Um after that I've done some uh did an internship at the Ethereum foundation worked on payment channels uh 10 years ago built hack prevention tools and now I'm the

developer relations at uh Argo for solidity. So core solidity what is the current state of things? Uh we have a prototype compiler. It's not ready for mainet use yet. The language is still changing quite a lot. Um and there will be a good amount of breaking changes until it's ready for production. We have a playground uh that runs in the browser. This is what we'll be using today. Uh where you could deploy in Kogo contracts um run inline tests etc etc. Um there are some contracts that have been ported from classic solidity and we are also formally verifying the semantics of the language. We just last week did the

first like uh alpha pre uh release. So it's like very early days still but there are there is now a binary you can download that has a language server formatter plugins for editors. So you can actually start playing around with the language. Um and classic solidity will continue to be uh maintained and developed as well. So don't don't worry about that. Um but this uh is a new front end to the source C back end. Um so as you can see here it lowers to u and from ule on it's the same back end. Um yeah um uh why are we doing a new front end?

Solidity over 11 years has uh accumulated a good amount of uh technical depth. it's hard to add new features. Um, so we wanted to start over um and build a language that has [snorts] uh some features that are more modern so to speak. Um, and also has a core language that has like a small set of primitives and one type which makes it easy to uh build a standard library but also to formally verify the language. Um, and yeah, just more modern features. Um, okay, I'm gonna skip this.

it's not so interesting. But yeah, there are still some uh things uh missing in the language. Uh some things we didn't decide yet if we want to do or not. Um but it also is very similar to and familiar to uh Solidity. So what will we be building today? We'll be building an ESC20 style token. Um and we do it like step by step in the playground. Um first we'll just build a a transfer. This is going to be very similar to to what you do in classic solidity to show that the syntax is very similar. Then we will introduce uh enums which is uh one of the new things we have like enums that carry data and

pattern matching on those. Uh personally this is my my new favorite feature. Then we'll do some modules um to show how we will have uh causality uh doesn't have any um inheritance. So we'll show uh how that works instead and then uh if there's time we will look a bit at the comp time and if there's even more time we will have another uh exercise u where you implement a hook. So open the playground uh on this link. Um the QR code leads to the link but you can also type it out. Um and then once you're there you can go to the run tab. I'll show it in a moment.

And there you can say run all tests. And this basically compiles and downloads the compiler. And once you've done that one time, you don't need internet for the rest of the of the session. So we'll just uh make sure everyone is uh on that level. I'll just give you all a moment and then jump over. Is there anyone still typing the the URL or can I continue otherwise it will also be shown in the at the top of the next window.

Huh? Yeah, I mean I just asked people and someone said they're still doing it. So, I'll just wait. Maybe I should have uh made a shorter link for the sake of the playground or the the demo. All right, I'll I'll jump over. You can still read it at the top of the of the screen here. So the first step I ask you to do is go to run and then you can or you can also just hit the compile up here and that will compile the the the first contract and it will download the um compiler so that you don't need

internet for the rest of the the session. Oh, sorry I forgot. Is anyone still typing or is everyone Is there anyone who's not see in the playground yet? One person. All right. Do you need the the URL or you just no internet? Okay. Then I will uh do the brief uh intro of the the playground here. So uh throughout this workshop we'll have uh we'll be working on different examples.

Um so we do them one by one. there is already there are already solutions to all the the the exercises. So if you feel like cheating, you can just jump ahead and and and copy it from there. Um but please try to to see if you can solve the the the challenges your yourself first. Um I'll be explaining um each uh exercise and also helping uh anyone who who needs um help. uh if you are just uh interested in in solving things as fast as possible, you don't need to to wait. You can play around, do whatever you want. Um and there's a a bonus uh task in the end as well. Um so yeah, uh don't feel obliged to to wait.

Uh but uh yeah, of course it's nice if everyone uh keeps the same pace. Then we have on the right side here we have run where you can try out interacting with uh a contract. Um and we have run tests and um as you might see already we have these uh inline tests here. Um this is currently just in the in the playground but we will also add it to the um com the the binary itself and it basically means you can run uh tests um directly in your in your file here and what it does is it will uh run each of these tests. So here we send uh 100 tokens to

this 0x70 address and it uh shows that the transaction succeeded and the next one shows that um it reverted because there's basically nothing in the the function that was run. So this uh these are designed so that when they're all green a test or like a a an exercise passes. So yeah, feel feel free to to play around uh as you are writing the the code and uh I've gone ahead and basically created the the skeleton or most of the code is written. So you just need to implement one function or a couple of functions for each uh each uh task. Um, but yeah, if you look through this code, it is it readable from like

for most people or should I make it bigger. Okay, that's good. All right, then. Oh, that looks so bad. Uh, okay. So, first thing you probably notice that's different is that we have the Pragma soul core. So this uh the files have the same extension as you're used to from solidity so but we use the pragma soul core so that the compiler knows that it's a core solidity file.

You also notice that the imports uh look different. It's a it's a different uh syntax than what you're used to. And we have a standard library. So it's the std um which I think is um really really nice compared to uh classic solidity where every time we wanted to add a feature to the language we had to do it in the compiler itself and now we can separate the language um from the compiler and you can add features uh to the language uh as you want. Um I have one example uh here.

No. Yeah. Here for example, this is how message sender is implemented. So it just uses the caller up code um and gives you and then we have the message sender. So this is an example of what you can do in the standard library uh which also means that anyone can uh add features so to speak and the standard library for core validity will be a community process um that anyone can contribute to. And another example would be for plus and minus which we are using in this uh first task where you see that they are implemented like this. Um so it is just standard library code which uh yeah it's

nice and I talked about the test uh comments already and here it's just a note that the playground uses uh uh 0x F39 to deploy and run uh all contracts to start with. Um and then we have the 0x7099 which is just a second account that we'll use as receiver for for transfers. The contract division same as you're used to balances um with the mapping is also fairly similar. You'll probably notice that we have postfix uh type definitions rather than pref prefix as in um classic constructor also fairly similar to all of you. I hope uh we just define like a

initial balance of the message sender and uh set the supply to a th00and [snorts] and yeah then the task the first task here is to implement transfer. It should be um pretty straightforward um to most of you who've written solidity before it is uh basically just the same as you do in in classic solidity. Um and I I added added this to to show that there is a good amount of uh familiarities between the two languages. So it doesn't uh seem entirely alien to uh solidity developer to start writing core solidity. So yeah uh please start uh implementing this one

function body and uh you can as I said you can run the test along the way to see if um if your code is correct. probably the the the the one thing you can do it's you you actually don't need this line for for this to to work but you can say let uh it's what you use to define local variables um so if you wanted to just have message sender um called from you can do that uh you can solve it easily without um and other than that I think there's nothing new in this uh exercise so yeah Please uh go ahead and uh try to solve it. You can put up your hand if

you have any kind of issues. I'll also start implementing it maybe. But I would rather uh help people to do it themselves. So there's still plenty of room here in the front. So there's a lot of people in the back. You probably don't see anything from the screen. So it you should probably come and sit here in the front. So >> they also have it on their own screen. Yeah. Uh, but if you want, there's plenty of space in the front and if you have questions, you can also go to the schedule to the talk and then click there to answer ask questions. And if you missed the URL at the beginning or the QR code, if you go

to the questions, you can also see the address there and copy that to your browser. And if you open this address in your browser, in case anyone missed it, you will see the same thing Jacob has on the screen right now. And in the comments is the uh the the task to do. Okay. So I just started also uh writing the code for anyone who wants to follow along. But we just define the the the from as message uh sender and then we're doing a require to check that uh message sender has um enough balance to actually uh send the amount.

And the next thing we need to do I guess uh if anyone is uh just uh not coding alone but uh you can tell me what would you uh what would we do next? Would you uh decrease the the balance of the from or increase to or something else? >> Good idea. is also for on the flow checks like >> yes I will I would uh also show that after I would remove the require and show that it uh still fails because uh or like the 5,000 at least fails and of course there are still a lot of

um what we going to call it like um uh we'll still be doing a lot of uh nice sugaring and and the syntax uh shortcuts. So, right now it's still a little bit verbose uh what you what you need to do, but all of this of course will be uh fixed eventually. >> Oh, >> would you prefer to go through the questions at the end or in the middle? >> Is there relevant to the what we're doing? I would like to do it now, but uh these are not directly about the code right now.

Maybe I'll do those later if they're not so relevant to the current state. Okay. So, I think this this should uh work unless I made any uh typos or um yeah, looks like the tests are passing. Um so, yeah, one someone asked if there's um like a check for overflow underflow. um we should be able to remove this require and it will still um pass because there's a check um if we're underflowing um when we sent the 5,000.

Um yeah, so as you see the the tests all still pass because um we have the the check for underflow in the arithmetics uh by default. Is anyone uh like is everyone somewhat following? If uh if you're totally lost, it's it's it's fine. We can uh you'll get the solution when we uh if you take workshop one transfer and then the solution. Um you basically have what I just uh wrote. So you you're still able to to follow along. Any uh questions so far or people with with issues that I can can help out?

No. All right. check the time. Great. [snorts] Then the next thing we will do is we will implement uh so now we we start changing things up a little bit. We have uh this enome called change which has mint, transfer and burn. So those are the basically representing the three operations that our token uh is able to do at this point in time. A mint just takes a receiver, a transfer takes a from and two and a burn takes a from um and of course then the the we will have one function that takes care

of applying these changes uh which also takes an amount. So if we are minting uh we provide the the the change with um mint and then the amount that we are minting uh and the the functions itself transfer mint and burn all call apply with the the the change that they represent. Um so as you see right now we won't even we can't even compile because the compiler is complaining that we're not covering all the the cases. So this is um we have this check that [snorts] we can never have a case that we are not handling which is caught at compile time which is very useful uh to ensure that

you don't forget to cover a specific case. Um and this ultimately rules out uh an entire class of smart contract uh box that we have seen in the past. So if we hover on change here, it shows uh non-exhausting uh exhaustive pattern match and it says we don't have a case for um change transfer. Uh so this is uh what we need to implement um and should be pretty straightforward but if anyone is not familiar with pattern matching uh it might look new because it's one of the new features to to the language. The idea is that we take uh the match will take a change. So we have

this change of type change and the change is like this enome up here. Um and then change here represents uh any of those. So now right now we have uh a mint case that we are covering and we need to cover transfer and burn. So those two we need to implement. uh and once that is done then the the the test uh tests should pass. I'll give you a moment uh to to do it yourself but I'll also uh start implementing it by here so that uh anyone who prefers just to look can follow.

Um so we need to do the case trans. Yeah. >> So just a quick technical check. Hands up anyone who has issues with connecting to the internet and thus isn't >> but that should be fine. Like if if they loaded in the beginning then they don't need >> in but hand hands up anyone who has internet issues. >> So you can maybe help this too. >> All right. And uh there's still space in the front. So if you want to see what Jacob is typing on his screen then feel free to come in the front.

Okay. So here we define the the the change type. So the the transfer and then that one takes a from and to as I mentioned above. You can also see it here on hover that it takes uh two addresses and then it's basically the same uh as before like we do the same require that it's uh that [snorts] the balance is higher than or equal to um the amount that is being sent and say sufficient balance if not.

So this is like just more or less the copy paste or it is a copy paste of before. Um Oops. All right. So this uh basically uh

should it will still fail because we are only covering uh two of thea the three cases and now it will tell us that we are not covering the the burn um case. So we would just have to implement that. I don't want to type it out right now but it will look similar to transfer. It will basically just uh not have the um update here. I can actually just uh copy it over. Then does anyone have any uh uh questions about the the concept of pattern matching or like is it is it clear what's uh what's going on? At least I

know to myself that when I was first introduced to it, it was pretty uh different from what you're used to in in in classic Solidity. I can't I don't have them open. Can what? >> Can we get what? >> Yeah. So, we also Yeah, there's a there is a default case. I I will show that as well. Um it's I think I got it. Um, so I think we just need to do this one, right?

Okay. So, this should now. Good point. Someone is uh awake. Yes. So, this should uh compile and hopefully the all of the tests will pass.

Yay. They do. Um and yeah, below you see we just run like this these um common tests. They just run and um show that everything works as expected. Thank you whoever it was that uh mentioned the supply. And then for the default uh case um we can uh do something like default um which will catch any un uh like if we would add a a new case um or anything other than the default would match on that. This can be useful in in in some situations. I would not use it in in in something like this where we want to make sure we cover all cases but there

are cases where default is uh is useful. So this is basically a catch all. Yeah. Yeah. That's exactly what I just mentioned. Now you can use both the default or the underscore uh syntax for for that if we added a new case. So that would be like uh I don't know what a good example I can't think of anything uh interesting to do here. Um but uh you could do that. >> Yeah. So in in this specific case, I don't think it's a it's that good of an idea, but it could be that you had functionality to do I don't know uh two

like there are two things that you can can like do and then maybe a default could be catching all if if someone just like send token to tokens to address or uh it could be it doesn't have to be used only on these changes or like on emails like that but you could also match on [snorts] let's see it could be that someone sends uh it could be anyone sends an amount uh like you could have amounts above uh a thousand would uh give you a premium subscription. Amounts above 500 would give you a normal subscription and uh and then everything else we just do default and that just gives you a like

free subs a basic subscription. It could be something like that. So you just where you just know you care about two cases and everything else falls under a a third case. Um and you don't want to you don't need to specify it. So it's a both both a shortcut but also just a anything else. It's it's quite uh quite nice but uh it has its place but here I wouldn't use it because I want to ensure that we cover all uh all cases. Yeah. Yeah. [snorts] Um, and this also means that if you wanted to add a new type of change, uh, could be a transfer from or something like that, you only need to do it in in this one place and then it will ensure that you or it will make sure the compiler will make sure that you have to uh address it throughout your code. So

you cannot forget it somewhere. Is um, everyone somewhat uh, following along? Any questions? Yeah. >> Yeah. I mean it's it's a good So the question is when writing our first contract, what is the recommended way to handle custom errors and debugging within this environment? Um so we we're [snorts] still early days. We don't have like the the full uh tool stack yet, but we do have like you can kind of uh you can make it work. So you just provide the the the bike code to foundry for example and you can use that

to test against. So you can write now you can write your test in classic solidity and test it against uh core. I've done that a couple of times myself. But we do need to of course build some of these tools out. Custom errors is being added or was added Martin do you remember? >> Yeah there are custom errors. uh I just uh didn't introduce them here because I think it was fairly recently but you can do custom errors as well. Uh maybe if there's time I can show an example in the end. Um all right but then let's uh jump on to the to the next uh question isn't from a keyword from the import

statement. What import statement? Uh, I mean it worked. Um, I think it's not a keyword. Um, not in in core, right? From I don't think from is a keyword in core. It worked now with Yeah, sorry. Yeah. >> Oh, it worked wrong. >> Ah, like here I I mean it that's a good question. It worked. But actually I it's I don't think it's a key. I think yeah I don't know it worked. Yeah. I don't know how you

what M what would you define or what would you call this here? Like uh like it's not a keyword but what uh how how does it work here then? >> Yeah. You have you have an identifier from >> Yeah. Okay. So it's okay. So here it's an identifier called from but it's not a keyword keyword. Okay then uh let's jump on to the next one. So now we will um just checking it. Okay. Um now we will see what it looks like to not have inheritance.

So in this example we're introducing a new file called ownable. And uh you'll notice that it's not uh capitalized because it doesn't have a contract uh inside of it. And uh this is just a module um that has a bunch of uh functions and you can define what it exports. You still see that imports uh like SG and generic and store generic. Um and then we have a strct called ownable that has one field in it which is an owner of type address and then a function owned by which tells you like returns an ownable of uh like um

containing who the owner is. Um yeah uh ah sorry it sets the first owner. So you need to like initialize the owner and this one is what does that then um we have owner of uh which shows uh who is the owner and the require owner is a little bit like a modifier. So it's something we can call to check um who uh is the owner uh or like to to to make sure that only the owner can call something otherwise it uh reverts. and then transferred we used to um return the state uh with two as the owner. So this is a little bit different than than uh what you're used to as

well. Um and then we export the functions that we want to interact with. Um, and something that is nice here is that you can be explicit about what parts of uh a module you want to export um and what you want to expose to other uh contracts. [snorts] So a contract only uh exposes things that it uh like has public functions for. So from inheritance you might be used to that if you inherit something that has a public function that that function is also exposed by your contract and but here you have to be explicit about what you uh expose and only public uh functions in a contract

are exposed. So it means that there's um one place for example for auditors to go and look at your code and see what is actually exposed um and you don't have to dig deep into all the levels of uh inheritance to understand uh what um surface of functions are exposed. So this is I think a nice uh feature as well. The [snorts] task now is to uh just import um ownable and the functions from it that you want. So you just need to go like you have this line here um uncomment it and then go and import the the things from ownable that uh we saw it was exporting and once you do that

you will start to see that these errors uh go away and at the bottom once you have done the importing then there is a function called transfer ownership which you need to implement um and mint function that we want to have the only owner uh sorry require owner uh check on. So yeah, if you're following along, you could just do like import and then we need to get the

forgot what it was. We have uh owner, our supporer. And now we should see that these errors went away. So it should at least compile. Um but probably the tests are not passing. Not all of them at least. Um, so yeah, we go down here and we have uh the transfer ownership and we should be able to just set ownable um to be uh

what's a question? Okay, if I can spell What to do wrong here? >> True. Uh, was it the first commandment? Yeah. Ah, sorry. Yes, we should be.

So, this is uh yeah, this is how we will uh transfer or like change the the owner and in mint we wanted to do the owner check. So now only the uh only the owner of ownable can uh call mint. Um now the test should pass and we have yeah great and one at the bottom you'll probably see there's a small example of a a steel function. So,

so what I want to show is that right now because ownable only exports uh ownable here in this way um it means that it doesn't export the constructor of ownable. So we cannot make new in instances of ownable outside of the module where it's defined. But if we uh if we do import uh export sorry um with this uh this syntax then we are also exporting the the the constructor and that basically means that now we are able to uh create a new um oops um now now we can create a new

ownable um outside of uh of the module. So anyone can just uh steal so to see so to speak the the ownership. So if we compile this and we try calls we should be able to say uh call this deal function now with any of these addresses. So and this will basically allow anyone to create a new ownable uh instance and uh update it to be the the owner of it. So this is something of course you don't want to to to happen but it's something to be aware of that >> [snorts] >> uh you should not be uh like kind of showcase how modules can decide

what is being exported and imported and that you can uh limit what you can or what users can can do with uh your um your code outside of the the module it belongs to. So this can also be this is a pretty powerful thing because you have a guarantee that if you're not exporting the constructor then it's only inside this the module that uh exports it that you can actually update it and change it. So you could also we could have uh uh I don't know we we could have a unis swap style pool or something like that where whenever you uh interact with a pool it's only through the module that it can happen and then we can run a bunch of invariant checks every time a

pool is uh uh updated actually it's not updated but we create a new uh pool uh enum with the new numbers and we can check invariance on that which I think is a neat um side effect. Any questions on on this step? Yes. Okay. That's actually the next uh the next part is is covering events, but right now we don't uh we don't have support for events yet. We're we're working on it. Um so right now we circumvented so to speak by using uh lock three. That's the solution. We already saw that. Is anyone uh Yeah, go ahead.

>> Yes, there's also an uh there was a question if people can use traits in modules and I will use an example a little bit later if it's time. I think I'll make it. Um so yeah, they can. Um all right. Then there was a question about events if the is it just if events are supported or what was the question? >> Yes. >> Okay. Yeah. The classic events or events will be supported right now. They they are not um but uh they will be right now. You can see here how we can kind of circumvent it is by having uh lock three that we just just um use instead. And

then this function kind of emits a transfer. It's it's not exactly how um [snorts] it doesn't work exactly the same, but for now uh you can do it. And this is an example of what it maybe would look like in the standard library when you would add something like emit of an event. But the next uh task is about uh comp time comp time uh compile time evaluation. Um so this is another great feature I think that we have in the in core solidity where you can uh have things like you can provide the comp time keyword and then the compiler ensures that this is um [snorts] evaluated during compile time. So um

instead of for example hashing the signature of uh like the of of transfer uh during um execution in in the runtime you will actually do it during compile time. Um and I think here um yeah this task is fairly straightforward but um we then have this uh log that I showed before where you can uh emit the the transfer from event and a little bit uh I think below you can play around with it a little bit. Um I'll just skip ahead on this one a little bit so we can cover a

little bit more ground. Yes to to uh if it was possible to do the same with constants before. Um and to some extent uh yes but I don't know if uh like maybe Marston you want to add a little bit on on on this one but I think we can do more um >> so it it is similar to constant but it's uh the idea is much more powerful. We we're actually thinking about how powerful it should be but uh right now it can even evaluate assembly. So you can write anything as a comp time. Yeah.

As long as as long as long as sorry [cough] as long as it really can be evaluated at compile time. We we had uh we had too much spicy food yesterday. >> Um yeah. So I just jumped ahead here. Um uh to to to solve this one. you just had to add this uh calc which already actually has the the the compile uh comp time um requirement but we just added uh here for for clar clarification um and when you compile this there you'll basically be able to see if I can

find here uh here so when we compile this so this is the expected um hash of uh of the the signature transfer address u int. And if [snorts] we compile it, you should be able to see in the u um this is the the u output for for for this. You should be able to then wrong to search for it and see that it is just here as a constant as this hash in the compiled code. Um and of course here this is maybe not the most interesting interesting example um but for example

the entire um like a lot of things in the standard library we have this dispatch um part of the standard library that is used to dispatch like all the the the the functions and and it uses comp time as well. So all of it is calculated at compile time instead of later on uh during runtime. So you can do some optimizations here and the same if you doing any kind of uh I don't know calculating any numbers and stuff like that you can do it uh just have it represented at the as the the the result in your um in your bite code.

I am about to run out of time. Um I will just show a quick uh example. Someone asked about the the traits. Um, so here we have a little bit more of a complicated example uh complicated uh but like adding some more stuff and we add a hook or hooks um which uh has a trade transfer or it has two transfer hook uh no it has one sorry um with two enums one is max transfer and one is blocked. So for example, if you wanted to say okay, I want to have different checks running on my transfer. Uh one could be there's a maximum amount that you can send and the other is if we

wanted to block a specific address to be the receiver, then we can add these uh like a trait for this where we have implementations for for the two of them. So one here we have uh for max transfer we have a function called check which is run on okay I'll go back to probably show it here. Um so you see at the beginning of um of apply as we had before we now have transfer hook um that has this uh check that it runs on different uh hooks with of the of each of these changes. So uh if we look at this one, it takes um the hook which we had defined.

Oh, I forgot where it was. Oh yeah, the the the max transfer enum [snorts] and the limit. So let's say the limit is 500 and then we match on the change which is the change from uh from before. Uh now we actually move change out into its own module just so it's a little bit easier to to to work with. Um and then we do a require that tests or that the amount we're trying to send is uh below the limit that is set by the max transfer trade. Um and in the same way blocked would check that the address we're trying to send to is not one of the blocked recipients. So this is a very

convenient way that you can add uh features so to so to speak or checks to uh um a function. So here we will make sure that you you can't do any of this and then at bottom uh we stack it. So this means that we can do both of them in in one basically. We could also uh and they run in the order you define them. So in this case uh if you try to to transfer more than the limit to the blocked account it would fail already on the the limit and not on the fact that it's a blocked account. Um so this is one way you can add features without uh inheritance to your uh contract. And I think

oh yeah the I think that is basically it. So you can see it's just one in the contract itself. It is just one line that we changed uh to get this functionality. Um and then the the functionality is implemented. Okay. Two we also defined the hook here. Um uh but yeah the and the hook here it was 500. That's the the limit of max transfer as you can see. And then the the block address is uh this uh 3C44. Uh but yeah, I think that's uh about wrapping it up almost. Um any last questions for for the the hook part.

>> All right, >> there are some general questions here. You want to have them now? >> Uh yeah, if there's time, I'll just uh finish up here. Um yeah, there are a lot more examples you can you can find on the on the playground. Right now, the playground is what you've been looking at is set to only show the the workshops, but if you go to the URL and remove the workshop one, then you'll get the full playground um uh without the the workshop examples, and you have to add the workshop one back. If you want the the playground um we will be making the the examples from from this workshop into a tutorial in a book instead. So you can find it there maybe two weeks or

so once I'm done enjoying my vacation next week. Um and yeah uh if you have time there's a quick uh four question survey just uh to help me understand what uh to improve in this workshop and otherwise here's a link where you can continue uh playing around. There's also uh the release I mentioned and any contributions uh issues or PRs are very very welcome. It's still early days. So any feedback or any ideas you have for useful standard library functions to to add or fun examples you end up uh creating, please uh share them. I'm very happy to to take a look and give some

feedback or whatever. um come find me after or shoot an email to course argo.org if you have any specific requests. Um and yeah maybe we can do a question or two also if anyone has questions in the room but uh >> yes so one question is about the slide you have open now basically uh asking about if people can run this playground locally and I guess anyone can clone that repository and then run everything locally. >> Yes. Uh if you yeah if you go to soulcore- rs on uh on GitHub uh you'll find a folder called playground and from within there it's just a pnpm uh or whatever it's called uh command to run the

playground locally um so yeah that that works uh as well >> and then there's a question that in the AI era can we create common template which uh help to to write a smart contract in a faster way by having all the properties, rules, and config on like a standardized way that the AI then customizes. >> Uh I mean I think I think that's basically what a programming language is already to some extent. But um to in my experience um LLMs have been very good at understanding and writing core solidity from from the get-go. Um, so, uh, I I don't even know if there needs

to be a a stand a more standardized, uh, way than what the the syntax, uh, dictates. >> Uh, I I'm guessing that the person asking about this has previously been like taking open chapel templates and then customizing them. Is is there some similar thing for >> Oh, you mean like the Okay, so like uh libraries. Um I mean we hope now Hrien uh left unfortunately but I know that uh um like open sepin I would say they kind of have play and so lady have played the role to some extent of being a standard library. Um and one of the things of course we need to find out moving forward is is what

what goes into the standard library. Should it be batteries included? Should we have like re-entrance? Should we have an SC20 token? uh implemented for or like supported in the standard library or or how is this uh going to look like but I'm I'm sure that open silence so etc will be adding their own uh libraries too >> worth saying too that the imports and the modules is a way to reuse code. >> Yeah, exactly. So instead of the inheritance the the modules will will allow you to to reuse uh code. Um there are some other examples as well in the playground. Uh one is called extensions

where you see kind of how uh open seance style ESC20 token could be implemented with uh adding in uh specific features like ownable and mintable um possible etc. Um, so yeah, >> also traits are a powerful way in terms of abstract ideas. >> Yeah, exactly. So the the last thing we saw with the hooks um and traits, that's one way of doing it as well. But you like we we're still working a little bit on what like finding out what our recommendation will be um in in for composition instead of inheritance, but you can do different things depending on

on what you're actually trying to achieve. Um and for those curious one of the reasons to get rid of inheritance uh I guess this is the most uh like the biggest uh criticism of like from some people but also a lot of people who are very happy uh about it. Um but it is because it is difficult to to understand when you go layers deep and the C3 linearization can be hard to to understand. So we want to get rid of this let's call it uh vector or uh yeah vector for for for vulnerabilities and and make things much more explicit throughout

and related to traits there's a question that uh since there are trait traits how can dynamic dispatch be implemented like how it is in rust >> that's so the the the nontechnical ical answer is compiler magic. The technical answer is uh the instance resol multiparameter type classes. Uh the instance resolution is a I think biggest part of the of the type checker and a large part of compiler and then there is uh the functions are specialized to to monomorphic types because it's a polymorphic type system and then the uh the actual method implementations are uh specialized to to monomorphisation.

>> [clears throat] >> I could not have said it better myself. All right. Any >> maybe maybe the last more philosophical question. Can you explain the background of why this is called core solidity? >> That's before my time. But I think that the the idea is because as I mentioned uh it it is just a small core language. It is actually eight primitives uh and one type in a [clears throat] language called we call it sale. And that is what all the like what I showed is more or less just sugaring on top of sale. H but it can all compile down or lower down to to to this sale language which is just eight primitives and one type. And the idea is that it's small enough to

formally verify it for example. Um and the fact that it is so small it's easy to extend on and build on. uh whereas uh classic solidity is just a big uh I don't know what to call it but like it doesn't it it's it's it's harder to kind of reason about uh classic solidity um and actually have a a spec as well but here with since the language is so small the core where core solidity comes from then um [snorts] yeah we can actually have a a spec and we can >> is there some like consensus that classic solidity will be phased out and all new stuff will be in.

>> Well, I also had a point about this here um that classic solidity will continue to be maintained um but mostly probably maintained uh we we adding features is is a big uh quite a challenge um by now which is also one of the reasons why we wanted to or why we're doing uh core solidity. Um yeah, so it's not going to be phased out and of course it will have we will support any upgrades to to the VM etc etc. Um but there will be more focus on on on course going forward.

>> All right, that's for all the questions and uh I guess we're ready to wrap up here. >> Yeah, thank you very much for for joining and I hope it was uh somewhat useful and that you learned something. Let's give a sorry round of missing repository. >> You can find the GitHub repository link in the des there a line for it here and Linux is not >> sorry >> link is not open.

>> It's a GitHub problem. >> Okay, there's a problem in GitHub as a bad [snorts] internet and a bad GitHub. It's not a good company. I >> Okay, >> the URL is >> so Jacob will be around here for >> additional questions. Yeah. And now let's give him a round of [music]