MENU

Practical Solidity Experiment #20

Do you need to zero-initialize every element when you allocate a new memory array in Solidity? They are saying all differently. YES – The memory may or may not be zeroed out. Because of this, one should not expect the free memory to point to zeroed out memory. NO – As all variables in Solidity, the elements of newly allocated arrays are always initialized with the default value. These two answers are written on Solidity official doc. Much confused! And as always, I decided to make an experiment to give myself a clear answer. It passes without an exception.As you see, it’s redundant to initialize the newly created array. – Tonyhttps://github.com/maAPPsDEV
Read More ›

Gatekeeper 2

When I first saw the modifier in the picture below, I was in despair.“Ethereum is not something I can do.”If you know how to solve this problem, you are already an expert. I was able to solve this problem only after reading the Ethereum yellow paper.By solving this problem, you will learn about the contract creation process in Ethereum. Sometimes even gates that appear to be highly secure can be passed with the right tools. I share my second “Gatekeeper” game solution. https://github.com/maAPPsDEV/gatekeeper-attack-two
Read More ›

Gatekeeper 1

Function modifier is a good gatekeeper that can protect your function from unexpected behavior.But you should know a few things about function modifiers. Function modifiers can be inefficient.When you add a function modifier, the code of that function is picked up and put in the function modifier in place of the _ symbol. This can also be understood as ‘The function modifiers are inlined”. In normal programming languages, inlining small code is more efficient without any real drawback but Solidity is no ordinary language. In Solidity, the maximum size of a contract is restricted to 24 KB by EIP 170. If the same code is inlined multiple times, it adds up in size and that size limit can be hit easily. Internal functions, on the other hand, are not inlined but called as separate functions. This means they are very slightly more expensive in run time but save a lot of redundant bytecode in deployment. Internal functions can also help avoid the dreaded “Stack too deep Error” as variables created in an internal function don’t share the same restricted stack with the original function, but the variables created in modifiers share the same stack limit. I managed to reduce the […]
Read More ›