,a vyper script is compiled using

 

 

State Variables

State variables are values permanently stored in contract storage and can be of any type, such as:

 

 

Mapping

The first thing a Vyper contract contains is the contract storage fields, such as a token balance mapping:

 

 

 

which is a state variable that defines keys and corresponding values.

Vyper mappings are basically hash tables that are initialized, as seen above, so that

“every possible key exists and is mapped to a value whose byte-representation is all zeros: a type’s default value.”

The key data is not stored in the mapping, but just its keccak256 hash to look up its value.

In defining balance, the type public() is given, followed by the mapping syntax:Where the value type of wei_value is given first, followed by the key (address) in square brackets – similar to Python’s handling of arrays.

 

Definitions

You’ll notice that Vyper uses a colon in defining names (like balance) as opposed to Python’s equal signs, although Python 3.6 includes the same syntax for variable annotation:

 

 

 

Where the colon syntax is for variable annotation, and the colon is used as the assignment operator that assigns just a type annotation only. Vyper uses this syntax for true value assignment.

Integer Types

Vyper has just two integer types: uint256 (for non-negative integers) and int128 (for signed integers) — as opposed to Solidity’s uint8 to uint256 in steps of 8, and same for int8 to int256 (this means 64 different keywords for int types).

 

Booleans, Operators, Comparisons, and Functions

Vyper has nearly identical syntax to Python for most operators, including:

 

 

 

As well as some similar built-in-functions:

 

 

 

And some new ones:

Lists

Lists in Vyper are declared using the format _name: _ValueType[_Integer], while setting the values and return statements have the same syntax as Py=thon.

For example:

 

Structs

Structs are types that you define, which group variables, and are accessed using struct.argname, as so (somewhat similar to Python dictionaries):

 

Defining Methods

Methods (contract methods in Vyper) are defined the same way in Python and Vyper:

 

In addition to what Python provides, Vyper includes Ethereum-specific decorators such as @payable and @assert – the former used to make the contract able to take transactions and the latter taking a boolean expression:

Notice the def function_name(arg1, arg2, …, argx) -> output: syntax to define a function. Unlike in Python, Vyper explicitly defines the output type in the def line after the ->.

Constructor Functions

Constructor Functions go by the same convention as Python and instantiate a given contract and parameters on the blockchain. The init initializes the program and is executed only once. For example:

 

As in Python, self is used to assert instance variables. The above function is decorated with the @public decorator to give it public visibility and allow external entities to call it (as opposed to the default — or leaving out the decorator — which is private).

The decorator @constant is used to decorate methods that only read a state, while @payable makes any method able to be called with a payment.

 

Events

You can log events using __log__ in indexed structures, as so:

Writing Vyper Contracts

Now, let’s write a couple simple Smart Contracts. The following code snippet allows the contract to receive an NFT (non-fungible token) and be able to send against that token.

The following demonstrates the @public decorator, defining a function with a single parameter that is explicitly given a type, and a simple code body using assert statements to verify if a user has the right to vote as part of a “voting with delegation” program:

Having discussed the syntactical and logical distinguishments, the code isn’t too intimidating. vyper.online offers the entire source code for the “voting with delegation” program, using structs for voters and proposals, and the following aptly-named functions:

As with any programming language, planning out the major constructs (in this case, function contracts) beforehand makes the programming much easier. The major difference in Vyper to keep in mind is the lack of OOP paradigms. In the current stage of development, you cannot yet make external code calls.

The considerations for allowing external code calls can be seen in the following development suggestion:

 

# External contract A:

Where contract B calls on contract A, including methods within A, in the simplest example possible.

Running Vyper

To follow along writing code, go to vyper.online, and write the code examples under the “Source Code” tab and click “Compile” when ready. The most used client (though in pre-alpha) for Vyper implementation and test-execution is Py-EVM, developed initially by Vitalik himself, which allows the user to add opcodes or modify existing ones without changing the core library, enabling far greater modularity and extensibility than with a typical client.

To get Py-EVM, just use pip install py-evm==0.2.0a16.

 

3a. Deploying Vyper Contracts

While Py-EVM is currently in pre-alpha and may be difficult to get up and running, there are two simpler alternatives to deploying Vyper contracts to public testnets (and a bonus):

1) Paste the bytecode generated from vyper.online into Mist or geth

2) Use the myetherwallet contract menu to deploy in the current browser 3) (Upcoming)

In the future, Vyper will integrate with populus, allowing you to easily deploy Vyper contracts

For simplicity’s sake, we’ll deploy contracts using option (1) and Mist (a fresh UI on top of geth as opposed to the terminal-based geth). Since Vyper compiles down to the same Bytecode as Solidity, we don’t need any Vyper-specific clients, and can follow these somewhat-roundabout steps:

1. Go to vyper.online and click “Compile” on the pre-filled voting “Source Code”
2. Copy everything under the “Bytecode” tab
3. Install Mist for your OS, if you haven’t already
4. Allow the node to download and sync (this happens automatically)
5. Select “USE THE TEST NETWORK” in the Mist setup
6. Create a password (and remember it…)
7. Input the Contract
8. Select “Contracts” in the Mist interface
9. Select “DEPLOY NEW CONTRACT”
10. Go to the “CONTRACT BYTE CODE” tab
11. Paste in the Bytecode you copied from vyper.online

Deploy the Contract

1. Select “DEPLOY” and enter the password from earlier
2. Confirm the Vyper contract has been deployed
3. Go to the “Wallets” tab in Mist
4. Scroll down to “Latest Transactions”
5. You should see the contract we just deployed!

*Although in the“Creating Contract” state as it’s not being mined and validated

Conclusion

This guide provides a logical and syntactical introduction to Vyper, allowing us to begin programming and deploying contracts. With the knowledge from this guide, you should be able to contribute to the development of Vyper, its documentation, and continue to learn by coding at vyper.online.

Again, Vyper is not meant to replace Solidity, but as one study found over 34,000 vulnerable contracts, the need for stronger security in this space is greater than ever, giving Vyper an important future in Ethereum

 

Further Reading and Roadmap

As Vyper is still in experimental development, the official documentation and GitHub are the most comprehensive resources, with the following providing value as well:

01.Vyper’s Community Gitter

02.Vyper Tools and Resources

03.“Ethereum Book” pages on Vyper

04.Study: “Finding The Greedy, Prodigal, and Suicidal Contracts at Scale”

05.“Step-by-Step Guide: Getting Started with Ethereum Mist Wallet”

07.Testing and Deploying Vyper Contracts

08.“Build Your First Ethereum Smart Contract with Solidity — Tutorial”[Generalizing the steps to fit Vyper is fairly straightforward]

Vyper’s development steps to version 1.0 focus on interfaces (as well as improvements in internal and external calls, among others), which define constraints so you can communicate with any object implementing that interface. Interfaces enable alternative solutions to upgrading Smart Contracts, so they’re not necessary for basic functions, and you can begin coding in Vyper although the language is incomplete.

 

The development roadmap to version 1.0, retrieved and edited from Vyper’s gitter:

01.Two types of files: interfaces (one interface per file) and contracts (one contract

per file).

02. You can define an interface like ERC721Metadata in an interface file and also in

a contract file.

03. The interface file is one-to-one fully compatible with the Ethereum ABI.

04. Write a translator from Solidity to Vyper interfaces.

05. Make a library of all the final ERC interfaces, even if you have to manually make

them.

06.Import interfaces from the interface files to contracts.

07. An interface is a type which decorates an address.

08. Interfaces can inherit other interfaces.

09. Carefully study interface IDs from ERC-165 and reproduce the examples given in

ERC-721 this relates to how interfaces inherit other interfaces.

10. Interfaces may have optional functions. (A break from solidity.)

11. Contracts can implement interfaces.

12. A contract that implements an interface but does not implement a required

function is an ERROR.

13. A contract that implements an interface but does not implement an optional

function is neither an ERROR nor a WARNING.

14. Rename @public to @external to match Solidity.

15. Introduce a new function decorator @internal which allows a function to be called

internally.

16. Reintroduce the function call syntax currently used for external calls (removed in

step 14) but have it apply to internal calls.

17.Implement external calls like this: External jump call table -> LOADCALLDATA

unpack -> add function parameters to stack -> call internal function -> do function

stuff.

18. Implement internal calls like this: add function parameters to stack -> call internal

function -> do the function stuff.

As you can see from the code we’ve written, Vyper is making big strides in its development, and has just a few major updates (broken into the smaller steps above) until 1.0 is released!