金色观察｜Spartan Labs研报：基础SBT以及隐私性SBT的实现

文/Yong Kang Chia和Jun Hao Yap，Spartan Labs，标题：The Construction of the Soul Part 2: Implementations of SBT

这是一个由三部分组成的系列文章，介绍SBT的根底常识、对SBT的愿景、其技能实施以及利用ZK技能的或许性。系列文章的方针是揭开SBT技能思想的神秘面纱，并供给一种完成来构建具有社会身份集成的Web3未来。第1部分评论什么是SBT及其基本特征（参看金色此前翻译文章“SBT根底常识和潜在案例全解析”）。第2部分评论其根底完成以及怎么运用SBT增加隐私。第3部分将评论怎么运用ZK技能来改进SBT隐私。

本文为其第2部分，将依据第一部分提出的规划辅导准则谈一谈SBT的完成。

内容

1、完成思路
1.1 与NFT的比较
1.2 根底SBT
→ 1.2.1 铸币和毁掉
→ 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、定论

1、SBT完成思路

在本末节内容中，咱们将评论SBT的完成及其利弊权衡。

1.1 SBT与NFT的比较

已然NFT和SBT听起来的确很类似，那么在详细完成方面，这些数据结构之间的要害区别是什么呢？

不行搬运性

与被规划为可买卖的NFT不同，SBT在本质上应该与魂灵绑定在一起，应该是不行搬运的。

隐私维护

NFT的数据是揭露的。可是，SBT项目或许期望保存其数据的私有性。

隐私能够经过各种不同办法完成。

可组合性

SBT的数据应该很容易被其他链上或链下项目读取。

以SBT特性为辅导准则，咱们在Solidity中完成了SBT。（https://github.com/SpartanLabsXyz/spartanlabs-contracts/tree/main/contracts/SoulBoundToken）

咱们将在下面末节内容中评论咱们的完成。

1.2 根底SBT

根底SBT能够作为模板供其他期望在SBT上构建的项目运用。根底完成不触及隐私方面的评论，隐私相关内容将在本文的第2节中打开。

1.2.1 铸造和焚毁

合约是这样规划的：铸造应由项目一切者把关。这是为了避免用户能够铸造任何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 Locker的潜在用例。

例如，当NFT在TimeLock.sol中被确定时，Locker或许依然期望“显现”他们的确具有这样一个确定的NFT。可是，从开发人员的角度来看，引证确定的NFT是很古怪的。因而，“魂灵绑定”代币能够表明出用户确定NFT的时刻，它们能够被答应进入“hallof fame”。在解锁时，一个不行搬运的包装代币需求被“燃烧”来解锁NFT，并且Locker将不再具有“hall of fame”方位。

1.2.6 SBT的隐私需求

可是，上述的根底SBT并没有考虑到隐私方面的需求。

正如在前一篇文章中说到的，web3的未来必将要与你的实在身份进行一定程度的集成。因而，链上集成后坚持个人身份的隐私是至关重要的，这样才能维护自己免受来自歹意行为者的损伤，比如，歹意行为者可检查区块链的公共数据，还原个人身份。

任何记录在链上的联系都能够立即被全世界的任何人看到，而不仅仅是参与者。经过相关SBT数据，歹意行为者能够从魂灵中还原用户的实在身份。

例如，假如人性证明得到更广泛的运用，维护隐私将变得愈加要害，由于另一种景象是，咱们所做的一切都将在链上直接与一张人脸相连。

2、SBT数据的私有存储

V神在其研究文章中提出了一些或许完成的具有隐私性的SBT，能够经过链上存储和链下存储来完成。

在本节内容中，咱们将评论SBT数据私有存储的或许完成办法。

2.1 链上存储数据，但要“哈希”地址

• 将数据项存储在一个地址中，该地址是以下数据的哈希值：（1）索引、（2）收件人地址和（3）专归于收件人的隐秘。

• 你能够向一个接口泄漏你的隐秘，然后它会搜索归于你的一切或许的数据项，但没有人会知道哪些详细项是你的，除非你自己泄密。

• 用户供给的隐秘将答应渠道找到与用户的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，NFT的数据一般也是存储在链下的。

不同之处在于，为了确保隐私，咱们首要有必要运用加密哈希函数（如SHA256）对URI字符串进行哈希。URI数据的哈希应该在链下完成，由于区块链上的一切数据都是揭露的，乃至是私有的状况变量也是如此。

为了避免暴力进犯辨认包括链下数据的链接，哈希值不应该仅仅是链接自身的哈希值。它可所以用户隐秘的函数，与链下数据存储链接，或许运用递归哈希或其他办法。这也被称为salting（加盐）。

下面是运用SHA256的Python完成示例：

这仅仅一个完成示例。还有许多其他办法能够含糊URI，例如随机附加隐秘、生成随机隐秘、peppering（加胡椒），以及运用专门为安全存储暗码而规划的其他算法。

然后运用数据的哈希值进行SBT的链上布置，而不是运用数据自身。

2.2.1 衔接链下数据与链上哈希链接

咱们怎样才能将链下数据与链上哈希链接衔接起来呢？

对合约一切者来说，一种或许的办法是将存储在链下方位的数据结构标准化。因而，SBT的一切者能够泄漏链下数据的链接，而项目（不一定与布置人员相同）能够哈希链接，以检查它是否与链上哈希值相同。假如哈希值相同，项目能够进行查询来检索存储在链下方位的数据。

为了维护用户的隐秘，对包括用户数据的链接的验证有必要由可信的、安全的第三方在链下完成。

2.2.2 链下隐秘危险

链下传输隐秘或许运用户暴露于缝隙和各种进犯之下。

项目有必要确保隐秘传输的安全，并避免常见的进犯，如回放进犯、中间人进犯和许多其他常见进犯。

一旦处理SBT检索的第三方的安全性遭到损坏，个人的隐秘就会揭露。

项目还应留意网络钓鱼进犯，由于用户或许会被提示在复制原始暗码的歹意网站上输入暗码。

此外，证明用户具有某种特点的仅有办法就是揭露隐秘。可是，为了创建SBT的匿名组合性，使不同的协议能够检索SBT数据，用户应该揭露必要的最小数据量。

假如项目所需的仅仅验证某个特点，那么用户不应该泄漏悉数隐秘。用户应该将他们的隐秘向尽或许少的项目发表。

因而，咱们需求考虑另一种办法，在这种办法中，项目能够验证用户具有某个特点，而用户则不会走漏他们的隐秘。

3、定论

在本文中，咱们根据本系列第1篇文章中介绍的规划辅导准则，介绍了SBT的完成。咱们完成了根底SBT以及具有链上和链下私有存储的SBT。可是，链下存储或许并不是真实的私有，由于用户将不得不揭露他们的隐秘，以证明他们具有某种特点。

ZK（零常识证明）技能的运用能够协助咱们减少用户的隐秘分享量，以坚持他们的SBT数据真实的私有性。这就引出了本系列文章的第3篇内容，在第3篇文章中，咱们将介绍运用zk-SNARK完成的SBT，在这种完成中，用户的隐秘能够坚持躲藏状况，避免受到各种办法的进犯。

此时快讯

【2022-09-23 14:52】【一些欧盟国家提议禁止向俄罗斯转移美元票据，并加强对加密货币相关交易的限制】9月23日消息，据报道，一些欧盟国家提议禁止向俄罗斯转移美元票据，并加强对加密货币相关交易的限制。（卫星新闻）