Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

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

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

Со временем архитектура эволюционировала в сторону полноценной VPN-сети на базе WireGuard, а точнее — его модификации AmneziaWG. Причин для этого шага было несколько:

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

В итоге получилась схема, при которой все сервисы доступны по красивым доменным именам с HTTPS, но абсолютно невидимы для внешнего интернета.

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

Технический стек

Блокчейн-инженер

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

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

Unity-разработчик

Unity-разработчики пишут код, который превращает концепцию виртуального мира в рабочее приложение. Они используют язык C# и движок Unity для создания интерактивных пространств — от игр до корпоративных тренажёров и обучающих платформ.

Специалист работает с VR/AR/XR-технологиями, настраивает физику объектов, анимацию персонажей и взаимодействие пользователей с окружением. Он интегрирует блокчейн для работы с NFT, тестирует производительность и оптимизирует приложения под разные устройства. Unity-разработчик создаёт техническую основу, на которой держится весь пользовательский опыт.

Специалист по кибербезопасности

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

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

Креативные роли

Графический дизайнер

Визуальная составляющая метавселенных влияет на то, как пользователи воспринимают виртуальное пространство и хотят ли они в нём оставаться. Дизайн здесь — часть интерактивного опыта, который формирует первое впечатление и заставляет пользователя остаться.

Графический дизайнер создаёт аватары, интерфейсы, объекты и окружение. Он работает над визуальным стилем метавселенной, подбирает цветовые схемы, разрабатывает текстуры и модели.

UX/UI-дизайнер миров

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

UX/UI-дизайнер миров проектирует удобную навигацию и интерфейсы для 3D-пространств. Он продумывает, как пользователь будет открывать криптокошелёк, просматривать NFT, общаться с другими аватарами или покупать виртуальные товары.

Создатель цифровых активов

Виртуальная экономика держится на цифровых активах — одежде для аватаров, предметах интерьера, аксессуарах, транспорте. Эти объекты пользователи покупают, продают, коллекционируют и используют для самовыражения.

Создатель цифровых активов разрабатывает 3D-модели виртуальных товаров. Он делает одежду и аксессуары для аватаров, предметы для виртуальных домов, уникальные NFT-коллекции. Специалист работает с 3D-редакторами: Blender или Maya, учитывает технические ограничения платформ и настраивает совместимость активов с блокчейном для подтверждения прав собственности.

Геймдизайнер VR-игр

Игры задают стандарты интерактивности в метавселенных. Многие виртуальные миры изначально создавались как игровые пространства и только потом обрастали социальными и экономическими функциями.

Геймдизайнер VR-игр проектирует игровой процесс для виртуальной реальности. Он придумывает механики, создаёт уровни, пишет сценарии, настраивает баланс сложности. Специалист работает с движками Unreal Engine или Unity, использует инструменты для 3D-моделирования и анимации, программирует взаимодействие объектов. Его задача — сделать так, чтобы пользователь был вовлечён и хотел возвращаться.

Управленцы и стратеги

Проджект-менеджер

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

Маркетолог метавселенных

Традиционная реклама в метавселенных не работает. Здесь бренды не покупают баннеры, а создают интерактивный опыт — виртуальные магазины, концерты, игровые события, NFT-коллекции.

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

Менеджер по безопасности

Он добавляет и обновляет политики конфиденциальности, контролирует соблюдение стандартов безопасности, анализирует риски и координирует работу технических специалистов.

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

Какие навыки нужны для работы в метавселенных

Конкретный список зависит от роли, но есть базовые, которые нужны всем:

• Программирование. C# и C++ для разработки на Unity и Unreal Engine. Python нужен для автоматизации, аналитики и работы с машинным обучением. JavaScript и Solidity для создания смарт-контрактов и веб-интеграций.
• 3D-моделирование и анимация. Blender, Maya, Cinema 4D — основные инструменты, чтобы создавать новый мир.
• Блокчейн и криптовалюты. Нужно понимать, как работают децентрализованные системы, NFT и смарт-контракты. Уметь настраивать транзакции, управлять цифровыми активами и сохранять их безопасность.
• Кибербезопасность. Защита данных, активов и устройств VR/AR от взлома и мошенничества.
• UX/UI для 3D-пространств. Вы решаете как пользователь взаимодействует с объектами в VR и как сделать этот процесс удобным.
• Облачные технологии. Виртуальному миру нужна мощная инфраструктура для обработки данных и поддержки тысяч одновременных пользователей.
• ИИ и машинное обучение. Искусственный интеллект для генерации аватаров, создания чат-ботов, персонализации контента и анализа поведения пользователей.
• XR/AR/VR-технологии. Нужно понимать специфику устройств, их ограничения и возможности для погружающего опыта.
• Unity и Unreal Engine. Два основных движка для разработки интерактивных миров. Unity чаще для мобильных VR-приложений и кроссплатформенных проектов, Unreal Engine — для высокобюджетных игр и визуализаций.

Из мягких навыков — креативность, умение работать в команде и быстро адаптироваться к новым технологиям. Метавселенные развиваются быстро, и специалисты должны постоянно учиться.

Если вы хотите освоить конкретные навыки для работы в метавселенных, есть программы, которые дают практическую базу. Например, в Академии ТОП можно пройти курсы по кибербезопасности и сетевым технологиям, разработке на Python, созданию игр на Unity, UX/UI-дизайну или работе с нейросетями. Это варианты для тех, кому нужно структурированное обучение с проектами и обратной связью.

Где искать работу в метавселенных

1. Образовательные платформы Coursera, Labster создают иммерсивные системы обучения. Студенты проводят виртуальные эксперименты, тренируются на симуляторах и ходят на лекции в VR.
2. Крупные игроки — Microsoft, NVIDIA и многие стартапы запускают офисы в метавселенных, проводят встречи в VR и обучают сотрудников на виртуальных тренажёрах.
3. Здравоохранение, аэрокосмическая отрасль, машиностроение. XR-технологии используются для подготовки персонала. Хирурги тренируются на виртуальных пациентах, инженеры изучают сложные механизмы в дополненной реальности.
4. Виртуальные музеи, концерты, выставки и тематические парки переносятся в цифровое пространство. Художники создают NFT-коллекции, музыканты делают концерты для аватаров.
5. Модные бренды представляют виртуальную одежду для аватаров, проводят цифровые показы и открывают шоурумы в метавселенных. NFT-мода становится отдельным рынком.
6. Банки экспериментируют с виртуальными офисами, страховые компании используют VR для обучения клиентов. Криптовалюты и NFT интегрируются в финансовые сервисы.
7. Виртуальная земля и объекты продаются, арендуются и используются для бизнеса. Агентства открывают офисы в метавселенных и проводят виртуальные туры по объектам.

Рынок растёт, технологии развиваются, и спрос на специалистов в метавселенных будет только увеличиваться. Сейчас об этом не говорят много и громко, потому что тренд укрепился и перешёл из стадии хайпа в рабочую фазу.

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

Его главная мысль: LLM не умеют думать — они лишь угадывают, какие слова должны идти дальше.

Несмотря на обилие впечатляющих демо и заявлений от крупных компаний, экс-хакер уверен: LLM — это не начало новой эры ИИ, а пузырь, раздутый маркетингом и страхом остаться позади.

LLM != мышление

По мнению автора, ключевая ошибка многих в том, что они путают внешнее поведение с внутренним пониманием.

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

Он приводит простой пример: LLM легко решает классическую задачу про козу, волка и капусту — но лишь потому, что она есть в обучающем датасете. Стоит заменить одно из слов, и модель начинает «сбоить». Это, по его мнению, доказывает отсутствие настоящего понимания.

Иллюзия прогресса и подмена понятий

По словам аналитика, индустрия строит «песочные замки», надеясь, что AGI (общий искусственный интеллект) вот-вот появится. Но за громкими словами стоят:

• краткосрочная жадность инвесторов;
• хайп, питающий венчурный капитал;
• и технологическая мода, где у каждого продукта должна быть «ИИ-функция».

Он сравнивает происходящее с NFT, VR, блокчейном и другими волнами переоцененной технологической надежды.

Большинство из них закончились ничем или медленно сошли на нет. LLM, считает он, ждет та же судьба — если не случится принципиально нового научного прорыва.

Последствия: переоценка и деградация

Исследователь также предупреждает об опасных последствиях чрезмерной зависимости от LLM:

• Когнитивный упадок. Люди перестают развивать навыки, доверяя все подсказкам моделей.
• Информационный коллапс. Модели «каннибализируют» интернет — копируют контент, ухудшают его качество, что в итоге подрывает источники, на которых сами и обучаются.
• Псевдопродуктивность. Пользователи чувствуют, будто стали эффективнее, но реальные метрики производительности говорят об обратном.

Что дальше?

По мнению автора, будущее LLM — не в замене людей, а в интеграции в существующие процессы: помощь специалистам, ускорение отдельных задач, улучшение UX.

Он призывает не становиться «инженером промтов», а развивать глубокую экспертизу, чтобы использовать LLM как инструмент, а не как костыль.

Аналитики отмечают, что подобные ситуации стали типичными для ИИ-индустрии последних лет, при этом проверить реальные технологии за маркетинговыми обещаниями становится все сложнее. Практика показывает, что значительная часть стартапов, позиционирующая себя как «ИИ-компании», не имеет собственных разработок в области искусственного интеллекта. При этом объем инвестиций в сектор уже превысил $320 миллиардов.

Почему инвесторы продолжают вкладываться в «технологический воздух»? Как отличить реальные разработки от искусно сконструированных фейков? Подробные ответы на эти и другие вопросы — в нашем расследовании.

Золотая лихорадка: как ИИ-стартапы стали новыми доткомами

Эксперты сравнивают текущую ситуацию на рынке ИИ-стартапов с пузырем доткомов конца 1990-х. За последние три года количество компаний, использующих в описании термин «искусственный интеллект», выросло в несколько раз. При этом далеко не все из них действительно разрабатывают собственные алгоритмы машинного обучения.

Яркий пример — история стартапа 11x, который в 2024 году привлек значительные инвестиции под проект ИИ для автоматизации продаж. Как выяснило издание TechCrunch, компания заявляла о сотрудничестве с крупными клиентами вроде ZoomInfo и Airtable, но эти организации публично опровергли какие-либо отношения с 11x.

Внутренние источники описали культуру завышенных метрик и других проблем с продуктом: ИИ-боты часто выдавали некорректную информацию (попросту галлюцинировали), а многие пробные периоды заканчивались досрочно из-за технических сбоев. Этот случай показывает, как хайп вокруг ИИ может скрывать фундаментальные недостатки технологий.

Почему же бизнес продолжает инвестировать в подобные проекты? Психологи объясняют эту ситуацию эффектом FOMO (Fear of Missing Out) — страхом упустить выгоду. Когда все вокруг инвестируют в ИИ, а СМИ наперебой пишут о преимуществах новых технологий, трудно остаться в стороне. Многие фонды предпочитают вложиться в десять сомнительных стартапов, чем пропустить один потенциально успешный проект. В случае удачи затраты многократно окупятся, но каковы шансы на успех?

Кухня фейковых ИИ-стартапов: как создают иллюзию «передовых» технологий

Современные технологические мошенники освоили целый арсенал приемов, позволяющий превратить набор готовых API в «инновационный продукт». Их методы стали настолько отточенными, что даже опытные инвесторы иногда не могут отличить реальную разработку от искусно сконструированной фальшивки. Заглянем за кулисы этого театра технологических чудес и рассмотрим наиболее распространенные схемы мошенничества.

Словарь мошенника: от AGI до нейроинтерфейсов

В мире ИИ-стартапов 2025 года сложился полноценный язык обмана — набор терминов и формулировок, которые превращают обычные технологии в «революционные прорывы». Эксперты выделяют несколько особенно популярных уловок.

AGI — священный грааль мошенников

Заявления о создании Общего Искусственного Интеллекта (AGI) — самый яркий красный флаг. В 2025 компания OpenAI опубликовала отчет, где четко указала: современные ИИ-системы остаются узкоспециализированными инструментами. AGI — гипотетический тип сильного ИИ, до создания которого еще далеко на текущем уровне развития технологий.

Тем не менее, стартапы привлекают многомиллионные инвестиции, обещая «первый коммерческий AGI», но их демо может оказаться тщательно срежиссированным диалогом с оператором.

Мультимодальность как прикрытие

Этот термин часто используют для описания простой интеграции нескольких API. Стартапы заявляют о «прорывной эмоциональной аналитике», но система просто передает данные в Google Vision API и Azure Face Recognition. Основатели отказываются предоставить доступ к коду, ссылаясь на «коммерческую тайну».

Нейроинтерфейсы без нейронов

После успеха Neuralink Илона Маска десятки стартапов нацелились на «прорыв в управлении устройствами силой мысли». Эксперты предупреждают, что многие такие решения часто регистрируют ложные срабатывания (артефакты движения вместо реальных нейросигналов) и имеют крайне низкую точность распознавания намерений.

Они даже могут выдавать случайные сигналы даже при тестировании на неодушевленных объектах.

Другие наиболее «злоупотребляемые» термины в 2025 году:

• «Blockchain-powered AI» — ряд проектов с такой технологией не имеет реального блокчейна.
• «Self-learning algorithm» — обычно означает простую настройку параметров.
• «Military-grade encryption» — маркетинговый штамп без спецификаций.
• «Quantum AI» — ни одного реального квантового вычисления.
• «Ethical AI» — часто отсутствует даже базовый compliance-документ.

Как распознать обман?

Когда слышите громкие заявления, требуйте:

• сравнения с существующими open-source решениями;
• результаты независимого бенчмаркинга;
• хотя бы один реальный кейс вне маркетинговых материалов.

Особенно тревожный сигнал — отказ от технических деталей под предлогом «секретности». Часто за такой отговоркой скрываются либо готовые API, либо полностью ручные процессы.

Реальный пример: Стартап DoNotPay, позиционировавший себя как «первого в мире ИИ-юриста», столкнулся с серьезными вопросами о своей технологии.

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

Этот случай демонстрирует распространенную практику, когда стартапы преувеличивают возможности своих технологий, маскируют простые алгоритмы под сложный ИИ и откровенно используют хайп вокруг нейросетей для привлечения инвестиций. При этом DoNotPay — реально существующий стартап, чья история хорошо документирована в авторитетных СМИ.

Искусство фейковых демонстраций

Современные технологии позволяют создавать убедительные, но фальшивые демонстрации возможностей ИИ. Рассмотрим основные методы, которые используют мошенники:

• «Человек за занавесом». Самый распространенный прием — когда за якобы автоматизированным процессом скрывается ручной труд. Вспоминаем тот самый случай с индийскими программистами.
• Предварительно записанные «интерактивные» демо. Многие компании показывают заранее подготовленные сценарии как живое взаимодействие. Например, в 2024 году выяснилось, что демонстрации «уникального» чат-бота от стартапа ChatX на 90% состояли из предварительно записанных ответов, хотя подавались как работа ИИ в реальном времени.
• Генерация идеальных условий. Для демо-роликов специально подбирают простейшие тестовые случаи. Сервисы показывают «безупречную» работу своего ИИ для генерации кода, но в реальных условиях точность системы на порядки ниже.
• Гибридные демонстрации. Новый тренд — комбинация ИИ и ручной доработки. Алгоритм делает черновой вариант, который затем правит человек, но в презентациях это подается как полностью автоматизированный процесс.
• Deepfake-презентации. Некоторые компании идут еще дальше, создавая полностью сгенерированных цифровых спикеров с реалистичной мимикой и голосом, которые рассказывают о несуществующих возможностях продукта.

Как распознать обман:

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

Эти простые методы помогут отличить реальные технологии от созданных иллюзий.

Ноу-код революция: как собирают ИИ-стартапы за выходные

Современные платформы для разработки без программирования открыли новую эру в создании псевдо-ИИ-стартапов. Сервисы типа Bubble и Retool позволяют за считанные дни собрать внешне убедительный продукт, используя готовые API популярных нейросетей. Согласно исследованиям, около половины новых проектов в сфере ИИ используют шаблонные решения на основе ChatGPT API и других доступных технологий.

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

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

Срываем покровы: что скрывается за громкими заявлениями

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

Mechanical Turk 2.0: цифровые рабы новой эры

Американский стартап Nate стал примером того, как компании выдают ручной труд за работу искусственного интеллекта. Компания привлекла $40 млн инвестиций, позиционируя себя как инновационный сервис для автоматизации онлайн-покупок с помощью ИИ.

Как работала схема обмана:

1. Вместо заявленных алгоритмов обработку заказов выполняли сотни работников на Филиппинах и в Румынии.
2. Уровень реальной автоматизации составлял «фактически ноль процентов», по данным Министерства юстиции США.
3. Компания использовала ботов лишь для имитации части транзакций.

Иными словами, подобно известной зарубежной краудсорсинговой платформе Mechanical Turk или аналогичным российским сервисам, фейковые стартапы используют людей для решения задач, которые дорого или невозможно выполнять с помощью компьютера. Участие в таких проектах становится новым «быстрым заработком в интернете», только на этот раз фрилансеры не разгадывают капчи, а участвуют в заведомо мошеннической схеме — играют роль ИИ за небольшое вознаграждение.

Мошенники из Nate реализовали проверенные методы маскировки:

• создали ложный нарратив об инновационных технологиях;
• использовали актуальность ИИ-тематики для привлечения инвестиций;
• подтверждали «работу алгоритмов» через поддельные метрики.

Генеральному директору Альберту Санигеру были предъявлены обвинения в мошенничестве с ценными бумагами с использованием электронных средств связи. Каждое из этих преступлений предусматривает до 20 лет лишения свободы.

Еще более громкий случай произошел с индийским стартапом BuilderAI, о котором мы писали ранее. Этот проект продержался 8 лет, прежде чем афера была раскрыта. Кто знает, какие еще тайны крупных и мелких ИИ-стартапов откроются нам в будущем?

Накрученные метрики и покупные отзывы

Проблема фальшивых показателей стала настоящей эпидемией в индустрии. Аналитики SimilarWeb обнаружили: большинство ИИ-стартапов имеют более 50% бот-трафика в своей статистике. Распространены три проверенных схемы обмана:

1. Накрутка DAU/MAU — использование ферм ботов для имитации активной аудитории.
2. Покупка отзывов — маркетплейс Clutch.co удалил 120 фальшивых рецензий о сервисе AIHelper.
3. Поддельные кейсы — публикация вымышленных историй успеха со стоковыми фото вместо реальных клиентов.

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

Почему пузырь еще не лопнул

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

Правовой вакуум и отсутствие регулирования

В России до сих пор не принят закон о регулировании искусственного интеллекта, хотя соответствующий проект существует с 2021 года. Это создает идеальные условия для мошенников. Только около четверти венчурных фондов проводят технический аудит ИИ-стартапов перед инвестированием.

Сложность проверки технологий усугубляется тем, что:

• нет стандартизированных методов оценки ИИ-решений;
• отсутствуют требования к публикации тестовых данных;
• не разработаны критерии для проверки уникальности алгоритмов.

В многих других странах ситуация с юридическим статусом ИИ тоже не определена.

Психология инвестирования в эпоху ИИ-хайпа

Инвесторы принимают решения на основе страха упустить возможность, а не объективных данных. Это особенно характерно для корпоративных инвесторов, новых фондов и государственных программ — гранты часто распределяются без должной проверки.

Яркий пример — история с инвестициями Microsoft в BuilderAI. Корпорация вложила $50 млн без глубокой технической экспертизы, полагаясь лишь на маркетинговые материалы.

В целом за последний год объем инвестиций в ИИ-стартапы вырос на 37%. Это свидетельствует о «гонке за единорогами» — инвесторы предпочитают делать крупные ставки на небольшое количество проектов, надеясь поймать следующий OpenAI. При этом реальная окупаемость таких вложений остается под вопросом.

Когда лопнет пузырь?

Аналитики и регуляторы по-разному оценивают сроки коррекции рынка ИИ-стартапов:

Ближайшие риски (2025-2026):

• В России эксперты прогнозируют волну банкротств среди технологических стартапов, особенно в условиях высокой ключевой ставки (21-25%) и снижения инвестиционной активности.
• Международные аналитики ожидают постепенное «сдувание» пузыря по мере ужесточения регулирования и проверки технологий.

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

Как не купить воздух и отличить настоящий ИИ-стартап от технологического фейка?

В условиях, когда мошеннические схемы становятся все более изощренными, инвесторам и партнерам нужны четкие критерии оценки. На основе анализа кейсов мы составили практическое руководство по проверке ИИ-стартапов.

Техническая экспертиза проекта

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

Важные технические аспекты для проверки:

• уникальность алгоритмов — запросите сравнение с open-source аналогами;
• качество данных — какие наборы используются для обучения;
• инфраструктура — собственные серверы или облачные решения.

Пример: успешный стартап DeepPavlov всегда публикует свои модели в открытом доступе, что подтверждает их технологическую состоятельность.

Проверка реальных кейсов и клиентов

Маркетинговые обещания легко проверить через демо-версию с возможностью ввода произвольных данных, отзывы реальных клиентов (не из маркетинговых материалов) и истории внедрения с конкретными цифрами эффективности.

Финансовая и юридическая прозрачность

Обязательные документы для проверки:

• бизнес-план с четкой монетизацией;
• отчеты о расходовании предыдущих инвестиций;
• финансовые модели на 3-5 лет.

Критически важно проверить патенты и авторские права, соответствие регуляторным требованиям, отсутствие судебных исков.

Практический совет: создайте чек-лист из 20-30 пунктов и привлекайте независимых экспертов для аудита каждого критерия. Как показывает практика, комплексная проверка на 80% снижает риски инвестирования в фейковые проекты.

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

Все ждали, что вот-вот начнётся киберпанк: наши аватары будут тусоваться в 3D, ходить по виртуальным улицам и работать в офисе на Марсе. Но метавселенная не случилась и вместо этого мы получили пустые миры, лаги и виртуальную морскую болезнь. Чтобы попасть в эту «новую реальность», нужен мощный комп, дорогущий VR-шлем и вестибулярка космонавта. Массовому пользователю это не по карману и не по душе. Даже если вы добрались до метавечеринки — вас ждала примитивная мультяшная графика.

Метавселенная — красивый технологический концепт, но без реального запроса со стороны людей. Одни видели в ней VR и AR, другие — NFT и блокчейн, третьи — некий 3D-интернет. И стало непонятно: что это вообще было и зачем?

Метавселенная обещала стать новым поколением соцсетей, что именно там будет жить наше будущее общение и работа. Весь хайп смыл новый тренд: волна генеративного ИИ. Meta* (признана в России экстремистской организацией и запрещена) и другие техногиганты свернули свои эксперименты и переключились на нейросети.

У бизнеса с метавселенными тоже не сложилось: ни чёткой модели монетизации, ни реальных кейсов. Продажа виртуальной недвижимости в Decentraland, мерч для аватаров, баннеры в виртуальных тусовках — всё больше напоминает Web3-версию The Sims, чем серьёзную платформу с реальной экономикой. Так что будущее в 3D отложили до лучших времён.

Игровые платформы вроде Minecraft, Roblox, Fortnite — это по сути и есть настоящие метавселенные, которые давно живут своей жизнью. Среднестатистический пользователь от виртуальных тусовок отказывается: ему проще зайти в Discord или залипнуть в обычный стрим на Twitch, чем надевать шлем ради планёрки в Horizon Worlds.

Я могу просто посмотреть стрим и получить лучший опыт. Надевать шлем не имеет смысла — никакой пользы

Громкие обещания про «полное погружение» и «эффект присутствия» на практике разбивались о суровую реальность — кривую техническую реализацию. Сейчас платформы выглядят заброшенными: пустые сцены, аватары без ног и скучные шаблонные взаимодействия. Ещё одна проблема — отсутствие единого мира. Все платформы живут по отдельности, между ними нет порталов и возможности перемещаться. К тому же, в виртуальности были серьёзные проблемы с безопасностью — например, случаи домогательств.

Есть надежда, что метавселенная вернётся — когда технологии и контекст будут готовы. Когда VR-шлемы станут лёгкими, дешевыми и удобными, появятся реальные сценарии, а не просто презентации для инвесторов. Тогда, может быть, мы ещё туда заглянем. А пока — rest in pixels, Metaverse.

NFT-мания

Пока одни тусовались в метавселенной и зарабатывали миллионы на продаже пикселей, другие гуглили, что такое OpenSea и почему JPEG стоит как однушка в Москве. Сейчас NFT называют либо финансовым пузырём, либо зачатками новой цифровой инфраструктуры.

Пандемия и локдаун дали интернету второе дыхание. Люди заскучали и начали скупать цифровое искусство, как раньше собирали марки, карточки или скины в играх. В 2021 году NFT стали мейнстримом: CryptoPunks, Bored Ape, Beeple — эти имена знали все. К цифровой лихорадке подключились бренды: Adidas, Nike и даже McDonald’s начали продавать цифровой мерч в метавселенных. Пиксельные обезьяны разлетались, как будто золото будущего: в январе 2022 NFT-маркетплейс OpenSea побил все рекорды, ведь месячный объём торгов составил около $5 млрд. Владение NFT стало признаком цифрового престижа. Люди устанавливали токены себе на аватарки в Twitter, потому что это был цифровой Rolex: если у тебя был токен — ты в теме. А если нет — шёл читать гайды на Tproger.

Но уже к лету того же года рынок начал сдуваться. В июне 2022 объем OpenSea упал до ~$700 млн, а в октябре 2023 он составлял лишь $91 млн. Минус 98% от пиковых значений. Что же пошло не так?

Большинство NFT не дают прав на владение цифровым активом. Вы покупаете не саму картинку, а ссылку на неё в блокчейне. Если сервер с изображением ляжет — останется только строчка кода, свидетельствующая о вашем хорошем вкусе. Многие NFT были просто картинками. Ни привязки к играм, ни доступа к сообществам, ни других функций — только красивая (или не очень) обёртка.

Зачем мне вообще покупать этот NFT вместо настоящего произведения искусства?

Тысячи NFT-проектов выходили каждый день, рынок быстро перенасытился, и в итоге NFT-платформы утонули в спаме и мошенничестве. Один из самых распространённых трюков — wash trading: пользователь продаёт токен сам себе, чтобы искусственно раздуть спрос. Исследования показывают, что по итогам 2022 года более половины объёма торгов NFT на Ethereum приходилось на липовые сделки. Кто-то считает, что NFT со временем обесценились. Но возможно, что они с самого начала были пустышками.

Ещё один удар по доверию — кражи и хаос с плагиатом. Работы художников массово превращали в NFT без их ведома: копировали, заливали и продавали, как своё. Никто не спрашивал разрешения у авторов, и уж точно не предлагал процент с продаж. NFT также критиковали за углеродный след и загрязнение окружающей среды.

NFT как спекулятивный пузырь — фактически умер. Большинство коллекций потеряли всякий торговый смысл: объёмы упали, активные игроки исчезли, а токены превратились в мёртвые цифровые артефакты. Лихорадочные инвестиции, основанные на спекуляциях, просто сдулись.

Но сама концепция уникального цифрового актива живёт дальше. Токен как технология адаптируется и трансформируется. В играх NFT уже показали себя как востребованный юзкейс: игроки могут владеть, торговать и прокачивать виртуальные предметы. Эксперты считают, что инфраструктура останется, и на её базе появятся проекты с реальной практической ценностью. А NFT превратится в элемент цифровой инфраструктуры — как инструмент доступа и сертификат владения. Цифровой «паспорт», который фиксирует принадлежность к сообществам, открывает возможности для участия в клубах и эксклюзивных событиях.

3D‑телевизоры: история провала объёмного кино у вас дома

В начале 2010-х 3D-ТВ казались мегатрендом после хита «Аватар». Однако к 2016 году большинство крупных производителей отказались от выпуска моделей с поддержкой 3D. Многие пользователи так и не получили качественный опыт из-за технических ограничений и ранней стадии развития.

Я знаю, почему 3D-телевизоры провалились: производители поспешили поймать волну кинотеатрального бумa, сделав технологию с тяжёлыми и требующими подзарядки очками. В то же время на горизонте появились большие плоские телевизоры без очков, которые выглядели гораздо лучше и удобнее для пользователей.

Что пошло не так? Во-первых, сами 3D-очки. Их нужно было заряжать, носить поверх своих, а сидеть при этом строго под определённым углом, иначе магия пропадала. Многие отмечают, что это было неудобно — очки были дорогими, тяжелыми, а некоторые зрители уставали уже на середине фильма: жаловались на напряжение в глазах, дискомфорт и головные боли. Технология, которая должна была удивлять, в итоге просто раздражала.

Контента почти не было, и пользователи, купив дорогой телевизор, сталкивались с вопросом: а что, собственно, смотреть? 3D-телевизоры были дороже своих 2D-аналогов, и с развитием 4K, HDR и OLED-технологий потребители начали отдавать предпочтение лучшему качеству изображения без 3D. Зачем платить за условную «глубину», если можно просто получить красивую живую картинку из коробки.

Несмотря на провал 3D-ТВ в их классическом виде, эксперты не ставят на них технологии крест. Как пишет WIRED, новый виток связан с автостереоскопическими дисплеями: они используют трекинг взгляда, линзы и AI, чтобы создавать объёмное изображение прямо на экране — без всяких аксессуаров.

Google Glass: будущее было на носу

Google Glass подавали как прорыв — интерфейс будущего прямо у вас перед глазами. Но вместо футуризма — странная дужка с экранчиком сбоку. Стоила как хороший ноутбук, делала как плохой смартфон. Пользователи получали уведомления на уровне браслета и фото из 2005 года. Памяти почти нет, батарея умирает быстрее, чем вы успеете сказать «Окей, Google».

Соучредитель Google Сергей Брин позже признал, что не понимал, как устроены поставки и насколько сложно произвести такие очки массово и недорого. И это многое объясняет: в Google Glass вложили идею, но не довели её до жизнеспособного устройства.

Хотя запуск обставили красиво: дали очки техноинфлюенсерам, звёздам, первопроходцам — маркетинг остался без главного: никакой конкретики, ни сроков, ни объяснения, зачем это всё нужно. Продукт обсуждали, хайп был — но в продаже его не было. Сама общественность встретила Glass с настороженностью: главной проблемой стала конфиденциальность. У очков не было явного индикатора съёмки, и люди не понимали, записывают их или нет.

Некоторые считают, что Google Glass просто опередили своё время. Прототип показали ещё в 2013 году на Google I/O, а уже к 2015-му производство свернули. На практике очки оказались недостаточно удобными, многие обозреватели говорили, что они нелепо выглядят, а способов их применения никто так и не придумал. При цене в $1500 очки превратились в атрибут избранных гиков, а не в массовый гаджет.

По оценкам аналитиков, всего было продано не более 250 тыс. таких устройств, причем на старте Google отдала лишь 10 000 очков ограниченному кругу «избранных». Попасть к покупателю было сложно — очки продавали только по рекомендациям действующих владельцев. Функционально устройство не впечатляло: маленький прозрачный дисплей с разрешением 640×360, слабая 5-Мп камера, мало памяти и скромные 2–3 часа работы от батареи не соответствовали ожиданиям пользователей.

После провала на массовом рынке Google сменила стратегию на бизнес‑фокус. С 2014 года разрабатывалась корпоративная версия Glass Enterprise Edition, адаптированная для промышленных задач. Однако эти бизнес-успехи не спасли проект на массовом рынке, и Google окончательно закрыла проект в 2023 году.

На фоне фиаско Google Glass, современные игроки делают выводы — и действуют иначе. Ray-Ban Meta* (признана в России экстремистской организацией и запрещена) не обещают революцию — они интегрируют ИИ и камеру в повседневную форму очков. Не «будущее на лице», а стильный способ снять сторис и получить подсказки от ИИ. Apple Vision Pro, напротив, сознательно уходит в премиум и не обещает быть массовым — только для профессионалов, с чётким сценарием: дополнительный дисплей, работа с контентом и Facetime. А Android XR (например, от Samsung) с амбицией создать экосистему, куда подключаются другие производители.

Главные фейлы: почему хайп умер быстрее, чем мы успели надеть шлемы

• Переоценка трендов: компании хотели влететь в хайповый тренд. В итоге технологии оказывались сырыми или неудобными.
• Нет ценности для пользователя: эти продукты часто не решали реальных задач, а разработчики не объясняли, почему именно их стоит использовать.
• Сложность и неудобства: тяжёлые VR-шлемы, громоздкие или нелепые устройства.
• Непроработанные риски: проблемы с приватностью, мошенничеством и токсичностью подрывали репутацию и доверие.

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

Может плодить новые эндпоинты или заставлять мобилку делать несколько запросов вместо одного? Каждый запрос жрёт трафик и батарею!

Элегантное решение — архитектура Backend for Frontend (BFF). Это прослойка между клиентскими приложениями и основным API, которая адаптирует данные под потребности конкретного клиента.

Основная идея backend for frontend

Один API не может эффективно обслуживать разные типы клиентов. Сайт, приложение для iOS, Android, умные часы — у каждого свои потребности в данных, ограничения по производительности и особенности интерфейса.

Монолитный API создают с расчётом на универсальность — на практике это приводит к компромиссам. Веб-версии нужны данные для сортировки, мобильному приложению — минимальный набор для экономии трафика.

Следуя архитектуре BFF, вы можете создать логику для каждого типа клиента и не засорять основной API. Вместо одного эндпоинта /api/products, который пытается угодить всем, появляются слои:

• один — оптимизирует данные для веба,
• второй — для мобильных устройств,
• третий — для умных часов.

Обычно данные приходят в неудобном виде: несколько связанных сущностей нужно запрашивать отдельно и склеивать на клиенте. BFF берёт эту работу на себя.

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

Каждый клиент получает данные в том виде, в котором может их сразу отобразить. Вместо загрузки 50 полей, из которых используется 5, BFF отдаёт только нужные данные.

«Можете добавить поле user_avatar в ответ?»

— «Это сломает мобилку».

«Тогда сделайте отдельный эндпоинт».

— «У нас нет времени».

С BFF этого диалога нет. Фронтенд-команда получает свой API и крутит его, как хочет.

Мобильное приложение съедает 10к запросов в секунду? Пишите BFF на Go. Веб-версию делает стажёр, который знает только JavaScript? Ставьте Node.js. Никто не заставляет выбирать одну технологию на все случаи жизни.

Как работает backend for frontend (BFF)

BFF размещается между клиентскими приложениями и основными бэкенд-сервисами, выполняя роль посредника. В отличие от API Gateway, который просто перенаправляет запросы, BFF трансформирует данные.

Архитектура взаимодействия

Классическая схема выглядит так: мобильное приложение обращается к своему BFF, веб-приложение — к своему, умные часы — к третьему. Каждый BFF знает особенности своего клиента и общается с основными сервисами на их «языке».

Когда мобильное приложение запрашивает список заказов, его BFF делает несколько вызовов к микросервисам:

• берёт базовую информацию о заказах,
• подтягивает данные о товарах,
• получает статусы доставки.

Затем склеивает всё в один ответ, отбрасывая ненужные поля и добавляя вычисляемые значения.

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

Обработка и агрегация данных

BFF не просто перекладывает данные из одного формата в другой. Он выполняет бизнес-логику.

Например, мобильный BFF может кешировать часто запрашиваемые данные, чтобы уменьшить количество сетевых запросов.

Если API возвращает цены в центах, мобильный BFF конвертирует их в рубли и округляет для отображения. Веб-версия получает точные значения с копейками для расчётов.

Независимость и масштабирование

Когда нагрузка на приложение растёт, масштабируется только его BFF. Проблемы с веб-версией не влияют на работу мобильных клиентов.

4 ключевых преимущества BFF

Оптимизация передачи данных

Самое очевидное преимущество — экономия трафика. Приложение не тащит 2 МБ JSON с полным каталогом товаров на мобильное устройство? BFF отдаёт только нужные поля.

Количество запросов тоже сокращается. Например, чтобы показать профиль пользователя, фронтенд делает 5 запросов:

• за основными данными,
• аватаром,
• списком друзей,
• последними постами,
• настройками приватности.

BFF объединяет всё в один запрос, получая данные параллельно от разных сервисов.

Упрощение фронтенда

Половина фронтенд-кода уходит на трансформацию ответов API:

• парсинг дат,
• группировку массивов,
• вычисление производных значений.

BFF может взять эту работу на себя.

Безопасность через изоляцию

BFF создаёт барьер между клиентами и сервисами. Мобильное приложение никогда напрямую не обращается к БД пользователей или платёжке — только через свой BFF.

Можно настроить разные уровни доступа:

• мобильный BFF видит только публичные данные,
• API для партнёров работает в песочнице.

Если мобильное приложение скомпрометировано, злоумышленник не получит доступ к внутренним сервисам.

Независимое масштабирование

Когда приложение попадает в топ App Store, нагрузка взлетает в разы. Но страдает только мобильный BFF — веб-версия продолжает работать стабильно. Можно быстро поднять дополнительные серверы только для мобильного трафика.

Появляется возможность экспериментировать с технологиями без риска. Хотите попробовать GraphQL для веб-версии? Внедряйте в один BFF. Тестируете новую базу данных? Подключайте к экспериментальной прослойке, не трогая продакшн.

Когда стоит использовать backend for frontend

BFF — инструмент для конкретных ситуаций.

Когда интерфейсы кардинально отличаются

Если ловите себя на мысли: «этот эндпоинт нужен только для веба» или «мобилка использует 10% полей из ответа», — пора задуматься о BFF.

Красный флаг — когда фронтенд-разработчики начинают писать костыли для обработки «неудобных» данных. Если половина JavaScript-кода занимается парсингом и трансформацией ответов API, что-то пошло не так.

Когда интерфейсы эволюционируют быстрее джунов

Стартапы и продукты в активной фазе развития меняют интерфейсы каждую неделю.

Классическая проблема: дизайнеры придумали новый способ отображения товаров в каталоге. Теперь нужны дополнительные поля, другая группировка, новые фильтры.

Без BFF это означает изменения в основном API, которые могут сломать другие клиенты. С BFF — правки только в одном месте.

Когда команды работают независимо

Если у вас несколько фронтенд-команд, которые постоянно конфликтуют из-за API, BFF даст им свободу.

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

BFF распределяет ответственность: каждая команда поддерживает свой слой.

Когда НЕ стоит использовать BFF

Если у вас простое приложение с одним клиентом, BFF добавит лишнюю сложность. Если API уже идеально подходит всем клиентам, зачем что-то менять?

3 типичные ошибки при внедрении BFF

Дублирование логики

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

Хуже, когда дублируется бизнес-логика. Расчёт скидок, обработка промокодов, правила доступа — это должно жить в основных сервисах, а не размазываться по BFF-слоям.

Избыточная сложность вместо упрощения

Пример: команда создаёт «универсальный BFF-фреймворк» с конфигурацией через YAML, поддержкой плагинов и собственным DSL. В итоге простое добавление поля в ответ требует изучения документации на 50 страниц.

Другая крайность — микро-BFF для каждой мелочи. Отдельный слой для авторизации, отдельный для форматирования дат, отдельный для валидации.

Неправильная гранулярность

Один BFF на все мобильные платформы может быть слишком общим: iOS и Android имеют разные особенности интерфейса. Но отдельный BFF для каждой версии приложения — явный перебор.

Частая ошибка — создание BFF по организационному принципу, а не по техническому. У нас три фронтенд-команды, значит нужно три прослойки. Но если все команды работают с похожими данными и интерфейсами, логичнее объединить усилия.

Практические примеры использования BFF

Netflix

Компания сделала разные API для веб-версии, мобильных приложений, Smart TV и игровых консолей. Каждый BFF оптимизирован под особенности устройства, например, TV-версия предзагружает больше контента из-за медленной навигации пультом.

Spotify

Используют BFF для разных клиентов: веб-плеер, мобильные приложения, десктопное приложение. Мобильный BFF агрессивно кеширует данные для офлайн-режима, веб-версия работает в реальном времени.

SoundCloud

Публично описывали переход на BFF-архитектуру. У них отдельные слои для веб-версии и мобильных приложений, которые по-разному обрабатывают аудиопотоки и метаданные треков.

Заключение

Страдают все, когда один API пытается обслуживать веб-версию, мобилки и что-то ещё. Фронтенд получает неудобные данные, бэкенд обрастает костылями, пользователи — медленными приложениями.

Backend for Frontend создаёт слой между клиентами и основными сервисами. Каждый тип устройства получает API, заточенный под его потребности.

Внедряйте BFF, когда интерфейсы кардинально отличаются, продукт быстро развивается, а текущий API снижает производительность.

Ты уже программист, если читаешь это! Больше про кодинг — здесь.

Как отображать анимацию NFT-подарков?

Для начала рассмотрим контракт, который содержит данные о NFT-подарке:

0:3a4f57aded85be8f7d1651b8e9d7749662014e08f6bcd3afaf2175c83188a7da

Из этого контракта можно получить всю необходимую информацию: атрибуты, описание и т.д. Эти данные можно запросить через API или вручную, нажав кнопку More в интерфейсе:

Там мы видим ссылочку с поясняющим ключом и именем:

Что именно мы из этого узнаём? Что анимация хранится в виде lottie. Эта информация очень полезна, так как с помощью нее мы сможем отображать и свою анимацию. Но как это сделать?

Как отобразить анимацию в вашем приложении?

Lottie — библиотека, разработанная компанией Airbnb. Позволяет отображать анимации в формате JSON, созданные с помощью AdobeAfter Effects. Благодаря Lottie разработчикам можно легко интегрировать высококачественные анимации в мобильные и веб-приложения, обеспечивая плавность и масштабируемость без значительного увеличения размера.

Применим на практике. Отобразить анимацию в вашем web. или TMA приложении проще простого, через библиотеку lottie-web.

В этом случае код будет выглядеть так:

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

• через ffmpg в mp4 (больший размер);
• покадрово в gif (потеря качества и размера);
• через webview.

Моя задача состоит же в отправке анимации пользователю непосредственно в Telegram. Логично, что формат хранения в Lottie выбран не просто так. Довольно много NFT хранятся в mp4, gif, webm.

Разгадка кроется не только в компактном размере данного формата, но и в устройстве Telegram стикеров.

Для решения задачи используем следующую схему:

1. загружаем https://nft.fragment.com/gift/hexpot-10348.lottie.json;
2. сжимаем в gzip;
3. отправляем в Telegram, например, в виде документа.

На golang это может выглядеть так:

Как мы видим, это лишь немного сложнее, чем отправить обычную картинку.

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

P.s. Всегда готов ответить на ваши вопросы. Пишите в тг @apitonDev.

Такой навык неоценим при генерации текста и решении всевозможных задач. Врожденная креативность таких «учеников» открывает море возможностей для контент-мейкеров, предлагая им источник вдохновения и помощь.

Моделей уже собралась целая коллекция — почти 30 штук (рейтинг на sapling.ai). Не только лишь Яндекс может составить OpenAI конкуренцию. Давайте сравним некоторые популярные решения с точки зрения разработчиков-внедренцев.

Мировое сообщество постоянно создает передовые языковые решения. Число параметров (считай, способностей оперировать словами, аббревиатурами и словосочетаниями) перевалило у некоторых за 1,5 триллиона единиц, модели стали демонстрировать «побочные эффекты»: резюмирование текста, разъяснения шуток, автодополнение кода и многое другое.

В качестве метрик для сравнения буду использовать:

• Количество тредов на StackOverflow;
• Объем параметров;
• Цена 1К токенов для малых проектов;
• Наличие условно бесплатного тарифа;
• Доступность гражданам РФ (усложнен ли деплой после ввода санкций);
• Способность решить математическую задачу.

GPT-4

Уволив и вернув Сэма Альтмана, OpenAI обратили внимание общественности на раскол мировоззрений: даже среди технических евангелистов есть лагеря оптимистов и пессимистов. Дело не столько в вере в скорейшую сингулярность с роботами-медсестрами, излечением деменции мозговыми чипами и полноценными виртуальными собеседниками. Люди сомневаются, успеют ли дожить до такого.

Среди всех моделей эта самая обсуждаемая, как в новостях, так и на форумах. Число тредов на StackOverflow перевалило за 4500 тысячи, а это много для отдельно взятой технологии. Компания не предлагает бесплатного тарифа для своих пользователей и в целом предлагает достаточно высокий ценник (0,06$ за тысячу токенов – примерно 800 слов)..

Задача:

Для начала – решение системы Wolfram Alpha (ряд сходится):

Ответ нейросети:

Если вы хотите познакомиться с API GPT поближе, изучите статью о собственных данных для GPT-4.

Деплоить приложение на GPT-4 в России – задача не для слабонервных по части оплаты. Приходится ехать за границу и создавать юрлицо на территории, скажем, Восточной Европы + банковский счет. Карточки из Казахстана не принимаются.

Google BARD

Примечательно, что модель обладает уникальной способностью генерировать точные и глубокие научные объяснения. BARD превосходно анализирует сложные проблемы и предлагает логические решения. Учебный корпус BARD включает в себя обширный массив текстовых данных — научные работы, книги и статьи. Основная цель ее — связные рассуждения.

Чтобы пообщаться с этой нейросетью, достаточно зайти на bard.google.com с VPN:

Решение задачи:

С оплатой, полагаю, в случае BARD будет также, как и с Google Cloud в целом. Поскольку на момент ввода санкций слишком большое число российских юрлиц пользовались продуктами Google, обходные решения об оплате нашлись довольно быстро, пускай и с огромной комиссией. Дорожку протоптали, и LLM наверняка подключится к той же системе биллинга.

LLaMA

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

Условия задачи по-русски модель не поняла, потому переформулируем на английский:

Ответ нейросети верный:

Помимо теста соотношения (Ratio Test) модель предложила альтернативный метод с неверным выводом.

Эта модель завоевала свое место под солнцем в сообществе экспериментаторов, поскольку предлагает условной бесплатный тариф.

YandexGPT 2

На мой взгляд, этот амбициозный проект вполне сможет перетянуть на себя одеяло на российском рынке. При наличии линейки продуктов Yandex Cloud с бесшовной интеграцией YaLM 2.0 шансы здорово подрастают.

Однако когда сравниваешь модели по числу параметров, отечественные импортозаместители сразу выглядят проигрышно. Не беда, создатели быстро исправляют ошибки и совершенствуют свои детища.

Решение задачи о сходимости верное:

GigaChat

Самая маленькая, если судить по числу параметров, модель: всего 18 млрд. параметров (в 88+ раз меньше GPT-4).

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

К сожалению, GigaChat не справился с задачей на сходимость ряда и даже рассказал о несуществующем тесте Сундарама-Рамануджана:

Заключение

Для вас я свела сравнительные характеристики моделей в таблицу:

Владелец NFT выставляет лот на аукционе и устанавливает для него первоначальную цену. Когда пользователи делают ставки, цена NFT растёт. Продавец также может снизить или повысить цену лота вручную исходя из его востребованности и популярности. Постоянное изменение цены создаёт проблему: чтобы выполнить свои обязательства перед пользователями и оставаться платежеспособной, платформа должна каким-то способом поддерживать необходимый объём активов и обеспечивать высокую ликвидность.

Существует несколько решений проблемы обеспечения ликвидности. В этой статье я сосредоточусь на одном из них, а именно — на построении протоколов по обмену и продаже NFT, основанных на принципах автоматического маркет-мейкера (АММ).

Одним из первых создателей такого протокола стал Sudoswap — лидирующий по количеству пользователей и уровню ликвидности NFT-маркетплейс, запущенный в конце июля 2022 года. На его примере мы рассмотрим, как АММ-протокол обеспечивает NFT высокую ликвидность. Меня зовут Роман Ярлыков, я разработчик смарт-контрактов компании MetaLamp, ко мне — на «ты» . Поехали!

• О протоколе Sudoswap
• Как формируются цены?
• Мультисвопы
• Sweep Mode
• А что с комиссиями?
• Параметры создания пула
• Обычный обмен
• Надежный обмен
• Их сравнение на практике
• Свопы NFT<>NFT
• Подведем итоги

О протоколе Sudoswap

Основатель Sudoswap— анонимный разработчик, широко известный вкриптосообществе благодаря своей коллекции NFT, сгенерированнойИИ, под названием 0Xmons.

При мысли об известных в DeFi-вселенной AMM-протоколах типа Uniswap или Balancer в голове возникают сложные механизмы, обилие математических формул и различных графиков в white paper.

Sudoswap ломает привычное представление о подробном мануале криптопроекта. Свой white paper создатель платформы называет litepaper, и в этом документе всего три страницы текста, написанного понятным обывателю языком, поэтому разобраться в нём несложно.

Технология АММ-протокола Sudoswap также проста и понятна. Как и на других DEX, она представляет собой смарт-контракты, которые автоматически поддерживают ликвидность в пулах с помощью специального алгоритма.

Главное отличие платформы от других NFT-маркетплейсов в том, что пулы ликвидности, которые она использует, индивидуальные, а не общие. Это значит, что у каждого пула есть только один конкретный владелец (поэтому не нужны LP-токены, т.е токены доли владения в пуле) и один конкретный смарт-контракт. Юзер, он же трейдер, может создавать сколько угодно пулов, это могут быть как односторонние пулы, так и знакомые нам по Uniswap пулы с двумя активами.

Пулы делятся на три категории:

1. Token. Даёт возможность купить NFT (за ETH или ERC20). Если у вас есть несколько NFT из определённой коллекции, вы создаете пул, где можно купить эти NFT за эфир;
2. NFT. Продажа NFT (за ETH или ERC20). Этот тип пула даёт возможность только продать свой NFT;
3. Trade. Отвечает за обмен NFT на токен (покупка и продажа). В такой пул заливаются и NFT, и токены, за которые они продаются; соответственно можно как купить NFT, так и продать. Easy as pie.

Как формируются цены?

Перейдём к применению АММ в кривых ценообразования — формулах, определяющих соотношение цен между активами. Протокол предлагает несколько кривых связывания цен на выбор: Linear curve, Exponential curve и Concentrated XYK curve. При создании пула трейдер указывает его параметры, в их числе — выбранную кривую плюс так называемую дельта (delta).

Поясню на примере c линейной кривой, как это работает. Рассмотрим пример ценообразования без учета комиссии:

Создаем пул NFT/ETH с ценой 1NFT за 1ETH и закидываем туда 5 NFT. Устанавливаем дельту 0.1 ETH, — это увеличит цену всех NFT из пула в случае покупки одного из них. Цена изменится на величину дельты — 0.1 ETH, то есть 4 оставшиеся NFT теперь стоят 1.1 ETH. При следующей покупке три оставшиеся будут стоить уже 1.2 ETH и т.д. В случае продажи NFT в пул цена каждый раз будет снижаться на величину дельты. То есть, после продажи одного NFT в пул, где осталось три NFT по цене 1.2 ETH, их станет 4 штуки по цене 1.1 ETH. Супер изи.

Экспоненциальная кривая работает по такому же принципу, только в этом случае дельта служит процентом, на который увеличивается и уменьшается цена.

Например, поставщик ликвидности может создать пул NFT/ETH со стартовой ценой 2 ETH и delta = 50%. Цена NFT увеличится до 2 + 50% = 3 ETH после покупки одного NFT из пула. После покупки второго NFT цена увеличится до 3 + 50% = 4.5 ETH и так далее. В любой момент продажи NFT пулу цена будет разделена на 1.5.

Резюмируем. Линейная кривая отвечает за прибавление и убавление цены на величину дельты. Экспоненциальная — за прибавление на величину дельты в процентах от предыдущей цены.

Недавно в твиттере Sudoswap объявили о внедрении нового семейства кривых связывания — Concentrated XYK curve. Эти кривые позволят настроить параметр «Концентрация» для контроля глубины пула и величины проскальзывания.

Concentrated XYK curve по-своему воспроизводят концентрированную ликвидность Uniswap v3. Например, стартовая цена задаётся при создании пула; при этом концентрированную ликвидность сложно представить в индивидуальном пуле, поэтому кривая предлагает заполнить его виртуальными токенами.

Ничего не поняли? Я пока что тоже. Информацию о том, зачем нужно новое семейство кривых на момент написания статьи можно почерпнуть лишь в паре твитов. Нет даже формул, так что единственный способ понять, как они работают — это разбирать код контрактов. Ах да, ещё есть два графика, которые напоминают игру «найди пять отличий»:

Мультисвопы

Функционал «мультисвоп» дает пользователю возможность покупать или продавать несколько NFT за одну своп-транзакцию. При мультисвопе значение spotPrice (цена в данный момент времени) будет обновлять delta для каждого купленного или проданного NFT.

Предположим, у нас есть сделка NFT — ETH со значением spotPrice 1 ETH, и линейная кривая со значением delta 0.1 ETH (в примере не будем учитывать комиссию).

Если пользователь продаст 5 NFT этой паре, он получит:

• 1 ETH за первый NFT
• 0.9 ETH за второй NFT
• 0.8 ETH за третий NFT
• 0.7 ETH за четвертый NFT
• 0.6 ETH за пятый NFT

По окончании мультисвопа новый spotPrice будет установлен на 0.5 ETH.

Sweep Mode

Sweep Mode — это фича, которая помогает совершить более выгодную сделку при покупке нескольких NFT из коллекции. Данный режим используется для поиска лучшей комбинации при покупке NFT.

Например, мы хотим купить 10 NFT из определённой коллекции со значением spotPrice 1ETH. Мы помним о кривой ценообразования: цена NFT будет увеличиваться после каждой сделки, — таким образом, кажется, выполнить условие покупки не удастся. В этом случае и пригодится Sweep Mode. В этом режиме протокол позволяет искать NFT с нужным значением в других пулах, и приобрести все 10 NFT из нужной коллекции в разных пулах по желаемой цене 1ETH.

Протокол применит тот же принцип при продаже NFT и постарается сбыть их в разные пулы по наиболее высоким ценам.

А что с комиссиями?

На централизованных маркетплейсах покупатели обычно платят комиссию платформы в размере 2.5% + % роялти (как правило 5 или 10%), таким образом общая комиссия достигает 12.5%. В Sudoswap действует комиссия в размере 0.5% — и никаких роялти. Отсутствие роялти стало предметом пламенных дебатов в твиттере; пользователи разделились на два лагеря и дискутировали о том, должны ли создатели получать гонорары за свои работы.

Правда состоит в том, что трейдерам выгодно отсутствие роялти, поэтому вряд ли они будут думать о морали. К тому же основатель платформы 0xmons писал в своем блоге, что рассчитывает на «китов», которые придут торговать большими объёмами, — а для них размер комиссии может стать решающим в выборе платформы.

Параметры создания пула

Контракт Sudoswap LSSVMPairFactory отвечает за создание новых пулов (называемых «парами»). Каждый пул представляет собой контракт с именем LSSVMPair, который принадлежит создателю пула и создаётся с настраиваемыми параметрами, — такими как тип пары (Token, NFT, Trade), тип кривой связи (линейная, экспоненциальная и концентрированная), спотовая цена, дельта и т.д. Затем эти пары можно отслеживать на предмет их активов и цен (полученных с помощью вызова «getBuyNFTQuote»).

Ниже — все параметры, передаваемые при создании пула:

После создания пула овнер сможет изменить spotPrice, delta и fee.

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

Обычный обмен

Концептуально напоминает обмен токенов на других DEX. Пользователь отправляет роутеру максимальную сумму ввода или минимальную сумму вывода (т. е. разрешенное проскальзывание), а также маршрут обмена и крайний срок. Затем маршрутизатор переключается между различными указанными парами. В конце всех свопов маршрутизатор суммирует все токены, которые должны быть получены или отправлены, и возвращает значение, если общее количество превышает указанное пользователем проскальзывание.

Иными словами, если недостаточно средств для покупки нескольких NFT по определённому маршруту, произойдёт откат транзакции.

Надёжный обмен

Надёжный своп, напротив, выполняет проверку проскальзывания для каждой своп-пары, а не совокупную проверку в конце. Если цена для указанной своп-пары превышает допустимое проскальзывание, маршрутизатор молча пропустит этот маршрут и перейдет к следующему без возвратов или ошибок.

Такой обмен подходит для ситуаций, в которых цена быстро меняется между отправкой транзакции и её исполнением. Если цена лота выросла за время отправления транзакции, пользователь в любом случае купит несколько NFT — в том количестве, на которое хватает отправленной суммы. Если останется сдача, маршрутизатор вернёт её пользователю.

Сравнение типов обмена на практике

Рассмотрим разницу между этими типами свопов на следующем примере.

Допустим, есть две пары для NFT и ETH. Первая пара имеет спотовую цену 1 ETH и линейную кривую с дельтой 0.1 ETH. Вторая пара имеет спотовую цену 1 ETH и линейную кривую с дельтой 1 ETH.

Пользователь Боб желает приобрести NFT, по одному из каждого пула за 1 ETH каждый, с проскальзыванием 10%. Боб отправляет своп-транзакцию. Прежде чем транзакция будет выполнена, пользователь Алиса покупает 1 NFT из каждого пула за 1 ETH каждый. Новая спотовая цена для первой пары составляет 1.1 ETH, а для второй пары — 2 ETH.

В случае отправки обычного свопа, Боб отправляет 2.2 ETH (2 ETH + 0.2 ETH для покрытия дополнительного 10% проскальзывания), — и транзакция завершается неудачей, поскольку он отправляет достаточно ETH, чтобы покрыть первый своп на новую цену 1.1 ETH, но недостаточно, чтобы покрыть второй своп в 2 ETH.

Если же Боб сделает надёжный обмен, он также отправит 2.2 ETH, но с максимальной стоимостью обмена 1.1 ETH. У маршрутизатора будет достаточно средств, чтобы покрыть первый своп в 1.1 ETH. Затем, увидев, что второй обмен стоит 2 ETH, маршрутизатор полностью пропустит эту пару. Транзакция завершится успешно, пользователю будет возвращено 1.1 ETH, а также отправлен один NFT, который он купил за 1.1 ETH.

Надёжные свопы улучшают взаимодействие с пользователем при более высокой волатильности за счёт увеличения количества газа.

Свопы NFT<>NFT

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

Ограничения и минусы

• Пулы ликвидности в Sudoswap независимы друг от друга; это и преимущество, и недостаток одновременно. Несмотря на то, что роутинг даёт возможность взаимодействовать сразу с множеством таких пулов, это не позволяет достичь той концентрации ликвидности, которую мы можем видеть в классических DEX.
• Пользователи всегда продают свои NFT мгновенно, если для этой коллекции есть пулы ликвидности. Если же NFT из разряда редких и уникальных, то его невыгодно продавать на такой площадке, ведь не существует пулов с редкими NFT по одной цене. Возможности проведения аукциона на Sudoswap тоже нет.
• Площадка также невыгодна тем, кто зарабатывает на роялти. Децентрализованные маркетплейсы не платят их и не предлагают им альтернативы. Напомню, что роялти — это в первую очередь соглашение между сообществом и создателями контента, маркетплейсы не обязаны их выплачивать, в контрактах они не зашиты, при обычной продаже p2p роялти никогда не списывались (как и комиссия маркетплейса).

Подведём итоги

Важные факты о том, как устроен АММ применимо к NFT:

• Есть односторонние и двойные пулы.
• У пула только один владелец.
• Владелец же устанавливает цены и определяет параметры изменения цены.
• Цена в пуле одинакова для всех токенов NFT, но меняется с продажей каждого токена.
• За изменение цены отвечает линейная, экспоненциальная и концентрированная кривая, которые корректируются дельтой. Чем больше актив из пула покупается тем он дороже и наоборот.
• При создании пула с одним активом его можно либо купить, либо продать, и нельзя обменять.
• Обмены могут выполнятся как токен на NFT, так и NFT на NFT. Можно строить маршруты обменов как в классических DEX, сами пулы агрегируются протоколом и позволяют осуществлять торговлю между пулами.
• Протокол AMM позволяет мгновенно купить, продать или обменять NFT. Протокол вносит большой вклад в увеличение ликвидности NFT-рынка, а также привлекает низкими комиссиями.

Это лишь поверхностный обзор основных возможностей AMM-NFT на примере одного протокола. Я описал далеко не весь функционал платформы; она развивается и постоянно добавляется что-то новое. При этом в мире DeFi существуют и другие протоколы, которые уже сегодня предлагают более широкий функционал и возможности.

Я бы назвал технологию АММ как минимум большими переменами, и как максимум — революцией в мире NFT-маркетплейсов. АММ позволяет легче управлять большими коллекциями, увеличивает общую ликвидность, снижает волатильность на этом рынке, а также ставит под вопрос существование роялти и двигает рынок к созданию других подходов к торговле NFT.

Если у вас нет медиафайлов и метаданных NFT в формате JSON, мы создали коллекцию изображений, с которыми вы можете поэкспериментировать. Вы можете найти медиафайлы здесь и файлы метаданных JSON здесь.

Мы будем использовать Hardhat, стандартную среду разработки Ethereum, для разработки, развертывания и проверки наших смарт-контрактов. Создайте пустую папку для нашего проекта и инициализируйте пустой файл package.json, выполнив в терминале следующую команду:

Теперь вы должны находиться в папке my-nft и иметь файл с именем package.json. Далее давайте установим Hardhat. Выполните следующую команду:

После установки hardhat, мы можем создать пример проекта Hardhat, выполнив следующую команду:

После этой команды, мы увидим несколько пунктов для выбора, выберите пункт (Create a basic sample project) и согласитесь со всем по умолчанию.

Давайте проверим, правильно ли установлен наш пример проекта. Выполните следующую команду:

Если все прошло успешно, вы должны увидеть следующее, отличия может быть адрес контракта:

Теперь у нас есть успешно настроенная среда разработки hardhat.

Далее, давайте установим пакет контрактов OpenZeppelin. Это даст нам доступ к контрактам ERC721 (стандарт для NFT).

Если мы хотим поделиться кодом нашего проекта публично (на веб-сайте, таком как GitHub), и при этом мы не хотим делиться конфиденциальной информацией, такой как наш закрытый ключ,  API Etherscan или наш URL-адрес Alchemy (не беспокойтесь, если некоторые из этих слов вам пока не понятны), давайте установим другую библиотеку с именем dotenv.

Теперь мы установили все зависимости и можем приступить написанию нашего контракта.

Написание смарт-контракта

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

Вот как будет сначала выглядит наш контракт:

1. pragma solidity ^0.8.9

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

2. import

Если у вас есть несколько файлов и вы хотите импортировать один файл в другой, Solidity использует ключевое слово import.

3. PRICE

Цена для чеканки(mint) одного NFT.

4. baseTokenURI

URL-адрес IPFS папки, содержащей метаданные JSON.

5. mapping

Это одно из видов хранилища данных (ключей и значений) который называется Storage, здесь мы будет хранить все токены принадлежащего пользователя.

6. event

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

Далее, мы установим baseTokenURI в нашем конструкторе. Мы также вызовем родительский конструктор(ERC721) и установим имя и символ для наших NFT.

Таким образом, наш конструктор выглядит так:

Когда мы устанавливаем его в качестве базового URI, реализация OpenZeppelin автоматически выводит URI для каждого токена. Предполагается, что метаданные токена 1 будут доступны по адресу

ipfs:/QmTMo6DFrfzKGGbkYsyMZRe16jBJcCcV72ZJHcM3a3Z2w7/1,

а метаданные токена 2 будут доступны по адресу ipfs:/QmTMo6DFrfzKGGbkYsyMZRe16jBJcCcV72ZJHcM3a3Z2w7/2

и так далее.

Однако нам нужно сообщить нашему контракту, что переменная baseTokenURI, которую мы определили, является базовым URI, который должен использовать контракт. Для этого мы переопределяем пустую функцию _baseURI() и возвращаем baseTokenURI.

Мы также пишем функцию для владельца, которая позволяет владельцу изменять baseTokenURI даже после развертывания контракта.

Резервация nft для владельца

Как владелец, вы можете зарезервировать несколько NFT для себя бесплатно (оплату надо сделать только за газ).

Здесь мы определяем публичную функцию reserveNFT, которая принимает один параметр _tokenId. Это и будет наш токен который мы хотим чеканить и зарезервировать для себя. Обратите внимание, что у этого параметра есть нижнее подчеркивание (_). Он не обязателен, но есть не прописанное внутреннее правило, что все входящие параметры мы пишем со знаком _;

1. _safeMint

Это та самая чудесная функция которая делает чеканку, ее мы берем из контракта ERC721.

2. nftOwner.

Сохраняем кому принадлежит этот токен.

3. emit

Запускаем наше событие, что пользователь (msg.sender) сделал чеканку (_tokenId)

Функция Mint NFT

Пришло время заработать немного денег. Для того чтобы пользователи могли чеканить наши nft они должны вызвать функцию mintNFT.

1. payable

Это модификатор, который дает знать что функция подлежит к оплате и пользователь отправляет эфир.

2. require:

Проверяет чтобы отправленный эфир был достаточным для чеканки nft.

Получение всех токенов, принадлежащих определенному пользователю.

Функция принимает адрес пользователя и возвращает токены которые мы хранили в хранилище nftOwner.

Вывод баланса

Самая прекрасная функция. Ее запуск, отправляет на кошелек владельца все заработанные эфиры.

Функцию может запустить только владелец.

1. balance – выбирает всю сумму на балансе контракта.

2. Проверяет чтобы баланс был положительным.

3. Отправляет эфир на кошелек владельца.

4. Проверяет что трансфер прошел успешно, в противном случае идет откат транзакции.

Проверка токена (modifier)

Если вы заметили, наши функции для чеканки reserveNFT, mintNFT могут чеканить токен который уже ранее уже был отчеканен. И перед началом процесса, мы не проверяем был ли данный токе уже отчеканен или нет. Для этого мы создадим модифаер который будет проверять статус токена до чеканки.

Модификатор функции выглядит так же как функция, но использует ключевое слово modifier вместо function. Его нельзя вызвать напрямую как функцию, вместо этого мы можем присоединить имя модификатора в конце определения функции, чтобы изменить ее поведение.

В modifier мы проверяем отчеканен ли переданный на чеканку токен. А все уже отчеканенные токены мы будем хранить в хранилище soldedTokenIds.

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

Для того чтобы наш модификатор начал правильно функционировать, мы должны добавить одно хранилище (Storage) soldedTokenIds и немного отредактировать наши функции для чеканки reserveNFT и mintNFT.

1. В самом верху контракт добавляем наше хранилище.

2. Отредактируем наши функции reserveNFT и mintNFT.

После чеканки мы храним ид токен в хранилище soldedTokenIds, и в конце функции мы добавили наш модификатор с параметром который получает наша функция.

Вот мы закончили с нашим смарт контрактом, он должен выглядеть следующим образом.

Развертывание контракта

Для того чтобы мы могли посмотреть как работает наш контракт, мы должны развернуть его на тестовых сетях, например на Rinkeby.

Примечание. Советую развернуть его на сети Rinkeby, чтобы мы могли посмотреть результат на платформе opensea, так как из других сетей на данный момент это будет невозможно.

Для развертывания нам понадобятся следующие вещи. URL-адрес RPC, закрытый ключ от кошелька и апи ключ от etherscan.io

1. Нам понадобится URL-адрес RPC, который позволит транслировать нашу транзакцию создания контракта. Мы будем использовать Алхимию. Создайте учетную запись в Alchemy, потом необходимо создать приложение (это бесплатно).

Пишем любое название, CHAIN: Ethereum, NETWORK: Rinkeby

После того как приложение создано, перейдите на панель инструментов Alchemy и выберите его. Откроется новое окно с кнопкой View Key в правом верхнем углу. Нажмите на кнопку и выберите URL-адрес HTTP.

2. Для того чтобы получить приватный ключ от кошелька, откройте расширение Metamask, нажмите на троеточие в правом углу, и в открывшемся окне нажмите на “Реквизиты счета”, затем на кнопку “Экспортировать закрытый ключ”.

После получения HTTP-адреса и закрытого ключа от кошелька, мы их пропишем в .env файл.

Теперь замените файл hardhat.config.js следующим содержимым.

Затем создадим файл scripts/run.js со следующим содержимым. IPFS URL замените со своим ipfs-ом (пример: ipfs://some_token/) или можете использовать наш ipfs который был описан выше.

Мы уже готовы для разворачивания нашего смарт контракта, но для этого нам потребуются деньги на нашем счете.

Фейковый эфир, вы можете взять отсюда:

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

Если все прошло успешно вы должны увидеть адрес вашего контракта. В нашем случае:

0xd440a80F4845D5bf1AdD3868573e286e2Df04df0

Вы можете проверить этот контракт на Etherscan. Перейдите на Etherscan и введите адрес контракта. Вы должны увидеть что-то вроде этого.

Нам осталось верифицировать наш контракт, чтобы полноценно использовать его.

Для верификации нам понадобится ключ Etherscan API. Зарегистрируйте бесплатную учетную запись здесь и получите доступ к своим ключам API здесь. Добавим этот ключ API в наш файл .env.

Установим следующий пакет для проверки нашего контракта.

npm install @nomiclabs/hardhat-etherscan

Теперь наш hardhat.config.js должен выглядеть следующим образом:

Теперь выполните следующие две команды:

npx hardhat clean

На места DEPLOYED_CONTRACT_ADDRESS поставьте тот адрес контракта который получили ранее, на места BASE_TOKEN_URI поставьте ваш ipfs url.

В нашем случае вторая команда выглядела так:

Теперь, если вы посетите страницу Rinkeby Etherscan вашего контракта, вы должны будете увидеть маленькую зеленую галочку рядом с вкладкой Contract, которая подтверждает что ваш контракт верифицирован и ваши пользователи теперь смогут подключаться к web3 с помощью Metamask и вызывать функции вашего контракта из самого Etherscan! Попробуйте это сами.

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

После того как вы отчеканили nft через reserveNFT или через mintNFT, вы на стороне OpenSea должны увидеть ваши nft (testnets.opensea.io)

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

Заключение

Теперь у нас есть развернутый смарт-контракт, который позволяет пользователям чеканить NFT из нашей коллекции. Очевидным следующим шагом будет создание приложения web3, которое позволит нашим пользователям создавать NFT прямо с вашего веб-сайта.

невзаимозаменяемых токенов (NFT) среди тех, кто отправит реплай на их твит.

Как получить?

Просто ответьте на этот твит. Условия простые, поэтому и получить эти токены шансы маленькие.

Зачем они мне?

Это уникальные токены, каждый который по-своему связан с Twitter. Где-то изображён первый логотип Twitter, где-то — тамагочи с твитом основателя компании Джека Дорси. Для фанатов соцсети — огонь.

Невзаимозаменяемые токены сейчас горячая тема. С начала года в одном только Twitter написали 29 миллионов твитов о NFT. Так что токен можно будет выгодно продать.

Почему 140?

140 — это количество символов, которые вмещается в один твит, визитная карточка Twitter. Токены выпустили в семь серий по 20 NFT.

Источник: TheNextWeb