Phase 0 state transition checklist—take 5

[JustinDrake]

(See #128, #218, #322, #675 for takes 1, 2, 3, 4.)

This issue keeps track of possible phase 0 state transition function changes.

• 1. (post-freeze discussion) BLS12-381 standardisation: See here.
• 2. (post-freeze discussion) Big vs little byteorder of hash_tree_root inputs: See also Little vs big endian #556.
• 3. (post-freeze discussion) Performance parameters fine-tuning: E.g. review SLOTS_PER_EPOCH and SHARD_COUNT based on benchmarks.
• 4. Issuance schedule: Enact schedule whereby 2**21 ETH is issued per year when 2**27 ETH is at stake.
• 5. Better aligned micro-incentives: Make crosslink incentives proportional to number of epochs in a crosslink. Make matching head incentives proportional to head slot vs target slot.
• 6. Stateless withdrawal credentials: Consider not storing withdrawal credentials. See Do not store withdrawal_credentials #937.
• 7. Remove MIN_ATTESTATION_INCLUSION_DELAY: Set MIN_ATTESTATION_INCLUSION_DELAY to 1.
• 8. (post-freeze discussion) Remove transfers: Consider completely removing the Transfer operation, going beyond MAX_TRANSFERS = 0. We want to do a practice hard fork that add a field to an SSZ object (in this case, adding the transfers field to BeaconBlockBody).
• 9. (post-freeze discussion) Last slot vs first slot epoch transitions: See Improve epoch processing within state transition #1043.
• 10. Merged historical stats: Consider merging latest_randao_mixes, latest_active_index_roots, latest_slashed_balances into a single SSZ object.
• 11. More historical stats: Store the last 8 months of historical lists so that historical start shards can be recomputed.
• 12. Crosslink lengths: Fix [Phase 1] get_custody_chunk_count is broken #1034.
• 13. Bitfields/bigints/generalised indices: See Cleaner bitfields #1019.
• 14 Fine-tune object field ordering: See Cleanup containers #917.
• 15 Crosslink in AttestationData: See Crosslink in AttestationData #1044.
• 16 (post-freeze discussion) Exit fee: See Withdrawal queue -> exit queue #850 (comment).
• 17 Improve upon latest_active_index_roots: For more efficient light clients. See Active registry roots #1104
• 18 (post-freeze discussion) Hard Forkability: See handling altered constants at forks #1101, also related to 8
• 19 Fixed size state: Make BeaconState fixed size to be friendly to SSZ partials.
• 20 Checkpoints: Refactor BeaconState to use Checkpoints.
• 21 Slashing early exit: (bug) In some circumstances getting slashed allows for an early exit.

[vbuterin]

2. Big-endian vs little-endian hash_tree_root: See Little vs big endian #556.

What are the places where little endian is still used in the hash tree root?

I have a strong preference toward not, for example, reversing the bytes of hashes the way bitcoin does. I had to deal with that as an implementer and it was painful. Endianness should be purely a convention about how we serialize things that are integers within the eth2 spec; we should be treating everything outside the eth2 spec proper (eg. hash algorithms, BLS signature and BLS pubkey serialization...) as black boxes that just give us bytes.

[JustinDrake]

What are the places where little endian is still used in the hash tree root?

To only place is byteorder when calling to_bytes on a uintN for N in [16, 32, 64, 128, 256]. This affects, for example, hash_tree_root of a slot number (of type uint64).

It's confusing that "endianness" is used for both bits and bytes. What about using big/little "byteorder" and "bitorder" instead?

we should be treating everything outside the eth2 spec proper (eg. hash algorithms, BLS signature and BLS pubkey serialization...) as black boxes that just give us bytes

Agreed :)

[vbuterin]

Ah sorry, meant to ask where big endian is used in tree hash root. To me it seems obvious that if SSZ serialization uses little endian then so should SSZ tree hashing, so I don't see the issue....

Bitorder is only relevant for bitfields, correct?

[vbuterin]

5. Better aligned micro-incentives: Make crosslink incentives proportional to number of epochs in a crosslink. Make matching head incentives proportional to head slot vs target slot.

This is arguably a bad idea, because the total payment that validators get would potentially be larger (!!!) if they skip crosslinks. That is:

• Honest strategy: (100% vote) (100% vote) (100% vote) (100% vote)
• Honest reward: 1 + 1 + 1 + 1 = 4
• Evil strategy: (60% vote) (60% vote) (60% vote) (100% vote)
• Evil reward: 0.6**2 + 0.6**2 + 0.6**2 + (1 * 4) = 5.08 (or if we're even stupider with the implementation: 0.6**2 + (0.6**2 * 2) + (0.6**2 * 3) + (1 * 4) = 6.16)

[vbuterin]

16 Exit fee: See #850 (comment).

Do we want an exit fee or a minimum time online? We already have this:

    # Verify the validator has been active long enough
    assert get_current_epoch(state) >= validator.activation_epoch + PERSISTENT_COMMITTEE_PERIOD

[djrtwo]

Consider completely removing the Transfer operation, going beyond MAX_TRANSFERS = 0. We want to do a practice hard fork that add a field to an SSZ object (in this case, adding the transfers field to BeaconBlockBody).

I'm not seeing much value here especially considering clients already have this functionality built and tested. If we sequester Transfer to another fork in between 0 and 1, we would have to define a whole state transition file for the in between fork. Coordinating a production fork around a constant change is significant enough IMO

[djrtwo]

Last slot vs first slot epoch transitions

Down to get on a call to convince you that this is still not the proper path :)

[djrtwo]

All items except (16) have been addressed. Closing this in favor of specific issue on exit fee #1521