Farcaster - это открытый протокол, позволяющий создавать социальные приложения.

Если вы не читали первую часть переходите сюда - клик

Как хранятся сообщения и как именно они передаются между хабами?
(Hubs - концептуально это как ноды в блокчейне, но алгоритм конценсуса отличается. Больше про hubs тут - клик)

Farcaster представляет новую концепцию - дельта-граф!

Дельта - это любые действия пользователя в социальной сети (like, unlike, share (Farcaster называют это - recast), reply).
Самое интересное происходит, когда люди создают дельты, конфликтующие друг с другом. Например, Боб лайкнул сообщение Алисы, а потом убрал лайк. Эти данные хранятся в хабе и когда разработчик их увидит, возникнет проблема. Два конфликтующих сообщения не могут быть одновременно истинны. Нужен способ решить конфилкт и прийти к консенсусу относительно того, что является текущим состоянием сети.

Набор дельт должен быть объединен с использованием набора правил для создания действительного социального графа.
Граф - простая структура данных, с вершинами, которые являются контентом и пользователями (то есть Алиса, Боб, сообщение Алисы "hello world", ответ Боба "welcome" - это всё вершины графа).
Когда пользователь создает сообщение, образуется новая вершина, а затем создается ребро (relationship), указывающее родителя этого сообщения. Ребра также указывают на взаимодействия, которые произошли (like, unlike, recast).

Основное правило - пользователь и часть контента могут иметь только одно отношение определнного типа. Одновременно не может быть, например, like и unlike. Отношения могут заключаться либо в том, что подобное истинно, либо в том, что ложно.
Хабы выполняют слияние (merge): берут набор дельт, анализируют и создают действительный социальный граф. А когда обнаруживается конфликт, то определяется только один "победитель"

Delta Graphs

Предположим, что Алиса создала сообщение "hello world", а Бобу оно понравилось. Для каждого сообщения определяется cid - идентификатор конфликта, который определяет уникальный объект в изменяемом графе. И определяется состояние - s. Вместе они образуют дельта-сообщение.

Повторяющиеся сообщения

Если Боб отправит два сообщения с одинаковым содержанием, то система не сможет увеличить количество лайков два раза. Это неправильно. Поэтому ввели уникальный идентификатор - хэш. Сообщения хэшируются. И так как второе сообщение имеет такое же содержимое, то и хэш не будет отличаться. Поэтому хаб сразу определит, что данное сообщение им уже обрабатывалось, и состояние не изменится. 

Duplicate messages

Конфликты

Что происходит, когда сообщения конфликтуют из-за изменения состояние s?

В данном случае уже не получится ссылаться на хэш. Из-за разного содержимого сообщений хэш будет отличаться.
Для решения проблемы ввели метку времени - t. Теперь известно какое сообщение было отправленно раньше, какое позже. И истинным считают более позднее сообщение.

Conflicts

Определение победителя

НО время может быть ненадёжно и быть одинаковым на двух конфликтующих сообщениях.
Тогда мы получим два сообщения с разными хэшами, но одним временем. А нам нужно выбрать только одно.
В таком случае для разрешения конфликта хабы начинают сравнивать хэши. Победителем станет сообщение, у которого выше хэш, то есть его номер или лексиграфический порядок больше. Такое решение является произвольным, но детерминированным.

В социальной сети тысячи-тысячи сообщений и когда они перемещаются между хабами, могут случаться всевозможные ошибки. Farcaster хотят разработать систему, устойчивую к этим ошибкам. Которая сможет решать конфликты, независимо от того кто, как, в каком порядке отправил сообщения.

Типы дельт, которые пользователи могут создавать.

Casts - сообщения (посты).
Reactions - реакции на различные элементы. Представляют отношения между человеком и объектом
Amps - одобрение одного пользователя другим. Простыми словами, повышаем пользователя до людей, которые на нас подписаны или следят.
Verifications - верификация, доказательство права собственности.
User Data - данные о пользователе, такие как: аватарка, статус и всё прочее, что создаёт ваш профиль.
Signers - с его помощью подписываются ваши сообщения.

Удаление сообщений
Вводим специальный тип сообщения, называемое сообщением об удалении. Оно не содержит само сообщение, а содержит ссылку на хэш сообщения для удаления. У него также есть свой собственный хэш и временная метка.
Хаб, видя запрос об удалении, отбрасывает исходное сообщение.

Model for hubs

Модель хабов

Алиса и Боб отправляют сообщения -> эти сообщения отправляются в их хабы
-> хабы обмениваются сообщениями друг с другом.
И со временем каждый хаб становится копией всех сообщений от Алисы и всех сообщений от Боба.

Но кто же управляет хабами?
Первая группа людей стимулирующая работу с хабами - FooCaster - люди создающие приложения в сети. Захотят запустить свой собственный хаб, чтобы быть уверенным, что всегда есть доступ для публикаций данных и для чтения.

Но не все начинают так серьезно, некоторые люди хотят поиграть с сетью. Поэтому они запускают CastAPI, а уже API запускает свой хаб, но к нему могут подключаться другие приложения и тоже получать данные.

Проблема, о которой ещё не говорили - что произойдёт, если Алиса будет отправлять много-много сообщений в сеть?

Сейчас побочным эффектом является то, что хабы должны становиться всё больше, чтобы хранить их все. Поэтому они становятся более дорогими в эксплуатации. В какой-то момент содержать собственный хаб станет нецелесообразно. Тогда разработчики начнут изпользовать CastAPI. Отчего сеть начнет становиться менее и менее децентрализованной.

А если Боб стал отправлять много сообщений, которые не несут важной информации, а являются спамом. Тогда CastApi создаст инструмент, который будет фильтровать сообщения вне сети. Это приведет к тому, что операторы сети смогут выбирать кого пропустить, а кого нет, и этим можно начать злоупотреблять. И мы вернемся в мир социальных сетей, где несколько влиятельных игроков, определяют что происходит!

Поэтому ясно одно: важно, чтобы существовали ограничения, насколько большим хаб может стать. Если они останутся меньше определенного размера, то будут достаточно рентабельны и каждый разработчик приложений сможет запустить собственный хаб. А иначе они станут слишком дорогими и маловероятно, что сеть останется децентрализованной.

Нельзя позволить пользователям хранить бесконечное количество информации.
Cпособ ограничить это - концепция сокращения дельты. Farcaster говорит, что пользователи могут делать публикации, но сообщения старше года будут удаляться из сети. Теперь они могут храниться в других архивных системах.
К тому же существуют ограничения по размеру, но они очень велики.

Такое отсечение данных помогает поддерживать сеть надёжной и децентрализованной

Если статья оказался для вас полезной, подписывайся)

twitter https://twitter.com/cryptoF09357302
mirror https://mirror.xyz/lisiiichka.eth
my wallet lisiiichka.eth / 0x1b3Dc17B63E83C9Ca3F414CFC24DCe7ACd889DA9