Farcaster Overview. Часть 2

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

Если вы не читали первую часть, советую ознакомиться сначала с ней - клик

Delta Graphs

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

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

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

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

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

Delta Graphs
Delta Graphs

Merging Deltas

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

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

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

Duplicate messages
Duplicate messages

Конфликты

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

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

Conflicts
Conflicts

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

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

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

Delta Types

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

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

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

Pruning Deltas

Model for hubs
Model for hubs

Модель хабов

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

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

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

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

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

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

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

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

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

Статья написана по материалам YouTube: ссылка - клик

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

lisiiichka.eth
Subscribe to Lisichka
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.