1000—Phase 0 spec freeze

[protolambda]

№ 1000 🎉 Congratz everyone!

This issue will track the progress towards phase 0 spec-freeze, a big milestone towards launch of phase 0.

---

The Phase 0 spec freeze

The idea of the spec-freeze is to enable client implementers to settle on a stable version of the spec, and prepare for launch. It is crucial to scrutinize the spec before this freeze, and find & fix any remaining bugs.

To be frozen for Phase 0:

• core/
  • 0_beacon-chain.md
  • 0_deposit-contract.md
  • 0_fork-choice.md
• validator/
  • 0_beacon-chain-validator.md
• networking
  • TBD

Timeline

• April 9 - Sydney workshop
• April 18 - Impl call #16
• April 24 - Release v0.6.0
• May 2 - Impl call #17
• May 4 - Release v0.6.1
• May 6-12: generalized test case setup: complete state-transition tests.
• May 13-15: Many in NY, prepare workshop
• May 16 - New York workshop, hosted by Pegasys: focus on client interop.
• May 17-19: EthNY hackathon, opportunity to implement new workshop ideas
• May 20 - May 31: more v0.6.x work
• June 1: possible date for v0.7.0 (if we do one)
• June 1-30: finalize things & make sure spec is ready to freeze
• June 30: FREEZE (as per this tweet)
• July 1 and later: implement frozen spec, testnets, etc. Launch target date TBD.

Action points for freeze

• Testing:
  • complete state-transition tests
    • unify "case setup" part of pytests and state-transition yaml-tests. (It is rather painful to duplicate effort between testing of the spec itself, and generation of test-vectors for clients. We're looking to unify where possible)
      • implement block-operation test cases described in Test-generator: operations from blocks #927
    • generate tests covering larger transitions, similar to chain-tests
    • Higher coverage with state-transition tests. From a client (yaml consuming) view. Spec already has good coverage. (See The spec-test coverage hunt #1200) Note: rewards/penalties epoch processing tests are postponed. All other tests made it in 🎉
  • fork-choice test vectors (See Executable fork choice #1185)
    • Note; some were implemented. To be extended some time in after freeze.
  • fuzzing
    • differential fuzzing between pyspec and ZRNT
    • fuzz ZRNT, look for panics / broken invariants
  • invariants testing, cc @JustinDrake part of fuzzing
• Experimentation:
  • network spec (if included) needs testing too
  • implement & iterate on pain points, don't wait till after spec freeze.
• Improve & simplify phase 0 spec where possible.
  • TODO: document things to be improved / changed (or added, if any) See Phase 0 state transition checklist—take 5 #1054
• Standardize constant presets.
  • minimal: constants for fast testing, may not be reliable enough for a testnet.
  • testnet: minimum viable reduced constants for a testnet. Minimal for now, will experiment more during interop testing.
  • mainnet: spec costants

[JustinDrake]

I suggest keeping track of this. We need to find about one bug a day to squash them all before freeze.

[hwwhww]

Tracking issue for first public testnet

I suggest that could be in https://github.com/ethereum/eth2.0-pm/ repo 😄

[protolambda]

Updated issue with spec-freeze tracking suggestion from @JustinDrake

[JustinDrake]

Some personal notes to set the right expectations for the spec freeze:

1. The main purpose for a spec freeze is to see the emergence of long-lived cross-client testnets by halting master releases.
2. We reserve the right to do cosmetic changes (e.g. any state transition change that doesn't affect hash_tree_root(state)) to the phase 0 spec after the freeze, especially on the dev branch.
3. BLS standardisation is unlikely to be finalised by June 30, although significant progress will have been made. Any inconsistency with the final BLS standard will have to be reflected in the launch release.
4. Bug fixes will obviously have to be incorporated in the launch release. If the bug impedes the formation of cross-client testnets (e.g. causes the state transition to stall) then an "emergency point release" will likely be warranted. Fixes to not-too-bothersome bugs can accumulate (unreleased) in the dev branch until much closer to launch.
5. Simplifications and cleanups found between July 1 and the actual launch date will not warrant a master release. Such simplifications and cleanups will have to be assessed on an ad-hoc basis for incorporation in the final phase 0 release or a future release (e.g. the phase 1 release).

[protolambda]

This issue is more or less complete (See #1231 for last tiny testing update). We will be polishing and pushing the last feature PR for freeze now. Closing this to focus on the remaining freeze issues/PR.