Transfers checklist

[JustinDrake]

• 0. Move transfers: Move transfers from 0_beacon-chain.md to 1_beacon-chain-misc.md. See Starting on phase 1 misc beacon changes #1323.
• 1. Harden recipient field: Make recipient a BLSPubkey instead of a ValidatorIndex.
• 2. Improve replay protection: Replace user-unfriendly slot-based replay protection (assert state.slot == transfer.slot) with one based on a transfer_roots list/vector in the BeaconState keeping track of recent transfer roots over many epochs.
• 3. Quantum-secure backup: Redefine withdrawal_credentials to include a commitment to secrets (see Quantum-secure backup infrastructure for BLS signatures #1342).

[vbuterin]

3. Quantum-secure backup: Redefine withdrawal_credentials to include a commitment to secrets (see Quantum-secure backup infrastructure for BLS signatures #1342).

This would imply supporting both current-style and new-style withdrawal credentials, right? Seems reasonable, as I do expect we'll see more types of withdrawal credentials (eg. authorize withdrawal direct to EE with pre-specified data only) in the future.

[dankrad]

This would imply supporting both current-style and new-style withdrawal credentials, right? Seems reasonable, as I do expect we'll see more types of withdrawal credentials (eg. authorize withdrawal direct to EE with pre-specified data only) in the future.

I understood it more in the sense of supporting commitment to such a secret, so that protocol support could be introduced if necessary.

Wouldn't supporting arbitrary withdrawals require coding the credentials as a script in a VM?

[JustinDrake]

This would imply supporting both current-style and new-style withdrawal credentials, right?

My suggestion is to abandon current-style withdrawal credentials. One concrete possibility is to have a credentials_root defined as the hash_tree_root of

class Credentials(Container):
    withdrawal_credentials: Bytes32  # 1 byte version prefix
    quantum_credentials: Vector[Bytes32, 512]  # Lamport secrets

Notice that operations that authenticate withdrawal_credentials against credentials_root need to supply quantum_credentials_root (i.e. a Merkle node as part of a Merkle path). I'm also tempted to avoid the 1-byte prefix hack:

class Credentials(Container):
    version: Bytes1
    withdrawal_credentials: Hash  # Unversioned
    quantum_credentials: Vector[Bytes32, 512]

By moving the 1-byte outside of withdrawal_credentials we allow the versioning to operate over quantum_credentials.

[JustinDrake]

A few more thoughts:

1. We may be able to stick with the current withdrawal_credentials if the convention is that the BLS private key for the withdrawal pubkey is derived from the hash_tree_root of quantum_credentials of type Vector[Bytes32, 512]. One disadvantage here is that revealing the quantum root also reveals the BLS private key. Another disadvantage is that it's no longer MPC-friendly to generate the withdrawal pubkey (see also point 2).
2. We want quantum_credentials to be reasonably MPC-friendly. Making elements of quantum_credentials be independently-generated SHA256 outputs means that computing hash_tree_root(quantum_credentials) can be done in the clear, and that quantum_credentials itself can be generated with 512 parallel secure evaluations of SHA256.
3. It makes sense for the version byte to cover both the withdrawal_credentials and quantum_credentials. Indeed, we may want to allow an MPC-friendlier hash function (e.g. a STARK-friendly hash function used elsewhere) at some point in the future.

[JustinDrake]

Yet another way to stick with the current withdrawal_credentials is to add a quantum_credentials field to DepositData and call it a day. Indeed, thanks to historical_roots historical deposit data can be authenticated. The main disadvantage here is that it requires modifying the deposit contract bytecode.

[djrtwo]

Closing this issue for now as Transfers are to be added in some later (to be determined) phase