G-d willing
Hello,
It is quite a headache when a DAML code is updated due to the fact that all existing contracts needs to be re-signed in order to contain the upgrade.
If it was due to an additional field which is new to the agreement, or introducing a new choice, I would understand since the parties did not sign for that new feature.
But on the other hand, what if it is a bug fix, the parties did not sign on a contract that does not really do what it says. Hence, fixing the bug and updating the contract should not require the parties to re-sign the updated contract.
I think that allowing the administrator of the ledger to have the ability to upgrade certain contracts without having the consent of the parties is very important.
This is can be based on an existing relationship model between the parties and the administrator that explicitly says that the operator can upgrade contracts on behalf of the parties.
Maybe my solution is not good, but having a solution for this issue is crucial.
Thanks,
Hi @cohen.avraham
Thanks a lot for your input. We do share your sentiment, but providing a solution that is secure, easy to use and operationally sensible in this regard is not trivial. However, we think we have found a way and there is currently a team implementing it. It will effectively be a “secure, zero-downtime, infinitely scalable, single admin ops, non-lock step upgrading of contract code”. Personally, I’m actually excited about the project and I’m looking forward to start sharing it with the community.
Thanks! Ratko
1 Like
G-d willing
Hi @Ratko_Veprek
Thank you very much for your reply, and I have to say that I am very happy to hear that a possible solution will be available soon. Do you have any rough idea when such a solution will be available?
This is definitely a crucial update for DAML.
Thanks,
We will initially start with a company internal review, before we make the feature available as early access to the users, but that phase will only start next year, and obviously depends on successfully completing the internal testing. But rest assured, we do understand the importance and significance of this feature and we are working hard to make it available to the community as soon as possible.
1 Like
HI @cohen.avraham
I understand your frustration. We built and maintain a production system in daml and every 2 months upgrade the system with new enhancements and fixes
We applied the following 3 strategies to minimize the impact to our users
1 / Operator signatory. For certain contracts, the operator of the system has sole euathorithy to upgrade damle contracts. (this is a dirty workaround, and needs to be carefully considered, as it weakens the security of the system)
2/ multiple dar startegy: by crreating a modular design, only the specific dars impacted need to be upgraded, so lessons the burden for approvals
3/ pre-authorized approval for upgrades: this startegy gives authorithy to the operator of the system to upgrade. It can be revoked at any time so gives the power back to the owner of the contract
I am very interested to here though the design approach from @Ratko_Veprek . Happy to further test this for a real live client implementation
Bart
G-d willing
Thanks @bartcant for your detailed response.
Regarding the 3 enhancements you suggested, the first one is not acceptable, as this can break many things in terms of achieving the right permissions for every party, and hurts the security of the entire system.
Regarding your second advise, you are right. I am following this approach in the projects I am working on.
And regarding your last suggestion, well, say that I created a DAR file that defines a template, say I create contracts from this template where I am the party that is permission to exercise a choice named Update.
And while I update the DAR file with an updated version of the template, well, I cannot exercise the Update choice of the old contract from within the new DAR file. So, I am not sure I understand your suggestion. Maybe you can explain it a bit more.
Thanks,
Avraham