Vyper Compiler Riddled with Bugs, 75% Fixed, Deposit Contract Not Affected – Trustnodes

Vyper Compiler Riddled with Bugs, 75% Fixed, Deposit Contract Not Affected


An audit report by Consensys Diligence has found the Python-based Vyper compiler has “multiple serious bugs” and “the codebase has a high level of technical debt which will make addressing these issues complex.”

“Since the existing Python-based Vyper implementation is not yet production ready, it has been moved out of the ethereum github organization into its own organization: vyperlang,” Piper Merriam of the Ethereum Foundation (EF), said before adding:

“The existing maintainers are planning to address the issues independently once again, but we will continue to follow the project closely.”

The existing maintainers said there was “an enormous amount of bug fixes” in a new release, adding 75% of the 29 bugs identified in the audit have now been fixed.

Vyper is like Solidity, a python based smart contracts coding language, and was initially authored by Vitalik Buterin, ethereum’s co-founder.

The deposit contract for ethereum 2.0 uses Vyper instead of Solidity, with a compiler being kind of a “translator” that turns human readable code into machine readable code.

However the Vyper maintainer who goes by the nick of URaTowel says the results of this audit do not affect the deposit contract.

That conclusion was supported by Danny Ryan, the ethereum 2.0 coordinator, who publicly said:

“The point of the formal verification techniques at the bytecode level is to remove the compiler from the picture.

Although we agree that the current Vyper compiler is not currently fit for production when not employing such deep analysis, the bytecode of the deposit contract has received an unprecedented level of analysis and scrutiny and is ready for production.

A detailed report will be released on the deposit contract methods in a matter of weeks, and we will have more discussion in blog posts on the usage of Vyper in this scenario.”

Formal verification takes into account any potential compiler level bugs that might affect the code, with the deposit contract itself undergoing an audit that is expected to report this month.

Depending on the results of that audit, the deposit contract will then launch presumably first on the testnet. That will then allow for the full on ethereum 2.0 testnet to launch, with it expected to run for at least three months provided it all goes smoothly.

After that three months period, this will go live with ethereans then able to send their eth to the deposit contract which burns and destroys them by sending them to an address that no one has the private key, so they can’t move.

In return for that burned eth, depositors get an equal amount of eth on the new ethereum 2.0 blockchain where they can stake and earn a variable rate of interest depending on how many stake, ranging probably at around 5% to 8% a year.

The chances of this going out by the end of March stand at less than 25% according to a prediction market, with it far more likely it goes out in late spring or early summer depending on how it all develops further.

Once it does launch, the current Proof of Work (PoW) chain will continue to operate as normal, with some describing the initial phase of the Proof of Stake Beacon chain more as an incentivized testnet.

Incentivized because the eth is real, but you can’t quite do much with it save for validating PoW blocks to begin with, followed then by the full functionalities as a normal blockchain once the sharding stages go out sometime next year at this rate by optimistic estimates.

Copyrights Trustnodes.com

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>