Version 5.3.0

What's Changed

This new minor version addresses an issue raised by @nalepae in #17, related to differences between complete and minimal implementations.

The previous v5.2.1 release had mistakenly assumed a minimal implementation in some places, by setting should_succeed: false in some cases where a complete database would be capable of signing. This caused erroneous failures on complete implementations.

To address this with the least disruption to existing test runners, we have kept the values of should_succeed to mean "can a minimal implementation sign this?", while adding a new field should_succeed_complete to carry the information about whether a complete implementation should be capable of signing.

Therefore the changes required by maintainers of minimal implementations are:

• Update deserialisation to allow for the existence of the should_succeed_complete field. It should be otherwise ignored.
• Update the test runner to forbid false positives. With the new field it should no longer be necessary to fail signing when should_succeed is true but signing is blocked by the watermark. These cases are now covered by should_succeed=false, should_succeed_complete=true.
• Report any failures or issues in case further adjustments are required to accommodate all implementations.

The changes required by maintainers of complete implementations are similar, but should use the should_succeed_complete field.

For full semantics please see the README: https://github.com/eth-clients/slashing-protection-interchange-tests#how-to-run.

For more detail of the rationale for the changes see #17 & #18.

Full Changelist

• Updating URL for eth-clients by @fredriksvantes in #13
• Clarify that signed messages should be remembered by @michaelsproul in #14
• Update tests with should_succeed_complete by @michaelsproul in #18

New Contributors

• @fredriksvantes made their first contribution in #13

Full Changelog: v5.2.1...v5.3.0