Farcaster - это открытый протокол, позволяющий создавать социальные приложения.
Если вы не читали первую часть, советую ознакомиться сначала с ней - клик
Delta Graphs
Как хранятся сообщения и как именно они передаются между хабами?(Hubs - концептуально это как ноды в блокчейне, но алгоритм конценсуса отличается. Больше про hubs тут - клик)
Farcaster представляет новую концепцию - дельта-граф!
Дельта - это любые действия пользователя в социальной сети (like, unlike, share (Farcaster называют это - recast), reply).Самое интересное происходит, когда люди создают дельты, конфликтующие друг с другом. Например, Боб лайкнул сообщение Алисы, а потом убрал лайк. Эти данные хранятся в хабе и когда разработчик их увидит, возникнет проблема. Два конфликтующих сообщения не могут быть одновременно истинны. Нужен способ решить конфилкт и прийти к консенсусу относительно того, что является текущим состоянием сети.
Набор дельт должен быть объединен с использованием набора правил для создания действительного социального графа.Граф - простая структура данных, с вершинами, которые являются контентом и пользователями (то есть Алиса, Боб, сообщение Алисы "hello world", ответ Боба "welcome" - это всё вершины графа).
Когда пользователь создает сообщение, образуется новая вершина, а затем создается ребро (relationship), указывающее родителя этого сообщения. Ребра также указывают на взаимодействия, которые произошли (like, unlike, recast).
Основное правило - пользователь и часть контента могут иметь только одно отношение определнного типа. Одновременно не может быть, например, like и unlike. Отношения могут заключаться либо в том, что подобное истинно, либо в том, что ложно.
Хабы выполняют слияние (merge): берут набор дельт, анализируют и создают действительный социальный граф. А когда обнаруживается конфликт, то определяется только один "победитель"
Merging Deltas
Предположим, что Алиса создала сообщение "hello world", а Бобу оно понравилось. Для каждого сообщения определяется cid - идентификатор конфликта, который определяет уникальный объект в изменяемом графе. И определяется состояние - s. Вместе они образуют дельта-сообщение.
Повторяющиеся сообщения
Если Боб отправит два сообщения с одинаковым содержанием, то система не сможет увеличить количество лайков два раза. Это неправильно. Поэтому ввели уникальный идентификатор - хэш. Сообщения хэшируются. И так как второе сообщение имеет такое же содержимое, то и хэш не будет отличаться. Поэтому хаб сразу определит, что данное сообщение им уже обрабатывалось, и состояние не изменится.
Конфликты
Что происходит, когда сообщения конфликтуют из-за изменения состояние s?
В данном случае уже не получится ссылаться на хэш. Из-за разного содержимого сообщений хэш будет отличаться.
Для решения проблемы ввели метку времени - t. Теперь известно какое сообщение было отправленно раньше, какое позже. И истинным считают более позднее сообщение.
Определение победителя
НО время может быть ненадёжно и быть одинаковым на двух конфликтующих сообщениях.Тогда мы получим два сообщения с разными хэшами, но одним временем. А нам нужно выбрать только одно.В таком случае для разрешения конфликта хабы начинают сравнивать хэши. Победителем станет сообщение, у которого выше хэш, то есть его номер или лексиграфический порядок больше. Такое решение является произвольным, но детерминированным.
В социальной сети тысячи-тысячи сообщений и когда они перемещаются между хабами, могут случаться всевозможные ошибки. Farcaster хотят разработать систему, устойчивую к этим ошибкам. Которая сможет решать конфликты, независимо от того кто, как, в каком порядке отправил сообщения.
Delta Types
Типы дельт, которые пользователи могут создавать.
Casts - сообщения (посты).
Reactions - реакции на различные элементы. Представляют отношения между человеком и объектом
Amps - одобрение одного пользователя другим. Простыми словами, повышаем пользователя до людей, которые на нас подписаны или следят.
Verifications - верификация, доказательство права собственности.
User Data - данные о пользователе, такие как: аватарка, статус и всё прочее, что создаёт ваш профиль.
Signers - с его помощью подписываются ваши сообщения.
Удаление сообщений
Вводим специальный тип сообщения, называемое сообщением об удалении. Оно не содержит само сообщение, а содержит ссылку на хэш сообщения для удаления. У него также есть свой собственный хэш и временная метка.
Хаб, видя запрос об удалении, отбрасывает исходное сообщение.
Pruning Deltas
Модель хабов
Алиса и Боб отправляют сообщения -> эти сообщения отправляются в их хабы -> хабы обмениваются сообщениями друг с другом.И со временем каждый хаб становится копией всех сообщений от Алисы и всех сообщений от Боба.
Но кто же управляет хабами?Первая группа людей стимулирующая работу с хабами - FooCaster - люди создающие приложения в сети. Захотят запустить свой собственный хаб, чтобы быть уверенным, что всегда есть доступ для публикаций данных и для чтения.
Но не все начинают так серьезно, некоторые люди хотят поиграть с сетью. Поэтому они запускают CastAPI, а уже API запускает свой хаб, но к нему могут подключаться другие приложения и тоже получать данные.
Проблема, о которой ещё не говорили - что произойдёт, если Алиса будет отправлять много-много сообщений в сеть?
Сейчас побочным эффектом является то, что хабы должны становиться всё больше, чтобы хранить их все. Поэтому они становятся более дорогими в эксплуатации. В какой-то момент содержать собственный хаб станет нецелесообразно. Тогда разработчики начнут изпользовать CastAPI. Отчего сеть начнет становиться менее и менее децентрализованной.
А если Боб стал отправлять много сообщений, которые не несут важной информации, а являются спамом. Тогда CastApi создаст инструмент, который будет фильтровать сообщения вне сети. Это приведет к тому, что операторы сети смогут выбирать кого пропустить, а кого нет, и этим можно начать злоупотреблять. И мы вернемся в мир социальных сетей, где несколько влиятельных игроков, определяют что происходит!
Поэтому ясно одно: важно, чтобы существовали ограничения, насколько большим хаб может стать. Если они останутся меньше определенного размера, то будут достаточно рентабельны и каждый разработчик приложений сможет запустить собственный хаб. А иначе они станут слишком дорогими и маловероятно, что сеть останется децентрализованной.
Нельзя позволить пользователям хранить бесконечное количество информации.
Cпособ ограничить это - концепция сокращения дельты. Farcaster говорит, что пользователи могут делать публикации, но сообщения старше года будут удаляться из сети. Теперь они могут храниться в других архивных системах.
К тому же существуют ограничения по размеру, но они очень велики.
Такое отсечение данных помогает поддерживать сеть надёжной и децентрализованной
Статья написана по материалам YouTube: ссылка - клик
Если статья оказался для вас полезной, подписывайся)
lisiiichka.eth