Solidity (Smart Contract Development) is Very Hard

I’ve once asked in a conference: “If you can find a JavaScript developer for $30/h and a financial software developer for $150/h, how much should I expect to spend on a smart contract developer?” The speaker answered: “$200″. I perfectly agree. Solidity looks deceptively simple, but it’s much much harder than it looks. I know it looks novice-friendly. I know it looks like JavaScript. However, it’s neither. Here’s why.

Your JavaScript runs on a server or a browser. It modifies mutable data-structures. If you screw-up something, you can go back and repair those records or restore from backup. You can’t do that in the blockchain. This means that average or high-quality code by the standards of other industries won’t cut it. You have to have very high-quality code to survive in the wild-west of public blockchains.

The data structures aren’t what they seem to be. You might have been used to JavaScript’s arrays and maps, classes and when you get in Solidity, you might find everything looking familiar. Sorry to break the news. Solidity data structures have nothing to do with your Javascript data structures. For example, you can’t iterate the keys of the map, that’s because keys turn to hashes, so data is not there whatsoever. In many cases, where you would need a single data structure in JavaScript, you will need quite a few in Solidity. Once again, budget a few more days for your project.

Every tick of your code runs many times in tens of thousands of servers. For example, let’s assume that a smart contract increases a counter “i++.“ Typically this would run once in a server in your data center or a visitor’s browser. This is not the case with Solidity. In Solidity, thousands of nodes have to run that operation and to agree on the result. Solidity runs in a quite complex distributed system by default. This means that your code is expensive to run when compared to traditional hosting. You might like to sort stuff, but you will likely not have that luxury in Solidity. Sorting a large array might be very expensive. String append and other operations? You guessed right. Very expensive! Each operation consumes Gas. If you run out of Gas, your contract dies. Silently. Which leads to the next point.

There are no Logs. There’s something named “logs” or “events,” but they’re an entirely different thing. They aren’t supposed to be used for debugging. When you run Solidity, and something goes wrong, you get no output. How could you after all? In which of the tens of thousands of servers your code run would you go to get that output? Bad contract calls get silently dropped, and you may have a very hard time debugging them.

Solidity and the ecosystem around it are somewhat unstable. Don’t get me wrong. People do an excellent job, but still. Smart contracts and solidity are so new, and people are still trying to figure them out. Things change name often. Features change dramatically or get dropped with little discussion. Events and Logs might or might not be emitted by your Smart Contract when running in debug environments like Ganache (former testrpc). Your test net might be very slow for complex contracts, and it may slow you down. It’s good there is less stability and rapid innovation in this domain — I love that. However, from the developer’s perspective, it’s very rough and very tough.

Finally, the domain is tough. When people write Solidity, it’s usually to express something important related to identity, ownership, property or governance. Those domains were never simple.

Security is important. ‘msg.sender’ or ‘tx.origin’? You have to think about those tiny details. You can get a better taste of subtle gotchas here. People work hard to provide formal verification because they know how easy it is to get things wrong and the compiler can do very few things to protect you. You need to be able to prove that your contract doesn’t lose money. You need to prove that your contract doesn’t allow people to move money they don’t own. You need to prove that your smart contract, while taking care of all those fancy permissions, won’t lock money in a corner in a way that prevents their owners to control them. It might not be money. It might be physical property ownership rights, or any other application domain, but when you use Solidity, more often than not, the domain is very demanding.

There are many ways to get involved in the blockchain ecosystem. Writing Solidity code is highly likely one of the most demanding ones.