The Problem with Solidity

When developers consider writing DApps, learning Solidity is typically listed as their #1 task. That’s because Solidity is the only language developers can use to create Ethereum-based smart contracts. However, Solidity remains somewhat lacking in documentation, user support, assertions (ability to test program assumptions), and formal verification (a method to prove a program correct for all inputs).

That’s because Solidity is a very young language, one that continues to surprise users with new security problems. As one developer stated “you don’t know you have a problem until you hit it, and even the best devs in the world — even the creator of the language itself — didn’t see it coming.” (Quora)

Immutability

The immutable nature of Solidity tends to exacerbate these security issues. When a user deploys a smart contract, there no going back to change it. As such, developers are incentivized to keep their code uncomplicated and perform tons of testing. According to best practices, coders should check their code in both the testnet and a private testnet before launching — because of varying results.

This is a bit different than how most developers create code, which consists of “pushing it out into the world to see how it works, keeping track of the bugs, and then going back to drawing board to re-write the code, fix the bugs, and re-releases it.” In essence, a continuing write-release-fix cycle.

For developers that don’t get it right the first time, they risk deploying a smart contract that will exist as long as Ethereum does. In order for an end-user to fully trust the smart contract, the Solidity code is designed to be immutable. As a consequence, some developers recommend that smart contracts contain a built in ‘kill’ function for the contract ‘just in case’. Without a write-release-fix cycle, coding without security flaws seems to be a precarious endeavor.

Reentrancy Attacks

Not incidentally, an ongoing issue with Solidity is its vulnerability to attack. In fact,

…there are many examples of attackers exploiting the logic of smart contracts to perform attacks with effects such as draining of funds, gaining an advantage over other users of the smart contract, and rendering the smart contract unusable. These attacks are often devastating due to the huge amounts of value placed in these smart contracts by their users. Due to the novelty and popularity of smart contracts, many of the worst smart contract vulnerabilities may not yet be discovered.” (nccgroup).

The best known Solidity vulnerability is called a reentrancy attack. To put it simply,

This attack consists on recursively calling the call.value() method in a ERC20 token to extract the ether stored on the contract if the user is not updating the balance of the sender before sending the ether. (Medium)

The most famous reentrancy attack to have occurred is known as The DAO Attack, a $60 million ether theft that occurred in June 2016. In these attacks, a malicious attacker sends ether via a deposit function, quickly withdrawing it via a withdraw function, and then doubling the withdrawal via the fallback function (triggered when the function signature does not match any of the available functions within a Solidity contract).

The fallback function allows the attacker to call upon the withdraw function again before the first withdraw function finishes — and thus before the userBalances variable is updated). In essence, the attacker ix tricking the victim’s account into thinking that it still has ether to withdraw before the victim’s account balance is set to zero. This can be done repetitively until the balance is depleted.

Other Security Issues

Aside from a reentrancy attack, smart contracts are vulnerable to phishing and other types of attacks as well. For instance, an attacker may call upon a wallets transfer function to send ether. For wallets that self-identify code-wise as tx.origin, that ether will be sent. (tip: use msg.sender instead).

Finally, Solidity users should also be sure not to perform too many external calls in their code. Calls to untrusted contracts can lead to malicious code being executed within a contract (or another contract dependent upon it). If an external contract must be called, developers should mark their code to indicate a potentially unsafe interaction (ie “untrustedClient”).

Several other common attacks on Solidity can be found here. Specific protocol recommendations to avoid security risks reside here.

Unsafe & Unready

With all these security holes, its appears that Solidity is a not-ready-for-prime-time as a programming language. Unfortunately, DApp innovation and development remains hostage to Ethereum. At least until another DApps-friendly platform comes along. For now, developers must employ a language that even the Ethereum recognizes as flawed:

Solidity was started in October 2014 when neither the Ethereum network nor the virtual machine had any real-world testing, the gas costs at that time were even drastically different from what they are now. Furthermore, some of the early design decisions were taken over from Serpent. During the last couple of months, examples and patterns that were initially considered best-practice were exposed to reality and some of them actually turned out to be anti-patterns.(Ethereum.org Blog).

Smart contracts are an ingenious invention, they certainly have enhanced the standing of blockchain technology. But why must they employ Solidity? As a thought experiment, what similar DAPPs might be created by a developer intent on using C++, Python, or other language?

The XTRABYTES platform might offer a potential solutions in the long-term. Is a code-agnostic platform that enables DApps developers to code at their hearts content. As the blockchain space matures, expect demands that alternatives to Solidity exist for creating smart contracts. XTRABYTES will be there.