# Farcaster Overview. Часть 2 By [Lisichka](https://paragraph.com/@lisiiichka) · 2023-01-18 --- Farcaster - это открытый протокол, позволяющий создавать социальные приложения. Если вы не читали первую часть, советую ознакомиться сначала с [ней - клик](https://mirror.xyz/lisiiichka.eth/Fp6Sck1NxNNJT3pZZovjROB7OKSPMa2YhEw3tzcMCjM) **Delta Graphs** Как хранятся сообщения и как именно они передаются между хабами?(Hubs - концептуально это как ноды в блокчейне, но алгоритм конценсуса отличается. Больше про hubs [тут - клик](https://github.com/farcasterxyz/protocol#4-hubs)) Farcaster представляет новую концепцию - **дельта-граф**! Дельта - это любые действия пользователя в социальной сети (like, unlike, share (Farcaster называют это - recast), reply).Самое интересное происходит, когда люди создают дельты, конфликтующие друг с другом. Например, Боб лайкнул сообщение Алисы, а потом убрал лайк. Эти данные хранятся в хабе и когда разработчик их увидит, возникнет проблема. Два конфликтующих сообщения не могут быть одновременно истинны. Нужен способ решить конфилкт и прийти к консенсусу относительно того, что является текущим состоянием сети. Набор дельт должен быть объединен с использованием набора правил для создания действительного социального графа.Граф - простая структура данных, с вершинами, которые являются контентом и пользователями (то есть Алиса, Боб, сообщение Алисы "hello world", ответ Боба "welcome" - это всё вершины графа). Когда пользователь создает сообщение, образуется новая вершина, а затем создается ребро (relationship), указывающее родителя этого сообщения. Ребра также указывают на взаимодействия, которые произошли (like, unlike, recast). Основное правило - пользователь и часть контента могут иметь только одно отношение определнного типа. Одновременно не может быть, например, like и unlike. Отношения могут заключаться либо в том, что подобное истинно, либо в том, что ложно. Хабы выполняют слияние (merge): берут набор дельт, анализируют и создают действительный социальный граф. А когда обнаруживается конфликт, то определяется только один "победитель" ![Delta Graphs](https://storage.googleapis.com/papyrus_images/84b3deefd551ef2b2267ac4bfb5c0587550c76da5428955d918ac33e4b92da10.png) Delta Graphs **Merging Deltas** Предположим, что Алиса создала сообщение "hello world", а Бобу оно понравилось. Для каждого сообщения определяется _cid_ - идентификатор конфликта, который определяет уникальный объект в изменяемом графе. И определяется состояние - _s_. Вместе они образуют дельта-сообщение. _Повторяющиеся сообщения_ Если Боб отправит два сообщения с одинаковым содержанием, то система не сможет увеличить количество лайков два раза. Это неправильно. Поэтому ввели уникальный идентификатор - хэш. Сообщения хэшируются. И так как второе сообщение имеет такое же содержимое, то и хэш не будет отличаться. Поэтому хаб сразу определит, что данное сообщение им уже обрабатывалось, и состояние не изменится. ![Duplicate messages](https://storage.googleapis.com/papyrus_images/8f65f97321d2c1d2b3a28e883dd872350e7c04b5c5062bf2bd4a1c6344234653.png) Duplicate messages _Конфликты_ Что происходит, когда сообщения конфликтуют из-за изменения состояние s? В данном случае уже не получится ссылаться на хэш. Из-за разного содержимого сообщений хэш будет отличаться. Для решения проблемы ввели метку времени - t. Теперь известно какое сообщение было отправленно раньше, какое позже. И истинным считают более позднее сообщение. ![Conflicts](https://storage.googleapis.com/papyrus_images/6bfa59530d7e5bdddb4f559a2d05f38dd64c6f845d7f23cf14e46a2aa2d64491.png) Conflicts _Определение победителя_ НО время может быть ненадёжно и быть одинаковым на двух конфликтующих сообщениях.Тогда мы получим два сообщения с разными хэшами, но одним временем. А нам нужно выбрать только одно.В таком случае для разрешения конфликта хабы начинают сравнивать хэши. Победителем станет сообщение, у которого выше хэш, то есть его номер или лексиграфический порядок больше. Такое решение является произвольным, но детерминированным. В социальной сети тысячи-тысячи сообщений и когда они перемещаются между хабами, могут случаться всевозможные ошибки. Farcaster хотят разработать систему, устойчивую к этим ошибкам. Которая сможет решать конфликты, независимо от того кто, как, в каком порядке отправил сообщения. **Delta Types** Типы дельт, которые пользователи могут создавать. Casts - сообщения (посты). Reactions - реакции на различные элементы. Представляют отношения между человеком и объектом Amps - одобрение одного пользователя другим. Простыми словами, повышаем пользователя до людей, которые на нас подписаны или следят. Verifications - верификация, доказательство права собственности. User Data - данные о пользователе, такие как: аватарка, статус и всё прочее, что создаёт ваш профиль. Signers - с его помощью подписываются ваши сообщения. _Удаление сообщений_ Вводим специальный тип сообщения, называемое сообщением об удалении. Оно не содержит само сообщение, а содержит ссылку на хэш сообщения для удаления. У него также есть свой собственный хэш и временная метка. Хаб, видя запрос об удалении, отбрасывает исходное сообщение. ![](https://storage.googleapis.com/papyrus_images/6b566ae6d5878daaf9f211e2a428d67b03227de8401eea224f6f1b9638ee1f9b.png) **Pruning Deltas** ![Model for hubs](https://storage.googleapis.com/papyrus_images/59921c93f4ac772db6565ba347558cd75c9a361f2223b914b39e7013f20ef73c.png) Model for hubs _Модель хабов_ Алиса и Боб отправляют сообщения -> эти сообщения отправляются в их хабы -> хабы обмениваются сообщениями друг с другом.И со временем каждый хаб становится копией всех сообщений от Алисы и всех сообщений от Боба. Но кто же управляет хабами?Первая группа людей стимулирующая работу с хабами - FooCaster - люди создающие приложения в сети. Захотят запустить свой собственный хаб, чтобы быть уверенным, что всегда есть доступ для публикаций данных и для чтения. Но не все начинают так серьезно, некоторые люди хотят поиграть с сетью. Поэтому они запускают CastAPI, а уже API запускает свой хаб, но к нему могут подключаться другие приложения и тоже получать данные. ![](https://storage.googleapis.com/papyrus_images/a4aef9f3de930502499a1773332097b77894dc181c96067a6fe9e4fb35a2eb2d.png) Проблема, о которой ещё не говорили - что произойдёт, если Алиса будет отправлять много-много сообщений в сеть? Сейчас побочным эффектом является то, что хабы должны становиться всё больше, чтобы хранить их все. Поэтому они становятся более дорогими в эксплуатации. В какой-то момент содержать собственный хаб станет нецелесообразно. Тогда разработчики начнут изпользовать CastAPI. Отчего сеть начнет становиться менее и менее децентрализованной. А если Боб стал отправлять много сообщений, которые не несут важной информации, а являются спамом. Тогда CastApi создаст инструмент, который будет фильтровать сообщения вне сети. Это приведет к тому, что операторы сети смогут выбирать кого пропустить, а кого нет, и этим можно начать злоупотреблять. И мы вернемся в мир социальных сетей, где несколько влиятельных игроков, определяют что происходит! Поэтому ясно одно: важно, чтобы существовали ограничения, насколько большим хаб может стать. Если они останутся меньше определенного размера, то будут достаточно рентабельны и каждый разработчик приложений сможет запустить собственный хаб. А иначе они станут слишком дорогими и маловероятно, что сеть останется децентрализованной. Нельзя позволить пользователям хранить бесконечное количество информации. Cпособ ограничить это - концепция сокращения дельты. Farcaster говорит, что пользователи могут делать публикации, но сообщения старше года будут удаляться из сети. Теперь они могут храниться в других архивных системах. К тому же существуют ограничения по размеру, но они очень велики. Такое отсечение данных помогает поддерживать сеть надёжной и децентрализованной Статья написана по материалам YouTube: [ссылка - клик](https://www.youtube.com/playlist?list=PL0eq1PLf6eUdm35v_840EGLXkVJDhxhcF) Если статья оказался для вас полезной, подписывайся) lisiiichka.eth [https://paragraph.xyz/@lisiiichka.eth](https://paragraph.xyz/@lisiiichka.eth) [https://twitter.com/cryptoF09357302](https://twitter.com/cryptoF09357302) --- *Originally published on [Lisichka](https://paragraph.com/@lisiiichka/farcaster-overview-2)*