Làm cách nào để xây dựng biểu đồ xã hội Web3 gồm một tỷ người dùng?

avatar
Foresight News
03-29
Bài viết này được dịch máy
Xem bản gốc
Bài báo này đề xuất hai đề xuất để phân lớp biểu đồ xã hội thành các bảng hàng tỷ người dùng: Biểu đồ Chuỗi(OCG) và Biểu đồ Chuỗi(CLG).

Tên gốc: Biểu đồ xã hội tỷ người dùng

Bởi Jon Stokes

Biên soạn bởi: Dan, W3.Hitchhiker

Với việc Elon Musk gần đây tiếp quản Twitter, những cuộc thảo luận về việc di chuyển khỏi các mạng xã hội lớn sang các giải pháp thay thế độc lập hoặc mở đã ngày càng tăng, nhưng tất cả những người ban đầu mơ ước về việc tham gia vào một cộng đồng thịnh vượng gồm những cư dân cũ của Twitter sẽ sớm gặp phải một vấn đề mà phe cánh hữu đã phải vật lộn kể từ cuộc thanh trừng phương tiện truyền thông xã hội đa nền tảng sau J6: sự khóa chặt mạng lưới là có thật.

Bạn có thể đi sâu vào phân tích lý thuyết và chiến lược về các vấn đề phối hợp, chuỗi ưu tiên, tín hiệu và các khái niệm lý thuyết trò chơi khác—và tôi không phủ nhận rằng đây là phương pháp 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 triệu người trong chúng ta, tất cả những gì bạn thực sự cần biết là một phương pháp đơn giản từ những ngày đầu của Internet.

Định luật Metcalfe phát biểu rằng giá trị của một mạng viễn thông tỷ lệ thuận với bình phương số lượng người dùng được kết nối (n²). Định luật Metcalfe lần đầu tiên được George Gilder đề xuất dưới dạng này vào năm 1993, được cho là dựa trên công trình nghiên cứu về ETH của Robert Metcalfe. Khoảng năm 1980, Định luật Metcalfe ban đầu không được diễn đạt theo nghĩa người dùng, mà theo nghĩa "các thiết bị truyền thông tương thích" (chẳng hạn như máy fax và điện thoại). Chỉ khi Internet toàn cầu hóa, định luật này mới mở rộng sang người dùng và mạng, vì ban đầu nó được dự định mô tả các kết nối ETH.

Gần như không thể khiến mọi người từ bỏ một biểu đồ mạng lớn, dày đặc để chuyển sang một biểu đồ nhỏ, thưa thớt chỉ vì biểu đồ trước có giá trị còn biểu đồ sau thì không.

Thật kỳ lạ, web3 lại giải quyết được vấn đề này. Hoặc ít nhất là có thể nếu chúng ta sử dụng một số hợp đồng thông minh đơn giản để biến blockchain 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 trình trước đây

Blockchain có thể và thực sự hoạt động như một bảng dữ liệu người dùng khổng lồ, được chia sẻ, mở, công khai và không bị bất kỳ thực thể nào kiểm soát. Như tôi đã viết trong The Billion User Table:

Blockchain công khai tương đương với một bảng người dùng duy nhất, quy mô lớn cho toàn bộ Internet và làn sóng ứng dụng phân tán tiếp theo sẽ được xây dựng trên đó.

Thay vào đó, có một mạng lưới các silo dữ liệu người dùng phi tập trung được kết nối bằng API, và một kho 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 nút lưu trữ phi tập trung. Do đó, blockchain lưu trữ danh tính thể hiện cả phi tập trung của lớp triển khai lưu trữ dữ liệu và sự tái tập trung củ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 bảng người dùng của họ (cùng với phần lớn dữ liệu độc quyền như xác nhận, điểm và lịch sử hoạt động) sang BitClout. Ngay lập tức, điều sau sẽ xảy ra: mỗi người dùng GitHub cũng là một người dùng Reddit, một người dùng LinkedIn và một người dùng BitClout. Tương tự, mỗi người dùng Reddit cũng là một người dùng GitHub, một người dùng LinkedIn và một người dùng BitClout. Tôi có thể nói thêm nữa, nhưng bạn hiểu ý tôi rồi đấy.

Mỗi công ty xây dựng trên cùng một bảng người dùng ảo sẽ ngay lập tức được tiếp cận với 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 trong Chuỗi thêm một người dùng mới, dịch vụ của bạn cũng sẽ thêm một người dùng mới. (Ở một mức độ nào đó, họ có thể chưa thực sự sử dụng dịch vụ của bạn, nhưng thực tế họ là những người dùng tiềm năng.)

Bài viết trước đã sử dụng Bitclout (Chuỗi trong dự án hiện được gọi là DeSo) làm ví dụ điển hình về blockchain có thể hỗ trợ trường hợp sử dụng này. Tuy nhiên, mặc dù tôi rất hào hứng với toàn bộ dự án DeSo, nhưng mọi chuyện lại không mấy suôn sẻ.

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

Đội ngũ 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 lượng lớn công sức kỹ thuật để giải quyết. Nhưng nhìn lại, tôi thực sự cho rằng họ đã cố gắng làm quá nhiều việc cùng một lúc. Họ nên chỉ tập trung vào vấn đề di động của biểu đồ xã hội.

Sử dụng thuật ngữ cơ sở dữ liệu từ bài viết 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 thêm một số bảng khác dành riêng cho Bitclout):

  • users
  • user_follows_user
  • posts
  • user_likes_post

Hai bảng cuối cùng luôn có dữ liệu bùng nổ, gây khó khăn cho việc vận hành khi số lượng người dùng tăng trưởng nhanh.

Do đó, tôi cho rằng phương pháp tốt hơn là sử dụng blockchain hiện có, về cơ bản đã có bảng đầu tiên (tức là users), và thêm bảng nối user_follows_user vào trong đó. (Chúng ta cũng có thể mở rộng phép nối cho các loại mối quan hệ khác, chẳng hạn như user_mutes_user , nhưng hiện tại, chúng ta sẽ giữ nguyên như vậy.)

Bảng liên kết người dùng với người dùng này cũng sẽ tăng trưởng không tuyến tính theo số lượng người dùng, nhưng tốc độ tăng trưởng sẽ chậm hơn và quan trọng hơn là lượng dữ liệu bổ sung cần thiết để biểu diễn nó (= lượng không gian khối bổ sung mà nó tiêu thụ) sẽ thấp hơn nhiều so với bảng sau.

Tôi đề xuất điều này vì mối quan hệ giữa người dùng và người hâm mộ là nguồn chính tạo nên sự gắn kết 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 được 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à trải nghiệm mạng xã hội khác đòi hỏi nhiều dữ liệu hơn, thì sự gắn kết cho các nền tảng đó về cơ bản sẽ bằng khô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ác tài khoản thực tế và mối quan hệ người theo dõi. Để xem các bài đăng trên Twitter trong biểu đồ đó (và các lượt thích, retweet, retweet trích dẫn, v.v. liên quan), 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 đến tribel.com, gab.com, hoặc một nền tảng mạng xã hội nào đó có chính sách kiểm duyệt và định kiến ​​riêng — nếu họ có thể đọc biểu đồ mạng xã hội của tôi từ blockchain, thì tôi có thể kết nối ví của mình ở đó, xem các kết nối tương tự và xem bất kỳ bài đăng nào họ đã đăng trên trang web khác này.

Nghe có vẻ không hấp dẫn lắm, nhưng hãy nghĩ đến việc nếu tôi theo dõi một người mới trên Tribel , tôi cũng đang theo dõi người đó trên Twitter và Gab — và trên mọi nền tảng xã hội khác sử dụng cùng biểu đồ trực Chuỗi về người dùng và mối quan hệ. Việc bỏ theo dõi và chặn cũng hoạt động theo cùng một cách — chỉ cần thực hiện một lần tại một nơi, và những thay đổi trên biểu đồ của bạn sẽ được phản ánh ngay lập tức ở mọi nơi.

Giờ đây, những ai đang đọc bài viết này với hy vọng tận dụng cơ hội này hẳn đã nhận ra điều chắc chắn sẽ xảy ra trong một thế giới như mô tả ở trên: ai đó sẽ tạo ra một máy trạm tất cả trong một cho phép bạn đọc và đăng bài từ bất kỳ hoặc tất cả các mạng lưới này thông qua một giao diện duy nhất. Khi đó, việc sở hữu các dịch vụ riêng biệt sẽ chẳng còn ý nghĩa gì, và tất cả chúng sẽ vỡ nợ... hay sẽ không?

Xem trước những điều sắp tới: số điện thoại + danh bạ + ứng dụng nhắn tin

Thế giới 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 liên kết với số điện thoại của bạn và tự động điền vào từ cơ sở dữ liệu danh bạ. Hệ thống số điện thoại là nguyên mẫu cho bảng dữ liệu hàng tỷ người dùng , và các ứng dụng danh bạ phân tán, tất cả đều có thể đọc và ghi định dạng Vcard chuẩn, tạo thành một biểu đồ các mối quan hệ được xây dựng trên bảng dữ liệu đó.

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

Do đó, bạn có thể chọn trao đổi tin nhắn với cùng một số điện thoại qua Signal, Telegram, WhatsApp, iMessage hoặc SMS truyền thống – tất cả tùy thuộc vào giao thức nhắn tin mà bạn và những người khác trong mạng muốn sử dụng.

Ngoài ra còn có một chu kỳ phi tập trung và tái tập trung hóa liên tục của các ứng dụng nhắn tin, bắt đầu từ thời ICQ và vẫn đang diễn ra trong thời đại WhatsApp/Signal/Telegram/Facebook, v.v. Bạn có thể tìm thấy bất kỳ máy trạm nhắn tin đa năng nào hỗ trợ nhiều nền tảng này chỉ trong một cửa sổ.

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

Về khả năng kết nối và xã hội

Mỗi nền tảng có các loại kết nối xã hội khác nhau mà người dùng có thể tạo ra với nhau. Facebook có tính năng kết bạn, theo dõi và chặn. Twitter có tính năng theo dõi, tắt tiếng và chặn. Những tính năng này rất hữu ích cho các nền tảng đó, nhưng chúng ta có thể cải thiện chúng để phù hợp hơn với blockchain và giúp 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 là bạn có thể kết hợp các công cụ nhỏ, riêng biệt và được xác định rõ ràng này để có được các hiệu ứng và chức năng khác nhau.

Hãy nghĩ đến "friend" trên Facebook — đó là một loại kết nối riêng, nhưng nó cũng có nghĩa là "follow", bởi vì khi bạn kết bạn với ai đó, bạn sẽ tự động theo dõi họ. Trên Twitter, "block" nghĩa là "mute", bởi vì khi bạn chặn ai đó, về cơ bản bạn đang tắt tiếng họ và ngăn họ xem bài đăng của bạn.

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

  • Theo dõi: Bạn có thể đọ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 bạn đã tắt tiếng.
  • Chặn: 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à một lệnh tắt tiếng cộng với một khối khác, do đó nó là hai thao tác trên cùng một địa chỉ đích, kết hợp với nhau (ví dụ: nếu tôi muốn chặn annoyinghater.eth, tôi sẽ tắt tiếng địa chỉ rồi chặn nó).

Nếu tôi muốn xem bài đăng của ai đó nhưng không muốn họ thấy bài đăng của mình , tôi có thể theo dõi rồi chặn họ. Hoặc, 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 họ hoặc định kì bỏ ẩn danh, tôi có thể theo dõi rồi tắt tiếng họ.

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ý giải hơn về các hợp đồng và mối quan hệ trong các chương sau.

Một số bối cảnh về hai Đề án của tôi

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

  • Giải pháp đầu tiên, On-Chain Graph (OCG) , cởi mở và đơn giản hơn, nhưng cũng đắt hơn về mặt phí, vì vậy một số người sẽ thích nó và một số thì không.
  • Giải pháp thứ hai, Chuỗi Graph (CLG) , phức tạp hơn nhưng rẻ hơn và cung cấp nhiều quyền kiểm soát và quyền riêng tư hơn, vì vậy tôi nghĩ hầu hết mọi người sẽ thích nó. Tuy nhiên, các nền tảng có thể hỗ trợ cả hai.

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

  • Token không thể phân tách (NFT) và Token không thể phân tách không thể chuyển nhượng (NTFT, còn được gọi là Token gắn kết linh hồn).
  • Dịch vụ tên miền Ethereum
  • 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 còn mơ hồ về một hoặc tất cả những điều trên, tôi đã cố gắng viết bài viết này theo cách mà bạn vẫn có thể nắm bắt được những kiến ​​thức cơ bản.

Đối với cả hai Đề án, tôi giả định chúng ta sử dụng ENS làm gốc của danh tính và thêm các bản ghi địa chỉ mới trong đó đó, chứa địa chỉ của một số hợp đồng NFT ERC721 khá chuẩn, đại diện cho ba loại mối quan hệ xã hội mà tôi đã nêu ở trên (theo dõi, tắt tiếng, chặn). Mục đích của ba hợp đồng này rất khác nhau tùy theo Đề án Đề án, nhưng ý tưởng cơ bản là đưa địa chỉ của chúng vào ba bản ghi địa chỉ ENS đặc biệt vẫn giữ nguyên.

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

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

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

-H "Chấp nhận: application/json"

{

"name": "jonstokes.(eth|com)",

"bio": "Nhà văn. Lập trình viên. Người lạc quan về công nghệ. Anh em mật mã học.",

"trang web": "https://jonstokes.com/",

"vị trí": "Austin, TX"

}

Một số nội dung trong hồ sơ JSON trùng lặp với các trường ENS hiện có, nhưng không sao cả; mục đích 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 tốn gas cập nhật bản ghi ENS.

Khuyến nghị 1: Biểu đồ trên Chuỗi

Khái niệm Đồ thị Trên Chuỗi sử dụng NTFT để biểu diễn ba mối quan hệ được đề cập ở trên. Đối với ba hợp đồng xã hội sau, cùng một ví lưu trữ NFT ENS cũng nên 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 phải 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í, bạn sẽ theo dõi tôi. Bất kỳ ai trong chúng ta cũng có thể đốt NFT này, khiến bạn hủy theo dõi tôi.
  • Chặn OCG: Khi tôi airdrop một NTFT từ hợp đồng OCG Ghosted của tôi vào ví của bạn, tôi sẽ chặn bạn. Chỉ tôi mới có thể đốt NTFT này để thanh toán cho bạn.
  • Tắt tiếng OCG: Khi tôi airdrop một NTFT từ hợp đồng OCG Mute vào ví của bạn, tôi đã tắt tiếng bạn rồi. Chỉ tôi mới có thể đốt 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à: "so với tôi, chủ sở hữu hợp đồng, bạn là X", trong đó"X" là người theo dõi, chặn hoặc tắt tiếng.

Sau đây là mẫu hợp đồng người theo dõi:

// SPDX-Mã định danh giấy phép: MIT

pragma solidity ^0.8.4;

nhập "@openzeppelin/contracts/token/ERC721/ERC721.sol";

nhập "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";

nhập "@openzeppelin/contracts/security/Pausable.sol";

nhập "@openzeppelin/contracts/access/Ownable.sol";

nhập "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";

nhập "@openzeppelin/contracts/utils/Counters.sol";

hợp đồng OCGFollower là ERC721, ERC721Enumerable, Pausable, Ownable, ERC721Burnable {

sử dụng Counters cho Counters.Counter;

Bộ đếm.Bộ đếm riêng tư _tokenIdCounter;

constructor() ERC721("OCGFollower", "OCGF") {}

hàm _baseURI() ghi đè nội bộ thuần túy trả về (bộ nhớ chuỗi) {

trả về "https://jonstokes.com/ocg/follower";

}

hàm quan hệ() công khai {

trả về "ocg follower";

}

hàm pause() public onlyOwner {

_tạm dừng();

}

hàm unpause() public onlyOwner {

_bỏ tạm dừng();

}

hàm safeMint(địa chỉ đến) công khai {

//Ngăn chặn bất kỳ ai ngoài chủ sở hữu đúc tiền

//một mã thông báo tới một địa chỉ mà họ không sở hữu.

require(isOwner(_msgSender()) || (_msgSender() == to), "Không thể đúc vào địa chỉ này");

uint256 tokenId = _tokenIdCounter.current();

_tokenIdCounter. tăng();

_safeMint(đến, tokenId);

}

hàm _beforeTokenTransfer(địa chỉ từ, địa chỉ đến, uint256) ghi đè thuần túy nội bộ {

//Vô hiệu hóa chuyển mã thông báo.

require(from == address(0) || to == address(0), "Không thể chuyển nhượng.");

}

// Các hàm sau đây là các hàm ghi đè bắt buộc của Solidity.

hàm supportsInterface(bytes4 interfaceId)

công cộng

xem

ghi đè (ERC721, ERC721Enumerable)

trả về (bool)

{

trả về super.supportsInterface(interfaceId);

}

}

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à mở rộng:

  • Mở rộng ERC721Enumerable được tích hợp để người nắm giữ token có thể được liệt kê bởi máy trạm mạng xã hội mà không cần phải quét toàn bộ Chuỗi.
  • Tôi sử dụng Pausable vì bạn có thể tạm dừng việc đúc tiền để về cơ bản khóa tài khoản của mình trong một thời gian, tức là ngừng chấp nhận người hâm mộ mới.
  • Ownable là thiết yếu vì có những việc chỉ chủ sở hữu hợp đồng mới được làm. Tôi không cho rằng cần thiết phải sử dụng các chức năng nhân vật mạnh mẽ hơn.
  • ERC721Burnable ở đây vì bạn cần có khả năng đốt token để xóa mối quan hệ theo dõi. Hàm burn() tiêu chuẩn được bao gồm ở đây với các quyền chúng ta cần, nghĩa là chỉ chủ sở hữu hoặc các chủ sở hữu token mới có thể đốt token.
  • Tôi đã thêm Counters để tokenID tự động tăng, 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ể token token vào địa chỉ của người khác. Đối với tất cả những người không phải chủ sở hữu, bạn chỉ có thể đúc token vào địa chỉ đã gọi hợp đồng.
  • _beforeTokenTransfer() bị ghi đè nên về cơ bản nó vô hiệu hóa khả năng chuyển token, tạo ra một token linh hồn đơn giản.
  • Hàm relationship() là một phương pháp tiện lợi đảm bảo có một phương pháp 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 ủng hộ việc thêm hàm này, nhưng có vẻ nó hữu ích.

Thực ra rất đơn giản, đối với cả phiên bản OCG có khiên và OCG im lặng, bạn cần thực hiện những thay đổi nhỏ sau:

  1. Thay đổi tên và ký hiệu hợp đồng
  2. Thay đổi giá trị trả về của relationship() và có thể là baseURI() để phản ánh mối quan hệ mà bạn đang thể hiện (tức là "tắt tiếng" hoặc "bóng mờ").
  3. Thay đổi safeMint() và burn() thành các hàm 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 thi các hợp đồng này đúng cách hay không (ví dụ: theo dõi, chặn, tắt tiếng). Tuy nhiên, điều này ít đe dọa và bất ổn hơn bạn nghĩ, bởi vì nếu một nền tảng xã hội cụ thể không thực thi các hợp đồng mà bạn quan tâm, đừng sử dụng nền tảng đó.

Tăng sự chú ý

Bạn có thể thêm payable vào safeMint rồi dùng setMintRate để thiết lập mức giá mà mọi người phải trả cho bạn cho những mục sau. Ví dụ như sau:

uint256 công khai mintRate = 0,01 ether;

hàm setMintRate(uint256 mintRate_) public onlyOwner {

mintRate = mintRate_;

}

hàm safeMint(địa chỉ đến) công khai phải trả {

// Yêu cầu trả tiền để theo dõi

require(msg.value >= mintRate, "Không đủ ether để đúc");

//Ngăn chặn bất kỳ ai ngoài chủ sở hữu đúc tiền

//một mã thông báo tới một địa chỉ mà họ không sở hữu.

require(isOwner(_msgSender()) || (_msgSender() == to), "Không thể đúc vào địa chỉ này");

uint256 tokenId = _tokenIdCounter.current();

_tokenIdCounter. tăng();

_safeMint(đến, tokenId);

}

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

Gợi ý 2: Đồ thị kết nối Chuỗi

Hợp đồng OCG được mô tả ở trên khá đơn giản, nhưng kế hoạch này có một số điểm riêng có thể gây ra sự bất đồng giữa nhiều người:

  • Mọi thứ đều công khai và trên Chuỗi, bao gồm cả việc chặn và tắt tiếng. Bạn không thể khóa tài khoản, nhưng giải pháp cho vấn đề này có thể là sử dụng một tài khoản thay thế.
  • Mỗi hành động đều tốn phí gas, nghĩa là bạn phải đưa ra quyết định thực sự về việc theo dõi, chặn và tắt tiếng ai. Nhưng nếu phí gas quá cao, mạng lưới có thể không sử dụng được.
  • Theo dõi trả phí có thể là một tính năng mong muốn hoặc không mong muốn đối với một mạng lưới hoặc một tài khoản cụ thể, nhưng bạn vẫn có tùy chọn này.

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ế giúp người dùng và nền tảng kiểm soát chi tiết hơn, đặc biệt là về việc ai được xem thông tin gì và ít tốn kém hơn khi sử dụng.

Ý tưởng cơ bản của Chuỗi Linked Graph (CLG): Thay vì 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, chúng tôi 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ề liên kết đến danh sách JSON gồm các tên ENS mà bạn muốn khai báo một số loại mối quan hệ xã hội (tức là tôi theo dõi họ, tắt tiếng họ hoặc chặn họ).
  • Quyền truy cập: Nếu các liên kết được trả về bởi listURI() đượ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 người nắm giữ truy cập đọc vào các liên kết được tìm thấy trong dữ liệu.

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

Giống như OCG, mỗi mối quan hệ xã hội đều được quản lý bằng hợp đồng thông minh, nhưng ngữ nghĩa của CLG thì khác:

  • Theo dõi: Chứa danh sách JSON các liên kết đến tên ENS mà bạn đang theo dõi và mã thông báo do danh sách này cấp sẽ cấp quyền đọc cho danh sách theo dõi đó.
  • đã tắt tiếng: Chứa danh sách JSON các liên kết đến tên ENS mà bạn đang tắt tiếng và mã thông báo mà nó phát hành sẽ cấp quyền truy cập đọc vào danh sách đã tắt tiếng đó.
  • khối: Chứa danh sách JSON các liên kết đến tên ENS mà bạn đang chặn và mã thông báo do nó phát hành sẽ cấp quyền truy cập đọc vào danh sách chặn đó.

Vì vậy, 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 X tài khoản của tôi", trong đó"X" có thể là "theo dõi", "tắt tiếng" hoặc "chặn".

Bạn có thể coi những gì tôi đề xuất trong phần này là một phép tính gần đúng của tổ hợp số điện thoại + danh bạ mà tôi đã mô tả cho các ứng dụng nhắn tin. Số điện thoại của bạn là (bán) 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 đó truy cập vào danh bạ của mình.

Trong gói mã thông báo xã hội CLG của tôi, tên ENS của bạn được công khai như số điện thoại, và bạn sẽ cấp và thu hồi mã thông báo để cấp hoặc từ chối quyền truy cập vào danh sách những người bạn có mối quan hệ. Bạn có thể cấp 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 bạn sẽ cấp cho các nền tảng xã hội để họ 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 ghi vào các 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í, bạn có thể ghi/cập nhật/xóa các danh sách. Một giải pháp thay thế khả thi là có một hợp đồng xã hội thứ tư cấp cho người nắm giữ NTFT quyền ghi vào các danh sách, để bạn có thể thuê ngoài việc quản lý danh sách cho một bên thứ ba)

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

  • Bạn có thể khóa các 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ể để danh sách đó ở chế độ công khai để bất kỳ ai cũng có thể đọc được.
  • Việc cập nhật danh sách ngoài Chuỗi không tốn phí gas.
  • Giải pháp này cho phép thiết lập thị trường dịch vụ lưu trữ biểu đồ xã hội có khả năng tương tác với các nhà cung cấp dịch vụ xã hội.
  • Bất kỳ ai hoặc bất kỳ dịch vụ nào cũng có thể dễ dàng phát hiện danh sách của bạn.

Kiểm soát truy cập token và quyền truy cập đọc

Cải tiến quan trọng cho phép hợp đồng CLG hoạt động là kiểm soát truy cập token. Khái niệm đằng sau kiểm soát truy cập token 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 nó bằng ví chứa một token truy cập cụ thể.

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

CLG sử dụng cổng token để thêm một số gián tiếp 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, để kiểm soát truy cập token hoạt động, nền tảng phải tuân thủ chúng. Giả sử, nếu nền tảng không tuân thủ kiểm soát truy cập token, bạn sẽ phải chuyển danh sách mối quan hệ của mình sang các nền tảng khác và thay đổi hợp đồng, đồng thời phát hành lại bất kỳ NFT nào nếu cần.

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

Mẫu hợp đồng: CLG theo sau

Hợp đồng sau đây sẽ là hợp đồng NTFT ERC721 tiêu chuẩn, rất giống với hợp đồng OCG ở trên:

// SPDX-Mã định danh giấy phép: MIT

pragma solidity ^0.8.4;

nhập "@openzeppelin/contracts/token/ERC721/ERC721.sol";

nhập "@openzeppelin/contracts/security/Pausable.sol";

nhập "@openzeppelin/contracts/access/Ownable.sol";

nhập "@openzeppelin/contracts/token/ERC721/extensions/ERC721Burnable.sol";

nhập "@openzeppelin/contracts/utils/Counters.sol";

hợp đồng CLGFollows là ERC721, Có thể tạm dừng, Có thể sở hữu, ERC721Burnable {

sử dụng Counters cho Counters.Counter;

Bộ đếm.Bộ đếm riêng tư _tokenIdCounter;

constructor() ERC721("CLGF theo dõi", "CLGF") {}

hàm _baseURI() ghi đè thuần túy nội bộ trả về (bộ nhớ chuỗi) {

trả về "https://jonstokes.com/clgfollows/";

}

hàm listURI() công khai {

trả về "https://jonstokes.com/clgfollows/list";

}

hàm quan hệ() công khai {

trả về "clg theo sau";

}

hàm pause() public onlyOwner {

_tạm dừng();

}

hàm unpause() public onlyOwner {

_bỏ tạm dừng();

}

hàm safeMint(địa chỉ đến) public onlyOwner {

uint256 tokenId = _tokenIdCounter.current();

_tokenIdCounter. tăng();

_safeMint(đến, tokenId);

}

hàm _beforeTokenTransfer(địa chỉ từ, địa chỉ đến, uint256) ghi đè thuần túy nội bộ {

//Vô hiệu hóa chuyển mã thông báo.

require(from == address(0) || to == address(0), "Không thể chuyển nhượng.");

}

}

Tất cả mở rộng đều giống như OCG, ngoại trừ việc tôi không đưa vào ERC721Enumerable vì không rõ liệu có ai muốn token 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).

Về chức năng, tôi đã thực hiện những thay đổi sau đây đối với đầu ra của trình hướng dẫn OpenZeppelin:

  • relationship() : Giống như OLG, hàm này trả về kiểu của 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 hợp đồng Solidity, và tôi chưa thấy nó được thực hiện, nhưng dù sao thì tôi cũng muốn hợp đồng tự báo cáo kiểu của nó. Vì vậy, tôi không biết nữa - nếu điều này làm bạn khó chịu, xin hãy bỏ qua.
  • listURI() trả về một liên kết đến một đối tượng JSON chứa danh sách các tên ENS mà bạn đang theo dõi (hoặc tắt tiếng hoặc chặn, tùy thuộc vào loại hợp đồng). Chúng tôi khuyến khích URI này được đánh dấu riêng tư, nhưng điều này không bắt buộc.

Thông thường, bạn sẽ sử dụng CLG Follows NTFT và đăng lên một địa chỉ thuộc sở hữu của nền tảng mạng xã hội. Bằng cách này, 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 những NTFT này cho người theo dõi để 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ể thực hiện việc này bằng cách airdrop chúng cho người theo dõi, hoặc bằng cách mở khóa khối đúc và cho phép bất kỳ ai tạo ra coin.

Tất cả các hợp đồng khác đều hoạt động chính xác như mô tả ở trên, nhưng có tên và ký hiệu khác nhau và trả về các giá trị khác nhau từ relationship() 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, việc thay đổi listURI() thành một hàm tương tự như tokenURI(uint256 tokenId) —tức là, chữ ký là listURI(uint256 tokenId) —sẽ nối tokenID vào cuối URI cơ sở, để mỗi người nắm giữ token sẽ nhận được URL danh sách riêng. Điều này, kết hợp với một số logic trên máy chủ danh sách, cho phép bạn cô lập danh sách để người nắm giữ token khác nhau sẽ nhận được các biểu đồ con khác nhau của biểu đồ chính. Bằng cách đó, nếu một nền tảng bị xâm phạm, chỉ phần biểu đồ đó của tôi bị rò rỉ.

Giống như OCG, bạn có thể thiết lập safemint thành một chức năng trả phí và thu phí người dùng khi truy cập danh sách của bạn. Xem mã trong phần OCG để biết ví dụ về điều này.

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 đó trong các biến, khởi tạo chúng trong hàm khởi tạo và cung cấp một setter onlyOwner để cập nhật chúng. Điều này sẽ làm tăng chi phí đúc tiền 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ụ

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

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

Một dịch vụ hữu ích khác là phiên bản chuyên biệt của Infura, cho phép hiển thị dữ liệu xã hội Chuỗi thông qua API. Ngoài ra, Infura có thể cung cấp API chuyên dụng cho dữ liệu xã hội.

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ôi không biết liệu tôi có mong đợi các đề xuất về biểu đồ xã hội Chuỗi của mình sẽ được áp dụng theo hình thức tôi đã mô tả ở đây hay không. Tôi nêu ra những ý tưởng này chủ yếu để khơi mào một cuộc thảo luận về cách chúng ta có thể chuyển đổi hiệu quả từ trạng thái khóa chặt hoàn toàn nền tảng 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ột số ý tưởng trên có vẻ giống với các đề xuất của web5, nhưng điểm khác biệt chính là hai ý tưởng của tôi được thiết kế đơn giản hơn và tận dụng các hợp đồng thông minh cũng như các nhà cung cấp danh tính trên Chuỗi hiện có (ENS, nhưng cũng như các nhà cung cấp tương tự trên Chuỗi khác).

Nếu bạn không rút ra được điều gì từ bài đăng này, tôi hy vọng ít nhất tôi đã chứng minh được 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 trong một 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 hiện có rất nhiều, chúng ta chỉ cần chọn chúng và sử dụng.

Nguồn
Tuyên bố từ chối trách nhiệm: Nội dung trên chỉ là ý kiến của tác giả, không đại diện cho bất kỳ lập trường nào của Followin, không nhằm mục đích và sẽ không được hiểu hay hiểu là lời khuyên đầu tư từ Followin.
Thích
Thêm vào Yêu thích
Bình luận
Nội dung liên quan