Improved transfer replay protection, and removal of transfers in phase 0

[JustinDrake]

Replace the current slot-based transfer replay protection mechanism by adding state.transfer_roots: Vector[Hash, MAX_TRANSFERS * SLOTS_IN_REPLAY_PROTECTION_PERIOD]. We can also completely move transfers from phase 0 to phase 1.

[vbuterin]

So the only substantive thing here is removing transfers from the block structure, right?

[vbuterin]

It's also worth noting that this mechanism could be reused in phase 2 to prevent replay of withdrawals from execution environments into other execution environments, though in that case SLOTS_IN_REPLAY_PROTECTION_PERIOD would need to be really long for safety (a year?).

[djrtwo]

Do you still have to specify a slot or epoch?

I'm not certain what problem this is actually solving. If a validator has a Transfer for a slot and it is not included in a chain and then broadcasts a repeat for slot + N, then both of these can still be replayed on a reorged chain even though the initial transfer was not included in the pre-reorged chain.

[djrtwo]

Or are you suggesting removing slot from Transfer? If this is the case, then I can just replay a transfer after the replay protection period.

[JustinDrake]

Do you still have to specify a slot or epoch?

Yes.

[JustinDrake]

Or are you suggesting removing slot from Transfer?

As discussed on our call, slot stays there (or can be replaced with epoch).

[djrtwo]

So is the only thing this solving the ability to expand it to epoch instead of slot?

[JustinDrake]

If a validator has a Transfer for a slot and it is not included in a chain and then broadcasts a repeat for slot + N

The point is that the re-broadcast would not have to modify slot + N, hence removing the risk of having two transfers accidentally go through.

[JustinDrake]

So is the only thing this solving the ability to expand it to epoch instead of slot?

It expands slot to SLOTS_IN_REPLAY_PROTECTION_PERIOD. The intent is that SLOTS_IN_REPLAY_PROTECTION_PERIOD is much larger than SLOTS_PER_EPOCH.

[protolambda]

We can also completely move transfers from phase 0 to phase 1.

Then we move it to a new phase-1 beacon-chain updates document? Or will it live with the updated beacon-block body definition in the custody game doc?

[JustinDrake]

Then we move it to a new phase-1 beacon-chain updates document?

A new phase 1 beacon chain update document makes sense. (Mixing transfers with the custody game is a bit awkward.) My guess is longer term the miscellaneous update documents will be collapsed into a unified beacon chain state transition document.

[djrtwo]

I'm thinking about organizing specs into new sub-directories (will break links... :/). These directories would be grouped by fork and ordered. This would open up easily putting transfer into it's own fork defined as a beacon chain file in forks/

That said, don't want to do this surgery until we discuss more

[djrtwo]

I'm still pro doing a transfer-enabling fork for practice independent of phase 1 fork

[protolambda]

Another replay case (although much rarer) is when validators change index after an Eth 1 re-org. Credits to @sorpaas for surfacing it and bringing it to our attention on discord.
A transfer could then be replayed (or re-used in a clean but unexpected state really...) to send the funds to the new validator now taking the receiver index.

This may be solved by modifying the other replay protection measures. Or we replace the receiver index with the receiver pubkey. And, as mentioned by Justin. When we have eth2 -> eth2 deposits, indices can get much more unstable, and transfers will need this replay protection. Something to keep in mind when revisiting the transfer design.

[JustinDrake]

@protolambda My favourite conservative fix is to replace indices in transfers by pubkeys.

[djrtwo]

transfers removed!