status-im
/
nimbus-eth1
mirror of https://github.com/status-im/nimbus-eth1.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update local_testnet.md (#976) 

More information on how the local testnet startup and the testing of it works.
This commit is contained in:
Kim De Mey 2022-02-22 15:55:47 +01:00 committed by GitHub
parent 6f21c232ae
commit bc63f99ea6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 43 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
fluffy/docs/local_testnet.md
View File

@ -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.