True。如此，这个记录在合约中的哈希值，就可以当成是一个事实（某个事件已经发生）的证明。这个为 Fact Registry 合约引入一个新的事实的过程，通常称为 「事实注册」。一笔签过名的 CT 所包含的链上事件的指纹有两个字段（实际上是这两个参数的哈希值）：（1）一个 Fact Registry 合约的地址；（2）上述合约中应当记录的事实。 StarkEx 有条件交易StarkEx 会批量打包 Layey-2 中的交易，并使用一条发送到链上的 STARK 证明来结算这些交易。如果某一批次中包含 CT，StarkEx 将保证相关的事实已经注册，以便能清算该批交易；否则，整批交易都会回滚。 有条件交易的案例在本部分，我们会提出一些应用场景，并指出 CT 如何能用在这些场景中。 详细案例 —— 快速取款在任意 L2 方案中，最初级的从 L2 转出资金到 L1 中的办法便是终局化一次 L2 的状态更新（在该次更新中包含一笔取款交易）。在基于有效性证明的系统（比如 StarkEx）中，终局化一次 L2 的状态更新需要在链上提交一个相应（于此次更新）的有效性证明，一般来说需要 10 分钟。这就意味着，如果用户使用这种方式来取款，就不得不等待至少 10 分钟。 而快速取款的用意正是为了解耦这种（取款对 L2 状态更新的）依赖，让用户能够在 「区块时间」 内免信任地将资金取出，也即，就像使用普通的以太坊合约一样。 那到底是怎么个流程呢？如果 Alice 想要从 L2 中取出 1 ETH 到 L1，Alice 可以在 L2 上签名一条将 1 ETH 转移给流动性提供者（LP）的 CT，条件是 LP 在 L1 上转移 1 ETH （减去一些手续费）给 Alice。Alice 的 CT 仅能在她收到 L1 上的转账之后才能执行，所以她不会面临对手方风险。 我们来看一个能够协助 CT 的简易的 Fact Registry 合约：
我们可以看到这个合约有一个 payabe 函数
Alice 签发的 CT 只有 keccack(1 ETH, Alice, nonce) 在 Fact Registry 中注册之后才能执行。而这个事实，也只有在给 Alice 的 1 ETH 转账发生了之后才能成功注册。Alice 可以无需信任地取出 1 ETH，整个过程只需她的前面，和 LP 在以太坊链上发起的一笔交易。 更多应用场景类似的流程可以捕捉到下列类型的事件，从而 L2 的 CT 也可以有更多的用途，例如：
|
