共识
共识模型
事件流依赖于有限的冲突解决或共识模型。全局共识和排序对发展并不是必需的，大多数决策都局限于单个事件流的消费方。保证是有限的，但如果任何两个参与者为同一事件流消费相同集合的事件，则它们将到达相同状态。事件流的底层日志结构允许创建多个平行历史记录或分支，从而形成树状结构。一个日志或有效的事件流是从已知“最新”事件到初始事件的单一树路径。最新时间也被称为“stream tips”。当日志中存在分支时，日志可以具有多个tips，并且用于该流程规范化日志选择“tip”的过程变成了一个共识问题
单流共识
流的Tip和规范日志是通过以下伪算法和规则选择的：
给定一组Tip，从每个Tip开始遍历树路径，直到共享的时间事件或初始事件。
从共享事件开始，反向遍历每条路径（朝向尖端即树的叶子节点），直到找到时间事件（或达到日志结尾）。这些事件集被认为是冲突的事件。
根据每个时间事件，确定时间戳证明中包含的交易的区块高度。选择具有最低块高度的路径。如果选择了单个路径，则退出并选择路径和Tip，否则继续。大多数情况下将在此处终止，拥有相同块高度将很少发生。
如果多个Tip具有相同的块高度，则选择从最后一个时间戳证明到 Tip 的事件数量最多的路径。如果一个单一路径被选择，则退出并选取该路径和Tip；否则请继续。
如果事件数量相等，则选择二进制格式中CID最小的事件和路径（这是任意但确定性的选择）。
跨流排序
假设网络中的所有时间戳事件都提交到同一个区块链，由时间戳事件中的chainId指定。Ceramic主网将时间戳证明提交到以太坊区块链。在流中添加时间戳事件为所有在同一区块链上打了时间戳的事件提供了相对全局时间的概念。如果更高级别的协议需要，这允许不同流之间的事件进行全局排序。Ceramic 事件也可以根据其所打上时间戳的区块链上的交易和状态进行排序。在大多数安全区块链上，您还可以参考墙钟时间，在某些合理范围内基于该时钟对系统内外部事件进行排序。
风险
滞后上传没有任何全局共识保证，所有的流和它们潜在的tips并不是任何时候都为所有参与者所知。网络中可能存在分区、c存在本地网络或个别参与者可能选择故意隐瞒某些事件而发布其他事件。这种有选择性的发布可能是恶意的，也可能不是，具体取决于流被消费的上下文。考虑以下示例：用户创建了一个流，进行了两个冲突的更新，并将其中一个时间戳早于另一个，但仅发布了后时间戳的更新数据。现在对流的后续更新将基于第二个已发布的更新进行。每个观察者都会接受这些更新作为有效，因为他们没有看到第一个更新。然而，如果用户稍后发布较早的更新数据，则该流将回溯到此次更新，并且对该流进行的所有其他更改都将无效。大多数情况下，在实践中故意延迟发布攻击并不成问题，在 Ceramic 中通常由单个用户控制各自拥有自己独立且互相独立之间不存在利益关系和攻击动机等原因导致攻击行为很少发生。然而，在允许多个最终用户写入同一条记录（stream）且具有更复杂访问控制的流中，这将成为一个更大的问题。在这种情况下，所有使用该流的用户都需要相信所有其他具有或曾经具有写入访问权限的用户，以确保他们不会秘密地保存时间戳写入而尚未发布，否则就会面临稍后揭示这些写入并导致流失去自先前秘密编写创建以来发生的所有编写。此外，请注意延迟发布也可能用作防止出售用户身份证明（identity）或账户。一个身份或账户的买家无法知道卖家是否在出售身份后公开保密事件。
Last updated