Giải thích chi tiết về giao thức xã hội Web3 Giao thức Farcaster: Phép thuật nào có thể khiến V God định cư?

Văn bản gốc: "Giao thức xã hội đã được cuộn lại!" Farcaster là gì? 》
Tác giả: ELEN
Farcaster Protocol là một sản phẩm hàng đầu khác trên đường đua SocialFi sau Lens Protocol. Farcaster là một dự án của cựu giám đốc điều hành Coinbase Dan Romero và Varun Srinivasan. Nó hiện đã nhận được 30 triệu USD đầu tư do A16Z dẫn đầu.
Mục tiêu của Farcaster là cung cấp giao thức trung lập đáng tin cậy cho hệ sinh thái WEB3, cho phép người dùng tiếp xúc trực tiếp với khán giả của họ, đồng thời cho phép các nhà phát triển tự do xây dựng ứng dụng khách mới.
 Thần Viafarcaster V định cư ở
Mục tiêu lâu dài của Farcaster là trở thành cơ sở hạ tầng cơ bản quan trọng trong mạng xã hội WEB3. Điều này phù hợp với định hướng của Lens Protocol. Tuy nhiên, thiết kế kiến ​​trúc của Farcaster phức tạp hơn nhiều so với Lens Protocol và nó áp dụng nỗ lực thu hẹp khoảng cách giữa WEB2 và WEB3.Chiến lược tìm điểm cân bằng tối ưu.
 ViaBlockTurbo
Hôm nay chúng ta sẽ xem xét sâu hơn về thiết kế lớp giao thức và ý tưởng ứng dụng sinh thái của Farcaster. Nếu muốn nghiên cứu sâu, bạn có thể xem qua github chính thức:
https://github.com/farcasterxyz/protocol
 Giới thiệu về Farcaster
Mạng xã hội là ngành phát triển nhanh nhất trong 10 năm qua. Nhiều nền tảng xã hội cung cấp cho các nhà phát triển API, cho phép các nhà phát triển "sáng tạo thứ cấp" và phát triển các hệ sinh thái mới, chẳng hạn như nhiều plugin thú vị khác nhau trên Twitter. Tuy nhiên, trong những năm gần đây, mọi thứ dường như không ổn. Có vẻ như ngày càng có ít điều mà các nhà phát triển có thể làm. Các hạn chế về API và các biện pháp kiểm duyệt khác nhau khiến các nhà phát triển không còn rảnh rỗi, thậm chí đôi khi không có bất kỳ thông báo nào. bị tước quyền truy cập.
Farcaster là một giao thức phi tập trung hoàn toàn tạo điều kiện cho các nhà phát triển xây dựng các ứng dụng mạng xã hội phi tập trung. Định nghĩa về phân cấp của Farcaster rất đơn giản: khi hai người dùng muốn liên lạc với nhau, không có cách nào ngăn điều này xảy ra. Nghĩa là, người dùng có toàn quyền kiểm soát danh tính, dữ liệu và kết nối xã hội của họ. Các nhà phát triển có thể xây dựng một ứng dụng xã hội phi tập trung hoàn toàn bằng cách phá vỡ các hạn chế của bất kỳ bên thứ ba nào hoặc thậm chí cả mạng lưới.
Tầm nhìn này cũng là điều mà Lens Protocol muốn đạt được. Chúng tôi có thể nghĩ rằng giá trị lớn nhất của giao thức cơ bản của SocialFi là cung cấp phương pháp triển khai kỹ thuật cơ bản của mạng xã hội hoàn toàn phi tập trung, để nó không bị kiểm soát bởi bất kỳ bên thứ ba nào. Tương tự như giá trị của IPFS trên thị trường lưu trữ phi tập trung.
 Viafarcaster.network Kiến trúc Farcaster
Farcaster áp dụng kiến ​​trúc kết hợp trên chuỗi + ngoài chuỗi để hoàn thành việc xây dựng giao thức phi tập trung. Danh tính của Farcaster được lưu trữ trên chuỗi Ethereum và tận dụng Ethereum để đảm bảo tính bảo mật, khả năng kết hợp và tính nhất quán của nó. Danh tính được kiểm soát thông qua địa chỉ Ethereum và các tin nhắn ngoài chuỗi được ký thông qua tài khoản Ethereum.
Dữ liệu của người dùng được mã hóa và ký thông qua danh tính và được lưu trữ trên các máy chủ do người dùng kiểm soát (Farcaster Hubs). Lý do dữ liệu không được lưu trữ trên chuỗi là do chi phí thanh toán trên hầu hết các mạng L1 và L2 quá cao và tốc độ. quá chậm.
Kiến trúc này khác với thiết kế của Giao thức LENS. Farcaster tính đến nhu cầu thực tế của các nhà phát triển nhiều hơn và giống với cách thể hiện của phương tiện truyền thông xã hội WEB2 hơn, giúp giảm chi phí học tập của người dùng. Tuy nhiên, Farcaster vẫn được phân cấp và nhận dạng người dùng. , dữ liệu và các mối quan hệ xã hội đều dựa trên blockchain.
Tài khoản
Tài khoản Farcaster tương tự như tài khoản trên các mạng xã hội có biệt danh như Twitter hoặc Reddit và các cá nhân có thể vận hành nhiều tài khoản cùng một lúc. Mỗi tài khoản có một số duy nhất được liên kết với nó, được gọi là ID Farcaster hoặc Fid. ID Farcaster có thể được lấy từ địa chỉ Ethereum bằng cách gọi Cơ quan đăng ký ID Farcaster (FIR). Địa chỉ này được gọi là địa chỉ ký quỹ và có thể ký thông tin ngoài chuỗi và trên chuỗi thay mặt cho tài khoản. Người dùng có thể chọn lấy tên hoặc tên Farcaster từ Cơ quan đăng ký tên Farcaster (FNR), nơi cấp cho họ một tên duy nhất, chẳng hạn như @alice.
Có thể hiểu rằng Fid là danh tính on-chain, trong khi FNR là danh tính có thể đọc được trên mạng xã hội. Nếu Fid là địa chỉ ví thì FNR là ENS.
Thông tin chữ ký
Thông tin chữ ký là đối tượng chống giả mạo và tự chứng nhận, được ký bởi fid. Thông tin chữ ký thể hiện hành động của người dùng, chẳng hạn như đăng bài, phản hồi trên mạng xã hội (nhận xét/tweet lại) hoặc sửa đổi thông tin tài khoản, chẳng hạn như tên người dùng.
Tin nhắn đã ký có thuộc tính tin nhắn chứa một số tải trọng. Tải trọng được tuần tự hóa, băm và được ký bởi một cặp khóa hợp lệ (ví dụ: địa chỉ costody). Phong bì chứa giá trị băm, chữ ký và khóa chung của cặp khóa ký mà bất kỳ người nhận nào cũng có thể sử dụng để xác minh chữ ký của fid.
Tin nhắn phải được tuần tự hóa bằng RFC-8785, được băm bằng BLAKE2b và được ký bằng sơ đồ chữ ký Ed25519. Mỗi tin nhắn cũng phải chứa một fid để truy vấn địa chỉ ký quỹ trên chuỗi và dấu thời gian để sắp xếp.
ứng dụng
Ứng dụng là các chương trình mà mọi người sử dụng để tương tác với mạng Farcaster. Một ứng dụng đơn giản có thể bao gồm một máy tính để bàn hoặc máy khách di động độc lập giao tiếp trực tiếp với Farcaster Hub. Nó có thể xuất bản các tin nhắn mới và xem các tin nhắn được xuất bản bởi các FID khác. Các ứng dụng như vậy được tự lưu trữ và phải được khởi tạo bằng địa chỉ lưu trữ hoặc khóa ký hợp lệ.
Các ứng dụng phức tạp hơn có thể thêm máy chủ phụ trợ proxy để lập chỉ mục dữ liệu của Hub. Lập chỉ mục cho phép máy chủ triển khai các chức năng như tìm kiếm, cung cấp thuật toán và phát hiện thư rác, những chức năng này khó thực hiện hoặc tốn kém trên Hub. Một ứng dụng như vậy có thể tự lưu trữ bằng cách lưu trữ các khóa trên máy khách; được ủy quyền bằng cách yêu cầu người dùng cung cấp khóa ký được ủy quyền hoặc được ký quỹ bằng cách quản lý tất cả các khóa.
Trung tâm
Hub là một máy chủ luôn hoạt động để xác minh, lưu trữ và sao chép thông tin chữ ký. Người dùng chọn một Hub và xuất bản URL của nó trên chuỗi bằng FIR. Người theo dõi của họ có thể sử dụng URL này để tìm và tải xuống tin nhắn của họ. Đồng thời, người dùng cũng có thể tự chạy Hub hoặc sử dụng dịch vụ lưu trữ của bên thứ ba.
 Danh tính của Farcaster
Hệ thống nhận dạng của Farcaster cho phép danh tính của người dùng có các thuộc tính sau:
 An toàn và phân cấp hoàn toàn Dễ dàng nhận dạng trên mạng xã hội Dễ dàng thiết lập (nhanh chóng và rẻ) Có thể phục hồi (không vi phạm bản chất của phân cấp)
Những tính năng này rất khó triển khai trong hệ thống nhận dạng vì chúng thường xung đột với nhau. Ví dụ: rất khó để có một hệ thống tên phi tập trung, đáng tin cậy (ví dụ: liệu có đảm bảo tính duy nhất của hệ thống tên hay không).
Farcaster cân bằng các tính năng này thông qua hai hệ thống độc lập. Cơ quan đăng ký ID Farcaster (FIR) cấp số ID mới, được gọi là fids; Cơ quan đăng ký tên Farcaster (FNR) cấp tên người dùng mới, được gọi là fname. Fids là các mã định danh phi tập trung, an toàn tồn tại trong mọi tin nhắn và có khái niệm tương tự như uuids.
Fname chủ yếu dùng để sửa đổi FIR, thay thế fid khi hiển thị và có thể thay đổi bất cứ lúc nào. Việc tách danh tính thành hai thành phần này cho phép chúng tôi đạt được mục tiêu của mình nhưng phải trả giá bằng việc tăng thêm một số độ phức tạp cho hệ thống. Cả hai hệ thống cũng triển khai cơ chế khôi phục nhằm bảo vệ việc mất các cặp khóa kiểm soát tên mà không ảnh hưởng đến tính phân cấp.
Cơ quan đăng ký ID Farcaster (FIR)
ID Farcaster là số nhận dạng số, tương tự như uuid. Khi hiển thị cho người dùng, chúng sẽ đứng trước một dấu chấm than (ví dụ: !8098).
FID đại diện cho một thực thể duy nhất, chẳng hạn như một cá nhân hoặc một tổ chức. Mọi tham chiếu đến thực thể này phải sử dụng fid của nó chứ không phải tên của nó. Phí đăng ký FID rất thấp và được sở hữu trọn đời. Hợp đồng FID không thể được nâng cấp hoặc sửa đổi dưới bất kỳ hình thức nào.
FID bắt đầu từ 0 và tăng lên 1 mỗi lần đăng ký mới. Fid được lưu trữ trên chuỗi dưới dạng uint256, đảm bảo nguồn cung gần như vô hạn vì nó có thể tăng lên ~10^77.
Người dùng có thể sử dụng FIR để định cấu hình URL nhằm tìm vị trí thông tin ngoài chuỗi của họ.
Cơ quan đăng ký tên Farcaster (FNR)
Tên Farcaster là duy nhất, tương tự như tên người dùng trên các mạng khác. Khi hiển thị cho người dùng, chúng sẽ được đặt trước ký hiệu @ (ví dụ: @alice).
Fname, cùng với hồ sơ, tên và mã thông báo xác minh, giúp nhận dạng trực quan một thực thể trong khi duyệt web. Không giống như fids, fname chủ yếu có thể đọc được và không liên quan gì đến dữ liệu cơ bản do người dùng tạo. Quyền sở hữu tên không phải là vĩnh viễn và người dùng phải trả một số phí hàng năm. Việc gia hạn fname có thể được thực hiện 90 ngày trước khi fname hết hạn. Tên hết hạn sẽ được bán đấu giá trong một cuộc đấu giá ở Hà Lan, với những người đặt giá thầu phải trả phí hàng năm và phí bảo hiểm, bắt đầu từ 1.000 ETH. Phí bảo hiểm giảm 10% cứ sau 8 giờ cho đến khi đạt 0 ETH.
Tên Fname là NFT do Cơ quan đăng ký tên Farcaster cấp trên cơ sở ai đến trước được phục vụ trước. Mỗi tên phải khớp với biểu thức chính quy /^[a-z0-9][a-z0-9-]{0,15}$/. Chúng có các thuộc tính cụ thể giúp chúng hữu ích hơn trong mạng xã hội so với các không gian tên khác như ENS. Chúng rẻ hơn để đúc và sở hữu, ít bị tấn công từ đồng âm hơn do giới hạn về bộ ký tự và cũng có thể phục hồi được. Farcaster không yêu cầu sử dụng fname, người dùng có thể tự do sử dụng các không gian tên khác và fids của họ.
Việc từ bỏ việc sử dụng fname sẽ không có nhiều tác động, vì Farcaster được thiết kế xoay quanh fid, và mọi thông tin cũng như hành vi đều hướng đến fid chứ không phải frame. tên có thể được thay đổi bất kỳ lúc nào mà không làm mất bất kỳ thông tin phụ thuộc nào trước đó.
Chính sách tên người dùng
Trong giai đoạn thử nghiệm beta, tên người dùng có thể được đăng ký miễn phí và tuân theo chính sách đơn giản. Mục đích của chính sách này là ngăn chặn việc người dùng không hoạt động lấy tên hoặc sử dụng tên với mục đích xấu để mạo danh người khác. Giải pháp cho vấn đề này không dễ dàng được tự động hóa và cần có sự phán đoán của con người để thực hiện. Chính sách tên người dùng có hai nguyên tắc cốt lõi:
 Mạo danh - Nếu bạn đăng ký dưới tên người dùng thuộc về một nhân vật hoặc tổ chức nổi tiếng của công chúng, tên của bạn có thể bị hủy đăng ký. Ví dụ: @elonmusk, @vitalikbuterin, @google hoặc @whitehouse. Không hoạt động - Nếu bạn không tích cực sử dụng tên người dùng trong hơn 60 ngày, tên của bạn có thể bị hủy đăng ký theo yêu cầu của người dùng khác hoặc theo quyết định riêng của chúng tôi.
Chúng tôi dự đoán rằng thường sẽ cần phải can thiệp thủ công vì có thể xảy ra xung đột chính đáng. Ví dụ: bạn đã đăng ký @vitalik và Vitalik Buterin đã đăng ký sau bạn và muốn có cái tên đó. Trong trường hợp này, chúng tôi hỏi ba câu hỏi để đưa ra quyết định:
 Người dùng này có đang hoạt động và tương tác trên Farcaster không? (Ví dụ: nếu họ đã xuất bản các bài đăng chất lượng cao trong vài tháng qua.) Người dùng này có yêu cầu chính đáng đối với tên này không? (Ví dụ: nếu tên của họ cũng là Vitalik) Người dùng này có tài khoản tương tự, đang hoạt động trên các mạng khác không? (Ví dụ: nếu họ có Vitalik và Vitalik.ens trên Twitter).
Nếu câu trả lời cho những câu hỏi này hầu hết là có, họ sẽ giữ nguyên quyền sở hữu tên của mình. Trong testnet, nhóm cốt lõi sẽ phân xử xung đột này và chúng tôi hy vọng sẽ chính thức thiết lập một hệ thống quản lý xung quanh vấn đề này khi chúng tôi tiến gần hơn đến mainnet. Nếu tên bị rút do trọng tài, người dùng sẽ không được hoàn lại tiền.
Khôi phục tài khoản
Nếu người dùng mất chìa khóa đến địa chỉ chứa ID và tên, ID và tên Farcaster có thể được phục hồi. Cả hai hợp đồng đều triển khai hệ thống khôi phục bị trì hoãn cho phép các yêu cầu địa chỉ khôi phục được chuyển đến địa chỉ mới. Nếu địa chỉ lưu ký không hủy quá trình chuyển trong vòng ba ngày thì địa chỉ khôi phục có thể hoàn tất quá trình chuyển.
Người dùng có thể đặt địa chỉ khôi phục thành một địa chỉ khác trong ví của chính họ, multisig được chia sẻ với bạn bè hoặc dịch vụ khôi phục của bên thứ ba. Người dùng cũng có thể thay đổi địa chỉ khôi phục bất cứ lúc nào. Quyền sở hữu vẫn được phân cấp vì địa chỉ khôi phục không thể thực hiện chuyển khoản mà địa chỉ giám sát không đồng ý.
Việc chuyển tài sản sang địa chỉ ký quỹ mới sẽ hủy đặt địa chỉ khôi phục. Nếu không, người dùng có thể mua tên trên OpenSea, chỉ để chủ sở hữu trước đó bí mật yêu cầu lại tên đó bằng địa chỉ khôi phục của họ.
 xử lý thông tin
Xử lý thông tin là quá trình Hub chấp nhận tin nhắn mới và xác định trạng thái của người dùng. Người dùng gửi tin nhắn đến Hub cho mỗi hành động của họ. Nếu người dùng thích một URL, không thích nó và thích nó thì ba thông báo sẽ được tạo. Hub nhận được tất cả thông tin sẽ xác định trạng thái hiện tại của các URL yêu thích của người dùng.
Hub có thể loại bỏ hai thông tin đầu tiên để tiết kiệm dung lượng. Hub có thể nén các tin nhắn như vậy bằng cách sử dụng thao tác hợp nhất, giúp tránh sự không nhất quán phía máy khách và tiết kiệm dung lượng. Tin nhắn có thể có các quy tắc khác nhau cho hoạt động hợp nhất của chúng. Ví dụ: hai lượt thích từ một người dùng đến cùng một người dùng có thể được nén thành một, nhưng hai lượt phản hồi thì không.
Hub có thể mất một số thông tin của người dùng và rơi vào trạng thái lỗi. Ví dụ: nó có thể chỉ nhận được tin nhắn thích và không thích đầu tiên, điều này sẽ đặt trạng thái hiện tại là không thích. Hoạt động hợp nhất sẽ cho phép trạng thái tiếp tục và đạt được tính nhất quán khi các thông báo bị thiếu được phát lại. Nói cách khác, việc hợp nhất cuối cùng phải đảm bảo tính nhất quán mạnh mẽ.
Hub đạt được điều này bằng cách triển khai một bộ CRDT cho từng loại thông báo, mã hóa các quy tắc hợp nhất và xác thực cụ thể. Tính năng này giúp Hub có tính khả dụng cao vì chúng có thể được đưa ngoại tuyến bất kỳ lúc nào và luôn có thể được khôi phục để đồng bộ hóa. Về mặt hình thức, bộ CRDT của chúng tôi là CRDT2 trạng thái delta ẩn danh và mỗi thông báo là một bản cập nhật được kết nối và không thể rút gọn trên bộ này.
Sắp xếp thông tin
Việc thu thập thông tin có thể sắp xếp thông tin chữ ký theo dấu thời gian và giải quyết xung đột hợp nhất với chính sách được viết lần cuối. Tuy nhiên, họ không thể đảm bảo thứ tự hoàn hảo vì dấu thời gian dễ bị lệch đồng hồ, lệch đồng hồ, giả mạo bởi người dùng độc hại và có thể xung đột vì một số lý do. Các ứng dụng có thể sử dụng đồng hồ hỗn hợp để tạo ra các dấu thời gian có thứ tự hoàn hảo mà không bị xung đột, nhưng chúng ta không thể ép buộc sử dụng chúng.
Thay vào đó, chúng tôi xác định một hệ thống sắp xếp cho các tin nhắn đảm bảo tổng số thứ tự bằng cách sử dụng dấu thời gian để xác định thứ tự ban đầu và hàm băm để phá vỡ xung đột. Tổng thứ tự được đảm bảo vì hai tin nhắn không thể có cùng giá trị băm trừ khi chúng là cùng một tin nhắn. Hai tin nhắn a và b có thể được so sánh bằng thuật toán này:
 Nếu a.timestamp>b.timestamp thì a lớn hơn. Nếu a.timestamp < b.timestamp thì b lớn hơn. nếu a.timestamp == b.timestamp
- Nếu a.hash>b.hash thì a lớn hơn.
- Nếu a.hash<b.hash thì b lớn hơn.
        - 如果a.hash = b.hash，a == b
Dấu thời gian được so sánh dưới dạng số, trong khi giá trị băm được so sánh dưới dạng chuỗi. Vì các so sánh chuỗi khác nhau giữa các lần triển khai nên chúng tôi phải chính xác trong các thuật toán so sánh của mình. Chúng tôi tin rằng hai giá trị băm x và y có thể được so sánh bằng cách so sánh từng cặp ký tự:
 Nếu tất cả các cặp ký tự bằng nhau và cả x và y đều kết thúc thì x == y Nếu tất cả các cặp ký tự bằng nhau và x kết thúc trước thì y>x Nếu gặp một cặp ký tự khác xC, yC thì Nếu ASCII( yC)>ASCII(xC), rồi y>x
Xác minh thông tin
Ngoài các xác thực dành riêng cho loại thông báo, tất cả các thông báo phải vượt qua các xác thực sau:
 message.timestamp không quá 1 giờ trước thời gian hệ thống. message.fid phải là số fid đã biết trong FIR. signerPubKey phải là người ký được quản lý hợp lệ hoặc chữ ký được ủy quyền cho message.fid hashFn(serializeFn(message)) phải khớp với phong bì.hash, trong đó hashFn là hàm Blake2B và serializeFn thực hiện chuẩn hóa JSON. EdDSA_signature_verify(envelope.hash, phong bì.signerPubKey, phong bì.signature) sẽ vượt qua.
Diễn viên
Cast là thông tin công khai do người dùng tạo, chứa văn bản và cũng có thể được nhúng vào phương tiện, hoạt động trên chuỗi hoặc các Cast khác. Các phiên truyền được lưu trữ trong bộ sưu tập CRDT3 hai giai đoạn để giải quyết xung đột giữa các tin nhắn.
Có thể thêm Cast thông qua thông báo CastAdd, được đặt trong bộ bổ sung của CRDT. Mỗi Cast được lập chỉ mục theo giá trị băm của nó, giá trị này được đảm bảo là duy nhất trừ khi các Cast giống hệt nhau. Nói rộng ra, hai thông báo thêm sẽ không bao giờ xung đột trừ khi chúng giống hệt nhau, trong trường hợp đó một thông báo có thể được loại bỏ một cách an toàn.
Các diễn viên có thể được loại bỏ thông qua thông báo CastRemove, trong đó có chứa tham chiếu đến hàm băm của CastAdd đích. Khi nhận được thông báo này, mục tiêu sẽ bị xóa khỏi tập hợp bổ sung nếu nó tồn tại và mục tiêu đã xóa sẽ được thêm vào tập hợp lại. Xung đột giữa các lần thêm và xóa được xử lý bằng quy tắc Xóa-Thắng, trong khi xung đột giữa các lần xóa được xử lý bằng quy tắc Ghi-Thắng Cuối cùng, quay trở lại thứ tự từ điển trong trường hợp hòa.
thêm thông tin
Cast Add có thể chứa văn bản unicode có tối đa 320 ký tự và hai URI có tối đa 256 ký tự. Máy khách chịu trách nhiệm giải mã và hiển thị URI và văn bản cùng nhau.
Diễn viên không có cha mẹ là diễn viên cấp cao nhất và ứng dụng khách sẽ xuất hiện trên hồ sơ hoặc dòng thời gian của người dùng. Diễn viên gốc là phản hồi cho một diễn viên, URL web hoặc đối tượng trên chuỗi khác và phải được hiển thị trong một chuỗi.
Các cuộc thăm dò tạo thành một chuỗi cây, trong đó mỗi gốc là một cuộc thăm dò hoặc URI và mỗi nút con là một cuộc thăm dò trả lời. Mỗi cây có thể được hiển thị dưới dạng một cuộc trò chuyện theo chuỗi. Cây được đảm bảo là không tuần hoàn vì nút cha phải được băm và ký trước khi nút con có thể trỏ đến nó. Mọi thay đổi đối với dữ liệu của nút cha sẽ phá hủy mọi mối quan hệ với các nút con của nó.
Thông tin truyền phải vượt qua các bước xác minh sau.
 Văn bản phải chứa <=320 ký tự unicode hợp lệ được nhúng phải chứa từ 0 đến 2 mục. Các mục phải là URI tối đa 256 ký tự. Nếu có cha mẹ thì phải là URI hợp lệ, không bằng URI của thông báo này (ví dụ: fid:/cast:).
xóa tin nhắn
Cast Remove chỉ đơn giản chứa tham chiếu đến hàm băm của Cast Add. Nó cho phép xóa vĩnh viễn Cast trong khi xóa dữ liệu của Cast gốc.
Tin nhắn phải vượt qua các bước xác minh sau:
 message.data.body.hash không được bằng message.envelope.hash. message.timestamp phải là <= đồng hồ hệ thống + 10 phút message.data.fid phải là fid đã biết trong FIR
hợp nhất quy tắc
Khi nhận được thông báo thêm a, nếu r tồn tại trong tập hợp lại và r.data.body.hash bằng a.hash thì a sẽ bị loại bỏ. Ngược lại, thêm a vào tập hợp cộng. Khi nhận được thông báo xóa r, nếu có a.hash bằng r.data.body.hash trong tập hợp đã thêm, hãy xóa nó. Nếu có r' trong rem-set, trong đó r.data.body.hash bằng r'.data.body.hash, nếu r'>r, loại bỏ r';
hành động
Hành động là một hoạt động công khai được thực hiện bởi người dùng trên một mục tiêu, có thể là một người dùng khác hoặc một hoạt động trên chuỗi. Hiện tại có hai loại hành động được hỗ trợ: thích và theo dõi. Giao thức có thể dễ dàng mở rộng để hỗ trợ các Hành động mới. Người dùng có thể hoàn tác và làm lại các hành động bằng cách chuyển đổi thuộc tính hoạt động trên tin nhắn. Về mặt khái niệm, mỗi hành động là một cạnh trong biểu đồ xã hội.
Hành động được quản lý bằng cách sử dụng LWW-Element-Set CRDT, đảm bảo tính nhất quán cuối cùng. Về mặt khái niệm, có một bộ sưu tập duy nhất lưu trữ tất cả các thông báo và xung đột được giải quyết thông qua dấu thời gian và thứ tự băm từ điển. Việc bổ sung được thực hiện bằng cách xây dựng một thông báo hành động a với hoạt động được đặt thành đúng, trong khi việc xóa được thực hiện bằng cách đặt hoạt động thành sai. Trong cả hai trường hợp, logic để hợp nhất các tin nhắn thành các bộ là:
Nếu có một Hành động x trong bộ sưu tập, thì các giá trị loại, Uri đích và fid của nó giống với hành động đến y. Nếu x>y, loại bỏ y nếu x;
xác minh
Xác minh là bằng chứng hai chiều về quyền sở hữu giữa tài khoản Farcaster và tổ chức bên ngoài. Việc xác minh có thể được sử dụng để chứng minh quyền sở hữu các địa chỉ Ethereum, NFT cụ thể, các tài khoản mạng xã hội khác và thậm chí cả tên miền.
Có ba khái niệm cốt lõi trong việc xác minh:
 Báo cáo, bao gồm các tham chiếu đến tài khoản Farcaster và các tổ chức bên ngoài. Các xác nhận quyền sở hữu có thể được băm để tạo mã định danh duy nhất cho mỗi xác nhận quyền sở hữu. Bằng chứng về tính định hướng từ một thực thể bên ngoài được ủy quyền đưa ra yêu cầu thể hiện ý định kết nối với tài khoản Farcaster. Bằng chứng về tính định hướng từ tài khoản Farcaster để chấp nhận yêu cầu liên kết khiếu nại với tài khoản Farcaster.
Sự ủy quyền của người ký
Ủy quyền người ký là thông báo cho phép cặp khóa mới tạo chữ ký cho tài khoản Farcaster.
Khi một fid được tạo ra, chỉ địa chỉ giám sát mới có thể thay mặt nó ký các tin nhắn. Người dùng có thể không muốn tải cặp khóa này vào mọi thiết bị vì nó làm tăng nguy cơ bị xâm phạm tài khoản. Địa chỉ giám hộ, còn được gọi là người ký giám hộ, có thể ủy quyền các cặp khóa của người khác được gọi là người ký được ủy quyền. Không giống như người ký theo quy định, người ký được ủy quyền chỉ được phép xuất bản thông tin ngoài chuỗi và không thể thực hiện bất kỳ hoạt động nào trên chuỗi.
Người ký quỹ tạo chữ ký ECDSA trên đường cong secp256k1 và chỉ có thể xuất bản thông tin ủy quyền của người ký. Tất cả các loại thông báo khác phải được ký bởi người ký được ủy quyền, người tạo chữ ký EdDSA trên đường cong255194. Người ký được ủy quyền có thể được sử dụng để ủy quyền cho các thiết bị mới hoặc thậm chí các dịch vụ của bên thứ ba ký tin nhắn cho một tài khoản. Nếu một người ký được ủy quyền bị xâm phạm, nó có thể bị thu hồi bởi chính nó, tổ tiên của nó trong chuỗi tin cậy hoặc bất kỳ người ký được ủy quyền nào. Khi người ký bị thu hồi, Hub sẽ loại bỏ tất cả thông tin ký của họ vì không có cách nào để phân biệt thông tin của người dùng với thông tin của kẻ tấn công.
Người dùng cũng có thể chuyển ID sang địa chỉ ký quỹ mới do khôi phục khóa hoặc thay đổi ví. Người ta thường mong muốn lưu giữ lịch sử để cả hai địa chỉ ký quỹ đều trở thành người ký quỹ hợp lệ. Tập hợp các người ký hợp lệ cho một id tạo thành một loạt các cây khác nhau. Phần gốc của mỗi cây là địa chỉ lưu ký lịch sử và các lá là người ký được ủy quyền.
Tập người ký là tập hợp hai pha được sửa đổi với ngữ nghĩa xóa-thắng và ghi-thắng cuối cùng. Thông tin mới sẽ được thêm vào bộ sưu tập nếu nó được ký bởi hiệu trưởng hoặc người giám hộ hợp lệ. Việc xóa được chấp nhận nếu có chữ ký của chính bạn hoặc tổ tiên. Sau khi người ký bị xóa, người ký đó không thể được thêm vào và tất cả các hậu duệ cũng như tin nhắn của nó đều bị loại bỏ.
Nếu hai người ký hợp lệ lần lượt ủy quyền cho cùng một người ký được ủy quyền thì sẽ xảy ra xung đột và phá hủy cấu trúc dữ liệu cây. Nếu điều này xảy ra, bộ sưu tập sẽ giữ thông báo có dấu thời gian và hàm băm từ điển cao nhất theo thứ tự.
Sự phân mảnh
Các trung tâm chỉ có thể sao chép dữ liệu cho các tài khoản cụ thể, đây là một thuộc tính hữu ích để mở rộng mạng. Nếu Farcaster phát triển đủ lớn để một máy chủ không thể hỗ trợ sao chép toàn bộ mạng lưới các trung tâm thì khối lượng công việc có thể được dàn trải trên nhiều trung tâm. Nhà điều hành trung tâm cũng có thể tránh đồng bộ hóa dữ liệu đối với những người dùng có hành vi ác ý hoặc không liên kết với nhà điều hành.
Sao chép có chọn lọc chỉ cung cấp một cái nhìn một phần của mạng. Nếu Hub đang đồng bộ hóa dữ liệu của Alice, nó sẽ biết rằng cô ấy đã trả lời và thích một trong các bài đăng của Bob. Tuy nhiên, nó sẽ không biết được nội dung bài viết của Bob, hay việc Bob thích câu trả lời của cô ấy rồi tiếp tục trả lời. Một ứng dụng nhằm mục đích cung cấp số lượt thích chính xác và cung cấp tất cả thông tin trả lời sẽ sao chép càng nhiều người dùng càng tốt.