Ethereum Foundation DevCon 6 - Developer Infrastructure Track, 18 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Demystifying Ethereum Assembly by Joshua Riley | Devcon Bogotá

Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/demystifying-ethereum-assembly/

# Demystifying Ethereum Assembly

The EVM creates an economic incentive to minimize computation and data storage.
This leads to extreme gas optimizations in a few different assembly languages and patterns.

In this workshop, we will learn about EVM assembly through both a walkthrough of EVM basics and real-world, practical examples of assembly. This workshop assumes an intermediate level understanding of programming and at least a beginner understanding of Ethereum.

Speaker(s): Joshua Riley
Track: Developer Infrastructure
Keywords: Assembly,Yul,Optimizations

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

A

A

Welcome everybody: this is going to be demystifying ethereum assembly, a practical zero to one guide, so my name is Joshua or JT, Riley I'm, an evm, smart contract engineer and so a little bit about why you know why I'm here giving this presentation there's a really really big gap between the intermediate solidity developer and the Wizards that can do the assembly black magic right that we see you know in some um popular GitHub, repos, so um I kind of went through this.

A

The hard way reading through you know as much documentation and paper and as many papers as I could, um and hopefully I've condensed this down enough that uh you know everybody here can kind of pick this up a little bit faster or maybe, if you already know this, you know, maybe this will kind of reinforce or you can learn new things. So this Workshop is going to be. You know pretty interactive.

A

So if anybody has questions, uh if I go over something- and maybe it's not clear- you know feel free to stop me, raise your hand, ask questions we're going to get to the bottom of pretty much anything. You guys have questions on today so, as we get started um section, one obviously understanding the ethereum virtual machine uh here is a link tree. It's going to be the link tree, slash evm assembly, and so this is going to have some useful links throughout this presentation.

A

uh The most important one um you know for you to be able to follow along and kind of play with these things is called evm.codes, so I'm going to be using that as well periodically throughout. Basically, what this is is a fantastic resource. It's got, uh you know everything you need to know about instructions, and then it also has a playground and that's where we're going to be demoing some of these things, so we can really visualize and internalize.

A

What's going on foreign, so first up we're going to talk about the instruction set, so the evm is a stack-based virtual machine with a relatively small instruction set, and these instructions can be categorized by one of the following. Roughly first is stack instructions, so these are things that have to do with the stack, the values that are on the stack and swapping duplicating things like this arithmetic instructions.

A

Are addition, subtraction, pretty basic stuff comparison, instructions tend to compare two values and then push zero if it's false or one if it's true bitwise instructions has to do with like bit, shifting and other really cool stuff memory. Instructions are going to be interacting with the memory in the evm which we'll get into a little bit more on that page and then contextual instructions. So these are like reading and writing to the environment, to storage and other things like that.

A

So first we have stack instructions, so stack instructions involve manipulating the position of a value on the stack or values on the stack, so push in value basically pushes a value to the top of the stack. Where n is the byte size of that value, pop will pop a value off the top of the stack swap in we'll swap a value on the stack with another and then dupe in will actually duplicate a value based on the index.

A

So as an example here this is a mnemonic bytecode. Basically, it's just a human readable format of what the actual evm by code is. So this is at the lowest level. uh So first we have push one right, so we're pushing a value of of size, one byte the value is going to be one and over here these uh orange bits here.

A

This is actually just uh comments to kind of represent exactly you know what the stack should look like after any given instruction this next one is going to push one and that value of one byte is going to be two. So now we have two and one on the stack you can do swap one which will swap we have dupe one which can duplicate the first value on the stack and then from there. We just do pop until we run out of values on the stack.

A

So if you guys want to open up the evm.codes website, this is evm.com playground. You can also find it in the link stream.

A

So, first we're going to do uh basically pushing the number one to the stack right. So we push of size one the value is going to be one we'll do the same thing with the number two I can do it with three.

A

And then we can start playing with this right. So let's say we want to swap the top instruction or sorry the top stack item with one. That's two items down from that, so we can do swap two and whenever we run this, we can basically step through every instruction here.

A

So the first one pushes the one to the stack. The second pushes the two to the stack. You can see the stack represented down here in the bottom right, we'll do the same for three and then swap two should swap the number three with the item two items down from it and there we go and it swaps.

A

So from stat constructions, we're going to go to arithmetic instructions so of course add We'll, add two values: sub we'll subtract. Two values mole will multiply two values: s mole does the same thing, but it treats the number as a signed integer. So what this means is that the number can be represented as positive or negative same thing with div uh div is divide and then s div, treats them as signed.

A

Integers mod will actually do the modulus, so the remainder after division exp does exponentiation, and then we actually have some instructions, add mod and mole mod. That will consume three items and basically do addition, then modulo and then multiplication. Then modulo.

A

And so here's our arithmetic example: we push a one to the stack. We push a 2 to the stack and then we call the add instruction. It consumes the two and the one adds them together and pushes a three to the stack.

A

Next, we'll push the number two to the stack, we'll duplicate it. So all right. Sorry, we'll duplicate the second item on the stack right. So now we have three two three and then we'll multiply, which will give us three or sorry we'll multiply. It'll, give us six, and so now the stack is six and then three and then we'll divide those which will give us two so hopping over to the playground again.

A

So we'll push two push three multiply and let's push.

A

Let's say five and then add so as we step through this see, the two is pushed to the stack, then the three those are multiplied. So the two and three are consumed. There's the six. We push the five we add it together and that'll give us 11.. Now this looks like B, because this is actually an hexadecimal representation. So, instead of going, you know one to nine, then rolling over. It actually goes one to nine, then a to F, and then it rolls over to the next.

A

So next up we have comparison instructions, so what this will do is pop one or two values from the stack perform a comparison and then based on the result, it'll either return true or false.

A

Those are actually reversed um if it pushes true, it's going to be one if it pushes false it's going to be zero, so LT will push if the Top Value is less than the second value. Slt, of course, is with signed, integers greater than or gt does greater than so. If the Top Value is greater than the second value, then we push one EQ will compare and see if the top two items on the stack are equal and then is zero. We'll push a true to the to the Top If.

A

Sorry it'll push true if the Top Value is zero. Now, something to note about is zero. You're going to see this a lot in uh you know you will file is another like low level assembly stuff is zero is commonly used as a sort of inverse operator right. So it's same as the exclamation point in front of a Boolean.

A

Thank you. So as a comparison example, we push one and then we push two we'll check equal. Of course, this is going to push false, that's going to be zero and then we can use is zero to invert that if we need to for whatever reason so it'll invert it the true and then at the end, we pop there.

A

Next up we have bitwise instructions, so bitwise instructions pop one or more values from the stack and perform some bitwise operation on them now and performs a bit wise and on the top, two stack values. So what this means is that every bit or every one is one or zero within this number. If you compare two values, the result is only one if both bits are one right, so if uh actually I think we'll have a bitwise example in a second, but basically it's only a one.

A

If the two bits are one, uh an or operation will be one. If either of the two values are, one xor is exclusive, or so basically it will only push a one if one of the two values is one, but not both, uh not we'll invert it. So, whatever the value is it'll invert that if it's zero one, if it's one zero and then shr and shl, will perform bit shift operations where we can shift the bits left and right.

A

So as an example uh over here on the left there's a little bit of encoding here, just showing you, um you know basically what these numbers look like in binary format and then on the right. We have push one push two you're familiar with this, but the shl operation is going to shift the number one by two bits right. So it's going to move it over two. So we can see uh here it starts at zero, zero, zero one.

A

But after it moves over two, it's going to be 0, 1, 0 0., and then we can do the same thing to shift it right. So we push another two to the stack. Shr is going to shift it back to where it was and then the not instruction. As you can see, it's going to flip every bit, so zero zero zero one becomes one one. One: zero.

A

So memory instructions can read and write to a chunk of memory. Now memory is this linear data that can be read and written too during the execution of a program. So it's a different place in the stack. It's good for storing things like arbitrarily sized values and things like that, so M store will store a 32, byte or 256 bit word to memory. Everything in the evm operates on these 32 byte words, so we can store full 32 byte word.

A

We can actually also store a single byte or 8-bit word to memory and we can also M load. So what this does is loads. A 32 byte word from memory, given some index in that memory, so here we're going to push the number one. Then the number zero to the stack and what M store is going to do is consume these two and it's going to say at position: zero, we're going to store the number one and it's going to be padded out to the full 32 bytes.

A

And so, if we basically after we've written to memory, if we push a zero to the stacker, if we push you know any um any index and memory to the stack, we can call M load it's going to consume that index and then return to us. The value there. So in this case, pushing 0 and M load is actually going to pull out this one.

A

We'll go ahead and do an example for this one.

A

Zoom in is that better cool, so we'll push the number one to the stack.

A

Wait we'll push one to the stack, then we'll push zero to the stack and M store is going to treat the zero as the index and the one is the value and we want to when we want to retrieve this later. We can push one, oh sorry, push zero and then M load, and so, if we step through this we'll see the stack has a one. Then a zero M store is going to put in memory.

A

That first word is a one and whenever we want to load from this, we start at index 0 and load, and it's going to push that value back onto the stack.

A

Now getting in the context, instructions specifically the ones that read from the local context- and this is not a comprehensive list- there are actually quite a few, but some of the important ones uh caller pushes the address that called the current context. So, if you're familiar with solidity, this is the same thing as message.cinder.

A

We have timestamp which pushes the current Block's timestamp again same thing as block dot timestamp. Then we have other things like static call which can make a read-only call to another contract. So if there's a function that sits on another contract, we can call that through static call, and as long as it doesn't write to persistent storage or doesn't update the state of the evm, then we can read from that call.

A

Data load can load a chunk of call data into the current context, and so what the call data is is basically the data that is sent to your contract, to tell you a little bit about what function, to execute what arguments it has and things similar to this so call data load can actually pull some of that data. For you, s-load can read a piece of data from persistent storage on the current contract, so contracts can only read their own storage, but basically we can read any slot using S load.

A

So as a quick context example, we can use the color instruction and it'll push that message sender to the stack we can. For example. Let's say we want to see if the caller is an owner of a contract right and let's say the owner is stored at slot zero in storage. What we can do, then, is we can use, push zero and then s load and that's going to load from the first slot. Whatever data is there in this case it's our owner and then we can compare them by using equal right.

A

So this is like the simplest representation of how to check if a contract is owned by somebody foreign. Next, we have the context, instructions that can write and again non-comprehensive lots of stuff going on here, but some of the really important ones s store can store data to persistent storage log in can append data to the current transactions logs. Where n is the number of special indexed values in the log right? So if you've again, if you've written solidity, you see the events you see sometimes that keyword indexed.

A

All of these are actual indexed indexed topics within this event. Now something to note here is in solidity. You can only have three indexed arguments in an event, but you can actually have up to log four, and the reason for this is a lot. The very first Topic in any log is actually the signature of an event right. So it's basically just a sha3 hash of this event, signature which we'll get into a little bit more in a moment and then the rest are the index.

A

Topics that you specify next is going to be call, so it makes a call to an external contract or to external code, but this actually can update the global state right. So there's no restrictions on solely reading or anything like that, and then finally, we have create and create two, and so what these can do is actually deploy code to a new address, creating a new contract.

A

So just a quick example of what you can write, for example. Maybe we want to store the last timestamp that some specific thing happened right, so we can use timestamp to push the Block's timestamp to the stack. We can push a zero and then s store and what's that, what that's going to do is store that time stamp at slot zero.

A

So, as a quick review again, the evm has a fairly simple instruction set most of what we've gone through. This is the bulk of what's actually going on under the hood. Of course, this section didn't cover every instruction, but it serves as a foundational understanding for Yule in the following sections and so to the left.

A

There's a simple contract that will store the caller's address and persistent storage and then return true to indicate success right so stepping through this, we have the caller we're pushing slot zero, we're calling s store. So that's going to store the caller, the caller address and Storage.

A

Next we want to store true or one in memory, and we can store that in the very first slot, so we'll push one which is true, we'll push zero, which is a slot in memory, we'll call M store which puts that in the memory and then to return. We actually have to give it two arguments. One is the offset in memory where we want to return data from, and then the second is the word size or the memory size that we want to return.

A

In this case, it's actually just going to be a single 32 byte word, so we'll push Ox, 20, Push, zero and then return.

A

So any questions so far on the instruction set.

B

A

Yeah, so these are the representation of uh the instructions here. So here again we have like push one push one and store Etc. Whenever we run this, we can actually step through foreign.

A

We can step through the instructions, and this is just a representation here.

A

A

Right so memory is here anything that's written. The memory goes into here. Anything on the stack is going to be here and then persistent storage. If any is going to be down there and then return value if any.

A

The stack can be 1024 items, I know, you'll notice in in solidity, you'll get the stack too deep error and actually the reason for this is you can only Swap and duplicate items, 16 deep right. So there's like a limit to how many local variables you can have because solidity actually stores these variables on the stack. So once it gets beyond that, solidity doesn't have like an easy way to access that without losing information. So that that's why you see that a lot um but yeah it actually can technically go like way way deeper.

B

um The memory is the frame dependent right. You.

A

Know we'll just go ahead and I'll just go ahead and answer some of these quick questions right now, while they're, while they're getting a setback up. So you mentioned, um like return data right okay, so uh there are actually special instructions to handle return data.

A

You have return data size and return data copy, um and so what you can do is whenever you actually make a call you're, not actually getting all that stuff back solidity kind of uh does does a little bit of magic for you there, but basically, what you can do is use the return data size instruction. It's going to give you the size of whatever was returned, and then you can use that to copy into memory.

A

Yeah, so it's not stored in memory per se like it's only stored in memory. Whenever you explicitly do it yeah.

A

Of Vlog zero, um oh I, guess we have the spec now.

A

Yeah, actually I don't want to get too too far ahead of myself, because we are going to do some more logging stuff, but I will go ahead and let you know so basically every log instruction um it takes. You know up to the number of topics which are on the stack and then it actually also takes a memory pointer and size. So, even if we don't log any topics per se, we can actually just log like a big chunk of memory, and so that's that's one way that we can.

A

You know, push data to that as an anonymous event.

A

It should be within the event logs I'm, not exactly sure how the client, libraries, decode Anonymous events. Obviously it's a little um unusual to see those nowadays but yeah we can. uh If we have time at the end, we can actually probably just break open a remix see how it works.

A

A

A

Yes, so uh create two uh one: it's I believe a bit more gas efficient and there's actually a way to deterministically, deploy to specific addresses from on chain using Create two. So it's just kind of a choosing utility of exactly which one you want to do.

A

A

Okay, cool sorry, I didn't want to go too far, and then we have to go back great, so the hardest part is over. uh That was all the really like in-depth stuff that uh we'll kind of give you this foundational knowledge for how to write. Yule you'll, thankfully, has a much higher level syntax. uh So what Yule is is it's a low-level language uh that can be written in inline solidity or as a standalone language? You can write Yule files by themselves, but you can also use it as a compilation Target.

A

So it also acts as an intermediate language that you can compile. Other high-level languages too, uh built into the language, are most evm instructions. These are callable as functions. uh There's basic control, flow support and functions. Well, user-defined functions now: you'll notice. Whenever we start looking at your code that the stack is largely abstracted away with the exception of a built-in pop function. So if there's some value that, maybe you don't need, that's returned from a function, you can just pop that immediately.

A

So here we have the syntax overview now note that the keywords, object and code are actually only used in Standalone you'll files, so chances are you're not going to be touching this if you're just writing inline assembly.

A

um One other thing to note here before we start stepping through uh Yule does have the if statement, but it does not have the else statement so to handle multiple cases, we can actually just use a switch and then the for Loop functions very similar to what you see in other high-level languages. Obviously, the syntax is a little bit more funky, but it still does the same thing so stepping through starting at the top. We have the assignment syntax.

A

Sometimes we have a colon, an equal sign, so anything on the right side is assigned to the left side variable. If the variable is being newly declared. If we're not reassigning, then we need to use the keyword, let for the function. Syntax. We have the keyword, function, the name of your function, any arguments and then return variables from that and so inside this function you can see the letter c is our declared as a variable implicitly by saying this is a return value and then colon equals will assign the sum of A and B right.

A

So you can see this is a lot simpler to read than just pushing things and adding- and things like this- and another thing to note about these internal functions- is that the return is implicit because return itself is actually an instruction that returns to the caller itself. That's not what this is doing. This is actually just manipulating some items, leaving an item on the stack and then jumping back from wherever this function was called foreign.

A

So here we have the if statement in this case we're checking if a is equal to zero, and if this is true, then we can execute some code. Inside of that, in this case we're just doing a revert below this. We have the switch so the switch. We have a value that we want to compare against and then each case is going to have the value that this variable could be right so case.

A

One means, if a is equal to one then we'll handle that yeah comments are wrong here um case two is: if a is equal to 2 and then default is our fallback right. So if nothing else matches, if we need to just do some logic to handle the rest we use default and then finally we have the for Loop right. So first we have uh let I we're assigning it zero. So this is your I equals zero part in the middle.

A

We have that comparison, so it's less than I and a so as long as I is less than a we're going to continue iterating and then next we have I being assigned basically the sum of itself uh and one right so we're basically incrementing it and then inside of there we can iterate and do our looping logic, okay.

A

So as a quick comparison to mnemonic byte code over here on the left, that was the code that we wrote a moment ago to uh you know, store the caller in storage, uh store, true in memory and then return that from memory and then over on. The right side is how we do it in Yule. So a lot less a lot, less verbose.

A

And so now we're going to jump into Yule in solidity, and this is really important, because not very many people write Standalone assembly files these days, most of the time you're going to be operating within the bounds of a solidity file. So you need to understand what standards and abstraction solidity has created. So some of these include the call data layout, which is the layout of that data that gets sent to your contract. The memory layout, storage, layout event, logging and errors.

A

So call data layout per the application, binary interface or ABI standard. The call data layout is as follows. So first, the first four bytes are the selector of a function and basically this is the sha3 hash of a function, signature, and that includes the name and then any argument types within that next, after the first four bytes each argument is padded to 32 bytes, no matter what, even if it's a un8, it's always up to 32 bytes.

A

um If an argument is of dynamic size, then the slot, where it should be, is actually going to hold a pointer to a place in call data where the rest of the data is. So if we have, let's say a string, that's over 32 characters. It's not going to fit in a single slot. What we have is a pointer that says: okay after everything else, here's where the string starts and it's just going to go, and there are other ways to determine. You know how long the string is.

A

So as a quick, visual representation. Here we have the transfer function, which this comes from the erc20 standard. So first up we have the signature. So that's transfer, it has address un256. now we're actually hashing here is transfer parentheses address un256. That's the only part that we're hashing here. So we can see the the hash full hash digest here, we're actually going to clip that to the leftmost four bytes and then the actual call data layout of one of these is going to be those four bytes followed by an address.

A

In this case, it's going to be the target to whom we're sending the erc20 and then the next is going to be the value right. So, even though these you know like an address is not a full 32 bytes we're still patting it all the way foreign next is going to be the memory layout. Now this one is really really important because per the solidity documentation. The first four slots of memory are reserved now slot zero and Slot Ox 20 or slot 32. These are actually scratch space, so you can use these.

A

You know whenever you're doing things in inline assembly. The ox 40, though, is the free memory pointer. So basically, what this does is, as memory is, expanding solidity will actually track how big memory is and when you can start adding new things to memory, and so what we'll actually do in some of this in some of the seal code, is we'll actually load from that to figure out where we can start storing things in memory. So it's really important.

A

If this does get overwritten, you have to make sure that you have that variable on hand right, so you can increment it if you store more things in memory, etc, etc, and then ox60 is a zero slot, so the zero slot is reserved specifically for whenever you're allocating new arrays I believe um this is like basically, a big big No-No Zone anytime people start overriding this. uh You know it's not a very good security practice.

A

You have to be very, very careful about it, so I'm not going to recommend it, but we have seen it before and we'll probably take a look at somebody who does that a little bit later, uh no dynamically sized arrays will occupy one slot which holds that pointer to where the actual value is in memory. There's another slide that indicates the length and then every every slot after that is reserved for a single element.

A

So if you have five elements, even if they're small values they're going to occupy five full slots now, byte, arrays and strings are similar with the exception that their elements are tightly packed and aligned to the left. So for Strings, it's you're, basically using a single byte value to represent a character. So in this case on the byte level, it is equivalent to byte arrays we're going to pack those as tightly as possible.

A

So as a quick memory example we're going to step through this now it's a function. uh It's pure it's going to return some bytes right, and so what we're going to do in here is first load the free memory pointer. So again, we're going to load from ox40.

A

we're going to declare this or assign this variable data because remember anything, that's declared bytes memory, okay, zoom in oh yeah, I thought. So thank you. It is not letting me zoom in.

A

Yeah sorry, this is not going to let me zoom in here, um but I'll go over basically every lines we'll step through here so uh yeah the data. Basically, what we're doing is storing that pointer to where the bytes are going to be restoring that next we're going to store the length. uh You know the length of the byte array at this point there, so at the free memory pointer we're going to store byte's length in this case we're just going to store four bytes.

A

It's going to be one one, two, two three, three, four four um we're going to store that then, and the next slide we're gonna. Well, sorry: first we're going to increment the free memory pointer right, so we're keeping track of this we're keeping track of how much um you know how much memory is being used here.

A

How much memory is being written to so we're going to increment that by 32 bytes or by a single word, then we're going to store at this new location, the bytes that are going to be padded they're, going to be packed to the left. After this we're going to increment the free memory pointer. One more time and we're going to store the basically in the free memory pointer slot we're going to store this updated free memory, pointer right, so basically as we're incrementing.

A

This we're keeping track of where the new free memory is and then once we're finished. With all of this, we're going to store it at the ox40 slot.

A

A

Right so it's going to again: let's say you append an extra bite to the end of this. It's going to store that extra bite at the end. It's going to keep it packed and then it's going to increase the.

B

Value of something else like if you, if you know, there's something at this right after that array and then you push it will move essentially right. All of it.

A

Should I haven't tried that we can actually try that as well? We can hop over to remix and try that um it would make sense if it would right, because then it would just get really really confusing right. Okay,.

A

Right right, you're right! Sorry, thank you! Storage.

A

Right so in solidity, uh you do have to specify the length ahead of time. Thank.

B

B

A

uh And they don't hit on one. It's like the like, like a struct like a memory structure, so memory struck so struct actually acts similar to a dynamically sized uh value. So it's actually going to be a pointer to that as well.

A

B

A

So whenever we store so the first time we're storing the bytes length right, we're storing the number four, um even though it's just a single value, that's actually occupying a full 32 bytes. So we want to increment it by the full 32.

A

Any other questions.

A

Great, so next we're going to have storage now, storage is actually going to be a few different cases here. First, we'll start with statically sized variables, so personalities, documentation, storage layout starts at slot zero. The data is stored and the rightmost bytes of that slot. Now, if the next value can fit into the same slot, obviously this is determined by type and the maximum value. It will actually be right, aligned into the same slot, so you can actually pack variables into storage.

A

You can do the same thing with storage, structs and then immutable and constant values that you see in the contracts they're actually not stored in storage at all. um So, basically, what these are. Is they replace that compile time with the exception of immutables? So if you have an immutable that can only be determined at deploy time whenever it runs to the Constructor it'll, actually replace every instance of that in the byte code.

A

So as a quick example, we have a contract, it's got five values in it. First is going to be a full un256, so we want to occupy an entire 32 byte slot. With this next we have two values of 128 bits, so basically 16 bytes each so these can actually be packed into a single slot and we'll see that they are so.

A

B is two it's here and the right most uh bit and C is packed in the next rice right most place in that slot, and then we have finally two U and eights which are stored here all right, so everything is packed as tightly as possible in storage whenever we're doing this layout next for a dynamically sized variables again per the documentation in solidity. A mapping slot is the hash of the key value concatenated with the storage slot.

A

Right so, let's say, for example, in a balance, mapping in an erc20 IT Maps an address to a unit 256, let's say it's in slot zero. What it's going to do is whenever you need to read or write to this, we're going to take that address, Pat it to 32 bytes concatenate, that with another 32 bytes, which is the slot it's going to be zero, and then we hash all of that and that's where the actual value is stored.

A

Now dynamically sized arrays, it stores the current length in whatever slot it occupies, and then its elements are stored. Sequentially starting at the sha3 hash of that slot number byte, arrays and strings are stored, the same way as other Dynamic arrays. Unless the length is 31 or less.

A

If this is the case, then what's going to happen is all of that's going to be packed into a single slot left aligned and then the length of that is going to be packed or is going to be placed at the rightmost byte and it's going to be 2x the length.

A

So looking at this one, we have three storage variables. We have a string, a array and a mapping. So looking to the storage layout first over to the left, we have six one, six, one, six, one, six one. These are the Four A's and then over on the right. We have eight, which is two times the length in the next slot, we're going to store the length of this data value, it's going to store one and two right.

A

So what's going to happen here is whenever we run whenever the code is executed, it's going to see that the length is 2 here at slot one and whenever it wants to access these values, it's going to Hash slot one and that's going to point down here to oxb1 et cetera Etc, and then we can see here's the first value and here's the second value and then finally, we have the mapping. It's mapping an address to a un256.

A

The actual storage slot of a mapping is always zero. That doesn't mean that it's not incremented, the storage is still incremented, but this slot is always going to be zero and then any addresses that are mapped to, of course, will be um that hash right, so oxe9, etc, etc.

A

So one more thing to mention something: that's really important to note- is storage in regards to inheritance, so solidity uses C3 linearization. So, basically, in the context of storage, what this means is storage slots, an apparent contract precede the child contract storage.

A

When a child has multiple parents, the order of the parents, storage is set by the order of inheritance right. This process is repeated, recursively and storage. Packing rules are still in play when applicable.

A

So here we have uh basic inheritance example: we have parent zero. It's going to store a it's going to be one parent, one is going to store B at a value of two and then finally, we have child, which is going to inherit parent, 0 and parent one, and it's going to have its own value C and that's going to be 3 and looking through the storage layout. First, we have parent, zero storage, then parent, one storage, then child storage. This is really important to note, especially with things like proxy contracts.

A

You'll see in some of the open, Zeppelin implementations, these storage paddings and things like this for upgradeability.

A

So next up we have event logs. So per the standardization event logs follow the following rules: they can have up to four topics. The first topic is always that hash of the event signature. So it's going to be the event name, parentheses and any types uh and the non-index topics are logged by storing them in memory and then passing to that log instruction, a pointer to where that memory starts and how big that memory is so as an event, log example at the top.

A

We have a hash and that's going to be the the event signature hash. uh Next we're just going to have. You know A and B, simple constants now in solidity. This first function is how we'll log this right, we say, emit the name of the event and then any arguments that go to that event.

A

Next, we have log in Yule, so this is actually what's happening under the hood. Whenever you do this in solidity, so first we want to store note that uh B is not indexed, so we want to store that in memory and then a is indexed. So we're going to have that you know on the stack right. It doesn't have to go into memory. So first thing we do is we're going to store B. We can just store it at slot. Zero, we're not going to be dealing with memory after this right.

A

The function is going to end, so we store at slot zero B, and then we call the log 2 instruction and what we're going to pass to. It is a memory pointer in this case slot zero of memory, the size of memory, which is going to be 32, bytes, the event hash, which is going to be topic one and then the index topic a which is going to be topic. Two.

A

So next we have errors so per the standardization. An error consists of a four byte selector and some error data. Now solidity actually has two predefined errors. This is error and panic, but since solidity, 0.8.4 developers can actually Define custom error types where you can have names and arguments and it's actually a bit more efficient than the standard require Boolean string. The reason for this is the the solidity defined errors. First is panic and it's got a unit 256.. uh So this is things like uh divide by zero overflow underflow.

A

That's when the Panic comes into play, each one has its own code, it's in the documentation and the next is the actual error error. This takes a string in memory and you can see so first is a panic code, so we have these four bytes, which is the Panic selector and then the next 32 bytes is going to be the actual Panic code. In this case, it's one then the next one is going to be require or what is standard with require.

A

We pass it a Boolean if it's false, it's going to throw this error with a string in it. Now note this actually takes up a lot more memory, because we have the error, selector and remember per the standards of strings. We first have to have a pointer to the string and then the actual string itself right. So that's going to occupy extra data.

A

Right so basically, because the error selector is only an offset of four bytes, that's actually not padded to the full 32.. So right after those four bytes we're going to start putting other data.

A

Any other questions.

A

Great all right, so next we're going to do applied, yield plus solidity, so we're actually going to hop over to remix and that's a remix.othereum.org.

A

And from that link tree earlier, we actually have some boilerplate code here, make sure this is big enough to see.

A

uh So you might want to just copy paste this from that link if you're going to be following along, because you know lots of already pre-encoded data and all that kind of stuff, so I'll give you guys a minute to get that pulled up copy pasted all that good stuff.

A

A

Just another second.

B

A

Yep, so that's going to have the code it's going to be in a gist, but you can just copy paste that.

A

Yes, one moment.

A

Maybe not I'm going to write it right here.

A

So it's going to be the link uh link, tr.e ethereum assembly, foreign.

A

Hopefully, internet doesn't rug, pull us here.

A

All right we'll go ahead and jump into it, so everything here that's predefined. This is just for the sake of us not having to go in and code stuff in the hexadecimal and all of that yeah right in the middle of the workshop. So just looking through these constants really quick how we have the length of the name in this case the name is actually going to be Yule token, so the length is going to be nine characters and then in here we have padded over to the left, the uh the string.

A

Next we have the symbol, that's going to just be you'll, Yul, all caps, and so here we can see the length is three, and these are the three characters for that string after this I went ahead and hashed the selectors for two two custom errors that we're defining here. One is going to be insufficient balance and the other is going to be insufficient allowance.

A

Now, no insufficient allowance, we're actually going to pass an address of the owner and the spender in here, and this is going to give better error messages for client libraries and for users.

A

So hopping into this first thing: we're going to do is we're going to define the name function and we're going to make this pure we're not storing anything in storage. We're actually just going to return a constant I'm just going to return a string in memory.

A

A

Now, what we're going to do if we remember the standard for storing strings and memory first is going to be the pointer, then the next slot is going to be the length and then the slot after that is going to be the actual data itself. So we're going to do three memory rights and then we're going to return from that.

A

So, first we're going to m-store at slot zero we're going to store ox 20. and that's where the actual data is going to be. It's going to be a 32 byte offset.

A

Next, we're going to store oh no hold on safety memory pointer. We want to load from memory.

A

So we load that uh now. This actually should be fine in this case like we know exactly where it is because nothing's been written in the memory, but it is good practice as often as possible to use this free memory pointer, so we're going to load from ox40.

A

Sure yeah so, let's say um so, I mean if you just start writing to the zero slot and in this case we're going to occupy three slots. That's going to take slot zero, Ox, 20 and Ox 40.. So it's actually going to overwrite the free memory pointer now, in this case we're actually returning from assembly. So we are safe here, but the problem is: if we're doing some assembly- let's say within you, know a function and maybe there's stuff that's happening after that.

A

Solidity is going to trust that whatever value is in ox40 is the right value. So if we overwrite this to something strange in this case, uh you know it would be the string padded over the left, which is actually technically a massive number. This would actually consume a massive amount of gas and realistically probably revert but yeah. So basically as much as possible, we want to use um you basically load whatever is at Ox 40, that's going to point. Normally it starts at Ox 80.

A

So that's after the four Reserve slots, uh but again for the sake of you know, keeping it safe. We're going to do it like this, so we m-store at the mem pointer we're going to store the link or sorry not the link, the ox 20 pointer after this we're going to store 32 bytes later we're going to store the actual length, so we're going to add the mem pointer nox20, so we're increasing. You know by a single word size we're going to store the name length.

A

Next, we're going to store at an ox 40 byte, offset.

A

uh You mean like, after the first M store, can.

B

We be storing the next appointment.

A

uh No, so this is actually an offset from this value itself, so yeah, so the ox 20 offset is just uh pointing to the actual link. That's itself.

A

So uh we stored the pointer, restoring the length and now finally, we're actually going to store the data. Foreign should look like right. Now is starting at the free memory pointer. We have the string pointer the string length and then the actual string, and so this is going to occupy three slots which is ox60. So what we can do is return starting at the mem pointer.

A

We can return Ox, 60, bytes, so very quickly. We're going to compile this I'm on solidity, 0.8.17.

A

We'll check that the compiler is at 0.8.17.

A

Everything's all good, so now we're just going to deploy this to a local virtual machine, and here we have the name function. Whenever we hit it, it's going to return Yule token for us.

A

All right, so next we have the symbol function, it's going to do basically, the same thing, the only difference being we need to store the symbol, length and the symbol. Data foreign.

A

A

Then we store in memory at the mem pointer string, pointer.

A

At an offset of ox 20.

A

We'll store the symbol length.

A

And add an offset of Ox 40, . or we'll store the symbol data and then same thing as before. It occupies the same number of slots, because everything is padded, we'll return, mempointer, ox60.

A

Now note, in this case, we're actually not incrementing the free memory pointer and that's because we actually are returning from the assembly itself. If we were to break out and continue doing things, we would actually want to actually store. You know what the new free memory pointer is. In this case, we would increment it by ox60 foreign.

A

Next, up we're going to do decimals.

A

It's going to return to un8.

A

So first now, in this case, we're actually not occupying very much memory at all, we're actually only occupying a single slot, so we can't actually just write to the very first slot right. It's mostly whenever you need the right three or more slots that you want to actually do it at the memory pointer in this case we're going to do a little bit of a hack there to keep that in the lowest slot. So we M store at zero.

A

The number 18 because we're not bad people and use six as decimals.

A

And then from there we're going to return from slot zero in memory we're going to return Ox 20, even though it's a un8 it's stored at the rightmost bytes. So we need to return that full 32 byte word.

A

All right now that we're done with um all of that basic boilerplate stuff: let's go ahead and set up a mapping. This is going to be mapping an address to un256.

A

We're going to make this internal in this case because I want us to actually like do it in assembly and see exactly what's happening. Obviously, we can just make this public and make it a lot easier, but we'll say internal underscore balances.

A

Next storage slot we're going to need, after that is going to be the allowances, so we're going to map and address to a nested mapping which Maps an address to a un256.

A

I'm just going to comment here what this is actually mapping to.

A

Great all right, so next we're going to do the balance of function.

A

It's going to take an address and we're actually not going to name this variable because we're going to manually load it from call data. So we can see how call data is working, but it is going to take an address.

A

It's going to be a public view function because we are going to read from State and it's going to return a uint 256.

A

All right, a quick time check great okay, so this is where it's going to get weird. um Remember: we're mapping an address to a balance and per the standard. What we need to do is we need to hash the address and then the slot and memory or a slot and storage. In this case it's zero, so we're going to Pat an address and then we're going to put zero and then we're going to Hash it. But the hashing function actually reads from memory, so we're going to use some memory to do this.

A

Okay, so first thing we do is we're going to m-store? Actually, no we're going to assign this variable for readability, we'll optimize a little bit in a moment. So first thing we want to do is get the let's say account, and so what we need to do is load the address from call data. Now, if you remember the first, four bytes are the function selector and then the next 32 bytes are the first argument in this case our address.

A

So what we'll do is we'll call data load and we're going to do that at an index of four. So it's going to take the next 32 bytes and put that into the account variable.

A

Next, we're going to store this in memory.

A

At slot zero we're going to store accounts and then at slot Ox 20 or at the 32 byte slot we're going to store just zero.

A

Next, we're going to get the hash which is going to be 256.

A

and what this is going to take an assembly now in you know, high level solidity. What this is going to take is like a string or bytes, but in low level uh you'll it's actually going to take a pointer in memory and the size and memory. So in this case, we're going to start at slot zero and we're going to consume two different slots right. So ox 40.

A

So this should actually be the key to this person's balance, so we can do from here.

A

Is we'll say, balance and that's going to be S load? Oh no balance is a reserved word hold on there. We go account. Balance is going to be S load at that hash right. So we're loading from persistent storage. This slot.

A

Next thing we want to do from here is: we want to M store now at this at this point, we're not actually going to need uh what's in slot zero and Slot. uh Well, 32! Well slot one like 0 and 32 here, so we can actually just overwrite that, with the account balance, okay, okay and then finally, we're gonna return, and so that's going to start at slot zero and it's going to be Ox 20 bytes.

A

So this is kind of like a more verbose version, so we can see exactly what's going on with variable names and things like that, but uh let's go ahead and do just a little bit of optimization and seeing like what what you might actually see in production right, so account is only used once that's loading here from call data, so we can actually just remove that and put that here right. So we're storing in memory add slot zero whatever's in-call data starting at four.

A

Here we have this hash.

A

Instead of declaring a new variable, we can actually just load that straight from Storage and then, instead of declaring an account balance variable, we can actually just replace that as well.

A

Right and so now it should be functionally exactly the same. We're storing the first argument in memory at slot zero, we're storing the slot number in slot ox 20. and then we're hashing that loading from Storage putting that value in the memory and then returning from memory, and so this is the full process of what a balance of function is doing.

A

That's the length of uh memory so far, so these these two slots, sorry.

A

A

A

Exactly because it's in the it's in the first storage slot, we can do that at zero, actually, something else we can do here since this is already implicitly zero. uh We could remove that, but again, for the sake of safety, we'll just leave that for now.

A

uh Return with, like just parentheses, volcano right, so in this case it's actually going to give us an error because it actually is.

A

Oh right right so like basically, if we don't say like return down here- oh yeah, so in that case it's actually not going to return anything like. If we did this, it would actually like load from call data load from Storage put it in the memory, but it wouldn't actually return anything to the caller, but the function itself is prepared will return some people right so I mean you can see here. It gives us a compiler warning. Let's see, unnamed return variable can remain unassigned.

A

That's actually a weird one: let's try that it's going to give us a warning, but we're going to try it anyway uh by the way this is using. Remix is a fantastic way to try out these little edge cases if you're ever not certain how something works. This has been an invaluable resource to try these things out.

A

So let's go ahead and give it a try. Balance of uh we're gonna need an address, we'll just copy this one.

A

It returns a zero okay, so I guess in that case, if you don't explicitly return, Then solidity will actually insert a return statement for you and it's just going to return. You know nothing at all.

A

So call data only loads using call data load, it only loads 32 bytes. um So in the case of like, for example, if you need to figure out what the function selector is right, you can only grab the full 32 bytes. So in this case you would actually use bit shifting. You would want to there's those four leftmost bytes. You want to shift them all the way to the right foreign.

A

So, just adding this alone shouldn't add any extra op codes. This is just like a abstraction for the high level language, but I believe we could actually just access it like this.

A

So this and what we were doing a moment ago is actually functionally identical right. So either we can like manually load from call data or if we name the argument, we can actually just put that in there.

A

Right yep, because the the function selector will be the same and then, if it's not actually used it shouldn't, consume and I mean of course it'll. There will still be a place in the call data for it, but if we're not explicitly using that variable, then you know there's no point in which that's going to be loaded from call data by solidity.

A

A

um No, so what this actually does is so the mem pointer tells you obviously where in memory to get the value and then ox60 is a length, but what this is actually going to do uh in this contract, it's going to finish executing it's going to stop executing and then whoever called this contract, whether it's neoa or another contract it'll, actually return that data. So it'll take that chunk of memory, in this case 60 by or ox60 bytes from free, mem pointer and that's actually going to be returned.

A

You know into it's going to be returned either to the client Library like ethers or web through JS, or it's going to be returned to another contract and coded as a string. Three still.

A

Right right, as soon as we call return, it's actually going to stop execution from there. So, even if we put in anything after that, as long as it always returns, we'll never go there.

B

So each function has its own memory uh stack when you execute or they share across, like if you go, uh you know.

A

B

They share the same memory or each.

A

Right great question so um any time that you call a contract, it's going to create, what's called a context, and so this context is going to have a clean stack, a clean memory. It's going to be able to access the storage at whatever address. Is there right and then other contextual information? So basically anytime a function is called on. This everything is a clean slate. So it's going to read and write from that same clean slate and then once the function finishes, it stops and the memory is gone right.

A

So uh in this case like they're, technically writing to the same same storage slots, but they're never executing at the same time. So we don't have to worry about any kind of like memory, overwrites or anything.

A

So if you call an internal yes, so if you call an internal function um actually at compile time, but this is a little bit confusing about um solidity- is that you have like public and internal functions. Public functions explicitly, you know, take some information from from the caller and then it's going to return some information based on that, whereas internal functions there's actually what what it does is it takes a number of items on the stack.

A

Let's say your internal function takes three arguments: it's going to expect three values on the stack and then it's going to operate on that and if it returns anything, it's actually just leaving values on the stack so inside of internal functions. Whenever you return from that, it's not actually using the return instruction. It's actually just leaving it on the stack and jumping back to where it came from.

B

B

A

Right so the first thing that happens during the execution of a contract, at least per solidity, is we're actually going to store a free memory pointer. So like the first two slots, you know zero and Ox 20. These are always going to start at a zero ox40 is going to have that uh free memory pointer and then uh the next slide after. That, of course, is the zero slot, so we're not putting anything there.

A

We can actually take a look uh briefly if we compile this and we look at compilation, details so you'll notice, the first few op codes here, we're going to push ox80, then we're going to push Ox 40 and then we're going to M store and what that's doing is storing ox80, which is the first free memory pointer we're storing that at slot ox40- and this is the first. This is actually like a big Telltale sign that a contract was written in solidity. This always happens. First, every solidity contract starts with you know, 6080604052.

B

B

A

Like when you have multiple internal functions or right yeah, exactly so, uh what what solidity actually does is those first two slots. uh The reason that they're kind of reserved is that's actually normally used as a sort of scratch space for hashing, so normally you're hashing, two values together. So that's where we'll put that and then hash that together.

A

A

Right so per the standard of how strings are stored in memory, it's always a pointer to the string and then the length of the string and then the actual string itself.

A

um So in this case it's kind of a formality, but it's really important to have that Ox 20 there, because whenever we return it, the client libraries expect it to be encoded as um actually no does that return that we're gonna try it. So, let's call name.

A

And what we can do here, this is another great way to look through transactions and find things you might not be sure about. Let's break this out, and it's not going to, let me make it bigger, okay uh right. So what we'll do right here at the very end, let's take a look.

A

So we have some memory laid out here, uh mostly zeros. It looks like all done, let's step through this really quick.

A

I really wish this would make me. Let me uh make it a little bit bigger here, uh but.

A

So here's the state of the stack right in this case we're going to push uh the free memory pointer, which is ox80, we're going to push uh the length which is ox60 and what that's going to do is point to slot ox80 in memory which is going to be here, and it's going to go for ox60 bytes. So here's the first here's the second and then here is the third right so because this actually gets returned with it. Client libraries are going to use this to actually decode strings.

A

So if we actually didn't, if we didn't return this properly, it would actually throw an error like it wouldn't know how to decode. It would just give you a bunch of bytes back right, so in that case it is sort of a formality, but it is important. You know to make sure that the client libraries know how to decode I think there was one more question right.

A

Call it internally Oh, you mean like if I say, like this dot name.

A

Right so we wouldn't want to use the the return instruction inside of an internal function like if it's being called internally um I mean you can use that, but just know that that's going to stop execution at that point, which is not what you want right, because that'll actually return back to the caller. So if you're trying to like return from an internal function, you're actually just you know, jumping back to the main function and that's where the actual return instruction is going to be.

B

B

Like 20, yes, that's an offset right.

A

B

Okay, so if you store the data, I, don't know if there's 16, for example,.

A

Yeah, so what that actually is, is it's it's Ox 20 from that place in memory.

A

Right uh so balance, let's go ahead and put that return back.

A

Okay, uh next we're going to do the transfer, and this is where it's going to get weird we're going to have. Basically, some conditional logic in here remember that overflow and underflow checks only happen in salinity, 0.8 and after so basically anything before that, and then anything assembly is unchecked, which means if somebody tries to transfer out more than they actually have. The evm is not going to stop that from happening. It will actually underflow roll back over to the very top and then they're going to have some obscenely massive amount of tokens.

A

So we want to make sure to check beforehand that the sender has enough tokens before they transfer out foreign.

A

It's going to be a non-payable, so we're actually just going to call it public and it's going to return a Boolean.

A

So first thing we want to do is load the caller's balance right. So what we need to do is Hash. um You know that that information that we did before so, let's say: let's no we're going to m-store one more time, so we're gonna get the mem pointer by loading from memory.

A

From the mem pointer we're going to store the caller's address in this case, we can get that by calling caller, with parentheses.

A

At the next slide, so mempointer Plus ox20 we're going to store the balance slot, which is actually going to be zero.

A

Then we're going to hash and let's say caller balance.

A

So we hash these two starting at mem, pointer with a size of ox40 and we're going to take that hash and use it to load from Storage.

A

So now we want to check and make sure that the caller's balance is at least as big as the amount. Now now that we've done the call data loading, we're actually just going to do this, for the sake of time, we'll say value and receiver just to keep things succinct.

A

So we want to check and say, if less than so, if color balance is less than the value to transfer, we're actually going to do some revert logic.

A

So we're going to take insufficient balance selector now this actually isn't going to take any argument. So all we really need to do is actually just store this one value foreign again at this point: we're reverting we're about to stop execution, so we can basically, just you know, write to uh the zero slot. This can't cause any harm, so M store at zero. The insufficient balance, selector, that's going to be that four byte selector padded to 32 bytes and then we're going to revert and revert actually functions, the same way as the return instruction.

A

So we're going to give it a pointer and a size in memory in this case we're doing the full ox20 I guess we could also just do oxo4, and so that's going to revert with that- and this is good because whenever we revert with the selector client, libraries are going to have access to this ABI. It's going to see that there is. You know this error called insufficient balance and that's the selector, and then we can actually do some. You know better error handling uh on the client side.

A

Sometimes you'll see people revert with zero zero and that actually just reverts with nothing, and obviously this isn't super helpful so as often as possible, even though it does take a long time and it is annoying make sure to store proper error information.

A

Okay, so uh from here we know that the color balance like if we're at this point in the code, we know the color balance is sufficient. So what we'll do is we'll deduct that we'll deduct the value from the caller balance and then we'll add it to the receiver's balance.

B

A

One moment foreign.

A

Just double checking okay, so we add these two together and then we'll say.

A

Let's say receiver balance.

A

Right, oh right, vice versa. Thank you. Sub.

A

Okay, so next we want to get the receiver balance, and so we'll do this in a similar way.

B

A

New color balance. Thank you, sweet, okay, uh so to get the receiver balance, we're gonna do the same thing except uh we're actually going to use the receiver as opposed to the caller.

A

Again, we're not going to need these two slots of memory anymore, so we can actually just overwrite these.

A

A

So the receiver balance is going to be what we load from Storage, which is going to be the hash starting at Min, pointer and of size ox 40.. So this is where we get the receiver balance.

A

A

Let's, do let's do this color balance slots because we're going to need this later. So let's take this and we're basically just going to create a variable with this right same thing,.

A

Great so functionally identical, but now we can actually access uh the slots a little bit later. Whenever we need it.

A

So now we want to get the new receiver balance again, we'll optimize a little bit later. New receiver balance is going to be sub.

B

A

Thank you. There we go okay, so subtraction color balance, add to receiver balance the value okay. So now we have our new balances set up. We've done, um you know the addition subtraction. So now we just need to store these back into storage. So we'll say s store. We need the key in the value. In this case the key is going to be the caller balance slot and the value is going to be new color balance.

A

And same thing, receiver balance slot.

A

New receiver balance.

A

All good cool um yeah, so just as a quick review of what we're doing with this transfer loading loading, the free memory pointer we're going to store at that memory pointer the caller then zero, because that's the slot of the balance mapping we're going to Hash that to get the slot we're going to load from it to get the color balance assert that it actually does have the balance that it needs.

A

If not we're going to revert, then we're going to Inc sorry, decrement or decrease the new caller to the new color balance, then we're going to do the same thing for the receiver. Obviously, we don't need to check for the Overflow we're going to check that a little bit later, um but we can be certain that this is not going to overflow.

A

So we'll increase the receiver balance to give us our new receiver balance and then we'll store that uh in storage here.

A

So last thing we need to do after all of this is we need to return from Return to the caller, a Boolean in this case we're going to return. True, it's the way. We do that again. It doesn't matter now we're at the end of the execution, so we'll store at slot zero ox1, which will be our true value. And if you return.

A

Those 32 bytes.

A

The log yes, the log, thank you.

A

Okay, so we're going to have a transfer event, probably should have hashed this uh as well, but we'll get those hashes in just a moment.

A

um So it's going to be a transfer event, we're going to have an indexed sender, an indexed receiver and an amount great so per the rules that we mentioned earlier we're going to have so this is going to actually be log. Three right, we're going to log the event. Signature event.

A

Hash, then we're going to log the sender as a topic, the receiver as a topic and then the amount, because it's not an indexed topic, we're going to put that in memory and then um basically pass the pointers to that to the log instruction so I'm going to quickly. Oh well, so small.

A

Great um so another place that you can do this if you want to get this stuff online and you might not have um if you might not have cast installed on your local machine, what you can do is go to this online hashing tool and you can basically punch in this stuff. I. Think internet is going to rug me once again, but oh no, there we go cool, so we can just say: transfer.

A

And then same thing right so Ox, DD, F2, etc, etc.

A

All right so we're going to set that as a constant.

A

All right, I'm going to add some comments in here just a moment.

A

B

A

Now, log, okay, so before we do any of the logging remember, we have to store the amount into memory.

A

So in this case again, execution is about to end. So we don't have to be too too careful about where we put things in memory. So let's go ahead and M store at slot zero. The amount I think in this case we called it the value right.

A

So we're storing that in memory and now we want to call log but remember we want to have the two indexed arguments and we want the um event signature. So that's going to be log. 3. first thing we want to pass is the pointer in memory it's going to start at zero. The size is just going to be this one value right. Everything else is going to come from the stack. We just need these 32 bytes at the beginning, then we're going to say, transfer hash.

A

The next topic is going to be the caller and then the final topic is going to be the receiver.

B

A

So at this point, we handle the balances, update the storage log, the event and return.

A

B

Values and the values.

A

The values in the log are only the non-index, so the actual indexed arguments are on the stack and then the um in the non-index are in memory, which also um I believe. This is also in the link tree, the full like yield documentation, basically everything you need to know about this. It's also going to have our log instructions in here right, so log, 0, 1, 2, 3 and 4.

A

B

100 more heaters.

B

Because you are having a new value.

A

So if it's the same, it uses the same slot. It first increases right. No, no! So whatever your Val, whatever the value is at that slot, it will decrease.

A

Then it loads increases. Oh yes, yes, okay, right.

A

Right catch. Thank you.

A

Right yeah, so let's do that as well, so let's just say equals. uh If the caller is equal to the receiver.

A

Subtract store load, add store right, oh yeah, so it evens out.

B

A

B

A

Great um yeah, for the sake of time, we're going to be bad developers and we're just gonna revert with zero zero and we're just not gonna tell anybody about that, all right, all right, great um good catch! Thank you!

A

So after transfer, let's do allowance.

A

No um okay: let's do allowance.

A

Great okay, so um in this case, what we need to do is.

A

All right so we're going to take the owner we're going to map that to a spender which then we map to a number. So the way that this works in storage is we're going to hash.

A

The owner and slot make sure I get this right owner and slot, and then the result of this will hash again.

A

So owner slot hash, then final key.

A

Let's double check the documentation, make sure we get that right.

A

Great, so uh here is the standard function and then nesting that would be.

B

A

Idea wrong order.

A

So the mapping rules are applied, then uh recursively.

A

So we're going to bring that down here, so we can remember.

A

Okay, so first we're going to do the inner hash, so we're going to M store the owner.

A

We're going to m-store the owner at slot zero we're going to M store at the next slot, the slot, which is going to be zero.

A

Inner hash is going to be shot 3 hash of the first two slots and then we're basically going to do the same thing again with the enter hash. Wait.

A

It's not one. Thank you.

A

Okay and then suspender foreign.

A

Slot, then, is going to be the hash of these once again, okay, and so now, what we want to do is load from Storage.

A

And then we want to store this in memory and return that back to the caller.

A

A

A

Here we go okay, so uh we hash together to form the first slot and then we hash again to form the second slot for this mapping. We load from that slide put that in memory and then we return it from memory to the caller.

A

A

So, in the interest of time we're going to copy paste, as all good developers do, okay, so um we're gonna do the same thing. So the hashing figure out the slot and then from here we want to set the value at this slot to the new amount.

A

So s store at allowance slots, the amount.

A

Next thing we want to do before we return is we want to create a log and that's going to be the approve event.

A

Going to have an owner foreign ER and an amount and so functionally this is going to be the same as the transfer. We have two indexed arguments, so it's going to be log three and we'll have to store the amount into memory.

A

A

Is it approve or approval.

A

It's just a proof.

A

It's just a moment.

A

Approval great, so that's going to be approval.

A

Say from here we'll take this hash.

A

Make sure that's hex.

A

Okay, so uh before we log the event again, we want to store the amount and Storage, and then we want to log three we'll start at slot zero. It's going to be of size, Ox 20, because it's just the amount first topic is going to be the approval hash. Next one is going to be the owner in this case. That's going to be our caller and the final one is going to be the spender the person who can spend on their behalf.

A

Okay, now that we've logged the event last thing we want to do is store one which for true, then we want to return that full amount.

B

A

um Right so on the lowest level, a Boolean is actually represented, as um basically a un8 that can only be zero or one, so it just occupies a single byte, but in this case we're returning the uh the ox 20 just returning the full word.

A

Okay, we're gonna do transfer from so this is going to have a sender, a receiver and an amount.

A

All right so we're going to do a very similar thing to the transfer from function we're actually going to just copy paste. Most of this, with an exception.

A

I, don't know if I'm going to be able to do this with this tiny Mouse hold on nice. Okay, no we're just gonna! Do it from scratch!.

A

We'll do it live okay, so we'll load the mem pointer. We want to generate the slot first for the approval. So we'll do the same thing as here.

A

ah Just a moment owner, it's gonna be.

A

Okay, so the owner in this case is going to be the sender and then the spender in this case is going to be the caller right. So basically, we want to check um what we're trying to load here. What we're trying to see is the Spenders permissions on behalf of the sender.

A

We'll call that caller allowance.

A

Foreign we're going to load from that slot, and so basically we want to do the same thing. We want to check and make sure that color allowance is not less than the amount right, so if it is less than then we're going to revert in this case, we're going to be storing the insufficient allowance error so notice. This is going to take two arguments. That's going to be the owner and the Spender foreign.

A

Since we're going to be storing a bit more information here, even though it is going to end execution again, formalities, mem pointer, so we're going to store the insufficient allowance selector. So that's going to be the first four bytes now remember: it's only four bytes in memory that we're occupying here. We actually want to write after this, the next 32 bytes.

A

So instead of adding a full Ox 20 we're actually just going to add ox04 right. So it's going to be the four bytes, then the next 32 bytes and then the next 32 bytes after that, so storing it. This slot, it's going to be.

A

The owner, in this case that's going to be the spin or the the sender and then the next one is going to be.

A

In a second thank you, so the next one is going to be the actual caller, so notice we're still increasing by Ox 20 at this point, but because it is at an offset of four first slot is going to be the mem pointer. The next one is going to be mem, pointer, plus four, and then the next one is going to be the mem pointer, plus four plus 32.

A

And so this is our entire Chunk in memory where the error is so we're going to revert starting at the Min pointer and then it's going to be Ox, let's see 4 24 and then 44. so ox44, and so that's going to yeah, basically assert that they actually have the allowance uh to spend there.

A

So now that we've done that, let's go ahead and.

A

B

A

Great uh so next thing we want to do is we want to get the balance slot from the sender foreign.

A

Balance. Thank you.

B

A

B

A

Okay, so uh doing the same thing oh God hold on this compiler is being obnoxious, we're just gonna do this. This is not actually important. I'm actually just doing this, so the compiler doesn't give us all this yellow text everywhere. We're gonna get rid of that in a moment.

A

Okay, uh so we're going to load the uh the sender's balance.

A

um Basically, again, we're storing the sender, storing the actual pointer and memory where this are pointer and storage, where this is going to come from uh we're going to Hash that to get the slot from the slot we load the balance.

A

Then we want to assert that it is at least that amount otherwise will revert with insufficient balance. Foreign store at the sender balance slot the sum of Cinder balance and amount.

A

Great next we'll do the receiver. So basically the same thing.

A

A

And then we will store.

A

A

A

Thing as before, basically once we pass this approval check, we're going to check the balances, make sure that it's all good send all this stuff through last thing we want to do before we return is we want to do the log so again M store at zero? The amounts log common three, it's going to start at slot zero offset of ox 20.

A

transfer hash is going to be. The first second is going to be the sender, and the final is going to be the receiver.

A

Oh and one last thing before we do this before you return as we want to make sure we decrease the allowance. If it is not the max, you went 256 value.

A

So if it is less than we're, checking.

A

I'm not sure of a good way to get this max value in assembly. A second.

A

No we're gonna have to log that or something.

A

A

Alex sorry right, yeah I didn't want to have to do it that way, but it looks like I'm gonna have to uh you could underflow, um which that is one thing that works, but also that does add, like that. That is computation um at runtime.

A

Best way, all right uh and the reason that we actually can't just use um so normally you could do something like type un256.max, but this actually is disallowed and assembly, because this is, you know, a higher level um higher level functionality. So we'll just do that.

A

All right, so if the caller allowance is less than this enormous value, what we want to do, then, is decrease the caller allowance and we'll store that back in the allowance slot.

A

And again, since we already checked to make sure that they have sufficient allowance, this should never underflow.

A

Okay, then, finally, we're going to store true.

A

And then we're going to return it.

B

A

That what is the um right so so there's a common pattern. It's not part of the standard, but this is something that uh seeing increasingly basically um to give like an infinite approval. uh You could just set it to the max. You went to 56 value and so, instead of actually having to do like math on that right, we can just check them uh right. So, if less than then we s store, so that's all good. All right!

A

So just reviewing this one, Function One Last Time we're going to generate the allowance slot check the allowance make sure it's sufficient. If not, we revert if it's less than the max value, we're actually going to decrease the color allowance.

A

Next, we want to make sure the sender balance is sufficient.

A

If not, we revert, then we want to subtract from the sender balance this amount. Then we want to add to the receiver balance this amount. Then, finally, we're going to log and then return true.

A

Two leaders, 165.

A

uh Right so so this is uh to generate the hash, so we're storing at slot zero descender.

A

And he said the other was 205.

A

A

um Yeah same thing right so at the memory pointer and then at the memory pointer, plus ox 20. right.

A

Okay, so we have transfer from we have approve, we have allowance, we have transfer balance of total Supply.

A

And again, we're just going to keep this internal just so we can. You know, for the sake of the exercise, write this out now. Of course, all of this that we're doing here is like very much over abusing assembly and in general, you don't want to use it this much. This is just to give like a good picture as to like, what's actually happening under the hood here.

A

So total Supply, it's going to get public view, function.

A

Okay, now this one's actually going to be really easy. Basically, what we want to do is store the value at this slot. Now this is slot number three or slot ox02. This is Oxo Alexa, one oxo2.

A

So we can M store at slot zero, the value that is loaded from Ox O2, then, from there we're turned Oxo ox 20.

A

I meant right, so I was actually going to do that in the Constructor. um But if we want to do a Min function we could I don't know. Actually are we short on time.

A

Right yeah, so it's always zero best token uh was there another question.

A

A

Hash three slots at the same: oh right. So if you want to Hash three slots, then you the first argument would be where in memory it is and then you would just say ox60.

A

It says three slots uh in this case we're only over hashing two, that's just per the solidity standard, uh but you could hash bigger stuff.

A

Foreign, not quite so, the the reason that uh we did the like separate hashing here is because um the second time we hash we're actually um concatenating the caller and the first hash like digest. So it has to be two different hashes.

A

All right so in our Constructor we will once again abuse assembly. uh So basically, what we'll do here is we'll just do a static total supply for the sake of Simplicity, we're going to store.

A

Into the caller slot the initial Supply, so first thing we want to do M store.

A

A

Next is going to be the slot for balances.

A

B

We're going to s store at.

A

The slots total Supply. What do we want to call this Max yeah I, like it cool all right, so we'll do that um now, since this is kind of technically a transfer from zero address, we'll go ahead and log an event for this as well. So uh mounts we're going to store into memory.

A

And then from there we're going to call log three transfer hash. No, no! No! No! No log, three memory pointer, it's gonna be zero memory size. It's going to be Ox, 20 to store that value, transfer, hash.

A

Zero address, we can just say zero here, then receiver.

A

And all three topics perfect.

A

Now from here, we're not going to return because in the Constructor of a contract, the way that, like a contract is actually deployed to the chain, is we take the entire contracts byte code and then some and basically, what we're doing is returning the entire contracts byte code like we're, putting the whole byte code in memory and then calling return on that? That's how the actual deployment process works and part of the reason why deployments go get so obscenely expensive because memory gas costs expand gas expansion, um sorry memory, expansion, gas cost scale quadratically.

A

So it gets very, very expensive. But the reason that I bring this up is we're not going to call return here, because a Constructor needs to do its job and return the bytecode at the end of this constructor's execution.

A

So everything compiles.

A

Moment of Truth whoops hold on.

A

All right, so, first, let's check decimals should be 18. name should be yield token symbol should be Yule total Supply. We did not increase the total Supply.

A

So s store that's going to be slot oxo2 and it's going to be Max un256 great good coin. Great tokenomics.

A

All right total Supply. Now it's this enormous number and let's do a quick transfer now we're just going to transfer to some random addresses. Here's.

A

I don't know first, let's call balance of on this address, just for the sake of seeing what's what it's a balance of. This should be the deployer's address foreign.

A

A

A

Ah That's it: okay. Okay, there we go one more try.

A

So balance of here our enormous number and then finally we'll just make a quick transfer here for let's say 10., because we're stingy.

A

And then we call and the balance is now 10 and that's an erc20 token written purely in yule, and that concludes today's Workshop.

A

So um really quick. uh These are some other resources uh that you guys can check out: educational resources, evm codes, obviously the yellow paper, if you're the generator and you're into that kind of thing: uh developer, tooling and languages. Huff language is basically a low level Assembly Language that will teach you a lot about the evm The Foundry development, environment, really good for testing and trying things and the remix browser IDE for that local testing in the browser.

A

Add liquidity or swap so that's not possible now um right, because all it has access to is like the message sender right um now. Maybe.

B

A

Right uh any other questions.

A

A

Right so some things are trivial, but some things you can actually like very heavily optimize, and that's that's actually why a lot of people tend to use assembly like, for example, take ABI dot encode. So this is actually like fairly gas intensive, especially like let's say you want to Loop a number of external calls. It's actually ABI encoding every time right and there's like a lot of gas, it's being consumed there, whereas, like maybe you're, calling the same function over this entire Loop. Instead, maybe what you could do in assembly? Is you run that Loop?

A

But let's say instead of you know doing this encoding the entire time every single time you just store it once, and you kind of like cache that right and so things like that will actually give you massive improvements and gas efficiency. Okay, so.

B

The company always.

A

Right, it is improving so a little bit about the state of the solidity compiler. Originally solidity used it's basically its own uh pipeline, so it would go from. You know, solidity to intermediate representation to byte code now, there's actually a migration happening where basically solidity will compile to Yule, and then we can actually use Yules pipeline to optimize, because the Yule Optimizer is very well developed. This was actually sort of the original reason of using Yule. Is that, like many high-level languages could compile to Yule and have the same?

A

You know basically intermediate representation where everybody can take advantage of the same Optimizer welcome.