Questions about contracts update/versionning, and immutability
I'de like to get more informations about smart-contracts , and smart-contracts update/versionning. Hi heard in a recent community hangout that RChain should support major, minor and patches versionning.
Let's say I pushed a contract on shard X, the address of the contract is "abcdef12345".
In the first place, is it possible to update the code of this smart-contract ? Or is the smart-contract's code at adress "abcdef12345" froze and fixed forever in the blockchain ? Maybe I do need to specify at deploy-time (or in my rholang code) in some way that this contract cannot be updated ? If it is not possible to update a contract, what was the discussion about major, minor and patches support about ?
If it is possible to update contract code, or push other versions of a contract code, how will it be accessed by other contracts ? Let's say I pushed a version 2 and 3 of my contract, how do I communicate with these new contracts ? do all three versions of the code still exist on the blockchain ? At what address will they be ("abcdef12345@2" "abcdef12345@3") ?
I'm asking all these questions because I have a specific business-application that requires complete immutability/persistence of the code after deploy. I want to guarantee to my clients that the code I delivered on RChain platform will never ever change and always behave the same way (I know for example that on EOS platform, a contract is by-default editable for the owner of the private key, but it can also be declared uneditable).
Thanks very much !
The way to make some contract public-facing (as opposed to private contracts that can only be called internally by your own code) is via the "registry". At the time of writing there are two APIs to interact with the registry: `insertArbitary` and `insertSigned`. The first allows you to associate some piece of Rholang data (including a name on which a contract is listening for input) with a random ID. This is then immutable and that ID will always return the same data. The second also allows you to insert any piece of Rholang data, however you also need to provide a public key and a signature over the data + a nonce. This option allows for the data stored in the registry to be updated by calling the registry again with the same public key and a new signature which is over the new data and a new nonce (which must be strictly larger than the old nonce, but not necessarily sequential). Nonces are 64-bit numbers, so there is a largest nonce. Inserting some data with that largest nonce makes it immutable because there is no larger nonce that can used to overwrite it.
In terms of versioning, you can still use the registry (with the `insertSigned` API), but instead of storing a contract name directly, perhaps you would store a map with keys being the versions (e.g. "1.2.3") and values being the contract names. You could then add a new version by simply updating the registry to hold a new map which includes the additional key-value pair.