大数跨境
首页
>
【超多细节】灵魂绑定代币操作指南
>

【超多细节】灵魂绑定代币操作指南

【超多细节】灵魂绑定代币操作指南 FastDaily
2022-10-08
2
导读：手把手

本文属于老雅痞原创文章，转载规矩不变，给我们打声招呼～

转载请微信联系：yaoyaobigc，更多DAO、Web3、NFT、Metaverse资讯请关注老雅痞👇

导读


今日FastDaily共推送3篇文章。


灵魂绑定代币自V神提出后，热的嘞，大家都想抢先下手。灵魂绑定代币愿景、概念我们都懂，但是，设计原则、实现方式和示例，你能说出来多少？推荐阅读本文。


拍卖在加密世界随处可见。Web2对拍卖可没少研究，也总结出了很多经验结论。这些经验对Web3有没有参考价值？推荐阅读第一条，a16z关于链上拍卖的最新文章。


加密货币真的被绝大多数人知道，基本上就是在俄乌争端时期。加密货币的抗审查性，不可更改性，匿名性等特点，天然的成为了战争时期关于钱的最佳选择。推荐阅读第三条，给你捋清楚当时，都发生了写什么。

Spartan Labs丨作者

灵魂绑定代币愿景、设计原则、实现方式和示例

灵魂的构建第一部分：SBT的ABC


内容
1. 什么是灵魂绑定令牌，为什么它很重要？
1.1 Web3空间中的问题
1.2 SBT作为社会可组合性的解决方案
1.3 SBT的使用案例
→ 1.3.1 SBT的现实案例
2. Spartan Labs对SBT的愿景
2.1 SBT的愿景是如何在现实世界中实现的？
2.2 属性的第三方验证
2.3 反方灵魂对SBT的使用
3. 我们的灵魂绑定代币的主要特点
3.1 不可转让性
→ 3.1.1 治理
→ 3.1.2 身份
→ 3.1.3 正确实施不可转让性的重要性
3.2 不可伪造性
→ 3.2.1 可变通的SBT
→ 3.2.2 不可伪造的SBT
3.3 SBT中的隐私
→ 3.3.1 我们应该保留哪种数据的隐私？
→ 3.3.2 我们如何在SBT中保持数据隐私？
3.4 链外存储
3.5 灵魂的发行和验证
→ 3.5.1 灵魂的验证
→ 3.5.2 更新SBT的数据
→ 3.5.3 发放SBT
4. SBT中的关键功能如何在Web3项目中发挥作用？
5. 结论
摘要
在该系列的第一部分，我们将介绍灵魂绑定代币（SBTs）的基础知识及其重要性，并提出SBTs的关键特征的愿景。
1. 什么是灵魂绑定的代币，为什么它很重要？
维塔利克-布特林（Vitalik Buterin）是以太坊的联合创始人之一，他与Glen Weyl和Puja Ohlhaver合著了一份题为 “去中心化社会：寻找Web3的灵魂”论文，内容详细介绍了他们对一个完全去中心化的社会（DeSoc）的愿景，以及“灵魂绑定 ”代币（SBT）的概念如何使其成为现实。
1.1 Web3空间的问题
世界的经济价值在很大程度上是由人和他们相互依赖的关系产生的。作为一个完全由数学和密码功能运行的系统，Web3缺乏表示这种社会关系和身份的基元，这导致了它对中心化的Web2基础设施的依赖，而它最初的目的就是要颠覆这种基础设施。
信任和所有权的核心方面应该在链上，以增强智能合约世界的社会可组合性，这可以为去中心化的应用打开许多可能性。
1.2 SBT作为社会可组合性的解决方案
灵魂被定义为持有SBT的钱包。SBT是数字代币，代表了“灵魂”的凭证、承诺和隶属关系。它可以将实体经济的信任网络与链上的声誉和公信力进行编程。
例如，在去中心化金融领域，如果像Aave这样的借贷平台部署了SBT，每个地址（灵魂）可以在链上有一个独特的身份，实现基于信用分数的借贷。
这意味着，如果Aave部署了SBT，它将允许Aave自己进行基于信用分数的贷款，或者允许其他Dapp进行合成。
信用分数现在由政府实体（如信用局）集中持有。
SBT的强大之处在于，它将信用分数等基本概念分散化。每个去中心化的应用程序（Dapp）都被授权选择他们相信的任何信用系统，并发展他们自己的判断，而不是因为信用局是唯一持有这种信息的实体而不得不相信信用局。
更重要的是，SBT能够实现其他各种关键的应用和用例，如社区钱包恢复、抗Sybil治理、去中心化机制以及具有可分解、共享权利的新型市场。
1.3 SBT的用例
使用SBT可能会有很多影响。以下是Vitalik共同撰写的论文中强调的一些相关的使用案例：
  1. 在NFT项目中验证艺术家的合法性
  2. 大多数NFT艺术家依靠OpenSea和Twitter这样的中心化平台来承诺稀缺性和初始出处。
  3. 如果艺术家能将他们的NFT项目与他们的SBT联系起来，SBT有助于提供出处
  4. 通过信誉释放担保不足的借贷市场
  5. 代表教育证书、工作历史和租赁合同的SBT可以作为信用相关历史的持久记录，使灵魂能够以有意义的声誉来避免抵押品要求并获得贷款。
  6. 减轻对DAO治理的攻击并改善其协调性
  7. 缓解Sybil攻击
  8. 动态领导权分配
  9. 治理的多样性
  10. 用可分解的、共享的权利和权限创建新的市场
  11. 衡量去中心化
1.3.1 SBTs的现实案例
项目已经开始实施SBT作为链上身份的解决方案。
Binance已经推出Binance Account Bound (BAB)代币，这是该公司基于该公司原生Build and Build (BNB)链的灵魂绑定或不可转让和非金融化代币的版本。通过平台的“了解你的客户”（KYC）程序验证了身份的用户可以直接在他们的数字Binance钱包中铸造SBT。BAB将被用作KYC凭证，表明用户的身份已被验证。第三方协议也可以利用它来空投NFT和防止机器人。BAB也可以被去中心化的自治团体使用，以实现四级投票。
其他NFT项目也试图将SBT与他们的项目相结合。例如，Arc Community正在向社区成员发行其Pyxis NFT，作为链上认可和未来奖励的方法。
2.Spartan Labs对SBT的愿景
尽管Vitalik的论文为SBT奠定了基础，但其关键特征、实施和用例还没有完全确定。在本节中，我们将概述我们对SBT的愿景，以及不同的孤立项目如何与系统的嵌入式社会信任进行合作。
我们设想的社会是将信誉系统与零知识（ZK）机制相结合，以保护个人的隐私。Balaji Srinivasan创造并推广了“假名经济”这一短语，他是这一概念最有力的支持者。
我们相信，SBTs可以在Web3空间中整合假名经济和社会可组合性的理念。SBTs不仅可以作为匿名个体的可信任的可组合性的额外机会，而且还可以实现跨项目和协议的互操作性，重新想象我们目前的Web3生态系统。
2.1 SBT的愿景是如何在现实世界中实现的？
想象一下，在这个世界上，大多数参与者都有储存对应于各种关系、会员资格和证书的SBT的灵魂。一个人可以有一个储存代表不同属性的SBT的灵魂，如教育证书、信用分数和成就。
2.2 属性的第三方验证
如何验证SBT中的属性并将其与链上身份联系起来？
这些受信任的第三方验证机构的功能类似于证书颁发机构（CA），其目的是验证身份并将身份与数字证书联系起来。这些证书用于保护信息，加密数十亿的交易，并实现安全通信。在颁发数字证书之前，CA将对申请人进行若干身份检查。
在SBT的背景下，可以有一个可信的去中心化的第三方中介DAO，其利益与属性的准确验证相一致。寻求SBT的个人可以向DAO支付初始验证费用。来自DAO的无关人员组成的小组将在允许铸造SBT数据之前进行检查，验证者将为他们的验证支付费用。
2.3 反方灵魂对SBT的使用
在其最基本的形式中，SBT的数据可以由个人宣布，就像我们在简历中透露自己的信息一样。然而，当一个灵魂持有的SBT可以由作为这些链接的对手方的其他灵魂发布或证明时，该系统的真正潜力就凸显出来了。这些对手方灵魂可以是个人、企业、机构和其他Web3项目。
对手方灵魂可以将SBT空投给他们的用户。然后，这些用户将与SBT项目互动，更新SBT数据。然后，其他有权限的协议可以利用SBT来读取和验证个人的属性。其他有权限的协议然后可以利用这个SBT来读取和验证个人的属性。这使得Web3项目具有社会可组合性，允许它们根据个人的属性实施不同的机制，例如允许属于某个特定组织的地址使用其产品，或者赋予经其SBT验证的关键利益相关者更高的投票权。
例如，一个有影响力的人可以是一个向长期粉丝发放SBT的灵魂。一所大学可以是向毕业生发放SBT的灵魂。活动组织者可以是一个向参加活动的人发放SBT的灵魂。
在接下来的章节中，我们将展示SBT的核心原则是如何从设计本身自发产生的。
3. 我们的灵魂绑定代币的关键特征
目前还没有关于SBT主要特征的正式定义。为了在Web3项目中普及SBT的使用，我们确定了SBT应该具有的重要品质。
3.1 非可转让性
不可转移性是指SBT应该保留在用户的灵魂中，或者被标记到用户的地址中。应该有硬性的检查来防止SBT的可转移性。
但我们为什么要让它不可转让呢？
3.1.1 管理
SBT的可转让性可能会导致治理问题。
  1. 如果可转让性的目标是为了使治理权力能够广泛分配，这将导致一个相反的效果，因为中心化的利益集团更倾向于从其他人那里获得治理权。
  2. 如果目标是将权力委托给有能力的领导人，那么可转让性就会产生反作用，因为没有什么能禁止有积极性但不熟练的人获得治理能力。
3.1.2 身份
SBT代表一个人的身份；因此，防止冒名顶替是至关重要的。身份不应该被转移，特别是当SBT中存在敏感数据时。我们不希望出现有人通过在二级市场上收购SBT而轻易获得有利的属性。
3.1.3 正确的不可转让性实施的重要性
正如Vitalik在他的文章中提到的，如果不可转让性被“天真”地做了，可转让性仍然会带来问题。用户可以很容易地构建一个保留了SBT的包装账户，然后出售账户所有权。
防止转让性
其他检查可能是必要的，例如在链上检查当前所有者是否与原所有者在同一地址，如果认为有必要，还可以随着时间推移进行更复杂的检查。项目也可以要求SBT是原始的SBT，这可以减少创造和利用包装物来玩弄系统的动机。
3.2 非同质化
SBT既可以是可替换的，也可以是不可替换的，由此产生的功能会有很大的不同。
3.2.1 可变通的SBT
可替换的SBT对于投票权和治理来说是很有用的，在这种情况下，有一种容易确定的方式来发现投票权是很重要的。一个微不足道的可替换灵魂的实现可以消除类似于ERC20的代币转让能力，除了合约或所有者本身。
3.2.2 非可替代性SBT
另一方面，非可替换的SBT允许更多的可能性，因为所有的灵魂都是独一无二的，我们希望将这些区别与他们的SBT相关联。信用历史、负面声誉和教育证书都可以与SBT联系起来，并可以选择将这些细节保密。
3.3 SBT的隐私
在链上记录的任何关系对整个世界上的任何人都是立即可见的，而不仅仅是参与者。通过关联SBT数据，敌对的行为者可能会从用户的灵魂中泄露用户的真实身份。
Web3生态系统的成功取决于隐私。在某些情况下，由于项目所代表的基本实体已经公开，增加隐私是不必要的。然而，在其他许多情况下，人们可能不希望透露他们拥有的所有数据，因为这可能对他们构成潜在威胁。
例如，如果一个人的疫苗接种状态成为一个SBT，我们可以做的最糟糕的事情之一就是建立一个系统，让SBT自动公开给所有人看，因为这对人们的医疗决定造成了社会压力。
通过在设计中包括隐私，我们可以防止在链上有身份的这些负面影响，并提高产生美妙事物的可能性。
3.3.1 我们应该保留哪种数据的隐私？
敏感数据或那些能使恶意行为者与个人身份相关联并泄露身份的数据。例子包括：
  • 个人资料
  • 医疗数据
  • 财务数据
  • 基于信誉的数据
3.3.2 我们如何保持SBT内数据的隐私？
有各种方法来保持这些数据的私密性，例如：
3.3.2.1 数据的哈希化

  • 哈希数据是一种相对简单的保持数据隐私的方法。
  • 哈希是输入数据的固定长度的单向变换。
  • 例如，如果我们可以将一个秘密的“Spartan Labs ”输入哈希函数。
  • 哈希函数将把这个数据转换成一系列十六进制，如`ca9210da4bd8dda215176e8621b84f477da40ffa2158eeff7ef5d14613dfa695`。
  • 这个十六进制是固定长度的，这意味着所有的散列结果都有相同的长度，从统计学上来说，不可能从中推断出 “Spartan Labs”。
  • 这里使用的哈希函数是SHA-256。
  • 如果散列的数据与链上的散列值一致，就可以验证用户的属性。
  • 其他各方将无法查看SBT的链上数据，如果散列的结果相同，就可以证明数据的有效性。
3.3.2.2 对称密钥加密
  • 项目可以向用户发放一个秘密密钥，然后他们可以对自己的数据进行加密，他们可以与其他可能需要验证其数据的项目分享。
  • 然而，这不是一个简单的方法，它要求用户保持他们的对称密钥的私密性，而其他想要利用用户的SBT数据的Web3项目也要实现同样的解密过程。
3.3.2.3 zk-Proofs

  • 零知识证明（zk-Proofs）允许人们证明任意的陈述，而不需要透露陈述本身以外的任何信息。

  • zk-Proofs可以在SBT上计算，以证明一个灵魂的特征（例如，它有某些成员资格），而不透露什么是特征。
  • 这通常被用于使用ZK-Rollup技术的L2，如zkSync、Polygon Hermez和Scroll。
3.4 链外存储
根据项目的需要，SBTs的数据可以存储在链上或链外。如果存储在链上，它可以存储在一个单独的合约上，并引用另一个地址，或者可以存储在SBT合约本身。
然而，在链上存储数据的计算成本很高。因此，我们建议SBT的关键特征之一是能够整合链外存储数据，类似于ERC721 NFT在链外存储数据的方式。这使得成本较低且类型多样的数据能够与SBT相关联。
3.5 灵魂的发行和验证
SBT的发行和验证属性对可组合性至关重要。
3.5.1 灵魂的验证
SBT界面的设计应使其他项目可以很容易地与用户的SBT互动。对于其他Web3项目来说，设计一个链上机制来验证用户的属性不应该很复杂。这意味着灵魂的属性可以很容易地在链上被查询和验证。
  • 如果SBT存储在链外位置，应该有一个建议的标准，让其他项目如何根据链外存储的数据结构查询数据。
  • 如果SBT有私人数据，应该有一个简单的方法来(1)验证用户提供的URI，或者(2)证明用户有某种属性而不透露URI，而只是秘密本身的哈希值。这是参考了ZK技术的使用。
3.5.2 SBT数据的更新
为防止用户的数据造假，只有合约所有人有权限更新用户的SBT数据。但是，项目应使项目可以提出对其SBT数据的修改。
3.5.3 签发SBT
项目可以很容易地将SBT发放给用户。这可以以类似于NFT的铸造方式或空投方式来完成。
4.SBT的关键功能如何在Web3项目中发挥作用？
假设一个项目想有一个智能合约，只允许有KYC信息的用户与合约互动。这个智能合约可以根据用户的数据属性执行不同的行动。其他项目应该能够在链上验证并对用户的数据进行操作。
然而，在区块链上，一切都是匿名的，用户只有他们的地址是可公开验证的属性。
该项目可以考虑使用SBT作为链上识别的机制，并存储用户的KYC数据。
为了使用SBT作为一种机制，该项目可以采取以下行动：
  • 用户提交他们的KYC信息，由现实世界的实体进行验证。一旦这些信息得到验证，该项目就会为用户开采SBT。用户提供的信息是加密的，并存储在链外。
  • 其他对手方项目也可以验证用户是被KYC过的，并且有某些属性，但不知道用户的具体信息。这些链上KYC的属性通过加密是私有的。然而，用户可以向这些其他对手方项目提供秘密，这就为他们提供了读取和验证其链上私人信息的能力。
  • 用户可以通过向负责的主要项目提出修改建议来更新他们的链外信息。
5. 结论
SBT是基于信誉的不可转让、不可伪造的代币，其数据只能由选定的各方访问。社会身份与无信任组合性的整合，如果做得好，可以改变Web3生态系统的未来。

灵魂的构建第二部分：SBT的实施


内容
1. 实施的想法
1.1 与NFT的比较
1.2 基本的SBT
→ 1.2.1 mint和燃烧
→ 1.2.2 链外存储
→ 1.2.3 验证SBT属性
→ 1.2.4 SBT数据的更新
→ 1.2.5 基本SBT的使用情况
→ 1.2.6 SBT中对隐私的需求
2.带有数据私人存储的SBT
2.1 在链上存储数据，但对地址进行散列处理
→ 2.1.1 使用实例
→ 2.1.2 讨论带链上哈希的SBT
2.2 将项目存储在链外的第三方供应商（如IPFS）上
→ 2.2.1 将链外数据与链上哈希链接连接起来
→ 2.2.2 链外秘密的风险。
3. 总结
我们已经介绍了SBT的基本原理，我们对SBT的愿景，其技术实现和利用ZK技术的可能性。第一部分讨论了什么是SBT以及它的基本特征。第2部分讨论了基本实现以及我们如何利用SBT增加隐私。最后，第三部分将讨论我们如何利用ZK技术来改善SBT的隐私。本系列文章的目标是揭开SBT技术思想的神秘面纱，并提供一个实现，以构建一个具有社会身份整合的Web3未来。
我们已经提出了SBT的愿景、用例和关键特征。
总之，围绕着SBT的实现的设计准则是：
  • 不可伪造
  • 不可转让
  • 发放和验证灵魂的可组合性
  • 隐私
  • 用于SBT的链外数据存储
我们将根据之前提出的设计准则，对SBT的实施进行探讨。
1. 实施的想法
在这一部分中，我们将讨论SBT的实现和它的权衡。
1.1 与NFT的比较
既然NFT和SBT听起来确实很相似，那么这些数据结构在实现上的关键区别是什么？
非可转移性
与NFT不同，SBT被设计为可交易的，SBT应该在本质上与灵魂相联系，应该是不可转让的。
隐私
NFT的数据是为了让人们公开查看。然而，SBT项目可能想让他们的数据保密。
隐私可以通过各种不同的方法来实现。
可组合性
SBT的数据应该很容易被其他链上或链下项目读取。
以下列特征为准则，我们在Solidity中实现了SBT。
我们将在下面的章节中讨论我们的实现。
1.2 基本SBT
基本的SBT作为一个模板，供那些可能想要建立在SBT之上的项目使用。基本的实现不包括对隐私的讨论，这将在文章的第2节。
1.2.1 mint和燃烧
契约的设计是这样的，铸币是由所有者把关的。这是为了防止任何潜在的漏洞，即用户可以铸造任何SBT信息，比如铸造一个好的信用分数，即使这不是项目所确定的。我们的想法是，项目应该确定并验证和铸造与SBT相关的正确数据。
同样，对于烧毁与地址相关的SBT，我们认为用户不应该能够轻易地删除他们的数据，特别是如果它是一个负面的属性。用户应该能够提议燃烧他们的SBT，但燃烧的执行应该由所有者决定。
焚烧可以由那些想让用户选择删除他们的数据的项目来实施。例如，一个希望从项目中删除其所有信息的用户，因为他与项目的目标不一致，应该有这样的选择。
另一个考虑因素是项目可能想如何策划他们的SBT社区，并在用户违反其条款和条件时将其删除。例如，在一个发布SBT的社区中，一个用户可能不遵守规则，表现出不适当的行为。因此，社区可以决定是否从其项目中删除该用户的SBT。这类社区可能希望进一步实施建议机制，允许建议自我烧毁以删除数据，或建议烧毁另一个人的SBT。
1.2.2 链外存储
数据可以被存储在链上或链外。在我们的实现中，我们假设SBT的数据是存储在链外的供应商，如IPFS。在我们的实现中，链外存储的URI可以与数据结构 “Struct Soul ”中的身份相联系。


项目能够根据其是否要在链外或链上存储SBT属性来调整建议的结构。
1.2.3 SBT属性的验证
其他交易方项目应该能够轻松地从SBT中检索数据。
这对想要验证用户的SBT属性的交易方很有用。其他项目将能够检查一个地址是否有灵魂，并验证该灵魂所包含的属性。
这对SBT与不同项目的可组合性很重要，因为其他项目可能想与用户互动并验证其属性。然而，用户和项目可能不希望这些数据是公开的，有几种方法可以使这些数据私有化。
1.2.4 SBT数据的更新
我们不希望用户或其他各方更新除许可机构以外的灵魂，因为我们希望他们的数据变化得到验证。
相反，项目实施合约，使用户可以在链外提出对灵魂的改变，而项目可以验证这些改变是否有效并在链上更新这些改变。


1.2.5 基本SBT的用法
SBT的基本实现适用于那些希望将数据分配给非私人性质的用户的项目。例如，想要根据白名单对NFT收集的支持来奖励他们的项目可以利用这个SBT。在未来，项目可以通过SBT向这些地址空投奖励。
上面的内容我们提出了SBT如何成为识别NFT锁子的潜在用例。
例如，当NFT在TimeLock.sol内被锁定时，储物柜可能仍然希望“显示”他们确实拥有这样一个锁定的NFT。然而，从开发者的角度来看，引用锁定的NFT会很奇怪。因此，“灵魂绑定”代币可以代表用户锁定NFT的时间，他们可以被允许进入名人堂。在解锁时，需要 “烧掉”一个不可转让的包装代币来解锁NFT，而这个储物柜将不再有 “名人堂”的地位。
1.2.6 SBT中对隐私的需求
然而，上面建议的基本SBT并没有考虑到隐私方面。
正如前文所提到的，未来的Web3将需要与你的真实身份进行一些整合。因此，在链上整合后保持个人身份的私密性是至关重要的，以保护自己不被那些可以查看区块链公共数据和泄露个人身份的恶意行为者利用。
任何被记录在链上的关系对整个世界上的任何人都是立即可见的，而不仅仅是参与者。通过关联SBT数据，敌对的行为者可能会从用户的灵魂中泄露他们的真实身份。
例如，如果人性证明得到更广泛的使用，隐私将变得更加重要，因为另一种情况是，我们所做的一切都会在链上直接与人脸联系起来。
2. SBT与数据的私人存储


在Vitalik的研究论文中，他提出了一些具有隐私性的SBT的可能实现方式，这在链上和链下存储中都可以实现。
在本节中，我们将讨论SBT数据隐私存储的可能实现。
2.1 将数据存储在链上，但对地址进行哈希运算
  • 将项目存储在一个地址，该地址是(i)一个索引的哈希值，(ii)收件人地址，和(iii)属于收件人的秘密。
  • 你可以将你的秘密透露给一个接口，然后它将搜索所有可能属于你的物品，但除非你透露你的秘密，否则没有人会知道哪些物品是你的。
  • 用户提供的秘密将使平台能够找到与用户的SBT相关的所有数据。
  • 这种方法也被称为消息认证的键合（HMAC）。它是通过对数据和共享秘密密钥运行加密散列函数而获得的消息认证码。
  • 为什么会有这种效果？以太坊地址是由Keccak-256哈希值生成的，并以十六进制数字表示。Keccak-256散列的最后20个字节被用来生成地址。
  • 由于一个十六进制数字是4位，我们将把Keccak 256哈希值的最后40位作为我们的地址。我们可以在这个地址上部署我们的项目。
  • 然而，请注意，用秘密的散列应该在链外进行，因为区块链上的一切（包括私人状态变量）都是公开的。
  • 因此，在部署或铸币时，只应提供哈希值而不是秘密。

如何在特定地址部署用户密钥。
2.1.1 使用实例
例如，Bob想用一个基于信用的贷款DApp来铸造一个SBT。
  • 借贷平台首先对Bob进行KYC。
  • 部署地址由Bob的客户ID、他的链上地址和“ Peanut”--他想出的一个秘密产生。
  • Bob的客户ID、地址和秘密被散列在一起，得到一个地址，用于数据部署地址。
  • 然后，一个包含Bob的KYC数据的SBT被部署到链上的部署地址。
  • 除了知道Bob的秘密的人，没有其他人可以扫描Bob的KYC数据。
  • 当一个项目想要查看Bob的KYC数据时，Bob只需要提供他的秘密 “Peanut”，他们就可以获得Bob的所有KYC数据。
2.1.2 讨论SBT与链上哈希的关系
优点：
这种方法允许与协议的互操作性，因为我们只需要秘密、索引和地址来检索项目。
缺点：
然而，将项目部署到特定的地址是很麻烦的，而且耗费大量的gas。
此外，将所有与SBT相关的数据存储在链上是没有意义的，有些数据可能更适合在链外存储。
更重要的是，用户的秘密的信任度掌握在项目手中；长期使用可能会导致泄密，类似于今天的密码泄密。
2.2 将项目在链外存储在第三方供应商如IPFS上
如上一节所述，将大部分数据存储在链上的成本太高。因此，一个更好的方法是将数据存储在链外，如IPFS或其他云服务的第三方平台。这种在链外存储数据的方法与NFT非常相似，其数据通常也是在链外存储。


不同的是，为了确保隐私，我们首先要用加密哈希函数（如SHA256）对URI字符串进行哈希。URI数据的散列应该在链外进行，因为区块链上的所有数据都是公开的，甚至是私人状态变量。
为了防止蛮力攻击来识别包含链外数据的链接，哈希值不应该只是链接本身的哈希值。它可以是用户的秘密与链外数据存储链接的函数，或者是递归散列，以及其他方法。这也被称为salting。
一个在Python中用SHA256实现的例子：



这只是一个实现的例子。还有很多其他的方法来掩盖URI，例如随机附加密码、生成随机密码、使用其他专门为安全存储密码而设计的算法。
然后，链上链SBT的部署是用数据的哈希值而不是数据本身。
2.2.1 将链外数据与链上哈希链接连接起来
我们可能如何能够将链外数据与链上哈希链接连接起来？
一种可能的方法是由合约所有者对存储在链外的数据结构进行标准化。因此，SBT的所有者可以揭示链外数据的链接，而项目（不一定与部署者相同）可以对链接进行散列，以检查它是否与链上的散列相等。如果哈希值相同，项目可以使用查询来检索存储在链外位置的数据。
为了维护用户的秘密，对包含用户数据的链接的验证必须在链外由受信任的安全第三方完成。
2.2.2 链外秘密的风险。
在链外传递秘密可能会使用户暴露于脆弱性和不同的攻击。
项目必须研究如何保证秘密传输的安全，防止常见的攻击，如回放攻击、中间人攻击、重放攻击和许多其他常见的攻击。
一旦处理检索SBT的第三方的安全被攻破，个人的秘密就会被公开。
项目还应该注意网络钓鱼攻击，因为用户可能被提示在复制原始密码的恶意网站上输入他们的密码。
此外，证明一个用户具有某种属性的唯一方法是暴露秘密。然而，为了创建SBT的假名可组合性，不同的协议可以从SBT中检索数据，用户应该暴露最小的所需数据量。
如果项目所需要的只是验证一个属性，用户就不应该暴露整个秘密。用户应该把他们的秘密暴露在尽可能少的项目中，这是可行的。
因此，我们需要考虑另一种方法，即项目能够在用户不泄露秘密的情况下验证用户是否具有某种属性。
3. 总结
我们根据本系列第一部分介绍的设计准则，经历了SBT的实现。我们实现了基本的SBT，以及具有私有链上和链下存储的SBT。然而，链外存储可能不是真正的隐私，因为用户必须放弃他们的秘密，以证明他们拥有的某种属性。
ZK技术的使用可以帮助我们减少用户对秘密的分享，以保持他们的SBT数据真正的隐私。

灵魂的构建第 3 部分：使用 zk-SNARK 实现的灵魂绑定代币


内容
1. 什么是ZK证明
2. ZK证明如何与SBT一起使用？
3. 什么是zk-SNARK？
4. 关于ZKSBT如何工作的高级解释
→ 4.1.1 生成一个随机的Lambda。
→ 4.1.2 生成证明密钥和验证密钥
→ 4.1.3 共享证明和验证密钥
→ 4.1.4 生成证明
→ 4.1.5 验证用户的属性
5. 高级示例的TL;DR
5.1 链上算法与链下算法
6. zkSBT的实现
6.1 电路创建
6.2 设置阶段
→ 6.2.1 密钥生成
6.3 证明生成阶段
6.4 验证程序阶段
→ 6.4.1 项目如何在其SBT中使用Verifier.sol？
→ 6.4.1.1 风险：防止重放攻击
6.5 实施架构
7. ZKSBT（zk-SNARK SBT）与对抗方灵魂的可组合性
7.1 单一的方法：SBT发行者承担责任
7.2 多石块方法：每个项目都要承担责任
8. 结语
在讨论隐私的过程中，我们看到如果用户为了验证一个属性而泄露了他的秘密，那么用户的隐私可能会很容易受到危害。因此，使用零知识技术来保证用户数据的安全可能是一个重要的选择。
下面，我们将讨论ZK如何可能成为增加SBT用户数据隐私的关键技术，以及项目如何应用实施Zero Knowledge SoulBound Token（zkSBT）。
1. 什么是ZK证明
零知识证明允许一方（证明者）向另一方（验证者）证明一个声明是真实的，而不透露声明本身的有效性以外的任何信息。
证明者必须让验证者相信他拥有满足某种关系的秘密参数（称为证人）的知识，而不向验证者或其他任何人透露该证人。
| 证人是我们约束条件的有效解决方案。
| 约束是指我们将问题转换成的多项式方程。问题的每个解决方案都必须符合约束条件的要求。例如，证明用户的信用分数是3，可以简单地转换为约束条件x=3。
2. ZK证明如何与SBT一起使用？
项目可以通过使用ZK证明来验证灵魂的属性（例如，它具有某些成员资格）。他们还可以通过允许用户验证任意的断言，而不需要给出除声明本身之外的任何进一步信息。
例如，在一个政府文件和其他证明可以加密证明的世界里，有人可以证明这样一个声明：“我是新加坡公民，年满18岁，拥有计算机科学的大学学位，还没有在这个系统中申请账户。”
还有其他的ZK实现；然而，zk-SNARKs是最突出的ZK技术，在黑暗森林Eth、龙卷风现金和ZK-Rollups等应用中利用。
3. 什么是zk-SNARK？
zk-SNARK是一种防ZK技术的实现，代表了零知识的简洁、非交互式的知识论证。
该缩写的各个部分有如下含义：
  • 零知识：在互动过程中，验证者除了知道声明的有效性外，什么都不知道。
  • 简洁：证明很短，可以快速验证。
  • 非交互式：没有或仅有少量的交互。对于zk-SNARKs，通常有一个设置阶段，在这之后，从证明者到验证者只有一个消息。此外，SNARKs通常具有所谓的 “公共验证者 ”属性，即任何人都可以自己验证证明。
  • 争论：验证者只针对计算能力有限的证明者进行保护。具有足够处理能力的证明者可以生成关于不正确语句的证明/论证。这被视为“计算上的健全性”，与 “完全健全性 ”相对。
  • 知识的：证明者如果不知道某个所谓的证人，就不可能构建一个证明/论证。
简单地说，这基本上意味着证明是一个可以独立验证的数据集合，没有证明者的参与。
4. 关于ZKSBT如何工作的高级解释
在这个例子中，SBT的用户是证明者，而向用户发布SBT的项目是验证者。
假设一个项目要看用户是否有某个属性`secret_attribute`。用户必须证明他们拥有`secret_attribute'属性，而不透露他们的秘密`s'，这些秘密是用来将`secret_attribute'属性散列成`hash_attribute'的。
通常情况下，用户会通过向项目提供秘密`s`来证明这一点，之后项目可以计算出哈希`hash_attribute`。然而，在zk-SNARK中，用户可以只提交他们拥有属性`secret_attribute`的证明，而不透露他们的秘密`s`。
我们可以用以下程序C来描述用户的情况：

换句话说：该程序接受一个公共哈希值`hash_attribute`和一个秘密值`secret_attribute`，如果`secret_attribute`的SHA-256哈希值与`hash_attribute`相等，则返回true。
使用函数`C(hash_attribute,secret_attribute)`，用户需要创建他们拥有`secret_attribute`的证明，而不需要透露`secret_attribute`。这就是zk-SNARKs解决的一般问题。
为了实现这个证明和验证系统，该项目首先要进行以下操作：
4.1.1 生成一个随机的Lambda。
lambda的生成是证明的第一步。注意到生成器的秘密参数lambda。任何知道这个参数的人都可以在不知道秘密`w`的情况下创造出评价为真的假证明。
因此，运行生成器需要一个非常安全的方法，以确保没有人发现并在任何地方存储这些参数。这也是Zcash团队用无比复杂的仪式来产生证明密钥和验证密钥，同时确保参数lambda在这个过程中被销毁的理由。
4.1.2 生成证明密钥和验证密钥
该项目必须生成两个公开的密钥——证明密钥`pk`，和验证密钥`vk`。密钥生成程序G需要一个秘密参数`lambda`和一个程序`C`。这些密钥是公共参数，只需要为一个给定的程序C生成一次。
在大多数情况下，这个程序C是以电路的形式实现的（更多细节在下一节）。

使用程序 C 和 lambda 生成证明密钥“pk”和验证密钥“vk”。
一个独立于用户和项目的受信任的独立小组可以运行生成器，并以一种没有人知道lambda的方式创建证明密钥`pk`和验证密钥`vk`。
然后，任何信任相关各方的人都可以在未来的互动中使用这些密钥。
4.1.3 证明和验证密钥的共享
该项目将与用户共享证明密钥`pk`和验证密钥`vk`。然后，这些密钥可以用来生成基于用户属性的证明，以及验证属性。
这里的 “共享 ”一词用得很宽泛。项目不需要明确披露，但他们可以在前端提供一个功能，允许用户或交易方进行自己的证明或验证。

项目为用户生成证明和验证密钥
4.1.4 证明的产生
然后用户需要证明他知道与已知哈希值 "hash_attribute "进行哈希的 "secret_attribute"。为此，用户运行证明算法`generate_proof`，使用输入pk、H和s来创建证明`prf`。
H是使用SHA256的s的公共哈希值。

其中 H 是哈希密钥，s 是密钥，pk 是证明密钥

用户生成证明
当项目想检查一个用户是否具有某种属性时：
4.1.5 验证用户的属性
用户将生成的证明`prf`交给项目，项目运行验证函数`verify(vk, H, prf)`。


该项目计算`verify(vk, hash_attribute, prf)`，如果证明是正确的，则返回真，否则返回假。
这个验证算法也可以是链上的。
如果验证算法返回真，项目可以确信用户拥有该属性，但用户不需要向验证项目透露其属性。


5. 高级示例的TL;DR
一个zk-SNARK由三个算法`G`、`P`、`V`组成，定义如下：
生成器程序
密钥生成器 “G”接受一个秘密参数 “lambda ”和一个程序 “C ”来产生两个公开可用的密钥，一个证明密钥 “pk ”和一个验证密钥 “vk”。这些钥匙是公共参数，对某个程序'C'可以只生成一次。
通过对lambda的适当处置，生成算法可以脱离链。然后，生成的证明密钥和验证密钥可以与用户共享。
请注意，程序C也被称为公共算术电路。
验证人程序
验证器P接受证明密钥'pk'，公共输入'x'和私人证人'w'作为输入。该算法生成一个证明`prf = P(pk, x, w)`。
用户的证明生成可以用证明和验证密钥及其证人在链外完成。建议在链外生成证明，因为生成证明的计算成本很高，而且用户的秘密可能在链上被泄露。
| 证人是由用户的秘密转化而来，这对我们的约束来说是一个有效的解决方案。
验证器程序
验证器V计算`V(vk, x, prf)`，如果证明是正确的，则返回真，否则返回假。因此，如果验证者知道有一个证人`w`满足`C(x,w)==true`，这个函数就会返回true。
验证可以在链上完成，因为它相对较小，需要输入证明、秘密的哈希值和验证密钥作为公共输入参数。
5.1 链上算法与链外算法
链下
  • 项目（验证者）将运行生成器来生成证明密钥和验证密钥。
  • 然后，任何用户（验证者）可以使用证明密钥来生成链外证明。
  • 用户可以通过运行具有以下输入的证明算法来做到这一点——证明密钥、公共输入和私人见证（由秘密的哈希值和秘密生成）。
链上
  • 智能合约内的一般验证算法可以用证明、秘密的哈希值和验证密钥作为公共输入参数运行。
  • 然后，验证算法的结果可用于触发其他链上活动。
下面的图片显示了从创建程序到使用zk-SNARK生成和验证证明的整个过程的摘要。

zk-SNARKs 的完整可信设置过程。资料来源：defi-learning.org
6. zkSBT的实施
我们已经经历了一个关于zk-SNARKs和SBT如何一起工作的高级例子。在这一节中，我们将通过一个微不足道的例子来说明一个项目如何实现zk-SNARKs和SBTs，以使交易方能够验证灵魂的属性。
假设一个信用借贷平台为一个用户铸造了一个SBT，并为该用户分配了一个信用分数。
该信用贷款平台希望允许其他交易方的项目来验证该用户的分数是否高于某个阈值。
我们可能如何能够创建这个？
这个应用有4个不同的部分。前端、后端、智能合约和电路。电路是与zk证明的生成和验证有关的主要组件，因此我们将更多地关注它。
6.1 电路创建
在我们使用zk-SNARKs之前，我们首先要把我们的程序规格转换成电路。对于电路的创建，我们使用IDEN3团队设计的circom2库。这个库已经被用于许多其他流行的应用程序，如龙卷风现金和Darkforest Eth.游戏。
例如，电路设计打算让用户铸造一个分配了信用分数的SBT，但其他人不知道信用分数是什么。然而，用户仍然可以证明他的信用分数高于阈值，并且他是有信用的。
简单地说，我们将设计一个简单的电路，如果用户的分数高于公共阈值，则返回 “真”，而无需让用户透露他的分数。


https://github.com/SpartanLabsXyz/zk-sbt/blob/master/circuits/demo/circuits.circom
我们在资源库中为不同的使用情况提供了其他的示例电路。项目可以考虑不同的电路，以满足其特定的限制。
https://github.com/SpartanLabsXyz/zk-sbt/tree/master/demo/circuits
关于电路设计的说明
zk-SNARKs中较难的部分是实现适当的电路约束，以确保程序的执行。如果电路实施不当，就可能被利用，而由于程序的零知识性质，这种利用很难被发现。
|什么是电路？
|电路指的是我们的约束条件被确定的程序。
| zk-SNARKs不能直接应用于任何计算问题。问题首先需要被转换为正确的形式。第一步是将程序转换为代数电路。
|更多信息请查看他们的文档（
https://docs.circom.io/background/background/#zero-knowledge-proofs）


A - B > 0，其中A是用户的秘密，而B是我们在验证算法中使用的阈值。
6.2 设置阶段
首先，信用贷款平台首先生成一个随机λ。在我们的例子中，我们使用tau的权力，这是一个可信的多方仪式的设置，以去中心化的方式生成随机λ。
请注意，存在不同的复杂程序来生成这个随机λ，因为至关重要的是，它保持未知，以防止任何人伪造他们的证明。
对于我们的应用，我们已经创建了一个例子脚本`execute.sh`来运行设置过程。
6.2.1 密钥生成
为了创建和检查证明，我们使用一个叫做SnarkJS的库，由Jordi Baylina和Iden3建立。SnarkJS使用你的电路来生成JavaScript和Solidity中的证明和验证代码，以及协议参数和证明和验证密钥。
证明密钥和验证密钥的例子：
https://github.com/SpartanLabsXyz/zk-sbt/tree/master/circuits/demo
6.3 证明生成阶段
“证明”是指用户为了证明自己的一个属性而生成的东西。
然而，在用户的输入属性被用作证明之前，它必须首先被转换为一个证人。
使用circom2库，我们可以通过以下命令轻松地生成证人
`node generate_witness.js circuit.wasm .../input.json witness.wtns`。
其中input.json是用户的输入，也就是用户的信用分数。
证明的生成可以在客户端的链外完成，它需要程序的输入（在电路中）、证人和证明的密钥。使用snarkjs和Groth16协议，我们可以用以下方式生成它
`snarkjs groth16 prove circuit_0001.zkey witness.wtns proof.json public.json`。
| Groth16是zkSNARK证明方案的一个具体实现。
一旦我们生成证明，我们就可以进入用户验证证明的阶段。
6.4 验证方案阶段
对于验证，我们是在链上进行的。使用`snarkjs`库，用户可以从提供的验证密钥中生成验证算法。然后，验证算法可用于使用`snarkjs`库生成一个solidity智能合约
在生成`Verification.sol`后，我们可以使用函数`verifyProof`来证明一个给定的SBT具有有效属性。
基本上`verifyProof`是一个函数，它接收一个哈希值和一个证明，并返回一个布尔值。


合约：
https://github.com/SpartanLabsXyz/zk-sbt/blob/master/contracts/Verifier.sol
6.4.1 项目如何在其SBT中使用Verifier.sol？
项目可以将验证器作为SBT合同中的一个接口，如函数`validateAttribute`所示。
这允许任何项目包括链上验证机制，用户只需要他们的证明和验证密钥来验证他们的属性。



https://github.com/SpartanLabsXyz/zk-sbt/blob/master/contracts/zkSBT.sol
验证属性
函数中的输入`a,b,c,inputs`是由snarkjs生成调用函数生成的参数。
`@param _soul`是灵魂的地址。`@param verifierAddress`是为Verifier.sol合约部署的地址。如果证明是有效的，该函数返回true，否则返回false。
6.4.1.1 风险：防止重放攻击
验证算法的风险之一是攻击者如何能够提交另一个用户的证明作为他们自己的证明，从而得到验证。项目必须注意到，这可能会发生。一些解决方案是添加检查或无效器，以防止攻击者提交其他用户的证明。
6.5 实施架构
简而言之，zk-SNARKs与Circom和Snarkjs的实现可以用下面的实现来概括。
用户可以在本地创建证明，然后上传简短的证明，以便在智能合约内进行恒定时间验证，其中计算成本很高。
整体架构可以在我们的资源库中查看，这里：
https://github.com/SpartanLabsXyz/zk-sbt#architecture
关于集成zk-SNARKs的步骤的更多信息，你可以参考我们的GitHub，或者更具体地说，用于生成所有算法和证明的脚本`execute.sh`。
https://github.com/SpartanLabsXyz/zk-sbt/blob/master/circuits/execute.sh
7. ZKSBT（zk-SNARK SBT）与反方灵魂的可组合性
在我们的例子中，我们把发布SBT的项目与可能要验证灵魂属性的对手方的角色结合起来。然而，对于SBT与其他可能想要验证用户SBT属性的对手方项目的可组合性，我们将不得不根据所使用的方法进行一些改变。
7.1 一体化的方法：SBT发行者承担责任
在SBT中的数据是直接的情况下，SBT发行者可能想生成他们自己的lambda、证明密钥和验证密钥。然后他们可以提供一个接口，允许交易方项目验证用户的属性。
这样做的好处是可以使SBT容易被采用，因为其他项目可以利用现有的验证机制而不需要生成和存储他们自己的lambda。
然而，如果SBT内的数据是多样的，并且存在几个不同的程序C，旨在证明SBT的不同属性，这可能是不可行的。
7.2 多重方法：每个项目都承担责任
各个交易方项目将负责生成lambda、证明密钥和验证密钥，而不是SBT发行人或集中式机构。然后，密钥和验证方法将通过项目的应用程序分发给用户。
然而，SBT发行者应提供包含特征的SBT数据结构的明确文件，同时保持数据的私密性。
这种策略可能适合于那些不想为保证其秘密而承担全部责任的SBT发行者。此外，如果需要对SBT内的数据进行多次证明，可能需要多个验证程序，每个程序都有自己的证明和验证密钥。
此外，这种策略消除了对中央机构的依赖，而是将确保证明的有效性的责任放在项目本身。
然而，这种策略将要求每个项目根据被测试的属性开发自己的生成、证明和验证算法。
8. 结语
综上所述，上面章节是关于如何使用zk技术使SBT真正私有化以及项目如何在solidity中实现zkSBT的入门文章。
SBT允许社会身份与无信任的可组合性的整合，如果做得好，可以改变Web3生态系统的未来。信任和所有权的核心方面可以在链上增强智能合约世界的社会可组合性，这可以为去中心化的应用打开许多可能性。
在这个系列的《灵魂的构建》中，我们阐述了我们对SBT的愿景，它们的潜在用例，以及如何实现它们的关键功能。我们已经勾勒出了SBTs的设计原则和实现方式，但我们的工作才刚刚开始。
未来的一个重要研究方向是对不同种类的数据权限的确切限制进行范围划分，对保持数据隐私的具体技术组合进行研究，以及在SBTs之上可以建立的产品，以创造一个 “假名经济”。
让我们用SBT带来的社会经济一体化为Web3建立一个更好的未来吧! LFB!
我们将在下周发布zkSBTs的端到端演示，使用我们在本次会议中所经历的代码。敬请关注!

【声明】内容源于网络
0
0
FastDaily
日更新闻
内容 2683
粉丝 0
FastDaily 日更新闻
总阅读593
粉丝0
内容2.7k