探討如何構建十億用戶的Web3社交圖譜

如何利用區塊鏈和智能合約技術構建出十億用戶的 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 特有的）：

• users

• user_follows_user

• posts

• 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 對象，看起來像這樣：

curl https://jonstokes.com/jons-profile.json

-H "Accept: application/json"

{

"name": "jonstokes.(eth|com)",

"bio": "Writer. Coder. Doomer Techno-Optimist. Cryptography Brother.",

"website": "https://jonstokes.com/",

"location": "Austin, TX"

}

檔案 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-License-Identifier: MIT

pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";

import "@openzeppelin/contracts/security/Pausable.sol";

import "@openzeppelin/contracts/access/Ownable.sol";

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";

import "@openzeppelin/contracts/utils/Counters.sol";

contract OCGFollower is ERC721, ERC721Enumerable, Pausable, Ownable, ERC721Burnable {

using Counters for Counters.Counter;

Counters.Counter private _tokenIdCounter;

constructor() ERC721("OCGFollower", "OCGF") {}

function _baseURI() internal pure override returns (string memory) {

return "https://jonstokes.com/ocg/follower";

}

function relationship() public {

return "ocg follower";

}

function pause() public onlyOwner {

_pause();

}

function unpause() public onlyOwner {

_unpause();

}

function safeMint(address to) public {

//Prevent anyone but the owner from minting

//a token to an address they don't own.

require(isOwner(_msgSender()) || (_msgSender() == to), "Unable to mint to this address");

uint256 tokenId = _tokenIdCounter.current();

_tokenIdCounter.increment();

_safeMint(to, tokenId);

}

function _beforeTokenTransfer(address from, address to, uint256) pure override internal {

//Disable token transfers.

require(from == address(0) || to == address(0), "Cannot be transferred.");

}

// The following functions are overrides required by Solidity.

function supportsInterface(bytes4 interfaceId)

public

view

override(ERC721, ERC721Enumerable)

returns (bool)

{

return 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 ether;

function setMintRate(uint256 mintRate_) public onlyOwner {

mintRate = mintRate_;

}

function safeMint(address to) public payable {

// Require pay-to-follow

require(msg.value >= mintRate, "Not enough ether to mint");

//Prevent anyone but the owner from minting

//a token to an address they don't own.

require(isOwner(_msgSender()) || (_msgSender() == to), "Unable to mint to this address");

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-License-Identifier: MIT

pragma solidity ^0.8.4;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

import "@openzeppelin/contracts/security/Pausable.sol";

import "@openzeppelin/contracts/access/Ownable.sol";

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";

import "@openzeppelin/contracts/utils/Counters.sol";

contract CLGFollows is ERC721, Pausable, Ownable, ERC721Burnable {

using Counters for Counters.Counter;

Counters.Counter private _tokenIdCounter;

constructor() ERC721("CLGFollows", "CLGF") {}

function _baseURI() internal pure override returns (string memory) {

return "https://jonstokes.com/clgfollows/";

}

function listURI() public {

return "https://jonstokes.com/clgfollows/list";

}

function relationship() public {

return "clg follows";

}

function pause() public onlyOwner {

_pause();

}

function unpause() public onlyOwner {

_unpause();

}

function safeMint(address to) public onlyOwner {

uint256 tokenId = _tokenIdCounter.current();

_tokenIdCounter.increment();

_safeMint(to, tokenId);

}

function _beforeTokenTransfer(address from, address to, uint256) pure override internal {

//Disable token transfers.

require(from == address(0) || to == address(0), "Cannot be transferred.");

}

}

所有的擴展都與 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 年被鎖定在一個社交網絡裏。解決這個鎖定問題的工具是廣泛存在的，我們只需要拿起它們並使用它們。

原文標題：《The Billion User Social Graph》

撰文：Jon Stokes

編譯：Dan，W3.Hitchhiker

來源：panewslab

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

---

標題：探討如何構建十億用戶的Web3社交圖譜

地址：https://www.torrentbusiness.com/article/30424.html

標籤：