Skip to content
This repository has been archived by the owner on Apr 6, 2020. It is now read-only.

Updated pre-/post reentrency Constantinople support #41

Closed
holgerd77 opened this issue Jan 23, 2019 · 5 comments
Closed

Updated pre-/post reentrency Constantinople support #41

holgerd77 opened this issue Jan 23, 2019 · 5 comments

Comments

@holgerd77
Copy link
Member

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.

@davidmurdoch
Copy link

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

@holgerd77
Copy link
Member Author

Hardfork naming ans switch semantics is discussed in the following EIP: ethereum/EIPs#1716

@holgerd77
Copy link
Member Author

Constantinople EIP for reference: https://eips.ethereum.org/EIPS/eip-1013

@holgerd77
Copy link
Member Author

SSTORE implementation PR in the VM: ethereumjs/ethereumjs-monorepo#367

@holgerd77
Copy link
Member Author

Addressed in #44, will close.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants