Deposit-related standardisation checklist

[JustinDrake]

For sanity we want to standardise extra-consensus various concepts related to deposits. The suggestion is to add those standards in this repo, similar to the networking standards. @CarlBeek is doing some experimentation in this repo.

• 0. rewrite BLS spec: Follow new standards (see here and here).
• 1. checksums: see Validator address checksums #1183
• 2. HD wallets: see https://github.com/CarlBeek/eth2.0-deposit-tooling
• 3. key store: see https://github.com/CarlBeek/eth2.0-deposit-tooling
• 4. quantum-secure backups: see Quantum-secure backup infrastructure for BLS signatures #1342

[vbuterin]

What's the purpose of standardizing a notion of address for validators? For transfers? In general I feel like just using the index as an ID for a validator would be best.

[djrtwo]

What's the purpose of standardizing a notion of address for validators?

@vbuterin What are you specifically referring to?

[vbuterin]

1. checksums: see Validator address checksums #1183

[djrtwo]

What's the purpose of standardizing a notion of address for validators? For transfers? In general I feel like just using the index as an ID for a validator would be best.

I think they mean a checksum for the validator pubkey rather than some notion of address. The only place that this would be useful at this stage would be in the deposit contract and maybe Transfers. Agreed that most validator related activities after induction should just be denoted in indices.

[vbuterin]

Why would a checksum be needed though? Checksums are there to protect against human error, and when is a human going to be putting in validator pubkey data anywhere?

[JustinDrake]

when is a human going to be putting in validator pubkey data anywhere

For both deposits (e.g. top ups) and transfers. The reason validator indices are not ideal for transfers is that it may be possible for an attacker to manipulate them (e.g. by reordering deposits), and hence steal funds. While manipulation is hard in the context of Eth1 deposits, Eth2 deposits may be easier to reorder.

[djrtwo]

@JustinDrake Are you suggesting adding a checksum (beyond the root checksum) for the addr in the deposit contract?

[JustinDrake]

@JustinDrake Are you suggesting adding a checksum (beyond the root checksum) for the addr in the deposit contract?

The suggestion is to standardise on a user-level checksum when manipulating validator pubkeys, especially for transfers. (No substantive change to consensus.) It's possible such as standard would also be picked up at the application layer in phase 2.

[mcdee]

Not sure if this fits here or elsewhere, but there need to be checks somewhere that clients are generating correct deposit data. Incorrect encoding of withdrawal credentials, for example, would not be picked up until someone tried to withdraw the funds by which time it would be a tad late.

The inputs to the test would be (validator private key, withdrawal private key, amount) and the output would be (deposit data root) after the signature has been applied, for example:

{
  "inputs": {
    "validatorkey": "1def3c44d41a17a84a678335395b484545946d1b1a56a01f3a8ea4905544e749",
    "withdrawalkey": "518b599fc3fff1dccaac87364f03575734d81ade9356a45c6fdcfd82d1b46562",
    "amount": "32000000000"
  },
  "outputs": {
    "depositdataroot": "bb96a5ace64d2b2a445b4ba860d1acece4d2cac2559d7e80d1f392717b8e6ac3"
  }
}

[Note we could use withdrawal public key rather than private key, but I figured it's better to provide both validator and withdrawal as private keys for consistency]

[JustinDrake]

@CarlBeek Have the items in this checklist been addressed? :)

[JustinDrake]

All the items (with the exception of checksums) have been standardised and implemented in the default deposit interface (private repo for now).