探讨如何构建十亿用户的Web3社交图谱

WB3交流加微信:WX-93588,⬅️此处为全站广告位,与正文项目无关
注册并登录App即可领取高达 60,000 元的数字货币盲盒:点击此处注册OKX

怎么运用区块链和智能合约技能构建出十亿用户的 Web3 交际图谱?

跟着埃隆 – 马斯克最近接管了 Twitter,关于从大型交际网络迁移到独立或敞开的代替计划的评论现已越来越多,但是一切那些刚开端幻想在参加昌盛的 Twitter 前居民社区的人,很快就会遇到自 J6 之后的跨渠道交际媒体大清洗以来,右派一直在尽力处理的问题:网络确定是实在的。

评论构建十亿用户的Web3 交际图谱两种方法:链上图和链式图

你能够对协调问题、偏好级联、信号和其他游戏理论式的概念进行理论和战略剖析–我不否认这些都是了解问题的有用方法–但要了解 Twitter 和 FaceboOK 对咱们数亿人的强壮影响,你真正需求知道的是网络时代初期的一个简略启发式方法

要让人们放弃一个大的、密集的网络图,而挑选一个小的、稀疏的网络图,几乎是不或许的,唯一的原因是前者有价值,而后者没有。

不过奇怪的是,web3 处理了这个问题。或许至少假如咱们运用一些简略的智能合约,将区块链从一个巨大的用户表变成一个巨大的交际图谱,它能够处理这个问题。

理论依据和以往的工作

区块链能够并且的确作为一个巨大的、同享的用户表发挥效果,它是敞开的、揭露的,不受任何一个实体操控。正如我在《十亿用户表》中写的那样:

先前的那篇文章用 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 的交际图谱都是敞开的,并且能够随时供给给其他想要保管帖子和其他更多数据密集型的交际网络体验的交际渠道,那么这些渠道的确定性根本上为零。

链上交际图谱或许是怎样的

评论构建十亿用户的Web3 交际图谱两种方法:链上图和链式图

想象一下,我的整个推特图是在链上体现的–包含实践的账户和追随者联系。为了检查该图中的 Twitter 帖子(以及相关的喜爱、转发、引证 – 转发等),我需求用我的钱包衔接到 Twitter.com。但是,假设我想跳转到 tribel.com,或 gab.com,或其他一些有自己特别倾向和节制方针的交际渠道–假如他们能从区块链上读取我的交际图谱,那么我能够在那里衔接我的钱包,看到同样的衔接,并看到他们在这个其他网站上的任何帖子。

这听起来或许没那么有吸引力,但考虑到这样一个现实:假如我在 Tribel 上重视一个新的人,那么我现在也在 Twitter 和 Gab 上重视这个人–以及在其他一切运用相同链上图的用户和联系的交际渠道上。吊销重视和屏蔽的工作方式也相同–在一个当地做一次,你的图谱的变化就会当即反映在一切当地。

现在,那些在阅览时想运用这一点的现已意识到,在一个如上所述的国际中,将不行避免地产生什么:有人会制作一个万能客户端,让你经过一个界面从任何或一切这些网络中阅览和发布信息。那么,具有独立的服务就没有意义了,他们都会关闭……或许他们会吗?

未来事物的预演:电话号码 + 联系人 + 音讯运用程序

评论构建十亿用户的Web3 交际图谱两种方法:链上图和链式图

我所描绘的国际现已以一种原型状态存在,以竞争性信息协议的方式存在,这些协议都与你的电话号码相联系,并从你的联系人数据库中填充自己。电话号码体系是亿万用户表的原型,而分布式的联系人运用程序都能够读写规范的 Vcard 格局,构成了树立在该表之上的联系图

有许多信息传递协议都是借助于这种电话号码 + 联系人的组合,其成果有点像我在这里描绘的交际网络。例如,当你第一次登录 Telegram 时,它会扫描你的联系人,然后你当即在这个新的运用程序中具有你现有的网络。

其成果是,你能够挑选经过 Signal、Telegram、WhatsApp、iMessage 或传统短信与相同的电话号码交换信息–这一切都在于你和你的网络中的其他人想运用哪种信息协议。

还有一个永久的循环,就是音讯运用的去中心化和再中心化,这从 ICQ 时代就开端了,在 WhatsApp / Signal / Telegram / Facebook / 等的时代仍然在产生。你能够找到任何数量的多合一音讯客户端,在一个窗口中支撑许多这些渠道。

这些信息运用都没有受到损害,由于它们都从同一个敞开的电话号码体系和可互操作的联系人运用和服务生态体系中获取身份–它们都共存并带来不同的东西,并且咱们中的许多人在它们之间切换,与咱们联系人中具有不同需求和偏好的不同子图攀谈。假如咱们把交际图谱移到链上,我希望这种动态会继续下去。

关于可组合性和交际联系

评论构建十亿用户的Web3 交际图谱两种方法:链上图和链式图

不同的渠道有不同类型的交际衔接,用户能够相互之间的衔接。Facebook 有朋友、重视和屏蔽。Twitter 有重视、静音和屏蔽。这些关于这些渠道来说是很好的,但咱们能够改进它们,使它们更适合区块链,使它们更具有可组合性。

可组合性是一个计算机科学术语,大概意思是,你能够混合和匹配这些小的、离散的、明确定义的东西,以获得不同的效果和功用。

考虑到 Facebook 的「朋友」–这是它自己的衔接类型,但它也意味着「重视」,由于当你把某人加为好友时,你会自动重视他们。在 Twitter 上,「封杀」意味着「静音」,由于当你屏蔽某人时,你根本上是在让他们静音,一起也阻止他们看到你的帖子。

关于我自己的两个交际图谱的主张,下面,我想主张跟从,更干净和可组合的交际图谱联系集:

  • 重视: 你能够阅览你所重视的人的帖子。

  • 静音: 你不能阅览你现已静音的人的帖子。

  • 屏蔽:你屏蔽的人不能阅览你的帖子。

在这个计划下,一个封杀是一个「静音」加一个「屏蔽」,所以它是对同一个方针地址的两个操作,一起组成的(例如,假如我想封杀 annoyinghater.eth,我就把这个地址静音,再把它的屏蔽)。

假如我想看到某人的帖子,但又不想让他们看到我自己的帖子,我能够重视他们,再加上屏蔽。或许,假如我想保存经过导航到他们的内容或定时吊销他们的静音来阅览,我能够重视加静音。

我企图以这种方式理清联系,由于它使咱们更简略推理接下来的章节中的合约和联系。

我的两项提案的一些背景

在本文的其余部分,我提出了两个将交际图谱分层到十亿用户表中的主张。

  • 第一种,On-Chain Graph(OCG),愈加敞开和简略,但在费用方面也愈加昂贵,所以有些人会喜爱它,有些人不会。

  • 第二种,链式图(CLG),更杂乱但更便宜,并且供给更多的操控和隐私,所以我预计大多数人会更喜爱它。不过,渠道能够一起支撑这两种方式。

要真正了解这两个提案,你需求对以下概念有一些根本的了解:

  • 不行拆分的代币(NFT)和不行拆分不行转让的代币(NTFT,也叫魂灵绑定的代币)。

  • 以太坊域名服务

  • 智能合约

了解一点 Solidity(以太坊的智能合约编程言语)也会有所帮助。假如你对上述一项或全部内容模糊不清,我企图以一种你应该仍然能够把握根本知识的方式来写这篇文章。

关于这两个提案,我假设咱们运用 ENS 作为身份的根,并向其添加新的地址记载,其中包含一些相当规范的 ERC721 NFT 合约的地址,这些合约别离代表我上面概述的三种类型的交际联系(跟从、静音、屏蔽)。这三个合约的效果从一个提案到另一个提案都十分不同,但把它们的地址放入三个特别的 ENS 地址记载的根本主意坚持不变。

评论构建十亿用户的Web3 交际图谱两种方法:链上图和链式图

我还想为交际用户数据 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:链上图

评论构建十亿用户的Web3 交际图谱两种方法:链上图和链式图

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 费用足够高,那么这或许会使网络无法运用。

  • 关于一个网络或一个特定的账户来说,付费重视或许是也或许不是一个抱负的功用,但你会有这样的挑选。

鉴于不是每个人都会喜爱这个主张的这些特质,我想提出一套代替的交际合约,给用户和渠道更细化的操控,特别是谁能看到什么样的信息,并且运用本钱更低。

评论构建十亿用户的Web3 交际图谱两种方法:链上图和链式图

链式链接图(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

此时快讯

【法官:美国政府反对Voyager-Binance.US交易的案件有 "实质性 "的理由】金色财经报道,纽约法官周五表示,美国政府在反对Binance.US以10亿美元收购破产的加密货币贷款机构Voyager的资产的交易中,有一个 "实质性的案情理由"。地区法官Jennifer Rearden表示,考虑到拖延可能给资产造成每月1000万美元的损失,她会尝试并迅速采取行动解决争端。(Coindesk)
版权声明:本文收集于互联网,如有侵权请联系站长删除。
转载请注明:探讨如何构建十亿用户的Web3社交图谱 | 币百度

相关文章