Tiêu đề ban đầu: "The Billion User Social Graph》

Tiêu đề ban đầu: "

Tác giả: Jon Stokes

Biên soạn gốc: Dan, W 3. Người quá giang

Với việc Elon Musk tiếp quản Twitter gần đây, đã có nhiều cuộc thảo luận về việc chuyển từ mạng xã hội lớn hơn sang các lựa chọn thay thế độc lập hoặc cởi mở, nhưng đối với tất cả những người mới bắt đầu mơ mộng về việc tham gia cộng đồng thịnh vượng gồm những cư dân cũ của Twitter, sẽ sớm thôi là một vấn đề mà cánh hữu phải vật lộn kể từ cuộc thanh lọc mạng xã hội đa nền tảng sau J6: khóa trực tuyến là có thật.Bạn có thể thực hiện phân tích lý thuyết và chiến lược về các vấn đề phối hợp, tầng sở thích, tín hiệu và các khái niệm kiểu lý thuyết trò chơi khác - Tôi không phủ nhận rằng đây là những cách hữu ích để hiểu vấn đề - nhưng hiểu được ảnh hưởng mạnh mẽ của Twitter và Facebook đối với hàng trăm hàng triệu người trong chúng ta , tất cả những gì bạn thực sự cần biết là。

kinh nghiệm đơn giản

Định luật Metcalfe phát biểu rằng giá trị của mạng viễn thông tỷ lệ thuận với bình phương số người dùng được kết nối của hệ thống (n 2 ). Định luật Metcalfe ban đầu được xây dựng dưới dạng này bởi George Gilder vào năm 1993 và được coi là công trình của Robert Metcalfe trên Ethernet. Vào khoảng năm 1980, Định luật Metcalfe ban đầu không được thể hiện theo đơn vị người dùng mà theo đơn vị "thiết bị liên lạc tương thích" (ví dụ: máy fax, điện thoại). Chỉ sau này với quá trình toàn cầu hóa Internet, luật này mới được áp dụng cho người dùng và mạng, vì ban đầu nó được dùng để mô tả các kết nối Ethernet.

Hầu như không thể khiến mọi người từ bỏ một biểu đồ mạng lớn, dày đặc để ủng hộ một biểu đồ mạng nhỏ, thưa thớt và lý do duy nhất là cái trước có giá trị còn cái sau thì không.

Tuy nhiên, thật kỳ lạ, web3 giải quyết được vấn đề này. Hoặc ít nhất nó có thể giải quyết vấn đề này nếu chúng ta sử dụng một số hợp đồng thông minh đơn giản để biến chuỗi khối từ một bảng người dùng khổng lồ thành một biểu đồ xã hội khổng lồ.

Cơ sở lý thuyết và công việc trước đâyCác chuỗi khối có thể và thực hiện chức năng như một bảng người dùng rộng lớn, được chia sẻ, mở và công khai, không bị kiểm soát bởi bất kỳ thực thể nào.

Như tôi đã viết trong Bảng tỷ người dùng:
Chuỗi khối công khai tương đương với một bảng người dùng quy mô lớn duy nhất cho toàn bộ Internet, trên đó làn sóng ứng dụng phân tán tiếp theo sẽ được xây dựng.
Thay vào đó là một mạng phi tập trung gồm các kho dữ liệu người dùng được kết nối bằng API, một kho lưu trữ dữ liệu người dùng phi tập trung duy nhất được truy cập thông qua một giao thức mở và một mạng lưới các nút lưu trữ phi tập trung. Như vậy, một chuỗi khối lưu giữ danh tính thể hiện sự phân cấp của lớp triển khai lưu trữ dữ liệu và tái tập trung hóa lớp truy cập lưu trữ dữ liệu.
Hãy tưởng tượng LinkedIn, Reddit và Github đều chuyển các bảng người dùng của họ (và rất nhiều dữ liệu độc quyền của họ như xác nhận, điểm và lịch sử hoạt động) sang BitClout. Ngay lập tức, đây là những gì xảy ra: Mọi người dùng Github cũng là người dùng Reddit, người dùng LinkedIn và người dùng BitClout. Tương tự, mọi người dùng Reddit cũng là người dùng Github, người dùng LinkedIn và người dùng BitClout. Tôi có thể tiếp tục, nhưng bạn sẽ nhận được điểm.

Mọi công ty được xây dựng trên cùng một bảng người dùng ảo đều có quyền truy cập tức thì vào các hiệu ứng mạng của mọi công ty khởi nghiệp khác trên bảng đó. Mỗi khi một công ty trên chuỗi tham gia một người dùng mới, thì dịch vụ của bạn cũng có một người dùng mới. (Theo một cách nào đó. Họ có thể chưa tích cực sử dụng dịch vụ của bạn, nhưng họ thực sự là những người dùng tiềm năng của dịch vụ của bạn).BitcloutBài viết trước đã sử dụng

(chuỗi trong dự án đó hiện được gọi là DeSo) là một ví dụ điển hình về chuỗi khối có thể hỗ trợ trường hợp sử dụng này. Nhưng dù tôi rất phấn khích về toàn bộ sự việc của DeSo, thì mọi chuyện lại không tuyệt vời như vậy.

Đây không phải là nơi để thực hiện khám nghiệm tử thi Bitclout/DeSo, nhưng sẽ rất hợp lý khi đánh dấu một khía cạnh quan trọng của cuộc thảo luận hiện tại của chuỗi khối này. Bitclout cố gắng đưa toàn bộ mạng xã hội vào chuỗi, trong đó mỗi bài đăng được viết trên chuỗi dưới dạng một đối tượng có thể tích lũy thu nhập (thông qua Bitclout Diamonds). Điều đó thật thông minh, nhưng bất kỳ blockchain nào đang cố gắng lưu trữ nội dung thực tế sẽ thấy nhu cầu dữ liệu của nó tăng tuyến tính với số lượng người dùng và kết nối.

Nhóm Bitclout đã rất quen thuộc với vấn đề tăng trưởng dữ liệu không giới hạn này và đã dành rất nhiều nỗ lực kỹ thuật thực sự để cố gắng giải quyết nó. Nhưng nhìn lại, tôi thực sự nghĩ rằng họ đang cố gắng làm quá nhiều thứ cùng một lúc. Họ chỉ nên tập trung vào vấn đề tính di động của biểu đồ xã hội.

• users

• user_follows_user

• posts

• user_likes_post

Được mô tả trong thuật ngữ cơ sở dữ liệu từ bài đăng trước của tôi, Bitclout cố gắng đưa tất cả các bảng sau vào chuỗi (cộng với một số bảng dành riêng cho Bitclout):

Hai bảng cuối cùng luôn có sự bùng nổ dữ liệu, điều này sẽ trở nên khó vận hành trong trường hợp người dùng tăng trưởng nhanh chóng.

Vì vậy, tôi nghĩ rằng một cách tiếp cận tốt hơn là sử dụng chuỗi khối hiện có, về cơ bản đã là bảng đầu tiên đó (tức là người dùng) và thêm bảng tham gia user_follows_user vào đó. (Chúng tôi cũng có thể mở rộng phép nối cho các loại quan hệ khác, chẳng hạn như user_mutes_user , nhưng bây giờ chúng tôi sẽ giữ nó đơn giản.)

Bảng kết nối giữa người dùng với người dùng này cũng sẽ phát triển tuyến tính với số lượng người dùng, nhưng với tốc độ chậm hơn và quan trọng hơn, để thể hiện lượng dữ liệu bổ sung mà nó cần (= dung lượng khối bổ sung mà nó tiêu thụ) sẽ thấp hơn nhiều so với bảng bài viết.

Tôi đề xuất điều này bởi vì mối quan hệ của người dùng và người hâm mộ tạo thành nguồn khóa chính cho mọi nền tảng mạng xã hội lớn. Nếu toàn bộ biểu đồ xã hội Twitter hoặc Facebook của bạn mở và sẵn sàng cho các nền tảng xã hội khác muốn lưu trữ bài đăng và các trải nghiệm mạng xã hội sử dụng nhiều dữ liệu khác, thì về cơ bản không có khóa nào cho các nền tảng đó .

Biểu đồ xã hội trên chuỗi có thể trông như thế nào

Hãy tưởng tượng toàn bộ biểu đồ twitter của tôi được thể hiện trên chuỗi – bao gồm cả tài khoản thực và các mối quan hệ với người theo dõi. Để xem các bài đăng trên Twitter trong biểu đồ này (và các lượt thích, tin nhắn lại, tin nhắn lại theo dõi, v.v.), tôi cần kết nối với Twitter.com bằng ví của mình. Nhưng giả sử tôi muốn chuyển sang Tribe.com hoặc gab.com hoặc một số nền tảng xã hội khác với các chính sách kiểm duyệt và xu hướng đặc biệt của riêng nó - nếu họ có thể đọc biểu đồ xã hội của tôi từ chuỗi khối, thì tôi có thể kết nối ví của mình ở đó và xem cùng một kết nối và xem bất kỳ bài đăng nào họ có trên trang web khác này.TribelĐiều này nghe có vẻ không hấp dẫn lắm, nhưng hãy xem xét thực tế là nếu tôiGabTheo dõi ai đó mới trên Twitter, vì vậy tôi hiện cũng ở trên Twitter và

Theo dõi người này trên Facebook – và trên mọi nền tảng xã hội khác sử dụng cùng một biểu đồ trực tuyến về người dùng và các mối quan hệ. Bỏ theo dõi và chặn hoạt động theo cùng một cách – thực hiện một lần ở một nơi và các thay đổi đối với Biểu đồ của bạn được phản ánh ngay lập tức ở mọi nơi.

Bây giờ, những ai muốn tận dụng điều này trong khi đọc đã nhận ra rằng trong một thế giới như thế giới ở trên, điều chắc chắn sẽ xảy ra là ai đó sẽ tạo một ứng dụng khách tổng hợp cho phép bạn truy cập dữ liệu từ bất kỳ hoặc tất cả của các mạng này thông qua một giao diện duy nhất. Đọc và xuất bản thông tin ở định dạng . Sau đó, không có ích gì khi có các dịch vụ riêng biệt, tất cả chúng sẽ ngừng hoạt động...hay chúng sẽ ngừng hoạt động?

Bản xem trước của những thứ sắp tới: số điện thoại + danh bạ + ứng dụng nhắn tin

Thế giới mà tôi đang mô tả đã tồn tại ở trạng thái nguyên mẫu, dưới dạng các giao thức nhắn tin cạnh tranh, tất cả đều được gắn với số điện thoại của bạn và tự điền từ cơ sở dữ liệu liên hệ của bạn. Hệ thống số điện thoại là nguyên mẫu của bảng hàng trăm triệu người dùng và chương trình ứng dụng liên hệ phân tán có thể đọc và viết định dạng Vcard tiêu chuẩn, tạo thành biểu đồ mối quan hệ dựa trên bảng.

Có nhiều giao thức nhắn tin dựa trên tổ hợp số điện thoại + số liên lạc này và kết quả hơi giống với mạng xã hội mà tôi đang mô tả ở đây. Ví dụ: khi bạn đăng nhập Telegram lần đầu tiên, nó sẽ quét danh bạ của bạn và ngay lập tức bạn có các mạng hiện có của mình trong ứng dụng mới này.

Do đó, bạn có thể chọn trao đổi tin nhắn có cùng số điện thoại qua Signal, Telegram, WhatsApp, iMessage hoặc SMS truyền thống – tất cả phụ thuộc vào giao thức nhắn tin mà bạn và những người khác trong mạng của bạn muốn sử dụng.Ngoài ra còn có một chu kỳ vĩnh cửu, đó là sự phi tập trung hóa và tái tập trung hóa các ứng dụng nhắn tin, bắt đầu từ kỷ nguyên ICQ và vẫn đang diễn ra trong kỷ nguyên WhatsApp/Signal/Telegram/Facebook/v.v. bạn có thể tìm thấy bất kỳ số lượngTất cả hợp lại thành một

Ứng dụng khách nhắn tin hỗ trợ nhiều nền tảng này trong một cửa sổ.

Không có ứng dụng nhắn tin nào trong số này bị xâm phạm vì tất cả chúng đều lấy danh tính của mình từ cùng một hệ thống số điện thoại mở và hệ sinh thái các ứng dụng và dịch vụ danh bạ có thể tương tác với nhau – tất cả chúng cùng tồn tại và mang lại điều gì đó khác biệt, và nhiều người trong chúng ta là Con người chuyển đổi giữa chúng, nói chuyện với nhau các biểu đồ con khác nhau của các liên hệ của chúng tôi với các nhu cầu và sở thích khác nhau. Nếu chúng ta di chuyển biểu đồ xã hội trên chuỗi, tôi hy vọng động lực này sẽ tiếp tục.

Về khả năng kết hợp và quan hệ xã hội

Các nền tảng khác nhau có các loại kết nối xã hội khác nhau mà người dùng có thể kết nối với nhau. Facebook có bạn bè, theo dõi và chặn. Twitter có theo dõi, tắt tiếng và chặn. Những thứ đó rất tốt cho các nền tảng này, nhưng chúng tôi có thể cải thiện chúng, làm cho chúng tốt hơn cho các chuỗi khối, làm cho chúng dễ kết hợp hơn.

Khả năng kết hợp là một thuật ngữ khoa học máy tính có nghĩa đại khái là bạn có thể kết hợp và kết hợp các công cụ nhỏ, rời rạc, được xác định rõ này để đạt được các hiệu ứng và chức năng khác nhau.

Hãy coi Facebook là "bạn bè" - đây là kiểu kết nối riêng của nó, nhưng nó cũng có nghĩa là "theo dõi" vì khi bạn thêm ai đó làm bạn, bạn sẽ tự động theo dõi họ. Trên Twitter, "chặn" có nghĩa là "tắt tiếng", bởi vì khi bạn chặn ai đó, về cơ bản, bạn đang tắt tiếng họ đồng thời ngăn họ xem bài đăng của bạn.

• Đối với hai đề xuất biểu đồ xã hội của riêng tôi, bên dưới, tôi muốn đề xuất các bộ quan hệ biểu đồ xã hội sau đây, rõ ràng hơn và có thể kết hợp được:

• Theo dõi: Bạn có thể đọc các bài đăng từ những người bạn theo dõi.

• Tắt tiếng: Bạn không thể đọc bài đăng từ những người mà bạn đã tắt tiếng.

Chặn: Những người bạn chặn không thể đọc bài đăng của bạn.

Theo sơ đồ này, một khối là "tắt tiếng" cộng với một "khối", do đó, nó bao gồm hai thao tác trên cùng một địa chỉ mục tiêu (ví dụ: nếu tôi muốn chặn gây phiền nhiễu.eth, tôi sẽ đặt địa chỉ này là Tắt tiếng, sau đó chặn nó).

Nếu tôi muốn xem bài đăng của ai đó nhưng không muốn họ xem bài đăng của mình, tôi có thể theo dõi họ, cộng với chặn. Hoặc, tôi có thể theo dõi và tắt tiếng nếu tôi muốn tiếp tục đọc bằng cách điều hướng đến nội dung của chúng hoặc tắt tiếng chúng theo định kỳ.

Tôi cố gắng làm rõ các mối quan hệ theo cách này vì nó giúp dễ dàng lập luận về hợp đồng và các mối quan hệ trong các chương sau.

Một số thông tin cơ bản về hai đề xuất của tôi

• Trong phần còn lại của bài báo này, tôi trình bày hai đề xuất để xếp lớp biểu đồ xã hội vào bảng một tỷ người dùng.

• Đầu tiên, Đồ thị trên chuỗi (OCG), cởi mở và đơn giản hơn, nhưng cũng đắt hơn về phí, vì vậy một số người sẽ thích nó và một số thì không.

• Thứ hai, biểu đồ chuỗi (CLG), phức tạp hơn nhưng rẻ hơn, đồng thời cung cấp nhiều quyền kiểm soát và quyền riêng tư hơn, vì vậy tôi dự đoán hầu hết mọi người sẽ thích nó hơn. Tuy nhiên, các nền tảng có thể hỗ trợ cả hai cách tiếp cận cùng một lúc.

• Để thực sự hiểu cả hai đề xuất, bạn cần có một số hiểu biết cơ bản về các khái niệm sau:

• Dịch vụ tên miền Ethereum

• hợp đồng thông minh

hợp đồng thông minh

Biết một chút về Solidity (ngôn ngữ lập trình hợp đồng thông minh của Ethereum) cũng sẽ hữu ích. Nếu bạn mơ hồ về một hoặc tất cả những điều trên, tôi đã cố gắng viết điều này theo cách mà bạn vẫn có thể nắm bắt được những điều cơ bản.ENSĐối với cả hai đề xuất, tôi cho rằng chúng tôi sử dụng

Ví dụ về bản ghi ENS, trong trường hợp này là tên ENS của riêng tôi

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"

}

Tôi cũng muốn đề xuất một bản ghi ENS bổ sung cho URI dữ liệu người dùng trên mạng xã hội để bạn có thể cập nhật dữ liệu trên mạng xã hội của mình mà không tốn xăng. Một bản ghi profileURI được đề xuất sẽ liên kết với một đối tượng JSON ẩn trên một số nền tảng của bên thứ ba, trông giống như sau:

Một số nội dung trong JSON hồ sơ là dư thừa với trường ENS hiện có, nhưng điều đó không sao; mục đích của việc này là cung cấp cho các nền tảng xã hội thứ gì đó để hiển thị và cho phép người dùng thực hiện các thay đổi đối với hồ sơ xã hội của họ mà không cần phải tốn xăng để cập nhật bản ghi ENS.

Đề xuất 1: Biểu đồ trên chuỗi

• Ý tưởng về On-Chain Graph sử dụng NTFT để biểu thị ba mối quan hệ trên. Đối với ba hợp đồng xã hội sau đây, cùng một chiếc ví chứa ENS NFT cũng sẽ sở hữu các hợp đồng này và ba bản ghi địa chỉ ENS tương ứng của chúng sẽ trỏ đến các hợp đồng này:

• Người theo dõi OCG: Khi bạn gửi một NTFT từ hợp đồng người theo dõi OCG của tôi vào ví của bạn, thì bạn sẽ theo dõi tôi. Bất kỳ ai trong chúng ta cũng có thể phá hủy NFT này và khiến bạn hủy theo dõi tôi.

• Chặn OCG: Tôi đã chặn bạn khi tôi airdrop một NTFT từ hợp đồng OCG Ghosted của tôi vào ví của bạn. Chỉ có tôi mới có thể phá hủy NTFT này để giải thoát cho bạn.

OCG Mute: Khi tôi airdrop một NTFT từ hợp đồng OCG Mute của tôi đến ví của bạn, tôi đã tắt tiếng bạn. Chỉ tôi mới có thể hủy NTFT này để bật tiếng cho bạn.

Ngữ nghĩa của ba trường hợp này về cơ bản là: "đối với tôi, chủ sở hữu hợp đồng, bạn là X", trong đó "X" là một loại người theo dõi, chặn và tắt tiếng.

// 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);

}

}

Đây là một hợp đồng theo dõi mẫu:

Nếu bạn đã quen thuộc với Solidity, bạn có thể thấy hợp đồng rất đơn giản (và chưa được kiểm tra!) này đang cố gắng thực hiện điều gì.

• Đầu tiên là phần mở rộng:

• Tiện ích mở rộng ERC 721 Enumerable được bao gồm để chủ sở hữu mã thông báo có thể được liệt kê bởi các ứng dụng mạng xã hội mà không cần phải quét toàn bộ chuỗi.

• Tôi sử dụng Có thể tạm dừng vì bạn có thể tạm dừng đúc tiền để khóa tài khoản của mình trong một khoảng thời gian, tức là ngừng chấp nhận những người theo dõi mới.

• Có thể sở hữu là điều cần thiết vì có một số điều mà chỉ chủ sở hữu hợp đồng mới nên làm. Tôi không nghĩ cần phải sử dụng các chức năng nhân vật mạnh mẽ hơn.

• ERC 721 Có thể ghi được ở đây vì bạn cần có khả năng ghi mã thông báo để xóa mối quan hệ theo dõi. Hàm burn() tiêu chuẩn được bao gồm ở đây có các quyền mà chúng tôi cần, tức là chỉ chủ sở hữu hoặc chủ sở hữu mã thông báo mới có thể ghi mã thông báo.

Tôi đã bao gồm Bộ đếm để tokenID được tự động tăng lên, điều này rất tiện lợi.

• Bây giờ hãy sửa đổi đầu ra của trình hướng dẫn OpenZeppelin:

• Sau khi safeMint() được sửa đổi, chỉ chủ sở hữu hợp đồng mới có thể đúc mã thông báo đến địa chỉ của người khác. Đối với tất cả những người không phải là chủ sở hữu, bạn chỉ có thể đúc tiền đến địa chỉ mà bạn gọi là hợp đồng.

• _beforeTokenTransfer() đã được viết lại để về cơ bản nó vô hiệu hóa khả năng chuyển mã thông báo, tạo mã thông báo soulbound đơn giản.

Hàm quan hệ () là một phương pháp thuận tiện đảm bảo có một cách dễ dàng để truy vấn hợp đồng và xác nhận mối quan hệ mà NFT đại diện. Tôi không phải là người thích bao gồm điều này, nhưng nó có vẻ hữu ích.

• Tất cả đều rất đơn giản, đối với các biến thể bị che khuất và tắt tiếng của OCG, bạn phải thực hiện các thay đổi nhỏ sau:

• Thay đổi tên và ký hiệu hợp đồng

• Thay đổi giá trị trả về của quan hệ () và có thể là baseURI () để phản ánh mối quan hệ mà bạn đại diện (nghĩa là "tắt tiếng" hoặc "bóng mờ").

Thay đổi cả hai hàm safeMint() và burn() thành onlyOwner để chỉ chủ sở hữu hợp đồng mới có thể gọi hai hàm này.

Rõ ràng, điều này sẽ phụ thuộc vào việc nền tảng có thực hiện đúng các hợp đồng này (tức là theo dõi, chặn, tắt tiếng) theo đúng cách hay không. Tuy nhiên, nó ít đe dọa và gây bất ổn hơn so với âm thanh của nó, bởi vì nếu một nền tảng xã hội cụ thể không hoàn thành hợp đồng mà bạn quan tâm, đừng sử dụng nó.

tăng chú ý

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);

}

Bạn có thể thêm khoản phải trả trong safeMint, sau đó sử dụng setMintRate để đặt giá mà mọi người phải trả cho bạn cho những khoản sau. Vì vậy, một cái gì đó như thế này:

Tôi chắc rằng tôi có thể nghĩ ra nhiều chỉnh sửa và tính năng khác để thêm vào đề xuất này, nhưng tốt nhất là nên bắt đầu với thứ gì đó đơn giản và dễ hiểu.

Đề xuất 2: Biểu đồ kết nối chuỗi

• Hợp đồng OCG được mô tả ở trên khá đơn giản, nhưng sơ đồ này có một số đặc điểm riêng có thể khiến nhiều người chia rẽ:

• Mọi thứ đều công khai, trên chuỗi, bao gồm cả chặn và tắt tiếng. Bạn không thể làm điều này để khóa tài khoản, nhưng một giải pháp khả thi cho vấn đề này là sử dụng một tài khoản thay thế.

• Mọi hành động đều tốn gas, điều đó có nghĩa là bạn phải đưa ra lựa chọn thực sự về người mà bạn theo dõi, chặn và tắt tiếng. Nhưng nếu chi phí gas đủ cao, thì điều này có thể khiến mạng không sử dụng được.

Theo dõi trả phí có thể hoặc không phải là một tính năng mong muốn cho một mạng hoặc một tài khoản cụ thể, nhưng bạn sẽ có tùy chọn.

Vì không phải ai cũng thích những phẩm chất này của đề xuất này, tôi muốn đề xuất một bộ hợp đồng xã hội thay thế cung cấp cho người dùng và nền tảng quyền kiểm soát chi tiết hơn đối với việc ai xem thông tin nào và ít tốn kém hơn khi sử dụng.

• Ý tưởng cơ bản của Biểu đồ liên kết chuỗi (CLG): Chúng tôi không thể hiện các mối quan hệ xã hội (theo dõi, chặn, tắt tiếng) trực tiếp trên chuỗi thông qua NFT mà lưu trữ các mối quan hệ này ngoài chuỗi và sử dụng mã thông báo trên chuỗi để khám phá và truy cập các mối quan hệ này.

• Khám phá: Hợp đồng cung cấp hàm listURI() trả về danh sách JSON các liên kết đến tên ENS mà bạn định khai báo mối quan hệ xã hội (nghĩa là tôi theo dõi họ, tôi tắt tiếng họ hoặc tôi chặn họ).

Quyền truy cập: Nếu liên kết do listURI() trả về được kiểm soát bằng mã thông báo, thì mã thông báo của hợp đồng sẽ cấp cho chủ sở hữu quyền truy cập đọc vào liên kết được tìm thấy trong siêu dữ liệu.

Sau đó, mối quan hệ xã hội không trực tiếp trên chuỗi mà được kết nối với chuỗi thông qua một bộ hợp đồng và URL.

• Giống như OCG, mỗi mối quan hệ trong số ba mối quan hệ xã hội được điều chỉnh bởi hợp đồng thông minh, nhưng CLG có ngữ nghĩa khác nhau:

• Đã theo dõi: Chứa danh sách JSON chứa các liên kết đến tên của ENS mà bạn đang theo dõi và mã thông báo do nó cấp cho quyền truy cập đọc vào danh sách theo dõi đó.

• Tắt tiếng: Chứa danh sách JSON gồm các tên được liên kết với ENS mà bạn đang tắt tiếng, mã thông báo do ENS cấp sẽ cấp quyền truy cập đọc vào danh sách đã tắt tiếng đó.

Chặn: Chứa danh sách JSON liên kết với tên ENS mà bạn đang chặn, mã thông báo do nó cấp cho phép đọc danh sách chặn.

Do đó, ngữ nghĩa của mã thông báo CLG là: "Đây là quyền truy cập đọc vào danh sách tài khoản X của tôi", trong đó "X" là "Theo dõi", "Tắt tiếng" hoặc "Chặn".

Bạn có thể coi đề xuất của tôi trong phần này giống như một sự kết hợp gần đúng giữa số điện thoại + sổ địa chỉ mà tôi mô tả cho các ứng dụng nhắn tin. Số điện thoại của bạn (gần như) công khai và khi bạn kết nối một ứng dụng nhắn tin mới với nó, bạn có thể cấp hoặc từ chối ứng dụng đó quyền đọc danh bạ của bạn.

Trong chương trình mã thông báo xã hội CLG của tôi, tên ENS của bạn được công khai giống như số điện thoại của bạn, đồng thời bạn phát hành và thu hồi mã thông báo để cấp và từ chối quyền truy cập vào danh sách những người mà bạn có liên quan. Bạn có thể cấp các mã thông báo này cho người dùng ngẫu nhiên nếu muốn, nhưng chủ yếu là bạn muốn cấp chúng cho các nền tảng xã hội để các nền tảng đó biết bài đăng của ai sẽ hiển thị cho bạn và bài đăng của ai sẽ ẩn (hoặc ai không nên xem bài đăng của bạn).

(Quyền truy cập ghi vào danh sách tạo nên biểu đồ xã hội của bạn có thể được kiểm soát bởi ENS NFT thông thường của bạn - nếu bạn có tên ENS trong ví của mình, bạn có thể ghi/cập nhật/xóa danh sách. Một khả năng thay thế là có một thứ tư hợp đồng xã hội cấp quyền truy cập ghi vào danh sách của chủ sở hữu NTFT, vì vậy bạn có thể thuê ngoài việc quản lý danh sách cho một số bên thứ ba)

• Lưu trữ các danh sách này ngoài chuỗi, trong khi trỏ đến chúng từ trên chuỗi, có một số lợi ích:

• Bạn có thể khóa mối quan hệ của mình khỏi chế độ xem công khai bằng cách sử dụng xác thực trên điểm cuối lưu trữ danh sách. Hoặc bạn có thể công khai để mọi người có thể đọc được.

• Cập nhật danh sách ngoài chuỗi không tốn xăng.

• Cách tiếp cận này cho phép tạo ra thị trường các dịch vụ lưu trữ biểu đồ xã hội có thể tương tác với các nhà cung cấp xã hội.

Bất kỳ ai hoặc dịch vụ đều có thể dễ dàng khám phá danh sách của bạn.

Kiểm soát truy cập mã thông báo và truy cập đọc

Một cải tiến quan trọng trong việc thực hiện các hợp đồng CLG là kiểm soát quyền truy cập mã thông báo. Khái niệm đằng sau kiểm soát truy cập mã thông báo là bạn không thể truy cập dữ liệu cụ thể trên máy chủ trừ khi bạn kết nối với máy chủ bằng ví chứa mã thông báo truy cập cụ thể.

Ví dụ: bạn có thể mã hóa quyền kiểm soát quyền truy cập đối với nội dung trên IPFS để chỉ những người đọc kết nối với điểm cuối bằng một NFT cụ thể trong ví của họ mới có thể xem các tệp cụ thể.

CLG sử dụng cổng mã thông báo để thêm một số hướng vào hợp đồng xã hội của chúng tôi, do đó, thay vì đại diện cho một loại mối quan hệ cụ thể – theo dõi, tắt tiếng hoặc chặn – NFT xã hội đại diện cho quyền truy cập đọc vào một phần biểu đồ xã hội của bạn.

Rõ ràng, để ngưỡng mã thông báo hoạt động, nền tảng phải tôn trọng nó. Có lẽ, nếu nền tảng không tôn trọng các biện pháp kiểm soát quyền truy cập mã thông báo, bạn sẽ chuyển danh sách mối quan hệ của mình sang nền tảng khác và thay đổi hợp đồng của mình, phát hành lại bất kỳ NFT nào nếu cần.

Ngoài ra, để rõ ràng, danh sách của một số người bị rò rỉ tại một số điểm. Chúng ta đang sống trong một thế giới vi phạm dữ liệu cá nhân, vì vậy nếu dữ liệu được lưu trữ ở đâu đó, thì một số dữ liệu sẽ bị xâm phạm. Tôi sẽ thảo luận về một số biện pháp giảm thiểu khả thi trong các chương sau.

Mẫu hợp đồng: 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.");

}

}

Hợp đồng bên dưới sẽ là hợp đồng ERC 721 NTFT tiêu chuẩn, rất gần với hợp đồng OCG ở trên:

Tất cả các tiện ích mở rộng đều giống như OCG ngoại trừ tôi không bao gồm ERC 721 Có thể đếm được vì không rõ liệu có ai muốn mã thông báo CLG Follows của họ được liệt kê hay không (cộng với việc nó làm tăng chi phí gas khi đúc)

• Đối với chức năng, tôi đã thực hiện các sửa đổi sau đối với đầu ra của trình hướng dẫn OpenZeppelin:

• mối quan hệ (): Giống như OLG, nó trả về loại hợp đồng xã hội. Một lần nữa, điều này có lẽ không cần thiết đối với các hợp đồng Solidity và tôi chưa thấy nó được thực hiện, nhưng dù sao, tôi cảm thấy mình muốn hợp đồng tự báo cáo loại của nó. Vì vậy, tôi không biết - xin vui lòng bỏ qua nếu điều này xúc phạm bạn.

listURI() trả về một liên kết đến một đối tượng JSON là danh sách các tên ENS mà bạn đang theo dõi (hoặc bị ẩn hoặc bị chặn, tùy thuộc vào loại hợp đồng). Chúng tôi muốn URI này được đánh dấu là riêng tư, nhưng không nhất thiết phải như vậy.

Hầu hết thời gian bạn sẽ sử dụng CLG Follows NTFT và đăng nó lên một địa chỉ thuộc sở hữu của nền tảng xã hội. Bằng cách đó, nền tảng có thể đọc danh sách theo dõi của bạn và hiển thị cho bạn các bài đăng chính xác.

Nhưng bạn cũng có thể gửi các NTFT này cho những người theo dõi để những người theo dõi của bạn có thể khám phá những người theo dõi khác. Bạn có thể làm điều này bằng cách thả dù cho những người theo dõi hoặc bằng cách bỏ cấm đúc tiền, cho phép bất kỳ ai đúc tiền.

Tất cả các hợp đồng khác hoạt động chính xác như trên, nhưng có tên và ký hiệu khác, đồng thời trả về các giá trị khác nhau từ quan hệ() và listURI().

các biến có thể

Nếu bạn lo lắng về việc danh sách của mình bị rò rỉ từ các dịch vụ khác nhau, bạn có thể dễ dàng thay đổi listURI() thành thứ gì đó giống như tokenURI(uint 256 tokenId) tức là chữ ký là listURI(uint 256 tokenId) nối tokenID thành The end of a URI cơ sở để mỗi chủ sở hữu mã thông báo nhận được URL danh sách của riêng mình. Tính năng này, kết hợp với một số logic trên máy chủ lưu trữ danh sách, cho phép bạn tách biệt các danh sách sao cho những người nắm giữ mã thông báo khác nhau nhận được các biểu đồ con khác nhau của biểu đồ chính. Theo cách đó, nếu một nền tảng được sở hữu, thì chỉ phần đó trong biểu đồ của tôi bị xâm phạm.

Bạn có thể muốn cập nhật các URL được trả về bởi tokenURI() và/hoặc listURI(), trong trường hợp đó, bạn sẽ cần lưu trữ các URL này trong các biến, khởi tạo chúng trong hàm tạo và cung cấp các hàm onlyOwner setter để cập nhật chúng . Điều này sẽ làm tăng chi phí đúc của bạn, nhưng nếu bạn chỉ cung cấp chúng cho các dịch vụ chứ không phải cá nhân, thì điều này có thể không thành vấn đề.

Phục vụ

Phục vụ

Cả hai đề xuất được nêu ở đây đều cung cấp một số vị trí cho các dịch vụ lưu trữ tập trung, ngay cả khi đó chỉ là một giải pháp tạm thời, cho đến khi hệ sinh thái chuyển đổi sang một hệ thống phân tán như IPFS.

Loại dịch vụ rõ ràng nhất là lưu trữ mọi thứ được trả về bởi một trong các hàm URI – dữ liệu hồ sơ, siêu dữ liệu NTFT và danh sách kiểm soát mã thông báo JSON (trong trường hợp của CLG).

Cuối cùng, có thể có các dịch vụ của bên thứ ba để xác minh tài khoản phù hợp với nhu cầu của người dùng và tổ chức.

tóm tắt

tóm tắt

Tôi không biết liệu tôi có mong đợi đề xuất biểu đồ xã hội trực tuyến của mình được thông qua theo hình thức mà tôi mô tả ở đây hay không. Tôi đưa ra những ý tưởng này nhiều hơn để khơi dậy các cuộc trò chuyện về cách chúng ta có thể chuyển đổi hiệu quả từ trạng thái nền tảng bị khóa hoàn toàn hiện tại sang trạng thái di động hơn, nơi bạn sở hữu biểu đồ của mình và có thể dễ dàng mang theo bên mình mọi lúc mọi nơi.

Nếu bạn không nhận được gì khác từ bài đăng này, thì tôi hy vọng ít nhất tôi đã nói rõ rằng trong thế giới của công nghệ sổ cái phân tán và hợp đồng thông minh, không ai trong chúng ta cần phải bị khóa vào mạng xã hội vào năm 2022. Các công cụ để giải quyết vấn đề khóa này có sẵn rộng rãi, chúng ta chỉ cần chọn chúng và sử dụng chúng.

liên kết gốc