Perhaps you saw they were handling raw venom and were too scared to ask.
What you see in this screenshot is just the impressive results: a Github diff showing off the gas performance of various tests on a slew of ERC standards, all of which either improved or stayed the same.
Not pictured is the months of work that went into making this happen by changing how the stack was reordered.
The result was a “free lunch” — improved code size (aka cheaper to deploy) and lower gas costs during execution.
This gas profile compares the standard Vyper ERC20 token with the hyperoptimized “Solady” implementation. The Vyper token outpeforms everything except deployment cost.
The gas improvements on the compiler side highlight Vyper’s engineering chops and relentless focus, although gas hyperoptimization has never been the project’s M.O.
The real comparison lies in the well-optimized ERC20 token featured above, written in such plain language that even non-coders can roughly intuit what is happening:
This contrasts with the extensive gas golfing of the Solidity-based equivalent, which relies on directly writing (ie `mstore`) hexcodes representing inline assembly language.
The Solidity engineering is no doubt an impressive feat. The complex instructions are well-documented.
Yet this sort of direct manipulation of the underlying bytecode is what Solidity (and Vyper) were designed to abstract away in the first place. If you are talented enough to understand and write direct assembly language, no need for a programming language at all… just write a series of raw opcodes!
For this reason, Vyper will likely never beat Solidity on gas optimization. There will always be chad devs who can torture the EVM to eke out another 0.1% in gas savings.
Vyper shifts the burden of assembly-level gas hyperoptimization onto the compiler devs. If you’re building a project, you just focus on building your project. Let the top notch devs tinker with gas improvements at the machine bytecode level and socialize the results through the compiler.
Thus, even though the Vyper compiler-level gas breakthroughs are impressive, the most remarkable aspect is how the scope of the Vyper project has never deviated from its focus on intuitiveness and readability.
We hammer on the “readability” point because it’s crucial. Not all devs are 100x chads like the Vyper team. The vast majority of devs know only enough to be dangerous, especially when deploying unmodifiable code that can handle your money.
The aforementioned Solady token is sufficiently complex that the median Fiverr coder won’t understand how to modify it properly. As a result, we’ll continue to see incidents like this hack from last year.
Why not just use Vyper?
The overall developer experience of Vyper continues to boast improvements. The recent release of Vyper 0.4 brought modules.
Combined with the frequently-updated Snekmate, and Vyper devs now have access to a robust library of templates, just as OpenZeppelin supercharged Solidity innovation.
The powerful Titanoboa dev tool recently shipped a new version:
The expanded error logging is a nice devex feature, but ability to compile prior versions of Vyper is critical. When using Boa to work with the contracts in the Curve ecosystem, the protocol has released code using the latest Vyper version since back in the v0.2 days. Now Boa can work with them all seamlessly.
If you haven’t, give Boa a shot. It really has become quick and easy to get started with a phenomenal developer experience. Our tutorial can show you the ropes:
Perhaps most exciting, the Ethereum Foundation has officially added Vyper to their bug bounty program, finally bringing the foundation’s ample resources to the challenging problem of securing compilers.
Vyper devs are truly cooking!
Support Vyper
We hope everybody can acknowledge the value to the ecosystem of having a robust and thriving Vyper dev community. According to highly accurate internet polls, a majority of new projects are using Vyper!
Of course, we don’t actually have any such illusions, but we do know that the projects which take the snek pill are finding the experience satisfying and rewarding.
One of the biggest advantages of opting for Vyper is quite simply the access to the top-notch and highly dedicated Vyper team. Building your project in Vyper means if you run into trouble, you can get help from the core team nearly 24/7.
If you don’t bother them, the devs will be forced to fool around and entertain each other….
Even if most of the readers will never deploy their own smart contract, we hope you all grok the importance that a thriving Vyper community has to the wider Ethereum ecosystem. When Vyper makes breakthroughs, these breakthroughs can get utilized everywhere throughout the EVM.
There’s plenty of sniping between Solidity devs and Vyper devs. In truth, it’s best for multiple languages to exist. Friendly competition among languages serving to drive improvements everywhere.
We hope Solidity maxis can see the rapid improvements in Vyper as an impetus to up their game. Similarly, Vyper has benefited from the existence of innovations driven by the rest of the ecosystem. We saw earlier how breakthroughs in gas efficiency engineered by Solidity devs pushed the Vyper compiler to improve its native token.
An arms race here actually benefits everybody.
An EVM dev utopia, if you can keep it…
Even as Vyper makes gains everywhere, the unfortunate reality is that sustained project funding is far from secure. The Vyper team had previously enjoyed generous grants from the Curve ecosystem, but this well is at risk of drying up rapidly.
Perhaps one day Vyper will take novel steps like establishing a for-profit wing which may secure sustainability long-term. At the moment, Vyper functions as an open source project and a public good.
We see a great opportunity for L2s, which could use Vyper as a pipeline to steer dev activity onto their chains.
It’s annoying that Vyper must beg for scraps while marketing departments get sauced, but this has long been a difficulty for open source projects.
Let’s pass the hat if we must and keep Vyper thriving!