EVM: From Solidity to byte code, memory and storage
Вставка
- Опубліковано 9 чер 2020
- Slides are here: drive.google.com/file/d/1HkpC...
Peter Robinson and David Hyland-Wood described how Solidity code is compiled, deployed, and executes in the Ethereum Virtual Machine. The talk covers EVM opcodes and how code in the EVM uses the various data locations:
Stack: EVM Opcodes pop information from and push data onto the stack.
CallData: Transaction parameters.
Memory: Temporary data store within a transaction.
Storage: Persistent storage that is part of world state.
Code: Stores code and static data such as strings.
Logs: Write-only event log output. - Розваги
This is such an amazing talk. Very much appreciate the amount of work that has gone into the slides and the content. I have a much deeper understanding of the EVM thanks to these 1.5 hours. Thank you Peter, David and team.
This presentation is straight 🔥 Good stuff!
Been trying to dig UA-cam for ages for a more in-depth talk on the mechanics of the EVM.
Just wow - this is incredible. Thank you so much. Hope to help on the education side soon :)
An amazing talk about EVM!
This is pure gold. Thank you so much ! (all i need to move on level 18 on Ethernaut)
This is a goldmine, thank you for this amazing presentation.
This is an amazing presentation. The level of detail is top notch. Keep up the good work!
Awesome video! Thanks for the lecture, very interesting to learn about it
Amazing talk! Congrats and the great content and its delivery. Thanks for sharing it with us.
🙏🏻
Huge thanks for your hard work sir. I really appreciate it 🎉
this channel is a hidden gem
So much win! This is demystifying the deep CS underbelly of Ethereum. Thank you for creating this content!
Impressive talk!!! Thank you for sharing.
Really solid deep dive. Thanks.
Very detailed videdo. Also good for knowing how VM works inside in general.
no such thing as interestx or etc or not
Really solidity deep study. Thanks.
thanks for the detailed explanation !! =] really want to learn more from you !
may I ask a question ?
@42:48, why does it have to revert if "CALLDATASIZE - 4" is less than 32 bytes ?
Definetely would like to have the new version but more visualized explanation for OP_Code again!! Still can't understand very well.
Thank you sir!
Amazing video, thank you. Cordiale.
thanks for sharing!
Wonder if they ever got to coding the array index underflow
Nice explanation. At 20:10 we have the byteCode of runtime. The deploy transaction stores only Init Code fragment (i.e. Contructor). At 27:53 we are doing a code copy (from where it is). My question is, where is the Code ? From where the code is fed to EVM since the transaction does not include the byteCode of runtime ? Meaning, do we send the actual byteCode separately alongside the deploy transaction to a Node ?
Also at 30:49, the code (runtime) is copied into the blockchain. Is it copied into the Merkle Praticia tree storage of that deploying account address ? Increasing the deployers nonce
The deployment transaction's data includes the byte code of the init code and the run time Solidity code. That is, have a look at the output of solc --bin SomeContract.sol . Those bytes of data for a deploy transaction are treated as code. The codecopy copies the code that is after the init code from where code is executing to memory. A reference to that location in memory is then returned, indicating the code that should be deployed.
Hi Peter, Thank you for contributing such a valuable video about the Ethereum EVM. I'm interested in the State and the Patricia Trie I would appreciate it if you could share with me the video that you mentioned in this video. Many thanks
I think that is going to be one of the videos on Stateless. Have a look at the channel, look at the Videos tab, and then go to the video that was just before this one.
@18:11 it's mentioned that, val2 = 3; will set "val2" as a state variable. Is that also not the case with val1, it's declared but assigned, however, doesn't that still make it a state variable?
Thank you for this amazing video.
@naz val1 is also a state variable. It will have its default value, which for uint256 is 0. However, what I was meaning was that in the constructor, all initial values of state variables are set-up.
42:36
Isn't the revert condition specified by assembly revert if (CALLDATASIZE - 4) = CALLDATASIZE - 4
The ISZERO returns 1 if 0x20 >= CALLDATASIZE - 4, 1 if 0x20 < CALLDATASIZE - 4
So it reverts if CALLDATASIZE - 4
Great talk! Let me point out a small correction though, at 30:53 the second argument of return, i.e., stack[1], is the length of the data and not the ending address
Correct. At some point, I should re-do the talk with many small / minor corrections.
The slide at 57:27 was confusing to me, because I was looking for 0x14, which is what gets assigned to valAddress in the code. Then I realized that 0x05 is 0x14 shifted right 2 bits. So the solidity compiler internally shifts 0x14 right 2 bits, putting 0x05 in the code, then outputs a shift left by 98 bits. Why does it do this? Well, I guess if it had to store 0x100, it could shift that to the right 8 bits, and put 0x01 in the code. So its output would be 1 byte less. Talk about microoptimization! So it doesn't really need to do it for 0x14 but it does anyways to simplify the code of the compiler.
Which brings to mind the next question, why does it PUSH5 0x13000000000? Why doesn't it PUSH1 0x13 and SHL by 32 bits? The mind boggles.
@27:09
Storage[1] = 3
Stack[0] is location to write to
stack[1] is the value to write
but in my mind its like
PUSH1 0x03 -> stack[0] = 03
PUSH1 0x01 -> stack[0] = 03, stack[1] = 01
SSTORE -> stack[0] is location (3) and stack[1] is value (1)
what am i missing?
stack[0] is the top of the stack. Hence, PUSH1 3: stack[0] = 3, PUSH1 5: stack[0] = 5, stack[1] = 3, and then PUSH1 7: stack[0] = 7, stack[1] = 5, and stack[2] = 3
@ 13:00 does anyone have the link to the video on Merkle Patricia Trie's?
ua-cam.com/video/mAplDMnUct8/v-deo.html
what happens to storage data that is persistent and then a revert happens, does it stay there? what about subsequent runs of the contract, does storage stay there for every run of the contract and does it use up the storage.
I have a million questions that are simple questions but are not addressed in the documentation and I am trying to piece together the functionality of progrmming in solidity. Sorry to be a downer thanks for all you help and comprising this too low drill down about stack storage and memory and call data
If there is a revert, storage is reverted to. It is as if the transaction didn't happen (except for the gas charges)
Storage is persistent across transaction executions
@@EthereumEngineeringGroup So previous slots used up are going to stay there and new transactions require new slot storage? thank you for your replies
Where can I find the community? Nice sharing thanks.
Join the meet-up group: www.meetup.com/ethereum-engineering/
I am 2 years late.. yet learning soo much!
This is really great talk! it helps me to get clear of the evm. BTW. could you help update the slide link, it is unavailable now. Thanks!
Link updated.
18:19 solc compile command
13:50 - Why State Root is 160 bits, and Account Storage Root is 256 bits numbers?
Storage slots are in a 256 bit range. Account addresses are 160 bits.
@@EthereumEngineeringGroup got it!
53:57 - where is 0x37?
0x36 is a PUSH1 instruction. It pushes the next byte from code onto the stack. As such, the 0x3d value is what is as location 0x37.
Any tools for AndroidOS?
Web3J is a Java library for interacting with Ethereum nodes.
@@EthereumEngineeringGroup All the insalls are CLI prompts (Windows).
Any solidity editors for Android?
I have a wireless keyboard.
At 1:04 my dog also bark who is there in laptop Screen 😄
Kannada
chi chi ikkada kuda entra