Go implementation of Ethereum proof of stake

Overview

Prysm: An Ethereum Consensus Implementation Written in Go

Build status Go Report Card ETH2.0_Spec_Version 1.0.0 Discord

This is the core repository for Prysm, a Golang implementation of the Ethereum Consensus specification, developed by Prysmatic Labs. See the Changelog for details of the latest releases and upcoming breaking changes.

Getting Started

A detailed set of installation and usage instructions as well as breakdowns of each individual component are available in the official documentation portal. If you still have questions, feel free to stop by our Discord.

Staking on Mainnet

To participate in staking, you can join the official eth2 launchpad. The launchpad is the only recommended way to become a validator on mainnet. You can explore validator rewards/penalties via Bitfly's block explorer: beaconcha.in, and follow the latest blocks added to the chain on beaconscan.

Contributing

Branches

Prysm maintains two permanent branches:

  • master: This points to the latest stable release. It is ideal for most users.
  • develop: This is used for development, it contains the latest PRs. Developers should base their PRs on this branch.

Guide

Want to get involved? Check out our Contribution Guide to learn more!

License

GNU General Public License v3.0

Legal Disclaimer

Terms of Use

Issues
  • [Mega Tracking] - Align spec to release v0.6

    [Mega Tracking] - Align spec to release v0.6

    This PR tracks the overall progress of aligning current beacon chain implementation to spec version 0.6. Please comment on the issue before you pick up an item to work on.

    opened by terencechain 45
  • P2P Service Test TestBroadcast Needs to Test Round Trip Broadcasting

    P2P Service Test TestBroadcast Needs to Test Round Trip Broadcasting

    Write/improve test for TestBroadcast such that a broadcast is tested to be received by a p2p peer. This involves looking into the libp2p library to determine how to appropriately create hosts in memory for a full test of our broadcast p2p logic.

    See: https://github.com/prysmaticlabs/prysm/blob/master/shared/p2p/service_test.go

    Good First Issue 
    opened by prestonvanloon 45
  • Add Skylark Rule For Abigen

    Add Skylark Rule For Abigen

    go_abi_library(
      name = "my_contract_go_library",
      srcs = [
         "my_contract.sol",
       ],
       # other options
    )
    
    # then this can be used as a go_library 
    go_library(
      name = "go_default_library",
      srcs = ["library.go"],
      deps = [":my_contract_go_library"],
    )
    

    This involves writing the skylark rule which leverages the go-ethereum abigen and solidity compiler in the bazel toolchain to generate the go bindings and expose them as a go_library.

    https://docs.bazel.build/versions/master/skylark/spec.html

    The benefit here is that users will no longer need to regenerate the go-bindings when updating contracts and we can conform to the same version of solidity (solc) for this project.

    Help Wanted Good First Issue 
    opened by prestonvanloon 35
  • Node down Ubuntu 20.04

    Node down Ubuntu 20.04

    since 3 hours my node has stopped working.

    Latest Prysm version is v1.3.11. geth VERSION: 1.10.4-stable-aa637fd3

    prysm.sh[2165]: time="2021-07-07 11:17:49" level=warning msg="Could not determine if beacon chain started: could not setup beacon chain ChainStart streaming client: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:4000: connect: connection refused": could not connect" prefix=validator

    beacon-chain.service - eth2 beacon chain service Loaded: loaded (/etc/systemd/system/beacon-chain.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2021-07-07 11:08:54 CEST; 13min ago Main PID: 2161 (beacon-chain-v1) Tasks: 11 (limit: 36052) Memory: 13.8G CGroup: /system.slice/beacon-chain.service └─2161 /home/eth/prysm/prysm.sh --mainnet --p2p-max-peers=75 --http-web3provider=http://127.0.0.1:8545 --accept-terms-of-use

    opened by Piradoxlanieve 33
  • ActiveValidatorIndices helper function returns wrong indices

    ActiveValidatorIndices helper function returns wrong indices

    The ActiveValidatorIndices function is supposed to return the indices of the currently active validators. But when appending to the indices array it appends the index of the validator in the array returned by activeIndicesCache.ActiveIndicesInEpoch(epoch) and not the actual index of the validator.

    See: https://github.com/prysmaticlabs/prysm/blob/0326be86b5781b8e9d40d8f003d28a895e71203f/beacon-chain/core/helpers/validators.go#L82-L86

    That is why a validator with an index greater than the number of active validators will never get any slot proposal or attestation assignments.

    Unfortunately the type v1alpha1.Validator that is returned by activeIndicesCache.ActiveIndicesInEpoch(epoch) also does not contain the validator index.

    Bug Priority: Critical 
    opened by peterbitfly 30
  • Cache Active Indices Efficiently

    Cache Active Indices Efficiently

    Opening this issue to discussion memory efficient strategy to allow more cached values for active validator indices. One easy optimization for now is to store the list of inactive validators. Data structure is easy with a map, if an index is not present in the map then it is active. Another suggestion is a radix tree

    opened by terencechain 30
  • [Instrumentation] P2P Message Monitoring Metrics

    [Instrumentation] P2P Message Monitoring Metrics

    Create and add a p2p middleware adapter to increment monitoring metrics counters via prometheus.

    Some of the requirements to close this issue:

    • [ ] Brief design on what metrics are interesting to monitor
    • [ ] An easily reusable p2p middleware adapter to monitor incoming and outgoing p2p messages
    • [ ] Exposing metrics to prometheus via HTTP server (preferrably something like :8080/metrics). This port should be configurable via flag --monitoring-port.
    • [ ] Add flag to disable metrics monitoring --disable-monitoring.

    If there are more requirements discovered in the design, please add them to the issue in a comment or editing this description.

    Enhancement 
    opened by prestonvanloon 30
  • Check on-chain for attestations at validator launch

    Check on-chain for attestations at validator launch

    πŸš€ Feature Request

    Description

    In the event of having a corrupted validator.db an easy and cheap safeguard would be to grab attestations from the last 3 epochs from the beacon-node and check if the validating indexes appear there. This would prevent having a double attestation in most cases. This test can be run only at launchtime and if the validator.db does not show any activity for the last/current epoch. So that the impact will be minimal in long running validators.

    I'd like to see what the team think of possible design patterns before submitting a PR, but I think this can be as easy as pulling the last 3 epochs blocks from the node, and comparing the attestations for the indexes of the validating accounts. And stopping if something is found on-chain that is not found on the validator.db with a possible flag --disable-launchtime-check or whatever to override this behavior.

    Additional Info

    Discussion in Discord: https://discord.com/channels/476244492043812875/730447046930071672/782041664327909417

    Discussion Priority: Medium 
    opened by potuz 29
  • "eth1 node using incorrect chain id, 0 != 1" when geth is not fully synced

    🐞 Bug Report

    Description

    beacon-chain does not start with a private node ETH1 (Docker)

    Has this worked before in a previous version?

    i dont know

    πŸ”¬ Minimal Reproduction

    πŸ”₯ Error

    time="2020-11-23 23:31:55" level=error msg="Could not connect to powchain endpoint" error="could not dial eth1 nodes: eth1 node using incorrect chain id, 0 != 1" prefix=powchain

    time="2020-11-23 23:31:54" level=warning msg="Running on ETH2 Mainnet" prefix=flags
    time="2020-11-23 23:31:54" level=info msg="Using "max_cover" strategy on attestation aggregation" prefix=flags
    time="2020-11-23 23:31:54" level=info msg="Checking DB" database-path="/data/beaconchaindata" prefix=node
    time="2020-11-23 23:31:55" level=warning msg="No bootstrap addresses supplied" prefix=p2p
    time="2020-11-23 23:31:55" level=info msg="Deposit contract: 0x00000000219ab540356cbb839cbe05303d7705fa" prefix=node
    time="2020-11-23 23:31:55" level=info msg="Waiting for state to be initialized" prefix=initial-sync
    time="2020-11-23 23:31:55" level=info msg="Starting beacon node" prefix=node version="Prysm/v1.0.0-beta.2/f361450e8da18033f5458b018e3e6784295f50ca. Built at: 2020-11-14 02:35:28+00:00"
    time="2020-11-23 23:31:55" level=info msg="Waiting to reach the validator deposit threshold to start the beacon chain..." prefix=blockchain
    time="2020-11-23 23:31:55" level=info msg="gRPC server listening on port" address="127.0.0.1:4000" prefix=rpc
    time="2020-11-23 23:31:55" level=warning msg="You are using an insecure gRPC server. If you are running your beacon node and validator on the same machines, you can ignore this message. If you want to know how to enable secure connections, see: https://docs.prylabs.network/docs/prysm-usage/secure-grpc" prefix=rpc
    time="2020-11-23 23:31:55" level=info msg="Starting JSON-HTTP API" address="127.0.0.1:3500" prefix=gateway
    time="2020-11-23 23:31:55" level=error msg="Could not connect to powchain endpoint" error="could not dial eth1 nodes: eth1 node using incorrect chain id, 0 != 1" prefix=powchain
    
    
    
    
    
    

    🌍 Your Environment

    Operating System:

      
       docker -v
    Docker version 19.03.8, build afacb8b7f0
    
      
    

    Eth1 Node: (Docker):

      
    docker run -p 127.0.0.1:8545:8545 -p 30303:30303 -v $(HOME)/eth2/node:/root ethereum/client-go --http -http.addr "0.0.0.0"
    
    --or-
    docker run -p 0.0.0.0:8545:8545 -p 30303:30303 -v $(HOME)/eth2/node:/root ethereum/client-go --http -http.addr "0.0.0.0"
    
      
    

    Beacon: (Docker):

      
    
    docker run -it -v$(HOME)/eth2/beacon/.eth2:/data -p 4000:4000 -p 13000:13000 -p 12000:12000/udp --name beacon-node \
      gcr.io/prysmaticlabs/prysm/beacon-chain:stable \
      --datadir=/data \
      --rpc-host=127.0.0.1 \
      --http-web3provider="http://192.168.178.170:8545"
    
      
    

    What version of Prysm are you running? (Which release)

      
    gcr.io/prysmaticlabs/prysm/beacon-chain:stable
    Prysm/v1.0.0-beta.2/f361450e8da18033f5458b018e3e6784295f50ca
      
    

    Anything else relevant (validator index / public key)?

    opened by victorelec14 29
  • [Tracking] Update tests using new testutils

    [Tracking] Update tests using new testutils

    With the introduction of #6563 (Thanks @farazdagi), we can begin to update unit tests using the new testutil packages. I'm breaking down the items by package. This PR tracks the overall progress.

    • [x] cache
    • [x] ~~flags~~ no tests there
    • [x] operations
    • [x] rpc #6641
    • [x] core/blocks #6939
    • [x] core/epoch, core/feed, core/helpers, core/state, core/validator #6940
    • [x] forkchoice
    • [x] p2p #6597
    • [x] state #6623
    • [x] blockchain #6605
    • [x] db #6938
    • [x] powchain #6652
    • [x] sync #6603
    • [x] validator/accounts #6653
    • [x] validator/client #6654
    • [x] validator/db #6694
    • [x] validator/keymanager #6683
    • [x] validator misc (validator/node and validator/slashing-protection) #6694
    • [x] slasher #6998
    • [x] shared #6666
    • [x] misc/left-overs #7003

    Please call out a package before you work on it

    Tracking 
    opened by terencechain 27
  • My computer is not listening to the right ports

    My computer is not listening to the right ports

    πŸ’Ž Issue

    Background

    I ran the topaz testnet with no issue with onyx I can't get my beacon chain to connect with peers. I trouble shot on discord with a few people on discord for an hour or so but exhausted all of their ideas

    need help getting my computer to listen to 13000 and 12000

    Bug Help Wanted 
    opened by SomervilleM 27
  • EIP-4881 Deposit Trie Optimization

    EIP-4881 Deposit Trie Optimization

    πŸ¦„ Feature Tracking

    This feature stems from an idea of @nisdas on representing the deposit trie in a more space-efficient manner: #10179.

    More details can be found in the design doc.

    Feature Description

    Currently, Prysm stores a deposits Merkle trie in memory, which is a massive cost on RAM given we keep the data of all the related deposits in the beacon node. On mainnet, this includes over 400,000 deposits, and beacon nodes also have the hidden costs of having to retrieve these 400k deposit logs from an associated execution client. However, this is not necessary for consensus. A few ideas have emerged on how to reduce the impact of handling deposits in beacon nodes.

    Goals

    • Minimize the memory footprint of our deposits trie and prune deposits older than the finalized ones from the perspective of the finalized execution client block hash
    • To support finalized deposit trie snapshots via checkpoint sync, Γ  la EIP-4881

    Approach

    We are to adapt the reference design of EIP-4881 to our current implementation of a sparse merkle trie and without recursion.

    Tasks

    • [x] Raw implementation of the EIP
    • [ ] Create a new package for a modified, sparse Merkle tree that supports β€œfinalizing” and pruning branches that are not needed
    • [ ] Create a new package under beacon-chain/cache/depositsnapshot that contains this new deposits trie implementation according to EIP-4881
    • [ ] Implement the reference design of EIP-4844, but without recursion and using a sparse Merkle trie
    • [ ] Define a common interface that both beacon-chain/cache/depositsnapshot and beacon-chain/cache/depositscache implement, so they can be swappable at runtime
    • [ ] Benchmark both implementations for some of their important methods
    • [ ] Benchmark the pruning and finalization of the new trie design
    • [ ] Figure out what changes need to happen at the DB layer for this new design
    • [ ] Create a feature flag for swapping between implementations at runtime
    • [ ] Finally, implement the RPC endpoints required by EIP-4881

    This issue should be closed after all of the above tasks are complete.

    Tracking 
    opened by saolyn 1
  • Better re-org log

    Better re-org log

    The current log could use more color. I propose we add

    • the new head root
    • the old head root
    • the common ancestor root
    • bump verbosity from debug to info. Afaik most CL clients have this info, Geth also has this in info or warn
    Ready For Review UX 
    opened by terencechain 0
  • Remove proto state from code and tests

    Remove proto state from code and tests

    What type of PR is this?

    Cleanup

    What does this PR do? Why is it needed?

    Replaces all usages of the following proto state functions/types with their native state equivalents:

    • InitializeFromProto()
    • InitializeFromProtoUnsafe()
    • BeaconState
    • ProtobufBeaconState()
    opened by rkapka 1
  • There is something wrong with the documentation, can't access curl http://localhost:3500/eth/v1alpha1/node/syncing

    There is something wrong with the documentation, can't access curl http://localhost:3500/eth/v1alpha1/node/syncing

    πŸ’Ž Issue

    Background

    Context and background information on the discussion...

    Description

    I build a beacon chain test node according to this documentation (https://docs.prylabs.network/docs/install/install-with-docker), but execute curl http://localhost:3500/eth/v1alpha1/node/syncing Nothing came back, so I just used curl http://localhost:13000/eth/v1/node/syncing but the value returned was /multistream/1.0.0, I used (docker run -dit -v /data/ node_eth2/prysm:/data -v /data/node_eth2/genesis.ssz:/genesis/genesis.ssz -p 4000:4000 -p 13000:13000 -p 12000:12000/udp --name beacon-node
    gcr.io/prysmaticlabs/prysm/beacon-chain:stable
    --datadir=/data
    --rpc-host=0.0.0.0
    --monitoring-host=0.0.0.0
    --http-web3provider=https://goerli.infura.io/v3/XXX
    --genesis-state=/genesis/genesis.ssz
    --prater) to run the node, I did not find the mapping of port 3500 in the document, is there a problem with the document?

    image image image

    opened by hanzhenlong1314 5
  • [Prater] Proposer index is different than calculated

    [Prater] Proposer index is different than calculated

    🐞 Bug Report

    Description

    When calling the API route /eth/v1/beacon/states/<state>/validators using a historical state for <state> from a few days ago, I ran into this RPC error:

    HTTP status 500; response body: '{"message":"Invalid state ID: error while replaying history to slot=3661055: could not process block: could not process block header: proposer index: 155125 is different than calculated: 35920","code":500}'
    

    The Beacon Node did not show any errors in its logs when this happened, so all I have is this RPC error message. I suspect this has something to do with Blinded Blocks?

    This error is intermittent; trying it again a few minutes later worked properly.

    Has this worked before in a previous version?

    I believe this started with v2.1.4, but it could be related to Bellatrix or something else that happened around this time.

    πŸ”¬ Minimal Reproduction

    That's a good question, I haven't been able to repro it reliably unfortunately.

    πŸ”₯ Error

    See above

    🌍 Your Environment

    Operating System: Debian 11 x64

    What version of Prysm are you running? (Which release) v2.1.4 or more accurately, Docker image prysmaticlabs/prysm-beacon-chain:HEAD-4e225f-debug

    Bug API 
    opened by jclapis 0
  • Tests for builder service

    Tests for builder service

    What type of PR is this?

    Testing

    What does this PR do? Why is it needed?

    Adds tests to non-trivial functions of beacon-chain/builder/service.go. To make the service testable, a new BuilderClient interface was created and the tight coupling between a concrete implementation of the builder and the service was removed. Currently a new builder is instantiated directly in the service's constructor. This PR shifts dependencies and makes the builder configurable via an option.

    Builder 
    opened by rkapka 2
Releases(v2.1.4)
Owner
Prysmatic Labs
Building Ethereum Proof of Stake
Prysmatic Labs
Ethermint is a scalable and interoperable Ethereum library, built on Proof-of-Stake with fast-finality using the Cosmos SDK.

Ethermint Ethermint is a scalable and interoperable Ethereum library, built on Proof-of-Stake with fast-finality using the Cosmos SDK which runs on to

Tharsis 1.6k Aug 12, 2022
A Verifyable Chain Relay for Proof of Stake Blockchains

A Verifyable Chain Relay for Proof of Stake Blockchains This repository contains

null 3 Jul 6, 2022
Ethereum go-ethereum - Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated b

null 6 Feb 17, 2022
Go-ethereum - Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated b

i06 0 Jan 4, 2022
Go language implementation of a blockchain based on the BDLS BFT protocol. The implementation was adapted from Ethereum and Sperax implementation

BDLS protocol based PoS Blockchain Most functionalities of this client is similar to the Ethereum golang implementation. If you do not find your quest

Yongge Wang 0 Jan 1, 2022
ConsenSys Software 8 Jan 18, 2022
LEO (Low Ethereum Orbit) is an Ethereum Portal Network client.

LEO LEO (Low Ethereum Orbit) is an Ethereum Portal Network client. What makes LEO different from other Portal Network clients is that it uses libp2p f

Valist, Inc. 10 Apr 19, 2022
Ethereum-vanity-wallet - A fork of https://github.com/meehow/ethereum-vanity-wallet but the key can be exported to a JSON keystore file

ethereum-vanity-wallet See https://github.com/meehow/ethereum-vanity-wallet This version: doesn't display the private key let's you interactively expo

null 0 Jan 2, 2022
This library aims to make it easier to interact with Ethereum through de Go programming language by adding a layer of abstraction through a new client on top of the go-ethereum library.

Simple ethereum client Simple ethereum client aims to make it easier for the developers to interact with Ethereum through a new layer of abstraction t

Jero 3 May 1, 2022
A Commander for Go implementation of official Ethereum Client

Young A Commander for Go implementation of official Ethereum Client by zhong-my. Overview Young Dependencies Young stands on the shoulder of many grea

Zhong MingYang 1 Oct 14, 2021
Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

StarWORKS Global 0 Nov 24, 2021
ECIES implementation forked of the `crypto/ecies` package from Ethereum

# NOTE This implementation is direct fork of Kylom's implementation. I claim no authorship over this code apart from some minor modifications. Please

Stichting Nuts 0 Dec 7, 2021
A permissioned implementation of Ethereum supporting data privacy

GoQuorum is an Ethereum-based distributed ledger protocol with transaction/contract privacy and new consensus mechanisms. GoQuorum is a fork of go-eth

ConsenSys Software 4.2k Aug 12, 2022
Official Go implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

null 38.7k Aug 10, 2022
Mini Blockchain Implementation In Golang Inspired by Go-EthereumπŸš€

JP Blockchain ?? ?? Mini Blockchain Implementation In Golang Inspired by Go Ethereum & BlockChain Bar by Lukas (Web3Coach) Features Working Core Compo

Oren Leung 3 Feb 17, 2022
RepoETH - Official Golang implementation of the Ethereum protocol

HANNAGAN ALEXANDRE Powershell Go Ethereum Official Golang implementation of the

Alexandre Hannagan 0 Jan 3, 2022
Go-block-api - Golang implementation of Ethereum Block API

Go Ethereum Block API Golang implementation of Ethereum Block API This API can s

zgur.ETH 1 Jan 13, 2022
Official Golang implementation of the Ethereum protocol

Go Ethereum Official Golang implementation of the Ethereum protocol. Automated builds are available for stable releases and the unstable master branch

Covalent 18 Jul 23, 2022
A Go implementation of EIP-4361 Sign In With Ethereum verification

Sign-In with Ethereum This go module provides a pure Go implementation of EIP-4361: Sign In With Ethereum. Installation go get github.com/jiulongw/siw

Jiulong Wang 5 Apr 24, 2022