Security and trust properties of inter-domain/ledger

Hi, I’m curious whether there is any technical mechanism that helps reduce trust requirements when doing interoperability between different domains or ledgers.

For example, when transferring a IOU Contract to domain2, how can the ledger convince itself that ledger1 has indeed burned the IOU and all previous IOU transactions on that ledger were valid (i.e. the IOU did not just appear out of nowhere)? Is this based on trust of a specific party/component?

2 Likes

Hi @Roman_Plasil , welcome to the Daml forums. The trust is in the signatories of the token. That’s why to transfer a token with signatories [alice, bank] from domain A to domain B, both alice and bank need to be connected to both domains A and B.

Thanks. So it sounds the trust is in the parties handling the transfer. Clearly that’s more useful to have a dynamic trust rather than fixed one for the whole network. But am I right that for the case of a token/iou that changes hands many times, I may find myself having to trust a random party who held the token some time ago that they correctly transferred it from ledger1 and didn’t create it out of nothing?

1 Like

In Daml - unlike in all other ledgers I’m aware of - receiving a token does not entitle you to any information about its history whatsoever. So even within the same ledger, when you accept a token, you have to trust at least one of its signatories. That’s why in our examples, the issuer of the token is always a signatory. They are the one party you should trust as they are the ones that would ultimately redeem the token.

Using that construct you can replicate different trust models. Eg to get consortium trust in a token (like on Stellar), you can have as signatory of your token the members of that consortium. They would then validate each transfer.

Or, if we added a decentralized public party to Daml, you could have them sign the Token in which case you get comparable trust and transparency to most public blockchains.

1 Like