Discussion thread for EIP-3076:
A JSON interchange format for Serenity (eth2) that contains the necessary slashing protection information required to safely migrate keys between clients.
Discussion thread for EIP-3076:
A JSON interchange format for Serenity (eth2) that contains the necessary slashing protection information required to safely migrate keys between clients.
Discussions with Trent Mohay on the Eth R&D discord raised some deficiencies in the current spec when it comes to potentially invalid data. I’ve been expanding the test coverage in the test repo, and have a few decisions that I need stakeholders to provide feedback on.
Presently the spec says nothing of the case where the data
array contains multiple
entries with the same pubkey
. We have three options:
ACCEPT
: explicitly allow duplicate pubkeysREJECT
: explicitly reject duplicate pubkeysABSTAIN
: leave duplicate pubkey semantics up to the implementationACCEPT
ACCEPT
semantics, likely by accident.REJECT
ABSTAIN
The duplicate_pubkey_not_slashable
test case exercises this code path.
It’s possible for an interchange file to contain blocks and attestations that
are mutually slashable, i.e. the interchange file contains evidence that the
validator has already committed a slashable offence. It’s also possible for
an interchange to contain messages that are slashable with respect to ones already
in the database.
Our options:
ACCEPT
: require implementations to import files even if they contain slashable dataACCEPT_PARTIAL
: require implementations to import all validators that are not slashable,REJECT
: require implementations to reject any imported file if it contains slashable dataABSTAIN
: allow implementations to choose a semantics that works for themACCEPT
ACCEPT_PARTIAL
ACCEPT
: more inputs accepted, less user confusionACCEPT
: compatible with databases that can’t store slashable messages (see REJECT
).REJECT
ACCEPT
semantics would greatlyABSTAIN
The following test cases exercise these code paths:
single_validator_slashable_blocks
single_validator_slashable_attestations_double_vote
single_validator_slashable_attestations_surrounds_existing
single_validator_slashable_attestations_surrounded_by_existing
The specification doesn’t currently place ordering requirements on blocks or attestations
within a file, but it may simplify implementation to do so.
ORDERED
: require messages to be ordered, and for implementations to reject unordered filesUNORDERED
: allow messages to be unordered, and require implementations to accept unordered filesABSTAIN
: allow implementations to choose ordered or unordered semanticsORDERED
UNORDERED
ABSTAIN
single_validator_out_of_order_blocks
single_validator_out_of_order_attestations
Presently signing roots are optional, but this has some downsides, so we could consider making them
mandatory.
MANDATORY
: require signing_root
on all blocks and attestationsOPTIONAL
: allow signing_root
to be omittedMANDATORY
Decision 2: REJECT
) Importing the same file twice if itOPTIONAL
Need input on the above decisions from Web3Signer, Teku, Prysm, Nimbus, and my co-author @sachayves
My votes are for:
REJECT
REJECT
, or ACCEPT_PARTIAL
ORDERED
MANDATORY
, especially if Decision 2 is REJECT
For web3signer we’re thinking:
This is really based on the fact that Web3signer treats the import file as though it were as trusted as our local db - thus if the import conflicts with the database, there’s no way of deciding which is right or wrong; so we keep them both - which in turn probably means you don’t want to sign either conflicting entry again (if given the opportunity)
These are my votes:
REJECT
user have to fix his input file and retryACCEPT_PARTIAL
if detected as slashable skip the data point (happened to me many times that i wasn’t caught on slashble offences as the network didn’t propagate my slashable attestation ) as a validator i just want to keep participate as long as i am not slashedUNORDERED
import can handle writing to the right location in its own implementationOPTIONAL
as in minimal data format blocking all attestations when signing root is missing for a certain epoch can be a default1: ACCEPT, It makes it easier to combine files and doesn’t seem like its at all difficult to support. Why make it hard for users? Implementations shouldn’t generate files with duplicate public keys though.
2: ACCEPT/ABSTAIN - teku just keeps a high water mark
arguably, if it’s been signed, it should be considered, and the fact that it was slashable is less important than not signing something that potentially interacts with those, so load it so you protect from signing again.
3: UNORDERED - the data format should be as permissive as possible, the implementation can order if required.
4: OPTIONAL - or could remain an implementation decision. Teku has no plans to support providing signing roots, and it would be a difficult argument to have a week before we go to RC.
It’s probably worth noting that the general philosophy for Teku and Web3Signer is:
And just to clarify for Decision 4, Signing Roots - they must be optional for Teku. No point making it an implementation decision or you couldn’t migrate slashing records from Teku to anything that requires signing roots.
Web3signer can work with optional signing-roots, I prefer to have them, but not at the expense of other clients.
Thank you all for the feedback. How about we move forward with these decisions:
ACCEPT
, with caveat “Implementations shouldn’t generate files with duplicate public keys”ACCEPT_PARTIAL
, abstain when it comes to whether or not slashable data must be imported (it would be very hard to support ACCEPT
in Lighthouse right now)UNORDERED
OPTIONAL
The logic for (1) and (3) is that we should be liberal in what we accept, and these are simple cases.
The logic for (2) is similar – mandate accepting as much as possible, with an acknowledgement that accepting everything is not feasible for all implementations.
The logic for (4) is: keep the standard compatible with varied implementations (e.g. Teku). Other implementations just need to take care that the null
/missing root compares as incompatible with every other root (including itself). Just like NaN
Condition 5 is currently not consistent with single_validator_resign_attestation.json tests, and Condition 5 is not consistent with Condition 2.
Condition 5 could be updated as follows:
Refuse to sign any attestation with target epoch less than or equal to the minimum target epoch present in that signer’s attestations (as seen in data.signed_attestations), except if it is a repeat signing as determined by the
signing_root
.
See `single_validator_resign_attestation.json`: Inconsistency with the EIP-3076 specification? · Issue #15 · eth-clients/slashing-protection-interchange-tests · GitHub for more details.