ethereum/portal-hive

Portal Network end-to-end test harness

portal-hive - Portal network end-to-end test harness

forked from ethereum Hive

Hive is a system for running integration tests against Portal Network clients.

• Test results can be seen on https://portal-hive.ethdevops.io/

To read more about hive, please check the documentation.

License

The hive project is licensed under the GNU General Public License v3.0. You can find it in the COPYING file.

portal-hive's Issues

Docs: instructions on running against a specific branch or local build

@ogenev How would I run portal-hive against a local build of trin? It would be useful to have a section about that in the docs here: https://github.com/carver/portal-hive/blob/main/docs/overview.md

In my particular case, I want to test my local changes in trin to see if #20 will start working.

Implement test matching pattern in hivesim-rs

Running and matching on a specific portal hive test helps us with local development and debugging.

Example implementation in GO: https://github.com/ethereum/portal-hive/blob/main/hivesim/testmatch.go

Implement test matching pattern in hivesim-rs

Running and matching on a specific portal hive test helps us with local development and debugging.

Example implementation in GO: https://github.com/ethereum/portal-hive/blob/main/hivesim/testmatch.go

Expectation of node in test portal_historyRoutingTableInfo of simulation ts-sim-test

The portal_historyRoutingTableInfo test launches Portal ping message in both directions of all the tested nodes.

Next it will call portal_historyRoutingTableInfo to see if all nodes have the other nodes in their routing tables.

However, an ENR only gets transmitted in a discv5 handshake message, and only the ENR of the requesting side is send.
This means that ENR's do not get transferred in all directions in this test scenario. This is why currently tests with Fluffy will fail this test scenario.

I'm curious what other clients do here to make this test pass. Do they actively send a FindNodes request to get this ENR (seems like something that could still fail in this test due to race conditions)? Or do they just simply add the ENR that is passed along the portal_historyPing method (Not really specified behaviour) to the routing table?

Issue in ts-sim-test for portal_historyRoutingTableInfo when testing with single client

I think there is a bug in the filtering of the clients when you run this test for one specific client: https://github.com/ethereum/portal-hive/blob/main/hivesim-ts/src/simulators/ts-sim-test/main.ts#L80

I.e. using the flag --client fluffy or another single client.
In that scenario the test will run between two fluffy clients, however both will get filtered out, meaning that it will not test for the proper amount of nodes in the routing table.

Solve portal-hive issue "Error response from daemon: No such container: CONTAINER"

Remove data-radius argument from ping tests

To get in line with ethereum/portal-network-specs#202

Upgrade simulators to use ethportal-api version tag instead of commit for selecting library version

#127 (comment)

Why is portal-hive tagged to a particular hash of ethportal-api? If possible I think it's much more preferable to tag to the version

Upgrade simulators to use ethportal-api version tag instead of commit for selecting library version

Add simulator docker builds to CI tests

Weth Contract owner

I am trying to find my private keys to withdraw my assets.

portal-hive nodes have access to external networks, causing test contamination

IpV4 UDP Socket: Some(194.33.40.238:9102)
IpV4 UDP Socket: Some(194.33.40.238:9101)

I was trying to work on tests and I found that when I ran fluffly it was connecting to bootstrap nodes. This has the possibility to contaminate tests. This doesn't mean we should change fluffy. But instead make it so the docker nodes used in simulaters are isolated per test.

portal_historyGetEnr*/portal_historyDeleteEnr*/(anything that uses nodeid as param) won't seralize properly

This will either one fixed once we revert our semi NodeID transition to native sigp/enr library or we wait for the new version of sigp/enr which fixes this issue. So if we are in a rush we can just revert the semi done conversion PR and do the conversion after the new sigp/enr with the fixes is our. Or we can just wait till the new sigp/enr version with the fixes is out.

Either way after this is resolved I think in ethportal we should probably have a unit test which tests if all of the standard types in the spec serialize correctly. To provent this from happening again.

Ability to run portal-hive tests directly against local binary of the client

When working on portal-hive failures that are related to a client, currently we need to rebuild the client its docker image.
How long this takes, does depend on the implementation of the Dockerfile for the client, but will always take more than then just building it locally, which you usually would do anyhow when testing.

It would be nice if we had some special debugging runner that could run the tests from a provided local binary.

This is not a crucial nor urgent feature, but it does seem there is some interest for this at least.

Add `historyPing` endpoint test to RPC compat

We don't currently have an RPC test for the historyPing endpoint to verify client compatibility.

Add one...

List of tests that need to be written

Let's add things to this list:

• rpc-compat:
  • portal_historyFindNodes (See that there was an incompatibility in trin. This checkbox replaces the issue: ethereum/trin#704 )