From bc63f99ea6eb0af9be55b7973b48c24021355a58 Mon Sep 17 00:00:00 2001 From: Kim De Mey Date: Tue, 22 Feb 2022 15:55:47 +0100 Subject: [PATCH] Update local_testnet.md (#976) More information on how the local testnet startup and the testing of it works. --- fluffy/docs/local_testnet.md | 58 ++++++++++++++++++++++++++---------- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/fluffy/docs/local_testnet.md b/fluffy/docs/local_testnet.md index 68d69a1cf..d2d5ca34b 100644 --- a/fluffy/docs/local_testnet.md +++ b/fluffy/docs/local_testnet.md @@ -25,20 +25,48 @@ To run the nodes without testing and keep them alive for manual testing: ./fluffy/scripts/launch_local_testnet.sh --enable-htop ``` -## Test flow of the local testnet +## Details of the test -Following testing steps are done for the Discovery v5 network and for the Portal -networks: - 1. Attempt to add the ENRs of all the nodes to each node its routing table: - This is to quickly simulate a network that has all the nodes propagated - around. - 2. Select at random a node id of one of the nodes. Let every node do a lookup - for this node id. +### Initial set-up -For the Portal history network a content lookup test is done: - 1. Node 0 stores `n` amount of block headers. Each block header is offered - as content to `x` amount of nodes. The content should get propagated through - the network via neighborhood gossip. - 2. For each block header hash, an `eth_getBlockByHash` JSON-RPC request is done - to each node. A node will either load this from its own database or do a - content lookup and retrieve it from the network. +Following inital steps are done to set up the Discovery v5 network and the +Portal networks: + 1. Nodes join the network by providing them all with one and the same + bootstrap node at start-up. TODO: The amount of bootstrap nodes should become + configurable. + 2. Attempt to add the ENRs of all the nodes to each node its routing table: + This is done in order to quickly simulate a network that has all the nodes +propagated around. A custom JSON-RPC call is used for this. + 3. Select, at random, a node id of one of the nodes. Let every node do a + lookup for this node id. + This is done to validate that every node can successfully lookup a specific + node in the DHT. + +### Sharing the data around + +How the content gets shared around: + + 1. First one node (the bootstrap node) will get triggered by a JSON-RPC call + to load a data file that contains `n` amount of blocks (Currently + `[header, txs, uncles]`, should probably become + `[header, [txs, uncles], receipts]`), and to propagate these over the network. + This is done by doing offer request to `x` (=6 currently) neighbours to that + content its id. This is practically the neighborhood gossip at work, but then + initiated on the read of each block in the provided data file. + 2. Next, the nodes that accepted and received the content will do the same + neighborhood gossip mechanism with the received content. And so on, until no + node accepts any offers any more and the gossip dies out. This should + propagate the content to (all) the neighbours of that content. TODO: This + depends on the radii set and the amount of nodes in the network. More starter + nodes are required to propagate with nodes at lower radii. + 3. The test binary will then read the same data file and, for each block hash, + an `eth_getBlockByHash` JSON-RPC request is done to each node. A node will + either load the block header or body from its own database or do a content + lookup and retrieve them from the network, this depends on its own node id and + radius. + Following checks are currently done on the response: + * Check if the block header and body content was found. + * The hash in returned data of eth_getBlockByHash matches the requested + one. + * In case the block has transactions, check the block hash in the + transaction object.