Skip to content

tests-focil-devnet@v0.2.0

Pre-release
Pre-release

Choose a tag to compare

View all tags
@github-actions github-actions released this 20 Aug 01:06
tests-focil-devnet@v0.2.0
23b0358

Description

Third release for FOCIL (EIP-7805) Devnet 0 (previous was tests-focil@v0.1.0).

What's Changed

Fill Fork

All filled tests in this release specify the "Bogota" network, instead of "Amsterdam" as previous releases.

The Amsterdam spec on top of which Bogota is based is the Glamsterdam Devnet-8 version.

Test Format

Changes to the Blockchain Engine fixture format

FixtureEngineNewPayload.status — removed

Previously an optional string that could carry INCLUSION_LIST_UNSATISFIED alongside the five PayloadStatusV1 values. That value was part of an earlier FOCIL draft. Consumers no longer need to special-case a sixth status — status is once again exactly the PayloadStatusV1 set, derived as before from the presence of validationError.

FixtureEngineNewPayload.inclusionListSatisfied — added
- inclusionListSatisfied: Optional[bool] (fork: Bogota)

Expected value of the inclusionListSatisfied field of PayloadStatusV2 returned by engine_newPayloadV6.

The field is present on every payload from Bogota on.

It mirrors PayloadStatusV2 and is orthogonal to validationError. A payload may be VALID while not satisfying its inclusion list at the same time. The value returned by the client in inclusionListSatisfied must be exactly equal to the one expected by the test for it to be considered as a pass.

New Tests

All blockchain and state tests from previous forks that were marked in #3337 now automatically generate an inclusion-list variant test where the last transaction of the last block is moved from the block to the inclusion list, with two different expectations:

  • If the transaction contained an error, or was otherwise not includable in the block, the block's inclusion list is expected to be validated as satisfied by the client.
  • If the transaction contained no errors and was includable in the block, the block's inclusion list is expected to be validated as unsatisfied by the client.

Both variants follow the same exact fixture format as described above.

Three bugs were found in the spec with these newly generated tests.

Spec Fixes

Spec bugs caught and fixed by tests mentioned in previous section:

  • Transactions with incorrect chain-id were still considered includable
  • Transactions with incorrect RLP encoding caused an exception in the inclusion list validator
  • Type-3 transactions were considered not-includable by default
Assets 3
Loading