(1) If I understand correctly, the DAML w/ Canton does not share the back-chain (older) transactions history about a particular contract instance or token issued that was issued on a ledger. But how can the recipient of the transaction ensure its legitimacy/validity?
Hello,
A contract is either active or archived. If the recipient is an observer/signatory on a contract, he can definitly see it.
Maybe I don’t understand your question: Do you have an example in mind ?
1 Like
Good question. To understand the answer you need to understand the conceptual differences between a Canton ledger and other DLT systems.
On other systems, you have contracts that are managed by the “operators of the system”. In most cases, there is zero privacy. Everybody validates everything. That works, but it’s a bit at odds with the usual desire for privacy within a business context.
In Canton, a contract is only known to the stakeholders, and the transaction validation is restricted to the particular set of signatories of the contracts references therein. Daml contracts are really different than other smart contracts. They are not “abstract computing instructions”, but represent actual legal contracts with named people that have cryptographically signed the contract. The contracts are not legal prose, but describe the evolution of a contract into other stages as functional expressions.
In particular important with real world contracts is that you always enter it with a particular person. How well you need to know that person depends on your use-case. The same is true in the real world. If you buy a coffee, you can do that without your ID, but if you open a bank account, you can’t open it as “Mr. X”.
So, when we speak about privacy, then it’s about keeping the relationships (contracts) private from others. The signatories in a contract itself are not private in the sense that the stakeholders know which “unique-identifier” representing a party and a participant is involved in a particular transaction. Albeit the “unique-identifier” doesn’t tell you more than “there is someone with a key”, and sometimes you need to run some KYC process (which you can do as Daml contracts) to learn about the real identity of a certain party in the form necessary for your business.
Let’s use an example. I have Alice, Bob and Bank. Bank and Alice have an I-OWE-YOU (IOU) contract with owner = Alice, obligor = Bank, amount = CHF 100. Now, when Alice wants to transfer this contract to Bob, Alice will exercise something like a “Transfer” choice that we assume exists in the IOU contract.
In this case, Alice’ participant will send a transaction involving [Alice, Bob, Bank]. The Bank (as the signatory of the IOU) will validate the transaction and confirm it. The Bank has no other choice than to confirm it, as the validation is deterministic (so deviation is detected as malicious behaviour). So Bob gets first hand evidence that the Bank is okay with the statement that it doesn’t owe Alice anything anymore and that they owe now to Bob. And this is something that you actually want: if somebody owes you money, you want to be sure that they still agree to that.
Does that help?
Cheers,
Ratko
4 Likes
Thanks @Ratko_Veprek for clarification.
So in case of malicious behaviour - what strategy we employ?
Does Canton Domain helps to provision strategies to mitigate such behaviours?