对于提交，其事务的根操作称为顶级操作。任何账本提交的顶级操作也是账本的顶级操作。

因此，《Canton总账》代表了各方所采取的所有行动的完整历史。账本的图形结构在账本中的提交上产生了发生之前的顺序。我们说提交c``1 发生在 c``2当且仅当分类帐包含从c``1到c``2的非空路径，或者等效地，图的传递闭包包含来自c``1至c``2。

从视觉上看，账本可以表示为随着时间的推移从左到右增长的序列。下面，紫色垂直虚线标记了提交的边界，每个提交都标有其请求者和更新 ID。蓝色箭头将每个“Exercise”和“Fetch”操作链接到输入合约的“Create”操作。这些箭头强调账本形成了 UTXO 区块链意义上的交易图。

例如，以下 Daml 脚本对运行的 DvP 示例的整个工作流程进行编码。

let eurAsset = SimpleAsset with
      issuer = bank1
      owner = alice
      asset = "1 EUR"
eur <- submit bank1 do createCmd eurAsset
    
let usdAsset = SimpleAsset with
      issuer = bank2
      owner = bob
      asset = "1 USD"
usd <- submit bank2 do createCmd usdAsset
    
proposeDvP <- submit alice $ do
  createCmd ProposeSimpleDvP with
      proposer = alice
      counterparty = bob
      allocated = eur
      expected = usdAsset
disclosedEur <- fromSome <$> queryDisclosure alice eur

(newUsd, newEur) <- submitWithDisclosures bob [disclosedEur] do
    exerciseCmd proposeDvP $ AcceptAndSettle with toBeAllocated = usd

此工作流程产生如下所示的分类账，其中有四次提交：

• 在第一次提交中，银行 1 请求创建发放给 Alice 的 SimpleAsset 或 1 EUR（合约 #1）。
• 在第二次提交中，Bank 2 请求创建发放给 Bob（合约 #2）的 1 USD 的 SimpleAsset。
• 在第三次提交中，Alice 请求创建 SimpleDvpPoposal（合约 #3）。
• 在第四次提交中，Bob 请求对 DvP 提案行使AcceptAndSettle 选择权。

<img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/dvp-ledger.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=2905a7d8b725484c0035079b45d2ba07” className=“align-center” alt=“整个 DvP 工作流程的提交顺序。首先，银行 1 和 2 发行资产，然后 Alice 提出 DvP，最后 Bob 接受并结算。“宽度=“3322”高度=“1362”数据路径=“images/docs_website/dvp-ledger.svg”/> 完整性约束不会在独立提交之间强加顺序。在此示例中，前三个提交TX 0、TX 1和TX 2之间不需要有边，因此它们可以按任何顺序呈现。

由于账本是一个 DAG，因此我们总是可以通过拓扑排序将顺序扩展为线性序列。对于接下来的部分，我们假设账本是完全有序的（除非另有说明）。我们在因果关系部分讨论更一般的偏序。

{/* COPIED_START source=“docs-website:docs/replicated/daml/3.4/overview/explanations/ledger-model/ledger-validity.rst” hash=“3710723f” */}

有效账本

其核心是“有效账本”的概念；如果将相应的提交添加到分类帐中会产生有效的分类帐，则允许进行更改。 有效的账本是满足三个条件的账本：

da-model-consistency 不允许对非活动合约进行练习和提取，即尚未创建或已被练习消耗的合约。仅当密钥未与另一个未使用的合约关联且所有密钥断言均成立时，才能创建具有合约密钥的合约。

da-model-conformance 给定合约只允许执行一组受限的操作。

da-model-authorization 可能要求特定变更的各方受到限制。

这些条件中只有最后一个取决于请求变更的一方（或多方）；另外两个就一般了。

{/* COPIED_START source=“docs-website:docs/replicated/daml/3.4/overview/explanations/ledger-model/ledger-integrity.rst” hash=“c93dba12” */}

诚信

本节解决谁可以请求哪些更改的问题。

为了回答下一个问题“谁可以请求哪些更改”，需要精确定义哪些分类账是允许的，哪些是不允许的。例如，上面的油漆报价账本直观上是允许的，而以下所有账本都不是。

<图>

<图>

<图>

<图>

<图>

一致性

一致性由两部分组成：

1.合约一致性：合约必须在使用之前创建，一旦消费就无法使用。 2. 密钥一致性：密钥是唯一的并且满足密钥断言。

为了准确定义这一点，需要“之前”和“之后”的概念。这些是通过将所有操作按顺序排列而给出的。从技术上讲，序列是通过对账本操作进行预序遍历来获得的，注意这些操作形成了一个（有序的）森林。直观上，它是通过始终在其适当的子操作之前选择父操作来获得的，否则总是在右侧的操作之前选择左侧的操作。下图描述了油漆报价示例中的最终订单：

<img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/consistency-order-on-actions.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=dad56899a6c7f7695b4b59005554d5cf” className=“align-center” style={{width: “100.0%”}} alt=“提交的时间顺序。第一次提交，银行请求 Iou Bank A。第二次提交，P 请求 PaintOffer P A P123。最后一次提交，A 请求，Exe A (PaintOffer P A P123) 导致 Exe A (Iou Bank A) 导致 Iou Bank P 导致 PaintAgree P A P123” width=“1251” height=“518” data-path=“images/docs_website/consistency-order-on-actions.svg” />

在图像中，如果存在从 act 到 act' 的（非空）路径，则操作 act 在操作 act' 之前发生。然后，act'发生在act之后。

合约一致性

合约一致性确保合约在创建之后和使用之前被使用。

一致性条件排除了双花示例。正如下面的红色路径所示，示例中的第二次练习发生在对同一合约进行消耗练习之后，违反了合约一致性标准。

<img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/consistency-banning-double-spends.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=f905e3b64ca7636365f4631da7185fe1” className=“align-center” style={{width: “100.0%”}} alt=“另一个提交时间序列。在第一次提交中，Iou Bank A 被银行请求。在第二次提交中，Exe A (Iou Bank A) 通过红线通向 Iou Bank B，表明违反了合约一致性。在第三次提交中，Iou Bank B 通过红线通向 Exe A (Iou Bank A)，Exe A (Iou Bank A) 通向 Iou P 银行。”宽度=“1220”高度=“362”数据路径=“images/docs_website/consistency-banning-double-spends.svg”/>

1. 主动，如果c最新的状态变化是创建；
2. 已存档，如果c的最新状态更改是一项消耗性的练习；
3. 不存在，如果c从未改变过状态。

如果仅当 c 处于活动状态时才发生c 上的 Exercise 和 Fetch 操作，并且仅当 c 不存在时才发生 Create 操作，则c 的账本是一致的。下图直观地展示了示例账本中所有点的不同合约的状态。<图> <img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/consistency-paint-offer-activeness.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=166f2ac81a3fbf9309dd910c050956cf” className=“align-center” style={{width: “100.0%”}} alt=”./images/consistency-paint-offer-activeness.svg” width=“1251” height=“502” data-path=“images/docs_website/consistency-paint-offer-activeness.svg” />

<图> <img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/consistency-alice-iou-activeness.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=1707ba950349e96fa049806cf0dc1350” className=“align-center” style={{width: “100.0%”}} alt=”./images/consistency-alice-iou-activeness.svg” width=“1251” height=“502” data-path=“images/docs_website/consistency-alice-iou-activeness.svg” />

顺序的概念可以在所有不同的账本结构上定义：操作、交易、交易列表和账本。因此，一致性、输入和输出以及合约状态的概念也可以在所有这些结构上定义。账本的活跃合约集是账本上所有活跃合约的集合。对于上面的例子，它由合约Iou Bank P和PaintAgree P A组成。

关键一致性

合约密钥为账本引入了关键的唯一性约束。为了捕捉这个概念，合约模型必须为系统中的每个合约指定该合约是否有密钥，如果有，则指定该密钥。每个合约最多可以有一个密钥。

就像合约一样，每个密钥都有一个状态。动作 act 是一个 按键上的动作 k 如果

• act 是对带有密钥 k 的合约 c 的 创建、执行或 获取 操作，或者
• act 是关键断言 NoSuchKey k。

如果密钥状态为 空闲 或 未知，则该密钥未分配。

密钥一致性确保每个密钥最多有一个有效合约，并且所有密钥断言都得到满足。

密钥一致性排除了有关密钥一致性的有问题的示例。例如，假设油漆工P已向A提出了参考编号为P123的油漆报价，但A尚未接受。当P尝试使用相同的参考号P123为David创建另一个油漆报价时，此创建操作将违反密钥唯一性。以下分类帐违反了密钥(P, P123)的密钥唯一性。

<图> </图>关键断言可以在工作流程中使用来证明某种合同不存在。例如，假设画家P是画家工会U的成员。该联盟保留了一份潜在客户黑名单，其成员不得与之开展业务。如果存在有效合同Blacklist @U &A，则客户A 被视为在黑名单上。为了确保在 A 被列入黑名单的情况下，画家 P 不会提供绘画报价，画家将其提交与密钥 (U, A) 上的 NoSuchKey 断言结合起来。以下账本显示了该交易，其中UnionMember U P代表P在联盟U中的成员资格。它授予P执行此类断言的选择，这是授权所需的。

<图> </图>

就像其他一致性概念一样，密钥一致性扩展到操作、事务和事务列表。

账本一致性

定义»账本一致性« 如果所有合约和所有密钥都一致，则分类账是一致的。

内部一致性

对于孤立的操作和事务来说，上述一致性要求太强了。例如，油漆报价示例中的承兑交易与分类账不一致，因为PaintOffer A P Bank和Iou Bank A合约在之前没有创建的情况下使用：

然而，交易仍然可以附加到创建这些合约并产生一致的分类账的分类账中。此类交易被称为内部一致，诸如PaintOffer A P Bank P123和Iou Bank A之类的合约称为交易的输入合约。对偶而言，交易的输出合约是交易创建但不存档的合约。

请注意，对于内部不一致的交易，输入和输出合约是未定义的。下图显示了内部一致和不一致事务的一些示例。

<图> <img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/internal-consistency-examples.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=ac4fdf1301dcb0ae79c2da90326df85f” className=“align-center” style={{width: “100.0%”}} alt=”./images/internal-consistency-examples.svg” width=“1100” height=“583” data-path=“images/docs_website/internal-consistency-examples.svg” />

与输入合约类似，我们将输入键定义为在交易开始时必须取消分配的集合。

定义»输入键« 如果 k 上的第一个操作 act 是 Create 操作或 NoSuchKey 断言，则密钥 k 是内部一致事务的 输入密钥。在黑名单示例中，P的交易有两个输入密钥：(U, A)（由于NoSuchKey操作）和(P, P123)（因为它创建了PaintOffer合约）。

一致性

一致性条件限制了账本上可能发生的操作。这是通过考虑 合约模型 M（或简称 模型）来完成的，它指定了所有可能操作的集合。如果账本上的所有顶级操作都是M的成员，则账本符合M（或符合M）。与一致性一样，一致性的概念不依赖于提交的请求者，因此它也可以应用于事务和事务列表。

例如，IOU 合约上允许的操作集可以描述如下。

<img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/models-simple-iou.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=367e3af7930fd69042909a29a8eff573” className=“align-center” style={{width: “80.0%”}} alt=“IOU 合约上允许的一组创建、转移和结算操作，如下面的段落所述。“宽度=“907”高度=“420”数据路径=“images/docs_website/models-simple-iou.svg”/>

图像中的框是模板，因为框内的合约参数（例如义务人或所有者）可以通过适当类型的任意值来实例化。为了便于理解，每个框都包含一个标签，描述相应操作集的直观目的。如图所示，转账箱施加了约束，即银行必须在已执行的 IOU 合约和新创建的 IOU 合约中保持不变。但是，所有者可以任意更改。相反，在和解行动中，银行和所有者必须保持不变。此外，为了保持一致，转让行为的参与者必须与合同的所有者相同。

当然，对参数之间关系的约束可以是任意复杂的，并且不能方便地在该图形表示中再现。这就是 Daml 的作用——它提供了一种更方便的方式来表示合约模型。 Daml 和合约模型之间的联系将在后面的部分中更详细地解释。

要查看实际的一致性标准，假设合约模型仅允许对 PaintOffer 和 PaintAgree 合约执行以下操作。

<img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/models-paint-offer.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=18c41c80ee34b639d2667e24cd9cb211” className=“align-center” style={{width: “90.0%”}} alt=“PaintOffer 和 PaintAgree 合约上可用的创建和接受操作。“宽度=“942”高度=“551”数据路径=“images/docs_website/models-paint-offer.svg”/>

爱丽丝更改要约结果以避免转移资金的示例的问题现在变得显而易见。

<img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/non-conformant-action.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=8c316201ce7b19be6d74a60c83d5e1fc” className=“align-center” alt=“说明问题的时间顺序，如下所述。“宽度=“1220”高度=“502”数据路径=“images/docs_website/non-conformant-action.svg”/>

A 的提交不符合合约模型，因为该模型不包含她尝试提交的顶级操作。

授权

最后一个标准排除了最后两个有问题的例子，即强加给画家的义务以及画家偷了爱丽丝的钱。其中第一个如下所示。

<img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/invalid-obligation.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=87da739c05b2ea006c1370a44095d7c4” className=“align-center” style={{width: “100.0%”}} alt=“仅显示一次提交的时间序列，其中 A 请求 PaintAgree P A P123。“宽度=“1220”高度=“242”数据路径=“images/docs_website/invalid-obligation.svg”/>

这个例子直观上不允许的原因是，PaintAgree合同应该表达油漆工有义务粉刷爱丽丝的房子，但他从未同意这项义务。在纸质合同中，义务在合同正文中表达，并强加给合同的签署人。

签署者和维护者为了捕获现实世界合约的这些元素，合约模型还为系统中的每个合约指定：

1. 非空的签字人集合，即受合同约束的各方。
2. 如果合约与密钥相关联，则为一组非空的 维护者，确保该密钥最多存在一个未使用的合约的各方。维护者必须是签名者的子集并且仅依赖于密钥。这种依赖性由函数maintainers捕获，该函数接受密钥并返回密钥的维护者。

在示例中，合约模型指定

1. Iou obligor owner合约只有obligor作为签署人。
2. MustPay obligor owner 合约有obligor 和owner 作为签署人。
3. PaintOffer houseOwner painter obligor refNo合同只有油漆工作为签字人。其关联键由画家和参考号组成。画家是维护者。
4. PaintAgree houseOwner painter refNo 合同有房主和油漆工双方签字。密钥由油漆工和参考号组成。画家是唯一的维护者。

在下面的图形表示中，合同的签署人用美元符号（作为义务的助记符）表示，并使用粗体。维护者被标记为@（作为强制唯一性的助记符）。由于维护者始终是签名者，因此标有 @ 的各方是隐式签名者。例如，注释油漆要约接受行动与签名者会产生下图。

<img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/signatories-paint-offer.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=f59d4caeae372b52ca5a79b4043248b9” className=“align-center” style={{width: “60.0%”}} alt=“原始油漆交易流程图。P 是维护者；A 和银行是签署者。“宽度=“620”高度=“363”数据路径=“images/docs_website/signatories-paint-offer.svg”/>

授权规则

签名者允许人们准确地声明画家有一项义务。强加的义务直观上是无效的，因为画家不同意这项义务。换句话说，画家没有“授权”创造义务。

在 Daml 账本中，一方可以通过以下方式之一授权提交的子操作：

• 提交的每个顶级操作均由提交的所有请求者授权。
• 合同c上的行使行动act的每项后果均由c的所有签署者和act的所有参与者授权。

第二条授权规则编码了要约-接受模式，这是合同法中合同成立的先决条件。合同c实际上是作为要约人的签署者的要约。该活动是受要约者接受要约。执行的结果可以解释为合同主体，因此 Daml 账本的授权规则与合同法中合同形成的规则密切相关。

1. 合约c的创建操作所需的授权者是c的签署人。
2. Exercise 或 Fetch 操作所需的授权者是其参与者。
3. NoSuchKey 断言所需的授权者是密钥的维护者。

我们将这个概念提升到分类账，即当分类账的所有提交都得到充分授权时。

示例

通过查看一些示例，可以很容易地直观地了解授权定义的工作原理。主要的例子，油漆报价分类账，直观上是合法的。因此，根据我们的定义，它也应该得到充分授权，事实确实如此。

在下面的可视化中，Π ✓ act 表示各方Π 授权操作act。授权结果如下所示。<img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/authorization-paint-offer.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=489df8e52d59814ff917a1f669b1e202” className=“align-center” alt=“原始油漆处理时间顺序，根据下面的授权进行深入描述。“宽度=“1311”高度=“502”数据路径=“images/docs_website/authorization-paint-offer.svg”/>

在第一次提交中，银行通过请求该提交来授权创建 IOU。由于银行是 IOU 合同的唯一签署人，因此该承诺具有充分的授权。同样，在第二次提交中，画家授权创建油漆报价合同，并且画家是该合同的唯一签署人，使得该提交也得到了充分授权。

第三次提交更加复杂。首先，Alice 通过请求来授权对油漆报价的行使。她是这次演习中唯一的演员，因此这符合授权要求。由于画家是油漆报价的签字人，而爱丽丝是演习的参与者，因此他们共同授权演习的所有后果。第一个结果是对 IOU 的练习，以 Alice 为主角，所以这是允许的。第二个结果是通过执行旧的 IOU（对于 A）创建新的 IOU（对于 P）。由于借条之前是由银行签署的，Alice是演练的主角，所以他们共同授权了这次创作。由于银行是唯一签署人，因此该行为是允许的。最终的结果是与爱丽丝和画家作为签字人签订了绘画协议。既然他们都授权了这一行动，那么这也是允许的。因此，整个第三次提交也是经过良好授权的，账本也是如此。

同样，我们的授权标准禁止直观上有问题的示例。在第一个例子中，爱丽丝强迫油漆工粉刷她的房子。该示例的授权如下所示。

<img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/authorization-invalid-obligation.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=d200a3bae13cf1b9de6cbf4664112c70” className=“align-center” alt=“爱丽丝强迫油漆工粉刷她的房子的场景的时间序列，下面将根据授权进行深入描述。“宽度=“1220”高度=“242”数据路径=“images/docs_website/authorization-invalid-obligation.svg”/>

Alice 通过请求授权对 PaintAgree 合约执行 Create 操作。不过，画师也是PaintAgree合约的签署人，但他并没有授权创建动作。因此，这个账本确实没有得到很好的授权。

在第二个例子中，画家从爱丽丝那里偷了钱。

<img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/authorization-stealing-ious.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=46bd84bcbf8f39ac6fff1787bc759dc4” className=“align-center” alt=“画家偷了爱丽丝的钱的场景的时间序列，下面将根据授权进行深入描述。“宽度=“1220”高度=“355”数据路径=“images/docs_website/authorization-stealing-ious.svg”/>

银行通过请求此操作来授权创建借据。同样，画家授权将欠条转让给他。然而，本次演习的执行者是 Alice，她并未授权此次演习。因此，这个账本没有得到很好的授权。

有效的账本、义务、要约和权利

Daml 账本旨在模仿现实世界中各方之间的互动，并受合同法管辖。账本上的有效性条件以及合同模型中包含的信息与合同法的概念有一些微妙的联系，值得指出。

首先，合同规定了隐含的账本义务，这是由于合同执行的后果而产生的。例如，PaintOffer 包含A 的账本义务，如果她接受要约，则转移她的 IOU。

其次，Daml 账本上的每个合约都可以模拟真实世界的报价，其结果（账本内和账外）由合约模型允许的合约上的 Exercise 操作指定。第三，在Daml账本中，就像在现实世界中一样，一个人的权利就是另一个人的义务。例如，A接受PaintOffer的权利，而P则有义务在她接受的情况下粉刷她的房子。在Daml账本中，合同模式下的一方权利是基于授权和一致性规则，该方可以执行的行使行为。

最后，有效性条件确保了 Daml 账本模型的三个重要属性，模仿合同法。

1. 义务需要同意。 Daml 账本遵循合同法的要约-接受模式，从而确保所有账本合同都是自愿形成的。例如，以下分类帐无效。

   <img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/authorization-invalid-obligation.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=d200a3bae13cf1b9de6cbf4664112c70” className=“align-center” style={{width: “100.0%”}} alt=“Alice 强迫油漆工粉刷她的房子的场景的时间顺序，如前面的授权规则示例部分所述。“宽度=“1220”高度=“242”数据路径=“images/docs_website/authorization-invalid-obligation.svg”/>

2. 需要同意才能取消账本权利。由于只有行使行动消耗合约，因此不能剥夺行动者的权利；合约模型明确指定了参与者是谁，授权规则要求他们批准合约消费。

   在例子中，Alice 有权转让她的 IOU；画家试图通过自己进行转移来立即从她手中夺走这一点，但这是无效的。

   <img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/authorization-stealing-ious.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=46bd84bcbf8f39ac6fff1787bc759dc4” className=“align-center” style={{width: “100.0%”}} alt=“画家偷走爱丽丝的钱的场景的时间顺序，之前在授权规则示例部分中进行了解释。“宽度=“1220”高度=“355”数据路径=“images/docs_website/authorization-stealing-ious.svg”/>

   各方仍然可以将其权利“委托”给其他方。例如，假设爱丽丝没有接受画家的报价，而是决定向他还价。然后画家可以接受这个还盘，其后果与之前一样：

   <img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/counteroffer-acceptance.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=9923105b566068031bd08e1f6787c44d” id=“counteroffer-acceptance” className=“align-center” style={{width: “60.0%”}} alt=“原来的 PaintAgreement 流程图，但现在最上面的合约是 CounterOffer。“宽度=“600”高度=“363”数据路径=“images/docs_website/counteroffer-acceptance.svg”/>

   在这里，通过创建CounterOffer合约，Alice将她将IOU合约转让给画家的权利。如果是委托，在提交之前，请求者必须了解属于所请求交易一部分的合同，但请求者不是签署人。在上面的例子中，画家必须先知道Alice的借条的存在，然后才能请求接受CounterOffer。下一节中介绍的观察者和泄露的概念可以实现这种场景。

3. 不能单方面逃避账本义务。一旦一项义务被记录在 Daml 账本上，就只能根据合同模型将其删除。例如，假设前面所示的 IOU 合约模型，如果账本记录了MustPay合约的创建，那么银行以后就不能简单地记录消耗该合约的操作：

   <图片src =“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/validity-no-removal -of-obligations.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=8eb83f0989399fc8152a044a779fa839” className=“align-center” style={{width: “100.0%”}} alt=“一个时间序列，其中第一次提交包括创建 MustPay 合约，第二次提交包括使用该合约的银行，如上所述。“宽度=“1220”高度=“251”数据路径=“images/docs_website/validity-no-removal-of-obligations.svg”/>

   也就是说，这个账本是无效的，因为上述行为不符合合约模型。{/* COPIED_START source=“docs-website:docs/replicated/daml/3.4/overview/explanations/ledger-model/ledger-privacy.rst” hash=“b3c9457c” */}

隐私

账本结构部分回答了“账本是什么样子？”的问题。通过引入分层格式来记录各方交互的变化。本节解决“谁看到哪些更改和数据？”的问题。也就是说，它解释了 Canton Ledgers 的隐私模型。

Canton Ledgers 的隐私模型基于需要知道的基础，并在子交易级别提供隐私。也就是说，一方仅了解影响该方拥有权益的合同的各方互动的那些部分，以及这些互动的后果。层次结构在这里很关键，因为它产生了子交易隐私的自然概念。为了使子交易隐私概念更加精确，我们引入了“被告知者”和“见证者”的概念。

知情人

一方可以在 Daml 模板和选择中扮演不同的角色；该方可以声明为signatory、选择controller、合同或选择observer。对于合同，如果一方是合同的签署人或合同观察员，则该方是利益相关者。

• 顾名思义，每个合同和选择observer都应分别观察合同的更改（创建或存档）和选择的行使。
• signatory受合约约束，因此拥有合约权益；他们应该了解合同何时创建或使用。
• 练习的参与者，即所选择的controller，在该动作中拥有利害关系，因此应该看到该练习；但他们可能在合同中没有利益。

这些观察结果引发了以下“被告知者”的定义，即应该被告知某项行动的一组各方。节点的信息对象是下表中标有 X 的集合的并集，

例如，Create节点的信息接收者是所创建合约的利益相关者，即签署者和观察者。对于消费Exercise节点，信息接收者包括消费合约的利益相关者、行动的参与者和选择观察者。

作为一项设计决策，合约观察者不会被告知非消耗性的 Exercise 和 Fetch 操作，除非它们明确地位于参与者或选择观察者之中。这是因为此类操作不会改变合约本身的状态。

为了说明信息接收者的概念，我们使用 Alice 和 Bob 交换资产的运行示例。 AcceptAndSettle动作中的节点具有下图蓝色六边形所示的被通知者。例如，Alice 是根节点①的信息者，因为她是输入合约 #3 的签署人，而 Bob 是信息者，因为他是选择的参与者。类似地，Bank 2 和 Bob 是 Fetch 节点 ③ 的通知者，因为 Bank 2 是输入合约 #2 的签署人，而 Bob 是参与者。如果鲍勃不是参与者，他就不会成为信息接收者，因为合约观察者不会自动成为非消耗性练习和获取的信息接收者。<img src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/dvp-acceptandsettle-informees.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=deab88d50ec2ecdae62259b6fc20baa5” className=“align-center” style={{width: “100.0%”}} alt=“AcceptAndSettle 操作中节点的被通知者。” width=“2321” height=“1311” data-path=“images/docs_website/dvp-acceptandsettle-informees.svg” />

动作的被通知者是其根节点的被通知者。 Importantly, nodes cannot exist without their children on the Ledger, as mentioned in the ledger structure section;只有行动才能做到，因为它们是整棵树。因此，动作的被通知者有权查看该动作中的所有节点，即使他们不是某些单独节点本身的被通知者。这种差异在下一节的证人概念下得到了形式化。

见证人

单个节点可以是多个操作的一部分。例如，下图扩展了子操作图，每个子操作的无边框框的右上角显示了被通知者。 Here, the Create node ③ is part of three subactions, namely those rooted at nodes ①, ②, and ③.因此，该创建节点会向所有这些操作的通知者显示，即使他们不是节点本身的通知者。这些当事人被称为证人。形式上，对于给定的交易tx，tx中节点的见证人是包含该节点的tx所有子操作的通知者的并集。 In particular, every informee of the node is also a witness.

该图以紫色显示子操作的根操作的见证人。对于节点③，见证人是Alice、Bob和银行1，因为Bob是①和③的信息者；银行1是②、③的被告知人； Alice 是①、②的被告知者。

<img src=“https://mintcdn.com/cantonfoundation/zmlOjLpKuDjnaObr/images/docs_website/dvp-settle-witness.svg?fit=max&auto=format&n=zmlOjLpKuDjnaObr&q=85&s=fced7c0cefb8dc1176e5657ff6ce9e75” className=“align-center” style={{width: “60.0%”}} alt=“Settle选择的子动作的通知者和节点的见证者。“宽度=“1122”高度=“1082”数据路径=“images/docs_website/dvp-settle-witness.svg”/>

投影

知情者应该看到他们有权看到的更改，但这并不意味着他们有权看到包含此类更改的任何交易的全部内容。这是通过交易的“预测”来实现的，它定义了一组各方对交易的看法。直观上，给定提交内的交易，一组参与方只能看到包含合约上所有操作的子交易，其信息接收者至少包括其中一个参与方。 Equivalently, the group of parties sees only those nodes whose witnesses include at least one of the parties. Thus, privacy is obtained on the subtransaction level.

This section first defines projections for transactions and then for ledgers.

交易预测

下图给出了以AcceptAndSettleExercise操作作为唯一根操作的交易示例，其通知者如上图所示。

<图片src=“https://mintcdn.com/cantonfoundation/QAGFSphBsRkeZIBi/images/docs_website/dvp-acceptandsettle-projection.svg?fit=max&auto=format&n=QAGFSphBsRkeZIBi&q=85&s=19d1943bd83536d7d81d2d3748a81ef1” className=“align-center” style={{width: “100.0%”}} alt=“image” width=“1748” height=“3362” data-path=“images/docs_website/dvp-acceptandsettle-projection.svg” />

由于 Alice 和 Bob 都是根操作的信息接收者，即 Bob 对 Alice 的 ProposeSimpleDvP 合约行使 AcceptAndSettle 选择，因此对 Alice 或 Bob 或两者的投影包含整个“行使”操作。 As an action consists of the whole subtree underneath its root node, Alice and Bob each see all the nodes they are witnesses of. For example, Alice’s projection includes the Fetch subaction, Bob’s Transfer exercise of on #2, and the creation of Bob’s SimpleAsset contract #5.同样，Bob 的预测包括 Alice 的 Transfer 练习 #1 和 Alice 的 SimpleAsset 合约 #6 的创建。相比之下，银行“不是”根本行动的知情者。 In fact, Bank 1 appears as an informee only in the Transfer Exercise action on #1 and its subaction, the creation of Bob’s new asset #5.因此，对 Bank 1 的预测仅包含此练习操作。 Bank 2 显示为树中两个不相关操作的通知者：#2 上的 Fetch 操作和 Transfer 练习操作。因此，对银行 2 的投影包含以这两个操作作为根操作的交易。这表明投影可以将单个根操作转变为子操作列表。

底部对银行 1 和银行 2 的预测表明，对多方的预测可能比对每一方的预测包含的信息严格更多。换句话说，仅根据 Bank 1 的投影和 Bank 2 的投影来重建对 Bank 1 和 Bank 2 的投影是不可能的。这里，这是因为不能从各个投影中唯一地确定三个根动作的顺序。 For this reason, projection is defined for a set of parties.

一组 `P` 各方的交易的 **投影** 是通过对交易的每个根操作 `act` 执行以下操作获得的子交易。

1. If `P` contains at least one of the informees of `act`, keep `act` as-is, including its consequences.
2. Else, if `act` has consequences, replace `act` by the projection (for `P`) of its consequences, which might be empty.
3. Else, drop `act` including its consequences.

这个定义不是对节点进行操作，而是对动作进行操作，即节点的子树。因此，当且仅当P至少包含该节点的一个见证人时，一组参与方P的交易投影才包含该节点。

As a projection is a transaction, it is possible to project a projection further.投影操作具有以下吸收属性：对各方递减子集的投影是吸收的。也就是说，如果一组参与方P是Q的子集，那么首先将交易投影到Q，然后投影到P与直接将其投影到P相同。直观上，该属性表达了这样一个事实：一组各方共同了解的有关交易的信息至少与这些各方的任何子组自己了解的信息一样多。 The converse is false, as the above example with projection to Banks 1 and 2 has shown.

相反，如果P不是Q的子集，那么首先将交易投影到Q，然后投影到P，只会导致投影到P的子交易。例如，如果我们将银行 1 的上述投影投影给 Bob，则生成的交易仅包含合约 #5 的创建操作。 This is a proper subtransaction of Bob’s projection.

This difference reflects that Bank 1 learns less about the Exercise node than Bob.特别是，Bank 1 无法从其预测中推断出 Bob 是练习节点的见证人。 This is a general pattern: the informees of an action may not learn about witnesses of nodes therein. This is crucial from a privacy perspective as it hides who is involved in the hidden parts of the transaction.

账本投影

最后，一组 P 各方的分类账** l 的投影是更新的 DAG，如下所示：

• Project the transaction of each update in l for P, but retain the update ID.
• Remove updates with empty transactions from the result.

We defer defining the edges in the projection to the causality section. Until then, we pretend that the ledger is totally ordered and projections retain the same ordering.值得注意的是，账本的投影不是账本，而是更新的 DAG。 The requesters from the commit cannot be retained because they are typically witnesses of the actions in the projection, but not informees. Yet, the informees of the action must not know all the witnesses.例如，如果银行 1 的预测确实提到鲍勃是最后一次提交的请求者，那么银行 1 可以推断鲍勃是爱丽丝在合约 #1 上行使Transfer选择的见证人。

Projecting the ledger of the complete DvP example yields the following projections for each party.

proposeDvP2 <- submit alice $ do
  createCmd ProposeSimpleDvP with
      proposer = alice
      counterparty = bob
      allocated = newUsd
      expected = eurAsset

<figcaption>具有转移操作的多账本因果关系图</figcaption>

<figcaption>两个 Daml 账本上的分割油漆还价工作流程的多账本因果关系图</figcaption>