The Problem With Solidity

    Well-Known Member Staff Member
    Likes Received:
    Trophy Points:
    May 12, 2018 at 02:08
    When developers consider writing DApps, learning Solidity is typically listed as their #1 task to complete. 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 simply 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)


    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 are encouraged to check their code in both the testnet and a private testnet before launching.

    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 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).

    [​IMG]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 (and if you identify your wallet as tx.origin, that ether will be sent). Use msg.sender instead.

    Finally, Solidity users should also be sure not to perform to many external calls in their code. Calls to untrusted contracts can lead to malicious code being executed in 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 resides here

    Unsafe & Unready

    WIth all these security holes, its appears that Solidity is a not-ready-for-prime-time programming language. Unfortunately, DApp innovation and development is being held hostage by Ethereum. At least until another DApp-friendly platform comes along. For now, developers must 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.( Blog).​

    Smart contracts are an ingenious invention, they certainly have enhanced the standing of blockchain technology. However, developers are now straight-jacketed into using Solidity. What similar DAPPs might be employed by a creative developer using C++, Python, or another language? Could similar smart contracts be developed without using Solidity?

    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.

    The post The Problem With Solidity appeared first on XTRABYTES Today.

    Continue reading...