文/Spartan Labs，標題：The Construction of the Soul Part 1: The ABCs of SBT
內容
1、什麼是SBT，為什麼它很重要？
1.1 Web3行業中的問題
1.2 SBT作為社會可組合性的解決方案
1.3 SBT用例
1.3.1 SBT的現實案例
2、Spartan Labs對SBT的願景
2.1 SBT的願景如何在現實世界中發揮作用?
2.2 第三方屬性驗證
2.3 交易方Souls（靈魂）對SBT的使用
3、SBT的主要特徵
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 靈魂（Soul）的發行和驗證
3.5.1 靈魂（Soul）的驗證
3.5.2 SBT數據的更新
3.5.3 SBT的發行
4、SBT的關鍵特性如何用於Web3 項目？
5、結論
1、什麼是靈魂綁定代幣？它為什麼如此重要？
V神是以太坊的聯合創始人之一，他與Glen Weyl和Puja Ohlhaver共同撰寫了名為《去中心化社會：尋找Web3的靈魂（Soul）》的白皮書，詳細描述了他們對完全去中心化社會（DeSoc）的願景，以及如何讓“靈魂綁定”代幣（SBT）從概念發展為現實。
1.1 Web3世界存在的問題
世界的經濟價值很大程度上是由人類及其相互依存的關係產生的。作為一個完全由數學和密碼函數運行的系統，Web3缺乏表示這種社會關係和身份的原語，導致Web3需要依賴其最初旨在顛覆的中心化Web2基礎設施。
信任和所有權的核心內容應該在鏈上，以增強智能合約世界中的社會可組合性，這可能為去中心化應用程序開啟許多可能性。
1.2 SBT是社會可組合性的解決方案
靈魂（Soul）被定義為持有SBT的錢包。 SBT是數字代幣，代表“靈魂（Soul）”的憑證、承諾和從屬關係。它可以將實體經濟的信任網絡編碼為鏈上聲譽和信用系統。
例如，在去中心化金融領域，如果像Aave這樣的借貸平台部署一個SBT，每個地址（靈魂）都可以有一個唯一的鏈上身份，從而實現基於信用評分的貸款。
這意味著，如果Aave部署了SBT，將允許Aave自身基於信用評分貸款，或允許其他Dapp進行整合。
信用評分現在是由信用局等政府實體機構集中掌控。
SBT之所以強大，是因為它去中心化了信用評分等基本概念。每個去中心化應用程序（Dapp）都被授權選擇他們信任的信用系統，形成自己的判斷，而不是僅僅因為信用局是持有此類信息的唯一實體而不得不信任它們。
更重要的是，SBT支持各種其他關鍵應用程序和用例，如社區錢包恢復、抗女巫攻擊治理、去中心化機制和具有可分解的共享權利的新市場。
1.3 SBT用例
使用SBT可能產生諸多影響。以下是V神合著的白皮書中強調的一些相關用例：
（1）驗證藝術家在NFT項目中的合法性。
（2）大多數NFT藝術家依賴於OpenSea和Twitter這樣的中心化平台以承諾藏品的稀缺性和來源。
（3）如果藝術家可以將他們的NFT項目與他們的SBT聯繫起來，SBT就可以幫助提供來源。
（4）通過聲譽開啟低抵押貸款市場。
（5）SBT可代表教育憑證、工作經歷和租賃合同而作為信用相關歷史的持久記錄，使靈魂（Soul）可以賭上有意義的聲譽，以避開抵押要求獲得貸款。
（6）減少對DAO治理的攻擊並改進治理協調。
（7）緩解女巫攻擊。
（8）動態領導分配。
（9）多樣性治理。
（10）創建具有可分解、共享權利的新市場。
（11）衡量去中心化。
1.3.1 SBT的真實用例
已有項目開始將SBT作為鏈上身份解決方案。
2022年8月19日，幣安準備推出幣安賬戶綁定（BAB）代幣，這是該公司基於其原生BNB鏈的靈魂綁定代幣或不可轉讓、非金融化的代幣版本。通過該平台的KYC程序驗證身份的用戶可以直接在其數字幣安錢包上鑄造SBT。 BAB將用作KYC的憑證，表明用戶身份已被驗證。第三方協議也可以利用BAB空投NFT和防止機器人攻擊。去中心化的自治團體也可以使用BAB來實現二次投票。
其他NFT項目也做出了嘗試與SBT整合。例如，Arc Community正在向社區成員發行其Pyxis NFT，作為鏈上識別和未來獎勵的一種方式。
2、Spartan Lab對SBT的願景
儘管V神的文章為SBT奠定了基礎，但SBT的關鍵特性、實現和用例還沒有被充分定義。在本節內容中，我們將概述我們對SBT的願景，以及不同的項目如何與該系統嵌入的社會信任進行協作。
我們設想了一個將聲譽系統與零知識（ZK）機制相結合的社會，以保護個人隱私。創造並推廣了“假名經濟”（pseudonymous economy）一詞的Balaji Srinivasan是對這一概念呼聲最大的支持者。
我們相信SBT可以在Web3世界裡整合假名經濟理念和社會可組合性。 SBT不僅為匿名個體可信的可組合性提供了額外機會，而且還支持跨項目、跨協議的互操作性，從而重塑我們目前的Web3生態系統。
2.1 SBT的願景如何在現實世界中發揮作用？
想像這樣一個世界，其中大多數參與者都擁有靈魂（錢包），存儲與各種關聯關係、成員資格和憑證相對應的SBT。或者每個人都可以有一個靈魂，存儲代表不同屬性的SBT，比如教育憑證、信用評分和成就。
2.2 第三方屬性驗證
如何驗證SBT中的屬性並將其鏈接到鏈上身份？
這些可信第三方驗證者的功能類似於認證機構（CA），其目的是驗證身份並將身份鏈接到數字證書。這些證書用於保護信息、加密數十億的交易，並實現安全通信。在簽發數字證書之前，CA會對申請人進行若干身份核驗。
在SBT的情況中，可能存在一個可信的去中心化第三方中介DAO，其利益與屬性的準確驗證保持一致。尋求SBT的個人可以向DAO支付初始驗證費用。在允許SBT數據鑄造之前，一個由DAO中不相關個體組成的小組會進行檢查核驗工作，驗證者將為自己的驗證工作收取相應費用。
2.3 對手方靈魂（Soul）的SBT用例
在最基本的SBT形式中，SBT中的數據可以由個人聲明，就像我們在簡歷中透露自己的信息一樣。然而，當一個靈魂持有的SBT可以由鏈接的對手方其他靈魂簽發或證明時，該系統的真正潛力便會凸顯。這些對手靈魂可以是個人、企業、機構或其他Web3項目。
對手方靈魂（Soul）可以向他們的用戶空投SBT。然後，用戶將與SBT項目交互，SBT項目會更新SBT數據。其他經授權許可的協議可以使用SBT來讀取和驗證個體的屬性。這使Web3項目具有社會可組合性，允許它們基於個體屬性實施不同的機制，例如允許屬於特定組織的地址使用其產品，或向經其SBT驗證的關鍵利益相關者授予更高級別的投票權。
例如，具有影響力的個體或機構可以作為一個靈魂向其長期支持者發行SBT。大學可以是一個靈魂，向畢業生髮放SBT。活動組織者也可以是一個靈魂，向活動參與者發放SBT。
在下一節中，我們將展示SBT的核心原理是如何從設計本身中自發產生的。
3、SBT的關鍵特性
目前對於SBT的關鍵特性還沒有正式的定義。為了將SBT推廣到Web3項目中，我們確定了SBT應該具備的重要品質。
3.1 不可轉移性
不可轉移性意味著SBT應該留在用戶的靈魂（錢包）中或被標記到用戶的地址。應該有嚴格的檢查來預防SBT的可轉移性。
但我們為什麼要讓它不可轉讓呢？
3.1.1 治理
SBT的可轉移性可能會導致治理問題。
（1）如果可轉移性的目的是使治理權力可以廣泛分配，將適得其反，因為中心化的利益方更傾向於從其他各方獲得治理權利。
（2）如果目標是將權力委託給有能力的領導者，那麼可轉移性也會適得其反，因為沒有什麼能阻止一個只有動機但無技能的人獲得治理能力。
3.1.2 身份
SBT代表個體身份。因此，防止冒名頂替是至關重要的。身份不應轉移，特別是在SBT包含敏感數據時。我們不希望出現這樣的情況，即有人可以通過在二級市場上獲得SBT而輕易獲得有利的屬性。
3.1.3 正確實施不可轉移性的重要性
正如V神在他的文章中所提到的，如果“天真地”實施不可轉移性，可轉移性問題依然會存在。例如，用戶可以輕易構建一個包裝賬號，保存SBT，然後出售賬號所有權。
預防可轉移性
所以，可能有必要進行其他檢查，例如檢查鏈上當前所有者是否與原始所有者處於相同的地址，在認為有必要的情況下，還會隨著時間推移進行更複雜的檢查。項目還可以要求SBT是原始的SBT，這可能會減少創建和利用包裝器的動機，此類包裝器旨在欺騙系統獲利。
3.2 不可替代性
SBT既可以是可替代的，也可以是不可替代的，因此對應的功能會有很大不同。
3.2.1可替代的SBT
可替換的SBT對於投票權和治理非常有用，在這種情況下，通過一種容易確定的方法來找出投票權可能非常重要。可替代靈魂的一個簡單實施用例是取消轉移代幣功能，與ERC20非常相似，除了合約或所有者本身有所不同。
3.2.2 不可替代的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）允許人們證明任意論斷，而無需透露論斷本身以外的任何信息。
零知識證明可以在SBT上計算，以證明靈魂的特徵（例如，具有某類成員資格），而不揭示具體特徵是什麼。
零知識證明通常應用於使用ZK-Rollup技術的L2中，如zkSync、Polygon Hermez和Scroll。
我們將在本系列的第二篇和第三篇文章中探討SBT中的隱私實現。
3.4 鏈下存儲
SBT數據可以存儲在鏈上或鏈下，這取決於項目的需要。如果存儲在鏈上，可以存儲在一個引用另一個地址的單獨合約中，也可以存儲在SBT合約本身中。
然而，在鏈上存儲數據的計算成本很高。因此，我們主張SBT的一個關鍵特性是集成鏈下數據存儲的能力，類似於ERC721 NFT存儲其鏈下數據的方式。這使得與SBT相關聯的數據成本更低，類型更豐富。
3.5 Souls的發行和驗證
SBT屬性的發行和驗證對於可組合性至關重要。
3.5.1Souls的驗證
SBT接口的設計應該使其他項目能夠輕鬆與用戶的SBT交互。對於其他Web3項目來說，設計一個鏈上機制來驗證用戶的屬性應該並不復雜。這意味著可以很容易在鏈上查詢和驗證靈魂的屬性。
如果SBT存儲在鏈下位置，那麼應該提出一個標準來說明其他項目如何根據鏈下存儲的數據結構來查詢數據。
如果SBT含有隱私數據，那麼應該有一種簡單的方法來（1）驗證用戶提供的URI，或者（2）證明用戶具有某個屬性，只暴露隱私本身的哈希值而不暴露URI，其參考了零知識技術的應用。
3.5.2 SBT數據更新
為了防止用戶偽造數據，只有合約所有者有權更新用戶的SBT數據。然而，項目應該使其能夠對其SBT數據提出修改建議。
3.5.3 SBT的發行
項目可以很輕鬆地向用戶發行SBT。這可以通過類似於鑄造NFT或空投的方式來完成。
4、SBT的關鍵特性如何在Web3項目中發揮作用？
假設一個項目想要有一個智能合約，該合約只允許擁有KYC信息的用戶與其交互。這個智能合約可以基於用戶數據的屬性執行不同的操作。其他項目應該能夠對用戶的鏈上數據進行驗證和執行操作。
然而，在區塊鏈上，一切都是匿名的，用戶只有他們的地址作為公開可驗證的屬性。
該項目可以考慮使用SBT作為鏈上識別和存儲用戶KYC數據的機制。
為了使用SBT機制，該項目可以採取以下行動。
（1）用戶提交他們的KYC信息，由現實世界的實體機構驗證。一旦該信息得到驗證，項目將為用戶生成SBT。用戶提供的信息被加密並存儲在鏈下。
（2）其他對手方項目也可以驗證用戶是經過KYC驗證的，具有一定的屬性，但並不知道用戶的具體信息。通過加密，這些鏈上KYC屬性是私有的。然而，用戶可以向這些對手方項目提供隱私信息，這為他們提供了查看和驗證鏈上私人信息的能力。
（3）用戶可以通過向主要負責項目提出變更請求來更新他們的鏈下信息。
在本系列的下兩篇文章中，我們將介紹項目如何實現這樣的SBT機制。
5、結論
SBT是基於聲譽的不可轉讓、不可替代的代幣，其數據只能由選定的各方訪問。將社會身份與去信任的可組合性結合起來，如果做得好的話，很可能會改變Web3生態系統的未來。
在本文中，我們列出了對SBT的願景、SBT潛在用例，以及應該為SBT實施的關鍵特性。我們已經草擬了SBT的設計原理，但一切才才剛剛起步。
在下一篇文章中，我們將基於本文討論的設計原理介紹SBT的實現。
