Serpent, one of ethereumâs earlier smart contracting languages is no longer safe to use.
That might be the biggest takeaway from an audit of ethereumâs Serpent compiling language, released last week by blockchain security firm Zeppelin Solutions. The findings point to dozens of problems with the compiler, including eight critical vulnerabilities.
Zeppelin was hired by Augur, an ethereum-based prediction market, to conduct the audit two months ago. With nearly $2 million-worth of its token (REP) sitting in a contract written in Serpent, Augur had good reason to be concerned about the security of the older language.
Augur was one of the earlier ethereum projects, and at the time its token contract was written, Serpent was the main smart contract language available. But soon after, Solidity was introduced and took over as ethereumâs flagship smart contract programming language, pushing Serpent to the wayside.
Even so, Augur CEO Joey Krug said there were few public warnings about possible issues that would prevent Serpent from executing code as expected.
He told CoinDesk:
âNobody ever said Serpent was insecure or depreciated. It just wasnât as popular [as Solidity].â
While Augur had planned to move to another smart contract language at some point, results of the compiler audit essentially forced the projectâs hand. As soon as Zeppelin notified Augur of the security issues involved, Augur moved quickly to migrate its REP tokens to a secure ERC-20 token contract written in Solidity.
For others wondering if they should follow suit, Zeppelin Solutions has spelled out the full results of its audit in a 36-page report.
In a blog post, Zeppelin called the Serpent project âlow qualityâ and âflawed,â and cautioned developers to refrain from using the language until its many critical problems were fixed.
The news prompted ethereum founder Vitalik Buterin to send out a tweet, calling the programming language âoutdated tech,â and warning it lacked adequate âsafety protections.â
As for Augur, the most critical Serpent vulnerability was one that would allow a hacker to change the date in which the REP token contract was created, essentially freezing up the token supply.
âYou could make the contract think it had not actually been officially created yet, so that basically none of the transfers would work,â said Krug.
If Serpent had only that one problem, Krug said he would have happily fixed the code and continued using the language for the time being. But the number of problems revealed by the audit were simply too overwhelming.
So instead, following an update path outlined by Zeppelin, Augur moved to rewrite its old REP token in Solidity and deploy the new ERC-20 contract on ethereum. It then effectively hacked its own Serpent smart contract, freezing the REP token, before migrating the balance of the frozen REP to the new contract.
In a separate blog post, Zeppelin urged any ethereum projects still using Serpent follow a similar migration path to move their tokens to a more secure Solidity contract.
The Serpent programming language and compiler were both written by Buterin. But the fact only one person wrote the code may underlie some of Serpentâs problems.
Zeppelin wrote in its report:
âLess eyes on the code means less bugs being noticed.â
Zeppelin also pointed out that Serpent is two years old, with few commits since October 2015. Adding to that, with hardly anyone using Serpent now, there is little possibility of anyone spotting problems in the code or of those problems being fixed.
Solidity, on the other hand, was written by a team of people led by Gavin Wood, one of the founders of ethereum. And because Solidity is more widely used and sees a lot more activity â 30 times the pull requests, 20 times the commits, eight times as many contributors, according to Zeppelin â compared to Serpent, the newer program is less likely to have the same number of issues.
As for what developers should use instead of Serpent, the Zeppelin report suggests Solidity is the best available answer today. However, it also suggest developers consider Viper, a successor to Serpent, stating that Viper âlooks superiorâ to Serpent. But in a tweet, Buterin recommended developers hold off until Viper passes an external audit first.
But, perhaps one of the more alarming issues brought to light by Zeppelinâs Serpent compiler audit is that Solidity itself has not been audited either. And given that millions of dollars-worth of tokens are currently managed by smart contracts written in Solidity, some, including Krug, find that news unsettling.
Adding to concerns about Solidity, the Zeppelin compiler audit comes on the heels of a $30 million hack of the Parity wallet, where a bug in the Parity code essentially allowed the hacker to turn three multi-signature wallets into zero-signature wallets, and drain the funds.
In a blog post following that attack, Parity pointed a finger at Solidity, stating that âsome blame for this bug lies with the Solidity language and, in its current incarnation, the difficulty with which one can understand the execution permissions over functions.â
But an even bigger ethereum theft took place a little more than a year ago, when a hacker took advantage of a loophole in the Solidity code to siphon $50 million in ether from a project called The DAO. The damage was deemed so extensive, the developers behind ethereum implemented a hard fork in the protocol to roll back its transaction history.
Software code audits are a requirement in many critical industries, and Demian Brener, CEO at Zeppelin, thinks the same case should be made for smart contract code.
âGiven the number of vulnerabilities uncovered in Serpent, we believe compiler audits, along with code audits, should become a best practice,â he wrote in an email to CoinDesk. He added that Zeppelin is currently talking with the Ethereum Foundation to make that happen.
Meanwhile, Krug summed up his own thoughts on the matter by saying:
âOverall, the message is, more stuff should be audited.â
Snakeskin image via Shutterstock