Published
5 years ago on
August 17, 2018
“Gas is a unit of cost for a particular operation a computer needs to execute, and it executes this instruction when we broadcast a transaction which contains an Ethereum program in order to run a dapp. For example, summing two numbers costs 3 gas. Multiplying them costs 5 gas. Storing a 256bit word into the blockchain costs 20000 gas, which means storing 1kb of data costs 640000 gas.”It’s a little more complex than this, but I think this definition covers it, if you are interested in learning more, you can see the full article by Bitfalls, here. So, why is saving gas important?Like ‘in real life’ reducing gas consumption can save money, something that is pretty vital when building applications for a financial network. There are many ways developers can save gas, most of these ways just require a bit of extra thinking when working on the code for DApps and therefore, saving gas is an activity that should be practiced by anyone who is involved in the development of DApps. The following guide is an extract from an article on Audithor.io, written by Bruno Škvorc, the owner of Bitfalls.com. You can see the full article for yourself, here. According to Škvorc:
“When we perform audits, we also include gas optimization techniques that can make your deployment and usage of the smart contract cheaper long term. This doesn’t matter much in ICOs where the contract is only used that one time, but can matter a whole lot in long-running dapps, contracts that are run repeatedly and maybe by different contracts, and in decentralized exchanges.”So, how do we do it?First of all, the removal of extra code. By removing un-required functions, the code will run more efficiently and therefore will use up less gas in the process, this includes the removal of unnecessary third party code too.Next, avoid loops. Naturally, loops within the code will cause functions to repeat, which in turn will use up more gas. Of course, Škvorc understands that sometimes loops are an essential part of the development of a DApp so often cannot be avoided, though in this instance a more efficient method would be ensuring that your loops aren't unbounded:
“Try to avoid unbounded loops, i.e. loops which you do not know the upper limit of iterations for. If the program doesn’t know how many loops a loop is likely to do, then it cannot estimate the gas cost when running a function and it cannot provide good usability for users. Worse than that, an unbounded loop can run out of gas: if you have thousands of users you want to do an operation on, your function might run out of gas before it can complete everything and that means all the changes will be reverted. You’ll lose gas and gain nothing.”Škvorc also points out a little hack that can be carried out by developers when gas costs are riding pretty low. By deploying heavy and expensive ‘test’ contracts on the blockchain and then destroying them before they use up their allocated gas, developers are given access to gas refund tokens that can be used in future deployments when gas prices are a little higher. In essence, you are given gas at a better price, at the expensive of running a test contract first:
“When an expensive contract is deployed, it takes up a lot of space on the blockchain. Freeing it up by destroying it generates a gas refund, but not in the way of giving you actual gas or ether, but in generating a discount for your next deployment.”There are of course many other optimisation techniques that are a hell of a lot more technical, if you’re interested i’d recommend reading the full article by Škvorc as it is suitable for those with little knowledge about gas and development too. If you’re au fait with the technology and pleased that we’ve pointed out some of these tricks to you, thanks us later. Investment Disclaimer
