Closed AnnaShaleva closed 4 months ago
I doubt many applications care about this (but I can be wrong). So an additional management contract call is not that bad and just an update counter is likely sufficient (you see the version that is currently in use and can react to that if needed). HF schedule is a separate matter and keeping whole update history is somewhat impractical as well.
Adding updatecounter
to the output seems to be the best, no need to make additional calls and more symmetry with regular contracts.
Adding
updatecounter
to the output seems to be the best, no need to make additional calls and more symmetry with regular contracts.
Agree
Ping @Jim8y
Summary or problem description We have
getnativecontracts
RPC call, and since neo-project/neo#2941 and #851 there's no such thing as "native update history" and there's no way to define native contract version or updates scheduler viagetnativecontracts
from the user side. We can query native Management contract and check for update counter, but it's a separate RPC call and it gives us only a view of previous contract updates. At the same time I still consider that it might be helpful to receive at least a notion of native contract version or (which is better) a scheduler of past and future updates viagetnativecontracts
RPC call, especially after https://github.com/neo-project/neo/pull/2942.Do you have any solution you want to propose? One of the alternatives I thought about is to include contract update counter to
getnativecontracts
response structure. However, this option is not a full replacement toUpdateHistory
field removed in #851, so maybe we can think about hardfork-based update history that can be retrieved for every native contract after https://github.com/neo-project/neo/pull/2942 merge.Where in the software does this update applies to?