Ethereum

Ethereum Seperent smart contract language ‘should not be considered safe to use’

Serpent smart contract language
(C) iStock.com/bugphai

One of ethereum’s earliest smart contracting languages is being put out to pasture, after an audit highlighted a number of vulnerabilities.

The audit was carried out by blockchain security specialists Zeppelin Solutions at the behest of prediction market Augur. As one of the earlier ethereum projects, Augur has a large amount of its REP in contracts written in Serpent.

While Serpent was the principle smart contract language available at the time of the Augur token contract, it was soon replaced as the main language by Solidity.

Zeppelin weren’t impressed with what they found. In a blog post, the company wrote:

“We have found the Serpent project to be of very low quality. It is untested, there’s very little documentation, and language design is very flawed. Serpent should not be considered safe to use unless many critical problems are fixed.”

Critical problems

The report splits the long list of issues it found with the Serpent Compiler into critical, high, medium and low-level risks.

The company highlights a number of critical risks:

Low quality tool and language

The report notes that the compiler ‘gives almost no assurances to developers, and things that should be errors are considered valid Serpent programs’. This poses a security risk for developers.

Stalled development

The last update of the language is over two years old.

No testing

The compiler does not have automated tests, which helps prevent regression problems (when changes break previously fine components) and catches issues early. The audited project did not have any tests and so was particularly prone to regression issues.

Untyped language

Serpent is an untyped language. The report states that:

“Types have proven a useful feature to prevent programming errors, facilitate refactoring, and in general enable more robust software engineering.”

Invalid syntax

The parser accepts ‘clearly invalid’ syntax which means the compiler generates bytecode from an invalid structure. This presents a high risk of the code to be executed not matching the user intention.

Compiler does not fail on non-initialised variables

The report says:

“Referencing a non initialized variable does not raise a compile error, and just returns 0. This leads to any misspelling causing a reference to the variable to silently fail, and yield potentially invalid values.”

You can read the full report here.

Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

To Top