Conform to https://eips.ethereum.org/EIPS/eip-7892, in order to pass EEST v5.1.0.
Suggested logic:
- EEST
blockchain_test fixtures now come with a new blobSchedule (as specced out by the EIP) and a network field, which is sth like OsakaToBPO1AtTime15k
- For tests which have
blobSchedule, it will be parsed to produce a mapping fork -> blob params
- The
network field, if one of the predefined transitions like OsakaToBPO1AtTime15k, will be recognized. The transition time will be used to find blob params in that mapping, for each block.
- If not found in the map, hardcoded blob params will be used as before (only up to Prague)
- For purposes other than blob params, "forks" like
OsakaToBPO1AtTime15k are just treated as Osaka, being the most recent non-BPO fork preceding the active fork for blob params
Beyond EEST v5.1.0, network field parsing (3.) may be substituted by parsing <Fork>Time fields similar to format given in the EIP itself, if that is chosen to be put in the blockchain_test fixture format. (5.) would then become irrelevant as special network values would not be used anymore.
Conform to https://eips.ethereum.org/EIPS/eip-7892, in order to pass EEST v5.1.0.
Suggested logic:
blockchain_testfixtures now come with a newblobSchedule(as specced out by the EIP) and anetworkfield, which is sth likeOsakaToBPO1AtTime15kblobSchedule, it will be parsed to produce a mappingfork -> blob paramsnetworkfield, if one of the predefined transitions likeOsakaToBPO1AtTime15k, will be recognized. The transition time will be used to find blob params in that mapping, for each block.OsakaToBPO1AtTime15kare just treated asOsaka, being the most recent non-BPO fork preceding the active fork for blob paramsBeyond EEST v5.1.0,
networkfield parsing (3.) may be substituted by parsing<Fork>Timefields similar to format given in the EIP itself, if that is chosen to be put in theblockchain_testfixture format. (5.) would then become irrelevant as specialnetworkvalues would not be used anymore.