Simple Refactoring with Solidity

Stork & Crow BV
Coinmonks
3 min readSep 28, 2018

--

Image Source

The classic movie line goes something like “I love the smell of refactoring in the morning” right? That’s how I remember it.

I was looking into a customer’s code base recently and although my task was simply to assure the code worked as intended, I couldn’t stop but think that a little refactoring would go a long way here to make the code more concise, cheaper to run and easier to read.

Below is a (very) sanitized version of the initial code.

The first thing that called my attention was the use of the now deprecated syntax for the constructor function. In Solidity, the constructor function of a contract used to be defined by having the exact same name as the contract itself. That is, if the contract was called “Voting”, then a function named “Voting” would be understood to be its constructor, a special function that is only run once, at deployment time, but a function named “voting” (small caps) would be a normal, universally accessible, function. This syntactic construct was the source of a number of costly mistakes with deployed contracts left un-initialised and sensitive “admin” functions left open for any devops199 out there… Now we use a function named “constructor”, it’s harder to miss.

Next it was the data structures. Storing an array with the addresses of all valid candidates on-chain can be expensive. I mean, the ideal cost is a function of the utility of having the data accessible for the contract to manipulate, so we need to see what does the contract do with it before making a judgement. Here, it was used for input sanitation with the use of the “isValidCandidate” function and the “require” keyword. Yikes, thats definitely expensive.

Writing smart-contracts is closer to developing for embedded devices than it is to web development because every computation is calculated and costed appropriately via the “gas” mechanism. This makes loops and excessive writing and reading from state ill advised because even a call to a read-only “view” function will cost an amount of Ether if invoked from a different smart-contract, which is good because that way a bad developer will cost way more than a good one :-)

Knowing that Solidity gives us free getter functions for data types identified as “public”, the “totalVotesFor” and the “isValidCandidate” functions are duplicating functionality already available by simply calling “candidates[_candidateAddr].votes” and “candidates[_candidateAddr].isValid” respectively, so I decided to remove them.

Running a simple test with 5 candidate addresses showed some good progress in terms gas costs. Deployment now costs ~205k gas, down from ~330k and the “voteForCandidate” function requires only ~6k gas, down from ~21k in the original code.

It’s possible to reduce gas on deployment by keeping the votes as uint256 (Ethereum uses 32-byte words) but the vote function balloons to ~20k gas and, honestly, I don’t think anyone will ever need more than 9223372036854775807 votes. :-)

Get Best Software Deals Directly In Your Inbox

--

--