|
| 1 | +# Slashing Protection Interchange Tests (EIP-3076) |
| 2 | + |
| 3 | +Tests for EIP-3076: |
| 4 | + |
| 5 | +https://eips.ethereum.org/EIPS/eip-3076 |
| 6 | + |
| 7 | +Discussion: |
| 8 | + |
| 9 | +https://ethereum-magicians.org/t/eip-3076-validator-client-interchange-format-slashing-protection/4883 |
| 10 | + |
| 11 | +## How to run |
| 12 | + |
| 13 | +Each test directory contains an interchange file and some extra data about how to test it. |
| 14 | + |
| 15 | +For example: |
| 16 | + |
| 17 | +```json |
| 18 | +{ |
| 19 | + "name": "single_validator_genesis_attestation", |
| 20 | + "genesis_validators_root": "0x0000000000000000000000000000000000000000000000000000000000000000", |
| 21 | + "steps": [ |
| 22 | + { |
| 23 | + "should_succeed": true, |
| 24 | + "contains_slashable_data": false, |
| 25 | + "interchange": { |
| 26 | + "metadata": { |
| 27 | + "interchange_format_version": "5", |
| 28 | + "genesis_validators_root": "0x0000000000000000000000000000000000000000000000000000000000000000" |
| 29 | + }, |
| 30 | + "data": [ |
| 31 | + { |
| 32 | + "pubkey": "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c", |
| 33 | + "signed_blocks": [], |
| 34 | + "signed_attestations": [ |
| 35 | + { |
| 36 | + "source_epoch": "0", |
| 37 | + "target_epoch": "0" |
| 38 | + } |
| 39 | + ] |
| 40 | + } |
| 41 | + ] |
| 42 | + }, |
| 43 | + "blocks": [], |
| 44 | + "attestations": [ |
| 45 | + { |
| 46 | + "pubkey": "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c", |
| 47 | + "source_epoch": "0", |
| 48 | + "target_epoch": "0", |
| 49 | + "should_succeed": false |
| 50 | + } |
| 51 | + ] |
| 52 | + } |
| 53 | + ] |
| 54 | +} |
| 55 | +``` |
| 56 | + |
| 57 | +To run a test, first initialize a new (empty) slashing protection database. |
| 58 | + |
| 59 | +Then for each entry in `steps`, import the `interchange`, process the `blocks` and `attestations`, |
| 60 | +and continue to the next step. |
| 61 | + |
| 62 | +Determine the test outcome according to the meanings of each of the fields, |
| 63 | +which are as follows: |
| 64 | + |
| 65 | +* `name: string`: the name of the test-case, informational. |
| 66 | +* `genesis_validators_root: Root`: the genesis validators root to use when |
| 67 | + creating the empty slashing protection database, or to compare the import |
| 68 | + against. |
| 69 | +* `steps[i].should_succeed: bool`: whether the `steps[i].interchange` given is valid and should |
| 70 | + be imported successfully. |
| 71 | +* `steps[i].contains_slashable_data: bool`: whether the `steps[i].interchange` contains some |
| 72 | + slashable data with respect to itself or the existing contents of the database. |
| 73 | +* `steps[i].interchange: Interchange`: slashing protection interchange data as described |
| 74 | + by the spec. |
| 75 | +* `steps[i].blocks: [object]`: a list of block signings to be attempted **after** |
| 76 | + importing the `interchange`, detailed below. |
| 77 | +* `steps[i].attestations: [object]`: a list of attestation signings to be attempted **after** |
| 78 | + importing the `interchange`, detailed below. |
| 79 | + |
| 80 | +Each block in `blocks` is structured as: |
| 81 | + |
| 82 | +```json |
| 83 | +{ |
| 84 | + "pubkey": "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c", |
| 85 | + "slot": "1", |
| 86 | + "signing_root": "0x0000000000000000000000000000000000000000000000000000000000000000", |
| 87 | + "should_succeed": false, |
| 88 | + "should_succeed_complete": true |
| 89 | +} |
| 90 | +``` |
| 91 | + |
| 92 | +Your test-runner should attempt to sign a block with `signing_root` at the given slot from the given |
| 93 | +`pubkey`. The `should_succeed` field describes whether this signing should be accepted (true) or |
| 94 | +rejected (false) _by a client using a minimal strategy_. Clients using a complete strategy should |
| 95 | +instead use the `should_succeed_complete` field which allows signing to succeed in more cases. If |
| 96 | +the block is signed successfully it should be incorporated into the slashing protection database. |
| 97 | + |
| 98 | +Each attestation in `attestations` is structured as: |
| 99 | + |
| 100 | +```json |
| 101 | +{ |
| 102 | + "pubkey": "0xa99a76ed7796f7be22d5b7e85deeb7c5677e88e511e0b337618f8c4eb61349b4bf2d153f649f7b53359fe8b94a38e44c", |
| 103 | + "source_epoch": "11", |
| 104 | + "target_epoch": "12", |
| 105 | + "signing_root": "0x0000000000000000000000000000000000000000000000000000000000000000", |
| 106 | + "should_succeed": true, |
| 107 | + "should_succeed_complete": true |
| 108 | +} |
| 109 | +``` |
| 110 | + |
| 111 | +Similarly to above, your test-runner should attempt to sign an attestation with these parameters |
| 112 | +using the given `pubkey`, and succeed based on the value of |
| 113 | +`should_succeed`/`should_succeed_complete`. Again, implementations that use the _complete_ strategy |
| 114 | +should use `should_succeed_complete`. All implementations should incorporate signed attestations |
| 115 | +into the database. |
| 116 | + |
| 117 | +Note that the top-level `genesis_validators_root` is not necessarily the same |
| 118 | +as the GVR contained in the interchange, to allow us to test the case where |
| 119 | +they are mismatched. |
| 120 | + |
| 121 | +## Handling Slashable Data |
| 122 | + |
| 123 | +The `contains_slashable_data` parameter is to be interpreted as follows: |
| 124 | + |
| 125 | +- If `should_succeed` is false, then `contains_slashable_data` is irrelevant |
| 126 | +- If `contains_slashable_data` is false, then the given interchange **must** be imported |
| 127 | + successfully, and the given block/attestation checks must pass. |
| 128 | +- If `contains_slashable_data` is true, then implementations have the option to do one of two |
| 129 | + things: |
| 130 | + - Import the interchange successfully, working around the slashable data by minification |
| 131 | + or some other mechanism. If the import succeeds, all checks must pass and the test |
| 132 | + should continue to the next step. |
| 133 | + - Reject the interchange (or partially import it), in which case the block/attestation |
| 134 | + checks and all future steps should be ignored. |
| 135 | + |
| 136 | +## Downloading the tests |
| 137 | + |
| 138 | +The `tests` directory is released as a versioned `.tar.gz` on the [Releases](https://github.com/eth-clients/slashing-protection-interchange-tests/releases) page. |
| 139 | + |
| 140 | +Alternatively, you could use a git submodule. |
0 commit comments