🏌️♀️⛽️Ok EVM gas golfers, got one that is going to test your every gas instinct.
NONE of these functions are optimal... but which one is the most gas efficient and why?
Pick a choice and also leave a comment on why you think so!
❌❌ NO LOOKING ANYTHING UP! ❌❌
a, b, or c?
The answer is C
Each does something a little different gas wise:
- External vs Public functions
- +=
- The location of the function in the file
But the biggest gas factor here is going to be BOTH reading and writing to storage.
The Chainlink core github repo runs with the standard or adding the prefix "s_" to any storage variable, so engineers know it's expensive to use.
In function C, we load the s_playerFunds into memory and read from memory as we loop through the array.
Whereas in a and b, we read right from storage, which is one of the most expensive operations out there!
We also initialize a totalFunds value in memory, instead of constantly writing to s_totalFunds.
a got that part right, but b just wrote to storage for every call.
Long story short:
Reading and writing to storage is expensive! If you have a large array in storage you want to do a lot of reads and writes on, pop it into memory first and go from there!
Here is what that looks like in our function C
playerFunds and totalFunds both get "wiped" after the function finishes, but s_totalFunds and s_playerFunds stays. You can access s_totalFunds & s_playerFunds even after the function finishes, but not playerFunds & totalFunds
And that's the difference between storage vs memory!
Shoot me a like, retweet, and follow if you learned something!
EDIT: It should be noted, that reading an array in from storage calls SLOAD on every element. But we still get the gas efficiency in C > B because we are calling playerFunds.length instead of s_playerFunds.length
• • •
Missing some Tweet in this thread? You can try to
force a refresh
🤥 4. "Cheat Codes" are an intuitive way to modify state of contracts you don't own, modify blockchain values, and more "magic" so you can test for any occasion.
Trivia: Proxies are often used for upgradeable smart contracts. They use delegatecall to call functions of a contract that has the logic they want, but store data in themselves.
Continuing the theme from my last trivia, why is this a bad proxy contract?
So there were two issues here:
1. setImplementation is public, meaning anyone can update this proxy!
2. The proxy uses a storage slot to hold the implementation address. If the implementation has storage, you’ll get hilariously rekt by storage collisions.
📀A proxy contract stores data in the proxy contract based on the implementation.
This means, if your implementation stores data, it might overwrite where we saved the implementation address!
You might think this is an easy step to skip, but if you don't have an unbreakable, bulletproof reason to become a blockchain engineer when it gets hard, you might back off. 💪
So create your list of unwaivering, unfaltering justification to begin your journey
3/
You can borrow some reasons from my past article, or use some of these:
🌎 Create an impact on the world that will last forever
💨 Create a faster, digitally immersive, world
💸 Relandscape the future of finance
(continue)
#Blockchain allows us to do amazing things, the easiest value add to understand is smart contracts.
In my CS class back in 2013 my professor taught us about #Bitcoin and I literally went “that sounds stupid”.
2/ Why does it have value? I also never thought gold made any sense either. Now my point of view has changed on Bitcoin and I think it has its place as a store of value.
However, I thought blockchain didn’t do much aside from a digital gold.
3/ I didn’t understand why people were so hyped.
Fast forward to a couple years working at a hedge fund. I get to see aaalllllll the shit of the current financial world. I got to do something called “trade matching” as part of my jobs.