Don't return contract address

[shuzang]

I run a 4 node quorum network consist of two PC and two raspberry pi, and ererythings looks well. When I run admin.peers in geth console, I can see all nodes. But when I deploy the contract, it returns "undefine". Then I deploy the example [public-contract] for test.

loadScript("public-contract.js") Contract transaction send: TransactionHash: 0x4b6fe6073117024cc8da299a7aa6a772063941b25c7da3de869857af76c0388f waiting to be mined... true

Thats all, I wait a long time but there is not a contract address return. but It should return like "> Contract mined! Address: 0xe975e1e11c5268b1efcbf39b7ee3cf7b8dc85fd7 ". And when I use eth.hashrate command, the result is 0.

Anyone know the reason? I execute the command in a PC, and the system information as follows:

Geth version: 1.8.18-stable-c894c2d7(quorum-v2.2.5) OS & Version: Linux/Ubuntu18.04 quorum brach is master, I compiled for PC and raspberry pi. consensus : Istanbul-BFT

[prd-fox]

What consensus mechanism are you running (Raft/IBFT/Clique)? Are you able to share your genesis file?

eth.hashrate will only be non-zero for PoW consensus algorithms, which Quorum does not support.

[shuzang]

@prd-fox The consensus is IBFT. The genesis is generated by istanbul-tools, and I just update the alloc field with the accouts generated by myself.

{
    "config": {
        "chainId": 10,
        "homesteadBlock": 0,
        "eip150Block": 0,
        "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "eip155Block": 0,
        "eip158Block": 0,
        "byzantiumBlock": 0,
        "constantinopleBlock": 0,
        "istanbul": {
            "epoch": 30000,
            "policy": 0
        },
        "txnSizeLimit": 64,
        "isQuorum": true
    },
    "nonce": "0x0",
    "timestamp": "0x5d7c4ae8",
    "extraData": "0x0000000000000000000000000000000000000000000000000000000000000000f89af8549493c20b1ffa9bf8738bf194d5203e3d2e2a48428d94ff75bd429c43de6719c2983c1e991b027990955994f22670e572a42729a2c10fb26f57bba46cbc3a4294350686ae7615e87a046fc4261fe58fda3872aa65b8410000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c0",
    "gasLimit": "0xe0000000",
    "difficulty": "0x1",
    "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
    "coinbase": "0x0000000000000000000000000000000000000000",
    "alloc": {
        "b619ead9d3d72b675a471b3d8ff67673de8ae7f4": {
            "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
        },
        "4cd5ae20dba37c96717f328dc6c02e1c1927be1c": {
            "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
        },
        "461d9bc69d4a32cb599310843bf5bf88342cc03c": {
            "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
        },
        "51ef0c6536e69e2ea46f5ec5e150da423305c63d": {
            "balance": "0x446c3b15f9926687d2c40534fdb564000000000000"
        }
    },
    "number": "0x0",
    "gasUsed": "0x0",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
}

[zzy96]

After you generate extraData with istanbul tool, do you configure your nodeKey as per extraData?

[shuzang]

What's your mean? Modify all node's extraData Field in their genesis file using their own nodeKey? I just cope the nodeKey to every node's data/geth directory follow tutorial-Creating a newwork from scratch. Then executing geth init in every node. Should I add a step after the copy action?

[prd-fox]

The genesis file looks like. Are all the nodes running and can see each other? What is the output of admin.peers?

[shuzang]

@prd-fox It seems like find the error. All nodes can see each other before I think, because run admin.peers can display all nodes.

> admin.peers
[{
    caps: ["istanbul/64"],
    enode: "enode://c286de4e89f4f209a6b32284b31829251ccb23bf5ab3bbe57ba08754392635ae755848dd6c4f367c7d92284e54e4b9f0d1a896924309380eb947e3b8c6641392@192.168.191.3:30303?discport=0",
    id: "4f9a5532353149bb2d21cbdaff75bd429c43de6719c2983c1e991b0279909559",
    name: "Geth/v1.8.18-stable-c894c2d7(quorum-v2.2.5)/linux-amd64/go1.11.12",
    network: {
      inbound: false,
      localAddress: "192.168.191.2:48906",
      remoteAddress: "192.168.191.3:30303",
      static: true,
      trusted: false
    },
    protocols: {
      istanbul: {
        difficulty: 1022,
        head: "0x9da0362bac7ea2b4764571a06fd272fe81a9efbf0ce0fa0be7f28e199b5e08ac",
        version: 64
      }
    }
}, {
    caps: ["istanbul/64"],
    enode: "enode://214dce3278a2b45fb0bf2a1d53c24eb213c5cbb08307e842feab0202cad4f685c5c62a4197d29318f07eb813bf4189db05096b551849039bf81fb74f0211320f@192.168.191.5:60480",
    id: "5e62fd3b39e5ae259d604f90350686ae7615e87a046fc4261fe58fda3872aa65",
    name: "Geth/v1.8.18-stable(quorum-v2.2.5)/linux-arm/go1.11.6",
    network: {
      inbound: true,
      localAddress: "192.168.191.2:30303",
      remoteAddress: "192.168.191.5:60480",
      static: false,
      trusted: false
    },
    protocols: {
      istanbul: {
        difficulty: 1022,
        head: "0x9da0362bac7ea2b4764571a06fd272fe81a9efbf0ce0fa0be7f28e199b5e08ac",
        version: 64
      }
    }
}, {
    caps: ["istanbul/64"],
    enode: "enode://cb50baa67204df2246b143e2982e40a89b2924e5c19e2834876c34042f0a81a2e2604ab210d19a048762f5355258d9840932ba868227857d928495d398c04af0@192.168.191.4:30303?discport=0",
    id: "c31b4abe77e8a91a1a03d06ff22670e572a42729a2c10fb26f57bba46cbc3a42",
    name: "Geth/v1.8.18-stable(quorum-v2.2.5)/linux-arm/go1.11.6",
    network: {
      inbound: false,
      localAddress: "192.168.191.2:36478",
      remoteAddress: "192.168.191.4:30303",
      static: true,
      trusted: false
    },
    protocols: {
      istanbul: {
        difficulty: 1022,
        head: "0x9da0362bac7ea2b4764571a06fd272fe81a9efbf0ce0fa0be7f28e199b5e08ac",
        version: 64
      }
    }
}]

But Today I run again, then find it's unstable. Even I can see all nodes, maybe a or two ndes will disappear a few minutes later. how can I make the connect stable? use bootnode or something else? I think my network should be ok, because all nodes are in a LAN. You can see that in output of admin.peers by ip address. And now I only put static-nodes.json in NodeA，

[prd-fox]

I would definitely leave the static-nodes.json file in all the nodes, otherwise they will potentially rely on Node A being active (if discovery is disabled, which it is in the guide).

If the nodes are originally seeing each other, then disconnecting, that certainly points to a networking issue. Are you able to upload logs from one or two of the nodes? This would indicate when and why a node disconnected.

I assume you aren't seeing the block count increase?

[shuzang]

@prd-fox It's autually a networking issue. I have not notice the log before. But it have already tell me the reason. The package loss rate and delay are really high. And I find it seems due to I install node in vmware and use bridge mode rather than connect to WiFi directly. Thanks.

INFO [09-14|10:56:00.419] Commit new mining work                   number=1 sealhash=1305ae…019d90 uncles=0 txs=0 gas=0 fees=0 elapsed=556.954µs
TRACE[09-14|10:56:00.420] Dial error                               task="staticdial 5e62fd3b39e5ae25 192.168.191.5:30303" err="dial tcp 192.168.191.5:30303: connect: connection refused"
DEBUG[09-14|10:56:00.421] Can't resolve node                       id=0x8e6a40         err="discovery is disabled"
TRACE[09-14|10:56:00.421] Dial task done                           task="staticdial 5e62fd3b39e5ae25 192.168.191.5:30303"
TRACE[09-14|10:56:00.420] handleRequest                            address=0x93C20b1ffA9BF8738BF194d5203e3D2E2A48428d state="Accept request" seq=1 number=1 hash=23cc4d…b11876
TRACE[09-14|10:56:00.422] Dial error                               task="staticdial c31b4abe77e8a91a 192.168.191.4:30303" err="dial tcp 192.168.191.4:30303: connect: connection refused"

[prd-fox]

Ok, great that you found the cause! Can this be closed then?