👾 Web3 native computing — Алексей Прошутинский
Конспект доклада Алексея Прошутинского, Engineer Fluence Labs, про децентрализованные вычисления.
Что такое Decentralised computing
Уже есть ряд децентрализованных систем. Например, DeFi и криптовалюты работают как децентрализованная финансовая система. Есть успешные попытки создать децентрализованные storages (хранилища), identity (аутентификацию), networking (сообщества), а также decentralised computing (распределенные вычисления). Речь пойдет о последнем пункте.
Блокчейн тоже можно отнести к decentralised computing, так как он распределенно выполняет алгоритмы смарт-контрактов, но консенсусы Proof-of-Stake и Proof-of-Work накладывают серьезные ограничения на вычисления, а также это дорого и медленно.
Есть децентрализованные хардвейр-маркетплейсы, ориентированные в основном на обработку видео, рендеринг или какие-то высоконагруженные вычисления.
Fluence разработали более общий вариант, освобождающий от необходимости обращаться к провайдерам, снимающий ограничения клауд-сервисов, а также которым можно пользоваться на любых устройствах. Например, клауд стек диктует определенную архитектуру. Допустим, у вас есть высоконагруженный сервер и тонкий клиент, вы не можете просто так перенести кусочек кода из клауда на клиент, потому что там абсолютно разные стеки.
Зачем нужно переходить на web3
Существует платформенный риск в web2-системах — зависимость от хардвер-инфраструктур и централизованных API. Если мы начинаем строить приложения на основе сервисов вроде Facebook API или Twitter Developer и так далее, то мы не контролируем ни данные, ни доступ к ним. Есть угроза того, что провайдер обанкротится и мы вместе с ним.
При переходе в web3 этот риск не исчезает, но меняет «упаковку». Например, мы можем посмотреть в блокчейне Ethereum любую транзакцию, но для юзкейсов в реальной жизни этого недостаточно. Нужно построить индекс и отправить много запросов, что невозможно сделать на клиенте. В итоге все упирается в проекты-индексы, а по сути являются web2 API.
Юзкейсы Peer-to-Peer Computing в реальном мире
Peer-to-Peer Computing — это нечто среднее между Centralised computing и On-chain computing. Это система без посредников, без избыточности, с опциональным консенсус и верификацией, дешевая в эксплуатации. Такую систему можно применить в кроссчейн-блокчейн приложениях, рилейеры, приложения с приватностью, dynamic NFT. Также большое количество приложений используют менеджмент на DAO. Возникает ситуация, когда оффчейн приложения пытаются менеджить на ончейне через ДАО. Тут возникает ситуация, что кто-то может украсть все деньги, ничего может быть не исполнено и так далее. А если менеджерится приложение на ончейне через ДАО — тут все нормально, пропозалы валидируются блокчейном.
Поэтому возникает необходимость в децентрализованном compute layer, тригеры которого слушают клиента на блокчейне. Получается фулстек, который менеджится на ончейне, а все остальное исполняется на офчейне.
Как эту задачу решает Fluence
Проект Fluence состоит из трех частей. Это P2P Development stack (первый язык программирования для одноранговых приложений), P2P computing network (открытая сеть из узлов, которая работает как коллективный компьютер) и Code creator/ hosting economy (приложения и код, которые работают как ликвидные цифровые активы).
Development stack состоит из двух частей: Marine (Wasm runtime, мультимодульный, запускается на девайсах пользователей и в браузерах) и Aqua (язык, специально разработанный для распределенных систем, помогает настроить координацию в условиях отсутствия центрального пункта управления. На языке Aqua можно написать любой воркфлоу, который нам нужен — любые сценарии и приложения. Самая близкая аналогия к этому AWS Stepfunctions. Marine можно представить как AWS Lambda. А Aqua Libs — это различные клауд-сервисы вроде routing, scaling, deploy, load balance и т.д. Сеть существует уже два года, языку Aqua — год.
В стандартном клауд-нейтив подходе приложения по HTTP обращаются к какому-то гейтвею с определенным API. С Aqua можно применить децентрализованный подход без центра синхронизации. Каждая нода решает, хочет ли она становиться хранилищем или нет. Сейчас у Fluence запущено около 30 нод, они открыты, на них можно деплоить все, что угодно. В сети есть еще ноды наших клиентов, хакеров.
Как работает Fluence Peer
В основе лежит Marine, который исполняет функции, все это координируется AquaVM, куда вользователи отправляют вызовы, а он отрпавляет результаты вызовов. Вызовы Marine исполняются по таймеру. Есть также различные плагины и сервисы. Например, Fluence Peer поставляется с IPFS-нодой, что дает доступ к децентрализованной файловой системе.
Особенности Fluence stack и cloud stack
Мы пытаемся переизобрести клауд-стек и строим его снизу вверх: Marine (исполняет функции), язык Aqua (собирает все вместе, делает композицию API), поверх этого можно реализовывать более сложные технологии: консенсус-алгоритмы, метрики и т. д.
Также есть функция Peer Discovery, можно присоединяться к пирам, находить ресурсы, пиры, функции. Есть плагины к Ceramic, IPFS, Ethereum, Near.
Проблема доверия в децентрализованных вычислениях
Можно хостить свои ноды, этот способ не требует постоянного аудита, так как вы доверяете своим нодам и их валидация верна. Если усложнить, то можно использовать TrustGraph, который является аналогом сертификатов. Мы можем выбрать authority (доверительный источник), который выписывает сертификаты или трасты различным пирам. На базе этого также можно строить консенсус-алгоритмы. Например, можно с 10 нод попросить результаты функции и свериться с сертификатами.
Fluence Network: cеть нод и маркетплейс
Девелопмент-стек работает на сети, которая по сути является маркетплейсом. Каждая нода решает, какие сервисы она может хостить. В итоге это выглядит примерно как IPFS. Благодаря отсутствию единого централизированого консенсуса, мы можем масштабировать эту сеть насколько угодно.
Как это решает проблему наличия провайдеров
В блокчейне есть смарт-контракты, и девелоперы смарт-контрактов не зависят от нод — это абсолютно разные люди/устройства. Если я разработчик мессенджера и в новой версии все испортил, то хостеры нод могут решить, какая версия мессенджера им больше подходит. После релиза какие-то ноды могут обновиться, а другие могут оставить прошлую версию.
Пока есть спрос, хостеры будут давать доступ к старым API. Отделение разработчика от платформы избавляет от опасности деплатформинга, приложения обслуживаются в случае спроса и они не исчезают внезапно по велению разработчика.
Открытая децентрализованная экономика
Каждая нода может сама решать, как она будет получать деньги за вычисления. Это может быть оплата запроса, сервиса, подписки и т.д.
Благодаря децентрализованности платформы у нас есть возможность иметь фуллстек ДАО-менеджмент приложения. Это можно использовать для финансирования контрибьюторов. Например, многие разработчики баз данных не получили свои вознаграждения потому что, Amazon предоставил базы данных как сервис, а опенсорсные разработчики ничего с этого не получают.
Полезные ссылки:
Explorer: dash.fluence.dev
Website: fluence.network
Diskord: fluence.chat
Telegram: @fluence_project
Twitter: @fluence_project
Careers: fluence.one/join.html
Documents: fluence.dev
Скачать презентацию: https://t.me/cyberacademy/21940
