如何利用區塊鍊和智能合約技術構建出十億用戶的Web3 社交圖譜？
隨著埃隆- 馬斯克最近接管了Twitter，關於從大型社交網絡遷移到獨立或開放的替代方案的討論已經越來越多，但是所有那些剛開始幻想在加入繁榮的Twitter 前居民社區的人，很快就會遇到自J6 之後的跨平台社交媒體大清洗以來，右派一直在努力解決的問題：網絡鎖定是真實的。
你可以對協調問題、偏好級聯、信號和其他遊戲理論式的概念進行理論和策略分析–我不否認這些都是理解問題的有用方法–但要理解Twitter 和Facebook 對我們數億人的強大影響，你真正需要知道的是網絡時代初期的一個簡單啟發式方法
梅特卡夫定律指出，電信網絡的價值與系統的連接用戶數的平方成正比（n2）。梅特卡夫定律最初是由George Gilder 在1993 年以這種形式提出的，並歸功於Robert Metcalfe 在以太網方面的工作。大約在1980 年，梅特卡夫定律最初不是以用戶為單位，而是以「兼容的通信設備」（如傳真機、電話）為單位。只是後來隨著互聯網的全球化，這一定律才延續到了用戶和網絡，因為它的初衷是描述以太網連接。
要讓人們放棄一個大的、密集的網絡圖，而選擇一個小的、稀疏的網絡圖，幾乎是不可能的，唯一的原因是前者有價值，而後者沒有。
不過奇怪的是，web3 解決了這個問題。或者至少如果我們使用一些簡單的智能合約，將區塊鏈從一個巨大的用戶表變成一個巨大的社交圖譜，它可以解決這個問題。
理論依據和以往的工作
區塊鏈可以而且確實作為一個巨大的、共享的用戶表發揮作用，它是開放的、公開的，不受任何一個實體控制。正如我在《十億用戶表》中寫的那樣：
公共區塊鏈相當於整個互聯網的一個單一的、大規模的用戶表，下一波分佈式應用將建立在它之上。
取而代之的是一個由API 連接的分散的用戶數據倉網絡，一個通過開放協議和分散的存儲節點網絡訪問的單一分散的用戶數據存儲。因此，身份託管區塊鏈代表了數據存儲實施層的去中心化，以及數據存儲訪問層的再中心化。
想像一下，LinkedIn、Reddit 和Github 都將他們的用戶表（以及他們的許多專有數據，如認可、積分和活動歷史）移植到BitClout。馬上就會發生以下情況：每個Github 用戶也是Reddit 用戶、LinkedIn 用戶和BitClout 用戶。同樣，每個Reddit 用戶也是Github 用戶、LinkedIn 用戶和BitClout 用戶。我可以繼續說下去，但你會明白這一點。
每個建立在同一虛擬用戶表上的公司都能立即獲得該表上其他每家創業公司的網絡效應。每當一個鏈上公司加入一個新的用戶，那麼你的服務也有一個新的用戶。( 從某種程度上說。他們可能還沒有積極使用你的服務，但他們實際上在你的服務的潛在用戶）。
先前的那篇文章用Bitclout（該項目中的鏈現在被稱為DeSo）作為可以支持這種用例的區塊鏈的典型例子。但是，儘管我對DeSo 的整個事情感到興奮，但它的結果並不那麼好。
這裡不適合做Bitclout / DeSo 的事後總結，但標出該區塊鏈的一個方面是有意義的，因為它對現在的討論很重要。Bitclout 努力將整個社交網絡放在鏈上，每個帖子都被寫在鏈上，作為一個對象，可以累積收入（通過Bitclout 鑽石）。這很聰明，但任何試圖承載實際內容的區塊鏈都會看到其數據需求隨著用戶和連接的數量而非線性增長。
Bitclout 團隊非常熟悉這種無限制的數據增長問題，並花費了大量的實際工程努力來解決這個問題。但事後看來，我實際上認為他們試圖同時做太多的事情。他們應該只專注於社交圖的可移植性問題。
用我之前文章中的數據庫術語來描述，Bitclout 試圖把以下所有的表都放在鏈上（另外還有一些是Bitclout 特有的）：
- 用戶
- user_follows_user
- 帖子
- user_likes_post
最後兩張表總是出現數據爆炸，在用戶迅速增長的情況下都會變得不容易操作。
因此，我認為更好的方法是採用現有的區塊鏈，它基本上已經是那個第一張表（即用戶），並在其中添加一個user_follows_user 連接表。( 我們還可以為其他類型的關係擴展連接，如user_mutes_user，但目前我們還是保持簡單的。)
這個用戶對用戶的連接表也會隨著用戶數量的增加而非線性增長，但增長速度會比較慢，更重要的是，為了表示它所需要的額外數據量（=它所消耗的額外塊空間量）將遠遠低於帖子表。
我這樣建議是因為用戶和粉絲關係構成了每個大型社交網絡平台鎖定的主要來源。如果你的整個Twitter 或Facebook 的社交圖譜都是開放的，並且可以隨時提供給其他想要託管帖子和其他更多數據密集型的社交網絡體驗的社交平台，那麼這些平台的鎖定性基本上為零。
鏈上社交圖譜可能是怎樣的
想像一下，我的整個推特圖是在鏈上體現的–包括實際的賬戶和追隨者關係。為了查看該圖中的Twitter 帖子（以及相關的喜歡、轉發、引用- 轉發等），我需要用我的錢包連接到Twitter.com。但是，假設我想跳轉到tribel.com，或gab.com，或其他一些有自己特殊傾向和節制政策的社交平台–如果他們能從區塊鏈上讀取我的社交圖譜，那麼我可以在那裡連接我的錢包，看到同樣的連接，並看到他們在這個其他網站上的任何帖子。
這聽起來可能沒那麼有吸引力，但考慮到這樣一個事實：如果我在Tribel 上關註一個新的人，那麼我現在也在Twitter 和Gab 上關注這個人–以及在其他所有使用相同鏈上圖的用戶和關係的社交平台上。取消關注和屏蔽的工作方式也一樣–在一個地方做一次，你的圖譜的變化就會立即反映在所有地方。
現在，那些在閱讀時想利用這一點的已經意識到，在一個如上所述的世界中，將不可避免地發生什麼：有人會製作一個全能客戶端，讓你通過一個界面從任何或所有這些網絡中閱讀和發布信息。那麼，擁有獨立的服務就沒有意義了，他們都會倒閉……或者他們會嗎？
未來事物的預演：電話號碼+ 聯繫人+ 消息應用程序
我所描述的世界已經以一種原型狀態存在，以競爭性信息協議的形式存在，這些協議都與你的電話號碼相聯繫，並從你的聯繫人數據庫中填充自己。電話號碼系統是億萬用戶表的原型，而分佈式的聯繫人應用程序都可以讀寫標準的Vcard 格式，構成了建立在該表之上的關係圖。
有許多信息傳遞協議都是藉助於這種電話號碼+ 聯繫人的組合，其結果有點像我在這裡描述的社交網絡。例如，當你第一次登錄Telegram 時，它會掃描你的聯繫人，然後你立即在這個新的應用程序中擁有你現有的網絡。
其結果是，你可以選擇通過Signal、Telegram、WhatsApp、iMessage 或傳統短信與相同的電話號碼交換信息–這一切都在於你和你的網絡中的其他人想使用哪種信息協議。
還有一個永恆的循環，就是消息應用的去中心化和再中心化，這從ICQ 時代就開始了，在WhatsApp / Signal / Telegram / Facebook / 等的時代仍然在發生。你可以找到任何數量的多合一消息客戶端，在一個窗口中支持許多這些平台。
這些信息應用都沒有受到損害，因為它們都從同一個開放的電話號碼系統和可互操作的聯繫人應用和服務生態系統中獲取身份–它們都共存並帶來不同的東西，而且我們中的許多人在它們之間切換，與我們聯繫人中具有不同需求和偏好的不同子圖交談。如果我們把社交圖譜移到鏈上，我希望這種動態會持續下去。
關於可組合性和社交關係
不同的平台有不同類型的社交連接，用戶可以相互之間的連接。Facebook 有朋友、關注和屏蔽。Twitter 有關注、靜音和屏蔽。這些對於這些平台來說是很好的，但我們可以改進它們，使它們更適合區塊鏈，使它們更具有可組合性。
可組合性是一個計算機科學術語，大概意思是，你可以混合和匹配這些小的、離散的、明確定義的工具，以獲得不同的效果和功能。
考慮到Facebook 的「朋友」–這是它自己的連接類型，但它也意味著「關注」，因為當你把某人加為好友時，你會自動關注他們。在Twitter 上，「封殺」意味著「靜音」，因為當你屏蔽某人時，你基本上是在讓他們靜音，同時也阻止他們看到你的帖子。
對於我自己的兩個社交圖譜的建議，下面，我想建議跟隨，更乾淨和可組合的社交圖譜關係集：
- 關注：你可以閱讀你所關注的人的帖子。
- 靜音：你不能閱讀你已經靜音的人的帖子。
- 屏蔽：你屏蔽的人不能閱讀你的帖子。
在這個方案下，一個封殺是一個「靜音」加一個「屏蔽」，所以它是對同一個目標地址的兩個操作，一起組成的（例如，如果我想封殺annoyinghater.eth，我就把這個地址靜音，再把它的屏蔽）。
如果我想看到某人的帖子，但又不想讓他們看到我自己的帖子，我可以關注他們，再加上屏蔽。或者，如果我想保留通過導航到他們的內容或定期取消他們的靜音來閱讀，我可以關注加靜音。
我試圖以這種方式理清關係，因為它使我們更容易推理接下來的章節中的合約和關係。
我的兩項提案的一些背景
在本文的其餘部分，我提出了兩個將社交圖譜分層到十億用戶表中的建議。
- 第一種，On-Chain Graph（OCG），更加開放和簡單，但在費用方面也更加昂貴，所以有些人會喜歡它，有些人不會。
- 第二種，鍊式圖（CLG），更複雜但更便宜，而且提供更多的控制和隱私，所以我預計大多數人會更喜歡它。不過，平台可以同時支持這兩種方式。
要真正理解這兩個提案，你需要對以下概念有一些基本的熟悉：
- 不可拆分的代幣（NFT）和不可拆分不可轉讓的代幣（NTFT，也叫靈魂綁定的代幣）。
- 以太坊域名服務
- 智能合約
了解一點Solidity（以太坊的智能合約編程語言）也會有所幫助。如果你對上述一項或全部內容模糊不清，我試圖以一種你應該仍然能夠掌握基本知識的方式來寫這篇文章。
對於這兩個提案，我假設我們使用ENS 作為身份的根，並向其添加新的地址記錄，其中包含一些相當標準的ERC721 NFT 合約的地址，這些合約分別代表我上面概述的三種類型的社交關係（跟隨、靜音、屏蔽）。這三個合約的作用從一個提案到另一個提案都非常不同，但把它們的地址放入三個特殊的ENS 地址記錄的基本想法保持不變。
我還想為社交用戶數據URI 提出一個額外的ENS 記錄，這樣你就可以更新你的社交數據而不需要消耗gas。一個擬議的profileURI 記錄將鏈接到一個藏在某些第三方平台上的JSON 對象，看起來像這樣：
捲曲 https://jonstokes.com/jons-profile.json
-H“接受：應用程序/json”
{
“name”: “jonstokes.(eth|com)”,
“bio”: “作家。編碼器。末日技術樂觀主義者。密碼學兄弟。”,
“網站”：“https://jonstokes.com/”，
“位置”：“德克薩斯州奧斯汀”
}
檔案JSON 中的一些內容與現有的ENS 字段是多餘的，但這沒關係；這樣做的目的是為了給社交平台提供一些可以顯示的東西，並讓用戶能夠對他們的社交檔案進行修改，而無需花費gas 來更新ENS 記錄。
建議1：鏈上圖
On-Chain Graph 的想法使用NTFT 來表示上述的三種關係。對於以下三個社交合約，持有ENS NFT 的同一個錢包也應該擁有這些合約，它們的三個對應的ENS 地址記錄應該指向這些合約：
- OCG 追隨者：當你從我的OCG 追隨者合約中存入一個NTFT 到你的錢包，那麼你就跟隨了我。我們中的任何一個人都可以銷毀這個NFT，使你取消對我的關注。
- OCG 屏蔽：當我從我的OCG Ghosted 合約中空投一個NTFT 到你的錢包中時，我就對你產生了屏蔽。只有我可以銷毀這個NTFT 來解除對你的困擾。
- OCG 靜音：當我從我的OCG 靜音合約中空投一個NTFT 到你的錢包時，我已經把你靜音了。只有我可以銷毀這個NTFT 來解除你的靜音。
這三種情況的語義基本上都是：「相對於我，即合約所有者，你是X」，其中「X」是追隨者、屏蔽、靜音的一種。
這裡有一個追隨者合約樣本：
// SPDX 許可證標識符：MIT
pragma solidity ^0.8.4;
導入“@openzeppelin/contracts/token/ERC721/ERC721.sol”；
導入“@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol”；
導入“@openzeppelin/contracts/security/Pausable.sol”；
導入“@openzeppelin/contracts/access/Ownable.sol”；
導入“@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol”；
導入“@openzeppelin/contracts/utils/Counters.sol”；
合約 OCGFollower 是 ERC721, ERC721Enumerable, Pausable, Ownable, ERC721Burnable {
將計數器用於 Counters.Counter；
Counters.Counter private _tokenIdCounter;
構造函數（）ERC721（“OCGFollower”，“OCGF”）{}
function _baseURI() internal pure override returns (string memory) {
返回“https://jonstokes.com/ocg/follower”；
}
函數關係（）公共{
返回“ocg 追隨者”；
}
功能暫停（）公共onlyOwner {
_暫停（）;
}
函數 unpause() public onlyOwner {
_unpause();
}
功能safeMint（地址）公共{
//防止除所有者之外的任何人鑄造
//他們不擁有的地址的令牌。
require(isOwner(_msgSender()) || (_msgSender() == to), “無法鑄造到這個地址”);
uint256 tokenId = _tokenIdCounter.current();
_tokenIdCounter.increment();
_safeMint(to, tokenId);
}
function _beforeTokenTransfer(address from, address to, uint256) pure override internal {
//禁用令牌傳輸。
require(from == address(0) || to == address(0), “無法轉移。”);
}
// 以下函數是 Solidity 所需的重寫。
函數支持接口（bytes4 interfaceId）
民眾
看法
覆蓋（ERC721，ERC721Enumerable）
回報（布爾）
{
返回 super.supportsInterface(interfaceId);
}
}
如果你熟悉Solidity，你可以看到這個非常簡單（而且未經測試！）的合約試圖做什麼。
首先是擴展：
- ERC721Enumerable 擴展被包括在內，因此代幣持有者可以被社交網絡客戶端列出來，而不必掃描整個鏈。
- 我使用Pausable 是因為你應該能夠暫停造幣，以便基本上鎖定你的賬戶一段時間，即停止接受新的粉絲。
- Ownable 是必不可少的，因為有些事情只有合約所有者應該做。我認為沒有必要使用更強大的角色功能。
- ERC721Burnable 在這裡，因為你需要能夠銷毀代幣，以便刪除關注關係。這裡麵包含的標準burn() 函數有我們需要的權限，即只有所有者或令牌所有者可以銷毀代幣。
- 我包含了Counters，這樣tokenID 就會自動遞增，這很方便。
現在對OpenZeppelin 嚮導的輸出進行修改：
- safeMint() 被修改後，只有合約的所有者可以將代幣鑄幣到其他人的地址。對於所有非所有者，你只能向你調用合約的地址鑄幣。
- _beforeTokenTransfer() 被重寫，這樣它就基本上禁止了轉讓代幣的能力，創造了一個簡單的靈魂綁定的代幣。
- relationship() 函數是一個方便的方法，確保有一個簡單的方法來查詢合約並確認NFT 代表什麼樣的關係。我並不贊成包括這個，但它似乎很有用。
這一切真的很簡單，對於OCG 的屏蔽和OCG 的靜音變體，你要做以下小改動：
- 改變合約名稱和符號
- 改變relationship() 和可能的baseURI() 的返回值，以反映你所代表的關係（即，「muted」或「ghosted」）。
- 把safeMint() 和burn() 都變成onlyOwner 函數，這樣只有合約所有者可以調用這兩個函數。
顯然，這將取決於平台是否以正確的方式履行這些合約（即關注、屏蔽、靜音）。不過，這沒有聽起來那麼有威脅性和不穩定，因為如果一個特定的社交平台不履行你所關心的合約，就不要使用它。
增加付費關注
你可以在safeMint 中加入payable，然後使用setMintRate 來設定人們必須為以下內容向你支付的價格。因此，類似於這樣的內容：
uint256 public mintRate = 0.01 以太；
函數 setMintRate(uint256 mintRate_) public onlyOwner {
mintRate = mintRate_;
}
function safeMint(address to) public payable {
// 需要付費關注
require(msg.value >= mintRate, “沒有足夠的以太幣來鑄造”);
//防止除所有者之外的任何人鑄造
//他們不擁有的地址的令牌。
require(isOwner(_msgSender()) || (_msgSender() == to), “無法鑄造到這個地址”);
uint256 tokenId = _tokenIdCounter.current();
_tokenIdCounter.increment();
_safeMint(to, tokenId);
}
我相信我還能想到許多其他的調整和功能來添加到這個建議中，但最好從簡單和容易理解的東西開始。
建議2：鍊式連接圖
上面描述的OCG 合約足夠簡單，但該方案有一些特質，可能會使很多人產生分歧：
- 所有的東西都是公開的，在鏈上的，包括屏蔽和靜音。你不能這樣做鎖定賬戶，但解決這個問題的辦法可能是使用一個替代賬戶。
- 每一個行動都要花費gas，這意味著你必須對你關注的人、屏蔽和靜音做出真正的選擇。但如果gas 費用足夠高，那麼這可能會使網絡無法使用。
- 對於一個網絡或一個特定的賬戶來說，付費關注可能是也可能不是一個理想的功能，但你會有這樣的選擇。
鑑於不是每個人都會喜歡這個建議的這些特質，我想提出一套替代的社交合約，給用戶和平台更細化的控制，特別是誰能看到什麼樣的信息，而且使用成本更低。
鍊式鏈接圖（CLG）的基本思想：我們不通過NFT 直接在鏈上表示社交關係（關注、屏蔽、靜音），而是在鏈下存儲這些關係，並使用鏈上代幣來發現和訪問這些關係。
- 發現：該合約提供了一個listURI() 函數，該函數返回一個JSON 列表的鏈接，該列表中的ENS 名稱是你打算聲明某種社交關係的（即，我關注他們，我讓他們靜音，或者我屏蔽他們）。
- 訪問：如果listURI() 返回的鏈接是令牌控制的，那麼合約的令牌就會授予持有者對元數據中發現的鏈接的讀取權限。
那麼該社交關係就不是直接在鏈上的，而是通過一組合約和URL 與鏈相連。
與OCG 一樣，三種社交關係中的每一種都由智能合約來管理，但CLG 的語義不同：
- 關注：包含一個鏈接到你正在關注的ENS 名字的JSON 列表，由它發出的令牌授予對該關注列表的讀取權限。
- 靜音：包含一個鏈接到你正在靜音的ENS 名字的JSON 列表，由它發出的令牌授予對該靜音列表的讀取權限。
- 屏蔽：包含一個鏈接到一個你正在屏蔽的ENS 名字的JSON 列表，由它發出的令牌授予對該屏蔽列表的讀取訪問權。
因此，CLG 令牌的語義是：「這是對我X 賬戶列表的讀取權限」，其中「X」是「關注」、「靜音」或「屏蔽」。
你可以把我在這一節中提出的建議看作是我為信息應用描述的電話號碼+ 地址簿組合的一個近似物。你的電話號碼是（準）公開的，當你把一個新的消息應用程序連接到它時，你可以授予或拒絕該應用程序對你的聯繫人的讀取權限。
在我的CLG 社交令牌計劃中，你的ENS 名字就像你的電話號碼一樣是公開的，你發行和撤銷令牌，以便授予和拒絕閱讀與你有某種關係的人的名單。如果你願意，你可以把這些令牌授予隨機用戶，但主要是你要把它們授予社交平台，以便這些平台知道誰的帖子要顯示給你，誰的帖子要隱藏（或誰不應該看到你的帖子）。
( 對構成你的社交圖的列表的寫入權限可能由你正常的ENS NFT 控制–如果你的錢包裡有你的ENS 名字，你就可以對列表進行寫入/ 更新/ 刪除的修改。一個可能的替代方案是有第四個社交合約，授予NTFT 持有者列表寫入權限，這樣你就可以將列表管理外包給一些第三方）
在鏈下託管這些列表，同時從鏈上指向它們，有幾個好處：
- 你可以通過在託管列表的端點上使用認證來鎖定你的關係，不讓公眾查看。或者你可以讓它對公眾開放，這樣任何人都可以閱讀它。
- 更新一個鏈下列表不需要花費gas。
- 這個方案使得與社交供應商互通的社交圖譜託管服務市場得以建立。
- 任何人或服務都可以輕易發現你的列表。
代幣訪問控制和讀取訪問
實現CLG 合約的關鍵創新是代幣訪問控制。代幣訪問控制背後的概念是，除非你用含有特定訪問代幣的錢包連接到主機，否則你不能訪問主機上的特定數據。
例如，你可以對IPFS 上的內容進行代幣訪問控制，這樣只有用錢包中的特定NFT 連接到端點的讀者才能查看特定的文件。
CLG 使用令牌門為我們的社交合約增加了一些間接性，因此，社交NFT 不是代表一種特定類型的關係–關注、靜音或屏蔽–而是代表對你的社交圖譜的一部分的讀取權限。
很明顯，為了使代幣門檻發揮作用，平台必須尊重它。據推測，如果平台不尊重代幣訪問控制，你會把你的關係列表轉移到其他平台，並改變你的合約，必要時重新發布任何NFT。
另外，要清楚的是，有些人的名單在某些時候會洩露。我們生活在一個個人數據洩露的世界，所以如果數據被託管在某個地方，那麼有些數據就會被洩露。我將在後面的章節中討論一些可能的緩解措施。
合約範本：CLG Follows
下面的合約將是一個標準的ERC721 NTFT 合約，與上述OCG 的合約非常接近：
// SPDX 許可證標識符：MIT
pragma solidity ^0.8.4;
導入“@openzeppelin/contracts/token/ERC721/ERC721.sol”；
導入“@openzeppelin/contracts/security/Pausable.sol”；
導入“@openzeppelin/contracts/access/Ownable.sol”；
導入“@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol”；
導入“@openzeppelin/contracts/utils/Counters.sol”；
合約 CLGFollows 是 ERC721，Pausable，Ownable，ERC721Burnable {
將計數器用於 Counters.Counter；
Counters.Counter private _tokenIdCounter;
構造函數（）ERC721（“CLGFollows”，“CLGF”）{}
function _baseURI() internal pure override returns (string memory) {
返回“https://jonstokes.com/clgfollows/”；
}
函數 listURI() 公共 {
返回“https://jonstokes.com/clgfollows/list”；
}
函數關係（）公共{
返回“clg跟隨”；
}
功能暫停（）公共onlyOwner {
_暫停（）;
}
函數 unpause() public onlyOwner {
_unpause();
}
函數 safeMint（地址） public onlyOwner {
uint256 tokenId = _tokenIdCounter.current();
_tokenIdCounter.increment();
_safeMint(to, tokenId);
}
function _beforeTokenTransfer(address from, address to, uint256) pure override internal {
//禁用令牌傳輸。
require(from == address(0) || to == address(0), “無法轉移。”);
}
}
所有的擴展都與OCG 相同，只是我沒有包括ERC721Enumerable，因為不清楚是否有人想讓他們的CLG Follows 代幣被列舉出來（另外它提高了鑄幣的gas 成本）
至於函數方面，我對OpenZeppelin 嚮導的輸出做了以下修改：
- relationship()： 與OLG 一樣，它返回社交合約的類型。同樣，對於Solidity 合約來說，這可能沒有必要，我也沒有見過這樣做，但儘管如此，我覺得我想讓合約自我報告它的類型。所以我不知道–如果這冒犯了你，請忽略。
- listURI() 返回一個指向JSON 對象的鏈接，該對像是你正在關注（或靜音或屏蔽，取決於合約類型）的ENS 名稱列表。我們希望這個URI 能被標記為隱私，但這並不是必須的。
大多數情況下，你會使用CLG Follows NTFT，把它發佈到社交平台擁有的地址。這樣，該平台可以讀取你的關注列表，並向你展示正確的帖子。
但你也可以把這些NTFTs 發給追隨者，以便你的追隨者可以發現其他追隨者。你可以通過空投給追隨者，或者通過解禁造幣，讓任何人造幣來實現。
所有其他合約的工作方式與上述完全相同，但有不同的名稱和符號，並從relationship() 和listURI() 返回不同的值。
可能的變數
如果你擔心你的列表從不同的服務中洩漏，那麼把listURI() 變成更像tokenURI(uint256 tokenId) 的東西是非常直接的，即簽名是listURI(uint256 tokenId)，它把tokenID 連接到一個基本URI 的末尾，這樣每個token 持有者就可以得到自己的列表URL。這個功能與列表主機上的一些邏輯相結合，可以讓你把列表隔離開來，使不同的令牌持有者得到主圖的不同子圖。這樣一來，如果一個平台被擁有，那麼只有我的圖的那一部分被洩露了。
和OCG 一樣，你可以把safemint 變成一個可支付的函數，並向訪問你的列表的人收費。請看OCG 部分的代碼，以了解這個例子的情況。
你可能希望能夠更新tokenURI() 和/ 或listURI() 返回的URLs，在這種情況下，你需要將這些URLs 存儲在變量中，在構造函數中初始化它們，並為更新它們提供onlyOwner setter 函數。這將增加你的鑄幣成本，但如果你只打算把它們給服務而不是個人，這可能並不重要。
服務
這裡概述的兩個建議都提供了一些集中式託管服務的地方，即使它只是一個權宜之計，在生態系統過渡到像IPFS 這樣的分佈式系統之前。
最明顯的服務類型是託管由URI 功能之一返回的任何東西–配置文件數據、NTFT 元數據和代幣控制的JSON 列表（在CLG 的情況下）。
另一個有用的服務是一種專門的Infura 版本，通過API 暴露鏈上的社交數據。或者，Infura 可以為社交數據提供一個專門的API。
最後，可以有第三方服務來驗證賬戶，以滿足用戶和組織的需求。
總結
我不知道我是否期望我的鏈上社交圖譜建議會以我在這裡描述的形式被採納。我提出這些想法，更多的是為了引發對話，討論我們如何從目前完全鎖定平台的狀態有效地過渡到更便攜的狀態，即你擁有你的圖譜，並可以輕鬆地將它隨身攜帶。
上述內容有一部分看起來有點像web5 的提議，但關鍵的區別在於，我的兩個想法被設計得更簡單，並利用了智能合約和現有的鏈上身份提供者（ENS，但也包括其他鏈上的類似提供者）。
如果你從這篇文章中沒有其他收穫，我希望我至少已經說明，在一個分佈式賬本技術和智能合約的世界裡，我們任何人都沒有必要在2022 年被鎖定在一個社交網絡裡。解決這個鎖定問題的工具是廣泛存在的，我們只需要拿起它們並使用它們。
