Hide NativeUpdateHistory behind hardforks

[roman-khimov]

Summary or problem description
We have NativeUpdateHistory mechanism since #2332, but we've never used it. It's not easy to configure it (can be a big table) and it only allows to handle native contract updates. Still, it's directly exposed to node's configuration.

We have hardfork mechanism since #2712 (and funny names for them since #2749). This one is much easier to handle, can adjust any logic and is used quite successfully (can be used even more as #2910 suggests).

Do you have any solution you want to propose?
Remove NativeUpdateHistory from the node configuration (that's a must to me, it's just confusing now) and maybe use it internally in conjunction with the hardfork mechanism (deploying/updating contracts when some hardfork happens).

Where in the software does this update applies to?

• Ledger
• Interops
• Native Contracts

[shargon]

But with native update history you can allow a native contract only from block X, with HF you can change the logic, but not the ability to call this native contract

[roman-khimov]

The idea is to have it implicitly configured via hardforks. Let's say hardfork X introduces a new contract C, so if we have a configuration with HF_X at H we can generate appropriate NUH that has no contract C at 0, but deploys it at H.

[roman-khimov]

The issue is about configuration simplification, the mechanism to update/deploy native contracts has to be present behind the scenes of course. It just needs to be tied to hardfork configuration.

[vncoelho]

NUH that has no contract C at 0, but deploys it at H

What is NUH? I agree with your proposal. This is a possible direction that we can start. But since I mentioned the recent issue I see this is as version control.

I think that a good feature of the history is the ability to call the previous contracts and resync with the past versions, as @shargon mentioned above.

[roman-khimov]

What is NUH?

NativeUpdateHistory.

[vncoelho]

I think that the NUH has some components in the way I presented in the recent issue. It has the activation for version and existence of contracts.

We just need to start to use it and polish its features. If needed we improve it.
I think the name is good as well. We need to start to use NUH, and Kecak PR #2925 may be a good start for us.
Let's try to use NUH with that PR and manage a safe resync that protects from the attack.