Skip to content

@holgerd77 holgerd77 released this Oct 25, 2018 · 205 commits to develop since this release

This is the first of a new regular series of test releases, which can be used to reference a static snapshot of the tests within your library. For a starter release notes will give an overall summary of the status of consensus Constantinople tests, a summary of recent noteworthy changes and an overview on release versioning. Subsequent releases will then provide a CHANGELOG towards the release before.

Constantinople Test Summary

  • EIP-145 (Bitwise shifting): Tests for SAR, SHL and SHR in GeneralStateTests/stShift directory, blockchain tests analogue
  • EIP-1014 (CREATE2): Various cases covered in GeneralStateTests/stCreate2 directory, blockchain tests analogue
  • EIP-1052 (EXTCODEHASH): Tests not merged yet, open PR #484
  • EIP-1283 (SSTORE): Dedicated tests in GeneralStateTests/stSStoreTest directory also covering Ropsten consensus issue cases, blockchain tests analogue, generally refilled state tests with new SSTORE gas metering rules in PR #511
  • EIP-1234 (difficulty): New difficultyConstantinople.json file and regenerated difficultyRopsten.json files in the BasicTests directory, see PR #518

Library Changes

Be aware that the format of BlockchainTests recently changed with the introduction of a new field sealEngine (values: NoProof | Ethash), see related JSON Schema change or BlockchainTest format docs for reference.

This means that you can faster-execute NoProof based tests skipping block validation. These tests nevertheless doesn't provide reliable values for PoW-based block header fields any more (mixHash, nonce), so make sure that you don't rely on the correctness of these values for the tests to pass.

Versioning

Library releases will follow semantic versioning:

  • major number updates every time there is a backwards incompatibility for test runners, eg~
    • new fork rules
    • backwards-incompatible change, like dropping the mixhash and setting sealEngine=NoProof (see these release notes)
  • minor number updates when new tests are added that are backwards compatible
  • patch number updates if an existing test is bugfixed

Here is an example how a follow-up release line could look like:

  • v6-alpha - starting to implement EIPs, but not all EIPs are finalized
  • v6-beta - all EIPs finalized, but some tests still in progress
  • v6.0.0 - all desired coverage for Constantinople tests to be considered "done enough"
  • v6.1.0 - more coverage added
  • v6.2.0 - more coverage added
  • v6.2.1 - bugfix on one of the tests
  • v7.0.0 - change in test format output (if backwards incompatible)
Assets 2
You can’t perform that action at this time.