수십억 명의 사용자를 보유한 Web3 소셜 그래프를 구축하는 방법은?

avatar
Foresight News
03-29
이 기사는 기계로 번역되었습니다
원문 표시
본 논문에서는 10억 명의 사용자를 가진 테이블에 소셜 그래프를 계층화하기 위한 두 가지 제안, 즉 온체인 그래프(OCG)와 체인 연결 그래프(CLG)를 제안합니다.

원제: 10억 명의 사용자 소셜 그래프

Jon Stokes 지음

편집자: Dan, W3.Hitchhiker

최근 일론 머스크가 트위터를 인수하면서 대형 소셜 네트워크에서 벗어나 독립적이거나 개방적인 대안으로 이전한다는 이야기가 커지고 있지만, 처음에 전 트위터 사용자로 구성된 활발한 커뮤니티에 합류하는 것을 꿈꾸던 사람들은 J6 이후 크로스 플랫폼 소셜 미디어가 사라진 이후 오른쪽에서 씨름해 온 문제에 곧 직면하게 될 것입니다. 바로 네트워크 잠금이 현실이라는 것입니다.

조정 문제, 선호도 연쇄, 신호 전달 및 기타 게임 이론적 개념에 대한 이론적, 전략적 분석을 수행할 수 있습니다. 이러한 방법이 문제를 이해하는 데 유용하다는 사실을 부인하지 않습니다. 하지만 Twitter와 Facebook이 수억 명의 사람들에게 미치는 강력한 영향을 이해하려면 인터넷 초창기의 간단한 경험적 법칙 만 알면 됩니다.

메트칼프의 법칙은 통신망의 가치가 연결된 사용자 수(n²)의 제곱에 비례한다고 말합니다. 메트칼프의 법칙은 1993년 조지 길더(George Gilder)가 로버트 메트칼프(Robert Metcalfe)의 이더넷(이더) 연구에 기인하여 이러한 형태로 처음 제안했습니다. 1980년경, 메트칼프의 법칙은 원래 사용자가 아닌 "호환되는 통신 장치"(팩스, 전화기 등)를 기준으로 표현되었습니다. 이 법칙은 원래 이더 연결을 설명하기 위해 고안되었기 때문에 인터넷의 세계화와 함께 사용자와 네트워크로 확장되었습니다.

사람들이 크고 조밀한 네트워크 그래프를 포기하고 작고 희소한 네트워크 그래프를 선택하도록 하는 것은 거의 불가능합니다. 단순히 전자에는 가치가 있고 후자에는 가치가 없다는 이유만으로 말입니다.

이상하게도, web3는 이 문제를 해결합니다. 적어도 간단한 스마트 계약을 사용하여 블록체인을 거대한 사용자 테이블에서 거대한 소셜 그래프로 전환한다면 가능합니다.

이론적 근거 및 이전 연구

블록체인은 개방적이고 공개적이며 어떤 특정 주체에 의해 통제되지 않는 거대한 공유 사용자 테이블 역할을 할 수 있으며, 실제로 그렇게 기능합니다. 제가 "10억 명 사용자 테이블"에서 썼듯이,

공개 블록체인은 인터넷 전체를 위한 단일 대규모 사용자 테이블과 같으며, 차세대 분산 애플리케이션은 이를 기반으로 구축될 것입니다.

대신, 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

마지막 두 테이블은 항상 데이터 폭발이 발생하기 때문에 사용자 수가 급격히 늘어나면 운영이 어려워집니다.

따라서 더 나은 접근 방식은 이미 첫 번째 테이블(즉, users)을 가지고 있는 기존 블록체인에 user_follows_user 조인 테이블을 추가하는 것이라고 생각합니다. ( user_mutes_user 와 같은 다른 유형의 관계에 대해서도 조인을 확장할 수 있지만, 지금은 간단하게 설명하겠습니다.)

이 사용자 간 조인 테이블도 사용자 수에 따라 비선형적으로 커지지만, 성장률은 더 느리고, 더 중요한 점은 이를 표현하는 데 필요한 추가 데이터 양(소모하는 추가 블록 공간의 양)이 게시 테이블보다 훨씬 낮다는 것입니다.

제가 이렇게 말하는 이유는 사용자와 팔로워 관계가 모든 대형 소셜 네트워킹 플랫폼의 주요 락인(lock-in) 요인이기 때문입니다. 만약 트위터나 페이스북 소셜 그래프 전체가 공개되어 게시물이나 데이터 집약적인 소셜 네트워킹 경험을 호스팅하려는 다른 소셜 플랫폼에 쉽게 접근할 수 있다면, 해당 플랫폼의 락인은 사실상 0이 될 것입니다.

온체인 소셜 그래프는 어떻게 생겼을까

제 트위터 그래프 전체가 온체인 표현된다고 상상해 보세요. 실제 계정과 팔로워 관계까지 포함해서요. 그래프에 있는 트위터 게시물(그리고 관련 좋아요, 리트윗, 인용 리트윗 등)을 보려면 지갑을 통해 Twitter.com에 연결해야 합니다. 그런데 tribel.com이나 gab.com, 또는 각자의 편향성과 관리 정책을 가진 다른 소셜 플랫폼으로 이동하고 싶다고 가정해 보겠습니다. 만약 그들이 블록체인 온체인 제 소셜 그래프를 읽을 수 있다면, 저는 그곳에 지갑을 연결하여 동일한 연결을 확인하고, 해당 사이트에 게시된 게시물을 모두 볼 수 있습니다.

그다지 매력적이지 않게 들릴지 모르지만, Tribel 에서 새로운 사람을 팔로우하면 Twitter와 Gab 에서도 그 사람을 팔로우하게 된다는 사실을 생각해 보세요. 그리고 동일한 온체인 사용자 및 관계 그래프를 사용하는 다른 모든 소셜 플랫폼에서도 팔로우하게 됩니다. 팔로우 취소와 차단도 같은 방식으로 작동합니다. 한 곳에서 한 번만 하면 그래프의 변경 사항이 모든 곳에 즉시 반영됩니다.

이 글을 읽고 이 혜택을 누리고 싶어 하시는 분들은 위에서 설명한 것과 같은 세상에서 필연적으로 어떤 일이 일어날지 이미 알고 계실 겁니다. 누군가 단일 인터페이스를 통해 모든 네트워크에서 글을 읽고 게시할 수 있는 올인원 클라이언트를 만들 것입니다. 그러면 별도의 서비스를 운영하는 것은 의미가 없고, 결국 모두 문을 닫게 될 것입니다... 아니면 과연 그럴까요?

앞으로 나올 것들의 미리보기: 전화번호 + 연락처 + 메시징 앱

제가 설명하는 세상은 이미 프로토타입 상태로 존재합니다. 즉, 전화번호에 연결되어 연락처 데이터베이스에서 데이터를 가져오는 서로 경쟁하는 메시징 프로토콜의 형태입니다. 전화번호 시스템은 수십억 명의 사용자 테이블에 대한 프로토타입이며 , 표준 Vcard 형식을 읽고 쓸 수 있는 분산 연락처 애플리케이션은 해당 테이블을 기반으로 관계 그래프를 형성합니다.

전화번호 + 연락처 조합을 활용하는 메시징 프로토콜이 많이 있으며, 그 결과는 제가 여기서 설명한 소셜 네트워크와 비슷합니다. 예를 들어, 텔레그램에 처음 로그인하면 연락처를 스캔하고, 기존 네트워크가 이 새 앱에 바로 추가됩니다.

따라서 Signal, Telegram, WhatsApp, iMessage 또는 기존 SMS를 통해 동일한 전화번호로 메시지를 주고받을 수 있습니다. 이는 모두 사용자와 네트워크의 다른 사용자가 어떤 메시징 프로토콜을 사용할지에 따라 달라집니다.

ICQ 시절부터 시작된 메시징 앱의 탈중앙화 와 재중앙화는 끊임없이 반복되고 있으며, WhatsApp/Signal/Telegram/Facebook 등의 시대에도 여전히 진행 중입니다. 이러한 다양한 플랫폼을 지원하는 올인원 메시징 클라이언트를 단일 창에서 찾을 수 있습니다.

이러한 메시징 앱들은 모두 동일한 개방형 전화번호 시스템과 상호 운용 가능한 연락처 앱 및 서비스 생태계에서 각자의 정체성을 도출하기 때문에 어떤 앱도 침해당하지 않습니다. 앱들은 모두 공존하며 서로 다른 기능을 제공하며, 많은 사람들이 서로 다른 니즈와 선호도를 가진 연락처의 여러 하위 그룹과 소통하며 앱을 전환합니다. 소셜 그래프를 온체인 이동시킨다면 이러한 역학 관계가 지속될 것으로 예상합니다.

구성 가능성과 사회적 연결에 관하여

플랫폼마다 사용자들이 서로 연결할 수 있는 소셜 연결 유형이 다릅니다. 페이스북에는 친구, 팔로잉, 차단 기능이 있고, 트위터에는 팔로잉, 뮤트, 차단 기능이 있습니다. 이러한 기능은 플랫폼에 유용하지만, 블록체인에 더 적합하고 구성이 용이하도록 개선할 수 있습니다.

구성 가능성은 이러한 작고, 분리되어 있고, 잘 정의된 도구를 혼합하고 일치시켜 다양한 효과와 기능을 얻을 수 있다는 것을 대략적으로 의미하는 컴퓨터 과학 용어입니다.

페이스북의 "친구"를 생각해 보세요. 페이스북 자체의 연결 방식이지만, "팔로우"라는 의미도 있습니다. 누군가를 친구로 추가하면 자동으로 팔로우되기 때문입니다. 트위터에서 "차단"은 "뮤트"를 의미합니다. 누군가를 차단하면 사실상 그 사람을 뮤트하고 게시물도 볼 수 없게 됩니다.

아래의 두 가지 소셜 그래프 제안에 대해 저는 더 깔끔하고 구성 가능한 소셜 그래프 관계 집합을 제안하고 싶습니다.

  • 팔로잉: 팔로우하는 사람의 게시물을 읽을 수 있습니다.
  • 음소거: 음소거한 사람의 게시물은 읽을 수 없습니다.
  • 차단: 차단한 사람은 게시물을 읽을 수 없습니다.

이 방식에서 차단 은 뮤트와 차단의 합성어이므로 동일한 대상 주소에 대한 두 가지 작업이 결합된 것입니다(예: annoyinghater.eth를 차단하려면 해당 주소를 뮤트한 다음 차단합니다).

다른 사람의 게시물은 보고 싶지만 내 게시물은 보고 싶지 않다면 , 팔로우한 후 차단하면 됩니다. 반대로, 콘텐츠를 탐색하거나 주기적으로 음소거를 해제해서 계속 읽고 싶다면, 팔로우한 후 음소거하면 됩니다.

저는 이런 방식으로 관계를 명확히 하려고 노력했습니다. 왜냐하면 다음 장에서 계약과 관계에 대해 추론하기가 더 쉬워지기 때문입니다.

내 두 가지 제안에 대한 배경 정보

이 글의 나머지 부분에서는 소셜 그래프를 10억 ​​명의 사용자로 구성된 표로 계층화하기 위한 두 가지 제안을 제시합니다.

  • 첫 번째인 온체인 그래프(OCG)는 더 개방적이고 간단하지만 수수료가 더 비싸기 때문에 어떤 사람들은 좋아할 것이고 어떤 사람들은 싫어할 것입니다.
  • 두 번째인 체인링크 그래프(CLG) 는 더 복잡하지만 저렴하고, 더 많은 제어 기능과 프라이버시를 제공하기 때문에 대부분의 사람들이 선호할 것으로 예상됩니다. 하지만 플랫폼은 두 가지 모두를 지원할 수 있습니다.

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

  • 비분해성 토큰(NFT)과 비분해성 비양도성 토큰(NTFT, Soul-Bound 토큰이라고도 함).
  • 이더 도메인 이름 서비스
  • 스마트 계약

솔리디티(이더 의 스마트 컨트랙트 프로그래밍 언어)를 조금 아는 것도 도움이 될 것입니다. 위의 내용 중 하나 또는 전부가 잘 이해되지 않더라도, 기본적인 내용은 충분히 이해할 수 있도록 이 글을 작성했습니다.

두 제안 모두 ENS를 신원 루트로 사용하고, 위에서 설명한 세 가지 유형의 소셜 관계(팔로우, 뮤트, 차단)를 나타내는 상당히 표준적인 ERC721 NFT 계약의 주소를 포함하는 새로운 주소 레코드를 추가한다고 가정합니다. 이 세 가지 계약의 목적은 제안마다 크게 다르지만, 각 계약의 주소를 세 개의 특수 ENS 주소 레코드에 저장한다는 기본 아이디어는 동일합니다.

ENS 레코드의 예, 이 경우 내 ENS 이름입니다.

또한, 소셜 사용자 데이터 URI에 대한 추가 ENS 레코드를 제안하여 가스 비용 없이 소셜 데이터를 업데이트할 수 있도록 하고 싶습니다. 제안된 profileURI 레코드는 타사 플랫폼에 숨겨진 JSON 객체에 연결되며 다음과 같은 형태를 갖습니다.

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

-H "수락: application/json"

{

"이름": "jonstokes.(eth|com)",

"bio": "작가. 코더. 파멸주의자, 기술 낙관주의자. 암호학 전문가.",

"웹사이트": "https://jonstokes.com/",

"위치": "오스틴, 텍사스"

}

프로필 JSON의 일부 내용은 기존 ENS 필드와 중복되지만 괜찮습니다. 목적은 소셜 플랫폼에 표시할 내용을 제공하고 사용자가 ENS 레코드를 업데이트하는 데 가스를 소비하지 않고도 소셜 프로필을 변경할 수 있도록 하는 것입니다.

권장 사항 1: 온체인 그래프

온체인 그래프(On-Chain Graph) 개념은 위에서 언급한 세 가지 관계를 표현하기 위해 NTFT를 사용합니다. 다음 세 가지 소셜 컨트랙트의 경우, ENS NFT를 보유한 동일한 지갑이 해당 컨트랙트도 소유해야 하며, 해당 컨트랙트에 해당하는 세 개의 ENS 주소 레코드는 해당 컨트랙트를 가리켜야 합니다.

  • OCG 팔로워: 제 OCG 팔로워 계약에서 NTFT를 지갑에 입금하시면 저를 팔로우하게 됩니다. 저희 중 누구든 이 NFT를 파괴할 수 있으며, 그렇게 되면 저를 팔로우 취소하게 됩니다.
  • OCG 차단: 제 OCG 고스트 계약에서 NTFT를 당신의 지갑으로 에어드랍 하면, 저는 당신을 차단합니다. 당신의 거래를 처리하기 위해 이 NTFT를 파기할 수 있는 사람은 저뿐입니다.
  • OCG Mute: 제 OCG Mute 계약에서 NTFT를 당신 지갑으로 에어드랍 때, 이미 당신은 뮤트된 상태입니다. 뮤트를 해제하려면 이 NTFT를 파기해야 합니다.

이 세 가지 경우의 의미는 기본적으로 "계약 소유자인 나에게 상대적으로 당신은 X이다"입니다. 여기서 "X"는 팔로워, 블록 또는 뮤트입니다.

다음은 팔로워 계약서의 샘플입니다.

// SPDX-License-Identifier: MIT

프래그마 솔리디티 ^0.8.4;

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

"@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol"을 가져옵니다.

"@openzeppelin/contracts/security/Pausable.sol"을 가져옵니다.

"@openzeppelin/contracts/access/Ownable.sol"을 가져옵니다.

"@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol"을 가져옵니다.

"@openzeppelin/contracts/utils/Counters.sol"을 가져옵니다.

계약 OCGFollower는 ERC721, ERC721Enumerable, Pausable, Ownable, ERC721Burnable입니다.

Counters.Counter에 Counters를 사용합니다.

카운터.카운터 private _tokenIdCounter;

생성자() ERC721("OCGFollower", "OCGF") {}

함수 _baseURI() 내부 순수 오버라이드는 (문자열 메모리)를 반환합니다.

"https://jonstokes.com/ocg/follower"를 반환합니다.

}

함수 관계() public {

"ocg 팔로워"를 반환합니다.

}

함수 pause() public onlyOwner {

_정지시키다();

}

함수 unpause() public onlyOwner {

_일시 중지 해제();

}

함수 safeMint(주소) 공개 {

//소유자 외의 누구도 주조하지 못하도록 방지

//자신이 소유하지 않은 주소에 대한 토큰.

require(isOwner(_msgSender()) || (_msgSender() == to), "이 주소로 민트를 발행할 수 없습니다");

uint256 토큰 ID = _토큰 ID 카운터.현재();

_tokenIdCounter.증가();

_safeMint(to, 토큰 ID);

}

함수 _beforeTokenTransfer(주소 시작, 주소 종료, uint256) 순수 내부 재정의 {

//토큰 전송을 비활성화합니다.

require(from == address(0) || to == address(0), "전송할 수 없습니다.");

}

// 다음 함수는 Solidity에 필요한 재정의입니다.

함수 supportsInterface(bytes4 interfaceId)

공공의

보다

오버라이드(ERC721, ERC721Enumerable)

(bool)을 반환합니다

{

super.supportsInterface(interfaceId)를 반환합니다.

}

}

Solidity에 익숙하다면 이 매우 간단한 (그리고 테스트되지 않은!) 계약이 무엇을 하려는지 알 수 있을 것입니다.

먼저 확장자:

  • ERC721Enumerable 확장 기능이 포함되어 토큰 보유자가 전체 체인을 스캔하지 않고도 소셜 네트워킹 클라이언트에 등록될 수 있습니다.
  • Pausable 사용하는 이유는 기본적으로 계정을 잠시 잠그기 위해 채굴을 일시 중지할 수 있기 때문입니다. 즉, 새로운 팔로워를 더 이상 받지 않습니다.
  • Ownable 계약 소유자만 해야 하는 일들이 있기 때문에 필수적입니다. 더 강력한 역할 기능을 사용할 필요는 없다고 생각합니다.
  • ERC721Burnable 팔로 관계를 제거하기 위해 토큰을 소각할 수 있어야 하기 때문에 여기에 있습니다. 표준 burn() 함수는 필요한 권한, 즉 소유자 또는 토큰 소유자만 토큰을 소각할 수 있도록 포함되어 있습니다.
  • 편리하게도 tokenID 자동으로 증가하도록 Counters 포함시켰습니다.

이제 OpenZeppelin 마법사의 출력을 수정하세요.

  • safeMint() 수정된 후에는 계약 소유자만 다른 사람의 주소로 토큰을 발행할 수 있습니다. 계약 소유자가 아닌 모든 사용자는 계약을 호출한 주소로만 토큰을 발행할 수 있습니다.
  • _beforeTokenTransfer() 기본적으로 토큰 전송 기능을 비활성화하고 간단한 소울바운드 토큰을 생성하도록 재정의되었습니다.
  • relationship() 함수는 계약을 쉽게 쿼리하고 NFT가 나타내는 관계를 확인할 수 있는 편리한 메서드입니다. 저는 이 함수를 포함하는 것에 찬성하지 않았지만, 유용할 것 같습니다.

모든 것은 정말 간단합니다. OCG 차폐형과 OCG 무소음형 모두에 다음과 같은 작은 변경을 하면 됩니다.

  1. 계약명 및 기호 변경
  2. relationship() 과 가능하면 baseURI() 의 반환 값을 변경하여 표현하려는 관계(예: "muted" 또는 "ghosted")를 반영합니다.
  3. safeMint() 와 burn() onlyOwner 함수로 변경하여 계약 소유자만 이 두 함수를 호출할 수 있도록 합니다.

물론 이는 플랫폼이 이러한 계약을 올바른 방식(예: 팔로우, 차단, 뮤트)으로 시행하는지 여부에 따라 달라집니다. 하지만 이는 생각보다 덜 위협적이고 불안정합니다. 특정 소셜 플랫폼이 여러분이 중요하게 생각하는 계약을 시행하지 않는다면, 해당 플랫폼을 이용하지 않는 것이 좋습니다.

주의가 증가하다

safeMint 에 payable 추가한 후 setMintRate 사용하여 다음 항목에 대해 지불해야 하는 가격을 설정할 수 있습니다. 예를 들어 다음과 같습니다.

uint256 공개 mintRate = 0.01 ether;

함수 setMintRate(uint256 mintRate_) public onlyOwner {

민트레이트 = 민트레이트_;

}

함수 safeMint(주소) 공개 지불 가능 {

// pay-to-follow가 필요합니다

require(msg.value >= mintRate, "이더를 발행할 만큼 이더가 부족합니다");

//소유자 외의 누구도 주조하지 못하도록 방지

//자신이 소유하지 않은 주소에 대한 토큰.

require(isOwner(_msgSender()) || (_msgSender() == to), "이 주소로 민트를 발행할 수 없습니다");

uint256 토큰 ID = _토큰 ID 카운터.현재();

_tokenIdCounter.증가();

_safeMint(to, 토큰 ID);

}

이 제안에 더 많은 수정과 기능을 추가할 수 있을 것 같지만, 간단하고 이해하기 쉬운 것부터 시작하는 게 좋을 것 같습니다.

제안 2: 체인 연결 그래프

위에 설명된 OCG 계약은 충분히 간단하지만, 이 계획에는 많은 사람들 사이에 의견 불일치를 일으킬 수 있는 몇 가지 특이점이 있습니다.

  • 모든 것이 공개되어 있으며, 차단 및 뮤팅을 포함한 온체인. 계정을 잠글 수는 없지만, 이 문제에 대한 해결책은 다른 계정을 사용하는 것일 수 있습니다.
  • 모든 행동에는 가스 비용이 발생하므로, 누구를 팔로우하고, 차단하고, 뮤트할지 신중하게 선택해야 합니다. 하지만 가스 비용이 너무 높으면 네트워크를 사용할 수 없게 될 수 있습니다.
  • 유료 팔로우는 네트워크나 특정 계정에 적합한 기능일 수도 있고 아닐 수도 있지만, 선택권은 있습니다.

이 제안의 이러한 특징을 모든 사람이 좋아할 것은 아니므로, 사용자와 플랫폼에 보다 세부적인 통제권, 특히 누가 어떤 정보를 볼 수 있는지에 대한 통제권을 부여하고 사용 비용이 저렴한 대안적인 사회적 계약을 제안하고자 합니다.

체인 연결 그래프(CLG)의 기본 아이디어는 다음과 같습니다. NFT를 통해 소셜 관계(팔로우, 차단, 음소거) 온체인 직접 표현하는 대신, 이러한 관계를 오프체인에 저장하고 온체인 토큰을 사용하여 이러한 관계를 발견하고 접근합니다.

  • 발견: 이 계약은 일종의 소셜 관계(예: 팔로우, 음소거 또는 차단)를 선언하려는 ENS 이름의 JSON 목록에 대한 링크를 반환하는 listURI() 함수를 제공합니다.
  • 접근: listURI() 에서 반환된 링크가 토큰으로 제어되는 경우, 계약의 토큰은 보유자에게 메타데이터에서 찾은 링크에 대한 읽기 접근 권한을 부여합니다.

그러면 사회적 관계는 온체인 에 직접적으로 존재하지 않고, 일련의 계약과 URL을 통해 체인에 연결됩니다.

OCG와 마찬가지로 세 가지 사회적 관계는 모두 스마트 계약으로 관리되지만 CLG의 의미는 다릅니다.

  • 팔로잉: 팔로우하고 있는 ENS 이름에 대한 링크의 JSON 목록을 포함하고 있으며, 이를 통해 발급된 토큰은 해당 팔로우 목록에 대한 읽기 액세스 권한을 부여합니다.
  • muted: 음소거할 ENS 이름에 대한 링크의 JSON 목록을 포함하고 있으며, 발급한 토큰은 해당 음소거 목록에 대한 읽기 액세스 권한을 부여합니다.
  • 블록: 차단하는 ENS 이름에 대한 링크의 JSON 목록이 포함되어 있으며, 이를 통해 발급된 토큰은 해당 차단 목록에 대한 읽기 액세스 권한을 부여합니다.

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

이 섹션에서 제가 제안하는 내용은 제가 메시징 앱에 대해 설명한 전화번호 + 주소록 조합과 유사하다고 생각하시면 됩니다. 전화번호는 (준)공개이며, 새로운 메시징 앱을 연결할 때 해당 앱이 연락처에 접근하는 것을 허용하거나 거부할 수 있습니다.

제 CLG 소셜 토큰 플랜에서는 ENS 이름이 전화번호처럼 공개되며, 토큰을 발급하고 취소하여 관계가 있는 사람들의 목록에 대한 접근 권한을 부여하거나 거부할 수 있습니다. 원하는 경우 무작위 사용자에게 이 토큰을 부여할 수 있지만, 주로 소셜 플랫폼에 부여하여 어떤 게시물을 보여주고 어떤 게시물을 숨길지(또는 어떤 게시물을 보지 말아야 할지)를 파악하는 데 사용합니다.

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

이러한 목록을 체인 밖에서 호스팅하고 온체인 상에서 이를 가리키는 데는 여러 가지 이점이 있습니다.

  • 목록을 호스팅하는 엔드포인트에서 인증을 사용하여 관계가 대중에게 공개되지 않도록 잠글 수도 있고, 누구나 읽을 수 있도록 공개 상태로 둘 수도 있습니다.
  • 오프체인 목록을 업데이트하는 데는 가스 비용이 들지 않습니다.
  • 이 솔루션을 통해 소셜 서비스 제공자와 상호 운용되는 소셜 그래프 호스팅 서비스 시장을 구축할 수 있습니다.
  • 귀하의 목록은 누구나 또는 어떤 서비스에서도 쉽게 발견될 수 있습니다.

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

CLG 계약을 가능하게 하는 핵심 혁신은 토큰 접근 제어입니다. 토큰 접근 제어의 개념은 특정 액세스 토큰이 포함된 지갑을 사용하여 호스트에 연결하지 않으면 호스트의 특정 데이터에 접근할 수 없다는 것입니다.

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

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

토큰 접근 제어가 제대로 작동하려면 플랫폼이 이를 준수해야 합니다. 플랫폼이 토큰 접근 제어를 준수하지 않는다면, 관계 목록을 다른 플랫폼으로 옮기고 계약을 변경하며 필요에 따라 NFT를 재발행해야 할 것입니다.

또한, 어떤 사람들의 목록은 언젠가는 유출될 수 있다는 점을 분명히 해 두십시오. 우리는 개인 정보가 유출되는 세상에 살고 있기 때문에, 데이터가 어딘가에 호스팅되어 있다면 그 중 일부가 유출될 수 있습니다. 이후 섹션에서 몇 가지 가능한 완화책을 논의하겠습니다.

계약 템플릿: CLG가 따릅니다

다음 계약은 위의 OCG 계약과 매우 유사한 표준 ERC721 NTFT 계약입니다.

// SPDX-License-Identifier: MIT

프래그마 솔리디티 ^0.8.4;

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

"@openzeppelin/contracts/security/Pausable.sol"을 가져옵니다.

"@openzeppelin/contracts/access/Ownable.sol"을 가져옵니다.

"@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol"을 가져옵니다.

"@openzeppelin/contracts/utils/Counters.sol"을 가져옵니다.

CLGFollows 계약은 ERC721, Pausable, Ownable, ERC721Burnable입니다.

Counters.Counter에 Counters를 사용합니다.

카운터.카운터 private _tokenIdCounter;

생성자() ERC721("CLGFollows", "CLGF") {}

함수 _baseURI() 내부 순수 오버라이드는 (문자열 메모리)를 반환합니다.

"https://jonstokes.com/clgfollows/"를 반환합니다.

}

함수 listURI() 공개 {

"https://jonstokes.com/clgfollows/list"를 반환합니다.

}

함수 관계() public {

"clg가 다음과 같습니다"를 반환합니다.

}

함수 pause() public onlyOwner {

_정지시키다();

}

함수 unpause() public onlyOwner {

_일시 중지 해제();

}

함수 safeMint(주소) public onlyOwner {

uint256 토큰 ID = _토큰 ID 카운터.현재();

_tokenIdCounter.증가();

_safeMint(to, 토큰 ID);

}

함수 _beforeTokenTransfer(주소 시작, 주소 종료, uint256) 순수 내부 재정의 {

//토큰 전송을 비활성화합니다.

require(from == address(0) || to == address(0), "전송할 수 없습니다.");

}

}

모든 확장 기능은 OCG와 동일하지만, CLG Follows 토큰이 열거되는 것을 원하는 사람이 있을지 불분명하므로 ERC721Enumerable 포함하지 않았습니다(게다가 채굴 가스 비용도 증가합니다).

함수와 관련하여 OpenZeppelin 마법사의 출력을 다음과 같이 변경했습니다.

  • relationship() : OLG와 마찬가지로 소셜 계약의 유형을 반환합니다. 다시 말하지만, Solidity 계약에서는 필요하지 않을 수도 있고, 실제로 구현된 사례도 본 적이 없지만, 계약에서 자체 유형을 보고하는 기능이 있으면 좋겠다고 생각합니다. 그래서 잘 모르겠습니다. 불쾌하시다면 무시해 주세요.
  • listURI() 팔로우 중인(또는 계약 유형에 따라 뮤트 또는 차단 중인) ENS 이름 목록이 포함된 JSON 객체 링크를 반환합니다. 이 URI는 비공개로 태그 하는 것을 선호하지만, 필수는 아닙니다.

대부분의 경우 CLG Follows NTFT를 사용하여 소셜 플랫폼이 소유한 주소에 게시합니다. 이렇게 하면 플랫폼에서 팔로우 목록을 읽고 올바른 게시물을 표시할 수 있습니다.

하지만 팔로워들에게 NTFT를 보내 팔로워들이 다른 팔로워들을 찾을 수 있도록 할 수도 있습니다. 팔로워들에게 NTFT를 에어드랍 하거나, 채굴 블록을 잠금 해제하여 누구나 코인을 생성할 수 있도록 하는 방법이 있습니다.

다른 모든 계약은 위에서 설명한 대로 정확히 작동하지만 이름과 기호가 다르고 relationship() 및 listURI() 에서 다른 값을 반환합니다.

가능한 변수

여러 서비스에서 목록이 유출될까 걱정된다면, listURI()를 tokenURI(uint256 tokenId) 와 비슷한 형태로 바꾸는 것이 매우 간단합니다. 즉, 시그니처가 listURI(uint256 tokenId) 인 것입니다. 이 방식은 tokenID 기본 URI 끝에 연결하여 각 토큰 소유자가 각자의 목록 URL을 갖도록 합니다. 이 기능을 목록 호스트의 로직과 결합하면 목록을 분리하여 각 토큰 소유자가 기본 그래프의 각기 다른 하위 그래프를 가질 수 있도록 합니다. 이렇게 하면 플랫폼이 침해되더라도 그래프의 해당 부분만 유출됩니다.

OCG처럼 safemint 유료 기능으로 만들고 목록에 접근하는 사람들에게 요금을 부과할 수 있습니다. OCG 섹션의 코드에서 이에 대한 예시를 확인하세요.

tokenURI() 및/또는 listURI() 에서 반환된 URL을 업데이트하고 싶을 수 있습니다. 이 경우 해당 URL을 변수에 저장하고, 생성자에서 초기화하고, onlyOwner setter 메서드를 사용하여 업데이트해야 합니다. 이렇게 하면 발행 비용이 증가하지만, 개인이 아닌 서비스에만 URL을 제공할 경우 문제가 되지 않을 수 있습니다.

제공하다

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

가장 명확한 서비스 유형은 URI 함수 중 하나에서 반환된 모든 것을 호스팅하는 것입니다. 여기에는 프로필 데이터, NTFT 메타데이터, 토큰 컨트롤의 JSON 목록(CLG의 경우)이 포함됩니다.

또 다른 유용한 서비스는 API를 통해 온체인 소셜 데이터를 제공하는 Infura의 특수 버전입니다. 또는, Infura가 소셜 데이터 전용 API를 제공할 수도 있습니다.

마지막으로, 사용자와 조직의 요구에 맞춰 계정을 검증하는 제3자 서비스가 있을 수 있습니다.

요약하다

제가 제안한 온체인 소셜 그래프가 여기에 설명한 형태로 채택될지는 잘 모르겠습니다. 제가 이러한 아이디어를 제시하는 이유는 현재의 완전한 플랫폼 종속 상태에서 벗어나 그래프를 소유하고 쉽게 휴대할 수 있는 더욱 휴대성이 뛰어난 상태로 효과적으로 전환할 수 있는 방법에 대한 논의를 촉진하기 위해서입니다.

위에 언급한 것 중 일부는 web5 제안과 비슷해 보이지만, 주요 차이점은 두 가지 아이디어가 더 단순하고 스마트 계약과 기존 온체인 ID 공급자(ENS, 그리고 온체인 유사한 공급자)를 활용하도록 설계되었다는 것입니다.

이 글에서 다른 것을 얻지 못하더라도, 분산원장 기술과 스마트 계약이 존재하는 세상에서 2022년에는 누구도 소셜 네트워크에 갇힐 필요가 없다는 것을 최소한 보여주었다고 믿습니다. 이러한 갇힘 문제를 해결할 수 있는 도구는 널리 존재하므로, 우리는 그것들을 선택하고 활용하기만 하면 됩니다.

출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
즐겨찾기에 추가
코멘트
관련 콘텐츠