Vyper vulnerability and Curve finance explained by a Vyper IDE developer

A couple of word about myself

I am Dexaran, a founder of EthereumCommonwealth team, security auditor, hacker (I have DDOSed EOS mainnet in 2019 and froze its DAPPs for half a year and drained Chintai exchange).

Founder of Callisto Security auditing organization. We have audited more than 300 smart-contracts and not even a single one that we reviewed was ever hacked.

My team (EthereumCommonwealth) built the first online version of the vyper compiler on 11 August 2017. Here is the report. Here is this online vyper compiler prototype.

I have participated in the development of the vyper programming language.

In 2020 I wrote this article that highlighted the problems of new programming language development and explained what happened to Curve Finance 3 years before it actually happened.

We have abandoned this project because:

1. It solves no real problems.
2. The development of a new programming language and/or compiler is a very specific task and it requires high expertise in compiler development — Ethereum team doesn’t have any compiler developers who participated in the real compiler development (GCC or LLVM).
3. From security point of view it is much better to rely on existing solutions if they don’t have any critical problems that need to be addressed.

TL;DR

One guy decided to create a new programming language (which was completely unnecessary to begin with), even though he had no experience in the developing of programming languages. After that, some other guy created a compiler for it, even though he wasn’t a professional compiler developer. Then some third guy built a system that managed a huge amount of his clients’ funds using all that stuff and then it all broke.

Then they started stating “no need to point fingers at each other” but from a security perspective it’s a complete responsibility of the guy who decided to pick exactly THAT insecure toolchain to build critically important software with it.

What happened?

A vulnerability was discovered in a vyper compiler.

This allowed hackers to drain $62M worth of funds.

The development of a new programming language is a big mistake and a security threat

I wrote it in 2020 and I strongly recommend any blockchain developer to review my article before digging into any code.

With the hack of Curve Finance it became evident WHY it is a mistake.

I can quote the most important idea from my article:

Developing a new compiler is extremely specific task that requires highly qualified team experienced in exact this area. All the custom compilers are orders of magnitude worse compared to the existing ones such are GCC or LLVM. This should be noted that GCC is in development for 32 years already while LLVM is 17 years in development. If someone decides to use a custom programming language for smart-contracts and developed a new compiler for it then it is reasonable to expect that it will take about 15 years to bring this tools to the level of performance and security of nowadays LLVM assuming that a team of highly specialized experts is dedicated for this task.

Were vyper compilers developers going to outperform LLVM that was in development for 17 years and had a dedicated expert working on it? Were they going to outperform it in 4 years without any expertise in the area? This is a gross disregard for security rules in development.

What has gone wrong?

Everything…

1. Vyper programming language — there was totally no point to create it at the first place. What is more important however is that this programming language was created without involving any security experts / experts in programming language & compiler development.
2. Vyper compiler development. This is a very specific, cumbersome and risk-involving task. Also done without any expertise in the area.
3. Utilizing this immature toolchain to build critically important parts of the financial application. Whose genius idea it was to take an untested toolchain and throw customers funds into it?

Security recommendations.

1. Read this article. Seriously, it have explained everything that happened 3 years before it happened.
2. Stop the development for the sake of development. Do not implement something that is unnecessary. Do not put it on table. Every line of new code has a chance to have a vulnerability or bug.
3. Do not use potentially insecure software. Stick to the tested options if it is not known to have serious problems.
4. Also do not use software that does have security problems just because everyone uses it.
5. If you don’t have expertise in some area — do not think you will outperform experts. Instead hire experts or consult with them at least.
6. Treat security seriously. VERY SERIOUSLY. You are dealing with your customers funds. Think of it as you are dealing with people’s lives.
7. Choose your auditors wisely. Your security auditor must be (1) transparent and (2) competent. There are a lot of “marketing auditors” nowadays. Use commonsense — if your auditors is known to have a number of contracts that were hacked after it was assigned a “secure” stamp — maybe it’s not the best auditor.