Ethereum is almost single-handedly responsible for the popularity and availability of so-called smart contracts. A smart contract is simple in concept: a set of instructions are followed automatically whenever certain conditions are met. The conditions and the instructions that follow are limited mostly by the imagination of the smart contract programmer.
For smart contract programming on Ethereum, the clear favorite is Solidity. Most smart contracts are written in Solidity, and every major resource for Ethereum smart contract programming covers Solidity.
BowTiedPickle published an excellent guide to reading smart contracts without knowing Solidity. Given that guide’s popularity, it’s clear that folks are interested in smart contracts but intimidated by Solidity.
Vyper for Beginners
- Part 1 — Introduction
- Part 2 — Toolkit
- Part 3 — Variables, Flow Control, Functions, Hello World!
- Part 4 — Interfaces
- Part 5 — Dynamic Arrays
High Level vs. Low Level Languages
You will often see the description “high level language” used online when discussing Solidity. What does that mean, exactly?
The Ethereum Virtual Machine (EVM) is the totality of that defines how a smart contract stores data, records transactions, and executes computations across the network. EVM does not have a concept of “Solidity”, and it has no way to execute “Solidity code”. Smart contracts written in Solidity are compiled down to EVM bytecode, an efficient machine language that is easily parsed by a computer, but not easily understandable by humans.
EVM bytecode is broken down into a series of “opcodes” or machine code functions for manipulating individual pieces of data. They are published in the Ethereum Yellow Paper, an extremely dense and technical document that describes every facet of EVM that a smart contract programmer would ever need.
For a new smart contract programmer, the Yellow Paper would be a poor choice. It is far too specific and has no practical “getting started” sections.
To bridge the divide between the programmer and the low level machine code, high level languages were created. These high level languages allow a programmer to express an idea like “store the value 69 in a variable named lol“. Then this abstract representation is fed into a compiler, which takes the readable instruction (high level) and transforms it into machine code instruction (low level).
When people talk about writing a smart contract, they typically intend to write that smart contract in a high level language. Then they compile and deploy the raw bytecode to the blockchain later.
The key takeaway here is that Ethereum runs entirely on low level bytecode. Solidity is only one means to turn a thought into that bytecode. Solidity is not Ethereum, and Ethereum is not Solidity.
There are alternatives, and I am writing this series to cover an alternative high level language: Vyper.
What is Vyper?
Viper (note the different spelling) is a smart contract language written by Ethereum creator Vitalik Buterin s a replacement for the since-deprecated Serpent smart contract language. The project was renamed Vyper after being taken over by a team of volunteers and contributors. You can review their repository and code on the Vyper GitHub project page.
Vyper has three primary goals:
- Security: It should be possible and natural to build secure smart-contracts in Vyper.
- Language and compiler simplicity: The language and the compiler implementation should strive to be simple.
- Auditability: Vyper code should be maximally human-readable. Furthermore, it should be maximally difficult to write misleading code. Simplicity for the reader is more important than simplicity for the writer, and simplicity for readers with low prior experience with Vyper (and low prior experience with programming in general) is particularly important.
NOTE: these points are taken verbatim from the Vyper documentation.
Because of the focus on security, simplicity, and auditability, Vyper purposefully omits some features that Solidity includes. This smaller feature set allows the Vyper maintainers to prioritize security by restricting features that could be abused. Whether these features are abused accidentally or intentionally, the danger of Solidity’s flexibility is well-known, and there is a long-running event called the Underhanded Solidity Contest that awards prizes to submitted smart contracts that contain the most devious, exploitable bugs.
The purpose of the contest is to expose these tactics to a wider audience and have them fixed, so this is a “white hat” effort.
Vyper is not immune to devious design patterns, but the fact that it’s written to make many of them impossible should encourage you to explore it.
Who Should Learn Vyper?
Anyone who already knows Python and wants to learn smart contract programming should try Vyper, full stop.
Vyper has very similar syntax to Python, and long-time Python programmers will have no issue expressing their ideas.
Who Is Using Vyper in Production?
This isn’t as widely known, but the original UniSwap project was written in Vyper. UniSwap V2 and V3 are written in Solidity, but we won’t hold it against them.
The most successful and highest profile projects using Vyper are Yearn and Curve.
If you decide to focus on Vyper, you may even catch the eye of our favorite Hentai aficionado banteg.
Who Am I?
I got started in the world of smart contract programming last summer when I discovered Andre Croje’s Rarity Project, a free-to-play (except for gas fees) Dungeons & Dragons-like RPG on the Fantom blockchain. I built a bot that would automatically send my heroes on adventures, level up, and collect gold & experience.
From there I began studying the inner workings of Uniswap, translating my Rarity experience into automated trading on UniSwap and its various forks.
I debuted Degen Code a few months later. Degen Code is a newsletter dedicated to creating blockchain automation tools in both Python and Vyper. I build DEX trading bots and write smart contracts for intra- and inter-network arbitrage. I publish several times a week and include the complete source code for all of my bots and smart contracts. Very little is “left as an exercise for the reader”, a common issue with deeply technical smart contract content.
What Will This Series Cover?
I will continue the series with specific mini-lessons covering how to write Vyper smart contracts. The next lesson will cover installing the required tools for writing, compiling, and deploying a Vyper smart contract.
If you’re enterprising and want to work ahead, look into the Brownie toolkit.
