May 23, 2022: Hot Vyper Summer™ 🔥☀️
OpenSea's Gas-Optimized Seaport Outshined by Vyper
The launch of OpenSea’s Seaport is rekindling the Vyper vs. Solidity flame wars.
Seaport is a pretty neat concept in and of itself. OpenSea will use Seaport to launch their next iteration, a decentralized NFT trading platform. They open sourced the code so anybody could replicate the platform on their own.
The initiative in and of itself is certainly praiseworthy, especially given OpenSea’s dominant role within the NFT ecosystem.
Yet the launch revived a flame war between the Vyper and Solidity developer communities. The Seaport contracts were engineered with extreme gas efficiency in mind, given that OpenSea’s existing contracts are gas guzzlers.
The amount of engineering utilized to get Seaport’s gas costs cheaper is remarkable. The final codebase is an incredibly complex engineering feat which will be studied by aspiring Solidity coders for some time. Although the codebase is well documented, casual coders will find it difficult to follow the complex logic needed to halve gas use.
While the technical sophistication required to create the codebase is an achievement, the Vyper community was quick to point out they could have achieved both gas savings and code readability if they’d simply used Vyper.
Consider the code Seaport uses to transfer tokens. The Seaport basic transfer function took a full thread to explain what was going on under the hood.
Where the Seaport contract pounded out several hundred lines of complex code to eke out gas savings in this case, the lengthy function was nonetheless outperformed by the far simpler out-of-the-box Vyper equivalent.
Team Solidity would note this was not a strictly 1:1 comparison. Much of the coding gymnastics in the Seaport contract was performed to efficiently bubble up error messages.
Team Vyper would rebut that this was a silly waste of effort, given that error messages are mostly only useful in dev environment anyway. For the case of OpenSea, it would cost ~$450K annually to bubble up error codes users wouldn’t even see in production.
The fact Solidity required heavy massaging to do what Vyper does in a legible line of code is notable. We’ll have to wait for a full rewrite to see a perfect comparison, but this round of the battle goes to Vyper.
Anybody who has attempted apples-to-apples comparisons among the current versions of Vyper and Solidity has generally conceded Vyper outperforms. I say “generally” because some I’ve seen some anecdotal reports to the contrary, though the methodology has not been made public in such cases.
I observed this fact myself a month prior, and other researchers who shared their notes have also found similar results.
The gas savings within Vyper are most clear when it comes to contract deployment.
Contract deployment is typically a one-time cost incurred by the deployer so it is less important to the end user.
What matters most is the efficiency in calling functions as everyday users interact with the smart contract. Here Vyper has a marginal efficiency edge according to most evidence, although the gap is narrower. Yet the wider smart contract community has struggled to accept this fact.
The Seaport release has more people questioning if it’s time to migrate to Vyper.
Developer obstinance is your opportunity. If developers insist on writing less efficient code, devs willing to make the switch have a competitive advantage.
Advocates of Solidity are mostly arguing they prefer Solidity because of the larger ecosystem of developers and corresponding tooling. Some also simply express a preference for Solidity’s curly bracket syntax over Vyper’s pythonic style.
The inheritance (capability of importing modules) is another drawback to Vyper, although it appears this will be implemented quite soon.
The above arguments mostly boil down to developer preference. In this case, users pay a slightly higher price to support developers’ preference for their familiar stack.
All developers can get the most gains by getting down and dirty with assembly-level bytecode. However in practice coding in such a manner is difficult and extremely slow. Therefore end users pay higher fees to support developer efficiency.
In terms of efficiency, though, Vyper is already quite close to raw assembly coding.
This sort of efficiency is required when running scripts that involve pinching Wei, for example MEV searching.
The tooling within Vyper has also advanced a long way from when some users first tried it out. ApeWorx, a smart contract development tool forked from Brownie, is providing robust functionality for devs.
ApeWorx is also releasing a much anticipated Ape Academy on June 1, which will centrally feature Vyper development.
In the meantime, if you’re interested in learning about Vyper development you should check out the great series by @BowTiedDevil or the Vyper docs.
Whales can also support the Vyper community directly by voting for the veFunder Vyper gauge on Curve.
If you lack funds and dev chops but want to support Vyper, meme magic is real. You can help support growing the ecosystem simply by spreading memes about Vyper.
Perhaps the flame wars will inspire Solidity devs to increase efficiency of future releases, at which point the differences between the languages would become purely stylistic.
Until such a point, we may see demand for Vyper developers increase. It’s a great time to learn the basics and enjoy a Hot Vyper Summer™!
