«Мы думали, как изобрести блокчейн-инфраструктуру, устойчивую к централизованным уязвимостям»: Евгений Пономарев про Fluence Labs, децентрализованные вычисления и хранение

ПРО БЭКГРАУНД. Я лично узнал про биткоин давно — майнил его в то время, когда на компьютере еще можно было что-то делать. Своим появлением Ethereum принес масштабную идею: теперь блокчейн-технологии можно применить не только для того, чтобы переизобрести финансовую систему и деньги, а чтобы шире смотреть на вещи. Ethereum добавил виртуальную машину поверх блокчейна, и люди начали рассуждать о большем разнообразии приложений. 

ПРО FLUENCE. По меркам web3 компания сама по себе достаточно старая. Мы начали что-то делать еще в 2017 году. Тогда я и наш кофаундер Дмитрий наблюдали за блокчейном со стороны. Нас завлекла идея переизобрести интернет-инфраструктуру с помощью блокчейна, чтобы заадресить проблемы централизации, владения и контроля инфраструктуры, приложений и сервисов. 

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

Есть клауд-инфраструктура, где хостится существенная часть интернета и все сервисы — это всего лишь 3 провайдера: Amazon, Google и Microsoft. Когда есть такие гиганты, которые контролируют инфраструктуру, то возникает много болевых точек, в которых что-то может пойти не так. Например, технические проблемы, когда админ или девопс выключает кластер или дата-центр. Либо государство говорит: «Вы на нашей территории — забаньте этого клиента». По сути какой-то из сотрудников компании может сделать что-то плохое по отношению к клиентам, а их миллионы.

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

Тогда существовал такой стейт проектов: вот есть Ethereum, и у него есть какое-то количество первых конкурентов. С точки зрения аналогов клауд компьютинга были такие проекты как StorJ, DFinity, Golem. Собственно, всё. Мы стали копать в сторону всяких баз данных и зашифрованных данных. Мы рисерчили разные стороны и потратили достаточное количество времени, чтоб понять, что имеет смысл делать. В конечном счете пришли к тому, что сейчас является Fluence.

Сейчас Fluence — это децентрализованная компьютерная платформа и маркетплейс. Мы делаем маркетплейс вычислительных ресурсов. Это значит, что любой владелец какого-нибудь Raspberry Pi или профессионального дата-центра может присоединиться к сети и быть готовым предоставлять свои ресурсы и зарабатывать копеечку. Поверх этих ресурсов есть девелоперский стек. Наш основной кастомер — это девелопер, который пользуется Fluence по аналогии с клаудами. В клауде есть serverless — это база данных и клауд-функции, которые дают возможность абстрагироваться от железа, на котором это исполняются и не думать про сервера, которые автоматически scalable и full tolerant. 

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

По дефолту все, что вы деплоите, деплоится сразу на несколько провайдеров. Там есть алгоритм координации провайдеров. Fluence дает тулзы для того, чтобы настраивать и программировать Fault Tolerance, scalability и все, что нужно на бэкенде.

Всё это можно описать на нашем языке программирования – Aqua. Он сделан специально для того, чтобы создавать секьюрно-распределенные системы. 

Я могу, по сути, запрограммировать то, как мой бэкенд и разные инстансы или функции, задеплоенные на разных провайдерах, будут себя вести вместе, чтобы получилось то, что именно мне нужно. Часть из этого будет просто забилдено во Fluence по дефолту. Сейчас, например, есть Fault Tolerance, но нет фичи Autoscaling. И за всё это можно будет платить стейблами на блокчейне. Ну, или любыми другими ERC-токенами.

Еще одна важная вещь, которую мы делаем — пруфы на вычисления. Они помогают избегать ситуации, когда нужно строить систему репутации провайдеров. Мы, по сути, делаем более строгую модель, в которой можно положиться на корректное исполнение кода во Fluence. Блокчейн тоже гарантирует это благодаря консенсусу, но в блокчейне сотни и тысячи нод исполняют одни и те же вычисления, чтобы обеспечить безопасность через консенсус. А во Fluence нет глобального консенсуса, но есть пруфы корректного исполнения кода. Когда вы деплоите функцию на несколько провайдеров, вы можете опционально добавить консенсус, но по факту это делает исполнение дороже. 

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

ПРО АНАЛОГИ FLUENCE. Есть вот Filecoin — децентрализованный маркетплейс  сторедж-провайдеров. Там есть интерфейс для клиента, в который загружаются файлы. Есть механизм инсентивов, что провайдеры обязуются хранить файлы в течение какого-то времени. Если они этого не делают, то они теряют стейк. А если хранят, то доказывают это пруфами. Это вот очень похоже на нас.

У нас тоже есть маркетплейс провайдеров просто с другим железом. И точно так же есть система пруфов — просто с точки зрения девелоперов это немного другой продукт и уровень. 

Есть еще проекты, например, Akash Network. Но у них все попроще. Они тоже делают маркетплейс, но по сути он мэтчит клиента с каким-то провайдером. При этом нет гарантий, что провайдер, например, не уйдет в оффлайн. 

ПРО РАСПРЕДЕЛЕННЫЕ ХРАНЕНИЕ И ВЫЧИСЛЕНИЯ. Мне кажется, что децентрализованные распределенные вычисления сложнее, потому что количество юзкейсов и форматов, упаковок и тасков сильно отличается. 

База данных — тоже больше про вычисления, нежели про хранение. Это и сторедж, и компьютинг. Но в индустрии про сторедж начали думать раньше всего. Например, IPFS начался примерно в 2015 году, у них была первая White paper. Про компьютинг стали думать позже. А более менее юзабельные продукты начали появляться только сейчас. Причем они не все запускаются на чейне, но дают адекватный продукт, который девелоперы могут использовать. 

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

Нам пришлось много низкоуровневых вещей изобретать. В частности, мы сделали Aqua — это такой distribute execution protocol и domain specific language. На нем можно писать скрипты, которые описывают распределенные вычисления в терминах нод и функций, которые на них должны быть исполнены с добавлением условий, операторов, циклов и так далее. Aqua – это такой аналог AWS Step Functions, который можно секьюрно запускать в публичой P2P-сети и который дает больше языковых фич.

На каждой Fluence-ноде есть виртуальная машина, которая исполняет язык Aqua. Его сервят все ноды. Каждая из них сервит входящие реквесты через Aqua. А каждый реквест — это дата-пакет, в котором содержится скрипт, который описывает, как именно реквест исполняется в разных функциях на разных пирах. Так мы делаем инфраструктуру, которая может выполнять распределенные алгоритмы, которые не нужно передеплоивать каждый раз на все ноды или на часть нод. Потому что эти алгоритмы программируются внутрь реквестов, которые изначально откуда-то исходят. 

Самый простой пример что можно сделать — P2P- чат между двумя девайсами, которые будут использовать Fluence-сеть по середине. В таком случае клиент Fluence на одном девайсе будет создавать дата-реквест, который будет говорить: «Пойди на такую-то ноду и исполни такую-то функцию, а результат функции отправь на тот девайс». Так мы передадим сообщение с одного девайса на другой через Fluence-ноду. Но дальше всё сильно усложняется.

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

ПРО MULTICOIN CAPITAL. Они верят в распределенную инфраструктуру и имеют возможность инвестировать в наиболее адекватные проекты в этой сфере. Когда мы анонсировали наш раунд, Ceramic тоже анонсировали раунд. А это распределенная база данных. Задача реализовать такую идею летала много лет, но Ceramic — одни из тех, кто правильно к этой задаче подобрались. И их решение многим нравится. Поэтому Multicoin в них инвестируют.

В портфолио Multicoin есть RenderToken. Проект по рендерингу видео и всего остального на GPU.  Соответственно, они организовывают маркетплейс на GPU. Вот Ethereum перешел на Proof-of-Stake и, вроде как, много GPU освобождается, потому что доходность майнинга на других чейнах гораздо ниже. И вот они ищут, куда их применить. Некоторые проекты стараются адрессить провайдеров на этих GPU, чтобы рендерить на них видео или делать машинное обучение.

Multicoin также инвестировали в проект, который делает распределенный CDN. Тоже идея, которая плавает вокруг в течение многих лет. Но нет четкого лидера с пропозишном. 

Кайл (фаундер Multicoin Capital) достаточно четко пушит примерно одну и ту же мысль —  у Fluence должны быть четкие юзкейсы, четкие понимания насчет кастомеров. Кайл всегда советовал не распыляться на всё подряд и не делать платформу для всего, а фокусироваться на конкретных сегментах и понимать свой рынок. 

ПРО ЮЗКЕЙСЫ FLUENCE. Мы позиционируем себя как приватный тестнет, а не как продакшн. Прямо сейчас мы не стремимся онбордить максимальное количество кастомеров и форсить их запускать настоящие продукты на Fluence. У нас много партнерств и экспериментов, но мы не пушим это. 

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

FLuence полезен web3 в качестве оракулов — он может индексировать чейны и делать ботов. Но там частично не хватает фичей, например, поддержки популярных языков программирования, таких как Python или Javascript. 

Сейчас нам не хватает поддержки популярных языков программирования, на которых можно писать функции, чтоб деплоить на Fluence. Мы все компилируем в WebAssembly, поэтому сейчас поддерживаются Rust и C++, но люди хотят Python и JavaScript. Мы работаем, чтоб Python точно был. Это сильно увеличит количество возможностей и снизит порог входа для девелоперов. А сейчас многие не пользуются Fluence, потому что просто не знают Rust. 

Также во Fluence юзеры могут выбирать провайдеров. Есть алгоритмы, которые эту магию прячут под капот. У нас пока нет фильтров для выбора провайдеров по гео и хардверу, потому что это нетривиальные задачи. Как проверить, что сервера провайдера действительно в Европе, если он заявляет об этом? Или что у него мощное железо — как проверить, так ли это?

Мы хотим сделать Proof-of-Capacity — это про награду за аллокацию определенных вычислительных ресурсов в сеть. С помощью технологии можно доказать, что у тебя есть определенное количество ресурсов, которое определяется CPU memory. Вот к такой технологии хотелось бы в будущем прийти. 

ПРО ДАУНСАЙДЫ И ПРОВАЙДЕРОВ. Технически и с ноутбуком можно стать провайдером. Но вряд ли кто-то это оценит.

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

Основной барьер именно в девелопер экспириенсе. Вот есть Vercel, который фрондендеры и джаваскриптеры используют, чтобы деплоить джаваскрипт-приложения. Там появились функции, которые под капотом исполняются в AWS Lambda. Настолько AWS интегрирован во многие сервисы. То есть, люди используют инфраструктуру Amazon даже не напрямую, а через много разных сервисов.

Heroku, например, позволяет деплоить что угодно тоже в Amazon. В этом смысле сейчас стейт Fluence и других децентрализованных технологий на таком уровне интеграций не существует. Поэтому даже тулинг, который существует вокруг Filecoin, очень базовый.

А люди привыкли даже не с Amazon API работать, а через прослойку, которая упрощает разработку. Такого экспириенса именно в web3-инфраструктуре нет. Но это дойдет. Нужно какое-то время — допилить базовые тулзы и начать делать интеграции с такими штуками, которые упрощают девелопер экспириенс. 

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

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

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

ПРО БУДУЩЕЕ ДЕЦЕНТРАЛИЗОВАННОГО КОМПЬЮТИНГА. На самом деле это всё постепенно развивается. За последние годы было много ситуаций, когда какая-нибудь цензура происходила где угодно: GitHub банил аккаунты или проекты, Twitter начинал творить непонятно что. Как только большая корпорация цензурирует своих пользователей или государство форсит корпорацию цензурировать пользователей, сразу идет волна, чтоб защитить эту инфраструктуру. 

В целом спрос на уменьшение platform risk у бизнесов существует давно. Вопрос в том, есть ли решение для этого. Вот я хочу сегодня снизить риск и переехать с Amazon. А куда? Ну, могу сервера в дата-центрах поднять. И что? Вернуться на тот уровень, где все были 20 лет назад до изобретения клауда? Я хочу те фичи и легкость, с которой я управляю своей инфраструктурой в клауде, но с меньшими рисками к цензуре.

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

Цена — существенный фактор для бизнесов, которые пользуются клаудами. Если современный бизнес ими пользуется, то они тратят много денег на это, и оптимизировать затраты для них будет только в радость.

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

ПРО КОМЬЮНИТИ И ТОКЕН FLUENCE. Сейчас мы таргетим девелоперов как комьюнити. Но комьюнити же широкое понятие, и есть разные роли. Когда мы соберемся в мейнет, у нас появятся компьютерные провайдеры и токен-холдеры — люди, которые будут участвовать в DAO и гаверненесе. 

Сейчас мы партнеримся с девелоперскими комьюнити. А еще делаем ивенты и спонсируем хакатоны. Недавно делали партнершип с Developer DAO в рамках Denver. Пока есть не запущенные партнерства в Индии. Мы стараемся продвинуть Fluence на слуху, даже если он пока в каких-то смыслах не готов для продакшна. Нужно, чтобы люди пробовали и фидбэчили. 

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

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