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
Summary or problem description
I've finished the port of HF-based native contract update, and this is the last remaining issue connected with this functionality. Currently native contract initialization happens every time when native contract needs to be deployed or updated:
This code works perfectly for the current mainnet/testnet and for the current version of native contracts. However, there might be a case (in some private installations like I had for the tests) when several hardforks are being active starting from the same height. Technically it's a valid node configuration, so let's take as an example the case when all hardforks are enabled from the genesis block. In this case await contract.Initialize(engine, hf); will be called only once during Genesis block persist with nil hardfork value.
Let's take as an example the following Initialize override:
The problem is: if we ever decide to extend this Initialize method with some contract storage changes required on new HFDomovoy hardfork (that is different from the contract's ActiveIn), then the initialization code is not going to work properly in case when several hardforks are active starting from the same height.
Do you have any solution you want to propose?
Call await contract.Initialize(engine, hf); in cycle consequently for the range of hardforks, starting from the hf and ending with the last hardfork that is active starting from the current block. Then native contracts will be able to properly manage their storage inside the Initialize override based on the provided hardfork. This change won't affect the existing behaviour for mainnet/testnet.
Where in the software does this update applies to?
Please, note that currently it's not a bug/problem for mainnet/testnet, that's why I'm creating a discussion issue rather than bug. But it can easily become a bug in future on further native contracts code extension, so to me it's worth solving right now.
The text was updated successfully, but these errors were encountered:
Summary or problem description
I've finished the port of HF-based native contract update, and this is the last remaining issue connected with this functionality. Currently native contract initialization happens every time when native contract needs to be deployed or updated:
neo/src/Neo/SmartContract/Native/ContractManagement.cs
Line 95 in 629baf8
This code works perfectly for the current mainnet/testnet and for the current version of native contracts. However, there might be a case (in some private installations like I had for the tests) when several hardforks are being active starting from the same height. Technically it's a valid node configuration, so let's take as an example the case when all hardforks are enabled from the genesis block. In this case
await contract.Initialize(engine, hf);
will be called only once during Genesis block persist withnil
hardfork value.Let's take as an example the following
Initialize
override:neo/src/Neo/SmartContract/Native/GasToken.cs
Lines 29 to 37 in 629baf8
The problem is: if we ever decide to extend this
Initialize
method with some contract storage changes required on newHFDomovoy
hardfork (that is different from the contract'sActiveIn
), then the initialization code is not going to work properly in case when several hardforks are active starting from the same height.Do you have any solution you want to propose?
Call
await contract.Initialize(engine, hf);
in cycle consequently for the range of hardforks, starting from thehf
and ending with the last hardfork that is active starting from the current block. Then native contracts will be able to properly manage their storage inside theInitialize
override based on the provided hardfork. This change won't affect the existing behaviour for mainnet/testnet.Where in the software does this update applies to?
Additional information
See the nspcc-dev/neo-go#3402 (comment).
Please, note that currently it's not a bug/problem for mainnet/testnet, that's why I'm creating a discussion issue rather than bug. But it can easily become a bug in future on further native contracts code extension, so to me it's worth solving right now.
The text was updated successfully, but these errors were encountered: