Ceramic：专注于内容动态更新的去中心化存储方案

该篇文章内容来源于Ceramic Protocol官网的介绍：Introduction - Ceramic Developers，和该项目的Github仓库文档：ceramic/SPECIFICATION.md at main · ceramicnetwork/ceramic (github.com)。

本人只是翻译的搬运工，如有侵权，请联系本人（VX:aichixianyu199x）进行删除。以下是中文翻译内容：

Ceramic是一种去中心化的协议，可以在全球公共网络上创建可变的防篡改数据结构。Ceramic的可编程数据流是通过数字签名，流更新规则和区块链锚定的组合来实现的。Ceramic流可用于构建灵活的数据结构，这些结构又可用于表示各种内容，例如自我主权身份，特定数据或内容，媒体文件，模式，数据访问控制策略，可验证的凭据，多方之间的协议等。该协议不依赖于任何特定的区块链系统，而是利用IPLD将更改编码为哈希链接数据结构，称为Merkle DAG（有向无环图），并将这些更新锚定到区块链中，该区块链为给定流的更新提供严格的排序。验证特定流的状态只需要用户同步给定流的数据，并且用户不需要像所有维护全局状态的区块链网络（即比特币，以太坊）那样同步整个网络的状态。因此，Ceramic网络中的节点可以选择仅固定它所关心的流。这意味着没有流的全局分类帐。

Ceramic 流由仅追加提交的日志组成，其中更新由去中心化身份 （DID） 签名，根据一组状态转换规则进行验证，然后锚定在区块链上。流类型指定显式规则，这些规则控制对流的有效更新（状态转换）的构成。这种架构允许陶瓷节点以分散的方式管理和验证给定流的状态，而无需集中式服务器或中间人。当对特定流进行有效更新时，节点会将更新广播到网络的其余部分，并且对此流感兴趣的任何节点都将更新其节点上给定流的状态。因此，任何节点都可以接收对流的查询并返回正确的状态，即使它不维护流本身的状态也是如此。只要网络上至少有一个节点继续保持给定流的状态，该流就对网络上的任何节点都可用。

Ceramic是一个去中心化的可组合数据网络，Ceramic让使用可组合的 Web3 数据构建应用程序变得非常简单，就像浏览数据模型市场、将它们插入到应用中以及存储、更新和检索这些模型中的数据一样简单。当不同的应用程序重用相同的数据模型时，它们的数据会自动进行互操作。通过去中心化的应用程序数据库，Ceramic使数据在所有应用程序中可组合和可重用。

Ceramic的优点

Ceramic的去中心化的数据网络为Web3开发人员提供了一系列功能，使得构建可扩展的Web3应用程序成为可能，这些数据可以跨应用程序重用和共享。

数据可组合性：Ceramic上的数据是结构化的，存储在数据模型中，这些数据模型可以很容易地被不同的应用程序重用，以便在它们之间共享数据。数据模型由社区中的开发人员创建，数据模型的生态系统在不断扩大。数据模型通常表示单个逻辑应用程序功能，如用户配置文件、社交图谱或博客，开发人员通常组合多个数据模型来创建其应用程序。

开发人员体验：在 Ceramic 上使用 Web3 数据构建可组合应用程序非常简单。安装 Ceramic，浏览数据模型市场，将这些模型插入您的应用程序，并自动访问存储在网络上的符合这些数据模型的所有数据。社区不断创建新的工具，使其更易于构建，并扩展可组合数据的可能性。

使用 Web3 登录：Ceramic对用户帐户使用去中心化身份（DID）标准，该标准与所有区块链钱包兼容。在您的应用程序中使用 Ceramic 时，用户可以使用他们已经拥有的 Web3 钱包进行身份验证，甚至可以根据需要从多个不同的区块链钱包（跨链）控制同一个 Ceramic 帐户。数据模型通常以帐户为中心，这意味着每个用户都可以控制自己的数据。

去中心化：Ceramic网络是去中心化的，无需许可，允许世界上的任何人启动一个节点，为网络上构建的用户和应用程序提供存储，计算和带宽资源。今天，运行Micromata没有标记化的激励措施，但社区正在探索各种选择。

可伸缩性：Ceramic的数据网络基础设施具有高度可扩展性，可以为需要大量数据吞吐量的用例提供服务。在 Ceramic 上，每个数据对象都维护自己的状态，节点独立处理流事务，从而实现无限并行化。这使得Microcial能够以全球数据规模运营，这比去中心化金融所需的规模大几个数量级。

Ceramic的运行机理

Ceramic使应用程序的数据库去中心化，数据在应用程序之间普遍可组合和重用。该网络由三个核心部分组成：一是高度可扩展的、去中心化的用于数据可用性和共识的基础设施，一是社区创建的数据模型市场，一是一套用于存储、更新和检索这些模型的数据的标准API。

可扩展、去中心化的数据基础设施

Ceramic最基础的一层是其可扩展的、去中心化的数据网络。Ceramic网络由一组无许可节点组成，这些节点协同工作，为网络上存储的所有状态提供数据可用性，并努力在每次有新事务时就这些状态达成共识。
然而，与旨在跟踪代币等金融应用程序的状态的第1层区块链不同，Ceramic专门设计用于跟踪高吞吐量数据应用程序的状态，例如去中心化社交网络，去中心化身份，加密游戏，声誉系统等。通过这种方式，Ceramic充当了一个全球性的，高度可扩展的去中心化数据库，世界上每个应用程序都可以在此基础上进行构建。
为了实现规模化，Ceramic对其网络的数据结构做出了一些固执己见的决定。最重要的是，在Ceramic中，没有可以在帐户之间共享的状态概念。每个州都只由创建它的帐户拥有，任何帐户都不能修改其他任何人的状态，尽管任何帐户都可以链接到另一个帐户拥有的一部分国家。
在 Ceramic 上，每个帐户都有一个可变数据对象的集合，称为流，只有他们作为这些流的所有者才能写入。存储在每个流中的内容是任意的，并且可以引用其他任何人的流中的内容。请注意，这并不排除计算。开发人员可以编写称为流代码的函数，用于定义如何更新这些流以及它们在每次新更新时执行的操作。
此体系结构可理清用户之间的状态，使系统能够非常清晰地水平扩展。您可以想象，账户 1 - 1000000 复制在另一组 Ceramic 节点上，账户 1000001 - 2000000 复制在另一组节点上。从理论上讲，如果需要，网络可以一直分片到每个用户，而不会破坏可组合性。为了确保用户分片之间的状态可验证性和可组合性，Ceramic依赖于Merkle树数据结构，该结构聚合了所有用户之间的事务，允许任何帐户随时验证任何其他人的流的完整性。

数据模型市场

Ceramic的第二个核心组件是其由社区创建的充满活力的开源数据模型生态系统，这些模型用于解锁跨应用程序的数据可组合性。数据模型是一种新颖的抽象，它统一了类似类型的应用程序如何存储和检索网络上每个用户的状态。例如，你可以想象每个去中心化的Twitter实现都将在几个共享数据模型上运行：一个用于每个用户的推文，一个用于他们的社交图谱，一个用于他们的DM，等等。通过采用相同的基础数据模型，应用程序能够对相同的数据进行本机互操作。
您可以将 Ceramic 对数据模型标准的使用与对金融分类账的令牌标准的使用进行比较。例如，在以太坊上，ERC-20可互换令牌和ERC-721不可替代令牌标准的引入已经产生了整个本地互操作的令牌和金融应用程序生态系统。陶瓷将同样的概念带入了数据。
Ceramic采用社区驱动的方法来创建这些数据模型，允许任何开发人员轻松地定义，共享和重用其模型与生态系统中的其他开发人员。随着社区创建更多的数据模型，我们将看到使用可组合数据构建的应用程序的数量和种类不断扩展。
以这种方式完成的可组合性也使开发人员体验更好。在 Ceramic 上构建应用程序就像浏览数据模型市场，将它们插入到您的应用程序中，然后自动访问存储在这些模型中的网络上的所有数据。不再需要每个开发人员都担心使用自己的孤立用户和数据引导他们的应用程序，从而使从想法到实现比以往任何时候都更容易。

开放接口

Ceramic的最后一个核心组件是其无需许可的开放API，用于存储，修改和检索来自网络的数据。通过标准化、泛化并向世界上每个开发人员开放这些 API，Ceramic 使开发人员能够在存储在网络上的共享资源之上进行构建，而不必担心集中化、审查风险或锁定。

技术概述

Ceramic是一种公共的，无需许可的开源协议，为存储在去中心化网络上的所有类型的数据结构提供计算，状态转换和共识。Ceramic的流处理使开发人员能够在动态信息之上构建安全，无信任，抗审查的应用程序，而无需受信任的数据库服务器。

本概述介绍了如何：

• 去中心化的内容计算催生了开源信息的新时代
• 流处理为动态、去中心化的内容提供了适当的框架
• 您可以使用Micromc将您的数据库替换为真正去中心化的替代方案

开源信息互联网

从本质上讲，Internet 是在有状态数据源上运行的应用程序的集合-从身份系统和用户表到用于存储用户、服务或计算机生成的各种内容的数据库和源。
当今互联网上的大多数信息都锁定在特定于应用程序的数据库服务器上，这些数据库服务器旨在保护作为专有资源的数据。作为受信任的中间人，应用程序通过要求显式权限、一次性 API 集成以及信任返回的状态是正确的，使其他人难以且不透明地访问此信息。这种孤立和竞争的环境给开发人员带来了更多的摩擦，给用户带来了更糟糕的体验。
在其他方面，网络已经迅速发展成为一个更加开源、可组合和协作的生态系统。我们可以在Git的分布式版本控制支持的开源软件和区块链的双花保护支持的开源金融中观察到这一趋势。开源的相同原则尚未应用于内容。
下一波变革性创新浪潮将是将相同的开源原则应用于世界信息，从而解锁一个可以跨应用程序或组织边界无摩擦共享的内容。要实现这一目标，需要一个专门为内容设计的去中心化计算网络，其灵活性、可扩展性和可组合性是一流的要求。

去中心化内容计算

应用程序的内容层的开源需要将信息部署到一个公共的、无需许可的环境中，在该环境中可以存储文件、执行计算、跟踪状态，并且其他人可以轻松访问内容。
其他Web3协议的进步已经在去中心化文件存储中取得了成功。作为去中心化网络的通用文件系统，IPFS（包括IPLD和Libp2p）提供了一个非常灵活的内容命名和路由系统。作为存储磁盘，持久的持久性网络（如Filecoin，Arweave和Sia）确保IPFS文件中表示的内容被持久化并保持可用。这种Web3协议堆栈在存储静态文件方面表现良好，但其本身缺乏计算和状态管理能力，无法实现更高级的类似数据库的功能，例如可变性，版本控制，访问控制和可编程逻辑。这些是使开发人员能够构建功能齐全的去中心化应用程序所必需的。
Ceramic使静态文件能够组合成更高阶的可变数据结构，编程为以任何所需的方式运行，其结果状态在去中心化的节点网络中存储和复制。Ceramic通过通用的去中心化内容计算基板，构建并扩展了IPFS文件系统和底层持久性网络，以及去中心化生态系统中的其他开放标准。由于Ceramic的免许可设计和统一的全球网络，世界上任何人都可以公开创建，发现，查询和构建现有数据，而无需信任集中式服务器，集成一次性API或担心返回信息的状态是否正确。

流

Ceramic的去中心化的内容计算网络是根据Web2中的各种流处理框架建模的。在这些类型的系统中，将引入事件，在事件到达时进行处理，并将生成的输出应用于日志。当查询和减少时，此日志表示一条信息的当前状态。这是一个适当的框架，用于概念化如何在去中心化的网络上建模动态信息。此外，由于处理任何特定流上的传入事件的函数可以使用任何用例的逻辑进行自定义编写，因此它提供了表示Web上可能存在的信息多样性所需的通用灵活性和可扩展性。
在 Ceramic 上，每条信息都表示为仅追加的提交日志，称为流。每个流都是存储在 IPLD 中的 DAG，具有称为 StreamID 的不可变名称和称为 StreamState 的可验证状态。流在概念上类似于Git树，每个流都可以被认为是自己的区块链，分类帐或事件日志。

流类型

每个流必须指定一个 StreamType，这是特定流使用的处理逻辑。StreamType 本质上是一个函数，在收到对流的新提交时由 Ceramic 节点执行，该提交控制流的状态转换和生成的输出。StreamType 负责强制实施流的所有规则和逻辑，例如数据结构、内容格式、身份验证或访问控制以及共识算法。如果更新不符合 StreamType 指定的逻辑，则忽略该更新。对流应用有效的提交后，生成的 StreamState 将广播到 Ceramic 网络上的其余节点。同时维护此流的其他每个节点都将更新其 StreamState 以反映此新事务。
Ceramic灵活的StreamTypes框架使开发人员能够将符合任何一组任意规则的任何类型的信息部署为有状态事件流。陶瓷客户端预先打包了一组标准的 StreamTypes，涵盖了广泛的常见用例，从而可以轻松开始构建应用程序：

• Tile文档：存储 JSON 文档的 StreamType，提供与 NoSQL 文档存储类似的功能。磁贴文档经常用作标识元数据（配置文件、社交图谱、信誉分数、链接的社交帐户）、用户生成的内容（博客文章、社交媒体等）、用于形成集合和用户表 （IDX） 的其他 StreamID 索引、DID 文档、可验证声明等的数据库替代品。磁贴文档依赖于 DID 进行身份验证，并且流的所有有效更新必须由控制流的 DID 签名。
• CAIP-10 Link：一种StreamType，用于存储将区块链地址链接到DID的加密可验证的证明。DID可以具有无限数量的CAIP-10链接，这些链接将其绑定到许多不同区块链网络上的许多不同地址。CAIP-10 链路还依赖于 DID 进行身份验证，与Tile文档相同。
• 自定义：您可以实现自己的 StreamType，如果预打包的 StreamType 不适合您的使用案例，则可以将其部署到 Ceramic 节点。

认证

StreamType 能够指定其身份验证要求，以便如何授权将新数据添加到特定流。不同的流类型可能会选择实现不同的身份验证要求。Ceramic StreamTypes支持的最强大和最重要的身份验证机制之一是DID，这是去中心化身份的W3C标准。默认流类型（Tile文档和 CAIP-10 链接）使用 DID。
DID 提供了一种从全局唯一、与平台无关的字符串标识符转变为包含用于签名验证和加密的公钥的 DID 文档的方法。陶瓷能够支持任何DID方法的实现。下面，找到陶瓷当前支持的 DID 方法：

• 3ID DID 方法：一种 DID 方法，它使用 Ceramic 的 Tile Document StreamType 来表示可变的 DID 文档。3ID 通常用于最终用户帐户。当3ID与身份索引协议和3ID钥匙串结合使用时（如3ID Connect中实现的那样），可以使用来自任何L1或L2网络的任意数量的区块链帐户轻松控制3ID。这提供了一种在所有其他平台上统一用户身份的方法。
• 密钥 DID 方法：从任何 Ed25519 密钥对静态生成的 DID 方法。密钥 DID 通常用于开发人员帐户。密钥 DID 是轻量级的，但缺点是其 DID 文档是不可变的，如果受到威胁，则无***换密钥。
• NFT DID方法（即将推出）：任何区块链上任何NFT的DID方法。DID文档是从链上数据静态生成的。与资产当前所有者的区块链账户关联的DID（使用CAIP-10 Link）是唯一被授权代表NFT DID行事的实体，在基于DID的系统中进行身份验证，并对NFT DID拥有的流或其他数据进行更新。当 NFT 的所有权发生变化时，控制器权限也会发生变化。
• Safe DID方法（即将推出）：一种用于任何区块链上的Gnosis安全智能合约的DID方法。通常用于组织、DAO 和其他多重 sig 实体。

Ceramic Network

Ceramic Network是一个分散的，全球性的节点网络，运行Ceramic协议，通过Libp2p对等网络协议的专用主题进行通信。Ceramic由于其独特的设计，能够实现最大的水平可扩展性，吞吐量和性能。

分片执行环境

与传统的区块链系统不同，传统的区块链系统将可扩展性限制在单个全局虚拟执行环境（VM）中，并且单个分类账的状态在所有节点之间共享，每个Micromc节点都充当单独的执行环境，用于在流上执行计算和验证交易 - 没有全局分类账。这种“内置”执行分片使陶瓷网络能够水平扩展，随着网络上节点数量的增加，并行处理越来越多的同时流事务。需要这样的设计来处理世界数据的规模，这比金融区块链所需的吞吐量大几个数量级。这种设计的另一个好处是，Ceramic节点可以在离线优先的环境中执行流事务，然后在重新上线时与网络的其余部分同步更新。

全局命名空间

由于所有节点都是同一Ceramic网络的一部分，因此Ceramic上的每个流都存在于单个全局命名空间中，在该命名空间中，任何其他节点都可以访问该名称库或将其引用为任何其他流。这将创建一个开源信息的公共数据网络。

其他节点职责

除了根据 StreamType 逻辑执行流事务外，Ceramic 节点还维护其他一些关键职责：
流状态存储：Ceramic 节点仅保留 StreamStates，以便它想要保留的流，此过程称为“固定”。不同的节点将维护不同流的 StreamStates，但多个节点可以维护单个流的状态。
提交日志存储：Ceramic 节点维护所有提交到它所固定的流的本地副本。
持久性连接器：Ceramic节点可以选择利用额外的持久存储后端来备份其正在固定的流的提交。这可以是上面提到的任何持久性网络，包括Filecoin，Arweave，Sia等（即将推出）。
查询响应：Ceramic节点响应来自客户端的流查询。如果节点已固定流，它将返回响应；如果没有，它将要求网络的其余部分通过libp2p提供流，然后返回响应。
广播交易：当 Ceramic 节点在流上成功执行事务时，它会通过 libp2p 将此事务广播到网络的其余部分，以便其他节点也固定此流，从而可以更新其 StreamState 以反映此新事务。

Ceramic 节点的组件

功能齐全的Ceramic节点由具有关联存储的陶瓷实例组成，并且需要Ceramic锚点服务 （CAS） 在网络上可用。
Ceramic节点的存储需求包括陶瓷状态存储和 IPFS 存储库。有关详细信息，请参阅保留 IPFS 数据。

数据可用性

本页介绍 Ceramic 上流的数据持久性和数据可用性模型。

概述

流数据可以分为两大类：提交和状态。虽然存在一些重叠，但这两种类型的数据具有足够的差异，因此在规划如何持久化和托管流时应单独考虑它们。在对给定流执行写入或查询时，给定流的所有提交和状态都必须可用；否则，您的客户端将返回错误。一旦所有数据重新联机，此错误将消失。如果由于持久性管理不当而导致给定流的一个或多个提交永久丢失，则此流将被损坏，并且错误不会消失。

流提交

每个流都是一个由一个或多个提交组成的事件日志，每个提交至少包含两个 IPLD 对象。这些提交共同存储构成流内容的数据。

缓存

Ceramic节点具有内置的缓存机制，用于短期存储提交。每当 Ceramic 节点对流执行写入或查询时，该流的所有提交都会首先从网络同步并自动加载到该节点的内存中缓存中。这导致最流行的流被复制得最多，从而提供一定程度的数据持久性和可用性。但是，为了保留磁盘空间和节点资源，内存中缓存默认限制为 500 个流（但可以配置为任意数量）。达到该数字后，最旧的流将从节点的缓存中逐出，以便为较新的流腾出空间。
如果节点碰巧关闭或重新启动，则将清除缓存。由于在关闭之前由于普及性或其他数据持久性措施而无法跨其他节点进行足够的复制，则仅存在于内存中的流将永远丢失。因此，仅缓存在比特定会话更长的时间内不是可靠的数据可用性来源。

注册

固定为提交提供了一种更持久的数据持久性机制。固定是指示 Ceramic 节点显式注册（即“固定”）特定流的提交的过程。由于提交存储在 IPLD 中，因此 Ceramic 节点已经包含一个捆绑的 IPFS 节点，该节点是发生此固定的位置。IPFS节点可以固定任何流的所有提交，这些流可以通过它所连接的Ceramic网络访问。Ceramic 引脚也可以使用外部IPFS节点而不是捆绑的内部版本工作。
如果开发人员希望以最简单的方式使其流在单个会话之外持久存在，并且对数据丢失更具弹性，那么固定是正确的选择。Ceramic节点可以固定无限数量的流。但是，请注意，如果只有一个IPFS节点正在固定给定的流，并且它永远消失或损坏，则该流将丢失。此外，如果只有一个节点正在固定流（并且没有其他 Ceramic 节点在缓存中具有该流），并且该节点脱机，则该流将对其他节点不可用。因此，为了提高弹性和数据可用性，最好让多个IPFS节点在不同的环境中运行，固定相同的流。
有关如何在Ceramic节点上固定流的说明，请参阅固定指南。

归档

存档是提交最持久、最持久的持久性形式。除了缓存和固定之外，Ceramic 开发人员还可以将其节点配置为连接到外部服务，以存档构成流的所有提交。存档提供的确切保证因实施和服务提供程序而异。例如，存档到Filecoin通过即用即付模式提供加密经济保证的数据可用性，而存档到Arweave则通过一次性支付模式提供加密经济保证的数据可用性。相反，存档到 Amazon S3 提供了一种更简单的模型，但 Amazon 无法保证您的数据始终可用 （例如，您可以停止支付账单），但存储仍然比仅使用固定和缓存更具弹性。

流状态

除了上面提到的存储在IPFS中的提交日志之外，每个流都有一个状态，该状态不存储在IPFS中，而是由所有缓存和/或固定流的 Ceramic 节点共同跟踪，持久化和提供。需要完整的提交历史记录和状态才能成功加载流并与之交互。

缓存

状态缓存的工作方式与提交缓存相同。

注册

状态固定的工作方式与提交固定相同，只是 IPFS 上不会发生状态固定。状态固定仅发生在 Ceramic 节点内部的数据库中。

归档

Ceramic正在开发一种持久的，去中心化的状态存储，它将用于持久化并保证流状态的可用性。这在路线图上。它对立即使用Ceramic并不重要，但将有助于使state更具弹性和可用性。同时，Ceramic 支持将状态存档到 Amazon S3，因为此选项比默认使用的本地数据库具有更高的持久性和可靠性。

Ceramic网络中的每个流都是独立的，所有流的生命周期都可以以相同的方式进行广泛的描述。流可能执行三个主要操作：创建、更新和查找。

创建流
创建流时，将创建包含流初始内容的 IPLD 对象。这称为创世提交，其 CID 用于（以及流类型）来生成流标识符 （StreamID）。根据流类型，对于什么是创世提交的有效内容，可能存在限制。

更新流
为了更新流，需要添加两个提交。这些更新将添加到提交日志中，该日志是提交的链接列表。首先创建包含内容更新的签名提交并将其添加到日志中。创建签名提交后，此提交的CID将发送到锚定服务，该服务将一组流更新批处理到Merkle树中，并将根哈希提交到区块链以进行最终确定。然后，锚定服务返回给定 CID 的锚点提交，该提交将添加到提交日志中。现已对流进行全面更新。将每个新提交添加到流的提交日志后，节点都会发布一条更新消息，其中包含 StreamID 和陶瓷 pubsub 主题的新提交的 CID。

查找流
若要查找流，需要 StreamID。一旦知道 StreamID，节点就可以通过向Ceramic pubsub 主题发送查找请求来查找流。具有此流状态的其他节点将使用它们知道的最新提交 CID 进行响应。进行查找的节点现在解析它接收的所有CID的提交日志（在大多数情况下，这只会是一个CID）。如果有任何冲突，冲突解决机制将解决它们。解决任何冲突后，来自签名提交的所有更新都将应用于创世提交，并找到流的最新状态。

共识

本页介绍 Ceramic 上流的共识和冲突解决模型。

概述

Ceramic保持对单个数据流的共识。这与传统的区块链系统形成鲜明对比，传统的区块链系统在整个全球分类账上保持共识，或者与分布式数据库系统形成鲜明对比，后者为整个数据库保持共识。在单个数据对象的级别上保持共识使Microc更具可扩展性，因为节点只需要跟踪它们所关注的流的信息，而不是网络上的所有流的信息。这也允许不同的Streams使用不同的共识模型 - 允许一个灵活且可扩展的共识系统，该系统可以随着时间的推移而发展，并根据特定的用例进行定制。在Ceramic***识由单个StreamTypes处理，这意味着将来引入的新StreamType也可能引入新的共识机制。

现有共识模型

如今，大多数现有的 StreamType 都使用使用 json 补丁编码的差异来表示状态转换，并使用最早的锚点 Wins 规则来解决冲突。

Json-patch diffs

在现有的 TileDocument StreamType 中，使用 json 补丁对文档内容的更新进行编码。生成的 diff 将进入陶瓷提交，并可用于将流的内容从以前的状态转换为新状态。同步 TileDocument 涉及从创世提交中获取初始状态，然后将每个后续提交的 json 补丁差异应用于内容，一次一个，直到流的提交日志结束，此时您拥有内容的当前状态。

写入冲突

有时，同一流的两个冲突日志可能同时存在。当流的控制器在不同设备上或通过不同的应用程序对同一流进行冲突的更新时，可能会发生这种情况。如果单个 Stream 具有多个能够创作流更新的最终用户（因为流具有多个控制器 DID，或者因为用作流控制器的 DID 方法允许多个用户/私钥代表其对消息进行签名，例如 did：safe DID 方法， 例如）。
无论单个流的去中心化日志的原因是什么，重要的是所有节点都可以就哪个是该流的正确日志达成一致（共识）。大多数 StreamType 目前依赖于“最早的锚点获胜”策略来解决流日志之间的冲突。

最早的锚点获胜

Ceramic 流的更新定期锚定在区块链（目前是以太坊）上。此不可变的发布证明用于获取更新发生时的无信任时间戳。这使我们能够安全地比较与 Stream 日志的不同分支关联的时间戳，以确定哪个更新首先发生。如果 Stream 日志存在冲突的历史记录，并且一个分支的锚定时间早于另一个分支，则较早锚定的分支将获胜。如果一个分支已锚定而另一个分支未锚定，则首选已锚定分支。

最长的更新链

最早的锚点获胜规则可以解决与就流的状态达成共识相关的许多问题，但如果快速创建多个更新，则仍然存在问题。由于锚点仅定期发生（取决于所使用的锚点服务，但目前3Box Labs为Microic主网运行的锚点服务每天两次），因此在任何更新被锚定之前，可以创建和发布多个更新。在这种情况下，我们仍然需要就当前状态达成共识。当流存在冲突的日志时，如果这些日志都未锚定，我们更喜欢较长的日志。这可确保保留更新最多的最活跃的历史记录。如果存在具有相同长度的冲突未锚定分支，则系统会以可逆方式（但确定性地）选择获胜的日志，以确保所有节点在同一日志上达成一致，即使没有好的信息可用于决定首选哪个。这可能会导致写入丢失在某些极少数情况下，其中在几秒钟内发布了冲突的更新。

同时更新

今天的陶瓷流使用读-修改-写方法进行更新。这意味着在某些特定情况下，写入冲突可能导致写入丢失。考虑一个应用，它想要将新条目添加到 TileDocument 流中包含的数组中。应用加载流，获取流的当前内容（包括要更新的数组的当前值），在本地向数组中添加元素，然后使用新内容向 Ceramic 发出更新。此代码可能如下所示：

const streamId = '<...>' // A StreamID for an existing Ceramic Stream
const doc = await TileDocument.load(ceramic, streamId)
// doc's content contains a 'friends' array field with the value ['mohsin', 'liz']
const content = doc.content
content.friends.push('sergey')
await doc.update(content)

如果在此代码运行时，对同一流进行了另一次更新（使用看起来大致相同的代码，但说添加“stephanie”而不是“sergey”），则当通过调用将新状态发布到网络时，此代码可能不知道该更新。你可能会最终将两个相互冲突的更新发布到网络上，一个将“sergey”添加到列表中，另一个将“stephanie”添加到列表中。在这种情况下，网络最终会就保留哪个更新达成共识，但选择哪一个是任意的，被拒绝的更新将永远丢失。这意味着最终的阵列有可能是 ，而最终的阵列也有可能是 ，没有办法提前知道哪个更新会胜出。doc.update['mohsin', 'liz', 'sergey']['mohsin', 'liz', 'stephanie']
对于 Ceramic 来说，这种行为通常不是问题，因为大多数 Ceramic 流都由单个最终用户控制，该用户不会同时对给定流进行多个同步更新。然而，这确实意味着，Ceramic目前并不适合依赖于允许多个最终用户同时更新单个流的应用程序。请注意，只要更新间隔超过大约 30 秒，就应该有足够的时间在整个 Ceramic 网络***享更新，并防止发生此类冲突。此外，未来的StreamTypes可能不会受到此问题的影响，因为未来的StreamTypes将能够使用更适合处理同时更新的不同共识机制。

未来改进

将来，Ceramic计划提供使用CRDT对Streams进行编码的StreamTypes，这将允许同时更新自动合并而不会发生冲突。然而，这些计划目前仍处于研究阶段。

安全

本页介绍 Ceramic 协议和各种系统（如 3ID Connect）的各种安全方面。

Ceramic协议

构成Microic的主要安全属性是加密签名，发布证明（通过区块链锚点）和哈希链接的数据结构。这些属性一起允许构造可验证的数据结构。除此之外，Ceramic还依靠libp2p pubsub来广播流更新。

流数据结构

通常，流由提交组成，这些提交使用哈希链接作为 DAG 链接在一起。此数据结构使用 IPLD 表示。提交总是包含某种证明，通常是签名或发布证明。当 Ceramic 节点同步流时，可以在本地验证此链接的提交 DAG，从而完全信任。
已签名的提交通常由流的控制器签名。不同的 StreamType 可能有不同的规则，关于如何对签名进行编码。TileDocument StreamType 使用 dag-jose 对签名进行编码。建议任何新的 StreamTypes 使用此格式。
发布证明是某些内容在某个时间点发布的证明。这是通过在区块链上发布内容的哈希来实现的。通过将多个内容哈希作为叶子放在merkle树中并仅发布根，可以使这些证明更具成本效益。发布证明提供流中事件的明确顺序，当您希望以安全的方式执行密钥吊销时，这非常有用。
链接的提交 DAG 提供事件的逻辑排序，这在构造使用 CRDT 类型逻辑的流时非常有用。有关这些好处的详细说明，请参阅Merkle-CRDTs论文。

冲突解决策略

Ceramic中的不同流类型可能具有不同的冲突解决策略，具有不同的安全属性。
最早的锚点规则通过选取在最早时间点锚定的流来解决流历史记录中的任何冲突。这样可以安全地吊销密钥，因为在吊销旧密钥后获得旧密钥所有权的人将无法生成早于第一个锚点的发布证明。这用于3ID DID方法，该方法注册一组与DID URL关联的公钥，当3ID流使用新的公钥更新时，撤销旧密钥，外部观察者可以确定3ID的状态，而无需任何辅助信息源。3ID建立在TileDocument流类型之上，也可以在其上构建替代的DID方法。
“最早锚点规则”的缺点是流的控制器可以秘密创建锚定提交，并在以后的时间点显示它们以更改流的历史记录。有多种方法可以缓解这种情况。其中之一是只允许在创建时主动发布所有已创建锚点提交的锚点服务。
最新的 nonce 规则通过简单地选择包含最大 nonce 的已签名提交来解决任何冲突。此策略不支持密钥吊销，因此无法更改具有此策略的流的控制器。Ceramic还不支持这种策略，但对于像DIDPublish这样的StreamTypes来说，它是必需的。将来，出于效率原因，Caip10Link StreamType 也可能更新为使用此策略。

网络广播

Ceramic节点使用libp2p pubsub来广播流提示。在广播中发生的两个操作是发布流更新和加载特定流的节点的提示查询。Ceramic节点的主要安全考虑因素是，它所关心的流的任何新提示都可能是该流的虚假或无效提示，因此需要验证。

DoS 攻击

恶意节点可以通过发送大量消息来向 pubsub 主题发送垃圾邮件。这可能是随机生成的消息，甚至不适用于有效流，也可能是被流更新规则拒绝的有效流的无效提示（下面解释的“虚假日志攻击”）。对此的主要反击是通过具有与垃圾邮件节点断开连接的自动信誉系统来限制单个节点可以发送的消息量。如今，Ceramic中不存在这样的声誉系统，尽管它计划作为未来的改进。

虚假日志攻击

恶意节点可以通过发送错误的提交日志来向固定特定流的节点发送垃圾邮件。毫无戒心的节点将同步流的日志并发现其无效，此时节点将丢弃错误的日志，而不会将其应用于流状态的本地副本。但是，如果假日志很长，并且恶意节点发送了其中的多个，则可能会导致大量开销。最简单的对策是简单地停止接受来自已被证明不可靠的节点的提示。一种更重要的方法是构建一个 StreamType，其中包含一个递归零知识证明，证明日志确实与给定的 streamid 正确关联。

Caip10 Link时钟同步

目前，Caip10Link 流类型依赖于客户端计算机上的系统时间来缓解重放攻击。仅当证明包含的时间戳大于上一次更新的时间戳时，Caip10Link 流的新更新才有效。但是，如果用户由于某种原因导致的系统时间错误地进入遥远的未来，则会出现一个问题。此时，用户将无法使用此计算机上创建的证据来阻止重放攻击。重放攻击可用于重置Caip10Link以指向它以前链接到的任何DID。可能的解决方法是切换到使用始终递增 1 的 a，或者在证明中包含指向上一个提交的指针。

隐私

本页介绍Ceramic协议的各种隐私方面。到目前为止，我们已经采取了措施，计划了未来的措施，以及未来的研究方向。

Ceramic 协议

StreamType系统在流如何为开发人员提供隐私功能方面已经非常灵活。

Tile和 Caip10 Link的默认属性

目前，如果您创建 TileDocument 或 Caip10Link 流，则默认情况下，放入其中的任何数据都将是公开的。但是，可以通过从 Ceramic （ceramic.did） 访问 DID 实例并使用其加密功能来加密放入流中的内容，如如何在 IPFS 上存储签名和加密数据博客文章中所述。

机密流

对 TileDocument StreamType 的一项计划改进是增加机密性。这基本上意味着每次更新流的内容都将通过对称密钥进行加密。每当 Ceramic 节点同步流时，它只有在具有此流的对称密钥时才能读取流内容。流元数据（如哪个 DID 对更新进行了签名、以什么顺序以及何时锚定更新）仍将是公开的。
像 DIDPublish 这样没有历史记录的 StreamType 可以进一步改善这种情况，因为同步流的节点不会看到历史更新元数据。

私有流

完全私有的流意味着所有数据和元数据都已加密。
一种方法是纺织线程DB采用的方法，它将跟随键和内容键的概念分开。这允许某些节点读取元数据并固定流，但看不到内容，而其他节点根本看不到流中的任何内容。因此，从本质上讲，流仍然只对具有跟踪密钥的受信任对等体集保密。
更好的方法可能是使用某种零知识证明系统来匿名跟踪一组流的尖端。这仍然是一个完全开放的研究课题，但可能会给阅读流的队伍增加一些开销。这里的一个好处是，与纺织线DB不同，该系统可以完全不受信任地运行。

（这部分内容为本人原创，属于瞎扯淡~）

当今的互联网大厂，根据其在不同业务场景的优势，把原本属于用户的数据分割存储到他们各自的服务器中，且对外（竞争对手）不提供数据访问的API接口，对内则侵犯数据隐私，利用用户数据的特点进行大数据杀熟的不道德的商业行为。

一方面，这会造成用户体验极其的不友好，给用户造成了碎片化的体验，比如我在某Q上有1000个好友，我有某度网盘上有100张我拍的北京故宫精美图，我想给我的多个好友共享我的图片，却要现在某度先进行下载，然后再批量发给我的Q好友，这样的体验十分不方便。归根到底而言，用户的好友属于用户的数据，用户的图片也属于用户的数据，Web3代表了人们打破平台垄断的渴望和愿景，去中心化存储就是Web3.0的一种极其重要的基础设施。

另一方面，对于开发者而言，即使是十分简单的应用，但由于其要使用到用户的多个平台的数据，因此其开发过程也变得极其繁琐。

所以说，这种平台化的互联网公司就是原罪~

IPFS是当下最为知名的去中心化存储协议，其可以确保去中心化网络中通用文件系统的内容持久化并维持可用性，但是IPFS中存储的数据更多是静态文件的格式，比如一段视频、一组图片，其在一般情况下不会再发生变更。但是有一些数据不是，比如word文档，今天是这个版本，过几天添加一段文字就是另一个版本了。这只是数据变更的一个微小的特点。主打静态文件的IPFS无法实现更加高阶的数据库的作用，而Ceramic则是一种将静态文件组合成更高阶的可变数据结构，其底层实现原理是一个通用的计算基板进行存储和复制，使得即使是在去中心化的网络节点中也可以很好的一致地保存文件的结果状态。

Ceramic底层也是构建于IPFS之上，但其扩展了IPFS的功能。

Ceramic的扩展方案很简单，每条信息都表示为仅附加的提交日志，在Ceramic的文档中，这种附加的提交日志被称为Stream（流）。具体的流机制，上面已经提到了。

Ceramic目前和未来主打的应用场景是去中心化身份（Decentralized Identifiers，DID），因为DID是一种经常变更的数据模型，所以其需要采用Ceramic这样的适合内容动态更新的web3.0存储方案。