当前位置:币圈 > 资讯 >

财经观察|Spartan Labs研报:基础SBT与隐私性SBT的达成

来源: www.cisue.com时间:2022-09-24 17:52

文/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 存储星际文件系统 等第三方提供商的链下项目
→ 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的数据存储在链下,由星际文件系统作为提供方。在大家的达成中,链下存储的URI可以与数据结构“Struct Soul”中的标识符相结合。

4zGOhj3OaG5YMTyE0lVUDBGt9UbvRlZ3fIWzHTQk.png

项目可以依据他们是想在链下还是链上存储SBT属性来调整建议结构。

1.2.3 SBT属性验证

其他买卖对手项目应该可以轻松检索SBT数据。

这对于想要验证用户SBT属性的买卖对手来讲非常有用。其他项目将可以查验一个地址是不是绑定了灵魂,并验证该灵魂所包括的属性。

这对于SBT与不同项目的可组合性尤为重要,其他项目可能期望进行交互并验证用户的属性。但,用户和项目可能不期望公开数据,有一些办法是可以保护数据隐私的。

1.2.4 SBT数据的更新

大家不期望用户或其他方更新灵魂,大家期望由经许可的权威方来更新,由于大家期望对数据的更改能得到验证。

由项目来达成合约,如此用户可以在链下建议对灵魂的更改,再由项目来验证更改是不是有效并更新链上更改内容。

ALmzjEzjEZRuXuMDSeCbNh6IyyA9T3i6FPru0Pyu.png

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)。它是通过对数据和共享密钥运行加密哈希函数获得的消息身份验证码。

为何这个办法会奏效?ETH地址由Keccak -256散列生成,并以十六进制数表示。Keccak -256散列的最后20个字节用于生成地址。

由于一个十六进制数是4位,所以大家将Keccak 256散列的最后40位作为大家的地址。大家可以在这个地址部署大家的项目。

但,请注意,带有隐私数据的哈希应该在链外实行,由于区块链上的所有内容(包含私有状况变量)都是公共的。

因此,在进行部署或铸造时,应该只提供哈希值,而不提供隐私数据。

rOOtYEVAVNqfK4TjBGrWUyX7hiJtCoqqnEOjmXjk.png

(上图为怎么样在一个特定地址上进行用户隐私数据布署)

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 用第三方提供方如星际文件系统,链下存储数据项

正如上一节提到的,把大部分数据存储在链上本钱太大。因此,更好的办法是将数据链下存储在第三方平台(如星际文件系统或其他云服务)上。这种在链下存储数据的办法很像NFT,NFT的数据一般也是存储在链下的。

DzgGUr4TClyv6tJBnr381HN2xrBLflgyxpYOZ0kb.png

区别在于,为了确保隐私,大家第一需要用加密哈希函数(如SHA256)对URI字符串进行哈希。URI数据的哈希应该在链下完成,由于区块链上的所有数据都是公开的,甚至是私有些状况变量也是这样。

为了预防暴力攻击辨别包括链下数据的链接,哈希值不应该只是链接本身的哈希值。它可以是用户秘密的函数,与链下数据存储链接,或者用递归哈希或其他办法。这也被叫做salting(加盐)。

下面是用SHA256的Python达成示例:

8gTuiuAL2DqA5OVQNgWxe6zm9Xgw8VEa2gJndsew.pngr2r5eOCP4rz7PfiWJYV3PvIu4IM1zWfqiWkqElBj.png

这只不过一个达成示例。还有很多其他办法可以模糊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,在这种达成中,用户的秘密可以维持隐藏状况,预防遭到各种方法的攻击。

标签: SBT

免责声明:

1.本文内容综合整理自互联网,观点仅代表作者本人,不代表本站立场。

2.资讯内容不构成投资建议,投资者应独立决策并自行承担风险。

相关百科知识