Hey dear Patrick, is there an available formatter plugin on VsCcode for huff? Feeling kind of inconvenient directly writing huff... Though I can manage it by adding spaces manually, but still it could be a lot better with a plugin (huff plugin & prettier won't work when chosen as default formatter)
Bro... I don't know what to say except... you're a treasure for Humanity. Seriously. Given the importance that crypto development is gonna reach with all the A.I. b*lls**t, the fact that you are doing so much to help people write reliable and efficient code... you already deserve AT LEAST some mentions in future history books. Thank you ❤
Completing this video could be exhausting because of the low-level stuff. But trust me, it's worth watching this video more than 10 times. After struggling with these vague opcodes for two years, I now have a better perspective of what the hell is happening behind the scenes.
Putting my bare hands into the gears of this EVM engine, I feel like a Rolex watchmaker or a Ferrari mechanic. What you're teaching us is Swiss precision watchmaking. thx a mil ! 🏎
Ohhh my gosh...was in the process of replicating the hardhat FundMe project in huff and here it is...the goat has launched it....This is a boost....BASED!
Well done with this excerpt of the course @PatricAlphaC I really enjoyed it. Quick question how can we identify the value type of each of the values used within the opcodes? For instance how do we know the number of horses updated is in fact a uint256 ? And also if there are multiple inputs to a function (address and amount) how do we identify these?
In bytecode, you don’t! When someone sends a “uint256” it’s just the hex of the uint256. So as far as the opcodes are concerned, it takes a bool, uint256, bytes32 whatever! This is where a compiler helps, since the compiler will not compile if types don’t match. But the opcodes don’t care, they just look at what the raw call data is.
If there are multiple parameters, you’d just see a second bytes32 object in the call data. Your call data would look like this: First 4 bytes: function selector Next 32 bytes: parameter 1 Next 32 bytes: parameter 2 For a total of 4+32+32 =68 bytes of call data
would building logic to convert each input into a type (uint256, bool, bytes32, etc.) and then matching that to a matrix (as a first step) to identify types that make sense (example perform a checksum test on a value to confirm if it is a checksum address) allow for the initial automation of assigning types to these values? @@PatrickAlphaC
I forgot some hex now I dusted it off for people like me, remember every hex value weighs 4 bits because every hexadecimal value can be represented in 4 bits that's why remove the 2 on 0x0102 because it weighs 4 bits try to put another hex value like A you'll see always returns 10
Amazing course! But still, I didn't get one thing. When I've compiled huff file with CONSTRUCTOR, the arguments has been added in the end of the runtime bytecode. Is it some default behavior?
hey patrick,i was see your foundry course and still watching security course, actually i have a question. I am almost familiar with solidity and smart contracts(foundry framework) and the same with security issues but now I am confused, what exactly should I do? for next step to become a security researcher? to find bug's? Contest? Reading writeups? or what?
So its essentially the same thing but with less bytecode at the end.@@PatrickAlphaC In your "selector" function you divide the word by 2^224, which leaves you with the selector. But in your version of the code, you hardcode 2^224. Instead you coud just hardcode 224 to bitshift. So like this, the code should compile with less bytecode: s := shr(0xe0, calldataload(0)) This works because x >> y = x/2^y Also on that note, you can calculate 2^224 in wolframAlpha or wherever and cast it to hex, to get your magic value to confirm. I used docker to run solc 8.20. Lastly to compile yul must add the --strict-assembly /path/... flag. Compare the final bytecode.
@@navibongo9354 Ah took me a second to recognize what you were talking about, sorry! Yeah, in retrospect, I should have done it more similar to the way I did the huff, which is what most compilers do, but a lot of the yul documentation did it like that, so I wanted to more closely resemble the docs. But yeah, good point!
The full course gonna be insane
(This will be the new part 2 of the security course)
Also I say “binary” instead of “opcodes” like 5 times - sorry
I'll be there no matter what!
Waooo it is going to be the absolut mega course ever 💣💥💥💯 🥳🥳🥳
Hey dear Patrick, is there an available formatter plugin on VsCcode for huff? Feeling kind of inconvenient directly writing huff... Though I can manage it by adding spaces manually, but still it could be a lot better with a plugin (huff plugin & prettier won't work when chosen as default formatter)
@@superggn4754 there is! Someone made a new one… I forget where tho tbh…
@@PatrickAlphaC so it's a new plugin... Huge thanks! I'll try looking for it, if I got it I'll put it here
Bro...
I don't know what to say except... you're a treasure for Humanity.
Seriously.
Given the importance that crypto development is gonna reach with all the A.I. b*lls**t, the fact that you are doing so much to help people write reliable and efficient code... you already deserve AT LEAST some mentions in future history books.
Thank you ❤
I legit spent the last 48 hours trying to figure this exact thing!
I’m here for you!
HOLD ME @@PatrickAlphaC
I'm a simple developer. I see new Patrick upload I click and I like before watching💯
Completing this video could be exhausting because of the low-level stuff.
But trust me, it's worth watching this video more than 10 times.
After struggling with these vague opcodes for two years, I now have a better perspective of what the hell is happening behind the scenes.
Putting my bare hands into the gears of this EVM engine, I feel like a Rolex watchmaker or a Ferrari mechanic. What you're teaching us is Swiss precision watchmaking. thx a mil ! 🏎
Learning and becoming better each day in Web3 Security by Patrick Collins sir 🔥🔥
Ohhh my gosh...was in the process of replicating the hardhat FundMe project in huff and here it is...the goat has launched it....This is a boost....BASED!
The fact all of this is for free in this economy says a lot.. thanks Patrick
I can't wait to see how long the full course is going to be.... hopfully challenging as the motivation is very hiiiigh now 😎
Bro puts out more content than Disney+ 🤯
Another incredible course by the one and only Web3 guru himself!
I was a EVM muggle before this course, thank you so much.
Thanks for your service to humanity
woohooooo! finally we are getting tutorial of my favorite in solidity the inline assembly !!
I love you Patrick ❤ seriously you are the best
Thank you so so much Patrick!! 👍👍🙏🤗
thank you for providing quality content
Bro is a legit legend !
He is back! with another banger!!!!!!!!!!
Omg this is soooo cool patrick youre the best!!! 😍
Hell yes it is
This is why we call you legend
Anytime fren
WE OPTIMIZING FOR GAS WITH THIS ONE🗣🗣🔥🔥🔥🔥
You damn right
Patrick strikes again!🔥
My bro is one🔥
LFG ! legend
Now we just need to get a collab with something like GOTO or NDC Conferences..
Oh and BlackHat
172nd...Thanks Patrick. You are the best !!!
back with a bang
What the hell is it, crazy super video, lets learn
Well done with this excerpt of the course @PatricAlphaC I really enjoyed it. Quick question how can we identify the value type of each of the values used within the opcodes? For instance how do we know the number of horses updated is in fact a uint256 ? And also if there are multiple inputs to a function (address and amount) how do we identify these?
In bytecode, you don’t! When someone sends a “uint256” it’s just the hex of the uint256. So as far as the opcodes are concerned, it takes a bool, uint256, bytes32 whatever!
This is where a compiler helps, since the compiler will not compile if types don’t match. But the opcodes don’t care, they just look at what the raw call data is.
If there are multiple parameters, you’d just see a second bytes32 object in the call data. Your call data would look like this:
First 4 bytes: function selector
Next 32 bytes: parameter 1
Next 32 bytes: parameter 2
For a total of 4+32+32 =68 bytes of call data
would building logic to convert each input into a type (uint256, bool, bytes32, etc.) and then matching that to a matrix (as a first step) to identify types that make sense (example perform a checksum test on a value to confirm if it is a checksum address) allow for the initial automation of assigning types to these values? @@PatrickAlphaC
@@danielbotha8994 you could, but honestly the extra gas wouldn’t be worth it IMO
this is amazing can you do something on account abstraction
we need more inline assembly!!!
MOAR
I forgot some hex now I dusted it off for people like me, remember every hex value weighs 4 bits because every hexadecimal value can be represented in 4 bits that's why remove the 2 on 0x0102 because it weighs 4 bits try to put another hex value like A you'll see always returns 10
Amazing course! But still, I didn't get one thing. When I've compiled huff file with CONSTRUCTOR, the arguments has been added in the end of the runtime bytecode. Is it some default behavior?
Correct! This is often how arguments are added to EVM code! Solidity does the same thing as huff. Yes this is default.
hey patrick,i was see your foundry course and still watching security course, actually i have a question. I am almost familiar with solidity and smart contracts(foundry framework) and the same with security issues but now I am confused, what exactly should I do? for next step to become a security researcher? to find bug's? Contest? Reading writeups? or what?
If you watch the security course, we tell you your next step 100% is CodeHawks. Go compete!
Wow
one item to be added to must-do list, c'mon Patrick, i haven't finished foundry course yet 😂
Ahah - keep up your pace, and you’ll catch up soon!
Haha. I'm on the same page too. Yet to finish foundry and advanced foundry. Patrick's a blockchain wizard. sweet jesus..
@@toppojaiwant the course is like a drug, i'm so addicted lol
Whether the program counter and jump destination are same Patrick
Sort of. The program counter must match the jump dest - huff does that for us
17 ❤❤❤❤❤❤❤❤❤
In all bug bounty gas optimization is informational,so no bounty 😢
But if you’re a dev, gas bad
Your Yul code is super weird. Why divide by 2^224? Bitshiting by 224 is cleaner in my opinion and produces less bytecode.
Which function?
So its essentially the same thing but with less bytecode at the end.@@PatrickAlphaC
In your "selector" function you divide the word by 2^224, which leaves you with the selector. But in your version of the code, you hardcode 2^224.
Instead you coud just hardcode 224 to bitshift. So like this, the code should compile with less bytecode:
s := shr(0xe0, calldataload(0))
This works because x >> y = x/2^y
Also on that note, you can calculate 2^224 in wolframAlpha or wherever and cast it to hex, to get your magic value to confirm.
I used docker to run solc 8.20. Lastly to compile yul must add the --strict-assembly /path/... flag. Compare the final bytecode.
@@navibongo9354 Ah took me a second to recognize what you were talking about, sorry!
Yeah, in retrospect, I should have done it more similar to the way I did the huff, which is what most compilers do, but a lot of the yul documentation did it like that, so I wanted to more closely resemble the docs.
But yeah, good point!
LFG
wtf, he has beard now
Sometimes lol
pls add subtitles
They take a few days to populate
😅 *promosm*
The 🐐 strikes once again! Thanks ser! 🫡
aah shit here we go again🚀🫡