A permissioned implementation of Ethereum supporting data privacy

Quorum Slack Build Check Download Docker Pulls

GoQuorum is an Ethereum-based distributed ledger protocol with transaction/contract privacy and new consensus mechanisms.

GoQuorum is a fork of go-ethereum and is updated in line with go-ethereum releases.

Key enhancements over go-ethereum:

  • Privacy - GoQuorum supports private transactions and private contracts through public/private state separation, and utilises peer-to-peer encrypted message exchanges (see Constellation and Tessera) for directed transfer of private data to network participants
  • Alternative Consensus Mechanisms - with no need for POW/POS in a permissioned network, GoQuorum instead offers multiple consensus mechanisms that are more appropriate for consortium chains:
    • Raft-based Consensus - a consensus model for faster blocktimes, transaction finality, and on-demand block creation
    • Istanbul BFT - a PBFT-inspired consensus algorithm with transaction finality, by AMIS.
    • Clique POA Consensus - a default POA consensus algorithm bundled with Go Ethereum.
  • Peer Permissioning - node/peer permissioning, ensuring only known parties can join the network
  • Account Management - GoQuorum introduced account plugins, which allows GoQuorum or clef to be extended with alternative methods of managing accounts including external vaults.
  • Pluggable Architecture - allows adding additional features as plugins to the core geth, providing extensibility, flexibility, and distinct isolation of GoQuorum features.
  • Higher Performance - GoQuorum offers significantly higher performance throughput than public geth

Architecture

GoQuorum Tessera Privacy Flow

The above diagram is very high-level overview of component architecture used by GoQuorum. For more in-depth discussion of the components and how they interact, please refer to lifecycle of a private transaction.

Quickstart

There are several ways to quickly get up and running with GoQuorum. One of the easiest is to use GoQuorum Wizard - a command line tool that allows users to set up a development GoQuorum network on their local machine in less than 2 minutes.

GoQuorum Projects

Check out some of the interesting projects we are actively working on:

Official Docker Containers

The official docker containers can be found under https://hub.docker.com/u/quorumengineering/

Third Party Tools/Libraries

The following GoQuorum-related libraries/applications have been created by Third Parties and as such are not specifically endorsed by J.P. Morgan. A big thanks to the developers for improving the tooling around GoQuorum!

Contributing

GoQuorum is built on open source and we invite you to contribute enhancements. Upon review you will be required to complete a Contributor License Agreement (CLA) before we are able to merge. If you have any questions about the contribution process, please feel free to send an email to [email protected]. Please see the Contributors guide for more information about the process.

Reporting Security Bugs

Security is part of our commitment to our users. At GoQuorum we have a close relationship with the security community, we understand the realm, and encourage security researchers to become part of our mission of building secure reliable software. This section explains how to submit security bugs, and what to expect in return.

All security bugs in GoQuorum and its ecosystem (Tessera, Constellation, Cakeshop, ..etc) should be reported by email to [email protected]. Please use the prefix [security] in your subject. This email is delivered to GoQuorum security team. Your email will be acknowledged, and you'll receive a more detailed response to your email as soon as possible indicating the next steps in handling your report. After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made towards a fix and full announcement.

If you have not received a reply to your email or you have not heard from the security team please contact any team member through GoQuorum slack security channel. Please note that GoQuorum slack channels are public discussion forum. When escalating to this medium, please do not disclose the details of the issue. Simply state that you're trying to reach a member of the security team.

Responsible Disclosure Process

GoQuorum project uses the following responsible disclosure process:

  • Once the security report is received it is assigned a primary handler. This person coordinates the fix and release process.
  • The issue is confirmed and a list of affected software is determined.
  • Code is audited to find any potential similar problems.
  • If it is determined, in consultation with the submitter, that a CVE-ID is required, the primary handler will trigger the process.
  • Fixes are applied to the public repository and a new release is issued.
  • On the date that the fixes are applied, announcements are sent to Quorum-announce.
  • At this point you would be able to disclose publicly your finding.

Note: This process can take some time. Every effort will be made to handle the security bug in as timely a manner as possible, however it's important that we follow the process described above to ensure that disclosures are handled consistently.

Receiving Security Updates

The best way to receive security announcements is to subscribe to the Quorum-announce mailing list/channel. Any messages pertaining to a security issue will be prefixed with [security].

Comments on This Policy If you have any suggestions to improve this policy, please send an email to [email protected] for discussion.

License

The go-ethereum library (i.e. all code outside of the cmd directory) is licensed under the GNU Lesser General Public License v3.0, also included in our repository in the COPYING.LESSER file.

The go-ethereum binaries (i.e. all code inside of the cmd directory) is licensed under the GNU General Public License v3.0, also included in our repository in the COPYING file.

Any project planning to use the crypto/secp256k1 sub-module must use the specific secp256k1 standalone library licensed under 3-clause BSD.

Owner
ConsenSys Software
ConsenSys is the software engineering leader of the blockchain space. Our full-stack Ethereum products help developers build next-generation networks.
ConsenSys Software
Comments
  • Quorum nodes cannot connect to remote bootnode and nodes

    Quorum nodes cannot connect to remote bootnode and nodes

    System information

    Hello, I have problems of remote connection in 7nodes examples

    Geth version: geth version

    I use docker container of quorum here to deploy 7 nodes examples in quorum. https://github.com/agriessel/quorum-docker

    OS & Version: Windows/Linux/OSX Linux Ubuntu 16.04

    Branch, Commit Hash or Release: git status

    Expected behaviour

    When I run 7nodes examples like your guide by putting all 7 nodes and bootnodes in the same container, all is good

    Now,

    • I have run first 3 nodes and bootnodes in the first container, called container 1. Off course, I used docker option -p 33445:33445 when I run this container 1 so that the port 33445 of bootnode in container can be accessible from 33445 of host machine

    • I run 4 last nodes in the second container, called container 2 on another machine or same machine (I tested both) Of course, The bootnodes option in commands point to bootnode_Enode[host_machine_of_container_1]:33445

    I hope that all 7 nodes that can connect

    Actual behaviour

    Only first 3 nodes in the container can connect each other. These 3 nodes connect to bootnode in the same container 1 (that mean bootnodes run in the same machine)

    When I run bootnode in this container 1, I tried all cases below, but none of them work

    nohup bootnode --nodekeyhex "$BOOTNODE_KEYHEX" --addr="0.0.0.0:33445" 2>>qdata/logs/bootnode.log &

    nohup bootnode --nodekeyhex "$BOOTNODE_KEYHEX" --nat "any" --addr="0.0.0.0:33445" 2>>qdata/logs/bootnode.log &

    nohup bootnode --nodekeyhex "$BOOTNODE_KEYHEX" --nat "extip:hostmachineIP" --addr="0.0.0.0:33445" 2>>qdata/logs/bootnode.log &

    nohup bootnode --nodekeyhex "$BOOTNODE_KEYHEX" --nat "any" --addr="172.17.0.2:33445" 2>>qdata/logs/bootnode.log &

    nohup bootnode --nodekeyhex "$BOOTNODE_KEYHEX" --nat "any" --addr="172.17.0.2:33445" 2>>qdata/logs/bootnode.log &

    172.17.0.2 is IP of container 1

    I have already used admin.addPeer in java script console to connect all of them, but I donot want to do it. More over, when I addPeer in this way, I cannot deploy script1.js in 7nodes examples any more When I type this command PRIVATE_CONFIG=tm1.conf geth --exec 'loadScript("script1.js")' attach ipc:qdata/dd1/geth.ipc

    I receive the error: err creating contract Error: Non-200 status code: &{Status:400 Bad Request StatusCode:400 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Date:[Thu, 11 May 2017 12:43:20 GMT] Server:[Warp/3.2.8]] Body:0xc427040300 ContentLength:-1 TransferEncoding:[chunked] Close:false Uncompressed:false Trailer:map[] Request:0xc4246a43c0 TLS:} true

    I must remove privateFor in this script script1.js to be successful

    Steps to reproduce the behaviour

    Thanks for your reponse how to connect to remote quorum nodes and solve the problem of deploying contract

    Backtrace

    [backtrace]
    
  • panic: runtime error: invalid memory address or nil pointer dereference

    panic: runtime error: invalid memory address or nil pointer dereference

    System information

    Geth version: geth version Geth Version: 1.9.25-stable Git Commit: 919800f Quorum Version: 21.10.1 Architecture: amd64 Protocol Versions: [65 64 63] Network Id: 1337 Go Version: go1.15.6 Operating System: linux GOPATH= GOROOT=go

    OS & Version: Windows/Linux/OSX Running on Google CLoud Platform GKE Kubernetes / # cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.14.2 PRETTY_NAME="Alpine Linux v3.14" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://bugs.alpinelinux.org/"

    Expected behaviour

    GoQuorum should gracefully shut down and restart.

    Actual behaviour

    Private state db is corrupted

    INFO [01-13|10:08:51.915] Initialising Ethereum protocol           name=eth     versions="[65 64 63]" network=1000 dbversion=8
    INFO [01-13|10:08:51.915] Initialising Quorum consensus protocol   name=istanbul versions="[100 99 64]" network=1000 dbversion=8
    WARN [01-13|10:08:51.918] DefaultPrivateStateRepository is nil when calling DefaultState 
    WARN [01-13|10:08:51.918] Head private state missing, resetting chain number=30216 hash="caaab9…a70075"
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xc6ecd4]
    
    goroutine 1 [running]:
    github.com/ethereum/go-ethereum/core/types.(*Block).NumberU64(...)
    	github.com/ethereum/go-ethereum/core/types/block.go:348
    github.com/ethereum/go-ethereum/core.(*BlockChain).SetHeadBeyondRoot(0xc000139900, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/core/blockchain.go:687 +0x1f4
    github.com/ethereum/go-ethereum/core.(*BlockChain).SetHead(0xc000139900, 0x0, 0xc0000e8d20, 0x0)
    	github.com/ethereum/go-ethereum/core/blockchain.go:566 +0x45
    github.com/ethereum/go-ethereum/core.(*BlockChain).ResetWithGenesisBlock(0xc000139900, 0xc0000de750, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/core/blockchain.go:838 +0x65
    github.com/ethereum/go-ethereum/core.(*BlockChain).Reset(0xc000139900, 0x1752c84, 0x2b)
    	github.com/ethereum/go-ethereum/core/blockchain.go:831 +0x37
    github.com/ethereum/go-ethereum/core.(*BlockChain).loadLastState(0xc000139900, 0x16de000, 0x0)
    	github.com/ethereum/go-ethereum/core/blockchain.go:518 +0x14ff
    github.com/ethereum/go-ethereum/core.NewBlockChain(0x19d6720, 0xc00042e520, 0xc0004ff260, 0xc00013ef00, 0x19d4ba0, 0xc00014c500, 0x0, 0x0, 0x0, 0x0, ...)
    	github.com/ethereum/go-ethereum/core/blockchain.go:313 +0x9ab
    github.com/ethereum/go-ethereum/eth.New(0xc0003ef1e0, 0xc000348a00, 0x3, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/eth/backend.go:228 +0xd39
    github.com/ethereum/go-ethereum/cmd/utils.RegisterEthService(0xc0003ef1e0, 0xc000348a00, 0x0, 0x3e8, 0x0)
    	github.com/ethereum/go-ethereum/cmd/utils/flags.go:2017 +0xf1
    main.makeFullNode(0xc0005a6840, 0x2549, 0x7, 0xc0006719a0)
    	github.com/ethereum/go-ethereum/cmd/geth/config.go:180 +0x12f
    main.geth(0xc0005a6840, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/cmd/geth/main.go:394 +0xf4
    gopkg.in/urfave/cli%2ev1.HandleAction(0x149ec20, 0x1823898, 0xc0005a6840, 0xc00065d140, 0x0)
    	gopkg.in/urfave/[email protected]/app.go:490 +0x82
    gopkg.in/urfave/cli%2ev1.(*App).Run(0xc0003d5ba0, 0xc000132000, 0x4e, 0x50, 0x0, 0x0)
    	gopkg.in/urfave/[email protected]/app.go:264 +0x5f5
    main.main()
    
    	github.com/ethereum/go-ethereum/cmd/geth/main.go:312 +0x55
    

    Steps to reproduce the behaviour

    Under heavy load with private contracts restart the server

    The issue has been highlighted by investigations from https://github.com/ConsenSys/quorum/issues/1287 into performance.

    Thanks to @frankie-lim-sweeho

  • Alastria Network · Full sync failed · GoQuorum v2.6.0 (and following)

    Alastria Network · Full sync failed · GoQuorum v2.6.0 (and following)

    I'm testing uploading the Alastria Quorum (v1.8.18) to new version (v2.7.0 and v20.10.0).

    But the chain syncronization fails, in full mode. Fast mode finish right.

    We use the well-know genesis node for Alastria node:

    https://github.com/alastria/alastria-node/blob/testnet2/data/genesis.json

    And the command line looks like:

    geth --datadir /root/alastria/data --networkid 83584648538 --identity VAL_DigitelTS_T_2_8_01 --permissioned --cache 10 --rpc --rpcaddr 127.0.0.0 --rpcapi admin,db,eth,debug,miner,net,shh,txpool,personal,web3,quorum,istanbul --rpcport 22000 --port 21000 --istanbul.requesttimeout 10000 --ethstats VAL_DigitelTS_T_2_8_01:[email protected]:80 --verbosity 3 --emitcheckpoints --targetgaslimit 8000000 --syncmode full --gcmode full --vmodule consensus/istanbul/core/core.go=5 --debug --vmdebug --nodiscover --mine --minerthreads 2
    

    But can't get past block 8597100. It happens in these both version upgrades we are testing:

    > admin.nodeInfo.name
    "Geth/VAL_DigitelTS_T_2_8_01/v1.9.7-stable-6005360c(quorum-v2.7.0)/linux-amd64/go1.15.2"
    > admin.nodeInfo.name
    "Geth/VAL_DigitelTS_T_2_8_01/v1.9.7-stable-af752518(quorum-v20.10.0)/linux-amd64/go1.15.2"
    

    The log its almost the same in both versions:

    Number: 8597101
    Hash: 0xe4a2d78d83c995c1f756a7813b07b93c77b975eb5ec0a7ea7d16b6636649b2e5
             0: cumulative: 48864 gas: 48864 contract: 0x0000000000000000000000000000000000000000 status: 1 tx: 0x5136041eb879d49699e76bf64aed8207376cd0d1f42aa20d80613bad309bece4 logs: [0xc0004bc790 0xc0004bc840]
    bloom: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000100000000000000000000000040000000000000000000000000000000000000000000000000
    0000000000100000000000000000000000000000000000000002000000000000000200000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000400000000000000000000000000000 state:
             1: cumulative: 97728 gas: 48864 contract: 0x0000000000000000000000000000000000000000 status: 1 tx: 0xb0e8e529893614560fcd421310d68cd03794fe8a22e36d5140ba6cde5b4300af logs: [0xc0004bc8f0 0xc0004bc9a0]
    bloom: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000100000000000000000000000040000000000000000000000000000000000000000000000000
    00000000001000000000000000000000000000000000000000020000000000000002000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    00000000000000000000000000000000000000100000000000000000000000000000000400000000000000000000000000000 state:
    Error: invalid merkle root (remote: 0f6d6606b447b6fd26392f999e84be08fdf8b71f956b83116017dbb371ea1f1a local: 8a6cab008e2572a774a3c1eadc36269fa65662471c088652853db94e38ff8e59)
    ##############################
    WARN [11-09|15:18:19.392|eth/downloader/downloader.go:336] Synchronisation failed, dropping peer    peer=d94e041d29046c47 err="retrieved hash chain is invalid"
    ERROR[11-09|15:18:21.002|core/blockchain.go:2214]
    ########## BAD BLOCK #########
    Chain config: {ChainID: 83584648538 Homestead: 0 DAO: <nil> DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 IsQuorum: true Constantinople: <nil> TransactionSizeLimit: 0 MaxCodeSize: 24 Petersburg:
     <nil> Istanbul: <nil> Engine: istanbul}
    

    This problem does not happen with the current stable Alastria version: the full syncronization finish right:

    Geth/VAL_DigitelTS_T_2_8_00/v1.8.18-stable(quorum-v2.2.2)/linux-amd64/go1.9.5
    

    Is necessary to be able to recreate the chain in full mode before in order to upgrade the network clients.

    Full log of fail sincronization, until "BAD BLOCK" message in:

    FULL LOG log.err.txt.gz

    rwxrwxrwx 1 ladmin ladmin 44902 Dec 15 13:11 log.err.txt.gz
    

    FULL LOG

    Related links:

    • https://blkexplorer1.telsius.alastria.io/block/8597101
    • https://blkexplorer1.telsius.alastria.io/block/8597100
    • https://docs.goquorum.consensys.net/en/stable/Reference/Logging%20and%20Errors/#resolution-of-database-corruption-issues (doesn't apply)
    • https://docs.goquorum.consensys.net/en/stable/Reference/Logging%20and%20Errors/#resolution-of-database-corruption-issues (doesn't apply)
  • New tenant added in an existing network is not getting identified from other nodes in the network

    New tenant added in an existing network is not getting identified from other nodes in the network

    I have setup a network enabling multitenancy with Quorum 21.7.1 and Tessera 21.7.2 integrated with hashicorp vault(docker image - quorumengineering/tessera:hashicorp-21.7.2)

    Initially each node had one tenant. Some transactions were performed. Then in the existing network I tried adding one new tenant in Node1.

    The steps I followed -

    1. Created new key pair in the hashicorp vault
    2. Updated the tessera config jason like :

    "keys": { "hashicorpKeyVaultConfig": { "url": "http://x.x.x.x:8200" }, "keyData": [ { "hashicorpVaultSecretEngineName": "xxx", "hashicorpVaultSecretName": "xxx-tessera-key", "hashicorpVaultPrivateKeyId": "privateKey", "hashicorpVaultPublicKeyId": "publicKey" }, { "hashicorpVaultSecretEngineName": "xxx", "hashicorpVaultSecretName": "yyy-tessera-key", "hashicorpVaultPrivateKeyId": "privateKey", "hashicorpVaultPublicKeyId": "publicKey" } ] }, "alwaysSendTo": [], "features": { "enableMultiplePrivateStates": "true" }, "residentGroups":[ { "name":"private", "description":"default privacy group", "members":["XXX"] }, { "name":"PS1", "description":"Privacy Group 1", "members":["YYY"] } ]

    1. restarted tessera and quorum in Node1.
    2. Initiated private transaction from Node2 keeping the new tenant of Node 1(i.e. PS1 resident group) as party of the txn. But got error in contract mining - Error: Non-200 status code: &{Status:404 Not Found StatusCode:404 Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 Header:map[Content-Length:[73] Content-Type:[text/plain] Date:[Fri, 12 Nov 2021 16:22:58 GMT] Server:[Jetty(9.4.25.v20191220)]] Body:0xc01dab0e00 ContentLength:73 TransferEncoding:[] Close:false Uncompressed:false Trailer:map[] Request:0xc01d7c1600 TLS:} undefined undefined

    Error in Tessera log -

    2021-11-12 12:51:34.443 [qtp751413576-33] INFO c.q.tessera.q2t.TransactionResource - Enter Request : POST : /sendraw 2021-11-12 12:51:34.474 [qtp751413576-33] INFO c.q.t.d.EncryptedTransactionDAOImpl - Stored transaction sswThPBnMMW+e9PSRVF2g6YpjRiRxrLFgBhLVYAS0KjpyItrsJ9aeTzDGiz9naUWRnzgCm6kRJaWf1bHc+7tqg== 2021-11-12 12:51:34.475 [qtp751413576-33] WARN c.q.t.a.e.KeyNotFoundExceptionMapper - Recipient not found for key: JVBix+8O4Ch7xi7j7fa372iC7Ssp3Op7LnT37Ft5Rms= 2021-11-12 12:51:34.475 [qtp751413576-33] INFO c.q.tessera.q2t.TransactionResource - Exit Request : POST : /sendraw 2021-11-12 12:51:34.475 [qtp751413576-33] INFO c.q.tessera.q2t.TransactionResource - Response for sendraw : 404 Not Found

  • GoQuorum Geth Crash with fatal error: concurrent map iteration and map write

    GoQuorum Geth Crash with fatal error: concurrent map iteration and map write

    System information

    Geth version: geth version Geth Version: 1.9.25-stable Git Commit: 919800f019cc5d2b931b5cd81600640a8e7cd444 Quorum Version: 21.10.0 Architecture: amd64 Protocol Versions: [65 64 63] Network Id: 1337 Go Version: go1.15.6 Operating System: linux GOPATH= GOROOT=go

    OS & Version: Windows/Linux/OSX Running on Google CLoud Platform GKE Kubernetes / # cat /etc/os-release NAME="Alpine Linux" ID=alpine VERSION_ID=3.14.2 PRETTY_NAME="Alpine Linux v3.14" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://bugs.alpinelinux.org/"

    Expected behaviour

    When transactions are send to the Geth RPC, it continue to process the txn and return receipt without crashing.

    Actual behaviour

    Geth (GoQuorum) crash with "fatal error: concurrent map iteration and map write" randomly, especially when we are sending > ~10 send transaction call per seconds to Geth.

    Steps to reproduce the behaviour

    Keep sending private smart contract transaction to Geth, at more than ~10 Txn per seconds, it would randomly crash. With public smart contract transaction, it does not crash even with 100 TPS.

    Backtrace

    Full log attached

    fatal error: concurrent map iteration and map write
    
    goroutine 82381 [running]:
    runtime.throw(0x17480af, 0x26)
    	runtime/panic.go:1116 +0x72 fp=0xc00db61980 sp=0xc00db61950 pc=0x450c52
    runtime.mapiternext(0xc00db61aa8)
    	runtime/map.go:853 +0x554 fp=0xc00db61a00 sp=0xc00db61980 pc=0x429f14
    github.com/ethereum/go-ethereum/core/state.Storage.Copy(0xc00b8561e0, 0xc00bc9cc00)
    	github.com/ethereum/go-ethereum/core/state/state_object.go:54 +0x156 fp=0xc00db61b18 sp=0xc00db61a00 pc=0x9541b6
    github.com/ethereum/go-ethereum/core/state.(*stateObject).deepCopy(0xc00da03400, 0xc00db86000, 0xc00db61c98)
    	github.com/ethereum/go-ethereum/core/state/state_object.go:439 +0x196 fp=0xc00db61c00 sp=0xc00db61b18 pc=0x956f96
    github.com/ethereum/go-ethereum/core/state.(*StateDB).Copy(0xc00dad2000, 0xc00db29e00)
    	github.com/ethereum/go-ethereum/core/state/statedb.go:794 +0x752 fp=0xc00db61f28 sp=0xc00db61c00 pc=0x95e8b2
    github.com/ethereum/go-ethereum/miner.(*worker).pending(0xc0008f78c0, 0x1711dad, 0x7, 0x0, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/miner/worker.go:294 +0x290 fp=0xc00db61ff0 sp=0xc00db61f28 pc=0xe9da70
    github.com/ethereum/go-ethereum/miner.(*Miner).Pending(...)
    	github.com/ethereum/go-ethereum/miner/miner.go:187
    github.com/ethereum/go-ethereum/eth.(*EthAPIBackend).StateAndHeaderByNumber(0xc000ae8f60, 0x19bd080, 0xc00917c270, 0xfffffffffffffffe, 0xc00d7f7960, 0x0, 0x0, 0x3c, 0x21e9fae)
    	github.com/ethereum/go-ethereum/eth/api_backend.go:174 +0x2a5 fp=0xc00db620e8 sp=0xc00db61ff0 pc=0xf00125
    github.com/ethereum/go-ethereum/eth.(*EthAPIBackend).StateAndHeaderByNumberOrHash(0xc000ae8f60, 0x19bd080, 0xc00917c270, 0xc00f8c9188, 0x0, 0x0, 0x0, 0xc00db4fb00, 0xc00dba2a80, 0x181fe70, ...)
    	github.com/ethereum/go-ethereum/eth/api_backend.go:192 +0x578 fp=0xc00db62260 sp=0xc00db620e8 pc=0xf00998
    github.com/ethereum/go-ethereum/internal/ethapi.DoCall(0x19bd080, 0xc00917c270, 0x19dc320, 0xc000ae8f60, 0xc00b9df868, 0xc00f759240, 0xc00f8c99f8, 0xc00b205a20, 0xc00db00580, 0xc00b205a00, ...)
    	github.com/ethereum/go-ethereum/internal/ethapi/api.go:944 +0x106 fp=0xc00db62648 sp=0xc00db62260 pc=0xdb73a6
    github.com/ethereum/go-ethereum/internal/ethapi.DoEstimateGas.func1(0x1cc352, 0x19bd000, 0xc00bc9c4e0, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/internal/ethapi/api.go:1137 +0x193 fp=0xc00db62fc8 sp=0xc00db62648 pc=0xdcf4b3
    github.com/ethereum/go-ethereum/internal/ethapi.DoEstimateGas(0x19bd080, 0xc00917c270, 0x19dc320, 0xc000ae8f60, 0xc00b9df868, 0xc00f759240, 0xc00f8c99f8, 0xc00b205a20, 0xc00db00580, 0xc00b205a00, ...)
    	github.com/ethereum/go-ethereum/internal/ethapi/api.go:1149 +0x1fa fp=0xc00db63268 sp=0xc00db62fc8 pc=0xdb8ada
    github.com/ethereum/go-ethereum/internal/ethapi.(*SendTxArgs).setDefaults(0xc00b9df810, 0x19bd080, 0xc00917c270, 0x19dc320, 0xc000ae8f60, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/internal/ethapi/api.go:1894 +0x299 fp=0xc00db63380 sp=0xc00db63268 pc=0xdbfcb9
    github.com/ethereum/go-ethereum/internal/ethapi.(*PublicTransactionPoolAPI).SendTransaction(0xc00113fce0, 0x19bd080, 0xc00917c270, 0x0, 0x0, 0xc00e963040, 0x4, 0x4, 0x0, 0x0, ...)
    	github.com/ethereum/go-ethereum/internal/ethapi/api.go:2075 +0x1d7 fp=0xc00db63828 sp=0xc00db63380 pc=0xdc2ed7
    runtime.call256(0xc006367dd0, 0xc0009fccb8, 0xc00bca4690, 0xc0000000f0)
    	runtime/asm_amd64.s:543 +0x5c fp=0xc00db63938 sp=0xc00db63828 pc=0x48821c
    reflect.Value.call(0xc020b52c00, 0xc0009fccb8, 0x13, 0x170d454, 0x4, 0xc00bbfbe00, 0x3, 0x3, 0xc00bbfbe30, 0xc00b2059c0, ...)
    	reflect/value.go:476 +0x8c7 fp=0xc00db63b50 sp=0xc00db63938 pc=0x4bcc87
    reflect.Value.Call(0xc020b52c00, 0xc0009fccb8, 0x13, 0xc00bbfbe00, 0x3, 0x3, 0x16, 0x7fa8ce35ee58, 0x30)
    	reflect/value.go:337 +0xb9 fp=0xc00db63bd0 sp=0xc00db63b50 pc=0x4bc179
    github.com/ethereum/go-ethereum/rpc.(*callback).call(0xc002091020, 0x19bd080, 0xc00917c270, 0xc00f363c20, 0x13, 0xc00b2059c0, 0x1, 0x1, 0x0, 0x0, ...)
    	github.com/ethereum/go-ethereum/rpc/service.go:206 +0x2c5 fp=0xc00db63cd8 sp=0xc00db63bd0 pc=0xbbcfc5
    github.com/ethereum/go-ethereum/rpc.(*handler).runMethod(0xc00eb08fc0, 0x19bd080, 0xc00917c210, 0xc00ed83810, 0xc002091020, 0xc00b2059c0, 0x1, 0x1, 0x1)
    	github.com/ethereum/go-ethereum/rpc/handler.go:416 +0xd9 fp=0xc00db63d48 sp=0xc00db63cd8 pc=0xbb45b9
    github.com/ethereum/go-ethereum/rpc.(*handler).handleCall(0xc00eb08fc0, 0xc0055b81e0, 0xc00ed83810, 0x203001)
    	github.com/ethereum/go-ethereum/rpc/handler.go:360 +0x345 fp=0xc00db63e30 sp=0xc00db63d48 pc=0xbb34a5
    github.com/ethereum/go-ethereum/rpc.(*handler).handleCallMsg(0xc00eb08fc0, 0xc0055b81e0, 0xc00ed83810, 0x19a6001)
    	github.com/ethereum/go-ethereum/rpc/handler.go:298 +0x1be fp=0xc00db63ef8 sp=0xc00db63e30 pc=0xbb29fe
    github.com/ethereum/go-ethereum/rpc.(*handler).handleMsg.func1(0xc0055b81e0)
    	github.com/ethereum/go-ethereum/rpc/handler.go:139 +0x46 fp=0xc00db63f68 sp=0xc00db63ef8 pc=0xbc2666
    github.com/ethereum/go-ethereum/rpc.(*handler).startCallProc.func1(0xc00eb08fc0, 0xc00e595e00)
    	github.com/ethereum/go-ethereum/rpc/handler.go:226 +0xd2 fp=0xc00db63fd0 sp=0xc00db63f68 pc=0xbc2832
    runtime.goexit()
    	runtime/asm_amd64.s:1374 +0x1 fp=0xc00db63fd8 sp=0xc00db63fd0 pc=0x489a21
    created by github.com/ethereum/go-ethereum/rpc.(*handler).startCallProc
    	github.com/ethereum/go-ethereum/rpc/handler.go:222 +0x66
    
    goroutine 1 [chan receive, 9 minutes]:
    github.com/ethereum/go-ethereum/node.(*Node).Wait(...)
    	github.com/ethereum/go-ethereum/node/node.go:445
    main.geth(0xc00012a580, 0x0, 0x0)
    	github.com/ethereum/go-ethereum/cmd/geth/main.go:399 +0x157
    gopkg.in/urfave/cli%2ev1.HandleAction(0x149dc00, 0x18226e0, 0xc00012a580, 0xc0004bc060, 0x0)
    	gopkg.in/urfave/[email protected]/app.go:490 +0x82
    gopkg.in/urfave/cli%2ev1.(*App).Run(0xc0000a0000, 0xc00003c500, 0x49, 0x50, 0x0, 0x0)
    	gopkg.in/urfave/[email protected]/app.go:264 +0x5f5
    main.main()
    	github.com/ethereum/go-ethereum/cmd/geth/main.go:312 +0x55
    

    crash.log.zip

  •  transaction to be stuck in pending state

    transaction to be stuck in pending state

    I'm using version V2.2.3, and I'll loop through the test cases.Trading will be suspended between 15 and 20w after two tests.Pending num is 30000. After I restart the node, the 30000 data can be synchronized. image image Contracts are submitted all the time, but are not synchronized with other nodes,After I restart the node, the 30000 data can be synchronized. I also got a new error on the other nodes,when that node restarts. image

  • panic: runtime error: invalid memory address or nil pointer dereference

    panic: runtime error: invalid memory address or nil pointer dereference

    TLDR:

    quorum geth crashes:

    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xbd4ef0]
    

    when running 7nodes example on host machine.

    System information

    geth version
    Geth
    Version: 1.7.2-stable
    Git Commit: ee498061b5a74bf1f3290139a53840345fa038cb
    Quorum Version: 2.0.1
    Architecture: amd64
    Network Id: 1
    Go Version: go1.9.3
    Operating System: linux
    

    I have tried both

    git checkout tags/v2.0.1
    

    and

    git checkout tags/v2.0.2
    

    Both result in the same error behavior below.

    For details how I compiled it, see quorum-examples/non-vagrant/README.md

    Expected behaviour

    That raft consensus 7nodes are starting up, exactly like in the vagrant virtualbox 7nodes example.

    @jpmsam had suggested to me, to run quorum outside of vagrant (like in the 7nodes example), for TPS speed improvements.

    Actual behaviour

    qdata/1.log

    nohup: appending output to 'nohup.out'
    INFO [04-23|10:48:57] Starting peer-to-peer node               instance=Geth/v1.7.2-stable-df4267a2/linux-amd64/go1.9.3
    [...]
    2018-04-23 10:48:59.905833 I | rafthttp: added peer 6
    2018-04-23 10:48:59.905860 I | rafthttp: starting peer 7...
    2018-04-23 10:48:59.905873 I | rafthttp: started HTTP pipelining with peer 7
    2018-04-23 10:48:59.906302 I | rafthttp: started peer 7
    2018-04-23 10:48:59.906336 I | rafthttp: added peer 7
    raft2018/04/23 10:48:59 INFO: 1 became follower at term 0
    raft2018/04/23 10:48:59 INFO: newRaft 1 [peers: [], term: 0, commit: 0, applied: 0, lastindex: 0, lastterm: 0]
    raft2018/04/23 10:48:59 INFO: 1 became follower at term 1
    2018-04-23 10:48:59.906940 I | rafthttp: started streaming with peer 6 (writer)
    2018-04-23 10:48:59.906975 I | rafthttp: started streaming with peer 6 (writer)
    INFO [04-23|10:48:59] Blockchain manager stopped 
    INFO [04-23|10:48:59] Stopping Ethereum protocol 
    2018-04-23 10:48:59.907992 I | rafthttp: started streaming with peer 6 (stream MsgApp v2 reader)
    2018-04-23 10:48:59.908070 I | rafthttp: started streaming with peer 6 (stream Message reader)
    2018-04-23 10:48:59.908114 I | rafthttp: started streaming with peer 7 (writer)
    2018-04-23 10:48:59.908123 I | rafthttp: started streaming with peer 7 (writer)
    2018-04-23 10:48:59.908136 I | rafthttp: started streaming with peer 7 (stream MsgApp v2 reader)
    2018-04-23 10:48:59.908196 I | rafthttp: started streaming with peer 7 (stream Message reader)
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xbd4ef0]
    
    goroutine 288 [running]:
    github.com/ethereum/go-ethereum/eth/filters.(*EventSystem).eventLoop(0xc420f67080)
    	/jpmorganchase_quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/filters/filter_system.go:417 +0x330
    created by github.com/ethereum/go-ethereum/eth/filters.NewEventSystem
    	/jpmorganchase_quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/filters/filter_system.go:112 +0x104
    

    qdata/2.log

    nohup: appending output to 'nohup.out'
    INFO [04-23|10:48:57] Starting peer-to-peer node               instance=Geth/v1.7.2-stable-df4267a2/linux-amd64/go1.9.3
    [...]
    2018-04-23 10:48:59.887429 I | rafthttp: added peer 7
    raft2018/04/23 10:48:59 INFO: 2 became follower at term 0
    raft2018/04/23 10:48:59 INFO: newRaft 2 [peers: [], term: 0, commit: 0, applied: 0, lastindex: 0, lastterm: 0]
    raft2018/04/23 10:48:59 INFO: 2 became follower at term 1
    2018-04-23 10:48:59.887453 I | rafthttp: started streaming with peer 7 (stream MsgApp v2 reader)
    2018-04-23 10:48:59.887518 I | rafthttp: started streaming with peer 7 (writer)
    2018-04-23 10:48:59.887560 I | rafthttp: started streaming with peer 7 (stream Message reader)
    2018-04-23 10:48:59.887615 I | rafthttp: started streaming with peer 7 (writer)
    INFO [04-23|10:48:59] Blockchain manager stopped 
    INFO [04-23|10:48:59] stopping raft protocol handler... 
    2018-04-23 10:48:59.888434 I | rafthttp: stopping peer 1...
    2018-04-23 10:48:59.888442 I | rafthttp: stopped streaming with peer 1 (writer)
    [...]
    2018-04-23 10:48:59.889374 I | rafthttp: stopped peer 7
    2018-04-23 10:48:59.889378 I | rafthttp: removed peer 7
    INFO [04-23|10:48:59] raft protocol handler stopped 
    INFO [04-23|10:48:59] ignoring expected ConfChangeAddNode for initial peer raft id=1
    INFO [04-23|10:48:59] start snapshot                           applied index=0 last snapshot index=0
    INFO [04-23|10:48:59] Database closed                          database=/quorum-examples/examples/7nodes/qdata/dd2/geth/chaindata
    INFO [04-23|10:48:59] Raft stopped 
    INFO [04-23|10:48:59] Stopping Ethereum protocol 
    INFO [04-23|10:48:59] Ethereum protocol stopped 
    INFO [04-23|10:48:59] Transaction pool stopped 
    ERROR[04-23|10:48:59] Failed to close database                 database=/quorum-examples/examples/7nodes/qdata/dd2/geth/chaindata err="leveldb: closed"
    Fatal: Error starting protocol stack: listen unix /quorum-examples/examples/7nodes/qdata/dd2/geth.ipc: bind: invalid argument
    

    Steps to reproduce the behaviour

    Follow the detailed walk through in

    https://github.com/drandreaskrueger/quorum-examples/blob/master/non-vagrant/README.md

    System is Debian

    uname -a
    Linux ... 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux
    

    Backtrace

    ? how ?

  • The TPS of Quorum

    The TPS of Quorum

    Hi, I want to know How many transactions do Quorum accomplish in a second?

    I build a 3 node test environment, the device info is CPU: 2 Intel(R) Xeon(R) CPU E5-2640 v2 @ 2.00GHz Mem: 4GB Disk:80GB in my test , TOP TPS is 137 , is the result reasonable? and do you have any methd to increase the TPS,eg ... change some parameter or so ?

  • Panic

    Panic

    Hi there,

    Please note that this is an issue tracker reserved for bug reports and feature requests.

    For general questions please use the gitter channel or the Ethereum stack exchange at https://ethereum.stackexchange.com.

    System information

    Geth version: 1.9.7-stable

    OS & Version: Ubuntu 16.04.7 LTS 16G RAM - inside docker

    Branch, Commit Hash or Release: af7525189f2cee801ef6673d438b8577c8c5aa34

    Expected behaviour

    Actual behaviour

    Steps to reproduce the behaviour

    Backtrace

    DEBUG[12-15|10:37:59.847] Reset ancient limit to zero
    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x1c0 pc=0xca6913]
    
    goroutine 286 [running]:
    github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).findAncestor(0xc000e8d180, 0xc00161e3c0, 0xc0594aefc0, 0x0, 0x0, 0xa)
            /tmp/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/downloader/downloader.go:890 +0x14d3
    github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).syncWithPeer(0xc000e8d180, 0xc00161e3c0, 0x5be8b18537b8ced6, 0x6e63d297fbd1810, 0x8ba3e9ad36a9fbb0, 0x133e551934bedb65, 0xc027c754c0, 0x0, 0x0)
            /tmp/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/downloader/downloader.go:456 +0x3df
    github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).synchronise(0xc000e8d180, 0xc025329b80, 0x10, 0x5be8b18537b8ced6, 0x6e63d297fbd1810, 0x8ba3e9ad36a9fbb0, 0x133e551934bedb65, 0xc027c754c0, 0x0, 0x0, ...)
            /tmp/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/downloader/downloader.go:424 +0x418
    github.com/ethereum/go-ethereum/eth/downloader.(*Downloader).Synchronise(0xc000e8d180, 0xc025329b80, 0x10, 0x5be8b18537b8ced6, 0x6e63d297fbd1810, 0x8ba3e9ad36a9fbb0, 0x133e551934bedb65, 0xc027c754c0, 0x0, 0x0, ...)
            /tmp/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/downloader/downloader.go:328 +0x8e
    github.com/ethereum/go-ethereum/eth.(*ProtocolManager).synchronise(0xc0002fde00, 0xc00b5160c0)
            /tmp/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/sync.go:199 +0x2ee
    created by github.com/ethereum/go-ethereum/eth.(*ProtocolManager).syncer
            /tmp/quorum/build/_workspace/src/github.com/ethereum/go-ethereum/eth/sync.go:152 +0x2e5
    
    
  • quorum --permissioned flag

    quorum --permissioned flag

    Hi there,

    We are using geth with --permissioned flag and we get this error

    ERROR[10-15|12:28:43.140] Read Error for permissioned-nodes.json file. This is because 'permissioned' flag is specified but no permissioned-nodes.json file is present. err="stat /root/node1/data/permissioned-nodes.json: no such file or directory"

    According to the documentation, geth should find permission-config.json instead permissioned-nodes.json

    any idea? Our quorum version is 2.3.0

    thanks!

  • Istanbul: bigger blockperiod value cause blockchain stuck

    Istanbul: bigger blockperiod value cause blockchain stuck

    Geth Version: 1.8.12-stable Git Commit: 8c4aea54d13d7ca6f148287d09aea9e0b6b0d8e6 Quorum Version: 2.1.1 Architecture: amd64 Protocol Versions: [63 62] Network Id: 1337 Go Version: go1.10.1 Operating System: linux GOPATH= GOROOT=/usr/lib/go-1.10

    I configured 3 quorum nodes with Istanbul consensus. If I set --istanbul.blockperiod 10, the whole blockchain will stuck after mining some blocks. The default blockperiod value which is 1 works fine. I tried to set blockperiod 5, it also works.

    Here is the log: INFO [11-30|09:43:01.105] Committed address=0x525ad36D11aA5E8139FC21D82485EF66B54AddB2 hash=5efda5…a129aa number=4 INFO [11-30|09:43:01.107] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed=618.701µs mgasps=0.000 number=4 hash=5efda5…a129aa cache=0.00B INFO [11-30|09:43:01.107] Commit new mining work number=5 txs=0 uncles=0 elapsed=159.2µs INFO [11-30|09:43:11.438] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed=645.6µs mgasps=0.000 number=5 hash=f1a986…4a93c9 cache=0.00B INFO [11-30|09:43:11.439] Commit new mining work number=6 txs=0 uncles=0 elapsed=276.6µs INFO [11-30|09:43:21.002] Committed address=0x525ad36D11aA5E8139FC21D82485EF66B54AddB2 hash=e785ef…ddc5ac number=6 INFO [11-30|09:43:21.002] Successfully sealed new block number=6 hash=e785ef…ddc5ac INFO [11-30|09:43:21.002] block reached canonical chain number=1 hash=ca631e…874dd2 INFO [11-30|09:43:21.002] mined potential block number=6 hash=e785ef…ddc5ac INFO [11-30|09:43:21.003] Commit new mining work number=7 txs=0 uncles=0 elapsed=111.2µs INFO [11-30|09:43:31.301] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed=623.101µs mgasps=0.000 number=7 hash=ea45e4…679276 cache=0.00B INFO [11-30|09:43:31.301] Commit new mining work number=8 txs=0 uncles=0 elapsed=150.2µs INFO [11-30|09:43:41.108] Committed address=0x525ad36D11aA5E8139FC21D82485EF66B54AddB2 hash=b7ab7a…547115 number=8 INFO [11-30|09:43:41.109] Successfully sealed new block number=8 hash=b7ab7a…547115 INFO [11-30|09:43:41.109] block reached canonical chain number=3 hash=967955…995fd8 INFO [11-30|09:43:41.109] mined potential block number=8 hash=b7ab7a…547115 INFO [11-30|09:43:41.109] Commit new mining work number=9 txs=0 uncles=0 elapsed=167.7µs INFO [11-30|09:43:41.438] Imported new chain segment blocks=1 txs=0 mgas=0.000 elapsed=539.7µs mgasps=0.000 number=8 hash=70df0c…773024 cache=0.00B

    Looks like if there happens to be two blocks with same block number but different hash, the blockchain will stuck.

  • Update etcd raft package to v3.3.27

    Update etcd raft package to v3.3.27

    This PR provides the following changes for Raft consensus protocol service:

    1. Removed dependencies to not up-gradable etcd module https://github.com/ConsenSys/etcd v3.3.13 and replaced to vanila https://github.com/etcd-io/etcd v3.3.27 version.
    2. Moved changes by Quorum team from obsolete https://github.com/ConsenSys/etcd package to main repository (added required code only).
    3. Added types compatibility between customized by quorum team and source raft packages
    4. Added few minor changes to Raft consensus service source code

    The main idea of this PR is to remove obsolete etcd package and provide ability to upgrade etcd package easier further.

  • Delay in event capturing by Quorum chaincode event listener

    Delay in event capturing by Quorum chaincode event listener

    We are observing delay between event emission and event being captured by the chaincode event listener.

    Transaction (which emits event) was posted from Application at - 11:40:44 GMT Block mining timestamp for this txn was: 1670931644873193200 i.e. 11:40:44 GMT Event captured by the chaincode event listener at – 11:40:57 GMT

    So, what could be the reason for the listener to take 13sec to read the event?

    Quorum network overview: No of nodes in the network : 20 Block height : 46016536

  • raft_addPeer returns duplicate raft id

    raft_addPeer returns duplicate raft id

    System information

    Geth Version: 1.10.3-stable Git Commit: d318a5aa973a7ac5edd09798870ed86060af14d8 Quorum Version: 22.7.4 Architecture: amd64 Network Id: 1337 Go Version: go1.16.15 Operating System: linux GOPATH= GOROOT=go

    Nodes all hosted in azure.

    Expected behaviour

    Given a new network that looks like this,

    static-nodes.json "enode://8334f9e52d3be971ea8472e7da6d966f2cc575eb7560d527d93da1a6aeb737f4313be41b9514049b21eb441240db7ecce18b4e95adf63b1e1472e15c436a5cd8@104.40.129.4:21000?discport=0&raftport=50400", "enode://989992ac3d6c27d25ddd4485aa68e892c327dffd50339608252d5263ebd5cba7b1acfbb65fb3376e0d0f094c088b966123266c0b1fbd0c2d5028e28f05004e0b@104.40.129.23:21000?discport=0&raftport=50400", "enode://618f8e797f44d02c7fb9cdc0ddb03a28c80cfc83109a4fe3c4178e01b2bb9b416d912c6581051bf0e466e212464ccf09365390ee6f80414a1a28274faa6c17bc@104.40.194.48:21000?discport=0&raftport=50400"

    Where the raft ids of each, according to raft.cluster at the shell, are 1, 2, 3 respectively.

    If I invoke raft_addPeer from a new node init container

    connecting to http://104.40.129.4:22000
    request: {jsonrpc="2.0", method="raft_addPeer", params=["node://178ac76fc92d6002f128f0979f48b8f669f89bdbef17548a8a4b097c12b746a78348ba92b0f3a1b4949411651b81c51b0e8377786263613e48bf5cfcba9bee1a@104.40.194.48:21001?discport=0&raftport=50401"], id="33"}
    

    I expect to get 4 as the raft id response

    Actual behaviour

    I get 3

    Steps to reproduce the behaviour

    • Setup a local docker networking environment which allows for static 3 static ip addresses

    • create the first node

    • create the next two nodes in turn, calling raft_addPeer, and then running geth with --joinexisting raftid

    • These first 3 nodes each get a unique IP address

    • When each successive node is added, call raft_addPeer on the first created, then use geth --joinexisting with the obtained raft id

    • For each node that is added, ensure that the static-nodes.json includes all previous nodes (but don't update the previously created nodes)

    • Create the 4rth node. give it the same IP as the 3rd node, but use a different port

  • Node panic: runtime error: invalid memory address or nil pointer dereference

    Node panic: runtime error: invalid memory address or nil pointer dereference

    System information

    version: master OS & Version: Linux Commit hash : 56184d8367be7109cfd76ba4896d841801c66520

    Expected behaviour

    Nodes run as usual.

    Actual behaviour

    Nodes crash down, and can not be recovered.

    Steps to reproduce the behaviour

    Setup a QBFT network locally, following the instruction in https://consensys.net/docs/goquorum/en/latest/tutorials/private-network/create-qbft-network. Repeatedly sending fuzzed consensus messages to node-2.

    Backtrace

    Root location: https://github.com/ConsenSys/quorum/blob/master/eth/downloader/downloader.go

    header := d.lightchain.GetHeaderByHash(h) // Independent of sync mode, header surely exists
    if header.Number.Uint64() != check {
    	p.log.Warn("Received non requested header", "number", header.Number, "hash", header.Hash(), "request", check)
    	return 0, fmt.Errorf("%w: non-requested header (%d)", errBadPeer, header.Number)
    }
    start = check
    hash = h
    

    In line 1004, nil pointer in header.Number.Uint64() .

    log info:

    panic: runtime error: invalid memory address or nil pointer dereference
    [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x10472ad00]
    
    
    goroutine 75621 [running]:
    github.com/ConsenSys/quorum/eth/downloader.(*Downloader).findAncestorBinarySearch(0x14006fa1c20, 0x14019ff0000, 0x100000001, 0xbcfc99, 0xbb9cb3, 0xbb9cb3, 0x0, 0x10509bcd8)
    	github.com/ConsenSys/quorum/eth/downloader/downloader.go:1004 +0x440
    github.com/ConsenSys/quorum/eth/downloader.(*Downloader).findAncestor(0x14006fa1c20, 0x14019ff0000, 0x14025d5a480, 0x1400067ab40, 0x0, 0x0)
    	github.com/ConsenSys/quorum/eth/downloader/downloader.go:856 +0x338
    github.com/ConsenSys/quorum/eth/downloader.(*Downloader).syncWithPeer(0x14006fa1c20, 0x14019ff0000, 0x93275d9e27d9cc81, 0x20880d02a23dad6b, 0xefba04bd94c4dbfb, 0x632ca43bf48c30be, 0x1404d8ac5c0, 0x0, 0x0)
    	github.com/ConsenSys/quorum/eth/downloader/downloader.go:513 +0x3c0
    github.com/ConsenSys/quorum/eth/downloader.(*Downloader).synchronise(0x14006fa1c20, 0x1403876e040, 0x40, 0x93275d9e27d9cc81, 0x20880d02a23dad6b, 0xefba04bd94c4dbfb, 0x632ca43bf48c30be, 0x1404d8ac5c0, 0x1, 0x0, ...)
    	github.com/ConsenSys/quorum/eth/downloader/downloader.go:469 +0x31c
    github.com/ConsenSys/quorum/eth/downloader.(*Downloader).Synchronise(0x14006fa1c20, 0x1403876e040, 0x40, 0x93275d9e27d9cc81, 0x20880d02a23dad6b, 0xefba04bd94c4dbfb, 0x632ca43bf48c30be, 0x1404d8ac5c0, 0x23ac5c4400000002, 0x8b4b0ae95c9805f1, ...)
    	github.com/ConsenSys/quorum/eth/downloader/downloader.go:356 +0x6c
    github.com/ConsenSys/quorum/eth.(*handler).doSync(0x140073c0000, 0x1403937e0c0, 0x1403c7781c0, 0x1c738c98100323fe)
    	github.com/ConsenSys/quorum/eth/sync.go:331 +0x100
    github.com/ConsenSys/quorum/eth.(*chainSyncer).startSync.func1(0x14006efd950, 0x1403937e0c0)
    	github.com/ConsenSys/quorum/eth/sync.go:307 +0x34
    created by github.com/ConsenSys/quorum/eth.(*chainSyncer).startSync
    	github.com/ConsenSys/quorum/eth/sync.go:307 +0x78
    

    .

  • Node crashes down after receiving fuzzed messages.

    Node crashes down after receiving fuzzed messages.

    System information

    Geth version: geth 1.10 OS & Version: Linux

    Expected behaviour

    Nodes run as usual.

    Actual behaviour

    Nodes crash down, and can not be recovered.

    Steps to reproduce the behaviour

    Using setup a QBFT network locally, following the instruction in https://consensys.net/docs/goquorum/en/latest/tutorials/private-network/create-qbft-network. Repeatedly sending fuzzed messages to node-1.

    Backtrace

    Root location: https://github.com/ConsenSys/quorum/blob/master/trie/node.go

    func mustDecodeNode(hash, buf []byte) node {
    	n, err := decodeNode(hash, buf)
    	if err != nil {
    		panic(fmt.Sprintf("node %x: %v", hash, err))
    	}
    	return n
    }
    

    In line 111, should not panic directly when decode failed.

    log info:

    panic: node 26a6e78d2e0af3a027383d2f2e6dee01d0bf5a2927e0399d0a2e5f3c47162c1b: invalid RLP string size 269 (want 0 or 32) (decode path: [4]<-full)
    
    goroutine 21821 [running]:
    github.com/ConsenSys/quorum/trie.mustDecodeNodeUnsafe({0xc144fac100, 0x20, 0x20}, {0xc0606fef00?, 0xc0606fef00?, 0x243?})
            github.com/ConsenSys/quorum/trie/node.go:111 +0xd4
    github.com/ConsenSys/quorum/trie.(*Database).node(0xc00015acc0, {0x25, 0xcd, 0x7b, 0x75, 0xaa, 0xc, 0x1, 0xed, 0x48, ...})
            github.com/ConsenSys/quorum/trie/database.go:403 +0x239
    github.com/ConsenSys/quorum/trie.(*Trie).resolveHash(0xc0c377ed80, {0xc11b4b216f?, 0x7ff7bca230b6?, 0xc0293cf268?}, {0xc040991770, 0x5, 0x41})
            github.com/ConsenSys/quorum/trie/trie.go:493 +0xe5
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0x20?, {0x7ff7bdfcdf10?, 0xc12e35bf98?}, {0xc040991770, 0x41, 0x41}, 0x5)
            github.com/ConsenSys/quorum/trie/trie.go:149 +0xe6
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0xc0c377ed80?, {0x7ff7bdfccef0?, 0xc02b4bca00?}, {0xc040991770, 0xc040991770?, 0x4?}, 0x4)
            github.com/ConsenSys/quorum/trie/trie.go:142 +0x3f4
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0x4b5fcbac153cdbf?, {0x7ff7bdfcdf10?, 0xc110fe2258?}, {0xc040991770, 0x41, 0x41}, 0x4)
            github.com/ConsenSys/quorum/trie/trie.go:153 +0x176
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0xc0c377ed80?, {0x7ff7bdfccef0?, 0xc02b780140?}, {0xc040991770, 0xc040991770?, 0x3?}, 0x3)
            github.com/ConsenSys/quorum/trie/trie.go:142 +0x3f4
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0xf22ab52246add520?, {0x7ff7bdfcdf10?, 0xc0fab7e798?}, {0xc040991770, 0x41, 0x41}, 0x3)
            github.com/ConsenSys/quorum/trie/trie.go:153 +0x176
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0xc0c377ed80?, {0x7ff7bdfccef0?, 0xc02b780000?}, {0xc040991770, 0xc040991770?, 0x2?}, 0x2)
            github.com/ConsenSys/quorum/trie/trie.go:142 +0x3f4
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0x2a1af08016459ffc?, {0x7ff7bdfcdf10?, 0xc14db04438?}, {0xc040991770, 0x41, 0x41}, 0x2)
            github.com/ConsenSys/quorum/trie/trie.go:153 +0x176
    github.com/ConsenSys/quorum/trie.(*Trie).tryGet(0xc0c377ed80?, {0x7ff7bdfccef0?, 0xc02b27be00?}, {0xc040991770, 0xc040991770?, 0x1?}, 0x1)
            github.com/ConsenSys/quorum/trie/trie.go:142 +0x3f4
    github.com/ConsenSys/quorum/trie.(*Trie).TryGet(0xc0c377ed80, {0xc0c377edd0, 0x20, 0x20?})
            github.com/ConsenSys/quorum/trie/trie.go:117 +0xd6
    github.com/ConsenSys/quorum/trie.(*StateTrie).TryGet(0xc0c377ed80, {0xc152978ce0?, 0xc152978ce0?, 0x20?})
            github.com/ConsenSys/quorum/trie/secure_trie.go:79 +0x3d
    github.com/ConsenSys/quorum/core/state.(*subfetcher).loop(0xc0a945cf70)
            github.com/ConsenSys/quorum/core/state/trie_prefetcher.go:321 +0x810
    created by github.com/ConsenSys/quorum/core/state.newSubfetcher
            github.com/ConsenSys/quorum/core/state/trie_prefetcher.go:230 +0x1cb
    
  • Quorum nodes unable to sync with BAD Block error after validators are shutdown and restored.

    Quorum nodes unable to sync with BAD Block error after validators are shutdown and restored.

    Setup Details: We are running GoQuorum with the high availability setup over AKS.

    Quorum Version: 22.7.4 Number of Parties: 2 (say Party A and Party B) Quorum: 3 pods for both parties Tessera: 1 node with 2 replicas (3 pods for both parties) Validator: 4 pods with Party A, none with Party B Other details: IBFT consensus protocol

    Scenario: All 4 validators of PartyA are down forcefully. 5 Transactions are submitted on PartyA. All the transactions are in pending state in transaction queue. After 1 hour, the validators on PartyA are restored.

    Issue: Quorum transaction nodes are unable to sync blocks further with BAD Block error on all transaction PODs with below error. INFO [12-15|12:44:05.288] Skip duplicated bad blocknumber=825,158 hash=89cb9a..84fd3b ERROR[12-15|12:44:05.288] ########## BAD BLOCK ######### Chain config: {ChainID: 1000 Homestead: 0 DAO: DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 IsQuorum: true Constantinople: 0 TransactionSizeLimit: 128 MaxCodeSize: 0 Petersburg: 0 Istanbul: 0, Muir Glacier: , Berlin: Catalyst: YOLO v3: PrivacyEnhancements: 0 PrivacyPrecompile: EnableGasPriceBlock: Engine: istan bul}

    Number: 825158 Hash: 0x89cb9abbb9adad15f2f317db4db844484298bb2815311da4a5656700db84fd3b

    Error: could not apply tx 2 [0x027b82b570c5442ea943dfefc169a025d98379d9a968eb908533e94ec08b93eb]: gas limit reached ##############################

    The block # 825158 on validator is having all 5 transactions which were in pending queue. Since the gas limit for block is 700000000 (each transaction is submitted with 350000000 gas), we expect only 2 transactions in a block(this is what happens in sunny day scenario when validators are up and running). Can additional transactions in block cause gas limit reached error and processing is stuck because of that? Block Data from validator { difficulty: "0x1", extraData: "0xd983010a03846765746889676f312e31362e3135856c696e7578000000000000f90164f854944946579522783b7b0cb3643fef1241ae99e2a33f9465bb63d8d1445e13b2359baebdc445e8d76e7ec9948e29bd29a d6c2bcec89246983b68c4790afe64ae949d4be5c6eae5ee3b3394ece3fe8ef5b9710bde40b841813bb0b1c93ba261faf4fb129ef5c3692f8925c85d5e35d9881205b7ab57829663b155a415a9cf9f0f956ed045a46e093e5f280431e3 8ac2662a3cd66a8a2f9901f8c9b841626c558084b5f02f0be4fb04e4769098f6a98d26dd32d2a16772b6dbf5d978162f3859468b200317e3595ba1090f3180d242bcc84596280babab28a829aa457e01b841c64c89b1680f84a9d65fc b82cc5e506ee779cb9f2ae55e4921efaf13e900d52936db05fd7e32fa44a9a182c3b48f45f398fcd5c1aefeb4cf8de87cd4b2efef2500b8416dae1fde506ca96d8dc735104d05fd4cde863f5a82f0639a5e372666a1a1c0642a2b6889 6fdb7934637b2be576afa6c703f03bc88c45592e82ff5f270a76e35a00", gasLimit: "0x29b92700", gasUsed: "0x0", hash: "0x89cb9abbb9adad15f2f317db4db844484298bb2815311da4a5656700db84fd3b", logsBloom: "0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", miner: "0x0000000000000000000000000000000000000000", mixHash: "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365", nonce: "0x0000000000000000", number: "0xc9746", parentHash: "0xf8a98ec4c2ed50a44adb0ce453dee399bd8fe767932c72f79094df37f86f0626", receiptsRoot: "0xa0004892f3c1af17ec3582d2c44c272f3dfb6211ef63491cad74814114d66ea8", sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", size: "0x6c9", stateRoot: "0x8ced0a226907ab111de2f676dbc9c8fdcc3636ab2cef4caf2efcb1773097d882", timestamp: "0x639b109d", totalDifficulty: "0xc9747", transactions: ["0x6a741068cf181a3bf57374ffad874a35244ea3e426960094490c4cb0ec0b3ab0", "0xd987514580509c2515642165fdf6a6043c26359ae949a968dd0f17a06767464f", "0x027b82b570c5442ea943dfefc 169a025d98379d9a968eb908533e94ec08b93eb", "0xe4d8fa6539cba54763370d74fd66db362a3d0d44e07ec44e5d6c78da783b81d8", "0x473d1d334d55e2b50414dec7ebbe65dab9d4f3abfc6b6e18f897cc868c4fc66d"], transactionsRoot: "0x80fa789362499a14598d5658996597edf66404780676dae4cb85509bd8b5d081", uncles: [] }

    Note:- The gasLimit set on genesis file is 3758096384.

    The genesis file ` { "alloc": {}, "coinbase": "0x0000000000000000000000000000000000000000", "config": { "homesteadBlock": 0, "byzantiumBlock": 0, "constantinopleBlock": 0, "petersburgBlock": 0, "istanbulBlock": 0, "eip150Block": 0, "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000", "eip155Block": 0, "eip158Block": 0, "maxCodeSizeConfig": [ { "block": 0, "size": 128 } ], "txnSizeLimit": 128, "chainId": 1000, "isQuorum": true, "istanbul": { "epoch": 30000, "policy": 0, "ceil2Nby3Block": 0 } },

    "difficulty": "0x1", "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000f89af85494bfb4dc5445976bb5060508517d279b27616501b39494b5a886f3931f25c415855bfe8ee807267551db94fb807f7bc4b6ccd23f5430983e9274aa4106e33094c8ec42597df155de1bd26f95516f41857ce6dde1b8410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c0", "gasLimit": "0xE0000000", "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365", "nonce": "0x0", "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000", "timestamp": "0x00" }

    `

Go-ethereum - Official Golang implementation of the Ethereum protocol

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

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

Oct 14, 2022
Jan 7, 2023
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

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

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

May 1, 2022
Go implementation of Ethereum proof of stake

Prysm: An Ethereum Consensus Implementation Written in Go This is the core repository for Prysm, a Golang implementation of the Ethereum Consensus spe

Jan 1, 2023
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

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

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

Dec 7, 2021
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

Jan 8, 2023
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

Aug 8, 2022
RepoETH - Official Golang implementation of the Ethereum protocol
RepoETH - Official Golang implementation of the Ethereum protocol

HANNAGAN ALEXANDRE Powershell Go Ethereum Official Golang implementation of the

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

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

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

Apr 24, 2022
run ABI encoded data against the ethereum blockchain

Run EVM code against a database at a certain block height - Note You can't run this against a running geth node - because that would share the db and

Nov 11, 2021
Huobi Eco Chain client based on the go-ethereum fork

The Huobi Open Platform is a unified infrastructure platform based on the technical, traffic and ecological resources of the Huobi Group, and will be gradually open to the blockchain industry.

Dec 31, 2022
Streaming Fast on Ethereum
Streaming Fast on Ethereum

Stream Ethereum data like there's no tomorrow

Dec 15, 2022