All Projects → ralexstokes → deposit-verifier

ralexstokes / deposit-verifier

Licence: Unlicense License
A smart contract to enhance the user experience of the `eth2` deposit contract.

Programming Languages

python
139335 projects - #7 most used programming language
solidity
1140 projects
Makefile
30231 projects

Projects that are alternatives of or similar to deposit-verifier

go-kzg
FFT, data-recovery and KZG commitments, a.k.a. Kate commitments, in Go - *super experimental*
Stars: ✭ 34 (+142.86%)
Mutual labels:  eth2
BeaconChain.swift
Swift implementation of Ethereum 2.0 beacon chain
Stars: ✭ 41 (+192.86%)
Mutual labels:  eth2
ethereumapis
A collection of public Ethereum APIs.
Stars: ✭ 70 (+400%)
Mutual labels:  eth2
ethmerge.com-content
Markdown formatted content for the ethmerge.com website.
Stars: ✭ 29 (+107.14%)
Mutual labels:  eth2
beacon-APIs
Collection of RESTful APIs provided by Ethereum Beacon nodes
Stars: ✭ 209 (+1392.86%)
Mutual labels:  eth2
prysm-grafana-dashboard
Guide step to step to get a Prysm dashboard using Grafana and Prometheus with mobile alerts
Stars: ✭ 57 (+307.14%)
Mutual labels:  eth2
e7mon
Ethereum clients monitor
Stars: ✭ 30 (+114.29%)
Mutual labels:  eth2
idex-contracts-whistler
IDEX 2.0 smart contracts
Stars: ✭ 43 (+207.14%)
Mutual labels:  eth2
scout
Scout is a Ethereum 2.0 Phase 2 execution prototyping engine.
Stars: ✭ 81 (+478.57%)
Mutual labels:  eth2

deposit-verifier

A smart contract to enhance the user experience of the eth2 deposit contract.

Exposes functionality on-chain to verify different parts of an eth2 deposit intended for the beacon chain.

Includes a "proxy" deposit function that will run the verification logic on-chain and only upon success forward the deposit to the actual deposit contract.

NOTICE

This smart contract has not been tested, audited or formally verified. It should be considered pre-alpha. USE AT YOUR OWN RISK.

What is this?

Validators of the eth2 network join by making a deposit to a smart contract called the deposit contract. This contract makes a cryptographic committment to the validator which can then be consumed on the eth2 network. Importantly, a given deposit has an associated amount of ETH attached meant to move to the validator on the eth2 network. This deposit is "one-way" for the time being in that any ETH sent to the deposit contract is not recoverable. Given that ETH sent to the deposit contract is not recoverable, any deposit accepted by the deposit contract but that is later found to be invalid by the eth2 network results in a permanent loss of ETH. Refer to the eth2-specs for more information.

One part of making a valid deposit is the inclusion of a valid signature according to the eth2 signature scheme BLS. In an attempt to keep the deposit contract minimal (and therefore easier to get correct), the verification of the BLS signature is omitted. Moreover, the efficient verification of this signature requires precompiles that are scheduled for the eth1 Berlin hardfork but are not currently available on mainnet and were not when the deposit contract was written.

This "verifying proxy" contract wraps the deposit contract, requiring a valid BLS signature before proceeding to make a call to the deposit function on the deposit contract. This proxy contract enhances the usability of the deposit contract by reducing the chance a potential validator will make a bad deposit resulting in lost ETH.

Installation

The deposit contract is maintained as a git submodule of this repo. To pull down the full repo:

$ git clone --recurse-submodules $REMOTE_ADDRESS

where $REMOTE_ADDRESS is the address of this github repo.

If you have already cloned this repo, you should be able to manually fetch the submodule:

$ git submodule init
$ git submodule update

How to compile the contract

With a sufficient version of the Solidity compiler (refer to the contract's pragma solidity), you can run:

$ make compile

to generate the ABI definition and the hex-encoded EVM bytecode.

These artifacts (along with the corresponding assets for the deposit contract) are included in this repo for convenience.

How to run the tests

Installation

The project uses a Python stack for unit tests. It is suggested to use pipenv (https://pipenv.pypa.io/en/latest/) to manage dependencies.

Once pipenv is installed:

$ pipenv --python $PATH_TO_PY_38 shell
# once inside the virtualenv
$ pipenv install

Testing

Once all of the dependencies are installed, you can use pytest (inside the virtualenv you have created). The -n auto flag will attempt to parallelize the test runs.

$ pytest -n auto tests
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].