위험 경고: '가상화폐', '블록체인'이라는 이름으로 불법 자금 모집 위험에 주의하세요. — 은행보험감독관리위원회 등 5개 부처
검색
로그인
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt
BTC
ETH
HTX
SOL
BNB
시장 동향 보기
이 문서에서는 10억 명의 사용자에 대한 Web3 소셜 그래프를 구축하는 방법을 살펴봅니다.
W3.Hitchhiker
特邀专栏作者
2023-03-29 11:00
이 기사는 약 8092자로, 전체를 읽는 데 약 12분이 소요됩니다
이 백서에서는 소셜 그래프를 10억 ​​명의 사용자 테이블에 계층화하기 위한 두 가지 제안인 온체인 그래프(OCG)와 연결된 그래프(CLG)를 제시합니다.

원래 제목: "The Billion User Social Graph

원래 제목: "

저자: 존 스톡스

원본 편집: Dan, W 3. Hitchhiker

Elon Musk의 최근 Twitter 인수로 대규모 소셜 네트워크에서 독립적이거나 개방적인 대안으로 마이그레이션하는 것에 대해 많은 이야기가 있었지만 이제 막 번성하는 전 Twitter 거주자 커뮤니티에 합류하는 것에 대한 환상을 갖기 시작한 모든 사람들에게 곧 있을 것입니다. J6 이후 교차 플랫폼 소셜 미디어 제거 이후 오른쪽이 씨름해 온 문제가 될 것입니다. 온라인 잠금이 현실입니다.조정 문제, 선호 캐스케이드, 신호 및 기타 게임 이론 스타일 개념에 대한 이론적이고 전략적인 분석을 수행할 수 있습니다. 이러한 개념이 문제를 이해하는 데 유용한 방법이라는 것을 부인하지는 않지만 Twitter 및 Facebook이 수백 가지에 미치는 강력한 영향을 이해합니다. 수백만 명의 우리가 정말로 알아야 할 것은

단순 휴리스틱

Metcalfe의 법칙에 따르면 통신 네트워크의 가치는 시스템에 연결된 사용자 수의 제곱(n 2 )에 비례합니다. Metcalfe의 법칙은 원래 George Gilder가 1993년에 이 형식으로 공식화했으며 이더넷에 대한 Robert Metcalfe의 작업에 기여했습니다. 1980년경 Metcalfe의 법칙은 원래 사용자 단위가 아니라 "호환 가능한 통신 장치"(예: 팩스, 전화) 단위로 표현되었습니다. 이 법은 원래 이더넷 연결을 설명하기 위한 것이었기 때문에 나중에 인터넷의 세계화와 함께 사용자와 네트워크에 적용되었습니다.

사람들이 작고 희소한 네트워크 그래프를 위해 크고 밀집된 네트워크 그래프를 포기하게 만드는 것은 거의 불가능하며, 유일한 이유는 전자는 가치가 있고 후자는 그렇지 않기 때문입니다.

그러나 이상하게도 web3는 이 문제를 해결합니다. 또는 최소한 블록체인을 거대한 사용자 테이블에서 거대한 소셜 그래프로 바꾸는 간단한 스마트 계약을 사용하면 이 문제를 해결할 수 있습니다.

이론적 근거 및 이전 작업블록체인은 하나의 엔티티에 의해 제어되지 않는 개방적이고 공개적인 하나의 광대한 사용자 공유 테이블로 기능할 수 있습니다.

내가 The Billion Users Table에 쓴 것처럼:
퍼블릭 블록체인은 차세대 분산 응용 프로그램이 구축될 전체 인터넷에 대한 단일 대규모 사용자 테이블과 같습니다.
그 자리에는 API로 연결된 사용자 데이터 웨어하우스의 분산형 네트워크, 개방형 프로토콜을 통해 액세스되는 사용자 데이터의 단일 분산형 저장소 및 저장 노드의 분산형 네트워크가 있습니다. 이와 같이 신원 관리 블록체인은 데이터 저장 구현 계층의 분산화와 데이터 저장 액세스 계층의 재중앙화를 나타냅니다.
LinkedIn, Reddit 및 Github가 모두 사용자 테이블(및 보증, 포인트 및 활동 기록과 같은 많은 독점 데이터)을 BitClout으로 포팅한다고 상상해 보십시오. 바로 다음과 같은 일이 발생합니다. 모든 Github 사용자는 Reddit 사용자, LinkedIn 사용자 및 BitClout 사용자이기도 합니다. 마찬가지로 모든 Reddit 사용자는 Github 사용자, LinkedIn 사용자 및 BitClout 사용자이기도 합니다. 나는 계속해서 갈 수 있지만 당신은 요점을 얻을 것입니다.

동일한 가상 사용자 테이블에 구축된 모든 회사는 해당 테이블에서 다른 모든 스타트업의 네트워크 효과에 즉시 액세스할 수 있습니다. 온체인 회사가 새로운 사용자와 합류할 때마다 서비스에도 새로운 사용자가 생깁니다. (어떤 면에서는 아직 귀하의 서비스를 적극적으로 사용하지 않을 수도 있지만 실제로는 귀하의 서비스의 잠재적 사용자입니다).Bitclout이전에 사용한 글

(해당 프로젝트의 체인은 이제 DeSo라고 함) 이 사용 사례를 지원할 수 있는 블록체인의 대표적인 예입니다. 하지만 전체 DeSo에 대해 흥분한 만큼 결과는 그다지 좋지 않았습니다.

이곳은 Bitclout/DeSo 사후 분석을 하는 곳이 아니지만, 지금 토론에 중요한 이 블록체인의 측면에 플래그를 지정하는 것이 이치에 맞습니다. Bitclout은 각 게시물이 (Bitclout 다이아몬드를 통해) 수입을 올릴 수 있는 개체로 온체인에 작성되는 전체 소셜 네트워크를 온체인에 넣기 위해 노력합니다. 영리하지만 실제 콘텐츠를 호스팅하려는 모든 블록체인은 사용자 및 연결 수에 따라 데이터 요구 사항이 선형적으로 증가하는 것을 볼 수 있습니다.

Bitclout 팀은 이 무한한 데이터 증가 문제에 대해 매우 잘 알고 있으며 이를 해결하기 위해 많은 실제 엔지니어링 노력을 기울였습니다. 하지만 돌이켜보면 사실 그들이 한 번에 너무 많은 일을 하려고 했던 것 같아요. 소셜 그래프의 이식성 문제에만 집중해야 합니다.

  • users

  • user_follows_user

  • posts

  • user_likes_post

내 이전 게시물에서 데이터베이스 용어로 설명된 Bitclout은 다음 테이블을 모두 온체인에 배치하려고 시도합니다(Bitclout 전용 테이블 포함).

마지막 2개의 테이블은 항상 데이터 폭증이 있어 사용자가 빠르게 증가하는 경우 운영이 어려워집니다.

따라서 더 나은 접근 방식은 기본적으로 이미 첫 번째 테이블(예: 사용자)인 기존 블록체인을 가져오고 여기에 user_follows_user 조인 테이블을 추가하는 것입니다. (user_mutes_user 와 같은 다른 유형의 관계에 대한 조인을 확장할 수도 있지만 지금은 간단하게 유지하겠습니다.)

이 사용자 대 사용자 연결 테이블은 사용자 수에 따라 선형적으로 증가하지만 더 느린 속도로 증가하며 더 중요한 것은 필요한 추가 데이터의 양(= 소비하는 추가 블록 공간의 양)을 나타내기 위해 posts 테이블보다 훨씬 낮습니다.

사용자와 팬 관계가 모든 대규모 소셜 네트워킹 플랫폼에 대한 잠금의 주요 소스를 구성하기 때문에 이것을 제안합니다. 전체 Twitter 또는 Facebook 소셜 그래프가 열려 있고 게시물 및 기타 데이터 집약적 소셜 네트워킹 경험을 호스팅하려는 다른 소셜 플랫폼에서 쉽게 사용할 수 있는 경우 해당 플랫폼에 대한 잠금이 거의 없습니다.

온체인 소셜 그래프의 모습

실제 계정과 팔로워 관계를 포함하여 전체 트위터 그래프가 온체인으로 구현된다고 상상해 보세요. 이 그래프에서 Twitter 게시물(및 관련 좋아요, 리트윗, 추적 리트윗 등)을 보려면 내 지갑으로 Twitter.com에 연결해야 합니다. 그러나 제가 trive.com, gab.com 또는 고유한 경향과 조정 정책이 있는 다른 소셜 플랫폼으로 이동하고 싶다고 가정해 보겠습니다. 그들이 블록체인에서 내 소셜 그래프를 읽을 수 있다면 거기에 내 지갑을 연결하고 동일한 연결을 보고 이 다른 사이트에 있는 모든 게시물을 봅니다.Tribel그다지 매력적으로 들리지 않을 수도 있지만,GabTwitter에서 새로운 사람을 팔로우하면 나도 Twitter에 있고

Facebook에서 이 사람을 팔로우하세요. 그리고 동일한 사용자 및 관계 온체인 그래프를 사용하는 다른 모든 소셜 플랫폼에서 팔로우하세요. 언팔로우와 차단은 같은 방식으로 작동합니다. 한 곳에서 한 번만 하면 그래프의 변경 사항이 모든 곳에 즉시 반영됩니다.

자, 읽는 동안 이것을 이용하고 싶은 분들은 위와 같은 세상에서 불가피하게 일어날 일은 누군가가 당신이 어떤 것 또는 모든 것의 데이터에 액세스할 수 있게 해주는 포괄적인 클라이언트를 만들 것이라는 것을 이미 알고 있습니다. 단일 인터페이스를 통해 이러한 네트워크의 정보를 읽고 게시합니다. 그렇다면 별도의 서비스를 갖는 것은 의미가 없습니다. 그들은 모두 폐업할 것입니다... 아니면 그럴까요?

미래의 미리보기: 전화번호 + 연락처 + 메시징 앱

내가 설명하고 있는 세상은 이미 프로토타입 상태로 존재합니다. 경쟁 메시징 프로토콜의 형태는 모두 전화번호에 연결되어 있고 연락처 데이터베이스에서 자신을 채우고 있습니다. 전화번호 체계는 수억 명의 사용자 테이블의 원형이며 분산 연락처 응용 프로그램은 표준 Vcard 형식을 읽고 쓸 수 있으며 테이블을 기반으로 관계 그래프를 형성합니다.

이 전화번호 + 연락처 조합에 의존하는 많은 메시징 프로토콜이 있으며 그 결과는 여기서 설명하는 소셜 네트워크와 약간 비슷합니다. 예를 들어 Telegram에 처음 로그인하면 연락처를 스캔하고 즉시 이 새로운 앱에 기존 네트워크를 갖게 됩니다.

결과적으로 Signal, Telegram, WhatsApp, iMessage 또는 기존 SMS를 통해 동일한 전화번호로 메시지를 교환하도록 선택할 수 있습니다. 이는 모두 귀하와 네트워크의 다른 사람들이 사용하려는 메시징 프로토콜에 따라 다릅니다.ICQ 시대부터 시작되어 WhatsApp/Signal/Telegram/Facebook 등 시대에도 여전히 일어나고 있는 메시징 애플리케이션의 분산화 및 재중앙화인 영원한 주기도 있습니다. 얼마든지 찾을 수 있습니다올인원

하나의 창에서 이러한 많은 플랫폼을 지원하는 메시징 클라이언트입니다.

이러한 메시징 앱은 모두 동일한 개방형 전화 번호 시스템과 상호 운용 가능한 연락처 앱 및 서비스 생태계에서 ID를 가져오기 때문에 손상되지 않습니다. 모두 공존하고 다른 것을 가져오며 많은 인간이 그들 사이를 전환하여 대화합니다. 요구 사항과 선호도가 다른 연락처의 다른 하위 그래프. 소셜 그래프를 온체인으로 옮기면 이 역학이 계속될 것으로 기대합니다.

구성 가능성 및 사회적 관계

플랫폼마다 사용자가 서로 연결할 수 있는 다양한 유형의 소셜 연결이 있습니다. Facebook에는 친구, 팔로우 및 차단이 있습니다. 트위터에는 팔로우, 음소거 및 차단 기능이 있습니다. 그것들은 이러한 플랫폼에 적합하지만 우리는 그것들을 개선할 수 있고, 블록체인에 더 적합하게 만들고, 더 구성 가능하게 만들 수 있습니다.

구성 가능성은 서로 다른 효과와 기능을 달성하기 위해 이러한 작고 개별적이며 잘 정의된 도구를 혼합하고 일치시킬 수 있음을 대략적으로 의미하는 컴퓨터 과학 용어입니다.

Facebook "친구"를 고려하십시오. 이것은 고유한 연결 유형이지만 "팔로우"를 의미하기도 합니다. 누군가를 친구로 추가하면 자동으로 그들을 팔로우하기 때문입니다. Twitter에서 "차단"은 "음소거"를 의미합니다. 누군가를 차단하면 기본적으로 해당 사용자를 음소거하는 동시에 해당 사용자가 귀하의 게시물을 볼 수 없도록 하기 때문입니다.

  • 아래의 두 가지 소셜 그래프 제안에 대해 다음과 같이 깔끔하고 구성 가능한 소셜 그래프 관계 세트를 제안하고 싶습니다.

  • 팔로우: 팔로우하는 사람들의 게시물을 읽을 수 있습니다.

  • 음소거: 음소거한 사람의 게시물을 읽을 수 없습니다.

차단: 차단한 사람은 게시물을 읽을 수 없습니다.

이 구성표에서 블록은 "음소거"와 "블록"을 더한 것이므로 동일한 대상 주소에 대한 두 가지 작업으로 구성됩니다(예를 들어 성가신hater.eth를 차단하려면 이 주소를 음소거로 설정합니다. 그런 다음 차단).

다른 사람의 게시물은 보고 싶지만 내 게시물은 보고 싶지 않은 경우 팔로우하고 차단할 수 있습니다. 또는 콘텐츠를 탐색하거나 주기적으로 음소거를 해제하여 계속 읽고 싶다면 팔로우하고 음소거할 수 있습니다.

다음 장에서 계약과 관계에 대해 더 쉽게 추론할 수 있기 때문에 이러한 방식으로 관계를 명확히 하려고 합니다.

내 두 가지 제안에 대한 약간의 배경

  • 이 백서의 나머지 부분에서는 소셜 그래프를 10억 ​​사용자 테이블에 계층화하기 위한 두 가지 제안을 제시합니다.

  • 첫 번째인 온체인 그래프(OCG)는 더 개방적이고 단순하지만 수수료 측면에서 더 비싸기 때문에 어떤 사람들은 그것을 좋아할 것이고 어떤 사람들은 그렇지 않을 것입니다.

  • 두 번째 체인 그래프(CLG)는 더 복잡하지만 더 저렴하고 더 많은 제어 기능과 개인 정보 보호 기능을 제공하므로 대부분의 사람들이 선호할 것으로 예상합니다. 그러나 플랫폼은 두 가지 접근 방식을 동시에 지원할 수 있습니다.

  • 두 제안을 실제로 이해하려면 다음 개념에 대한 기본적인 지식이 필요합니다.

  • 이더리움 도메인 이름 서비스

  • 스마트 계약

스마트 계약

솔리디티(Ethereum의 스마트 계약 프로그래밍 언어)를 조금 아는 것도 도움이 될 것입니다. 위의 항목 중 하나 또는 모두에 대해 모호한 경우 기본 사항을 파악할 수 있는 방식으로 이 글을 작성하려고 했습니다.ENS두 제안 모두에 대해 다음을 사용한다고 가정합니다.

신원의 루트로서 위에서 설명한 세 가지 유형의 사회적 관계(팔로우, 음소거, 차단)를 나타내는 상당히 표준적인 ERC 721 NFT 계약의 주소를 포함하는 새 주소 레코드를 추가합니다. 이 세 계약의 역할은 제안마다 매우 다르지만 주소를 세 개의 특수 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를 사용하여 위의 세 가지 관계를 나타냅니다. 다음 세 가지 소셜 계약의 경우 ENS NFT를 보유하고 있는 동일한 지갑이 이러한 계약도 소유해야 하며 세 개의 해당 ENS 주소 레코드가 이러한 계약을 가리켜야 합니다.

  • OCG 추종자: 내 OCG 추종자 계약에서 NTFT를 지갑에 입금하면 나를 따르게 됩니다. 우리 중 누구라도 이 NFT를 파괴하고 나를 팔로우 해제하도록 만들 수 있습니다.

  • OCG 차단: 내 OCG Ghosted 계약에서 지갑으로 NTFT를 에어드랍했을 때 차단했습니다. 오직 나만이 이 NTFT를 파괴하여 당신을 안심시킬 수 있습니다.

OCG Mute: 내 OCG Mute 계약에서 귀하의 지갑으로 NTFT를 에어드롭할 때 귀하를 음소거했습니다. 나만이 NTFT를 파괴하여 음소거를 해제할 수 있습니다.

이 세 가지 경우의 의미는 기본적으로 "나와 관련하여 계약 소유자, 당신은 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() 함수에는 필요한 권한이 있습니다. 즉, 소유자 또는 토큰 소유자만 토큰을 소각할 수 있습니다.

토큰 ID가 자동으로 증가하도록 카운터를 포함시켰습니다. 이는 편리합니다.

  • 이제 OpenZeppelin 마법사의 출력을 수정합니다.

  • safeMint()가 수정된 후에는 계약 소유자만 다른 사람의 주소로 토큰을 발행할 수 있습니다. 모든 비소유자의 경우 계약을 호출한 주소로만 코인을 발행할 수 있습니다.

  • _beforeTokenTransfer()는 기본적으로 토큰 전송 기능을 비활성화하여 간단한 영혼에 묶인 토큰을 생성하도록 재작성되었습니다.

Relationship() 함수는 계약을 쿼리하고 NFT가 나타내는 관계를 쉽게 확인할 수 있는 편리한 방법입니다. 나는 이것을 포함하는 팬이 아니지만 유용한 것 같습니다.

  • 정말 간단합니다. OCG의 마스크 및 OCG의 음소거 변형에 대해 다음과 같은 작은 변경을 수행해야 합니다.

  • 계약 이름 및 기호 변경

  • 당신이 표현하는 관계(즉, "음소거됨" 또는 "고스트됨")를 반영하도록 관계() 및 가능한 경우 baseURI()의 반환 값을 변경합니다.

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에 지불 가능 금액을 추가한 다음 setMintRate를 사용하여 사람들이 다음 항목에 대해 지불해야 하는 가격을 설정할 수 있습니다. 그래서 다음과 같습니다.

이 제안에 추가할 다른 많은 조정 및 기능을 생각할 수 있다고 확신하지만 간단하고 이해하기 쉬운 것부터 시작하는 것이 가장 좋습니다.

제안 2: 체인 연결 그래프

  • 위에서 설명한 OCG 계약은 충분히 간단하지만 체계에는 많은 사람들을 분열시킬 수 있는 몇 가지 특이한 점이 있습니다.

  • 차단 및 음소거를 포함하여 모든 것이 공개되고 온체인입니다. 계정을 잠그기 위해 이렇게 할 수는 없지만 이 문제에 대한 가능한 해결책은 대체 계정을 사용하는 것입니다.

  • 모든 행동에는 가스 비용이 듭니다. 즉, 누구를 팔로우하고, 차단하고, 음소거할지 실제로 선택해야 합니다. 그러나 가스 비용이 충분히 높으면 네트워크를 사용할 수 없게 될 수 있습니다.

유료 팔로우는 네트워크나 특정 계정에 바람직한 기능일 수도 있고 아닐 수도 있지만 선택권이 있습니다.

모든 사람이 이 제안의 이러한 특성을 좋아하지 않을 것이라는 점을 감안할 때, 나는 사용자와 플랫폼이 누가 어떤 정보를 볼 수 있는지에 대해 보다 세밀한 제어를 제공하고 사용 비용이 적게 드는 대안적인 사회 계약 세트를 제안하고 싶습니다.

  • 체인 링크 그래프(CLG)의 기본 아이디어: NFT를 통해 체인에 직접 사회적 관계(팔로우, 차단, 음소거)를 표현하지 않고 이러한 관계를 오프체인에 저장하고 온체인 토큰을 사용하여 발견하고 이러한 관계에 액세스합니다.

  • 발견: 계약은 사회적 관계를 선언하려는 ENS 이름에 대한 JSON 링크 목록을 반환하는 listURI() 함수를 제공합니다(즉, 내가 그들을 팔로우하거나 음소거하거나 차단합니다).

액세스: listURI()에서 반환된 링크가 토큰으로 제어되는 경우 계약의 토큰은 보유자에게 메타데이터에 있는 링크에 대한 읽기 액세스 권한을 부여합니다.

그런 다음 소셜 관계는 체인에 직접 연결되지 않고 일련의 계약 및 URL을 통해 체인에 연결됩니다.

  • OCG와 마찬가지로 세 가지 사회적 관계 각각은 스마트 계약에 의해 관리되지만 CLG는 의미 체계가 다릅니다.

  • 팔로우: 팔로우하고 있는 ENS의 이름에 대한 JSON 링크 목록과 해당 관심 목록에 대한 읽기 액세스 권한을 부여하는 발행된 토큰을 포함합니다.

  • 음소거: 음소거 중인 ENS에 연결된 이름의 JSON 목록을 포함하며, 여기서 발급된 토큰은 음소거된 목록에 대한 읽기 액세스 권한을 부여합니다.

차단: 차단 중인 ENS 이름에 연결되는 JSON 목록이 포함되어 있으며, 차단 목록에 대한 읽기 액세스 권한을 부여하는 토큰이 발급됩니다.

따라서 CLG 토큰의 의미는 다음과 같습니다. "이것은 내 X 계정 목록에 대한 읽기 액세스입니다." 여기서 "X"는 "팔로우", "음소거" 또는 "차단"입니다.

이 섹션의 제안은 메시징 응용 프로그램에 대해 설명하는 전화 번호 + 주소록 조합의 근사치로 생각할 수 있습니다. 귀하의 전화번호는 (준)공개이며 새 메시징 앱을 연결할 때 연락처에 대한 해당 앱 읽기 액세스를 허용하거나 거부할 수 있습니다.

내 CLG 소셜 토큰 프로그램에서 귀하의 ENS 이름은 귀하의 전화번호와 같이 공개되며 토큰을 발행 및 취소하여 귀하와 관련된 사람들의 목록에 대한 액세스 권한을 부여하거나 거부합니다. 원하는 경우 임의의 사용자에게 이러한 토큰을 부여할 수 있지만 대부분 소셜 플랫폼에 부여하여 해당 플랫폼이 귀하에게 표시할 게시물과 숨길 게시물(또는 귀하의 게시물을 볼 수 없는 사람)을 알 수 있도록 합니다.

(소셜 그래프를 구성하는 목록에 대한 쓰기 액세스는 일반 ENS NFT에 의해 제어될 수 있습니다. 지갑에 ENS 이름이 있는 경우 목록을 작성/업데이트/삭제할 수 있습니다. 가능한 한 가지 대안은 네 번째를 갖는 것입니다. NTFT 보유자에게 목록 쓰기 액세스 권한을 부여하는 사회 계약이므로 목록 관리를 일부 제3자에게 아웃소싱할 수 있습니다.)

  • 이러한 목록을 오프체인에서 호스팅하고 온체인에서 가리키면 몇 가지 이점이 있습니다.

  • 목록을 호스팅하는 엔드포인트에서 인증을 사용하여 공개적으로 볼 수 없도록 관계를 잠글 수 있습니다. 또는 누구나 읽을 수 있도록 공개할 수 있습니다.

  • 오프 체인 목록을 업데이트하는 데는 가스 비용이 들지 않습니다.

  • 이 접근 방식을 통해 소셜 공급자와 상호 운용 가능한 소셜 그래프 호스팅 서비스 시장을 만들 수 있습니다.

누구나 또는 서비스에서 귀하의 목록을 쉽게 찾을 수 있습니다.

토큰 액세스 제어 및 읽기 액세스

CLG 계약 구현의 주요 혁신은 토큰 액세스 제어입니다. 토큰 액세스 제어의 기본 개념은 특정 액세스 토큰이 포함된 지갑을 사용하여 호스트에 연결하지 않으면 호스트의 특정 데이터에 액세스할 수 없다는 것입니다.

예를 들어 지갑에 특정 NFT가 있는 엔드포인트에 연결하는 독자만 특정 파일을 볼 수 있도록 IPFS의 콘텐츠에 대한 액세스 제어를 토큰화할 수 있습니다.

CLG는 토큰 게이트를 사용하여 소셜 계약에 약간의 간접적인 정보를 추가하므로 팔로우, 음소거 또는 차단과 같은 특정 유형의 관계를 나타내는 대신 소셜 NFT는 소셜 그래프의 일부에 대한 읽기 액세스를 나타냅니다.

분명히 토큰 임계값이 작동하려면 플랫폼이 이를 준수해야 합니다. 아마도 플랫폼이 토큰 액세스 제어를 존중하지 않는 경우 관계 목록을 다른 플랫폼으로 전송하고 계약을 변경하여 필요한 경우 NFT를 재발행합니다.

또한 명확히 하기 위해 일부 사람들의 목록은 어느 시점에서 유출됩니다. 우리는 개인 데이터 침해의 세계에 살고 있으므로 데이터가 어딘가에 호스팅되면 일부 데이터가 손상될 것입니다. 나중 장에서 몇 가지 가능한 완화에 대해 논의할 것입니다.

계약 템플릿: CLG Follows

// 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 계약입니다.

모든 확장은 ERC 721 Enumerable을 포함하지 않은 것을 제외하고는 OCG와 동일합니다. 누군가가 자신의 CLG Follows 토큰을 열거하기를 원하는지 명확하지 않기 때문입니다.

  • 함수의 경우 OpenZeppelin 마법사의 출력을 다음과 같이 수정했습니다.

  • 관계(): OLG와 마찬가지로 사회 계약 유형을 반환합니다. 다시 말하지만 이것은 아마도 Solidity 컨트랙트에 필요하지 않을 것이고 나는 그것을 본 적이 없지만 그럼에도 불구하고 컨트랙트가 그 유형을 자체 보고하기를 원한다고 생각합니다. 그래서 잘 모르겠습니다. 기분이 상했다면 무시하십시오.

listURI()는 팔로우하고 있는(또는 계약 유형에 따라 음소거되거나 차단된) ENS 이름 목록인 JSON 개체에 대한 링크를 반환합니다. 이 URI를 비공개로 표시하고 싶지만 반드시 그럴 필요는 없습니다.

대부분의 경우 CLG Follows NTFT를 사용하여 소셜 플랫폼 소유의 주소에 게시합니다. 그렇게 하면 플랫폼에서 관심 목록을 읽고 올바른 게시물을 보여줄 수 있습니다.

그러나 팔로워가 다른 팔로워를 발견할 수 있도록 이러한 NTFT를 팔로워에게 보낼 수도 있습니다. 팔로워에게 에어드롭하거나 주화 금지를 해제하여 누구나 채굴할 수 있도록 함으로써 이를 수행할 수 있습니다.

다른 모든 계약은 위와 동일하게 작동하지만 이름과 기호가 다르고 Relationship() 및 listURI()에서 다른 값을 반환합니다.

가능한 변수

다른 서비스에서 목록이 유출되는 것이 걱정된다면 listURI()를 tokenURI(uint 256 tokenId)와 같은 것으로 변경하는 것이 매우 간단합니다. 각 토큰 소유자가 고유한 목록 URL을 갖도록 기본 URI. 목록 호스트의 일부 논리와 결합된 이 기능을 사용하면 다른 토큰 보유자가 기본 그래프의 다른 하위 그래프를 얻도록 목록을 분리할 수 있습니다. 그렇게 하면 플랫폼이 소유된 경우 내 그래프의 해당 부분만 손상됩니다.

tokenURI() 및/또는 listURI()에 의해 반환된 URL을 업데이트할 수 있기를 원할 수 있습니다. 이 경우 이러한 URL을 변수에 저장하고 생성자에서 초기화하고 업데이트를 위한 onlyOwner setter 함수를 제공해야 합니다. . 이렇게 하면 주조 비용이 증가하지만 개인이 아닌 서비스에만 제공하려는 경우에는 문제가 되지 않습니다.

제공하다

제공하다

여기에 설명된 두 가지 제안 모두 임시방편일지라도 생태계가 IPFS와 같은 분산 시스템으로 전환될 때까지 중앙 집중식 호스팅 서비스를 위한 장소를 제공합니다.

가장 확실한 유형의 서비스는 프로필 데이터, NTFT 메타데이터 및 토큰 제어의 JSON 목록(CLG의 경우)과 같은 URI 함수 중 하나에서 반환되는 모든 항목을 호스팅하는 것입니다.

마지막으로 사용자 및 조직의 요구에 맞게 계정을 확인하는 타사 서비스가 있을 수 있습니다.

요약하다

요약하다

내 온체인 소셜 그래프 제안이 여기서 설명하는 형식으로 채택될 것으로 기대하는지 모르겠습니다. 나는 완전히 잠긴 플랫폼의 현재 상태에서 그래프를 소유하고 어디를 가든지 쉽게 휴대할 수 있는 보다 이식 가능한 상태로 효과적으로 전환할 수 있는 방법에 대한 대화를 촉발하기 위해 이러한 아이디어를 더 많이 제시합니다.

이 게시물에서 다른 것을 얻지 못했다면 분산 원장 기술과 스마트 계약의 세계에서 2022년에는 우리 중 누구도 소셜 네트워크에 갇힐 필요가 없다는 점을 최소한 분명히 했으면 합니다. 이 잠금 문제를 해결하는 도구는 널리 사용 가능하므로 선택하여 사용하기만 하면 됩니다.

원본 링크

ENS
NFT
지갑
스마트 계약
Facebook
Telegram
공중 투하
Odaily 공식 커뮤니티에 가입하세요