Matter 中的分布式合规设备总帐 (DCL)(转自乐鑫博客)

Matter 的优势之一在于 Matter 设备制造商（供应商）无需自己开发手机 APP 或云服务，其 Matter 设备就可以加入任何支持 Matter 的生态系统，与生态中的其他 Matter 设备无缝互联。

这是如何实现的呢？Matter 设备制造商是如何安全地发布设备信息，并允许 Matter 生态系统访问它们呢？这篇文章，我们将讨论 Matter 中的分布式合规设备总帐 (Distributed Compliance Ledger, DCL)。

分布式合规设备总帐 (DCL) 是什么？

Matter DCL 是一种基于区块链技术的，安全加密的分布式存储网络，允许连接标准联盟 (CSA) 和授权供应商发布其 Matter 设备信息，并允许 Matter 生态通过 DCL 客户端查询相关信息。

Matter 设备信息被存储在 5 个数据库中：

供应商数据库 (Vendor Schema)：包括供应商的基本信息，例如公司法定名称、与 VendorID 关联的品牌名称、供应商的主页 URL 等。
设备信息数据库 (DeviceModel Schema)：包括设备的基本信息，例如产品名称、产品 ID、零件编号、commissoning 信息等在各软件版本中均通用的信息。
设备软件版本数据库 (DeviceSoftwareVersionModel Schema)：包括软件版本的详细信息，例如发布说明 URL、固件摘要 (FirmwareDigests)、OTA 软件镜像 URL 等。

注意：DCL 中仅存储 URL，而非镜像本身。因此，供应商需将 OTA 软件镜像存储在其他位置，并仅将镜像的下载 URL 发布到 DCL 中。

上述所有信息均将存储在 DCL 中。此后，Matter 生态系统可以通过访问 DCL 完成以下操作：

DCL 是一个由多个独立服务器组成的网络，由 CSA 联盟及其成员拥有和托管。每台服务器都持有一份包含 Matter 设备信息的数据库副本，服务器之间通过加密的安全协议相互通信。

每个供应商都需要安装自己的 DCL 服务器吗？答案是否定的。

CSA 联盟提供公共的 DCL 服务器，支持供应商使用 DCL 客户端访问 DCL 信息。CSA 还可为成员配置“写权限”，允许其将自己的 Matter 设备信息发布到 DCL 中。

供应商也可以安装自己的专用 DCL 服务器。这种专用 DCL 服务器通常仅供供应商自己的客户端使用，但也可选择允许其他供应商访问。

供应商可以（通过 CSA 的 DCL 服务器或其自有的专用 DCL 服务器）在自己的 VendorID 下添加新的设备型号。供应商需要在创建帐户的过程中将 VendorID 与公钥相关联，才能拥有对 DCL 的“写权限”。
供应商可以更新现有设备型号的部分信息（如产品名称、产品描述、固件和硬件信息等），且仅可更新与自己供应商帐户相关联设备的相关信息。
CSA 认证中心可以向 DCL 中写入或撤销设备的认证状态。

所有人均可从 DCL 中读取：

接下来，让我们通过一个简单的示例，了解一下 DCL 的典型工作流程。首先，我们假设有如下角色：

典型的工作流程如下所示：

供应商 A 是 CSA 成员，已注册公钥并获得 DCL 的”写权限”。供应商 A 开发并生产了一个 Matter 灯泡 B，同时使用 CSA 的 DCL 服务器，将灯泡 B 的信息添加到了 DCL 中。
供应商 A 将一批灯泡 B 寄送给测试机构 T，由 T 对 B 进行 Matter 认证测试，再将测试结果发送至 CSA。CSA 检查收到的测试结果，如果测试通过，则在 DCL 中添加灯泡 B 的设备认证信息。
消费者 C 从市场上购买了一个灯泡 B，使用支持 Matter 的生态系统 G 的手机 APP 对灯泡 B 进行 commissioning，使灯泡 B 加入生态系统 G，并与 G 中的其他设备协同工作。生态系统 G 需要向 DCL 获取灯泡 B 的相关信息来完成 commissioning 流程。
在此之后，供应商 A 为灯泡 B 开发了一个新功能。此时，供应商 A 在 DCL 中发布一个包含新功能的软件版本。生态系统 G 中的某设备提供 Matter OTA 升级功能，可协助灯泡 B 完成 OTA 过程。
之后，消费者 C 又对支持 Matter 的另一个生态系统 H 所提供的一些服务感兴趣，于是以类似的方法将灯泡 B 加入了生态系统 H。此时，灯泡 B 可以同时在生态系统 G 和 H 中无缝得协同工作。

这样一来，消费者 C 可以无缝享受这两个生态系统提供的所有服务。