EIP-3076: Validator client interchange format (slashing protection) #3076
Conversation
EIPS/eip-3076.md
Outdated
|
|
||
| The validator in question now runs the risk of voting for two different blocks in the same epoch (a slashable offence) for the next 225 epochs (since they've already voted on these epochs with client A, and now stand to vote on them again with client B). | ||
|
|
||
| The above situation may sound far-fetched, but it's actually very similar to the incident that occurred on the eth2 Medalla testnet on August 14th, where a time skew that affected all Prysm clients spiraled into a series of [cascading failures]((https://medium.com/prysmatic-labs/eth2-medalla-testnet-incident-f7fbc3cc934a)). It resulted in the testnet experiencing several days without finality -- an outcome that could have resulted in tens of millions of dollars in collective penalties had it occurred on mainnet. |
There was a problem hiding this comment.
There's an extra pair of parens on this URL causing CI to fail
There was a problem hiding this comment.
talk about cascading failures...
Co-authored-by: Michael Sproul <micsproul@gmail.com>
Co-authored-by: Michael Sproul <micsproul@gmail.com>
There was a problem hiding this comment.
I think the only real blocker for merging as draft here is the discussion-to link, which I need to get feedback from other EIP editors on.
Some of the feedback here is similar to my feedback on previous ETH2 EIPs, which is a bit of a hot discussion topic. The core issue is that ETH2 is mostly defined elsewhere, but there are a small number of pieces that are being defined in this repository. This creates complications when one wants to reference one from the other, since our general policy is to not have EIPs link externally. That being said, we can put off finalizing that debate until a later phase of this EIP (e.g., Last Call/Final) and for now it isn't a blocker like it was for some other ETH2 specs in here.
EIPS/eip-3076.md
Outdated
| eip: 3076 | ||
| title: Validator client interchange format (slashing protection) | ||
| author: Michael Sproul (@michaelsproul), Sacha Saint-Leger (@sachayves), Danny Ryan (@djrtwo) | ||
| discussions-to: https://discord.com/channels/595666850260713488/598292067260825641/ |
There was a problem hiding this comment.
This is the first time someone has proposed a Discord channel as a discussion-to link, so I'll need to talk with the other editors to see if that is allowed. Normally, an https://ethereum-magicians.org/ forum post is the preferred discussion-to location.
There was a problem hiding this comment.
So I realise this was a strange choice, but I couldn't think of a better one.
From EIP-1:
examples for places to discuss your EIP include Ethereum topics on Gitter, an issue in this repo or in a fork of this repo, Ethereum Magicians (this is suitable for EIPs that may be contentious or have a strong governance aspect), and Reddit r/ethereum.
Since this EIP is neither contentious nor has a strong governance aspect, I didn't think it was worth starting an Ethereum Magicians thread.
Since (I assume?) Discord channels perform much the same role as Gitter topics did back then, and the discussion has already naturally occurred there (see https://discord.com/channels/595666850260713488/598292067260825641/745665794435973170), I thought it might be appropriate.
Although, I have to say, I'm not completely happy with it, since the url is less expressive than a Gitter topic url, and one has to join the entire discord group to join the channel.
There was a problem hiding this comment.
We've started an Ethereum Magicians thread nonetheless, as it's nice to have a focussed discussion, whereas the previous eth2 channel covers a lot of other topics and is likely to be noisy:
https://ethereum-magicians.org/t/eip-3076-validator-client-interchange-format-slashing-protection/
There was a problem hiding this comment.
Replaced discord with ethereum magicians link. We can mark this as resolved?
|
|
||
| ## Abstract | ||
|
|
||
| A standard format for transferring a key's signing history allows validators to easily switch between clients without the risk of signing conflicting messages. While a [common keystore format](https://eips.ethereum.org/EIPS/eip-2335) provides part of the solution, it does not contain any information about a key's signing history. For a validator moving their keys from client A to client B, this can lead to scenarios in which client B inadvertently signs a message that conflicts with an earlier message signed with client A. |
There was a problem hiding this comment.
Keep in mind that linking to a draft EIP creates a weak dependency here that may cause problems if you want to move this to final before 2335 becomes final. If the only reason for mentioning it is as comparison, I recommend just leaving it out as it isn't really meaningful information for developers 5-10 years in the future who are reading this EIP (target audience).
| A standard format for transferring a key's signing history allows validators to easily switch between clients without the risk of signing conflicting messages. While a [common keystore format](https://eips.ethereum.org/EIPS/eip-2335) provides part of the solution, it does not contain any information about a key's signing history. For a validator moving their keys from client A to client B, this can lead to scenarios in which client B inadvertently signs a message that conflicts with an earlier message signed with client A. | ||
|
|
||
| We propose a database interchange format that helps solve this problem. The format contains a record of all blocks and attestations signed by a set of validators. |
There was a problem hiding this comment.
This content currently feels much more like motivation rather than an abstract. Ideally, the abstract is a human readable and terse version of the specification. A couple paragraphs that gives the reader the highlights of the specification without getting bogged down in the edge cases and minutia. Someone may read the abstract to try to "get the gist" of the specification and decide whether this is an EIP that they want to implement.
| [pps]: https://github.com/ethereum/eth2.0-specs/blob/v1.0.0-rc.0/specs/phase0/beacon-chain.md#proposer-slashings | ||
| [isad]: https://github.com/ethereum/eth2.0-specs/blob/v1.0.0-rc.0/specs/phase0/beacon-chain.md#is_slashable_attestation_data | ||
| [csr]: https://github.com/ethereum/eth2.0-specs/blob/v1.0.0-rc.0/specs/phase0/beacon-chain.md#compute_signing_root | ||
| [cd]: https://github.com/ethereum/eth2.0-specs/blob/v1.0.0-rc.0/specs/phase0/beacon-chain.md#compute_domain |
There was a problem hiding this comment.
Are these links likely to go stale? Normally we prefer to have everything inlined and avoid linking externally partially to avoid having to deal with dead links. Linking to the ETH2 specs repository seems a bit special, but I still have a concern over links breaking and EIP maintainers having to then deal with that down the road. This is especially true with the links being to v1.0.0-rc.0 which certainly doesn't sound like a very permanent location....
Ideal situation would be that the contents at the other end of these links be inlined, but I don't know if that is reasonable or not in this context.
There was a problem hiding this comment.
The links use a GitHub tag rather than a branch name, so will only go stale if the tag gets deleted (which I hope is unlikely).
Our intent here was to link to the latest version of the spec at time of writing, and then update the tag to v1.0.0 once it is released (before this EIP is finalised). Granted, that still doesn't stop this EIP from bitrotting if breaking changes are introduced to the Eth2 spec post 1.0, but in that case I think the EIP should be amended, or a new EIP drafted in its stead
| [isad]: https://github.com/ethereum/eth2.0-specs/blob/v1.0.0-rc.0/specs/phase0/beacon-chain.md#is_slashable_attestation_data | ||
| [csr]: https://github.com/ethereum/eth2.0-specs/blob/v1.0.0-rc.0/specs/phase0/beacon-chain.md#compute_signing_root | ||
| [cd]: https://github.com/ethereum/eth2.0-specs/blob/v1.0.0-rc.0/specs/phase0/beacon-chain.md#compute_domain | ||
|
|
There was a problem hiding this comment.
Style consistency.
|
|
||
| The specification is designed to be flexible enough to support the full variety of slashing protection strategies that clients may implement. | ||
|
|
||
| An earlier design encompassed two separate formats to achieve the same goal: `complete` and `minimal` (for the complete changelog [see here](https://hackmd.io/@sproul/Bk0Y0qdGD)). |
There was a problem hiding this comment.
It is best to just explain the rationale for a decision and leave it at that. Linking out to previous implementations will almost certainly result in dead links and for future readers it can be confusing. In this case, something like this seems like it would be fine:
| An earlier design encompassed two separate formats to achieve the same goal: `complete` and `minimal` (for the complete changelog [see here](https://hackmd.io/@sproul/Bk0Y0qdGD)). | |
| We considered using two separate formats (`complete` and `minimal`) rather than a single consolidated format but found that ran into problems. |
| ## Implementation | ||
|
|
||
| Implementations exist for the following clients: | ||
| - [Teku](https://github.com/ConsenSys/teku/pull/2820) | ||
| - [Lighthouse](https://github.com/sigp/lighthouse/pull/1544) | ||
| - [Prysm](https://github.com/prysmaticlabs/prysm/pull/7518) | ||
| - [Nimbus](https://github.com/status-im/nimbus-eth2/pull/1643) |
There was a problem hiding this comment.
This is currently a bit of a hot topic among the editors at the moment, but this content feels like it would be much more appropriate for the hard fork coordination process than for the EIP. The EIP is a technical specification, and it doesn't really care if anyone has implemented this or everyone has implemented this. Also, when someone is reading this in 5-10 years after all of these clients are no longer maintained and the repositories/organizations have been renamed/deleted then these links will no longer be adding value.
Note: As I mentioned, this is currently a bit of a hot topic so not a blocker for draft at the moment.
|
|
||
| ## Test Cases | ||
|
|
||
| The relevant test cases can be found in [this repository](https://github.com/eth2-clients/slashing-protection-interchange-tests). |
There was a problem hiding this comment.
Any chance we could just inline these into the EIP rather than having them be linked externally? Can we just copy them over to ../assets/eip-3076/* and call it a day? Test cases like this feel pretty critical to this EIP, and having them live outside of the EIP change control process feels like it isn't quite right.
There was a problem hiding this comment.
Yes! I'm happy for them to live within the EIP. We'll push them shortly.
Co-authored-by: Micah Zoltu <micah@zoltu.net>
Co-authored-by: Micah Zoltu <micah@zoltu.net>
…thereum#3076) A JSON interchange format for Serenity (eth2) that contains the necessary slashing protection information required to safely migrate keys between clients.
A JSON interchange format for Serenity (eth2) that contains the necessary slashing protection information required to safely migrate keys between clients.