<p>Введение. Социальные сети стали неотъемлемой частью жизни современного человека. Для многих пользователей соцсети стали привычным способом коммуникации и социализации, а для некоторых – даже способом основного заработка [1]. Однако, несмотря на постоянное развитие уже привычных централизованных социальных сетей, существующие решения не лишены недостатков: случаются массовые утечки персональных данных пользователей, централизованные социальные сети подвержены цензуре и кибератакам. Чтобы устранить типичные недостатки централизованных соцсетей, предлагается использование набирающих популярность децентрализованных технологий: блокчейна и межпланетной файловой системы [2] (IPFS). Подобные технологии позволяют создать надежную, защищенную децентрализованную систему, доступ к которой возможен с различных платформ. Благодаря децентрализации возможно значительно сократить влияние кибератак на работоспособность системы, предоставить больший контроль пользователей над собственными персональными данными и построить более безопасную систему, не подверженную цензуре и ограничениям со стороны третьих лиц, по сравнению с централизованными аналогами. Также децентрализация системы подразумевает возможность масштабирования и развертывания собственных узлов системы, тем самым распределяя нагрузку при росте количества пользователей и объема данных в системе.</p>

Предложенные в статье технические решения позволяют обеспечить более высокую производительность по сравнению с конкурентными решениями благодаря использованию языка программирования Golang, а также обеспечить более быструю загрузку контента, защищенность и децентрализацию данных благодаря использованию IPFS и Ethereum. Также нами сформированы требования к разрабатываемой децентрализованной социальной сети и составлено техническое задание на проектирование и разработку приложения, а также была выбрана адаптированная модель жизненного цикла Agile, позволяющая вести гибкую разработку с учетом изменения требований к приложению.

Спроектирована эффективная архитектура социальной сети, позволяющая уменьшить связность компонентов приложения и повышающая отказоустойчивость всей системы: разработанная архитектура учитывает возможности и ограничения блокчейна Ethereum и определяет использование сети IPFS для хранения данных в системе и повышения эффективности работы всей системы. Благодаря использованию смарт-контракта Ethereum и сети IPFS, система предоставляет возможность децентрализованного доступа пользователя к системе с любого подходящего клиента, а с помощью провайдера Metamask – удобство взаимодействия с системой.

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

Исследовательский раздел.

<p>Анализ существующих конкурентных решений среди социальных сетей. На рынке уже присутствуют некоторые конкурентные решения в области децентрализованных социальных сетей. Рассмотрим самые популярные и развитые социальные сети среди них.</p>

Mastodon [3], Misskey [4] и diaspora [5] – децентрализованные социальные сети, которые были созданы в ответ на проблемы, связанные с централизованными социальными сетями, такими как Twitter и Facebook. Diaspora* использует собственный протокол diaspora*¹ federation protocol [6] для взаимодействия с другими социальными сетями, такими как Friendica и Hubzilla, тогда как Mastodon и Misskey используют протокол ActivityPub [7] для обмена данными между различными серверами. Рассмотрим каждую из них более подробно.

Mastodon – децентрализованная социальная сеть, предоставляющая функции микроблогинга для обмена короткими сообщениями, известными как «гудки» («toots»). Mastodon работает на принципе распределенной сети, где серверы, называемые «узлами», управляются их администраторами и могут взаимодействовать друг с другом. Примечательно то, что любой пользователь может создать свой узел и администрировать его на свое усмотрение. Пользователи могут создавать аккаунты на любом узле и общаться с другими пользователями, независимо от того, на каком узле они зарегистрированы. Каждый узел устанавливает свои собственные правила, касающиеся поведения пользователей, и может быть настроен под конкретные потребности сообщества.

Основной функционал Mastodon включает в себя: Таймлайн – пользователи могут видеть сообщения от других пользователей, на которых они подписаны; локальный таймлайн – пользователи могут просматривать сообщения от пользователей, зарегистрированных на том же узле, что и они; Хэштеги – пользователи могут использовать хэштеги для объединения сообщений по теме; подписки – пользователи могут подписываться на других пользователей, чтобы видеть их сообщения в своем таймлайне. Mastodon также поддерживает различные форматы контента, включая текстовые сообщения, изображения и видео; она также интегрируется с другими децентрализованными социальными сетями – такими, как Diaspora и Friendica, что позволяет поддерживать общение с пользователями этих сетей.

Misskey – это децентрализованная социальная сеть с открытым исходным кодом, которая разработана на языке программирования Node.js и использует базу данных MongoDB [8]. Аналогично Mastodon, Misskey является платформой для микроблоггинга и одной из замен Twitter в Fediverse [9]. В целом, имеет схожий с Mastodon основной функционал. Одной из ключевых особенностей Misskey является то, что она поддерживает децентрализованную модель данных, что означает, что каждый участник сети может хранить свои данные на своем собственном устройстве. Это повышает уровень безопасности и приватности пользователей, так как они могут контролировать свои данные и решать, кому предоставлять доступ к ним. Функционал поддерживает обмен текстом, изображениями, видео и аудио, а также отображать предупреждения о контенте и проводить опросы. Можно также использовать хэштеги и находить сообщения на их основе, но подписаться на хэштег нельзя. Нельзя редактировать свои сообщения, но можно их удалить и опубликовать заново. Misskey также предлагает ряд дополнительных функций, которые делают ее уникальной среди других децентрализованных социальных сетей. Например, она поддерживает функцию автоматического перевода текстов на другие языки, что может быть полезно для пользователей, которые общаются на разных языках.

Diaspora* – это социальная сеть, которая позволяет пользователям создавать свои собственные серверы и подключаться к другим серверам. Она имеет функциональность, аналогичную Facebook, включая профили пользователей, группы и возможность обмена сообщениями.

Diaspora* также позволяет пользователям создавать закрытые группы и общаться внутри них. Эта сеть разработана с учетом приватности и безопасности пользователей, а также с целью предоставления им контроля над своими данными. Она отличается от Mastodon и Misskey более широкими возможностями управления приватностью, и более широкой интеграцией с другими социальными сетями:

– в отличие от Mastodon и Misskey, которые ориентированы на собственную экосистему, Diaspora* предоставляет возможность подключаться к другим социальным сетям и сервисам – таким как Facebook и Twitter;

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

Все три социальные сети имеют свои преимущества и недостатки.

Mastodon имеет большое количество пользователей и сообществ, но может быть сложно найти интересных людей для подписки.

Misskey имеет более удобный интерфейс и меньше ограничений на размер сообщений, но ее пользовательская база меньше, чем у Mastodon.

Diaspora* имеет более простой интерфейс и более удобную систему поиска пользователей и сообществ, но ее пользовательская база также меньше, чем у Mastodon.

Однако, хоть вышеперечисленные социальные сети и распределены, они не полностью избавились от централизации – подключение к социальной сети осуществляется через какой-нибудь узел, который может быть недоступен. Узлы, в свою очередь, полностью контролируются администраторами, что может нарушать приватность пользователей, зарегистрированных на них. И наконец, загрузка медиаконтента реализована все так же через CDN [10] или через запрос к узлу, на котором есть эти данные. Проанализируем способы устранения этих недостатков для повышения доступности и скорости загрузки контента.

<strong>Анализ способов повышения скорости загрузки контента</strong><strong>. </strong>Есть несколько способов, которые могут помочь повысить скорость загрузки контента для пользователей в социальных сетях:

<ol> <li>оптимизация изображений и видео: изображения и видео можно оптимизировать, чтобы уменьшить их размер и ускорить время загрузки. Например, можно использовать форматы изображений с меньшим размером, сокращать продолжительность видео, уменьшать разрешение и т. д.;</li></ol>

<ol> <li>использование CDN: Content Delivery Network (CDN) – это сеть серверов, расположенных в разных частях мира, которые могут быстро доставлять контент пользователям в их регионах. Использование CDN может существенно ускорить загрузку контента для пользователей;</li></ol>

<ol> <li>кэширование: кэширование – это процесс сохранения данных на сервере или на устройстве пользователя, чтобы ускорить доступ к этим данным в будущем. Кэширование может существенно ускорить загрузку контента для пользователей;</li></ol>

<ol> <li>поддержка HTTP/2 [10]: HTTP/2 – это протокол передачи данных, который предоставляет более быстрый и эффективный способ передачи данных в Интернете. Поддержка HTTP/2 может помочь ускорить загрузку контента для пользователей;</li></ol>

<ol> <li>использование прогрессивной загрузки: прогрессивная загрузка – это технология, которая позволяет загружать контент по частям. Например, сначала загружается небольшое изображение низкого разрешения, а затем более крупное изображение высокого разрешения. Это позволяет пользователю быстро увидеть контент, даже если он не полностью загружен.</li></ol>

С учетом недостатков аналогов, разрабатываемое решение должно быть максимально независимым от серверов и доступным для пользователей. Таким образом, нежелательно использовать CDN, а также оптимизировать изображение и видео, допуская потерю качества. Использование HTTP/2 также нецелесообразно, поскольку протокол еще не широко распространен и может не поддерживаться браузером пользователя. Целесообразным решением в таком случае является использование межпланетной файловой системы (IPFS) – протокола и распределенной системы хранения и обмена файлами, которая использует уникальный идентификатор содержимого в качестве адреса для доступа к файлам.

IPFS основывается на технологиях блокчейна и P2P-сетей и позволяет создавать децентрализованные приложения с высокой степенью безопасности и доступности. Она также может использоваться для обмена контентом в сети без централизованного контроля, что делает ее полезным инструментом для создания децентрализованных социальных сетей и других приложений.

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

<strong>Выбор средств разработки приложения</strong><strong>. </strong>Выбор средств разработки для децентрализованной социальной сети является важным этапом проекта. Для достижения поставленных целей необходимо выбрать оптимальный набор инструментов, который обеспечит эффективную работу над проектом и сократит время его разработки. Исходя из анализа конкурентных решений и возможностей оптимизации разрабатываемого решения по сравнению с аналогами, основополагающим компонентом разрабатываемой социальной сети является IPFS как протокол для распределенного хранения и обмена файлами. Для регистрации и авторизации пользователей и защиты их персональных данных мы будем также использовать блокчейн-платформу Ethereum [12], которая является одной из самых популярных платформ, активно развивается и предоставляет использование смарт-контрактов для разработки децентрализованных приложений. С учетом недостатка блокчейна Ethereum по ограничению размера записываемого объема данных платформа плохо оптимизирована для хранения больших файлов. Но благодаря использованию IPFS, файлы можно хранить в децентрализованной файловой системе, а в блокчейн записывать хэш и метаинформацию о сохраненном файле. Таким образом, можно получить эффективную работу этих технологий в паре.

<strong>Выбор средств разработки клиентской части</strong><strong>. </strong>Для разработки клиентской части децентрализованной социальной сети можно выбрать один из нескольких популярных фреймворков: React [13], Angular [14] или Vue [15].

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

Angular также является популярным фреймворком для разработки клиентской части, который обладает многими возможностями «из коробки», такими как поддержка маршрутизации, форм и валидации. Но его использование может быть связано с трудностями внедрения и более сложным процессом обучения.

Vue – относительно новый фреймворк, который также обладает многими возможностями, но при этом имеет более простую структуру и легче внедряется в проект. Vue также имеет удобную документацию, что упрощает процесс изучения фреймворка.

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

<strong>Выбор средств разработки серверной части</strong><strong>. </strong>IPFS реализована на языке программирования Go (Golang), и разработчики предоставляют пакет go-ipfs-api [16] для взаимодействия с узлом IPFS. Кроме того, Go можно использовать для написания смарт-контрактов на платформе Ethereum с помощью библиотеки go-ethereum [17], которая является официальной реализацией Ethereum на Go. Эта библиотека предоставляет множество функций для работы с Ethereum – таких, как создание и отправка транзакций, чтение и запись данных в блокчейн и многое другое. Кроме того, Go имеет высокую скорость выполнения и эффективность, что может быть важным при работе с блокчейн-технологиями, которые зачастую имеют высокие требования к производительности. Таким образом, Go является самым подходящим языком программирования для разработки заявленной социальной сети. Рассмотрим несколько популярных фреймворков для Go.

<ol> <li>Fiber [18] – это быстрый и эффективный веб-фреймворк, который основан на fasthttp. Он имеет простой и понятный интерфейс API, который удобен для разработчиков. Fiber поддерживает многопоточность и встроенную поддержку WebSocket, а также предоставляет инструменты для обработки запросов и ответов, маршрутизации, сжатия, кэширования и многое другое. Fiber имеет дружественную документацию и активную поддержку сообщества.</li></ol>

<ol> <li>Gin [19] – это еще один быстрый и эффективный веб-фреймворк, который также основан на fasthttp. Он имеет более широкий набор функций, чем Fiber, включая встроенную поддержку мидлваров, простую маршрутизацию и шаблонизацию. Gin также имеет поддержку многопоточности, WebSocket и поддержку RESTful API. Gin также имеет дружественную документацию и активное сообщество, которое предоставляет множество плагинов и дополнений.</li></ol>

<ol> <li>Echo [20] – это еще один быстрый и легкий веб-фреймворк для языка Go. Он имеет простой и понятный интерфейс API, который позволяет быстро создавать веб-приложения. Echo также поддерживает встроенные механизмы маршрутизации, мидлвары, сжатие и кэширование. Однако он не имеет встроенной поддержки WebSocket и многопоточности.</li></ol>

Для разработки серверной части решено использовать фреймворк Fiber для Go, который является легковесным и быстрым фреймворком для разработки веб-приложений. Он достаточно популярен, имеет понятную документацию на нескольких языках и, по сравнению с другими рассмотренными фреймворками, активно развивается в последние годы.

<h3><strong>Проектный раздел</strong><strong>.</strong></h3>

<strong>Выбор адаптированной модели жизненного цикла разработки приложения</strong><strong>. </strong>Адаптированные модели жизненного цикла [21] – это способы описания этапов разработки программного обеспечения с учетом особенностей конкретного проекта. Наиболее распространенными моделями являются Waterfall, Agile, Spiral и V-образная. Waterfall – линейная модель, где каждый этап проходится последовательно, и к предыдущему не возвращаются. Это подход, который обычно используется для крупных проектов с ясно определенными требованиями и четкими сроками. Agile – гибкая модель, которая позволяет разработчикам быстро реагировать на изменения требований.

Она подходит для более гибких проектов, где требования могут меняться на протяжении всего процесса разработки. Spiral – итерационная модель, где процесс разработки проходит через несколько циклов. Каждый цикл представляет собой фазу планирования, разработки и тестирования. Эта модель подходит для проектов с высоким уровнем риска или неопределенности. V-образная модель сочетает преимущества Waterfall и Spiral, предполагая более подробную разработку требований и тестирования в начале процесса разработки, а затем включая итеративные циклы для дальнейшей разработки и тестирования.

Учитывая специфику разработки многоплатформенной децентрализованной социальной сети с использованием IPFS, наиболее подходящей моделью жизненного цикла может быть Agile. Это позволит быстро реагировать на изменения требований и учитывать возможности технологий, которые еще находятся в разработке.

<strong>Разработка архитектуры приложения</strong><strong>. </strong>Архитектура разрабатываемой социальной сети будет состоять из следующих компонентов:

<ol> <li>клиентская часть (Frontend) – пользовательский интерфейс, который будет предоставлять функциональность пользователям социальной сети. Может быть реализована как браузерное веб-приложение или мобильный клиент;</li></ol>

<ol> <li>серверная часть (Backend) – сервер, который будет предоставлять API для клиентской части. Необходим для взаимодействия пользователя с конкретным узлом IPFS для сохранения и получения контента;</li></ol>

<ol> <li>IPFS (InterPlanetary File System) – распределенная файловая система, которая будет использоваться для хранения контента пользователей. IPFS предоставляет децентрализованный и устойчивый способ хранения файлов, используя хеширование контента. Контент будет храниться на IPFS-узлах, а не на централизованном сервере.</li></ol>

<ol> <li>Ethereum – платформа для смарт-контрактов, которая будет использоваться для регистрации и управления данными пользователей. Ethereum предоставляет распределенную базу данных, которая позволяет создавать и исполнять смарт-контракты. Данные пользователей будут храниться в смарт-контрактах Ethereum, которые будут доступны для чтения и записи из любого узла сети.</li></ol>

Разработанная функциональная схема на основе перечисленных компонентов представлена на рис. 1.

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

<strong>Разработка архитектуры клиентской части приложения</strong><strong>. </strong>Для обеспечения децентрализации разрабатываемой системы было решено использовать смарт-контракты блокчейна Ethereum: с помощью смарт-контракта можно реализовать регистрацию и аутентификацию пользователя в социальной сети, а также хранить информацию о пользователе в блокчейне и список опубликованных им постов. Однако, такой подход имеет свои ограничения: любое изменение блокчейна, например обновление информации о пользователе или регистрация нового пользователя, требует создания новой транзакции, подписанной пользовательским приватным ключом от криптокошелька.

Для того чтобы изменения, содержащиеся в транзакции, были применены, необходимо, чтобы транзакция была отправлена в сеть блокчейна и обработана майнером, что влечет за собой оплату пользователем комиссии за работу майнера. Из-за того, что приватный ключ пользователя нельзя публиковать в сети Интернет и можно хранить лишь в зашифрованном хранилище на физическом устройстве, все транзакции по изменению информации в блокчейне будут осуществляться с клиентской части приложения, а серверная часть будет обращаться к функционалу смарт-контракта только для чтения информации, сохраненной в блокчейне. Для ускорения разработки и удобства использования системы пользователем будет использоваться провайдер Metamask [22].

Metamask – это популярный кошелек для Ethereum и расширение для браузера, которое позволяет пользователям взаимодействовать с децентрализованными приложениями Ethereum непосредственно из веб-браузера. Провайдер Metamask обеспечивает удобный и безопасный способ для клиентской части децентрализованного приложения получать доступ к кошельку пользователя и инициировать транзакции от его имени, не требуя от приложения непосредственного доступа к приватным ключам пользователя. Для работы с Metamask пользователю необходимо использовать любой браузер с поддержкой расширения Metamask на компьютере или мобильном устройстве.

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

Для оптимизации работы системы и уменьшения размера комиссии за выполнение транзакции в блокчейне в него записывается лишь CID файла, сохраненного в IPFS с помощью API серверной части приложения.

<strong>Разработка архитектуры серверной части приложения</strong><strong>.</strong> Для разработки прототипа серверной части приложения архитектуру серверной части можно разбить на следующие модули: модуль маршрутизации и обработки запросов отвечает за принятие запросов от клиента, маршрутизацию их к соответствующим обработчикам, а также за обработку запросов и отправку ответов клиенту; модуль обработки Ethereum-транзакций отвечает за взаимодействие с блокчейн-сетью Ethereum: запрашивает информацию из смарт-контрактов и обрабатывает полученные результаты; модуль обработки IPFS-запросов обеспечивает взаимодействие с IPFS-сетью, загрузку и хранение файлов в децентрализованной файловой системе; модуль уведомлений отвечает за отправку пользователям уведомлений о различных событиях в приложении – таких, как новые сообщения, комментарии, лайки и другие. Схема архитектуры серверной части социальной сети представлена на рис. 3.

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

<strong>Проектирование схемы базы данных</strong><strong>. </strong>Для обеспечения децентрализации данных, хранящихся в системе, нецелесообразно использование привычных реляционных и нереляционных СУБД для таких централизованных клиент-серверных систем, как PostgreSQL [23] или MongoDB. С учетом уже используемых технологий IPFS и смарт-контрактов блокчейна Ethereum, возможно организовать хранение данных в разрабатываемой системе: на узлах IPFS будут храниться данные, используемые системой, например изображения в байтовом представлении или информация о постах и их содержимом в формате JSON [24], а в блокчейне Ethereum будут храниться указатели, CID [25], на необходимое содержимое, записанное в IPFS – например список CID-постов, опубликованных пользователем. Для записи данных в сеть IPFS используются модели данных, описанные в виде структур языка Golang, которые конвертируются в формат JSON перед записью. Рассмотрим поля используемых моделей для хранения данных в системе.

Модель «Post»: CID записи в сети IPFS. Заголовок поста. Содержимое поста (модель «PostContent»). ID автора поста. Время создания поста.

Модель «PostContent»: Текстовое содержимое поста. Изображения, прикрепленные к посту (модель «Image»). Видео, прикрепленные к посту (модель «Video»). Файлы, прикрепленные к посту (модель «File»).

Модели «Image», «Video» и «File» состоят из двух полей: СID и объекта метаданных содержимого, записанного в IPFS.

Для хранения информации о пользователе используется модель «User» с полями адреса пользователя в сети блокчейна и дополнительной информацией профиля пользователя.

<strong>Технологи</strong><strong>ческий</strong><strong> раз</strong><strong>дел</strong><strong>.</strong>

<strong>Разработка интерфейса приложения</strong><strong>. </strong>Для функционирования рассматриваемой социальной сети разработан смарт-контракт Ethereum [26] на языке Solidity [27] и размещен в сети блокчейна. В разработанном контракте реализован функционал регистрации и аутентификации пользователя, получение и изменение информации пользователя, добавление и получение постов пользователя, установка нового пароля пользователя.

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

Функции на чтение информации из блокчейна, например authenticate и getUserInfo, не изменяют информации в блокчейне и будут использоваться на серверной части приложения для аутентификации пользователя и получения необходимой информации о пользователе и его постах из блокчейна.

После создания и развертывания контракта в сети блокчейна разработчик может взаимодействовать с контрактом и использовать его функционал. Взаимодействие с контрактом осуществляется с помощью ABI и вызова функций блокчейна через JSON RPC [28]. Форма регистрации пользователя представлена на рис. 4.

В поле Account отображен адрес подключенного кошелька пользователя, полученного от провайдера Metamask. Для аутентификации и авторизации пользователя в системе пользователь должен ввести пароль в форму аутентификации, после чего клиентская часть инициирует запрос на аутентификацию к серверной части и, в случае успешной аутентификации, получает JWT-токен [29] для просмотра страницы с постами других пользователей. Форма аутентификации представлена на рис. 5.

После успешной аутентификации пользователь переходит на страницу с постами других пользователей. Клиент получает список постов из ответа на запрос получения всех постов от серверной части приложения при загрузке страницы. Страница со списком постов представлена на рис. 6.

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

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

<strong>Разработка бизнес-логики приложения</strong><strong>. </strong>Серверная часть децентрализованной социальной сети разработана в соответствии с техническим заданием и обеспечивает децентрализацию и масштабируемость компонентов системы. Смарт-контракт, размещенный в блокчейне Ethereum, позволяет осуществлять регистрацию нового пользователя или идентификацию и аутентификацию уже зарегистрированного пользователя, а также хранить идентификаторы на опубликованные посты и описание профиля пользователя в хранилище IPFS. Для осуществления транзакций и изменения данных в блокчейне пользователь использует криптокошелек и пару ключей: приватный и публичный. Приватный ключ пользователя хранится только на физическом устройстве пользователя и не отправляется ни в один компонент системы через сеть Интернет. Пользователь должен использовать приватный ключ для подписи транзакций с помощью специального провайдера, например Metamask, и не должен где-либо публиковать приватный ключ или набор ключевых слов для доступа к кошельку через провайдера в сети Интернет.

Для аутентификации пользователя на сервере пароль пользователя предварительно шифруется алгоритмом SHA256, что исключает для злоумышленников возможность расшифровать пароль и повышает безопасность аккаунта пользователя. Для повышения безопасности системы также возможна реализация двухфакторной аутентификации: сервер генерирует случайное сообщение; отправляет на клиентское приложение пользователя, где пользователь подписывает сообщение с помощью своего приватного ключа и отправляет обратно серверу; сервер расшифровывает сообщение публичным ключом пользователя и проверяет принятое сообщение на соответствие сгенерированному.

Для доступа к постам, опубликованным в социальной сети, реализована авторизация пользователя по JWT-токену: после успешной аутентификации пользователь получает персональный токен, который используется в заголовках запроса для просмотра опубликованных постов или создания нового поста. Масштабируемость системы обеспечивается возможностью пользователя развернуть собственный сервер приложения и указать в переменных окружения любой адрес узла IPFS или размещенного в сети Ethereum смарт-контракта. Благодаря принципам работы IPFS, значительно сокращается возможность утраты данных в системе за счет хранения блоков данных на нескольких узлах сети, а благодаря сети блокчейна обеспечивается безопасность и подлинность транзакций пользователей.

Рассмотрим более детально функционал взаимодействия серверной части приложения с развернутым смарт-контрактом Ethereum и узлом IPFS.

Взаимодействие с развернутым смарт-контрактом Ethereum в сети блокчейн на серверной части осуществляется с помощью установленного пакета geth. Этот пакет предоставляет API для взаимодействия с сетью блокчейна на языке Go и позволяет автоматически сгенерировать необходимые функции на языке Go для работы с контрактом на основе ABI разработанного смарт-контракта [30]. В случае успешной аутентификации пользователя сервер генерирует JWT-токен с помощью алгоритма HS256 и возвращает клиенту для последующих запросов на защищенные эндпоинты.

Взаимодействие между сервером и узлом IPFS обеспечивается посредством библиотеки go-ipfs-api с помощью вызова процедур через специальный API узла. Для подключения и вызова команд нужно создать специальный объект, «Shell», указав в аргументах адрес узла IPFS, к которому нужно подключиться.

<strong>Тестирование приложения</strong>. В рамках MVP клиентская часть лишь отправляет HTTP запросы для взаимодействия с сервером через REST API и использует расширение Metamask для взаимодействия со смарт-контрактом Ethereum, поэтому в данном случае целесообразно ограничиться ручным тестированием клиентской части. Тестирование API серверной части и взаимодействие сервера с узлом IPFS и смарт-контрактом Ethereum, напротив, заслуживает большего внимания для проверки работоспособности и надежности ключевых узлов системы. Тестирование создания нового поста на клиентской части представлено на рис. 7 и 8.

Для тестирования серверной части используется стандартная библиотека «testing» языка Go и формат для написания тестов фреймворка Fiber. Для тестирования функционала по взаимодействию с IPFS и со смарт-контрактом Ethereum были использованы тестовый узел IPFS и счет в тестовой сети Sepolia блокчейна Ethereum. Рассмотрим тестирование методов контроллера для управления пользователями «Login» и «Register» для аутентификации и регистрации соответственно. Внутри тестовых функций описаны тест-кейсы для аутентификации и регистрации: «Успешная аутентификация пользователя»; «Неудачная аутентификация пользователя»; «Регистрация нового пользователя»; «Попытка регистрации существующего пользователя».

При тестировании регистрации пользователя тестовый пользователь удаляется в конце теста. Результаты тестирования представлены на рис. 9.

Рассмотрим и оценим технические характеристики серверной и клиентских частей. Серверная часть написана на Golang на фреймворке Fiber и использует протокол HTTP для взаимодействия с узлом IPFS и узлом блокчейна Ethereum. Работа приложения потребляет в среднем 20 Мб ОЗУ и обеспечивает время отклика 10-20 миллисекунд (рис. 10).

Развернутый локальный узел IPFS потребляет в среднем 250 Мб ОЗУ. Для взаимодействия со смарт-контрактом используется платформа Infura, которая предоставляет возможность работы с выделенным узлом блокчейна Ethereum, следовательно, физические ресурсы машины не используются. Клиентская часть написана на Vue и потребляет в среднем 35 Мб ОЗУ. На рис. 11 показано время выполнения запросов к серверной части при аутентификации, получении всех постов в социальной сети и создании нового поста пользователя.

Полученный результат потребления ОЗУ компонентами системы и время выполнения операций внутри системы оценены как удовлетворительные.

<strong>Расчет вычислительной и емкостной сложности</strong><strong>. </strong>Для определения ресурсозатратных алгоритмов разработанной системы необходимо рассчитать их временную и емкостную сложность в худшем случае. При расчёте рассматриваются основные функции компонентов системы. Объем входных данных, с которыми работают алгоритмы, принимается за <em>n</em>. Расчёты вычислительной и ёмкостных сложностей основных функций для компонентов системы осуществляются в следующей последовательности: <table class="docx-publication-table"><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>T</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mn>1</mn></mrow></mfenced><mo>,</mo></math> </td><td class="docx-publication-cell"> (1)</td></tr><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>V</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mi>n</mi></mrow></mfenced><mo>,</mo></math> </td><td class="docx-publication-cell"> (2)</td></tr></table> где <em>T</em> – вычислительная сложность; <em>GetUsers</em> – функция получения списка пользователей; <em>O</em> – трудоёмкость алгоритма; <em>V</em> – ёмкостная сложность; <em>n</em> – размер входных данных.<table class="docx-publication-table"><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>T</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>I</mi><mi>n</mi><mi>f</mi><mi>o</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mi>n</mi></mrow></mfenced></math> ,</td><td class="docx-publication-cell"> (3)</td></tr><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>V</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>I</mi><mi>n</mi><mi>f</mi><mi>o</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mi>n</mi></mrow></mfenced><mo>,</mo></math> </td><td class="docx-publication-cell"> (4)</td></tr></table> где <em>T</em> – вычислительная сложность; <em>GetUsersInfo</em> – функция получения информации о профилях списка пользователей; <em>O</em> – трудоёмкость алгоритма; <em>n</em> – размер входных данных; <em>V</em> – ёмкостная сложность.<table class="docx-publication-table"><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>T</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>P</mi><mi>o</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mn>1</mn></mrow></mfenced></math> ,</td><td class="docx-publication-cell"> (5)</td></tr><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>V</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>P</mi><mi>o</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mi>n</mi></mrow></mfenced><mo>,</mo></math> </td><td class="docx-publication-cell"> (6)</td></tr></table> где <em>T</em> – вычислительная сложность; <em>GetUser</em><em>Posts</em> – функция получения постов пользователя; <em>O</em> – трудоёмкость алгоритма; <em>V</em> – ёмкостная сложность; <em>n</em> – размер входных данных.<table class="docx-publication-table"><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>T</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>P</mi><mi>o</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mi>n</mi><mi> </mi><mo>×</mo><mi> </mi><mi>T</mi><mo>(</mo><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>P</mi><mi>o</mi><mi>s</mi><mi>t</mi><mi>s</mi><mo>)</mo></mrow></mfenced><mo>=</mo><mi>O</mi><mo>(</mo><msup><mrow><mi>n</mi></mrow><mrow><mn>2</mn></mrow></msup><mo>)</mo></math> ,</td><td class="docx-publication-cell"> (7)</td></tr><tr><td class="docx-publication-cell"> <?xml version="1.0" encoding="UTF-16"?> <math xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math"><mi>V</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>s</mi><mi>P</mi><mi>o</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mi>V</mi><mfenced separators="|"><mrow><mi>G</mi><mi>e</mi><mi>t</mi><mi>U</mi><mi>s</mi><mi>e</mi><mi>r</mi><mi>P</mi><mi>o</mi><mi>s</mi><mi>t</mi><mi>s</mi></mrow></mfenced><mo>=</mo><mi>O</mi><mfenced separators="|"><mrow><mi>n</mi></mrow></mfenced><mo>,</mo></math> </td><td class="docx-publication-cell"> (8)</td></tr></table> где <em>T</em> – вычислительная сложность; <em>GetUsers</em><em>Posts</em> – функция получения информации постов по списку пользователей; <em>O</em> – трудоёмкость алгоритма; <em>n</em> – размер входных данных; <em>V</em> – ёмкостная сложность.

Результаты расчета сложности алгоритмов затем сводятся в таблицу.

<em>Таблица </em> <strong>Сложность основных функций компонентов системы</strong><table class="docx-publication-table"><tr><td class="docx-publication-cell"> Функция</td><td class="docx-publication-cell"> Описание</td><td class="docx-publication-cell"> <em>T</em></td><td class="docx-publication-cell"> <em>V</em></td></tr><tr><td class="docx-publication-cell"> <em>GetUsers</em></td><td class="docx-publication-cell"> Функция получения списка пользователей</td><td class="docx-publication-cell"> <em>O</em>(1)</td><td class="docx-publication-cell"> <em>O(</em><em>n</em><em>)</em></td></tr><tr><td class="docx-publication-cell"> <em>GetUsersInfo</em></td><td class="docx-publication-cell"> Функция получения информации о профилях списка пользователей</td><td class="docx-publication-cell"> <em>O(n)</em></td><td class="docx-publication-cell"> <em>O(n)</em></td></tr><tr><td class="docx-publication-cell"> <em>GetUserPosts</em></td><td class="docx-publication-cell"> Функция получения постов пользователя</td><td class="docx-publication-cell"> O(1)</td><td class="docx-publication-cell"> <em>O(n)</em></td></tr><tr><td class="docx-publication-cell"> <em>GetUsersPosts</em></td><td class="docx-publication-cell"> Функция получения постов по списку пользователей</td><td class="docx-publication-cell"> <em>O(n</em>²)</td><td class="docx-publication-cell"> <em>O(n)</em></td></tr></table> <em>Источник:</em> разработано авторами.

Результаты расчетов показали, что наиболее ресурсозатратной функцией серверной части является <em>GetUsersPosts</em>, используемая алгоритмом получения списком постов по списку пользователей. Для клиентской части функции оптимизированы для активного использования хранилища приложения и в наихудшем случае (отсутствие данных в хранилище) показывают линейную сложность. Объем обрабатываемых данных является небольшим, в связи с чем обеспечивается скорость выполнения описанных выше запросов (функций).

<strong>Заключение. </strong>В результате исследований проведена разработка многоплатформенной децентрализованной социальной сети с использованием межпланетной файловой системы. Проведен анализ конкурентных решений для выявления их недостатков и формирования требований к разработанной социальной сети. В результате анализа приведены подходящие технологии и средства разработки для обеспечения децентрализации системы и повышения скорости загрузки хранящегося в ней контента. Делается обоснованный вывод, что использование межпланетной файловой системы и блокчейна снизит централизацию компонентов системы и окажет положительное влияние на скорость загрузки данных, хранящихся в социальной сети, на стороне клиента пользователя. Использование технологий блокчейна и IPFS в связке с алгоритмами шифрования и авторизацией пользователя по JWT-токену обеспечивает необходимую безопасность пользовательских данных при эксплуатации разработанной децентрализованной социальной сети. Применение смарт-контрактов Ethereum и узлов сети IPFS с возможностью развертывания и использования собственных состояний при конфигурации компонентов системы обеспечивают масштабирование и больший контроль пользователя над своими персональными данными в системе. За счет этого достигается стабильность работы при увеличении числа пользователей без снижения скорости загрузки данных, хранящихся в системе.

Важно отметить, что в процессе разработки был реализован следующий функционал: регистрация и авторизация пользователя, публикация нового поста и отображение всех постов социальной сети. Для ограничения доступа к защищенным ресурсам системы использовано взаимодействие клиента и сервера с помощью JWT-токена. В результате тестирования проверена работоспособность разработанного функционала компонентов социальной сети. В ходе оценки технических характеристик разработки было выявлено потребление объема ОЗУ серверной частью социальной сети в среднем 270 Мб (вместе с локальным узлом IPFS) и клиентской частью – в среднем 35 Мб. Таким образом, в результате разработки получено решение, обеспечивающее эффективное взаимодействие с узлом IPFS и смарт-контрактом Ethereum. Разработанное решение обеспечивает более высокую скорость доставки контента, хранящегося в IPFS, и более низкую централизованность данных по сравнению с конкурентными решениями. В результате расчета вычислительной и емкостной сложностей алгоритмов определено, что наиболее ресурсоемким алгоритмом является получение опубликованных постов по списку пользователей.

<strong>Экономическая целесообразность</strong> разработки многоплатформенной децентрализованной социальной сети с использованием межпланетной файловой системы заключается в том, что данный программный продукт позволит сократить время загрузки и отображения информации в социальной сети, значительно повысить безопасность пользовательских данных и обеспечить больший контроль пользователя над их распространением и отображением. При использовании разрабатываемого веб-приложения снижается риск утечки персональных данных пользователей по сравнению с конкурентными централизованными решениями. Также возможно размещение решения в сети Интернет в соответствии с политикой открытого исходного кода для уменьшения возможных уязвимостей и расширения функционала разрабатываемого продукта с помощью мирового сообщества. Выбор программных и организационно-технологических проектных решений обеспечил минимизацию финансовых, материальных и трудовых затрат. Разработка является экономически целесообразной.