The P2P and discovery ports are now always dynamically assigned (set to port 0 when starting pantheon) to guarantee they always select an available port.
This however means you can't determine the ports that will be used or the enode URL for a node before it has started. The main effect of this is that nodes have to use the peer discovery process to discover each other rather than having every node in the network in the boot nodes list. A single node is started first with no bootnodes, then other nodes are started with that node as their bootnode and use peer discovery to find the other nodes as they start.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Create a new PrivateContractAddress generation
* Remove resolveAccountFromPublicState
* Change method sign to BytesValue
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Start P2P network synchronously so the ports are guaranteed to be known before we write the ports file
Include the P2P TCP port in ports file even when peer discovery is disabled.
Load information from the advertised peer rather than the discovery listening socket.
Fix admin_nodeInfo to include the ?discport param in the enode URI when the discovery port differs from the P2P port.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
rpc_module enumerates the modules exposed to RPC. This allows the
`geth attach` geth javascript console to attach to Pantheon and use the
json-rpc APIs that pantheon and geth share.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Implement admin_nodeInfo RPC call. This involved bringing data from the
ethNetworkConfig and genesis json into the rpc call, so it had a lot of
testing side effects.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* [PAN-2341] Created mechanism to publish sync status
* Refactoring WebSockets syncing subscription to respond to SyncStatus events
* Removing rpc-ws-refresh-delay option
* Removing ws-refresh-delay option from ATs
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Use a single thread to persist received world state nodes to avoid RocksDB timeouts due to contention on the write lock.
* Fix RocksDbTaskQueue so it doesn't read stale data when resuming a transfer.
* Skip downloading empty trie nodes.
* Log unhandled errors from world state download requests
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Instantiate individual metrics where they're used
* Cache prometheus metrics to allow "duplicate" creation of metrics
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Adds a PeerValidator that, when the Dao fork milestone is in use, checks that the Dao block is present on each peer when they connect and disconnects them if they are on the wrong chain.
Also:
* Make GetHeadersFromPeer task stricter in validating response matches.
* Update BlockHeadersMessage to return a list of headers
* Add more controls to DeterministicEthScheduler test util
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Do parallel extract signatures in the parallel block importer.
* remove the extraction from FullSyncBlockHandler
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
There's an issue with the world state downloader where the download process could stall. The sequence goes like:
1. Inside requestDataFromPeer thread A takes out the sendingRequests lock
2. Thread A checks shouldRequestNodeData which returns true
3. Thread A sends a request for data
4. Thread A checks shouldRequestNodeData which returns false so it exits the while loop
5. Thread B receives the response to the (only) outstanding request
6. Thread B enters shouldRequestNodeData but fails to get the sendingRequests lock so exits the method
7. Thread A releases the sendingRequests lock and exits the methods
There are now no threads checking if they should send new requests and no outstanding requests to trigger a check in the future so the download is stuck and will never make anymore progress.
The fix is to switch the order of taking out the sendingRequests lock and checking shouldRequestNodeData so we release the sendingRequests lock before we go back round the loop to check shouldRequestNodeData.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* move to an offer() instead of a put() on the downloader so that when
the task is stopped the put will see that it is done and not wait
forever.
* remove peer based focus of the task. Let subtasks pick their peers.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
There is a failure mode of IBFT whereby a validator fails to import
a block, and also fails to receive the NewBlock message from its
peers. This means said validator is unable to participate in
subsequent rounds, and may cause the network to halt.
To overcome this issue, if an IBFT validator receives messages from
a future height, it will update the "BestEstimatedHeight" of the
corresponding EthPeer object, such that the Synchroniser will
(eventually) download the requisite blocks - thus allowing the
IBFT network to continue to operate.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
--> adapt `BlockBroadcaster` to use `send` method on `EthPeer`
--> adapt `EthProtocolMamnager` to utilize `BlockBroadcaster` to disseminate newly mined block
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
Edwin Greene
Adrian Sutton
Vinicius Stevam
Danno Ferrin
mbaxter
Chris Mckay
S. Matthew English
Lucas Saldanha
Jason Frame
Ivaylo Kirilov
Trent Mohay
Sally MacFarlane