You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 6, 2020. It is now read-only.
As far as I can read out from both the notes from core developers meeting 53 as well as some covering media articles like this one on blockonomi.com there will now technically be two Constantinople hardforks, the current already happened on test nets including EIP-1283 and a second one again removing the feature. On mainnet there will only be the last one applied.
Technically this would mean two Constantinople files here in the src/hardforks directory. For naming I would prefer to keep constantinople for the latter one - since this will be the lasting one staying relevant in mid- and long term and choose something like constantinopleTmp for the testnet fixing one. In constantinopleTmp all parameters would have to be set to the values currently collected in the current constantinople file. The new constantinople file would then re-set the SSTORE values to its pre constantinopleTmp state.
For the different src/chains files the two (!) hardforks have to be added. There has to be special care regarding upstream libraries that this is done (and applied on upstream libraries like the VM) in a way that on mainnet on Constantinople switch all the values from constantinopleTmp are taken and then the value resetting (overwriting) in constantinople is also taking place. This can probably be achieved by adding both hardforks with the same block number, constantinopleTmp coming first. This has to be carefully tested if it really works on upstream though.
Before we continue on this I would like to have at least one confirmation that my analysis is correct.
The text was updated successfully, but these errors were encountered:
From what I understand the constantinople that ends up going live on mainnet will have a different name than the constantinople that is running on the test nets. So the naming convention in common may need to reflect that. Source: https://gitter.im/ethereum/AllCoreDevs?at=5c45b174dab15872cecb810a
As far as I can read out from both the notes from core developers meeting 53 as well as some covering media articles like this one on blockonomi.com there will now technically be two
Constantinople
hardforks, the current already happened on test nets including EIP-1283 and a second one again removing the feature. On mainnet there will only be the last one applied.Technically this would mean two Constantinople files here in the src/hardforks directory. For naming I would prefer to keep
constantinople
for the latter one - since this will be the lasting one staying relevant in mid- and long term and choose something likeconstantinopleTmp
for the testnet fixing one. InconstantinopleTmp
all parameters would have to be set to the values currently collected in the current constantinople file. The newconstantinople
file would then re-set theSSTORE
values to its preconstantinopleTmp
state.For the different src/chains files the two (!) hardforks have to be added. There has to be special care regarding upstream libraries that this is done (and applied on upstream libraries like the VM) in a way that on mainnet on Constantinople switch all the values from
constantinopleTmp
are taken and then the value resetting (overwriting) inconstantinople
is also taking place. This can probably be achieved by adding both hardforks with the same block number,constantinopleTmp
coming first. This has to be carefully tested if it really works on upstream though.Before we continue on this I would like to have at least one confirmation that my analysis is correct.
The text was updated successfully, but these errors were encountered: