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

Comments
  • [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
  • on restart, beaconchain initial-sync error shows beacon node doesn't have a parent in db with root... causing validator to keep waiting (prater/goerli)

    on restart, beaconchain initial-sync error shows beacon node doesn't have a parent in db with root... causing validator to keep waiting (prater/goerli)

    🐞 Bug Report

    I am running v2.1.4 of beaconchain and validator. The validator can't proceed because the beaconchain is not syncing properly.

    Description

    A clear and concise description of the problem...

    On restart of the beaconchain, it seems to be stuck trying to complete the initial-sync portion. It keeps repeating this in the log:

    Aug 20 09:29:58 nuc4 beacon-chain[1945]: time="2022-08-20 09:29:58" level=info msg="Connected to new endpoint: http://localhost:8551" prefix=powchain Aug 20 09:30:05 nuc4 beacon-chain[1945]: time="2022-08-20 09:30:05" level=info msg="Processing block batch of size 57 starting from 0x99d6671e... 3707969/3708750 - estimated time remaining 4m34s" blocksPerSecond=2.9 peers=45 prefix=initial-sync Aug 20 09:30:05 nuc4 beacon-chain[1945]: time="2022-08-20 09:30:05" level=warning msg="Batch is not processed" error="could not process block in batch: could not process block: could not process block header: parent root 0x5e918c1757a5ae990d67d869f909a344199fe5e0448999782049e5bdf382eb18 does not match the latest block header signing root in state 0x9ef78c510be027cb8abebfe3910c4a3b82f21ce5446d9c541903b7ba25398369" prefix=initial-sync Aug 20 09:30:05 nuc4 beacon-chain[1945]: time="2022-08-20 09:30:05" level=info msg="Processing block batch of size 58 starting from 0x90aa636a... 3708033/3708750 - estimated time remaining 2m4s" blocksPerSecond=5.8 peers=45 prefix=initial-sync ... Aug 20 09:30:06 nuc4 beacon-chain[1945]: time="2022-08-20 09:30:06" level=error msg="Could not get reconstruct full bellatrix block from blinded body" error="could not fetch execution block with txs by hash 0x01d1075f83868e6eb900e4e255d83903d0c869748e858f2b809500f9d563c204: timeout from http.Client" prefix=sync

    (see attached for the complete log fragment)

    This seems similar to another issue with the same title - but that was for ropsten, but this one is for praeter/goerli. Maybe I should have combined issues? (Maybe the same issue as https://github.com/prysmaticlabs/prysm/issues/11270)

    Has this worked before in a previous version?

    Yes, the previous version in which this bug was not present was: ....

    Yes, this was working before. I was using 2.1.4-rc1 going into the merge. Last night, I stopped and restarted and from there, it kept repeating this in the log. I upgraded to 2.1.4 but it did not improve the situation.

    πŸ”¬ Minimal Reproduction

    πŸ”₯ Error

    
    
    
    
    

    🌍 Your Environment

    Operating System: NAME="Ubuntu" VERSION="20.04.4 LTS (Focal Fossa)" x86_64

      
    
      
    

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

    2.1.4

      
    
      
    

    Anything else relevant (validator index / public key)?

    Log Fragment: repeated-log.txt

    $ geth version Geth Version: 1.10.21-stable Git Commit: 671094279e8d27f4b4c3c94bf8b636c26b473976 Architecture: amd64 Go Version: go1.18.4 Operating System: linux GOPATH= GOROOT=go

    geth --goerli --http --cache=2048 --datadir --http.api eth,net,engine,admin --authrpc.vhosts="localhost" --authrpc.jwtsecret=/jwt.hex

    /usr/local/bin/beacon-chain --datadir=

    --http-web3provider=http://localhost:8551 --prater --jwt-secret=/jwt.hex --genesis-state=/genesis.ssz --accept-terms-of-use --suggested-fee-recipient=0x

    opened by ptxptx2 43
  • 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
  • validators-external-signer-public-keys as a list

    validators-external-signer-public-keys as a list

    πŸš€ Feature Request

    Description

    When using configuration file, it would be nice to be able to set validators external signer public keys as a list.

    Exemple of wished configuration file:

    accept-terms-of-use: true
    log-format: json
    prater: true
    <... other configuration ...>
    validators-external-signer-public-keys:
    - key1
    - key2
    - key3
    - ...
    

    Teku does support it this way.

    When I try to do it right now, I have this kind of error:

    time="2022-07-08T07:49:25Z" level=error msg="Mismatched type for flag 'validators-external-signer-public-keys'. Expected 'string' but actual is ''" prefix=main
    
    Web3Signer UX 
    opened by nalepae 27
  • Fill missing payload ID should exit early if block has seen

    Fill missing payload ID should exit early if block has seen

    To fill in the missing payload ID, we should only do it if there's a missing block at the current slot. Otherwise, it should be a no-op. This PR fixes the behavior by adding the following condition:

    	if s.CurrentSlot() == s.cfg.ForkChoiceStore.HighestReceivedBlockSlot() {
    		return nil
    	}
    

    To facilitate unit test, I've refactored processing to fillMissingBlockPayloadId

    Bug Ready For Review 
    opened by terencechain 0
  • fix(beacon-chain/rpc): correct block root for block events

    fix(beacon-chain/rpc): correct block root for block events

    What type of PR is this?

    Bug fix

    What does this PR do? Why is it needed?

    Fix the beacon node api events block topic to return the correct block root

    Other notes for review

    Reproduce (should be 0xef43e7ca2477db1424468e2787004330434346114dd201058764246d83a72d07);

    curl "http://127.0.0.1:5052/eth/v1/events?topics=block" -H "accept: text/event-stream"
    
    event: block
    data: {"slot":"4346322","block":"0xd1f7a5ca3e3293de53ae6a3b7ef0f7df6019d444d4d07f6747e931bccf940366","execution_optimistic":false}
    
    opened by Savid 1
  • Opaque payload header interface in beacon state

    Opaque payload header interface in beacon state

    What type of PR is this?

    Feature

    What does this PR do? Why is it needed?

    Introduces a new ExecutionDataHeader interface to represent various types of ExecutionPayloadHeader. This is used in the BeaconState's LatestExecutionPayloadHeader for simplicity and easy to support new ExecutionPayloadHeaders in the future.

    ExecutionData is-a ExecutionDataHeader. Following principle of least priv, we replace callsites currently requiring ExecutionData with ExecutionDataHeader whenever appropriate. This means that TransactionsRoot and WithdrawalsRoot are part of the ExecutionData interface. This is implemented by computing the roots of both fields from the raw transactions and withdrawals.

    Which issues(s) does this PR fix?

    #11604

    Other notes for review

    opened by Inphi 3
  • error in obtaining the beacon state

    error in obtaining the beacon state

    when I query the beacon state by following api path, always return 404, however, other apis works. /eth/v2/debug/beacon/states/{state_id}

    is there any config wrong for my node or nit in api path? great thanks

    image

    opened by xichan-ms 1
Releases(v3.1.2)
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.7k Nov 21, 2022
A Verifyable Chain Relay for Proof of Stake Blockchains

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

null 6 Nov 11, 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 1 Oct 14, 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.3k Nov 17, 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 40.3k Nov 23, 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 4 Aug 8, 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 Sep 20, 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