# Farcaster Overview. Часть 2

**Published by:** [Lisichka](https://paragraph.com/@lisiiichka/)
**Published on:** 2023-01-18
**URL:** https://paragraph.com/@lisiiichka/farcaster-overview-2

## Content

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

## Publication Information

- [Lisichka](https://paragraph.com/@lisiiichka/): Publication homepage
- [All Posts](https://paragraph.com/@lisiiichka/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@lisiiichka): Subscribe to updates