この記事では、10 億ユーザーの Web3 ソーシャルグラフを構築する方法について説明します。

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

BTC0.0₂₀

ETH0.0₂₀

HTX0.0₂₀

SOL0.0₂₀

BNB0.0₂₀

この記事では、10 億ユーザーの Web3 ソーシャルグラフを構築する方法について説明します。

W3.Hitchhiker

2023-03-29 11:00

本文约8092字，阅读全文需要约32分钟

このペーパーでは、ソーシャルグラフを 10 億人のユーザーテーブルに階層化するための 2 つの提案、オンチェーングラフ (OCG) とリンクドグラフ (CLG) を紹介します。

原題：「The Billion User Social Graph》

原題：「

著者: ジョン・ストークス

オリジナルコンピレーション: Dan, W 3. ヒッチハイカー

イーロン・マスク氏による最近の Twitter の乗っ取りにより、大規模なソーシャルネットワークから独立系またはオープンな代替ネットワークへの移行について多くの議論が行われてきましたが、元 Twitter 住民の活気に満ちたコミュニティに参加することを夢見始めているすべての人にとって、間もなく実現します。これは、J6後のクロスプラットフォームソーシャルメディアの粛清以来、右派が取り組んできた問題となるだろう。オンラインロックダウンは現実のものだ。調整の問題、好みのカスケード、シグナリング、その他のゲーム理論スタイルの概念について、理論的かつ戦略的な分析を行うことができます。これらが問題を理解するのに有用な方法であることは否定しませんが、Twitter と Facebook が何百もの人々に与える強力な影響を理解することができます。私たちの何百万人もの皆さんが本当に知っておく必要があるのは、。

単純なヒューリスティック

メトカーフの法則によれば、電気通信ネットワークの価値は、システムに接続されているユーザーの数 (n 2 ) の 2 乗に比例します。メトカーフの法則は、もともと 1993 年にジョージギルダーによってこの形式で定式化され、イーサネットに関するロバートメトカーフの研究によるものとされています。 1980 年頃、メトカーフの法則は当初、ユーザー単位ではなく、「互換性のある通信デバイス」 (ファックス、電話など) 単位で表現されました。この法律はもともとイーサネット接続を記述することを目的としていたため、この法律がユーザーとネットワークに引き継がれるようになったのは、インターネットのグローバル化に伴って後になってからです。

大規模で高密度のネットワークグラフをあきらめて、小規模で疎なネットワークグラフを選択させることは、ほとんど不可能です。唯一の理由は、前者には価値があり、後者には価値がないからです。

しかし奇妙なことに、web3 はこの問題を解決します。あるいは、ブロックチェーンをユーザーの巨大なテーブルから巨大なソーシャルグラフに変えるいくつかの単純なスマートコントラクトを使用すれば、少なくともこの問題は解決できます。

理論的根拠とこれまでの成果ブロックチェーンは、特定のエンティティによって制御されず、オープンかつパブリックなユーザーの 1 つの広大な共有テーブルとして機能することができ、実際に機能します。

「10 億ユーザーの表」で次のように書きました。
パブリックブロックチェーンは、インターネット全体の単一の大規模なユーザーテーブルに相当し、その上に分散アプリケーションの次の波が構築されます。
その代わりに、API によって接続されたユーザーデータウェアハウスの分散ネットワーク、オープンプロトコルを通じてアクセスされるユーザーデータの単一の分散ストア、およびストレージノードの分散ネットワークが配置されます。このように、アイデンティティ管理ブロックチェーンは、データストレージ実装層の分散化と、データストレージアクセス層の再集中化を表します。
LinkedIn、Reddit、Github がすべて、ユーザーテーブル (および承認、ポイント、アクティビティ履歴などの多くの独自データ) を BitClout に移植していることを想像してください。すぐに、何が起こるかというと、すべての Github ユーザーは、Reddit ユーザー、LinkedIn ユーザー、および BitClout ユーザーでもあります。同様に、すべての Reddit ユーザーは、Github ユーザー、LinkedIn ユーザー、および BitClout ユーザーでもあります。延々と続けることもできますが、要点は理解できるでしょう。

仮想ユーザーの同じテーブル上に構築されたすべての企業は、そのテーブル上の他のすべてのスタートアップのネットワーク効果に即座にアクセスできます。オンチェーン企業が新しいユーザーを追加するたびに、あなたのサービスにも新しいユーザーが追加されます。 (ある意味、彼らはまだあなたのサービスを積極的に利用していないかもしれませんが、実際にはあなたのサービスの潜在的なユーザーです)。Bitclout前回使用した記事

(そのプロジェクトのチェーンは現在 DeSo と呼ばれています) このユースケースをサポートできるブロックチェーンの代表的な例として挙げられます。しかし、DeSo の全体像には興奮していましたが、結果はそれほど良くありませんでした。

ここは Bitclout/DeSo の事後検証を行う場所ではありませんが、今の議論にとって重要なこのブロックチェーンの側面にフラグを立てることは意味があります。 Bitclout は、ソーシャルネットワーク全体をオンチェーンに置くよう努めており、各投稿は (Bitclout Diamonds 経由で) 収入を得ることができるオブジェクトとしてオンチェーンに書き込まれます。これは賢いことですが、実際のコンテンツをホストしようとするブロックチェーンでは、ユーザーと接続の数に応じてデータのニーズが直線的に増加することになります。

Bitclout チームは、この際限のないデータ増加の問題に精通しており、この問題を解決するために実際のエンジニアリング努力に多くの労力を費やしてきました。しかし、今になって考えると、彼らは一度に多くのことをやろうとしすぎていたのだと思います。ソーシャルグラフの移植性の問題のみに焦点を当てる必要があります。

users
user_follows_user
posts
user_likes_post

前回の投稿のデータベース用語で説明したように、Bitclout は次のすべてのテーブル (および Bitclout 固有のテーブル) をすべてオンチェーンに配置しようとします。

最後の 2 つのテーブルでは常にデータが爆発的に増加するため、ユーザーが急速に増加すると操作が困難になります。

したがって、より良いアプローチは、基本的にすでに最初のテーブル（つまりユーザー）である既存のブロックチェーンを使用し、それに user_follows_user 結合テーブルを追加することだと思います。 ( user_mutes_user など、他のタイプの関係の結合を拡張することもできますが、今は単純にしておきます。)

このユーザー間の接続テーブルもユーザー数に応じて直線的に増加しますが、その速度は遅くなり、さらに重要なことに、必要な追加データの量 (= 消費する追加ブロックスペースの量) を表すために、投稿テーブルよりもはるかに低くなります。

私がこれを提案するのは、ユーザーとファンの関係が、あらゆる大規模なソーシャルネットワーキングプラットフォームにとってロックインの主要な原因となるためです。 Twitter または Facebook のソーシャルグラフ全体がオープンであり、投稿やその他のよりデータ集約的なソーシャルネットワーキングエクスペリエンスをホストしたい他のソーシャルプラットフォームからすぐに利用できる場合、それらのプラットフォームに対するロックインは基本的にゼロになります。

オンチェーンのソーシャルグラフはどのようなものになるのか

実際のアカウントとフォロワーの関係を含め、私の Twitter グラフ全体がオンチェーンで具体化されていると想像してください。このグラフで Twitter の投稿 (および関連するいいね、リツイート、追跡リツイートなど) を確認するには、ウォレットで Twitter.com に接続する必要があります。しかし、私が、tribe.com、gab.com、あるいは、独自の特別な傾向とモデレーションポリシーを持つその他のソーシャルプラットフォームにジャンプしたいとします。ブロックチェーンから私のソーシャルグラフを読み取ることができれば、そこにウォレットを接続して、同じ接続を確認し、この他のサイトにある投稿を確認してください。Tribelこれはあまり魅力的に聞こえないかもしれませんが、私がもしそうだったとしたら、という事実を考えてください。GabTwitter で新しい人をフォローして、私も Twitter を利用するようになりました。

Facebook でこの人をフォローしてください。また、ユーザーと関係の同じオンチェーングラフを使用する他のすべてのソーシャルプラットフォームでもフォローしてください。フォロー解除とブロックは同じように機能します。1 か所で一度行うと、グラフへの変更が即座にどこにでも反映されます。

さて、これを読んでいる間にこれを利用したいと思っている人は、上記のような世界では必然的に起こることは、誰かがあらゆるデータまたはすべてのデータにアクセスできるようにする包括的なクライアントを作成することであることをすでに理解しています。単一のインターフェイスを介してこれらのネットワークの情報を読み取り、公開します。そうなると、別々のサービスを持つ意味はなくなり、すべて廃業してしまうでしょう...それとも廃業してしまうのでしょうか？

今後のプレビュー: 電話番号 + 連絡先 + メッセージングアプリ

私が説明している世界は、すべて電話番号に関連付けられ、連絡先データベースから自動的に取り込まれる、競合するメッセージングプロトコルの形で、プロトタイプの状態ですでに存在しています。電話番号システムは、数億のユーザーのテーブルのプロトタイプであり、分散連絡先アプリケーションプログラムは、標準の Vcard 形式を読み書きして、テーブルに基づいて関係グラフを形成できます。

この電話番号と連絡先の組み合わせに依存するメッセージングプロトコルは数多くあり、その結果は、ここで説明しているソーシャルネットワークに少し似ています。たとえば、Telegram に初めてログインすると、連絡先がスキャンされ、すぐにこの新しいアプリに既存のネットワークが表示されます。

その結果、Signal、Telegram、WhatsApp、iMessage、または従来の SMS を介して同じ電話番号でメッセージを交換することを選択できます。すべては、あなたとネットワーク内の他のユーザーがどのメッセージングプロトコルを使用したいかによって異なります。また、メッセージングアプリケーションの分散化と再集中化という永遠のサイクルもあり、これは ICQ 時代から始まり、WhatsApp/Signal/Telegram/Facebook などの時代でもまだ起こっています。いくらでも見つけることができますオールインワン

これらのプラットフォームの多くを 1 つのウィンドウでサポートするメッセージングクライアント。

これらのメッセージングアプリはいずれも、同じオープンな電話番号システムと、連絡先アプリとサービスの相互運用可能なエコシステムから ID を引き出しているため、侵害されることはありません。これらはすべて共存し、何か異なるものをもたらし、私たちの多くはそれらを切り替えて会話しています。さまざまなニーズや好みを持つ連絡先のさまざまなサブグラフ。ソーシャルグラフをオンチェーンに移行すれば、この力関係は続くと私は予想します。

構成可能性と社会的関係について

プラットフォームが異なれば、ユーザーが相互に接続できるソーシャル接続の種類も異なります。 Facebookには友達がいて、フォローしていて、ブロックしています。 Twitterにはフォロー、ミュート、ブロックがあります。これらはこれらのプラットフォームにとっては素晴らしいものですが、私たちはそれらを改善し、ブロックチェーンにとってより適したものにし、より構成しやすくすることができます。

コンポーザビリティとはコンピュータサイエンスの用語で、大まかに言うと、これらの小さく個別の明確に定義されたツールを組み合わせて、さまざまな効果や機能を実現できることを意味します。

Facebook の「友達」について考えてみましょう。これは独自の接続タイプですが、誰かを友達として追加すると、自動的にその人をフォローするため、「フォローする」という意味もあります。 Twitter では、「ブロック」は「ミュート」を意味します。誰かをブロックすると、基本的にその人をミュートすると同時に、その人があなたの投稿を見ることもできなくなるからです。

私自身の 2 つのソーシャルグラフ提案として、以下の、よりクリーンで構成可能なソーシャルグラフ関係のセットを提案したいと思います。
フォロー: フォローしている人の投稿を読むことができます。
ミュート: ミュートしたユーザーの投稿を読むことはできません。

ブロック: ブロックした人はあなたの投稿を読むことができません。

このスキームでは、ブロックは「ミュート」に「ブロック」を加えたものであるため、同じターゲットアドレスに対する 2 つの操作で構成されます (たとえば、迷惑なヘイター.eth をブロックしたい場合は、このアドレスをミュートにし、その後、ブロックしてください）。

誰かの投稿は見たいが、自分の投稿は見たくない場合は、その人をフォローしてブロックすることができます。または、コンテンツに移動するか定期的にミュートを解除することで、読み続けたい場合はフォローしてミュートすることもできます。

このようにして関係を明確にしようとしているのは、次の章で契約と関係について推論しやすくなるからです。

私の 2 つの提案の背景

このペーパーの残りの部分では、ソーシャルグラフを 10 億ユーザーのテーブルに階層化するための 2 つの提案を紹介します。
1 つ目の On-Chain Graph (OCG) は、よりオープンでシンプルですが、料金の面でも高価なので、好む人も嫌いな人もいます。
2 番目の連鎖グラフ (CLG) は、より複雑ですが安価で、より多くの制御とプライバシーを提供するため、ほとんどの人がこれを好むと予想します。ただし、プラットフォームは両方のアプローチを同時にサポートできます。
両方の提案を本当に理解するには、次の概念についてある程度の基本的な知識が必要です。
イーサリアムドメインネームサービス
スマートコントラクト

スマートコントラクト

Solidity (イーサリアムのスマートコントラクトプログラミング言語) について少し知っておくことも役に立ちます。上記の 1 つまたはすべてが曖昧でも、基本を理解できるようにこれを書いてみました。ENS両方の提案で、次を使用すると仮定します。

ID のルートとして、上で概説した 3 つのタイプの社会的関係 (フォロー、ミュート、ブロック) を表すいくつかのかなり標準的な ERC 721 NFT 契約のアドレスを含む新しいアドレスレコードを追加します。これら 3 つの契約の役割は提案ごとに大きく異なりますが、住所を 3 つの特別な ENS アドレスレコードに入れるという基本的な考え方は同じです。

ENS レコードの例、この場合は私自身の ENS 名

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"

}

また、ガスを消費せずにソーシャルデータを更新できるように、ソーシャルユーザーデータ URI に追加の ENS レコードを提案したいと思います。提案された profileURI レコードは、次のようなサードパーティプラットフォームに隠された JSON オブジェクトにリンクします。

プロファイル JSON の一部のコンテンツは既存の ENS フィールドと重複していますが、問題ありません。この目的は、ソーシャルプラットフォームに表示するものを提供し、ユーザーが ENS レコードの更新にガスを費やすことなくソーシャルプロフィールを変更できるようにすることです。

提案1: オンチェーングラフ

On-Chain Graph の考え方では、NTFT を使用して上記 3 つの関係を表現します。次の 3 つのソーシャルコントラクトの場合、ENS NFT を保持する同じウォレットがこれらのコントラクトも所有する必要があり、それらの 3 つの対応する ENS アドレスレコードがこれらのコントラクトを指す必要があります。
OCG フォロワー: 私の OCG フォロワー契約からの NTFT をウォレットに入金すると、私をフォローしたことになります。私たちの誰もがこのNFTを破壊し、私のフォローを解除させることができます。
OCG のブロック: OCG Ghosted 契約から NTFT をあなたのウォレットにエアドロップしたときに、あなたをブロックしました。あなたを安心させるためにこのNTFTを破壊できるのは私だけです。

OCG ミュート: OCG ミュート契約からあなたのウォレットに NTFT をエアドロップしたとき、私はあなたをミュートしました。この NTFT を破壊してミュートを解除できるのは私だけです。

これら 3 つのケースの意味は基本的に次のとおりです。「契約所有者である私から見て、あなたは X です」。「X」は一種のフォロワー、ブロック、ミュートです。

// SPDX-License-Identifier: MIT

pragma solidity ^ 0.8.4;

import "@openzeppelin/contracts/token/ERC 721/ERC 721.sol";

import "@openzeppelin/contracts/token/ERC 721/extensions/ERC 721 Enumerable.sol";

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

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

import "@openzeppelin/contracts/token/ERC 721/extensions/ERC 721 Burnable.sol";

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

contract OCGFollower is ERC 721, ERC 721 Enumerable, Pausable, Ownable, ERC 721 Burnable {

using Counters for Counters.Counter;

Counters.Counter private _tokenIdCounter;

constructor() ERC 721("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");

uint 256 tokenId = _tokenIdCounter.current();

_tokenIdCounter.increment();

_safeMint(to, tokenId);

}

function _beforeTokenTransfer(address from, address to, uint 256) 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(bytes 4 interfaceId)

public

view

override(ERC 721, ERC 721 Enumerable)

returns (bool)

{

return super.supportsInterface(interfaceId);

}

以下はフォロワー契約のサンプルです。

Solidity に精通している場合は、この非常に単純な (そしてテストされていない) コントラクトが何をしようとしているのかがわかるでしょう。

まず拡張子:
ERC 721 Enumerable 拡張機能が含まれているため、ソーシャルネットワーククライアントはチェーン全体をスキャンすることなくトークン所有者をリストできます。
私が Pausable を使用するのは、ミントを一時停止して一定期間アカウントを実質的にロックできる、つまり新しいフォロワーの受け入れを停止できる必要があるためです。
契約所有者のみが行う必要があることがいくつかあるため、所有可能であることが不可欠です。より強力なキャラクター機能を使用する必要はないと思います。
ERC 721 Burnable は、フォロー関係を削除するためにトークンを書き込むことができる必要があるためにここにあります。ここに含まれる標準の burn() 関数には、必要な権限が含まれています。つまり、トークンを書き込むことができるのは所有者またはトークン所有者だけです。

tokenID が自動でインクリメントされるようにカウンターを組み込みました。これは便利です。

次に、OpenZeppelin ウィザードの出力を変更します。
safeMint() が変更されると、コントラクトの所有者だけが他の人のアドレスにトークンを鋳造できるようになります。所有者以外の場合は、コントラクトと呼ばれるアドレスにのみコインを鋳造できます。
_beforeTokenTransfer() は本質的にトークンを転送する機能を無効にし、単純な魂に縛られたトークンを作成するように書き直されました。

relationship() 関数は、コントラクトをクエリして NFT がどのような関係を表すかを確認する簡単な方法を保証する便利なメソッドです。私はこれを含めるのが好きではありませんが、便利そうです。

それはすべて非常に簡単です。OCG のマスクされたバリアントと OCG のミュートされたバリアントの場合は、次の小さな変更を行う必要があります。
契約名と記号の変更
表現する関係 (つまり、「ミュート」または「ゴースト」) を反映するように、 relationship() および場合によってはbaseURI() の戻り値を変更します。

コントラクト所有者のみがこれら 2 つの関数を呼び出せるように、safeMint() と burn() の両方をonlyOwner 関数に変更します。

明らかに、これはプラットフォームがこれらの契約 (つまり、フォロー、ブロック、ミュート) を正しい方法で履行するかどうかに依存します。ただし、特定のソーシャルプラットフォームが気になる契約を履行していない場合は、そのプラットフォームを使用しないでください。

注目を集めた

uint 256 public mintRate = 0.01 ether;

function setMintRate(uint 256 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");

uint 256 tokenId = _tokenIdCounter.current();

_tokenIdCounter.increment();

_safeMint(to, tokenId);

}

safeMint に Payable を追加し、setMintRate を使用して、人々が以下に対して支払わなければならない価格を設定できます。したがって、次のようになります。

この提案に追加する他の多くの調整や機能を思いつくことはできると思いますが、シンプルでわかりやすいものから始めるのが最善です。

提案 2: チェーン接続グラフ

上で説明した OCG 契約は非常に単純ですが、このスキームには多くの人の意見を分ける可能性のあるいくつかの特異性があります。
ブロックやミュートも含め、すべてがオンチェーンで公開されます。これを行ってアカウントをロックすることはできませんが、この問題を解決するには代替アカウントを使用することが考えられます。
すべてのアクションにはガスがかかります。つまり、誰をフォロー、ブロック、ミュートするかについて実際の選択をする必要があります。ただし、ガスのコストが十分に高い場合、ネットワークが使用できなくなる可能性があります。

有料フォローは、ネットワークまたは特定のアカウントにとって望ましい機能である場合とそうでない場合がありますが、オプションはあります。

この提案のこうした性質を誰もが気に入るわけではないことを考慮して、ユーザーとプラットフォームが誰にどの情報を見るかをよりきめ細かく制御でき、使用コストが低くなる代替の社会契約セットを提案したいと思います。

チェーンリンクグラフ (CLG) の基本的な考え方: NFT を通じてチェーン上でソーシャル関係 (フォロー、ブロック、ミュート) を直接表すのではなく、これらの関係をオフチェーンに保存し、オンチェーントークンを使用して発見し、これらの関係にアクセスします。
ディスカバリー: コントラクトは、社会的関係 (つまり、フォローする、ミュートする、またはブロックする) を宣言する予定の ENS 名へのリンクの JSON リストを返す listURI() 関数を提供します。

アクセス: listURI() によって返されるリンクがトークン制御されている場合、コントラクトのトークンにより、所有者はメタデータ内で見つかったリンクへの読み取りアクセスが許可されます。

この場合、社会的関係はチェーン上に直接存在するのではなく、一連のコントラクトと URL を通じてチェーンに接続されます。

OCG と同様に、3 つのソーシャル関係はそれぞれスマートコントラクトによって管理されますが、CLG のセマンティクスは異なります。
Follows: フォローしている ENS の名前へのリンクの JSON リストが含まれており、それによって発行されたトークンにより、そのウォッチリストへの読み取りアクセスが許可されます。
ミュート: ミュートしている ENS にリンクされている名前の JSON リストが含まれており、それによって発行されたトークンにより、そのミュートされたリストへの読み取りアクセスが許可されます。

ブロック: ブロックしている ENS 名にリンクする JSON リストが含まれており、それによって発行されたトークンにより、ブロックリストへの読み取りアクセスが許可されます。

したがって、CLG トークンのセマンティクスは次のようになります。「これは、私の X アカウントのリストへの読み取りアクセスです」。ここで、「X」は「フォロー」、「ミュート」、または「ブロック」です。

このセクションでの私の提案は、メッセージングアプリケーションについて説明した電話番号とアドレス帳の組み合わせの近似値と考えることができます。電話番号は（準）公開されており、新しいメッセージングアプリを接続すると、そのアプリに連絡先への読み取りアクセスを許可または拒否できます。

私の CLG ソーシャルトークンプログラムでは、あなたの ENS 名は電話番号と同様に公開されており、トークンを発行および取り消して、何らかの関係がある人々のリストへのアクセスを許可または拒否します。必要に応じて、これらのトークンをランダムなユーザーに付与することもできますが、ほとんどの場合、ソーシャルプラットフォームにトークンを付与して、誰の投稿を表示し、誰の投稿を非表示にするか (または誰の投稿を見るべきではないか) をプラットフォームが認識できるようにします。

(ソーシャルグラフを構成するリストへの書き込みアクセスは、通常の ENS NFT によって制御される場合があります。ウォレットに ENS 名がある場合は、リストの書き込み/更新/削除が可能です。考えられる 1 つの代替案は、4 つ目の方法です。 NTFT 保有者にリストへの書き込みアクセスを許可する社会契約により、リスト管理をサードパーティに委託できるようになります）

これらのリストをオフチェーンでホストしながら、オンチェーンからそれらのリストを指定すると、いくつかの利点があります。
リストをホストしているエンドポイントで認証を使用すると、関係を公開できないようにロックダウンできます。または、誰でも読めるように公開することもできます。
オフチェーンリストの更新にはガスはかかりません。
このアプローチにより、ソーシャルプロバイダーと相互運用可能なソーシャルグラフホスティングサービスのマーケットプレイスの作成が可能になります。

誰でも、またはサービスがあなたのリスティングを簡単に見つけることができます。

トークンのアクセス制御と読み取りアクセス

CLG コントラクトの実装における重要な革新は、トークンアクセス制御です。トークン・アクセス制御の背後にある概念は、特定のアクセス・トークンを含むウォレットでホストに接続しない限り、ホスト上の特定のデータにアクセスできないというものです。

たとえば、IPFS 上のコンテンツに対するトークン化されたアクセス制御を使用して、ウォレット内の特定の NFT を使用してエンドポイントに接続するリーダーのみが特定のファイルを表示できるようにすることができます。

CLG はトークンゲートを使用してソーシャルコントラクトに間接的な機能を追加するため、特定の種類の関係 (フォロー、ミュート、ブロック) を表す代わりに、ソーシャル NFT はソーシャルグラフの一部への読み取りアクセスを表します。

明らかに、トークンのしきい値が機能するには、プラットフォームがそれを尊重する必要があります。おそらく、プラットフォームがトークンのアクセス制御を尊重しない場合は、関係リストを他のプラットフォームに転送し、契約を変更し、必要に応じて NFT を再発行することになります。

また、明確にしておきますが、ある時点で一部の人のリストが漏洩します。私たちは個人データ侵害の世界に生きているため、データがどこかにホストされている場合、一部のデータが侵害されることになります。考えられる軽減策については後の章で説明します。

契約テンプレート: CLG フォローズ

// SPDX-License-Identifier: MIT

pragma solidity ^ 0.8.4;

import "@openzeppelin/contracts/token/ERC 721/ERC 721.sol";

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

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

import "@openzeppelin/contracts/token/ERC 721/extensions/ERC 721 Burnable.sol";

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

contract CLGFollows is ERC 721, Pausable, Ownable, ERC 721 Burnable {

using Counters for Counters.Counter;

Counters.Counter private _tokenIdCounter;

constructor() ERC 721("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 {

uint 256 tokenId = _tokenIdCounter.current();

_tokenIdCounter.increment();

_safeMint(to, tokenId);

}

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

//Disable token transfers.

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

}

以下の契約は、上記の OCG 契約に非常に近い、標準の ERC 721 NTFT 契約になります。

すべての拡張機能は OCG と同じですが、CLG Follows トークンを列挙してもらいたい人がいるかどうかが明確ではないため、ERC 721 Enumerable を含めませんでした (さらに、鋳造のガスコストが上がります)。

関数に関しては、OpenZeppelin ウィザードの出力に次の変更を加えました。
relationship(): OLG と同様に、社会契約のタイプを返します。繰り返しになりますが、これはおそらく Solidity 契約には必要ありませんし、私はそれが行われているのを見たことがありませんが、それでも、契約にはそのタイプを自己報告してもらいたいと感じています。だからわかりませんが、気分を害する場合は無視してください。

listURI() は、フォローしている (または契約の種類に応じてミュートまたはブロックされている) ENS 名のリストである JSON オブジェクトへのリンクを返します。この URI をプライベートとしてマークしたいのですが、そうする必要はありません。

ほとんどの場合、CLG Follows NTFT を使用し、ソーシャルプラットフォームが所有するアドレスに投稿します。そうすることで、プラットフォームはウォッチリストを読み取り、正しい投稿を表示できるようになります。

ただし、これらの NTFT をフォロワーに送信して、フォロワーが他のフォロワーを発見できるようにすることもできます。これを行うには、フォロワーにエアドロップするか、コインの禁止を解除して誰でも鋳造できるようにします。

他のすべてのコントラクトは上記とまったく同じように機能しますが、名前とシンボルが異なり、relationship() と listURI() から異なる値を返します。

考えられる変数

さまざまなサービスからリストが漏洩することが心配な場合は、 listURI() を tokenURI(uint 256 tokenId) のようなものに変更するのが非常に簡単です。つまり、署名は listURI(uint 256 tokenId) で、トークン ID をトークンの末尾に連結します。ベース URI なので、各トークン所有者は独自のリスト URL を取得します。この機能をリストホストのロジックと組み合わせると、異なるトークン所有者がメイングラフの異なるサブグラフを取得するようにリストを分離できます。そうすれば、プラットフォームが所有されている場合、グラフのその部分だけが侵害されます。

tokenURI() や listURI() によって返される URL を更新できるようにしたい場合があります。その場合、これらの URL を変数に格納し、コンストラクターで初期化し、更新用のonlyOwner セッター関数を提供する必要があります。。これにより鋳造コストが増加しますが、個人ではなくサービスにのみ鋳造コストを提供する場合、これはおそらく問題になりません。

仕える

ここで概説した両方の提案は、エコシステムが IPFS のような分散システムに移行するまで、たとえ一時しのぎであっても、集中型ホスティングサービスのための場所を提供します。

最も明白なタイプのサービスは、URI 関数の 1 つによって返されるもの (プロファイルデータ、NTFT メタデータ、トークンコントロールの JSON リスト (CLG の場合)) をホストするものです。

最後に、ユーザーや組織のニーズに合わせてアカウントを検証するサードパーティサービスを利用できます。

要約する

私のオンチェーンソーシャルグラフの提案が、ここで説明する形で採用されることを期待しているかどうかはわかりません。私がこれらのアイデアをさらに取り上げるのは、完全にロックダウンされたプラットフォームの現在の状態から、グラフを所有し、どこにでも簡単に持ち運べる、よりポータブルな状態にどのように効果的に移行できるかについての会話を促すためです。

この投稿から他に何も得られないとしても、少なくとも、分散型台帳テクノロジーとスマートコントラクトの世界では、2022 年に私たちの誰もがソーシャルネットワークに閉じ込められる必要はないということを明確にできたことを願っています。このロックの問題を解決するツールは広く入手可能であり、私たちはそれらを手に取って使用するだけで済みます。