Skip to content

EIP-7928 Implementation Tracker: Block-Level Access Lists #1878

@marioevz

Description

@marioevz

EIP-7928: Block-Level Access Lists

Target Fork

Amsterdam

Instructions

  • Assign issue to EIP specification and testing owner(s).

Important

A specifications specialist and a testing specialist should ideally share ownership of the EIP.

  • Add the issue to the target fork milestone if applicable (i.e., the EIP is at least in the CFI stage).

Guidance for Marking Items Complete

An item should only be checked off once the EIP is considered stable. In this context, stable means:

  • No major issues or ambiguities are still being uncovered in the specification or tests.
  • There are no open discussion points awaiting resolution.
  • Client implementations have been consistently passing the tests for at least a week.

It is ultimately up to the owners' discretion to decide when an item should be marked as complete, using this guidance as the basis for that decision.

In exceptional cases, an EIP may require changes after some items have been marked complete or even after the entire issue has been completed and closed. This can happen, for example, when significant design optimizations are identified and agreed upon in ACD, or when critical security issues surface and require updates to the specification or tests.

When this occurs, owners should either unmark the relevant checkboxes if the issue is still open, or create a new tracking issue for the modifications if the original issue had already been closed.

Specification + Testing Status

  • Testing complexity assessed and documented.
  • Specification implementation merged to eips/amsterdam/eip-7928 (skip if the fork branch merge below is already complete).
  • Specification updates merged to the corresponding forks/amsterdam branch.
  • EIP updates proposed in case of architectural choices surfaced during implementation.
  • Required testing framework modifications implemented.
  • Test suite implemented.
  • Full code coverage for all changes.
  • No regressions or failures in tests from prior forks (including static tests).
  • Testing checklist complete.
  • Hardening session completed.
  • Benchmarking tests written and results documented.
  • Ran tests using execute to ensure compatibility, and marked specific tests to be skipped when they cannot be executed on live networks.
  • Added Mainnet-marked tests (example test).

Process Status

  • Hive tests passing on at least two implementations.
  • EIP included in a devnet.

Metadata

Metadata

Labels

A-spec-specsArea: Specification—The Ethereum specification itself (eg. `src/ethereum/*`)A-spec-testsArea: tests for specifications e.g. json_infraC-eipCategory: tracking implementation of an EIPC-testCategory: testE-hardExperience: difficult, probably not for the faint of heart

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions