It is guaranteed that the Enter action precedes contract usage, subject to the trust assumptions of the underlying ledgers and the interoperability protocol.Ī contract may enter and leave the visibility of a Participant Node several times.įor example, suppose that the painter submits the following commands and their commits end up on the given ledgers. This may happen as part of command submission or for other reasons, e.g., load balancing. These Enter and Leave events are generated by the underlying interoperability protocol. There should be at most one Create action and at most one consuming Exercise action for each contract. The actions Enter and Leave are similar to a Create and a consuming Exercise action, respectively, except that Enter and Leave may occur several times for the same contract whereas The contract is reported in the Active Contract Service and can be used by command submission. This action signals that the Participant Node starts outputting events concerning this contract. The contract is accordingly no longer reported in the active contract service and cannot be used by command submissions.Ĭonversely, P2 outputs an Enter c2 action some time before the ArchivedEvent on the transaction stream. In particular not when the contract is archived. This action signals that the Participant Node no longer outputs events concerning this contract To keep the transaction stream consistent, P2 additionally outputs a Leave c1 action on Alice’s transaction stream. Then the Participant Node P2 outputs the Create action as a CreatedEvent, but not the Exercise in form of an ArchiveEvent on the transaction serviceīecause Ledger 2 can not notify P2 as P2 does not host Alice on Ledger 2.Ĭonversely, when one transaction creates a contract c2 with stakeholder Alice on Ledger 2 and another archives the contract on Ledger 1, then P2 outputs the ArchivedEvent, but not the CreatedEvent. In the above topology, e.g., one transaction creates a contract c1 with stakeholder Alice on Ledger 1 and another archives the contract on Ledger 2. With interoperability, a transaction can use a contract whose creation was recorded on a different ledger. The presentation assumes that you are familiar with the following concepts: This document explains the visibility limitations due to interoperability and their consequences for the Transaction Service, by example and formally by introducing interoperable versions of causality graphs and projections. In particular, interoperability affects which events a party observes and their order. These limitations influence what parties can observe via the Ledger API of each Participant Node. Interoperability may limit the visibility a Participant Node has into a party’s ledger projection, i.e., its local ledger, when the party is hosted on multiple Participant Nodes. Some Participant Nodes can connect to multiple ledgers and provide their parties unified access to those ledgers via the Ledger API.įor example, when an organization initially deploys two workflows to two Daml ledgers, it can later compose those workflows into a larger workflow that spans both ledgers. That is, the contracts created on one ledger can be used and archived in transactions on other ledgers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |