Skip to content
Pythonic Smart Contract Language for the EVM
Python Other
  1. Python 99.6%
  2. Other 0.4%
Branch: master
Clone or download
fubuloubu Merge pull request #1576 from iamdefinitelyahuman/entry_points
Move bin to vyper/cli, use entry_points
Latest commit 0b7b9b7 Aug 19, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.circleci Whitespace Mar 13, 2019
.github Don't know why it was like this Feb 7, 2019
.snapcraft Add missing deploy section for travis/snap Apr 19, 2018
docs Add release notes for beta.11 Jul 23, 2019
examples Merge pull request #1497 from matnad/master Jun 27, 2019
logo [ImgBot] optimizes images Sep 23, 2018
scripts Merge master. Mar 11, 2019
snap Merge pull request #1546 from ethereum/fubuloubu/snapcraft-bumpversion Jul 24, 2019
tests increase test deadline to 1 second Aug 9, 2019
vyper fixes per @fubuloubu review Aug 19, 2019
.bumpversion.cfg build: Update bumpversion rules to keep snapcraft config in sync Jul 24, 2019
.coveralls.yml Revert some coveralls config updates Mar 16, 2019
.gitattributes Add .gitattributes file Jan 8, 2018
.gitignore doc: Added snap build process to Makefile Jul 24, 2019
Dockerfile Install test dependencies as well when building the image, to be able… Aug 30, 2018
LICENSE lay an egg Nov 13, 2016
MANIFEST.in Add MANIFEST.in support for producing nice clean git sha1 commit hash. Jul 23, 2019
Makefile doc: Added snap build process to Makefile Jul 24, 2019
README.md die gitter Jul 24, 2019
SECURITY.md docs: Bad link for Uniswap Jul 23, 2019
make.cmd Added new commands to make.cmd: dev-deps, lint, docs, clean (all 4 cmds) Jun 26, 2019
requirements-docs.txt create viper docs skeleton Sep 1, 2017
setup.cfg Add hypothesis. Mar 18, 2019
setup.py update tox.ini and setup.py Aug 19, 2019
tox.ini fixes per @fubuloubu review Aug 19, 2019
upload_coverage.sh Revert some coveralls config updates Mar 16, 2019

README.md

Build Status Documentation Status Coverage Status PyPI Docker Snapcraft Join the chat at https://gitter.im/ethereum/vyper

Getting Started

See Installing Vyper to install vyper.
See Tools and Resources for an additional list of framework and tools with vyper support.

Principles and Goals

Vyper is a smart contract development language built with the following 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.

Some examples of what Vyper does NOT have and why:

  • Modifiers - e.g. in Solidity you can do function foo() mod1 { ... }, where mod1 can be defined elsewhere in the code to include a check that is done before execution, a check that is done after execution, some state changes, or possibly other things. Vyper does not have this, because it makes it too easy to write misleading code. mod1 just looks too innocuous for something that could add arbitrary pre-conditions, post-conditions or state changes. Also, it encourages people to write code where the execution jumps around the file, harming auditability. The usual use case for a modifier is something that performs a single check before the execution of a program; our recommendation is to simply inline these checks as asserts.
  • Class inheritance - requires people to jump between multiple files to understand what a program is doing, and requires people to understand the rules of precedence in case of conflicts (which class' function X is the one that's actually used?). Hence, it makes the code too complicated to understand.
  • Inline assembly - adding inline assembly would make it no longer possible to Ctrl+F for a variable name to find all instances where that variable is read or modified.
  • Function overloading - This can cause lots of confusion on which function is called at any given time. Thus it's easier to write misleading code (foo("hello") logs "hello" but foo("hello", "world") steals your funds). Another problem with function overloading is that it makes the code much harder to search through as you have to keep track on which call refers to which function.
  • Operator overloading - way too easy to write misleading code (what do you mean "+" means "send all my money to the developer"? I didn't catch the part of the code that says that!).
  • Recursive calling - cannot set an upper bound on gas limits, opening the door for gas limit attacks.
  • Infinite-length loops - cannot set an upper bound on gas limits, opening the door for gas limit attacks.
  • Binary fixed point - decimal fixed point is better, because any decimal fixed point value written as a literal in code has an exact representation, whereas with binary fixed point approximations are often required (e.g. 0.2 -> 0.001100110011..., which needs to be truncated), leading to unintuitive results, e.g. in python 0.3 + 0.3 + 0.3 + 0.1 != 1.

Some changes that may be considered after Metropolis when STATICCALL becomes available include:

  • Forbidding state changes after non-static calls unless the address being non-statically called is explicitly marked "trusted". This would reduce risk of re-entrancy attacks.
  • Forbidding "inline" non-static calls, e.g. send(some_address, contract.do_something_and_return_a_weivalue()), enforcing clear separation between "call to get a response" and "call to do something".

Vyper does NOT strive to be a 100% replacement for everything that can be done in Solidity; it will deliberately forbid things or make things harder if it deems fit to do so for the goal of increasing security.

Note: Vyper is beta software, use with care

Installation

See the Vyper documentation for build instructions.

Compiling a contract

To compile a contract, use:

vyper your_file_name.vy

Alternative for GitHub syntax highlighting: Add a .gitattributes file with the line *.vy linguist-language=Python

There is also an online compiler available you can use to experiment with the language and compile to bytecode and/or LLL.

Note: While the vyper version of the online compiler is updated on a regular basis it might be a bit behind the latest version found in the master branch of this repository.

Testing (using pytest)

python setup.py test

Contributing

  • See Issues tab, and feel free to submit your own issues
  • Add PRs if you discover a solution to an existing issue
  • For further discussions and questions talk to us on gitter
  • For more information, see Contributing
You can’t perform that action at this time.