ethereumsmartcontractspantheon

Pantheon On chain permissioning whitelisted nodes will not sync


I have successfully run the boot node, successfully deployed the contracts, and successfully whitelisted a second node (transaction confirms and the node shows up in the permissions UI.

Enode URL's

Enode1 (boot node): enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303 
Enode2: enode://479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149@127.0.0.1:30304

Boot params

//Boot node
pantheon --data-path=data --genesis-file=../cliqueGenesis.json --bootnodes --network-id 123 --rpc-http-enabled  --rpc-http-api=ETH,NET,CLIQUE --host-whitelist="*" --rpc-http-cors-origins="*"  --rpc-http-host=0.0.0.0 --rpc-ws-enabled --rpc-ws-host=0.0.0.0 --rpc-ws-port=7001 --permissions-nodes-contract-enabled --permissions-nodes-contract-address="0x0000000000000000000000000000000000009999" --logging=TRACE

//2nd node
pantheon --data-path=data --genesis-file=../cliqueGenesis.json --bootnodes="enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303" --network-id 123 --p2p-port=30304 --rpc-http-enabled --rpc-http-host=0.0.0.0 --rpc-http-api=ETH,NET,CLIQUE --host-whitelist="*" --rpc-http-cors-origins="*" --rpc-http-port=8546 --rpc-ws-enabled --rpc-ws-host=0.0.0.0 --rpc-ws-port=7002  --permissions-nodes-contract-enabled --permissions-nodes-contract-address="0x0000000000000000000000000000000000009999" --logging=TRACE

Boot node is successfully producing blocks and if I remove the onchain permissioning flags the nodes sync fine.

When booting the second node it looks like the peer discover finds the boot node but just won't sync with it.

2019-08-02 09:54:50.077+00:00 | nioEventLoopGroup-2-1 | INFO  | NettyConnectionInitializer | P2P network started and listening on /0:0:0:0:0:0:0:0:30304
2019-08-02 09:54:50.079+00:00 | main | INFO  | PeerDiscoveryAgent | Starting peer discovery agent on host=0.0.0.0, port=30304
2019-08-02 09:54:50.236+00:00 | vert.x-eventloop-thread-1 | INFO  | VertxPeerDiscoveryAgent | Started peer discovery agent successfully, on effective host=0:0:0:0:0:0:0:0 and port=30304
2019-08-02 09:54:50.277+00:00 | main | TRACE | NodePermissioningController | Node permissioning: Checking enode://479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149@127.0.0.1:30304 -> enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303
2019-08-02 09:54:50.279+00:00 | main | TRACE | NodePermissioningController | Node permissioning - Sync Status: Permitted enode://479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149@127.0.0.1:30304 -> enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303
2019-08-02 09:54:50.291+00:00 | main | DEBUG | RecursivePeerRefreshState | Start peer search.
2019-08-02 09:54:50.299+00:00 | main | TRACE | NodePermissioningController | Node permissioning: Checking enode://479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149@127.0.0.1:30304 -> enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303
2019-08-02 09:54:50.303+00:00 | main | TRACE | NodePermissioningController | Node permissioning - Sync Status: Permitted enode://479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149@127.0.0.1:30304 -> enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303
2019-08-02 09:54:50.305+00:00 | main | DEBUG | RecursivePeerRefreshState | Initiating bonding round with 1 candidates
2019-08-02 09:54:50.349+00:00 | main | INFO  | DefaultP2PNetwork | Enode URL enode://479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149@127.0.0.1:30304
2019-08-02 09:54:50.367+00:00 | main | INFO  | DefaultSynchronizer | Starting synchronizer.
2019-08-02 09:54:50.374+00:00 | main | INFO  | FullSyncTargetManager | No sync target, wait for peers.
2019-08-02 09:54:50.391+00:00 | main | DEBUG | WaitForPeerTask | Waiting for new peer connection. 0 peers currently connected.
2019-08-02 09:54:50.427+00:00 | vert.x-eventloop-thread-1 | TRACE | DiscoveryProtocolLogger | <<< Sending  PING  packet to peer 0xe2246659b988d7d58afdfba0184fdc2d (enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303): Packet{type=PING, data=PingPacketData{from=Endpoint{host='127.0.0.1', udpPort=30304, getTcpPort=30304}, to=Endpoint{host='127.0.0.1', udpPort=30303, getTcpPort=30303}, expiration=1564739750318}, hash=0xb086c0428ca6e4288d442c852096536b195fae094dcdb22425714b4e985af0c3, signature=SECP256K1.Signature{r=59371524344037357194017148306924807840555029457334576942167910342864972320181, s=46690608351691036854421743205564797548033242302421808752532793676769394264052, recId=1}, publicKey=0x479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149}
2019-08-02 09:54:50.421+00:00 | main | INFO  | JsonRpcHttpService | Starting JsonRPC service on 0.0.0.0:8546
2019-08-02 09:54:50.482+00:00 | vert.x-eventloop-thread-1 | DEBUG | AbstractByteBuf | -Dio.netty.buffer.checkAccessible: true
2019-08-02 09:54:50.483+00:00 | vert.x-eventloop-thread-1 | DEBUG | AbstractByteBuf | -Dio.netty.buffer.checkBounds: true
2019-08-02 09:54:50.492+00:00 | vert.x-eventloop-thread-1 | DEBUG | ResourceLeakDetectorFactory | Loaded default ResourceLeakDetector: io.netty.util.ResourceLeakDetector@2d542e35
2019-08-02 09:54:50.543+00:00 | vert.x-eventloop-thread-1 | DEBUG | Recycler | -Dio.netty.recycler.maxCapacityPerThread: 4096
2019-08-02 09:54:50.544+00:00 | vert.x-eventloop-thread-1 | DEBUG | Recycler | -Dio.netty.recycler.maxSharedCapacityFactor: 2
2019-08-02 09:54:50.545+00:00 | vert.x-eventloop-thread-1 | DEBUG | Recycler | -Dio.netty.recycler.linkCapacity: 16
2019-08-02 09:54:50.547+00:00 | vert.x-eventloop-thread-1 | DEBUG | Recycler | -Dio.netty.recycler.ratio: 8
2019-08-02 09:54:51.070+00:00 | vert.x-eventloop-thread-1 | INFO  | JsonRpcHttpService | JsonRPC service started and listening on 0.0.0.0:8546
2019-08-02 09:54:51.073+00:00 | main | INFO  | WebSocketService | Starting Websocket service on 0.0.0.0:7002
2019-08-02 09:54:51.103+00:00 | vert.x-eventloop-thread-1 | INFO  | WebSocketService | Websocket service started and listening on 0.0.0.0:7002
2019-08-02 09:54:51.117+00:00 | main | INFO  | Runner | Ethereum main loop is up.
2019-08-02 09:54:52.427+00:00 | vert.x-eventloop-thread-0 | TRACE | DiscoveryProtocolLogger | <<< Sending  PING  packet to peer 0xe2246659b988d7d58afdfba0184fdc2d (enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303): Packet{type=PING, data=PingPacketData{from=Endpoint{host='127.0.0.1', udpPort=30304, getTcpPort=30304}, to=Endpoint{host='127.0.0.1', udpPort=30303, getTcpPort=30303}, expiration=1564739752329}, hash=0xf8e7ad298b63d7dae82c16cbbe3a1b5c27dd93f007fd0008451de95988b08065, signature=SECP256K1.Signature{r=108161254540768041112331117880317281197939903194186394721153575210189226990970, s=25335905657342236875185697177877343526807833775651780225153166459223878285973, recId=1}, publicKey=0x479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149}
2019-08-02 09:54:55.341+00:00 | vert.x-eventloop-thread-1 | DEBUG | RecursivePeerRefreshState | Bonding round timed out
2019-08-02 09:54:55.343+00:00 | vert.x-eventloop-thread-1 | DEBUG | RecursivePeerRefreshState | Iterative peer search complete.  1 peers processed over 1 rounds.
2019-08-02 09:54:55.355+00:00 | vert.x-eventloop-thread-0 | TRACE | DiscoveryProtocolLogger | <<< Sending  PING  packet to peer 0xe2246659b988d7d58afdfba0184fdc2d (enode://e2246659b988d7d58afdfba0184fdc2d31dd85e601770eaed91466eb6e13cbd18d394bcc728db5669b5e753a78569b063a79c5f7071a2893358b6c3582b1d0b3@127.0.0.1:30303): Packet{type=PING, data=PingPacketData{from=Endpoint{host='127.0.0.1', udpPort=30304, getTcpPort=30304}, to=Endpoint{host='127.0.0.1', udpPort=30303, getTcpPort=30303}, expiration=1564739755335}, hash=0x55faf76e5e7b509dd4b0df79d3c9a4faf51df16e38a050f06996d0600f92cae8, signature=SECP256K1.Signature{r=28609065823694674016209372508335203365319878204703173661146642900828039667693, s=54964792650200075745336870062081458264148378812873627359872745664462351621443, recId=0}, publicKey=0x479ac6c64689fac07096047dc2dfb6a3c99143ffa05e8a40e1d70fd8ae180aabd4f6079a4b897d47dc5877d513b3071cbaa58c9f1d8b57d24520308359e2c149}
2019-08-02 09:54:55.399+00:00 | EthScheduler-Timer-0 | INFO  | FullSyncTargetManager | No sync target, wait for peers.

Solution

  • I'm one of the developers involved in the Pantheon Permissioning work.

    It would be good to see the logs of the bootnode as well to get a better understanding of what might be wrong.

    and successfully whitelisted a second node

    Let me ask you one thing, have you added to the whitelist BOTH the bootnode and the second node? The bootnode also needs to be whitelisted.

    What I believe is happening is that the second node is trying to connect to the bootnode (we have a rule that the nodes will trust their bootnodes until they are in sync with the network) but the bootnode is not accepting the connection because, when it checks the smart contract, it looks for a rule exist(nodeA, nodeB) in the whitelist. And if the bootnode is not on the whitelist, this rule will never evaluate to true.

    If you haven't added the bootnode to the whitelist, try to do so and let me know if it solves your issue!