关于DeSoc的技术评述：第一部分

kevinyu
发布于 2022-06-08 13:40
阅读 24

本文评论了DeSoc生态系统中的非可转让代币（SBT）及其技术实现挑战，重点探讨将凭证存储在链上与链外的权衡，讨论了可扩展性、互操作性、隐私和Sybil抵抗等问题，并提出了两种解决方案来应对这些挑战。文章结构清晰，包含深入的技术分析和实际应用建议，是一篇较为优秀的技术评论。

## **简介**

微软的 [Glen Weyl](https://twitter.com/glenweyl)、Flashbots 的 [Puja Ohlhaver](https://twitter.com/pujaohlhaver) 和 [Vitalik Buterin](https://twitter.com/VitalikButerin) 最新发表的关于 **去中心化社会**（或 **DeSoc**）的文章 [1](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-1 在加密社区引起了轰动。有些人甚至将其与下一个“DeFi/NFT夏季”的潜在启动Hook。整篇文章围绕“ **公开可见、不可转让但可能可撤销的"代币**”这一理念，构建了一些元叙事，即所谓的 [Soul-bound tokens](https://twitter.com/VitalikButerin) (SBT)。

作者详细描述了不可转让代币（及其链外对应物，可验证凭证）能为目前**超金融化**的加密空间所带来的激动人心的未来。这些 SBT 可以作为 **声誉的信号** 和 **工具**，用于更广泛的 **去中心化网络协调**。由于这个话题也是我在过去几个月与 [Clique](https://twitter.com/clique2046) 团队探索的内容之一，因此我在此撰写一篇评论，探讨 DeSoc 生态系统的优缺点、潜在设计规范以及技术实施的挑战。

这篇评论分为两部分。第一部分主要探讨将凭证系统 **上链** 与 **下链** 之间的 **权衡**，以及设计身份系统的 **遗产兼容性** 方面。第二部分将更关注多元性、二次投票/资助以及声誉系统的通用机制设计。

## **DeSoc 文章摘要**

一个幽灵在加密空间中徘徊——过度金融化的幽灵。**DeSoc** 旨在用“ **灵魂**”和“ **SBT**”来解决这个问题，这是一对用于信号声誉、代表会员资格和授予访问权限的 **账户**（钱包）和公开可见但不可转让的 **凭证**（代币）。请记住，“账户”和“凭证”的定义可以是高度 **抽象**的，而不一定限制于位于 **公共区块链** 上。这样一个系统的一些重要设计规范包括 SBT 的 **发行**、用于 **声誉** 的 SBT 抵押、不同 SBT 的 **可编程隐私** 和基于社区的 **密钥恢复** 方案。

“灵魂”和“SBT”与 **去中心化身份** 领域中的“ **去中心化标识符**” 和 “ **可验证凭证**” 类似。作者在第 8.4 节中对此进行了详细阐述，并指出 DID 的 “ **单边隐私**” 是一个主要缺陷以及限制应用范围的因素。 **缺乏社会/社区恢复机制**，这对普通用户安全至关重要，以及 **缺乏大群体用户之间的可编程性和可组合性**，是当前 DID 设计空间的一些其他问题，而 **SBT** 正在努力解决这些问题。

虽然我坚信许多应用依赖于 **网络效应** 并取决于某种程度的预先建立的 **公开性** （声誉抵押等），但把 **Layer1 区块链**（例如以太坊）直接作为主要 **执行层** 来 _存储、更新_ 和 _检索_ **凭证状态** （在这种情况下是 SBT 状态）有多个缺点。这已在原始作者和早期采用可验证凭证的用户之间产生了 [一些争论](https://twitter.com/AnastasiaU/status/1532584511107698689)。因此，我将尝试在此提供一个中立的分析，考虑 **可扩展性**、**互操作性**、**隐私** 和 **可组合性** 方面的 SBT。还提出了两种潜在的实现方案（均为混合方法）供进一步讨论。

## **我们应该将凭证放在链上吗？**

### **完全上链 SBT 的好处**

如果 SBT 并不具备可转让性，为什么要把它放在链上？**不可转让性** 意味着 **无许可区块链共识机制** 并不是绝对必要的，因为涉及的唯一交易将是凭证的 **发行**、**状态更新** 和 **验证**。前两个步骤需要由 **受信第三方（例如一组委员会节点）** 触发，该节点为 **状态改变** 的事实来源 [2](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-2。所有的写操作都委托给 TTP，然后可以通过任意 **点对点** 协议广播状态更新，并被其他节点验证（例如用于 **去中心化存储**，以维护所有客户端的状态 **可用性**）。凭证的验证可以在任何地方发生（通过智能合约的链上或通过某些 SDK 的链外）。

然而，确实有多种拥有本地上链不可转让凭证的好处。首先，**与现有链上协议的集成**将更容易。例如，根据 DeFi 农业记录发行链上 SBT 可以在链上原生发生，无需任何预言机。类似的案例适用于 DAOs 的 **基于声誉的链上治理**。

除了 **可组合性**，如果所有的发行逻辑都硬编码到 **智能合约** 中，自动赋予已经拥有良好声誉的账户（例如，持有大量高质量 SBT）授权，可以强制执行 **完全去中心化**。这将消除运行 **单独网络** 的需要 **有许可的发行者节点**，因为 **发行者实体** 可以直接设置由特定条件触发的智能合约。简单地说，可以将 SBT 的 `claim` 函数设为公开，任何人只要满足某些标准（例如，拥有某些其他 SBT），就可以调用。

与 VC 相比，SBT 另一个优势是它们作为账户的 **标志** 的能力。如果想要在链上验证一个声明是否真实并尝试使用 VC，就需要持有者 **可用** 并 **愿意合作**，这对 **单边隐私** 是一个巨大的限制。此外，仅能在时间点`t` **当它呈现时** 查询声明状态。**IDX** [3](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-3 是一个优秀的选择，作为一个中心化存储库，查询凭证及其状态，前提是链上验证不是绝对必要的。

现在，让我们来谈谈将所有内容上链的一些潜在细微差别。

### **可扩展性**

**凭证的设计空间** 将由于频繁状态更新的 **开销** 受到限制，这会产生 **高额的Gas费用**。例如，想要有一个凭证来详细说明在不同社交媒体平台上有多少追随者（可以是一些阈值值的集合）。在这种情况下，每当该数字变化时，就需要发起一个链上交易以更新状态。如果试图存储一个 **社交图**，这变得更不可扩展。在大多数情况下，用户甚至没有 **财务激励** 来支付Gas费用。

另一方面，如果代币作为某些链外凭证的 **指针**（比如 NFT）被存储，我们就需要重新引入一个有权限的节点委员会来管理这些链外凭证。这与普通的 NFT 是不同的（Jpegs 并不应该改变），因为 **智能合约** 需要以可验证的方式写入 **链外** 存储。作为参考，这是一个预言机问题，Chainlink 正在通过他们的 [动态 NFT](https://blog.chain.link/what-is-a-dynamic-nft/) 来实施。

### **互操作性**

将凭证完全上链使得 **声誉系统** **链特定**。这引入了 **互操作性** 的额外问题。与普通的可转让和金融资产不同，它们可以穿越不同链的 **桥接**，类似于 SBT 的凭证是不可转让的，并且它也必须是 **抗 Sybil** 的，即同一凭证需要在多个链中去重（特别是涉及链外数据时）。那么，哪个链将成为 **单一事实来源**呢？跨链互操作性如何工作？谁来维护 **不同执行层** 之间的状态变化？

**发行者自身** 可能需要维护在不同链上同步的 SBT 的独立实例。这将赋予它一次性 **撤销** 所有凭证的权利。如果发行者自身位于一个链上，并且能够 **操控凭证状态** 于 **另一个链**，这会相当麻烦。oracle 问题将普遍存在于所有互操作的操作中，类似于如果必须在链上验证链外 VC 声明。

未来，随着链变得更加 **应用特定**，这个问题可以获得更多缓解——在这种情况下，对互操作性的压力将大大降低，因为 GameFi 凭证通常不会离开特定于游戏的链（类似于 web2 游戏平台的内部声誉系统，例如 Steam 徽章）。不过，用户可能需要证明在不同链上拥有多个账户以交叉引用凭证。**去重** 和 **链接** 不同身份再次成为一个问题。

### **隐私**

作者已经讨论了 **可验证凭证** 的 **单边隐私** 特性。争论的焦点在于把一切放在链上 **自动** 强制执行 **公开性** （除非使用某些隐私保护链，在这些链上状态由受信硬件/TEE 或特定的零知识 sigma 协议管理）。然而，使用链外网络维护凭证可以更加灵活：用户可以选择 **本地** （私有）存储凭证或在 **备份网络** 中存储凭证，是否加密（私有/公共）。这将消除单边隐私，同时确保公共和私有凭证具有相同的接口。

链上 **zk-attestations** 的问题是，状态很难更新。目前的应用似乎只专注于证明一次性声明。将 zk-attestation（例如，属于某个身份组）映射到链上 SBT 似乎是理想的，因为用户在完成证明后并不会脱离该身份组。

最终，不同的应用场景将需要不同的隐私和信任假设。对于 **基于智能合约** 的设置来说，**可编程隐私** 可能更容易实现。诸如 FLAX (Wei) [4](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-4 的研究正在探索这个方向。与可验证凭证一起以去中心化的方式运行计算（例如某些 **MPC 算法**），似乎比与 **隐私保护链** 管理的状态运行同样的计算要困难得多。

### **抗 Sybil**

与小型本地运行网络相比，**抗 Sybil** 显得更容易。“ **公民证明**” 协议 [5](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-5 使用诸如 _可链接环签名_ [6](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-6 的密码学工具来实现这个目标，尽管这是一种不可扩展的方式。作者提到了在用户的公共链上 SBT 与其他已知声誉用户之间进行 **关联检查**。当很少有人具有足够声誉时，这就很容易为网络带来 **启动** 问题。随着时间的推移，这也可能进一步 **中心化** 网络，围绕某些个体而发展。

### **实现不可转让代币**

假设在链上以不可转让代币的形式放置凭证是最佳选择。那么，问题就变成了：如何实现它？社区之前探索了各种解决方案，大多数建议对 `transfer` 和 `transferFrom` 方法进行某种Modification。**[EIP-1238](https://github.com/ethereum/EIPs/issues/1238)** 下的一个抽象接口如下：

![](https://img.learnblockchain.cn/2025/03/12/6390602f-e927-4d22-b117-850a09fbb7d9_1380x1042.png)

社区已详细描述此设计下的一些问题：

- 一旦账户（钱包）被破坏，**谁来管理凭证的转移**？更重要的是，如何管理？根据这种实现，似乎非常困难。DeSoc 提出的 **社区基础密钥恢复机制**，通过扩展 **受信方** 的集合到账户所在的所有“社区”，来改进常规社会恢复方案。在实施中，监护人的集合将不断变化，而每个监护人可以访问的钱包也将会变化。这显著增加了 **恢复图的复杂性**。对于监护人集中的恶意行为者（如果不受信）的串通没有简单的解决方案。

- 在监护人之间可以应用流动性和相关性折扣等机制作为基本检查。像 MACI[7](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-7这样的受信串通抗性机制更为稳健，但信任设置中断可能会很困难。

- 也许像 **[EIP 121](https://github.com/ethereum/EIPs/issues/121)** 这样的标准中，提出了一种用于资产管理和转移的统一 **代理** 合同设计。然而，这也引入了关于转移的粒度的新问题（例如，单个资产还是与某个钥匙相关的所有资产？）

最终，可能没有简单的方法来迫使 **发行者** 重新发行徽章或发起有权限的转移。这是一个经历了大量社区争论的话题。如果你对此话题感兴趣，请查看以下 GitHub 问题：[ERC-1888: 可转让证书](https://github.com/ethereum/EIPs/issues/1888)，[调查 Open Badges 对我们需求的适用性](https://github.com/topiahq/badges/issues/1)，[CDIP 2 - Maker 生态系统活动的不可转让徽章](https://github.com/makerdao/community/issues/433)。

## **替代解决方案**

为了解决上述问题，我将详细说明两种解决方案。在任何情况下，**私密凭证** 应该由用户 **本地** 存储（并可能由具有加密数据的网络备份），两者之间的区别主要在于 **公共凭证** 的发行、更新和验证。

### **第一个解决方案：链外 DID 与链上锚定（基于 VC)**

第一个解决方案与Layer2设计相似，因为它以批量方式 **锚定** 存储在 **链外** 的凭证的 **PKI 状态变化**（公共密钥基础设施，基本上促进数字证书的 CRUD）到基础去中心化网络（可以是任何公共账本），在这里作为 **结算层**。 **公共凭证** 本身可以存储在任何 **去中心化存储系统** 中（根据不同的信任假设，可以是 IPFS、Arweave，甚至只是由凭证发行委员会运行的一组存储节点）。

去中心化标识符网络可以通过类似 **Sidetree 协议** [8](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-8 来实现，该协议可以在任何现有的去中心化锚定系统（比特币，以太坊等）上运行，用于无许可凭证管理，使得系统链无关。Sidetree 下的 **委员会节点** 负责写入、观察和处理所有 DID PKI 状态操作，遵循确定性协议规则。

一组核心的 **状态变化操作**（例如 CRUD（创建、更新、恢复和停用））预先进行定义。由 **委员会节点** 将 **CAS**（基于内容的存储）引用锚定到基础锚定系统中、聚合操作的操作集，这在底层作用作为 **线性时间顺序的预言机**。DID PKI 操作因此存储有不可改变的历史，可以回放和验证，从而实现 DIDs 的一致视图。

在这样的设置下，Soul/SBT 可以重新表述为一组具有以下规范的 **可验证凭证**，根据 W3C VC 标准 [9](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-9[10](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-10。可以安排定制隐私，而链间互操作性可以通过与 DID 系统互动的链无关的预言机来解决。

- `pk^U`，或用户标识符：凭证主体的伪匿名标识符

- `ctx`，或上下文：表示发行上下文的字符串

- `{claim_i}`，或声明：每个 `claim_i={a_i,v_i,P_i}`，其中 `a_i` 表示属性，`v_i` 表示值（作为与 `a_i` 的键值对），`P_i` 表示数据提供者（即声明的来源，可以通过现有发行者（如 YouTube）或某个链上的 DeFi 应用等）

- `σ`，或签名：签署者在 `pk^U`、`ctx` 和 `{claim_i}` 上签名。签名表示为 `σ=Sig_{sk^C}({pk^U, ctx, {claim_i}^k})`，其中 `C` 是委员会节点集合，`k` 是声claim的数量。

显著的是，同样的设计可以在实际的 rollup 中复制，并直接使用一个主要链如以太坊作为 SBT 的结算层，而不仅仅是锚定交易。在这种情况下，可以更好地利用智能合约来管理凭证状态变化。可扩展性方面也不会是一个大问题，因为Gas费用将便宜。

### **第二个解决方案：修改分片（基于 SBT）**

第二个解决方案将凭证上链（例如，以 SBT 形式），但它利用 **分片** 来增加可扩展性并减少开销。基本上，不同的凭证集在由 **经过验证的/授权的发行者** 维护的分片下管理，每个子集负责自身的凭证 **状态变化**。每个分片自行协商其状态，并生成由分片验证者的法定人数签名的 Merkle 根。接着，信标链将分片根组合成一个信标根作为结算。

该设计的好处在于对 **跨分片通信** 的 **有限需求**，因为大多数凭证是简单的 **不可转让**。因此，账户无需试图找到分片中事务的 Merkle 路径，并以原子方式处理。当然，这将要求对每个 **分片** 的特定域进行非常小心的设计，以最小化此类通信。

该设计与 **以太坊** 目前正在推向的方向一致，因此可能也值得探索。如果实施了额外的信任假设（例如，借助 **可信硬件**，或特定的 zk 移动协议/承诺方案如 **Aztec** [11](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-11），也可以部分解决隐私问题。这将需要不同的分片具有不同的属性（类似于以太坊的第 1/2 阶段分片，当某些分片可以处理代码执行时，而其他分片作为可用性引擎）。在这里，跨链互操作性问题可能更难解决，因为桥接仍将是必要的。

## **凭证的遗产支持**

DeSoc 论文没有足够解决如何 **启动** 凭证的问题。为了应对目前 web3 中的 **过度金融化**，不能仅依赖这些链上金融应用程序作为身份信誉的唯一来源。目前链上的唯一主要数据源似乎就是交易（代币、NFT）、抵押数据、收益农耕数据等。一个非常重要的做法是以某种方式利用 **传统平台** 上的 **链外用户数据** 来引导声誉。例如，为了实施一个 **欠抵押** 的借贷协议，除了依赖于过去的链上 DeFi 行为外，还可以生成关于其 **银行储蓄** 和 **信用记录** 的证明声明。另一个例子可能是在链上社交协议中 **导入当前社交图（或其子图）**  在 **Twitter** 上。还有一个例子可能是通过政府网站（SSN）证明身份实施的 **抗 Sybil**。

为了实现这一点，需要某种 **去中心化的预言机** 方案，允许用户向第三方（例如链上应用程序）证明 **公共或私有** 数据在现有社交平台上的 **来源**，而无需 **服务器端** 修改。例如，用户可以轻松向链上服务证明她（与该服务交互的地址的拥有者）追随 YouTube 上的创作者，而无需 YouTube 本身通过服务器端 SDK、认证 API 等来证明数据的来源。

此处提到的主要学术研究为 **DECO** [12](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-12。一般思想是与数据提供者从 **用户端** 导出私有 TLS 会话数据，并向第三方应用（验证者）证明其原创性。在实施过程中，它在 TLS 会话期间在证明者、验证者和数据提供者之间建立了安全的 **三方握手**，然后执行查询并以 **零知识** 的方式向验证者证明所需的数据。该过程由安全多方计算（SMPC）的 2 方变种提供支持。TLS 会话的客户端密钥 **分成两个份额**，一个由用户持有，另一个由预言机持有。在预言机共享未公开的数据包之前，用户需要 **先提交** 从查询返回的数据包。因此，在确保数据的来源的同时，私有数据本身永远不离开客户端。

DECO 的另一种替代方案是 **Town Crier** [13](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-13，它基于可信硬件（如 SGX）引入了额外的安全假设。对源数据进行来源导出的早期开源尝试 **TLSNotary** [14](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-14 仅支持已废弃的 TLS 版本，并且不提供任何隐私。理论上，DeSoc 框架可以通过上述任一框架进行补充，以丰富其声誉系统。

![](https://img.learnblockchain.cn/2025/03/12/2F233dac63-e423-471b-84a0-7ebd6f7abd3f_726x439.png)

## **结论**

这篇评论摘录了我与 Clique 团队在过去几个月对声誉系统/身份/凭证空间所进行的许多思想过程。

总体而言，DeSoc 论文是一篇出色的研究论文，介绍了更多多样化的 web3 应用背后的新原始矩阵。我看到许多关于将凭证上链相比于完全实施链外 VC 的批评，但这其中更有深意。如本文讨论的，采用链外层进行凭证 CRUD 可能更有利于 **可扩展性** 和 **互操作性**（为声明提供单一事实来源，可映射到不同链上的账户），而链上凭证在 **可组合性** （与智能合约）、潜在的 **隐私** 和 **安全性** 方面要更佳（可编程隐私、社区恢复机制等）。最后，基于特定权衡的混合方法可能会更好。

本系列的第二部分将主要讨论在 DeSoc 下的此类声誉系统的通用机制设计。

* * *

_我是一名杜克大学的数学与计算机科学学生。目前，我正在 [Clique](https://twitter.com/Clique2046) 构建连接 web2 数据和 web3 应用的 DID 中间件。在此之前，我是中国全国物理比赛冠军、Megvii 的计算机视觉研究员，以及真格基金的科技投资者。如果你觉得这篇文章有趣，请在 [Twitter](https://twitter.com/kvny2046) 上关注我，与我通过电子邮件 [kevin@2046inc.xyz](mailto:kevin@2046inc.xyz) 联系，或在纽约市与我喝咖啡。_

_特别感谢 Puja、Glen、Wei、Raphael、Will Robinson、Kydo 和 Lushuo 的技术反馈。此外，感谢 Yinhong、DCBuilder、LW、Jessy、Priyanka、Jaden 和 Robert 的校对。_

## **参考文献**

[1] [去中心化社会：寻找 Web3 的灵魂](https://deliverypdf.ssrn.com/delivery.php?ID=558024120114006070087079014069121028033081036015093092028097097121122029094121022006001026024056060127015100113118068085072090049035005060074067079013076066068111098003017087074084099004088113016089107122101090090102003012100026071087126104083098072073&EXT=pdf&INDEX=TRUE)

[2] [你需要区块链吗](https://eprint.iacr.org/2017/375.pdf)

[3] [IDX：开放身份的开发工具包](https://learnblockchain.cn/article/12633)

[4] [灵活匿名交易 (Flax)：走向保护隐私和可组合的去中心化金融](https://eprint.iacr.org/2021/1249.pdf)

[5][公民证明：重新民主化无许可加密货币](https://berkeley-defi.github.io/assets/material/Proof%20of%20Person.pdf)

[6][可链式自发匿名组签名](https://eprint.iacr.org/2004/027.pdf)

[7] [最小化抗串通基础设施](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413?u=weijiekoh,%20https:/medium.com/privacy-scaling-explorations/release-announcement-maci-1-0-c032bddd2157)

[8] [Sidetree v1.0.0](https://identity.foundation/sidetree/spec/)

[9] [可验证凭证数据模型 v1.1](https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential)

[10] [去中心化标识符 (DIDs) v1.0](https://w3c.github.io/did-core/)

[11] [AZTEC 协议](https://github.com/AztecProtocol/AZTEC/blob/master/AZTEC.pdf)

[12] [DECO：利用去中心化预言机将 Web 数据解放](https://arxiv.org/abs/1909.00938)

[13] [CanDID：具有遗产兼容性、抗 Sybil 和问责性的去中心化身份](https://eprint.iacr.org/2020/934.pdf)

[14] [TLSNotary：工作原理](https://tlsnotary.org/how_it_works)

* * *

>- 原文链接： [kevinyu.substack.com/p/a...](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

简介

微软的 Glen Weyl、Flashbots 的 Puja Ohlhaver 和 Vitalik Buterin 最新发表的关于 去中心化社会（或 DeSoc）的文章 [1](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-1 在加密社区引起了轰动。有些人甚至将其与下一个“DeFi/NFT夏季”的潜在启动Hook。整篇文章围绕“ 公开可见、不可转让但可能可撤销的"代币”这一理念，构建了一些元叙事，即所谓的 Soul-bound tokens (SBT)。

作者详细描述了不可转让代币（及其链外对应物，可验证凭证）能为目前超金融化的加密空间所带来的激动人心的未来。这些 SBT 可以作为 声誉的信号 和工具，用于更广泛的 去中心化网络协调。由于这个话题也是我在过去几个月与 Clique 团队探索的内容之一，因此我在此撰写一篇评论，探讨 DeSoc 生态系统的优缺点、潜在设计规范以及技术实施的挑战。

这篇评论分为两部分。第一部分主要探讨将凭证系统上链与下链之间的权衡，以及设计身份系统的 遗产兼容性 方面。第二部分将更关注多元性、二次投票/资助以及声誉系统的通用机制设计。

DeSoc 文章摘要

一个幽灵在加密空间中徘徊——过度金融化的幽灵。DeSoc 旨在用“ 灵魂”和“ SBT”来解决这个问题，这是一对用于信号声誉、代表会员资格和授予访问权限的账户（钱包）和公开可见但不可转让的凭证（代币）。请记住，“账户”和“凭证”的定义可以是高度抽象的，而不一定限制于位于 公共区块链 上。这样一个系统的一些重要设计规范包括 SBT 的发行、用于声誉的 SBT 抵押、不同 SBT 的 可编程隐私 和基于社区的 密钥恢复 方案。

“灵魂”和“SBT”与 去中心化身份 领域中的“ 去中心化标识符” 和 “ 可验证凭证” 类似。作者在第 8.4 节中对此进行了详细阐述，并指出 DID 的 “ 单边隐私” 是一个主要缺陷以及限制应用范围的因素。 缺乏社会/社区恢复机制，这对普通用户安全至关重要，以及 缺乏大群体用户之间的可编程性和可组合性，是当前 DID 设计空间的一些其他问题，而 SBT 正在努力解决这些问题。

虽然我坚信许多应用依赖于 网络效应 并取决于某种程度的预先建立的 公开性 （声誉抵押等），但把 Layer1 区块链（例如以太坊）直接作为主要 执行层 来 存储、更新 和检索 凭证状态 （在这种情况下是 SBT 状态）有多个缺点。这已在原始作者和早期采用可验证凭证的用户之间产生了一些争论。因此，我将尝试在此提供一个中立的分析，考虑 可扩展性、互操作性、隐私和 可组合性 方面的 SBT。还提出了两种潜在的实现方案（均为混合方法）供进一步讨论。

我们应该将凭证放在链上吗？

完全上链 SBT 的好处

如果 SBT 并不具备可转让性，为什么要把它放在链上？不可转让性 意味着 无许可区块链共识机制 并不是绝对必要的，因为涉及的唯一交易将是凭证的发行、状态更新 和验证。前两个步骤需要由 受信第三方（例如一组委员会节点） 触发，该节点为 状态改变 的事实来源 [2](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-2。所有的写操作都委托给 TTP，然后可以通过任意 点对点 协议广播状态更新，并被其他节点验证（例如用于 去中心化存储，以维护所有客户端的状态 可用性）。凭证的验证可以在任何地方发生（通过智能合约的链上或通过某些 SDK 的链外）。

然而，确实有多种拥有本地上链不可转让凭证的好处。首先，与现有链上协议的集成将更容易。例如，根据 DeFi 农业记录发行链上 SBT 可以在链上原生发生，无需任何预言机。类似的案例适用于 DAOs 的 基于声誉的链上治理。

除了 可组合性，如果所有的发行逻辑都硬编码到 智能合约 中，自动赋予已经拥有良好声誉的账户（例如，持有大量高质量 SBT）授权，可以强制执行 完全去中心化。这将消除运行 单独网络 的需要 有许可的发行者节点，因为 发行者实体 可以直接设置由特定条件触发的智能合约。简单地说，可以将 SBT 的 claim 函数设为公开，任何人只要满足某些标准（例如，拥有某些其他 SBT），就可以调用。

与 VC 相比，SBT 另一个优势是它们作为账户的标志的能力。如果想要在链上验证一个声明是否真实并尝试使用 VC，就需要持有者可用并 愿意合作，这对 单边隐私 是一个巨大的限制。此外，仅能在时间点t 当它呈现时 查询声明状态。IDX [3](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-3 是一个优秀的选择，作为一个中心化存储库，查询凭证及其状态，前提是链上验证不是绝对必要的。

现在，让我们来谈谈将所有内容上链的一些潜在细微差别。

可扩展性

凭证的设计空间 将由于频繁状态更新的开销受到限制，这会产生 高额的Gas费用。例如，想要有一个凭证来详细说明在不同社交媒体平台上有多少追随者（可以是一些阈值值的集合）。在这种情况下，每当该数字变化时，就需要发起一个链上交易以更新状态。如果试图存储一个 社交图，这变得更不可扩展。在大多数情况下，用户甚至没有 财务激励 来支付Gas费用。

另一方面，如果代币作为某些链外凭证的指针（比如 NFT）被存储，我们就需要重新引入一个有权限的节点委员会来管理这些链外凭证。这与普通的 NFT 是不同的（Jpegs 并不应该改变），因为 智能合约 需要以可验证的方式写入链外存储。作为参考，这是一个预言机问题，Chainlink 正在通过他们的动态 NFT 来实施。

互操作性

将凭证完全上链使得 声誉系统 链特定。这引入了 互操作性 的额外问题。与普通的可转让和金融资产不同，它们可以穿越不同链的桥接，类似于 SBT 的凭证是不可转让的，并且它也必须是 抗 Sybil 的，即同一凭证需要在多个链中去重（特别是涉及链外数据时）。那么，哪个链将成为 单一事实来源呢？跨链互操作性如何工作？谁来维护 不同执行层 之间的状态变化？

发行者自身 可能需要维护在不同链上同步的 SBT 的独立实例。这将赋予它一次性撤销所有凭证的权利。如果发行者自身位于一个链上，并且能够 操控凭证状态 于 另一个链，这会相当麻烦。oracle 问题将普遍存在于所有互操作的操作中，类似于如果必须在链上验证链外 VC 声明。

未来，随着链变得更加 应用特定，这个问题可以获得更多缓解——在这种情况下，对互操作性的压力将大大降低，因为 GameFi 凭证通常不会离开特定于游戏的链（类似于 web2 游戏平台的内部声誉系统，例如 Steam 徽章）。不过，用户可能需要证明在不同链上拥有多个账户以交叉引用凭证。去重和链接不同身份再次成为一个问题。

隐私

作者已经讨论了 可验证凭证 的 单边隐私 特性。争论的焦点在于把一切放在链上自动强制执行 公开性 （除非使用某些隐私保护链，在这些链上状态由受信硬件/TEE 或特定的零知识 sigma 协议管理）。然而，使用链外网络维护凭证可以更加灵活：用户可以选择本地（私有）存储凭证或在 备份网络 中存储凭证，是否加密（私有/公共）。这将消除单边隐私，同时确保公共和私有凭证具有相同的接口。

链上 zk-attestations 的问题是，状态很难更新。目前的应用似乎只专注于证明一次性声明。将 zk-attestation（例如，属于某个身份组）映射到链上 SBT 似乎是理想的，因为用户在完成证明后并不会脱离该身份组。

最终，不同的应用场景将需要不同的隐私和信任假设。对于 基于智能合约 的设置来说，可编程隐私 可能更容易实现。诸如 FLAX (Wei) [4](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-4 的研究正在探索这个方向。与可验证凭证一起以去中心化的方式运行计算（例如某些 MPC 算法），似乎比与 隐私保护链 管理的状态运行同样的计算要困难得多。

抗 Sybil

与小型本地运行网络相比，抗 Sybil 显得更容易。“ 公民证明” 协议 [5](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-5 使用诸如 可链接环签名 [6](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-6 的密码学工具来实现这个目标，尽管这是一种不可扩展的方式。作者提到了在用户的公共链上 SBT 与其他已知声誉用户之间进行 关联检查。当很少有人具有足够声誉时，这就很容易为网络带来启动问题。随着时间的推移，这也可能进一步 中心化 网络，围绕某些个体而发展。

实现不可转让代币

假设在链上以不可转让代币的形式放置凭证是最佳选择。那么，问题就变成了：如何实现它？社区之前探索了各种解决方案，大多数建议对 transfer 和 transferFrom 方法进行某种Modification。EIP-1238 下的一个抽象接口如下：

社区已详细描述此设计下的一些问题：

一旦账户（钱包）被破坏，谁来管理凭证的转移？更重要的是，如何管理？根据这种实现，似乎非常困难。DeSoc 提出的 社区基础密钥恢复机制，通过扩展 受信方 的集合到账户所在的所有“社区”，来改进常规社会恢复方案。在实施中，监护人的集合将不断变化，而每个监护人可以访问的钱包也将会变化。这显著增加了 恢复图的复杂性。对于监护人集中的恶意行为者（如果不受信）的串通没有简单的解决方案。
在监护人之间可以应用流动性和相关性折扣等机制作为基本检查。像 MACI[7](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-7这样的受信串通抗性机制更为稳健，但信任设置中断可能会很困难。
也许像 EIP 121 这样的标准中，提出了一种用于资产管理和转移的统一代理合同设计。然而，这也引入了关于转移的粒度的新问题（例如，单个资产还是与某个钥匙相关的所有资产？）

最终，可能没有简单的方法来迫使 发行者 重新发行徽章或发起有权限的转移。这是一个经历了大量社区争论的话题。如果你对此话题感兴趣，请查看以下 GitHub 问题：ERC-1888: 可转让证书，调查 Open Badges 对我们需求的适用性，CDIP 2 - Maker 生态系统活动的不可转让徽章。

替代解决方案

为了解决上述问题，我将详细说明两种解决方案。在任何情况下，私密凭证 应该由用户本地存储（并可能由具有加密数据的网络备份），两者之间的区别主要在于 公共凭证 的发行、更新和验证。

第一个解决方案：链外 DID 与链上锚定（基于 VC)

第一个解决方案与Layer2设计相似，因为它以批量方式锚定存储在链外的凭证的 PKI 状态变化（公共密钥基础设施，基本上促进数字证书的 CRUD）到基础去中心化网络（可以是任何公共账本），在这里作为 结算层。 公共凭证 本身可以存储在任何 去中心化存储系统 中（根据不同的信任假设，可以是 IPFS、Arweave，甚至只是由凭证发行委员会运行的一组存储节点）。

去中心化标识符网络可以通过类似 Sidetree 协议 [8](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-8 来实现，该协议可以在任何现有的去中心化锚定系统（比特币，以太坊等）上运行，用于无许可凭证管理，使得系统链无关。Sidetree 下的 委员会节点 负责写入、观察和处理所有 DID PKI 状态操作，遵循确定性协议规则。

一组核心的 状态变化操作（例如 CRUD（创建、更新、恢复和停用））预先进行定义。由 委员会节点 将 CAS（基于内容的存储）引用锚定到基础锚定系统中、聚合操作的操作集，这在底层作用作为 线性时间顺序的预言机。DID PKI 操作因此存储有不可改变的历史，可以回放和验证，从而实现 DIDs 的一致视图。

在这样的设置下，Soul/SBT 可以重新表述为一组具有以下规范的 可验证凭证，根据 W3C VC 标准 [9](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-9[10](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-10。可以安排定制隐私，而链间互操作性可以通过与 DID 系统互动的链无关的预言机来解决。

pk^U，或用户标识符：凭证主体的伪匿名标识符
ctx，或上下文：表示发行上下文的字符串
{claim_i}，或声明：每个 claim_i={a_i,v_i,P_i}，其中 a_i 表示属性，v_i 表示值（作为与 a_i 的键值对），P_i 表示数据提供者（即声明的来源，可以通过现有发行者（如 YouTube）或某个链上的 DeFi 应用等）
σ，或签名：签署者在 pk^U、ctx 和 {claim_i} 上签名。签名表示为 σ=Sig_{sk^C}({pk^U, ctx, {claim_i}^k})，其中 C 是委员会节点集合，k 是声claim的数量。

第二个解决方案：修改分片（基于 SBT）

第二个解决方案将凭证上链（例如，以 SBT 形式），但它利用分片来增加可扩展性并减少开销。基本上，不同的凭证集在由 经过验证的/授权的发行者 维护的分片下管理，每个子集负责自身的凭证 状态变化。每个分片自行协商其状态，并生成由分片验证者的法定人数签名的 Merkle 根。接着，信标链将分片根组合成一个信标根作为结算。

该设计的好处在于对 跨分片通信 的 有限需求，因为大多数凭证是简单的 不可转让。因此，账户无需试图找到分片中事务的 Merkle 路径，并以原子方式处理。当然，这将要求对每个分片的特定域进行非常小心的设计，以最小化此类通信。

该设计与 以太坊 目前正在推向的方向一致，因此可能也值得探索。如果实施了额外的信任假设（例如，借助 可信硬件，或特定的 zk 移动协议/承诺方案如 Aztec [11](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-11），也可以部分解决隐私问题。这将需要不同的分片具有不同的属性（类似于以太坊的第 1/2 阶段分片，当某些分片可以处理代码执行时，而其他分片作为可用性引擎）。在这里，跨链互操作性问题可能更难解决，因为桥接仍将是必要的。

凭证的遗产支持

DeSoc 论文没有足够解决如何启动凭证的问题。为了应对目前 web3 中的 过度金融化，不能仅依赖这些链上金融应用程序作为身份信誉的唯一来源。目前链上的唯一主要数据源似乎就是交易（代币、NFT）、抵押数据、收益农耕数据等。一个非常重要的做法是以某种方式利用 传统平台 上的 链外用户数据 来引导声誉。例如，为了实施一个 欠抵押 的借贷协议，除了依赖于过去的链上 DeFi 行为外，还可以生成关于其 银行储蓄 和 信用记录 的证明声明。另一个例子可能是在链上社交协议中 导入当前社交图（或其子图） 在 Twitter 上。还有一个例子可能是通过政府网站（SSN）证明身份实施的 抗 Sybil。

为了实现这一点，需要某种 去中心化的预言机 方案，允许用户向第三方（例如链上应用程序）证明 公共或私有 数据在现有社交平台上的来源，而无需 服务器端 修改。例如，用户可以轻松向链上服务证明她（与该服务交互的地址的拥有者）追随 YouTube 上的创作者，而无需 YouTube 本身通过服务器端 SDK、认证 API 等来证明数据的来源。

此处提到的主要学术研究为 DECO [12](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-12。一般思想是与数据提供者从 用户端 导出私有 TLS 会话数据，并向第三方应用（验证者）证明其原创性。在实施过程中，它在 TLS 会话期间在证明者、验证者和数据提供者之间建立了安全的 三方握手，然后执行查询并以 零知识 的方式向验证者证明所需的数据。该过程由安全多方计算（SMPC）的 2 方变种提供支持。TLS 会话的客户端密钥 分成两个份额，一个由用户持有，另一个由预言机持有。在预言机共享未公开的数据包之前，用户需要 先提交 从查询返回的数据包。因此，在确保数据的来源的同时，私有数据本身永远不离开客户端。

DECO 的另一种替代方案是 Town Crier [13](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-13，它基于可信硬件（如 SGX）引入了额外的安全假设。对源数据进行来源导出的早期开源尝试 TLSNotary [14](https://kevinyu.substack.com/p/a-technical-commentary-on-desoc-part#footnote-14 仅支持已废弃的 TLS 版本，并且不提供任何隐私。理论上，DeSoc 框架可以通过上述任一框架进行补充，以丰富其声誉系统。

结论

这篇评论摘录了我与 Clique 团队在过去几个月对声誉系统/身份/凭证空间所进行的许多思想过程。

总体而言，DeSoc 论文是一篇出色的研究论文，介绍了更多多样化的 web3 应用背后的新原始矩阵。我看到许多关于将凭证上链相比于完全实施链外 VC 的批评，但这其中更有深意。如本文讨论的，采用链外层进行凭证 CRUD 可能更有利于 可扩展性 和 互操作性（为声明提供单一事实来源，可映射到不同链上的账户），而链上凭证在 可组合性 （与智能合约）、潜在的隐私和 安全性 方面要更佳（可编程隐私、社区恢复机制等）。最后，基于特定权衡的混合方法可能会更好。

本系列的第二部分将主要讨论在 DeSoc 下的此类声誉系统的通用机制设计。

我是一名杜克大学的数学与计算机科学学生。目前，我正在 Clique 构建连接 web2 数据和 web3 应用的 DID 中间件。在此之前，我是中国全国物理比赛冠军、Megvii 的计算机视觉研究员，以及真格基金的科技投资者。如果你觉得这篇文章有趣，请在 Twitter 上关注我，与我通过电子邮件 kevin@2046inc.xyz 联系，或在纽约市与我喝咖啡。

特别感谢 Puja、Glen、Wei、Raphael、Will Robinson、Kydo 和 Lushuo 的技术反馈。此外，感谢 Yinhong、DCBuilder、LW、Jessy、Priyanka、Jaden 和 Robert 的校对。