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.
‘Low quality’ and ‘flawed’
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.
More eyes needed
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.
Solidity audit?
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