Maciej
dc69dbba72
**Overview:** Adding an extra malus variant focusing on disputing finalized blocks. It will: - wrap around approval-voting - listen to `OverseerSignal::BlockFinalized` and when encountered start a dispute for the `dispute_offset`th ancestor - simply pass through all other messages and signals Add zombienet tests testing various edgecases: - disputing freshly finalized blocks - disputing stale finalized blocks - disputing eagerly pruned finalized blocks (might be separate PR) **TODO:** - [x] Register new malus variant - [x] Simple pass through wrapper (approval-voting) - [x] Simple network definition - [x] Listen to block finalizations - [x] Fetch ancestor hash - [x] Fetch session index - [x] Fetch candidate - [x] Construct and send dispute message - [x] zndsl test 1 checking that disputes on fresh finalizations resolve valid Closes #1365 - [x] zndsl test 2 checking that disputes for too old finalized blocks are not possible Closes #1364 - [ ] zndsl test 3 checking that disputes for candidates with eagerly pruned relay parent state are handled correctly #1359 (deferred to a separate PR) - [x] Unit tests for new malus variant (testing cli etc) - [x] Clean/streamline error handling - [ ] ~~Ensure it tests properly on session boundaries~~ --------- Co-authored-by: Javier Viola <javier@parity.io> Co-authored-by: Marcin S. <marcin@realemail.net> Co-authored-by: Tsvetomir Dimitrov <tsvetomir@parity.io>
malus
Create nemesis nodes with alternate, at best faulty, at worst intentionally destructive behavior traits.
The first argument determines the behavior strain. The currently supported are:
suggest-garbage-candidateback-garbage-candidatedispute-ancestor
Integration test cases
To define integration tests create file
in the toml format as used with zombienet
under ./integrationtests describing the network to spawn and
also the zndsl file (with .zndsl extension ) using the format
defined in the (DSL[(Domain Specific Language)]) doc.
Usage
Assumes you already gained permissiones, ping in element
@javier:matrix.parity.ioto get access. and you have cloned the zombienet repo.
To launch a test case in the development cluster use (e.g. for the ./node/malus/integrationtests/0001-dispute-valid-block.toml):
# declare the containers pulled in by zombie-net test definitions
export MALUS_IMAGE=docker.io/paritypr/malus:4131-ccd09bbf
export ZOMBIENET_INTEGRATION_TEST_IMAGE=docker.io/paritypr/synth-wave:4131-0.9.12-ccd09bbf-29a1ac18
export COL_IMAGE=docker.io/paritypr/colander:4131-ccd09bbf
# login chore, once, with the values as provided in the above guide
gcloud auth login
gcloud config set project "parity-zombienet"
gcloud container clusters get-credentials "parity-zombienet" --zone "europe-west3-b" --project parity-zombienet
# launching the actual test
cd zombienet
npm run build
node dist/cli.js test <path to polkadot repo>/node/malus/integrationtests/0001-dispute-valid-block.zndsl
# Access logs (in google cloud storage)
gsutil ls gs://zombienet-logs/zombie-<namespace uniqueId>/logs/
This will also teardown the namespace after completion.
Container Image Building Note
In order to build the container image you need to have the latest changes from Polkadot and Substrate master branches.
pwd # run this from the current dir
podman build -t paritypr/malus:v1 -f Containerfile ../../..