商量怎样建设十亿用户的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://jonst币安官网登录okes.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/E币安官网入口RC721Burnable.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