Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transfers checklist #1343

Closed
1 of 4 tasks
JustinDrake opened this issue Aug 7, 2019 · 6 comments
Closed
1 of 4 tasks

Transfers checklist #1343

JustinDrake opened this issue Aug 7, 2019 · 6 comments
Labels

Comments

@JustinDrake
Copy link
Collaborator

JustinDrake commented Aug 7, 2019

  • 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).
@JustinDrake JustinDrake pinned this issue Aug 7, 2019
@vbuterin
Copy link
Contributor

vbuterin commented Aug 7, 2019

  1. 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
Copy link
Contributor

dankrad commented Aug 8, 2019

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
Copy link
Collaborator Author

JustinDrake commented Aug 12, 2019

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
Copy link
Collaborator Author

JustinDrake commented Aug 14, 2019

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
Copy link
Collaborator Author

JustinDrake commented Aug 14, 2019

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
Copy link
Contributor

djrtwo commented Dec 12, 2019

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

@djrtwo djrtwo closed this as completed Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants