Store contract ID->hash mapping and allow to iterate over contracts

[roman-khimov]

Summary or problem description

1. Some private chains like NeoFS sidechain have well-known IDs for non-native contracts, but their hashes can change from one network to another (because contracts change over time).
2. There are requests like List all deployed contracts/tokens? neo-modules#748 that have a need to iterate over contracts, but the best way to do it is using historic deployment order which is closely tied to contract's ID.

Do you have any solution you want to propose?

1. Store ID->hash mapping in the ContractManagement contract, it doesn't need a lot of storage space.
2. Provide getContractByID(id integer) method that will return contract's state corresponding to ID (or just a hash).
3. Provide listContracts (or listNonNative) method that will return an iterator with contract hashes in deployment order (by ID).
4. Extend getcontractstate RPC with the ability to request contracts by ID.

Neo Version

• Neo 3

Where in the software does this update applies to?

• Native contracts
• RPC (HTTP)
• SDK

[Jim8y]

One map store active contracts and another for destroyed contracts?

[erikzhang]

neo/src/Neo/SmartContract/Native/NativeContract.cs

Line 144 in 28ab45a

this.Hash = Helper.GetContractHash(UInt160.Zero, 0, Name);

The hash of a native contract is determined by its name and should not change.

[roman-khimov]

One map store active contracts and another for destroyed contracts?

Well, there could be some deactivation flag stored, although we already block destroyed contracts now. Not sure about that, active ones are the most interesting to me.

The hash of a native contract is determined by its name and should not change.

This issue is specifically about non-native ones. Consider NeoFS chain, it has NNS contract deployed there as the contract number 1, that's the policy, but it differs from chain to chain. Also, contract iterator is a useful thing to have.

[realloc]

We need this feature to improve the NeoFS deployment in testing/on-prem environment.

We want to pre-generate signed transactions to update settings in Sidechain contracts and use them directly, without the need to have access to Alphabet private keys from the CI environment.

Can also be considered a security improvement =)

[superboyiii]

I think it makes sense!