Immutable Canisters vs Main Net System Canisters Breaking Changes

Developers
,
1

I was looking through github and saw that people are hardcoding interfaces in order to communicate with different main net canisters.

For example I saw that people were using get_icp_to_cycles_conversion_rate() function from NNS and that got changed to get_icp_xdr_conversion_rate(). Now in this situation if I had a contract running in prod that was using this method and that contract was immutable then my app would stop working and I could not do anything about this.

I also saw that the nns canister id’s also changed so I am assuming that the previous version is still running exactly for this use case where backwards compatibility is required. I am not totally sure that this is actually true so I would appreciate if someone can confirm it.

Considering that what was mentioned above is true then what is the behaviour for sub dependencies where that NNS canister might have sub dependencies that change as well, how will the system handle this?

My assumption is that for internet computer to assure backwards compatibility then the systems canisters must be immutable and all changes actually imply a new separate install.

Again, these are only assumptions and I would appreciate a lot if someone could clarify the things a bit.

Thank you!

2

The identities of the NNS canisters on the main net have never changed.

Although the NNS canisters themselves are not immutable, all upgrades should not introduce breaking changes to the interfaces which have been publicly advertised.

Having said that, I don’t think we have a consistent way through which we do such advertising but a rule of thumb we try to stick to is that Candid interfaces don’t change (whereas protobuf ones may) — I believe the example you gave for the interface to get the conversion rate is like that(?).

3

Then why not set in stone this rule and enforce it directly into the source code? Any interface update should automatically mean a hard fork imo.

4

This is actually a really good question IMO, and brings to mind the concept of a “permanent API” that Dominic proposed in his seminal 20-year plan Medium post.

Unfortunately, I haven’t heard mention of that idea anywhere else.