(00:00:05) Александр Селезнев: Здравствуйте, дорогие подкаст-слушатели! С вами подкаст «Базовый Блок» — старейший подкаст про блокчейн на русском языке. У микрофона сегодня Александр Селезнев и мой соведущий Сергей Тихомиров.

(00:00:21) Сергей Тихомиров: Всем привет!

(00:00:22) Александр Селезнев: Сегодня выпуск 205-й, и в гостях у нас Евгений Пономарев, кофаундер Fluence. Привет!

(00:00:30) Евгений Пономарев: Привет всем!

(00:00:32) Александр Селезнев: Женю я очень давно хотел позвать в гости. Помню, как мы встретились в Сан-Франциско в октябре 2018 года, где-то в 20-х числах, на каком-то мероприятии про распределённый блокчейн. Мы с Женей тогда очень хорошо затерли, и я почувствовал, какой замечательный, интересный, образованный человек. Одно удовольствие пообщаться с человеком, который свободен от буллшита в душе. Потом оказалось, что Женя ещё и говорит по-русски — терли мы тогда по-английски, и было приятно. Потом пересекались много раз, и каждый раз я думал позвать Женю на подкаст. Женя тоже хотел, но каждый раз говорил: «У меня сейчас не время, давай через полгода, у нас будет пивот, после пивота пообщаемся». Так продолжалось семь лет.

(00:01:49) Александр Селезнев: Наконец настал момент, когда произошёл тот самый пивот, после которого у нас в гостях Евгений Пономарев из Fluence Network. Но перед тем как мы перейдём к контенту, хочу сказать несколько благодарностей. В первую очередь благодарю самого Женю и Fluence за поддержку. Что можно сказать про Fluence? Это облачная платформа на базе децентрализации, децентрализованная инфраструктура, которая даёт более дешёвую и отказоустойчивую альтернативу традиционным облачным решениям — AWS, DigitalOcean, Hetzner. С помощью Fluence вы получаете доступ к глобальной сети независимых провайдеров, можете быстро запускать виртуальные серверы и разворачивать рабочие нагрузки по всему миру, при этом значительно снижаете расходы и не зависите от одного провайдера. На этом выпуске мы все эти утверждения проверим на прочность.

(00:02:49) Александр Селезнев: Также спасибо нашим другим спонсорам. Это Zerion с Zerion API — мощный инструмент для Web3-разработчиков. С его помощью можно в реальном времени получать данные о кошельках, токенах, DeFi-позициях и NFT на более чем 24 блокчейнах, включая Solana. API даёт детальные человекочитаемые транзакции, multichain, высокий uptime, масштабируемость на тысячи запросов в секунду. Zerion API используют Uniswap, OpenSea, WalletConnect, Rainbow Wallet и другие крупные компании.

(00:03:22) Александр Селезнев: Третий спонсор — GOSH. GOSH разрабатывает блокчейн Acki Nacki на новом протоколе, который достигает консенсуса за две итерации — самый быстрый из теоретически возможных. GOSH готовится к запуску Mainnet в ближайшие месяцы, у них уже миллионы участников в коммьюнити, я сам проверял. Заключены партнёрства с Oracle, Amper Computing, основные направления Acki Nacki — мобильный гейминг, мемкоины, DePIN и прочее. Надеюсь, скоро у нас в гостях будет Митя Горошевский, основатель GOSH. И last but not least.

(00:03:51) Александр Селезнев: Спасибо тем, кто поддерживает нас на patreon.com/basicblockradio и на boosty.to/basicblockradio. Спасибо вам огромное.

(00:04:07) Александр Селезнев: Что ж, перейдём к вопросам. Первый вопрос у нас всегда один и тот же: Женя, расскажи про свой путь в крипте. Как ты попал в крипту? Как ты оказался там, где ты есть сейчас?

(00:04:13) Евгений Пономарев: Пришло время ответить, где я был 8 лет. В крипте я оказался ещё раньше: первый раз я узнал, что такое Bitcoin, где-то в 2012 или 2011 году, уже точно не помню. Тогда как раз был период, когда майнинг-пулы уже были, а GPU-майнинга ещё не было, то есть это было за поколение до ASIC. Был только Bitcoin, какие-то альткоины, на Хабре выходили первые статьи про Bitcoin — я подумал, что это довольно интересная штука, совсем не похожая на все digital-деньги, которые были до этого. Я поинтересовался, но, к сожалению, не сильно глубоко. Как и многие, что-то запускал, майнеры потыкал, но весь софт был в зачаточном состоянии и далеко до среднего потребителя. Было непонятно, выживет ли это, потому что стоимость биткоина, как у мемкоинов, могла уходить почти к нулю — неясно было, есть ли смысл вкладывать силы и ресурсы. Потом было несколько волн, я следил за развитием. Наверное, как и многие, после запуска Ethereum в начале 2017 года, когда ICO начали шуметь, до меня это долетело, и я понял: надо что-то делать в крипте. Технология мне давно была интересна, но я не понимал, что там сделать: когда был только Bitcoin и можно было скопировать чейн с новым логотипом, фантазии не хватало на то, какой value я могу принести. С Ethereum стало интересно — можно строить разные распределённые технологии на блокчейне. Тогда я задумался про computing, storage, про интернет-протоколы, которые можно переделать для лучшей децентрализации с помощью блокчейна. Уже в 2017 году я стал full-time в этой индустрии.

(00:06:36) Александр Селезнев: Что ты делал в первое время? Сразу появился Fluence?

(00:06:41) Евгений Пономарев: Да, смешно, но сразу появился Fluence. Я стал думать, что запустить, ходил советоваться с друзьями. Мы с кофаундерами оформились как группа. Был мой кофаундер Митя Куринский — он до сих пор кофаундер и CTO Fluence, и Саша Демитко, тогда кофаундер, потом ушёл заниматься AI. Мы решили что-нибудь поделать, сделать проект с децентрализованными зашифрованными базами данных. Первая итерация Fluence — децентрализованная шифрованная база данных, прототип, который мы запилили в 2017 году, и первый раунд фандрейза на неё. Потом мы пивотнулись, и ещё много раз. В целом могу порассказывать всю историю: как двигались, искали product market fit, что получалось, а что нет.

(00:07:49) Александр Селезнев: Если честно, это очень интересно, потому что Fluence — реальный долгожитель: не так много блокчейн-проектов живут так долго. Для меня обычно самое сложное — смастерить цельный vision, куда мы с командой будем двигаться, убедить всех, что я сам в это верю, самому в это поверить и убедить всех вокруг. Каждый пивот я лично воспринимаю как невероятно тяжёлую фазу, мне это супер болезненно даётся — не только в бизнесе, во всех направлениях, особенно если ты лидер. Интересно, что вы пережили много таких сложных моментов. Можете рассказать чуть больше: как это давалось и почему, и куда?

(00:08:47) Евгений Пономарев: Очень смешно было, когда мы начинали проект: тогда был год ICO, мы подумали — ICO звучит весело, давайте сделаем ICO. Сначала принято было делать pre-ICO, более ранний раунд, чтобы были ресурсы на маркетинг или допилить продукт, а потом выпустить токен. Мы сделали первый pre-ICO и получили значительную сумму в крипте. Мы поняли, что абсолютно не готовы запускать токен и публично выходить на рынок: на тот момент у нас не было работающего продукта, не было клиентов, нас три с половиной человека, и мы не знали, что делать, хотя собирать раунд было весело.

(00:09:49) Александр Селезнев: В этой ситуации многие тогда оказались.

(00:09:57) Евгений Пономарев: Да, мы просто поняли, что не готовы: если выпустим токен, это будет фейл, все потеряют деньги, и мы будем выглядеть не в лучшем свете. Мы стали откладывать, и тогда до конца 2017 года шёл знаменитый буллран, а в 2018 году он уже пошёл на спад. Пока мы откладывали, рынок падал, и мы откладывали ещё сильнее. В 2017 году было ещё смешно, что через, по-моему, два месяца после первого раунда половина собранных денег лежала на мультисиге Parity. Произошёл хак Parity мультисигов, и мы потеряли половину денег. Мы такие: окей, мы планировали бюджет, а теперь половины нет. Вернуть всем деньги уже не можем, потому что осталась только половина. Тогда ещё не было принято сразу фандрейзить в стейблкоинах и в фиате, мы далеко не всё переложили в стейблкоины, и всё скакало вместе с рынком. Это было очень страшно и неприятно. Со временем мы научились с этим справляться: следующие раунды мы уже рейзили в фиате и не играли в игру, когда деньги компании лежат в волатильной валюте. Там на самом деле очень много событий: мы порейзили, потеряли деньги, не знали, что делать, отложили выпуск токена, сделали прототип продукта и поняли, что фигня не летит. По сути мы тогда сделали шифрованную базу данных, которая могла выполнять разные query: ты мог что-нибудь запросить и получить результат так, что владелец машины, на которой база хостится, не видит, какие данные у него внутри. Там были какие-то метаданные, а сами данные зашифрованы — детали уже не помню, честно говоря. Мы подумали, что в целом прикольная тема: все вокруг говорят про децентрализацию, про новые приложения и юз-кейсы для блокчейна, confidential computing тоже на слуху — давайте сделаем более general юз-кейс, некий trustless computing. Он не будет confidential, он будет trustless: можно вычислить алгоритм или программу на удалённой машине и иметь proof о том, что вычисление было корректным. Мы стали строить систему с двумя компонентами. Был блокчейн на Tendermint-консенсусе, чтобы валидировать вычисления быстро среди малого числа нод, и была отложенная batch validation с алгоритмом наказания валидаторов Tendermint-консенсуса, если они что-то провалидировали неправильно. Такой был дизайн, мы долго его придумывали и пилили, и под эту технологию смогли зарейзить следующий раунд. В следующем раунде, в 2018 году, мы уже рейзили от криптофондов — они тогда появились. У нас был 1kx, который сейчас стал достаточно большим, они тогда лидировали раунд, и были другие фонды поменьше, которых они притащили. Когда мы это делали, мы с тобой, Саш, познакомились, и с этой штукой ездили по миру по блокчейн-конфам, питчили. Тогда много разных проектов и необычных технологий, люди что-то создавали, появились ethereumовские хакатоны — мы везде были. Казалось, время, когда все что-то новое придумывают, но к 2019 году постепенно стало видно, что всё это новое никуда не едет с точки зрения adoption и применения. Мы оказались ребятами, которые тоже что-то делают, вроде концептуально несут децентрализацию в массы, придумывают deep tech, у нас был white paper на 50 страниц — но по факту не можем найти юз-кейс, непонятно, кому нужно и зачем. Где-то к концу 2019 года мы опять пришли к очередному пивоту: деньги закончились полностью. Была история, когда продукт не летит, денег нет, но как будто есть инвесторы, готовые дать ещё денег и сделать bridge round, потому что им нравится команда, им нравится, как мы думаем. Мы думали, что делать. В итоге взяли деньги и сделали небольшой bridge round. К нам присоединился Том: от нас ушёл один кофаундер, Саша пошёл заниматься AI-штуками, мы нашли Тома — нас с ним свели инвесторы, мы заобщались, оказался хороший коннект. Дальше следующие пару раундов случились благодаря Тому и его отношениям с разными фондами. К 2020 году мы перешли на новую итерацию. В предыдущей версии на блокчейне мы запускали код WebAssembly — мы напилили WebAssembly runtime — и подумали: оставим runtime, избавимся от консенсуса, потому что не поняли, зачем запускать WebAssembly в консенсусе, если не делать свой блокчейн, а делать arbitrary computation. Мы стали делать систему, которая позволяла запускать WebAssembly-код на удалённых машинах и иметь trace вычислений: ты разбиваешь код на функции, и по каждому запуску функций есть метадата, подписанная ключами, о том, что были такие-то input и output и выполнен такой-то WebAssembly-файл. Ты можешь чейнить вычисление этих функций, они могут считаться на разных машинах. Ты даёшь системе список функций, выполняешь их на удалённых машинах, и в конце имеешь trace о том, что всё выполнено корректно с точки зрения подписей. Оставался trust к тому, что вычисление в принципе было выполнено, но у тебя много метадаты об input-ах, output-ах и коде, который машина клеймит, что выполнила.

(00:17:50) Александр Селезнев: Сейчас я пошучу — только люди не придумают, чтобы zero-knowledge не использовать.

(00:17:55) Евгений Пономарев: Да, и нужно понимать, что всё, что мы делали, тогда zero-knowledge была ещё новой штукой, о ней только начинали говорить, ничего не работало, homomorphic encryption тоже особо не был развит — сейчас он чуть продвинулся, тогда не было нормальных layer-2 блокчейнов, было время Polkadot и Cosmos, которые на WebAssembly запускали смарт-контракты. Казалось, что WebAssembly — это будущее, и что Web3-шный мир не обязан был стать таким, как он стал: было много альтернативных веток, куда всё могло пойти. Мы делали систему с content addressability: использовали IPFS, чтобы были immutable адреса функций, immutable адреса данных и так далее. Были разные оптимизации, потому что тогда IPFS ещё плохо работал, были проблемы discover-ить машину, на которой лежит нужный content ID. В итоге получалась некая централизованная IPFS-нода, на которой на самом деле всё лежит, просто ты получаешь данные по content ID. Мы использовали libp2p, libp2p-соединения — это была система оркестрации вычислений с определённым trustless. Всё вылилось в custom DSL, Domain Specific Language под названием Aqua. Оно дожило до 2024 года: началось где-то с 2020 года с runtime, потом добавлялись штуки, и прожило достаточно долго, хотя весь этот период мы очень страдали с поиском adoption для этой истории.

(00:19:57) Александр Селезнев: Давай сейчас чуть-чуть перейдём к современности?

(00:20:04) Евгений Пономарев: Давай, да, можно очень долго рассказывать. Ты спросил про пивоты — по сути мы всю историю компании пивотились, но как-то получалось сформулировать гипотезу, которая нравилась нам и инвесторам, которые поддерживали нас в следующем раунде. Потом понимали, что что-то не складывается, и пивотились дальше, но всё время пытались делать историю вокруг децентрализации вычислений. Оно было совсем не похоже на cloud, местами странное, возможно, это можно было повернуть ещё в какие-то стороны. К чему пришли? В прошлом году мы поняли, что за все эти годы вокруг нас сформировалась куча людей из Web3-коммьюнити, которые приходили и хотели пользоваться нашим compute, но не могли: продукты были странные, технологии странные, либо узкий юз-кейс, либо мы говорим «у нас WebAssembly», а у них Node.js, а Node.js не работает с WebAssembly, или они хотят запускать ноды, а архитектура этого не позволяет. Мы поняли: давайте просто делать cloud в нормальном понимании слова. Мы пришли к тому, что по сути делаем Airbnb для compute или Uber для compute: агрегируем профессиональных провайдеров железа и даём cloud-продукты поверх этих агрегированных ресурсов. Сейчас cloud-продукты — это виртуальные машины, виртуализация, по сути прототип Amazon EC2, сейчас чуть более basic, придём к feature parity. Будем добавлять контейнеры, GPU, load balancers — джентльменский набор cloudа, над ним работаем. VM-ки работают, официально в альфа-стадии, скоро переходим в публичную бета и дальше будем двигаться.

(00:22:21) Александр Селезнев: Давай сейчас перейдём к тому, как на понятийном уровне работает Fluence и чем он отличается от централизованных облачных сервисов. Перед этим последний вопрос про историю: ты упомянул эпоху ICO, после неё было огромное количество проектов про децентрализованные вычисления — ICP нынешний, они вроде ещё живы, Golem, много других. Как думаешь, почему тогда это было нельзя сделать? Почему почти все тогда померли? Почему сейчас это можно и получается, а тогда нет?

(00:23:10) Евгений Пономарев: Короткий ответ в том, что все эти команды делали продукты для инвесторов, а не для кастомеров. Они были очень успешны с точки зрения ICO, а потом у них не было никаких кастомеров. Сейчас, наверное, у ICP что-то движется по продукту: они позиционировали себя как cloud, на самом деле всегда делали блокчейн — layer-1, он работает, давно есть. Но они сделали его со своей кастомной виртуальной машиной и своим языком, поэтому не поймали adoption: EVM не было. Насколько я понимаю, они пытаются его драйвить, пытались пнуть в Bitcoin-экосистеме, не знаю, что получилось, и драйвят через ICO-генератор и всякое такое. По сути они делают layer-1 — это немного не то же самое, не наш рынок, это не cloud, а другой блокчейн со своими особенностями. Другие команды как-то затухли, я не особо вижу, что они что-то делают, возможно живы, возможно нет. Основная проблема в том, что тогда никто не поймал product-market fit: пытались сделать что-то, что восхитит инвесторов, но непонятно зачем нужно.

(00:24:36) Александр Селезнев: Узнаваемые проблемы. Давай поговорим про Fluence. Когда мы готовились к этому выпуску, ты скинул своё выступление в Гонконге в 2025 году, я его посмотрел и в начале, в мотивационной части, увидел примерно то, что и ожидал: есть облачный поставщик компьютеров, например AWS, у него условная себестоимость — скажем, 50% или 30% от цены — плюс неэффективности, налоги, маржа и так далее. А Fluence, по твоей картинке, выходит в три раза дешевле по себестоимости. Давай поговорим про это. Почему так?

(00:25:29) Евгений Пономарев: Да, здесь достаточно всё просто. В этом сравнении есть определённая доля маркетинга, потому что важно понимать, что мы сравниваем. Если есть сервер, который ты можешь купить у хорошего поставщика по хорошей цене, поставить в дата-центр и отбить его стоимость плюс операционные расходы за два или два с половиной года и заработать на этом 20% в год, цена получится очень низкой. Если пойдёшь в Hetzner — он, наверное, среди русскоязычного коммьюнити самый популярный провайдер bare-metal и виртуализованных серверов, — там будет чуть дороже, чем в этой минимальной модели с минимальной маржой. Если возьмёшь более сложный продукт вроде DigitalOcean, который даёт не только виртуализацию, но и довольно много сервисов поверх, там будет ещё дороже — процентов на пятьдесят, наверное, дороже Hetzner, если я не ошибаюсь в цифре. А если придёшь в Amazon, Google и Azure, у них своя иерархия: по-моему, Google самый дешёвый, потом Azure, Amazon самый дорогой. Соответственно, они возьмут с тебя ещё примерно в два раза больше, чем DigitalOcean. Потому что могут. По сути мораль такая: у них очень много сервисов, огромные sales-ресурсы, много способов lock-in клиента на долгие контракты, они продают enterprise — и за счёт этого могут держать высокие цены. Но по факту существенная часть этой цены — маржа. Если смотреть на cost железа, он очень низкий. Наша идея в целом такая: давайте перестанем платить эту огромную маржу за compute — ресурс, который становится existential для всего человечества, особенно с AI, а потребление compute и без AI всё время растёт, люди постоянно строят новые дата-центры, нужно всё больше серверов, чтобы обслуживать данные, которые генерирует человечество. Давайте сделаем compute доступным. Как? С помощью децентрализации нельзя будет брать большую маржу на compute, и давайте сделаем cloud-сервис open source поверх этого. Базовая идея: не берём маржу на железо, делаем сервисы open source — так мы конкурируем с большими cloud-ами. Если по фичам и по reliability добьёмся parity, когда мы реально сравнимы с большими cloudами, люди смогут нас выбирать. Для этого нужны бизнес-компоненты и values, по которым клиенты выбирают cloud: хотя бы SLA, service level agreement, availability — когда большой cloud гарантирует uptime твоих ресурсов. На разные сервисы у них разная availability: на базовый сервис Amazon, по-моему, три девятки, то есть 99,9% uptime, на storage — пять девяток, на разные сервисы устроено по-разному. Что означают эти девятки? Если я плачу Amazon, а их серверы падают чаще, чем допускает этот процент, мне возвращают часть денег: какая-то доля платежа компенсируется, потому что они не выполнили условия по доступности железа. Мы понимаем, что в Amazon идут и платят большую маржу те, кто хочет быть максимально спокойным за свои вычисления и экономит на DevOps-ресурсах за счёт множества сервисов больших провайдеров. Эта конкуренция устроена очень сложно. С Hetzner, который продаёт bare-metal, мы можем конкурировать более-менее понятно. С Amazon гораздо сложнее, потому что его выбирают по другим критериям, которые мы пока не можем доставить, но планируем доставить больше. Надеюсь, тут что-то понятно.

(00:30:35) Александр Селезнев: Очень прикольно, на самом деле, совершенно по-другому посмотрел на эту проблему. Мне интересно было следующее: если я правильно понял, мы можем конкурировать по цене, если режем эту гигантскую маржу и делаем сервисы open source. А само железо насколько сопоставимо по цене, если я вообще правильно задаю вопрос? Насколько сопоставимо по цене сам compute? Мне, например, совершенно непонятно, как децентрализованный сервис может стоить дешевле такого же централизованного. Децентрализованный значит, что эффект масштаба у тебя слабее: всё в одном дата-центре централизованно обслуживать эффективнее, и так далее.

(00:31:29) Евгений Пономарев: Да, но сначала надо определить децентрализованность. Мы долго думали и существовали в Web3-парадигме: давайте сделаем магическую сеть, там будут разные устройства, ноутбуки, домашние компьютеры, которые шерят computational resource, и за счёт этого будет дешевле. На самом деле спроса на computation на телефоне в кармане нет. Никому не нужен computation на твоём телефоне, никто не будет слать код на девайс, чтобы ты его вычислил. Практически 99% юз-кейсов просто не будут работать. Обычный cloud-юз-кейс: пользователь открыл мобильное приложение или сайт, ему надо с бэкэнда что-то подгрузить — в этот юз-кейс cloud должен вписаться. Нужен хороший connection от девайса пользователя к бэкэнду, который он использует, поэтому бэкэнд должен сидеть в дата-центре, на сотовой вышке или где-то, где есть достаточно мощная вычислительная мощность, соответствующая современному потреблению современных application. Мы отбросили идею, что чужие компьютеры будут нодами и будут отдавать железо, и сказали: давайте сфокусируемся на compute-провайдерах, которые держат enterprise-grade серверы в дата-центрах третьего–четвёртого тира. Есть система сертификации дата-центров: tier 1, 2, 3, 4 означают определённые свойства — альтернативная power-line, два провайдера интернет-подключения, security и так далее. Современный дата-центр — сложная штука: здание с хорошим интернет-каналом, охлаждением, security. В таких дата-центрах стоят серверы, подключённые ко всему этому. Они должны быть современными по hardware-конфигурации: если серверы десятилетней давности, они никому не нужны, на них всё медленно, экономика не сходится. Мы сказали: только такие серверы и только такие провайдеры, пока что, на текущий момент. Если мы хотим, чтобы нами пользовались те, кто сейчас на Hetzner или Amazon, у нас тоже должно быть хорошее железо. Плохое железо, плохой connection, плохой availability — и мы им не нужны. Сейчас любой провайдер не может просто заджойниться в сеть: она permissioned на текущей стадии, подключаются только те, с кем у нас налажены контакты и отношения. Они предоставляют железо в сеть. Мы будем подключать провайдеров case-by-case, пока в какой-то момент не откроем публичное подключение — но там тоже будут ограничения, как они смогут доказать, что у них хорошее железо.

(00:34:59) Сергей Тихомиров: У меня follow-up по этой части. Что бы ты сказал на следующий вопрос? Получается, если ваши провайдеры вычислительных ресурсов — профессиональные дата-центры, Fluence — это ещё один cloud-провайдер, просто with extra steps? Вы стоите посередине между дата-центрами и пользователями. Зачем тогда Fluence, если дата-центр может напрямую продавать услуги пользователям — тем более, как ты говоришь, с длинными контрактами, с vendor lock-in, для него это может быть более выгодное предложение.

(00:35:25) Евгений Пономарев: Да, смотри, дата-центры и провайдеры — немного разные люди, разные компании. Дата-центр строит здание, владеет им и сдаёт в аренду стойки, подключения. Провайдеры покупают серверы и ставят их в дата-центр: они арендуют место, это клиенты дата-центра и наши провайдеры. У наших провайдеров арендовано какое-то количество стоек в дата-центрах, их бизнес — сдать это железо в аренду через Fluence, при этом операционные cost — платить дата-центру, обслуживать железо и так далее. Fluence в этом случае действительно агрегирует таких провайдеров, которые предоставляют серверы в арендованных дата-центрах на большой Fluence Marketplace. Разница с cloud в том, что весь наш стек open source: мы строим историю так, что если ты как клиент Fluence задеплоил что-то у провайдера, недоволен им и хочешь мигрировать на другого, ты делаешь это просто. Миграция должна быть абсолютно seamless. Если хочешь переехать on-premises, на своё железо, софт менять не нужно: поднимаешь свои серверы и переносишь весь workload. С cloudами история в том, что ты всегда на проприетарном софте. Между cloudами люди мигрируют через кучу слоёв, но в целом это боль. Мигрировать из одного cloud в другой — боль. Мигрировать из cloud на свои серверы — боль. Если пользуешься их проприетарными cloud-сервисами, а они все проприетарные, переехать так легко не получится.

(00:37:24) Сергей Тихомиров: Можно я задам follow-up тоже? Немного наивный, потому что я так непосредственно с этой проблематикой не соприкасаюсь. Правильно ли я понимаю, что cloud provider — это не «я плачу деньги, мне дают доступ по SSH к стандартному репозиторию Ubuntu, я ставлю что хочу: Bitcoin-ноду, HTTP-сервер, что угодно», и переезд на другой cloud provider — скопировать файлы и запустить те же бинарники? Можешь прояснить: помимо условного репозитория Ubuntu поверх стоят ещё слои амазоновского софта в Amazon, гуглового в Google — такой middleware между операционной системой и мной как пользователем, который мешает просто переехать с Amazon на Google, Microsoft или куда-то ещё?

(00:38:16) Евгений Пономарев: Смотри, надо понимать, что существенная часть пользователей облака пользуется — тот пример, который ты привёл, это Amazon EC2, их базовый сервис, который даёт тебе железку, в которую ты по SSH можешь зайти. Честно говоря, не помню, какой процент их revenue, но он не 80%, не 50% и, может быть, даже не 40%. Всё остальное — сервисы более высокого уровня. Это когда ты можешь drag-and-drop'ом, грубо говоря, контейнер задеплоить на амазоновскую инфраструктуру, которая автоматически эластично scalable и вообще магическая и работает красиво. Или это какие-то API, endpoint'ы, которыми ты пользуешься для инференса модели или для чего угодно. У больших облаков ты в основном покупаешь не SSH, а всякого рода API и некую композицию этого API — у них есть тулы, как это всё вместе сочетается. Соответственно, мы сейчас на уровне SSH, то есть конкурируем с Amazon EC2 и такими сервисами. Всего остального у нас пока нет. Если всё твоё back-end приложение состоит из open-source софта, который ты сам оркестрируешь, и тебе для этого достаточно только SSH-доступа к удалённым машинам, и ты именно так пользуешься облаком, то переехать из этого облака легко. Но поскольку большинство людей всё равно пользуются другими сервисами в облаке, которые надстроены вокруг этих машин, им переехать становится сложно. В нашем случае мы надстраиваем эти сервисы у себя тоже над базовой виртуализацией, над базовыми виртуальными машинами, но они остаются open-source. Это стратегия и ключевое value, чтобы быть альтернативой облаку.

(00:40:17) Сергей Тихомиров: Я пытаюсь понять из того, что ты рассказываешь — возможно, это частично отвечает на мой вопрос. Ещё у меня один follow-up по этой теме: почему именно невозможен или менее вероятен vendor lock-in в случае Fluence? Почему не получится так, что при вашем успехе многие будут деплоить свои сервисы, использовать Fluence, и получится vendor lock-in уже только для Fluence? Куда они будут переезжать, если им не понравится Fluence целиком — не как конкретный провайдер, а как целиком эта экосистема?

(00:40:47) Евгений Пономарев: Смотри, когда ты пользуешься Linux, можно сказать, что есть vendor lock-in в Linux, но у тебя свободы гораздо больше. Это вопрос к определению vendor lock-in и к тому, что такое vendor в этом смысле — производитель софта или производитель софта с какими-то условиями. Я бы сказал, что здесь мы пытаемся накладывать меньше условий. Если ты пользуешься нашим стэком и мы тебе больше не нравимся как поставщик ресурсов, ты можешь взять целиком своё приложение и перенести на другие ресурсы. Тебе не обязательно быть частью Fluence он-чейн Marketplace и платить транзакции через Fluence он-чейн smart contract. Больше свободы за счёт open source, но бизнесовая часть здесь важна: облако может завтра сказать, что переходит в open source, open source'ит все свои технологии — посмотрите, какие мы хорошие. Но очень большая вероятность, что этого не случится, потому что у них корпорация, есть shareholders, shareholders хотят зарабатывать деньги, есть бизнес-модель, и они, скорее всего, не могут себе позволить это сделать. Мы с самого начала сделали DAO: у нас есть децентрализация governance, которая должна преследовать ценности, которые мы изначально заложили. Если ты спрашиваешь, есть ли риск, что когда-нибудь DAO передумает и скажет: давайте всё за closed sourcing, превратим это в приватную компанию — наверное, риск есть, потому что DAO может проголосовать за всё что угодно. Но это риск любого DAO. Непонятно, как сделать лучше.

(00:42:31) Сергей Тихомиров: DAO для меня звучит как разве это не то же самое, что shareholders, только на новой технологии? Держатель токенов — их главная мотивация в том, чтобы ценность их токенов повышалась, ценность системы повышалась. В каком-то смысле это отражает динамику обычной компании, руководство которой мотивировано повышать стоимость акций или прибыльность или другие финансовые метрики.

(00:42:54) Евгений Пономарев: Да, наверное, здесь у меня есть такие размышления: shareholders и лица, принимающие решения в компаниях, которые выросли с for-profit бизнес-моделью, у них другой mindset, чем у тех, кто присоединяется и начинает влиять в системах с децентрализованным управлением DAO. Риск есть, но mindset другой, и из-за другого mindset есть большая вероятность, что эти ценности сохранятся. Они будут говорить: да, наша стоимость токена растёт именно потому, что мы продолжаем делать вот эту бизнес-модель, и эта бизнес-модель привлекает кастомеров — они как раз к нам приходят именно потому, что у нас более open-source децентрализованное решение, чем у больших облаков. Но риск есть, люди могут передумать.

(00:43:44) Александр Селезнев: А я хотел полушутя, полусерьёзно сказать, что вообще токены различных блокчейн-протоколов — это часто просто мемкоины с дополнительными шагами. Они позируются скорее на вере, а не на экономической эффективности какого-то протокола. Уже пытались посчитать: если посчитать, сколько должна стоить компания, которая генерирует столько же прибыли, как 1inch, оказывается, что она должна стоить существенно меньше, чем market cap условно 1inch. Это я из головы, я же не понял, про кого шла речь. Реально, во многом это вопрос веры в технологию, в идеалы и так далее. Мне кажется, текущая ситуация даже не противоречит.

(00:44:31) Евгений Пономарев: Stock-to-flow модель не работает в крипте, понятно, что крипта очень сильно спекулятивна. Мультипликатор вот этих спекуляций в цене токена просто максимальный по сравнению со stocks. Но это другая история, это скорее краткосрочные движения цены. А мы, наверное, говорили именно про долгосрочное: не будет ли долгосрочного риска, что все те, кто управляют DAO, передумают и сделают из Fluence приватную компанию, как OpenAI, например, сделал.

(00:45:01) Сергей Тихомиров: У меня ещё есть вопрос по этому разделу про общую экономическую идею и общий подход. Потом мы, может быть, закопаемся немного в технические детали, но на high-level мне бы ещё хотелось понять вот что. Традиционные облачные провайдеры, допустим, действительно запирают своих пользователей внутри своих систем, за счёт этого они получают большую маржу и, в принципе, они дороже, чем могли бы быть. Если мы этому пытаемся противопоставить децентрализованную сеть, мы предоставляем пользователям большую свободу поменять провайдера в случае чего, что, по моему пониманию, должно усиливать конкуренцию и вести к снижению цен в среднем. Но при этом мы берём на себя дополнительные затраты — если не полноценный консенсус, то по крайней мере какую-то peer-to-peer координацию, нахождение провайдеров, мэтчинг провайдеров и пользователей, желающих воспользоваться их услугами, и вообще, наверное, меньшую эффективность по сравнению с огромным дата-центром Amazon, который специально кастомно построен, чтобы максимально быть эффективным именно для их use case'ов. Не получится ли так, что наиболее эффективным способом предложить более выгодные цены клиентам является не построение децентрализованной сети, а просто построение конкурента Amazon, который уменьшит свою маржу и за счёт этого попробует захватить большую долю рынка?

(00:46:21) Евгений Пономарев: Слушай, я думаю, что здесь эффективность очень сильно зависит от use case'а, от типа workload, который нужен кастомеру, а также от географии и объёмов workload в определённых географиях. Вообще нужно понимать, что Amazon — это не просто сервера в каких-то дата-центрах. У Google, Amazon и Microsoft свои кабеля под океанами, через которые у них лучшее и быстрее, по сути, connection происходит между дата-центрами. Это, на самом деле, некие глобальные приватные сети, которые для огромных глобальных сервисов очень подходят и очень эффективны. Если у тебя большой глобальный бизнес, у тебя кастомеры во всех странах и тебе нужны compute-ресурсы в куче стран одновременно, то, скорее всего, тебе с Amazon будет гораздо удобнее работать, по крайней мере по сравнению с тем, что у нас есть сейчас. И нам, чтобы дойти до такого состояния, как Amazon, надо очень много всего сделать. Поэтому сейчас мы, по-честному, себя, конечно же, не сравниваем с большими облаками. Мы больше смотрим на конкуренцию с Hetzner, Interserver и всякими такими компаниями поменьше, через основной бизнес — bare-metal и какая-то базовая виртуализация.

(00:47:54) Александр Селезнев: Кстати, мне кажется, можно ввернуть вопрос от слушателей нашего чата. Вопрос от слушателя Андрей С. Я так понимаю, это потенциальный пользователь Fluence. Он задал вопрос с предысторией. Говорит: мы раним достаточно много серверов под ноды. У нас это вечная головная боль — найти адекватного провайдера в нужных локациях. Есть опыт использования, наверное, десятка провайдеров. AWS high-class — великолепное качество. Любые локации, но дорого. Hetzner — лучшее соотношение цена-качество, но мало локаций. Всё остальное — от безысходности. Интересуют ноды в США и Токио. Машины с NVMe-дисками, 8–16 TB+. Вопросы: кто фактически предоставляет вам инфраструктуру и железо? Есть ли планы по разворачиванию, например, в Японии?

(00:48:40) Евгений Пономарев: У нас провайдеры — независимые компании, обычно небольшие. Исторически так развивалась наша сеть провайдеров. Мы ещё в предыдущей итерации продуктовой много коллаборировали с Filecoin. Там у них был определённый бум в экосистеме. Мы задружились со многими провайдерами, которые были storage-провайдерами Filecoin. Это люди, которые купили железо, сервера разного типа: есть сервера, которые более заточены под compute, есть сервера с огромными дисками как раз под storage. Они mined Filecoin. В какой-то момент у Filecoin начался кризис роста, честно говоря: они перестали расти из-за волатильности токена и того, что reward'ы привязаны к storage — reward'ы за storage всегда в Filecoin. У многих провайдеров сломалась экономика, они перестали зарабатывать и стали искать, куда девать эти сервера, особенно с compute. Мы стали с ними общаться, и они стали первыми провайдерами во Fluence. При этом их сервера фактически стоят в таких же дата-центрах, в которых стоят сервера любых больших онлайн-интернет-компаний. Просто эти сервера сейчас, по сути, подключены как ресурсы на Fluence. Про локации: у нас есть локации в Америке, есть локации в Европе, Японии пока нет. В Азии не очень тривиально добывается хорошее железо по хорошим ценам — по крайней мере, у нас сейчас такое состояние, но мы в целом ищем провайдеров постоянно. Просто это небыстрый процесс по подключению провайдеров, учитывая особенности нашего стека для провайдеров. Но в том вопросе, я не помню детали, железо есть, NVMe-диски есть в Европе, в Америке, есть локации — если надо, давайте пообщаемся.

(00:50:42) Александр Селезнев: Вопрос, Серёжа, я сейчас задам ещё пару вопросов от слушателей, перейдём дальше. Тоже от слушателя Андрей С. Вопрос со звёздочкой. Цитирую: понимают ли они, что в условной Германии их сервис мало интересен, так как там уже есть топовые провайдеры, и готовы ли они предоставлять хорошие сервера в жопе мира?

(00:51:01) Евгений Пономарев: В жопе мира, если там нет дата-центров, то там не будет хороших серверов — или, по крайней мере, могут быть хорошие сервера с плохим интернет-соединением, или хорошие сервера дорого. Потому что есть, например, в некоторых странах высокие пошлины на железо — в Бразилии, в Индии получается дороже. Но если use case — ранить ноду, то смешно, конечно, что мы все эти годы шли к децентрализации. И к чему пришли? Что у нас, во-первых, половина всех нод в больших облаках сидит, а вторая половина сидит в больших дата-центрах. И все блокчейны, они фактически, может быть, за исключением Bitcoin и каких-то других радикальных блокчейнов, которые специально сделаны на радикальном ключе, ноды-то в основном все в дата-центрах. Поэтому тут, наверное, зависит от потребностей. Нас сейчас основной use case в целом на Web3 рынке — это ранить ноды блокчейнов. Мы на своём железе в разных дата-центрах раним ноды блокчейнов. Мы себе говорим, что мы улучшаем децентрализацию за счёт того, что мы более децентрализованы, чем те альтернативные провайдеры. А так-то, конечно, физически сервера централизованы в дата-центрах. Просто этих дата-центров много, и они пользуются open-source протоколом, который мы им даём.

(00:52:27) Александр Селезнев: И последний вопрос, который хочу передать от наших слушателей. Вопрос от нашего слушателя Конрада. Как обеспечивается защита GDPR и других законов о защите данных? Давай, наверное, даже максимально расширим сейчас этот вопрос. Как вообще у вас обстоят дела с регуляторикой? По-любому же там есть огромное количество различных сертификаций, наверное, каких-то лицензий, законов, которым нужно соответствовать. Это же очень сложно глобально всему этому соответствовать.

(00:52:58) Евгений Пономарев: Да, смотри, там по факту несколько вещей. Если мы приходим к enterprise и говорим: у нас есть железо, покупайте железо, они первым делом спрашивают про SLA, то есть гарантии availability. Второй вопрос — сертификаты. Являемся ли мы как компания SOC 2-сертифицированы, есть ли у нас ISO 27001, и про GDPR. GDPR — история скорее про то, что данные клиентов должны храниться в той стране, из которой клиенты. Если наш кастомер хранит данные своих юзеров в нужном регионе у нас, у него всё хорошо. Если он хранит их в другом регионе, это он нарушает GDPR, а не мы, потому что он ответственен перед своими кастомерами. Мы как провайдер не перемещаем пользовательские данные наших кастомеров, данные или workloads в другие страны без их ведома. Мы вообще этого не делаем. Они сами выбирают, в какой стране хостятся. В той стране у них виртуалка, в той стране они загружают данные. По SOC 2 мы сейчас в процессе, потому что это непростая история: нужно, чтобы вся цепочка вендоров была сертифицирована. У дата-центров обычно есть SOC 2-сертификаты, у провайдеров не у всех, и нам тоже сделать сертификат непростая задача. Но если мы говорим про юз-кейсы в виде хостинга нод и многих AI-юз-кейсов, в целом всем пофиг, потому что данные публичные. Публичные данные не распространяются под эти требования, то есть тебе не нужны все эти сертификаты.

(00:54:57) Александр Селезнев: Для хостинга нод — да. Но я так понимаю, ты уже упомянул, что вы приходите к корпорациям, и они начинают задавать вопросы. Для них это всё-таки критически важно. У них свой отдел безопасников, который от А до Я всё проговорит.

(00:55:10) Евгений Пономарев: Если они хостят ноды, им всё равно. Если они будут хостить ноды у нас, им всё равно. Если они будут хостить свой бэкенд со своими юзерами, базы данных юзеров, конечно, им нужны сертификаты от нас. И если у того провайдера, где они размещаются, есть сертификат, они сразу могут работать. Им на самом деле не обязательно нужен сертификат именно нас как DAO, как Swiss Foundation.

(00:55:37) Александр Селезнев: Серёж, у тебя был вопрос по этой теме, я вижу в нашем плане выпуска.

(00:55:41) Сергей Тихомиров: Да, мне интересно было бы в схожей тематике задать следующий вопрос. Когда мы говорим про децентрализованную сеть, у меня, по крайней мере, возникает вопрос про цензуроустойчивость. Я понимаю из ваших материалов и из того, что ты уже рассказал, что это не главный value proposition на данный момент, но всё-таки интересно что-то про это узнать. Могу ли я захостить через Fluence приложение, которое может вызвать вопросы у регуляторов или у кого-то ещё? Могу ли я захостить что-то вроде миксера или другие подобные вещи? Кто это контролирует? Подвергаются ли фильтрации задачи или приложения, которые хостятся через вас?

(00:56:22) Евгений Пономарев: Смотри, единой фильтрации нет, но фильтрация и удаление workloads есть по жалобе. Так устроен весь интернет и весь рынок cloudов. Если тебе прилетают жалобы, ты обязан удалить, иначе будут большие проблемы. Все cloudы удаляют, потому что риск даже не в миксерах, наверное, а во всяком пиратском софте: приходят жалобы. Есть жуткие вещи вроде детского порно. Кто-то может арендовать виртуалку за 5 долларов, загрузить туда дикий нелегальный контент и хостить веб-сервис. Жалобы обычно прилетают по IP-адресу провайдера, провайдер передаёт нам, мы это сносим сразу. Здесь нет обходных путей.

(00:57:16) Сергей Тихомиров: Можно уточняющий вопрос? Получается, все cloudы, вы в том числе, сносите по первому требованию исполнительной власти какой-либо страны, а не по судебному решению?

(00:57:30) Евгений Пономарев: Да, на самом деле так делают, наверное, практически все. Я знаю, что раньше были географии, где провайдеры не реагировали на жалобы, в основном какая-нибудь Азия. Люди там постили всякую нелегальщину, и в целом это как-то работало, но это не sustainable model, в этом нет смысла, потому что очень быстро возникают проблемы: провайдеров могут прийти и закрыть. Мы сейчас пытаемся выработать концепты градации серого: какие категории жалоб, какие категории контента и workloads, как мы на них реагируем. В целом мы можем снести провайдера, провайдер может вырубить сервер, и тут много разных вовлечённых сторон. Нужно понимать, как сделать так, чтобы по фейковым жалобам не вырубать legit customer, и как максимально быстро реагировать на жалобы, где что-то серьёзное. Там много деталей, не во всех у нас есть точный ответ сейчас.

(00:58:52) Сергей Тихомиров: Да, понятно, спасибо. Ситуация сложная. Чёткой грани, видимо, нет. Тот же условный Tornado Cash был окей, потом вдруг стал не окей, а теперь вроде тоже окей, но не совсем понятно, до конца ли или нет, и как на это реагировать.

(00:59:10) Евгений Пономарев: Да, я думаю, что если сейчас кто-то будет хостить Tornado Cash, скорее всего будет жалоба, и скорее всего мы это снесём, потому что для нас риски слишком большие.

(00:59:23) Александр Селезнев: Давайте я задам чуть поглубже технические вопросы. Мы уже упоминали характеристики вроде SLA, uptime и прочего. Я не из этой области. Какие гарантии вы можете предоставить пользователю по сравнению с популярными облачными сервисами? Они же тоже спрашивают.

(00:59:58) Евгений Пономарев: Сейчас, поскольку мы в private alpha, мы формально не подписываем SLA, но по факту мы на связи с клиентами всё время, потому что хотим отследить все возможные проблемы. Как только что-то идёт не так, мы это сразу фиксируем очень быстро. Можно, наверное, посмотреть какой-то исторический uptime, этой цифры просто нет под рукой. По выкатыванию новой инфраструктуры где-то могут быть downtime, но мы будем заранее предупреждать и мигрировать workload, чтобы было незаметно. Мы сейчас проводим достаточно много ручной переработки, чтобы кастомеры были счастливы. Следующий шаг по SLA — внутреннее название Programmatic SLA. Это означает, что провайдеры… Начнём с того, что у нас есть блокчейн, на самом деле это роллап. На роллапе смарт-контракты репрезентируют marketplace, на котором провайдеры регистрируются, говорят: у меня такие-то сервера, такая конфигурация железа, и так далее. Провайдер будет коммититься на определённый тип SLA. В cloudе практически всё, что мы делаем в целом по SLA, означает uptime. Uptime означает количество девяток: сколько времени из 100% выделенные кастомером ресурсы будут доступны. Они говорят: я коммичусь на три девятки, или на две, или на четыре. Это фиксируется в сделке, которую кастомер заключает с провайдером на блокчейне. Дальше есть мониторинг из разных частей: self-reporting, внешний мониторинг. Мы хотим сделать краудсорсную штуку: дать возможность определённому количеству внешних людей по сути пинговать провайдера, базовый IP провайдера, который в целом говорит, доступен ресурс провайдера или нет. Этот внешний пинг не говорит ничего о том, доступен ли конкретный сервер и конкретная виртуальная машина, но сигнализирует, доступен ли провайдер и какой у него средний latency из разных географий. Это внешняя evaluation. Есть self-reporting: провайдер сам докладывает, что его ресурсы доступны. Дизайн self-reporting в процессе. Я могу сейчас наврать, но кажется, в последней версии мы хотели это сделать на TEE-чипах: обязать провайдеров иметь TEE-чипы и сделать так, чтобы они не могли подделать актуальность сообщения «я доступен». На всех серверах должны быть эти TEE-чипы, чтобы понимать, что сервер доступен. Это репортится он-чейн. Он-чейн видно данные от внешних observers и от провайдера, которые сложно подделать. Мы можем примерно понять настоящий uptime провайдера.

(01:03:59) Сергей Тихомиров: Хочу уточнить по этой части. Когда ты говоришь про uptime, правильно ли я понимаю, что проверить мы можем по сути только то, отвечает ли кто-то, если я постучусь на этот IP? Мы не можем проверить, что у него столько-то ядер процессора, такая-то оперативная память или другие hardware-параметры? Или это тоже можно доказать в TEE или каким-либо образом?

(01:04:20) Евгений Пономарев: Да, смотри, история с uptime и SLA — мы очень много сил и ресурсов потратили на proof of compute, который у нас называется proof of capacity. Там было несколько итераций. Предыдущая итерация до сих пор есть: по факту это proof-of-work. У нас есть алгоритм, который провайдеры запускают у себя. Там RandomX-алгоритм определённой сложности, которая определяется он-чейн, есть определённые эпохи, в которых они должны засабмитить нужное количество proofs. По тому количеству proofs, которые успевают засабмитить в эпоху, мы можем оценить performance железа: на плохом железе не успеют или будут делать меньше proofs, на хорошем — больше. В целом это работает как метод определения performance железа, но есть проблемы. Это очень вероятностная история подбора хэша. Если делаешь слишком большой difficulty, они начинают не успевать в эпоху, и нужно думать: это плохое железо или как распределить rewards, которые мы за это тоже даём. Если они слишком быстро решают задачу, им становится экономически выгодно outsource это на high performance железо. Там нет хорошего решения. Ещё проблема: если используем proof-of-work, они тратят на это электричество, нагружают железо, операционные косты растут. Мы хотим перейти на систему, которая тоже зависит от TEE: делать бенчмарки. Ещё проблема proof-of-work в том, что на диск не можешь нормально доказать нестандартную конфигурацию соотношения процессора и памяти. В proof-of-work мы сделали так, что ты proving один физический core и 4 ГБ памяти, этими кусочками proving свои ресурсы. Если у тебя, например, 16 ядер и пол терабайта памяти, ты не сможешь запровить всю остальную память и сказать, что она у тебя есть. Мы перейдём к бенчмаркам, которые люди будут ранить в TEE-чипах. Деталей пока нет, но скорее всего мы на это всё перейдём, потому что это экономически эффективнее. Там есть определённые trust assumptions, но в целом провайдерам не очень выгодно хачить всю систему как к кастомерам, особенно учитывая нашу текущую наполовину permissioned систему, когда мы не допускаем любых провайдеров в любое время.

(01:07:37) Александр Селезнев: А вот про потерю кастомеров: у вас, я так понимаю, какая-то система рейтингов, что кастомер может сказать: отстой, не понравилось, перехожу на другого?

(01:07:48) Евгений Пономарев: Пока нет никакой системы рейтингов — как раз потому, что мы всех кастомеров знаем. Если у кого-то из них возникает проблема, мы сразу об этом узнаём. Сейчас всё работает в полуручном режиме. Ты можешь видеть он-чейн данные по proof of capacity, которые провайдеры предоставляют, но их сложно вытаскивать из чейна; кастомеры на них пока особо не смотрят. Когда появится SLA с latency, у них будут дашборды, чтобы было прозрачно и понятно: этот провайдер онлайн, у него такая-то статистика uptime, такие-то latency. Это гораздо более понятная история. Плюс бенчмарки железа мы тоже можем описать понятными метриками. Метрика хэшрейта вообще не репрезентативна для кастомерского workload: на определённых CPU можно выдавать хороший хэшрейт, но плохо работать для кастомера, и наоборот. Усреднённый хэшрейт в среднем что-то показывает, но это не очень хороший показатель для кастомера — подходят ли ему ресурсы этого провайдера.

(01:09:13) Александр Селезнев: Знаешь, почему-то появилось лёгкое чувство ностальгии. Кастомер захотел воспользоваться вычислительными мощностями — создаётся смарт-контракт, туда кладутся деньги, люди начинают в нём участвовать, он-чейн proof of capacity. У меня прям strong vibes с 2018 года: давайте всё класть он-чейн, давайте всё доказывать он-чейн. Реально тёплое чувство всё это вызывает. Кстати, что у вас за rollup, поверх чего?

(01:09:53) Евгений Пономарев: Да, layer-2 к Ethereum: мы на стеке Arbitrum, называется Arbitrum Orbit. В целом это optimistic rollup — там есть особенность, что withdrawal с чейна долгий, а депозит быстрый. Мы сделали так, что кастомеры в итоге платят на том чейне, на котором хотят, а мы пока руками перегоняем ликвидность на наш чейн. У нас есть ресурсы, которые мы сами менеджим: когда кастомер платит на каком-то чейне, мы подсовываем ему баланс на своём чейне. Там тоже есть место для быстрых бриджей, но изначально мы просто хотели как можно быстрее доставить customer experience. Строить бриджи для этого — оверкилл, когда можно гонять ликвидность руками.

(01:10:50) Сергей Тихомиров: У меня ещё вопрос по механике маркетплейса. На сайте и в ваших материалах, как я понимаю, вы приводите конкретные цифры: сколько стоит задеплоить что-то на Amazon, на Hetzner, сколько на Fluence — на Fluence значительно дешевле. Можешь поподробнее рассказать про механику ценообразования? Кто назначает эти цены? Можно ли обсуждать цены, вести переговоры? Или провайдеры просто предлагают свои цены, а кастомеры соглашаются или идут к другому?

(01:11:21) Евгений Пономарев: Последний вариант: провайдеры сами выбирают цены. У каждого своя экономика — своё железо по своей цене, своя бизнес-модель, разная стоимость аренды, разные локации. Цена всё равно будет зависеть от провайдера. Сейчас мы просим провайдеров ставить более-менее одинаковую цену — период раннего роста экосистемы. Но неизбежно придём к тому, что цены будут разные и будут зависеть от кучи параметров: разные серверы, разные локации и так далее. Каких-то алгоритмов договаривания там особо нет.

(01:12:01) Сергей Тихомиров: Продолжая тему экономики — или плавно переходя от технической части к финансовой, хотя они у нас сегодня довольно тесно переплетаются. Можешь рассказать, как сеть вознаграждает провайдеров и за что именно? Я понимаю, что есть два типа награды: за конкретные выполненные задачи и за задеплоенную мощность, даже если она простаивает. Подчеркни эту механику: зачем так сделано и как это работает?

(01:12:32) Евгений Пономарев: Есть два типа наград, но они не за выполненную задачу. Смотри: ты подключаешь железо. Если оно подключено к сети, доступно и шлёт proof of capacity, ты получаешь token reward. Если на это железо приходит клиент и арендует его, клиент платит тебе за ту часть, которую арендовал — stablecoin. Та часть, которая остаётся незанятой клиентом, продолжает submit proof of capacity и получает token reward. У нас есть протокольный фиксированный reward, выраженный в долларах, на средний CPU-core и на кусочек ресурса, который выглядит как один CPU-core и 4 ГБ памяти. Если я правильно помню, протокол оплачивает такой кусочек 10 долларов в месяц — примерно 3 цента в день в FLT токенах по текущей цене FLT. У тебя сервер, допустим, 64 ядра и сколько-то памяти. Часть сервера запускает proof of capacity и получает reward в токенах. Оставшаяся часть занята клиентами, и клиенты платят по той цене, которую ты назначил. Эта цена может отличаться от протокольного стандарта в токенах: ты можешь назначить любую — меньше или больше. Но proof of capacity награждает только стандартные ресурсы. У тебя может быть сервер с 64 ядрами и, например, 2 терабайта памяти, а мы награждаем только 64 ядра и 256 ГБ памяти — это кусочки «одно ядро, 4 ГБ памяти». Остальная память протоколом не награждается, и ты заинтересован её монетизировать, а не просто держать сервер. Клиенты при аренде VM сейчас могут выбрать конфигурацию; кастомную память пока выбрать нельзя, но это скоро доедет. Есть стандартные инстансы — сколько ядер и памяти получаешь — дальше конфигурируешь больше памяти на VM, больше дисков, количество IP и так далее. Когда провайдеры продают клиентам мощности, они их полностью утилизируют. Когда делают proof of capacity и монетизируют idle-ресурсы, деньги за proof of capacity они получают только за стандартизированный объём ресурсов.

(01:15:13) Александр Селезнев: В таких историях у меня сразу следующий вопрос. Каждый раз, когда в блокчейн-проекте вижу вознаграждение пользователям токенами, мне это похоже на заливание венчурными деньгами какой-то дыры в бюджете, какой-то неэффективности. Мы награждаем какими-то для нас бесплатными деньгами, потому что можем. И каждый раз вопрос: почему кто-то захочет купить этот токен? Примитивно, зная природу человека, если вы раздаёте токены за что-то для людей не очень важное, скорее всего они будут сливать в стакан ежемесячно — давление на цену, токен падает, все несчастны, голосующие тоже несчастны. Эту картину наблюдаю постоянно: токены падают, и интересно понять, кто может захотеть покупать FLT.

(01:16:24) Евгений Пономарев: Давай разделим вопрос цены — кто может захотеть — и utility. Объясню, в чём состоит utility, и как это работает в целом; ты потом решишь, драйвит ли это цену. Мы уже обсуждали, что цена в крипте сильно спекулятивна: в моменте может летать вверх и вниз, люди разочаровываются и уходят, считают, что проект умер. Но есть различие между полными мемкоинами без utility и проектами, где utility есть. У нас core utility токена — стейкинг. Это не традиционный блокчейн-стейкинг, где стейкаешь на валидатора, который секьюрит блоки. Здесь стейкаешь на железо или фактически на провайдера. Есть протокольный параметр: какое долларовое выражение токенов должно быть застейкано, чтобы определённое количество железа было подключено к сети. Провайдеры при добавлении нового железа каждый раз должны обеспечить его стейк токенами — по сути, железо генерит прибыль, и чтобы ресурс был в сети, мы просим токен collateral: кто-то должен засекьюрить железо collateral в токенах, тогда оно доступно на marketplace. Когда железо приносит токены или stablecoin — stablecoin от клиентов, токены от proof of capacity — rewards делятся между провайдером и тем, кто постейкал. Мы не требуем стейкинга от самих провайдеров. В упрощённой модели это могли бы быть сами провайдеры: хочу добавить железо, хочу зарабатывать — должен постейкать. Мы разнесли стейкинг и провайдеров. Люди с токенами — инвесторы, token-holders, long-term believers — могут стейкать на железо и получать staking rewards, потому что железо зарабатывает. У staking-протокола несколько итераций, есть текущая и то, куда движемся. Сейчас это атомарные стейки на каждый сервер в сети; немного перейдём к пулам — там вопросы, как провайдерам maintaining железо, выключать его, переставать слать proofs, как это влияет на стейк, за что слэшить. В общем виде: провайдер даёт железо, token-holder даёт стейк, сервер активизируется и зарабатывает токены и stablecoin. Провайдер получает токены и stablecoin, token-holder получает только токены — его доля stablecoin тоже конвертируется в токен. Legal-история с выдачей token-holders stablecoin как staking reward не очень понятная, их могут расценить как дивиденды; лучше давать токены. Примерно из этой мотивации.

(01:20:07) Сергей Тихомиров: Можешь рассказать про механику слэшинга, какую роль он играет — ты его упомянул — как сейчас работает и встречается ли на практике? За что можно слэшить участников?

(01:20:18) Евгений Пономарев: Да, на практике это было несколько раз, но редко — в основном из-за багов в нашем софте для провайдеров; их починили. Слэшинг сейчас такой: мы не слэшим token-holder, слэшим только unvested FLT rewards. Rewards за proof of capacity не сразу попадают стейкеру и провайдеру — их кладут в смарт-контракт и вестят 6 месяцев. Если ты провайдер, rewards идут постоянно, и всегда есть хвост unvested FLT rewards. Если сервер перестаёт слать proof of capacity — протокол считает его недоступным — или прислал недостаточно proofs за эпоху, послэшатся эти unvested rewards. Мы называем это Capacity Commitment: commitment, что определённый computational resource будет доступен в течение определённого времени. Если за это время он перестаёт слать proofs, лишается незавестированной части наград, а стейк возвращается token-holder. Мы пока не слэшим token-holders совсем — довольно спорный вопрос, зачем в этой модели слэшить token-holder.

(01:21:46) Сергей Тихомиров: Наверное, завершая раздел токеномики: играет ли какую-то роль liquid staking в этой системе и какую? Мне кажется, я видел этот термин в вашей документации, мы про это пока не говорили. Как вы вписываетесь в экосистему liquid staking?

(01:22:02) Евгений Пономарев: У нас есть партнёрство с компанией Parasail. Они делают liquid staking токены для NEAR, Filecoin, Ethereum и ещё нескольких проектов. По сути они сделали пул, в который можно постейкать вместо того, чтобы стейкать напрямую в протокол. Если ты стейкаешь в их пул, получаешь pFLT — liquid staking токен. Примерно как stETH на эфире: заложил один FLT, получил один pFLT. Потом твой FLT зарабатывает rewards, и rebaseится количество FLT, которое ты можешь получить, если вернёшь один pFLT в пул. Это rebasing-токен. Есть ещё wrapped pFLT, который не rebaseится, чтобы его могли использовать DeFi-протоколы. Пока у нас нет особого юз-кейса для pFLT — единственный маркетинговый: можно фармить points в нашей pointless-программе, где points ничего не стоят. Очень весело, большая инновация в блокчейне — наконец-то называем всё своими именами. Нам это очень нравится, и там на самом деле есть value, зачем участвовать. Могу про это потом отдельно рассказать. Мы смотрим на cloud и на токен как на два отдельных продукта. Есть roadmap фич и продуктов для cloud и отдельный roadmap всего, что связано с экономикой токена. Одна из интересных вещей — stablecoin, collateralized wrapped pFLT. Если у тебя есть FLT, ты можешь постейкать его, получить liquid staking токен, который аккумулирует yield от стейкинга, и сминтить на него stablecoin. Этим stablecoin можешь заплатить за cloud или, с помощью нашей биздевовской магии, если добавим его в DeFi-протоколы, извлечь value. Или поменять на обычный stablecoin и купить поесть. Можно также залевериджить FLT-позицию. Идея — добавить в экономику фичи, которые позволят и кастомерам cloud, и провайдерам эффективнее пользоваться капиталом. Для этого нужно принести value в систему. Если у кастомера есть FLT, он может пройти эту цепочку, получить stablecoins и заплатить за cloud. По той же схеме — алгоритмические free credits: можно занять Fluence stablecoin из пула, сформированного теми, кто stake FLT. Платишь только interest rate и можешь этим кредитом заплатить computation provider. С другой стороны провайдер с unvested FLT rewards за proof of capacity — для них это риск. Они могут против этого объёма FLT так же занять stablecoin и на него купить серверов, быстрее утилизировать капитал и скейлиться. Юзеры могут больше пользоваться cloud, залевериджив позицию и заплатив больше, быстрее поскейлить свои нужды. В эту сторону мы движемся. Пока всё не готово — это концепция, возвращаясь к вопросу, можем ли мы просто напечатать токенов и раздать. Зачем всё это? Почему не как Uber — взять инвесторские деньги и раздавать по 10 долларов кастомерам и провайдерам? Ответ, я думаю, в том, что в крипте больше механик, ручек и штуковин, чтобы подкрутить эффективность экономики и использование капитала. Нам не нужно брать кэш от инвесторов и отдавать пользователю. Можно через collateralized loans или stablecoin minting залевериджить капитал, который находится в системе.

(01:27:37) Сергей Тихомиров: Вопрос немного в сторону или развивая ещё одну тему — ещё один горячий топик в 2025 году, который я увидел в вашем посте про roadmap на 2026 год. Вы хотите развивать Fluence так, чтобы это было полезно в свете AI-революции и огромного спроса на compute со стороны AI-приложений для обучения моделей, инференса и так далее. Можете раскрыть эту тему? Конкретный вопрос: из того, что я понимаю про AI — не так много, но из заголовков следует, что огромные дата-центры, которые тренируют модели, сильно выигрывают от того, что они централизованы в одной локации. При огромных объёмах данных передача по подводным кабелям через океан была бы слишком долгой, поэтому всё помещают в один гигантский дата-центр где-нибудь в пустыне. Если мы хотим такую нагрузку положить на Fluence, подходит ли Fluence для этой роли? Не будет ли слишком высокой latency или других технических ограничений? Или всё будет работать хорошо? Если шире поставить вопрос — какие AI-related задачи ты видишь наиболее применимыми на Fluence?

(01:29:05) Евгений Пономарев: Да, смотри, в AI надо разделять тренировку новых базовых моделей, fine-tuning и инференс. Ещё пару лет назад много команд пытались тренировать новые базовые модели, но быстро пришло к тому, что несколько компаний сделали модели, которые другим уже очень тяжело повторить. Чтобы тренировать большую базовую модель, нужны десятки тысяч GPU последних моделей в одной локации, соединённых очень жирными линками — NVIDIA их патентует и так далее, я уже не помню всех названий. Компаний, которые сейчас тренируют большие базовые модели в мире, наверное около сотни, не больше. Все остальные фактически перешли либо на дообучение базовой модели — fine-tuning. Для LLM это значит, что ты шлёшь сотни тысяч строк промптов и объясняешь, как модель должна отвечать на определённые промпты. Вторая задача — инференс. Это то, что сейчас очень сильно растёт: индивидуальные запросы конечных юзеров к моделям. На рынок тренировки базовых моделей мы не особо смотрим — это рынок для компаний, которые могут построить дата-центр сами: клиент OpenAI, для OpenAI строишь дата-центр, или такие ребята, или NVIDIA, которые сами производят железо. Мы смотрим на fine-tuning и инференс, где много сервис-провайдеров. Это базовый рынок GPU, TPU — чипов, на которых ранится AI. Он устроен немного по-другому, чем большие cloud: менее монополизирован, больше конкуренции, маржа ниже. Большие cloud всё равно продают enterprise GPU с хорошей маржой, но есть много альтернативных провайдеров с железом, которое можно взять. Уже куча слоёв сервисов — serverless inference, hosted models и так далее. Рынок вырос буквально за полтора года, мы смотрим, как зайти. Гипотезы сформулированы в roadmap, но конкуренция ценой не очень доступна: если знаешь каналы дешёвых GPU — можно, но это limited opportunity, не скейлится, потому что все покупают GPU у одного производителя, монополия сильная. Спрос огромный — если есть возможность прикоснуться к нему, логично рядом с обычными серверами иметь GPU: те же клиенты, которые пользуются обычными серверами, пойдут арендовать GPU в одном месте, им так удобнее.

(01:33:21) Александр Селезнев: Настала череда случайных вопросов, которые пришли в голову при подготовке к выпуску на совершенно разные темы. Я вспомнил: когда-то давно в твоей истории в Инстаграме видел, что когда случился крах Silicon Valley Bank, у вас там были деньги. Расскажи, пожалуйста, про эту историю.

(01:33:47) Евгений Пономарев: Да, слушай, это ещё одна история из жизни стартапера — какой год был, уже не помню, 2022-й, по-моему. Мы уже пережили несколько пивотов, заморозку денег с фандрейзинга, кассовые разрывы. Не все крипто-стартапы вообще могут открыть счёт в банке. Сейчас у многих его нет — стейблкоины развелись настолько, что можно жить без банковского счёта. Мы когда-то смогли, были очень рады, у нас было два счета — в Silicon Valley Bank и Signature Bank. В один прекрасный день оказалось, что именно эти два банка внезапно в ситуации, когда денег нет. Пятница, дальше выходные, правительство Америки не работает — пришла новость. То ли 80, то ли 90 процентов денег компании было в Silicon Valley Bank. Мы стали думать, что делать на оставшихся 10%, как долго проживём, можно ли быстро зафандрейзить. За выходные оказалось, что Silicon Valley Bank настолько важен для американской IT-инфраструктуры — в этом банке были счета у огромного количества стартапов из Калифорнии — что это вопрос национальной безопасности. В понедельник, по-моему, Байден указом дал деньги банку, все выдохнули. Видите, какие хорошие преимущества доллара по сравнению с Bitcoin — спасает стартапы. Деньги, которые у нас в эфирах заморожены с 2017 года, до сих пор лежат на смарт-контракте — смарт-контракты это код и закон, ничего нельзя сделать. Выходные были стрессовые, но к тому моменту нас уже ничем не удивить — столько раз что-то шло не так, заморозка банка — ладно, переживём. Всё обошлось.

(01:36:29) Александр Селезнев: Прикольно, что вопрос национальной безопасности касается какого-то second-tier банка, в котором просто по случайности огромное количество стартапов держат счета. Даже такой банк может оказаться too big to fail.

(01:36:48) Евгений Пономарев: Да, точного ответа, пожалуй, нет — никто не знает, почему они решили спасать этот банк. Возможно, они оценили потенциальные риски из‑за того, что технологический сектор очень важен для Америки и на него делают большую ставку. Сейчас весь AI-boom во многом идёт из Калифорнии. Если у калифорнийских компаний пропадёт много денег в Silicon Valley Bank, это действительно риск для Америки, и поэтому tier-2 банк взяли и спасли.

(01:37:23) Александр Селезнев: Следующий рандомный вопрос. Помню, кажется, чуть больше года назад был airdrop Fluence, и как и все airdropы, он сопровождался огромным количеством негатива и хейта. Расскажи про свой опыт. Зачем вы вообще решили это делать? Кажется, вы дропали людям, которые коммитили в open source? В общем, расскажи. Кстати, мне вы не дропнули — меня тоже хейт.

(01:37:56) Евгений Пономарев: Да. Кстати, хейта было не так много — я больше видел благодарности, если честно, чем хейта, и это довольно прикольно: до сих пор на какой‑нибудь crypto conf можно встретить человека: «О, вы из Fluence, я ваш airdrop получил и правда продал его сразу — или не сразу». По статистике половину продают. История airdrop такая: мы гики и хотели придумать справедливый airdrop, думали об этом очень давно, а токен все эти годы не запускали. Пока мы думали, рынок сильно поменялся, и оказалось, что airdrop делать не надо — плохая история, особенно для людей без большого skin in the game в твоём проекте. Когда всё начиналось, в 2020 году наоборот все делали airdrop: «давайте кинем коммьюнити, привлечём внимание к проекту». Мы хотели привлечь внимание, но минимизировать число тех, кто продаст, и максимизировать тех, кто потенциально станет юзерами — airdrop как маркетинговый инструмент к кастомерам, без сильного удара по экономике. По факту, наверное, по экономике всё‑таки ударило, и второй раз такой же airdrop я бы не делал, хотя можно было придумать по‑другому, потому что позитива тоже создало много. Суть: мы взяли кастомеров, хакатонщиков, code-контрибьюторов за все годы — получилось хорошее число людей, но не сотни тысяч и даже не десятки. Нам нужно было раздать airdrop сотням тысяч релевантных людей — мы взяли Web3 open source репозитории и контрибьюторов оттуда. По сути airdrop получили те, кто контрибьютил в Web3-репозитории за последний, по‑моему, год. Особенность — trustless claim: если у тебя был приватный ключ от публичного ключа, опубликованного на GitHub, ты мог заклеймить airdrop. Попал в список, ключ на GitHub есть — заклеймил. У каждого юзера можно сделать публичный ключ public; он доступен по адресу вроде github.com/username.keys. У кого ключи были — вошли в airdrop, у кого нет — нет. Скорее всего, у тебя были контрибьюшены в Web3-репозитории, но ключи не были опубликованы, поэтому тебя не включили — это самая частая причина, почему кто‑то не вошёл; таких людей на самом деле больше. Это часть нашего гиковского решения по клейму: есть смарт-контракт, на своём компе с приватным ключом запускаешь bash- или Python-скрипт, он создаёт Ethereum-кошелёк и сообщение, подписанное приватным ключом с GitHub; отправил сообщение на смарт-контракт — получил токен. Нет централизованного сайта, который связывает публичный ключ со смарт-контрактом, раздающим токен. Нам казалось круто — trustless airdrop по GitHub-ключам, децентрализация. Но многие не вошли, и люди жаловались. Точно такой же airdrop по той же базе через два месяца после нас делал Starknet, у них на сайте была кнопка авторизации через GitHub — вошло больше людей, потому что они не делали нашу хитрую систему, а OAuth через GitHub. OAuth — trusted штука: если взломать их backend, можно заклеймить все аллокации за кого угодно. Мы хотели, чтобы всё было блокчейн-нативно. Получилось, как получилось.

(01:42:41) Александр Селезнев: Прикольно. Сохраним для истории эти два кейса — кажется, это в целом что‑то говорит о блокчейн-мире и о мире в целом. Ещё один бонусный вопрос. DePIN Day — я так понимаю, в последнее время у вас стало… Раз в год, по-моему, на major Ethereum-конфах и не только Ethereum, если я правильно понимаю. Наверное, одна из главных DePIN-конф — одна из важных. Вокруг вас, я так понимаю, кучкуется коммьюнити DePIN-протоколов, и у тебя, наверное, есть overview того, что в DePIN происходит. Небольшой дисклеймер: у меня всегда очень скептическое отношение к DePIN, потому что средний DePIN-проект вызывает ощущение «давайте использовать вычислительные мощности мобильных телефонов» — какие‑то фантазийные истории. Долгая подводка к вопросу. Как тебе кажется, как ты смотришь сейчас на DePIN-коммьюнити? Есть ли там что‑то интересное?

(01:43:58) Евгений Пономарев: Давай я, наверное, скажу, что это не коммьюнити, а сегмент рынка. Сегмент, который выгодно отличается от многих других тем, что проекты генерят revenue от кастомеров. DePIN — что это? Краудсорсинг ресурсов, чтобы из них сделать продукт и продать кастомеру — фактически оно. Fluence делает Airbnb для compute: Airbnb, Uber и sharing economy — предыдущая итерация DePIN, DePIN — следующая, только с блокчейном. DePIN — это Airbnb с блокчейном. У блокчейна очевидные преимущества для краудсорсинга: перераспределять ценность тем, кто контрибьютит ресурсы, платить в любой юрисдикции и так далее, плюс DeFi поверх, который даёт leverage и capital efficiency. Если смотреть на сегмент в целом, на любом сегменте есть откровенная фигня и проекты с выручкой. В DePIN, кажется — могу ошибаться — больше всего выручки сейчас генерят compute-проекты. Мы, к сожалению, пока не в топ‑3: у тех, кто наверху, очень большая выручка, дальше она падает, но мы постепенно ползём вверх. Есть проекты, которые краудсорсят видеозаписи езды по дорогам и продают данные в Google или Mapbox для панорам, или компаниям, которые делают self-driving — им нужны тысячи видеозаписей движения по дороге. Есть компании, которые собирают данные о погоде с датчиков на балконах, строят точные прогнозы и продают их тем, кому нужен прогноз погоды. Есть проекты с геймингом с very low latency за счёт близости клиентов — интересная штука, я не видел, чтобы хорошо работало, но есть вероятность: между клиентами игры не нужно много данных гонять, двух геймеров можно через сотовую вышку соединить достаточно эффективно. Где‑то можно сделать локальный CDN на этой же базе — есть проект CDN: TikTok-видео подгружаешь с сотовой вышки или через неё с девайса недалеко от тебя; работает только для популярных роликов, которые много людей в какой‑то area смотрят одновременно. Бесполезные проекты есть в любой индустрии, особенно в крипте, поэтому я бы не сравнивал только по этому. Здесь интересно, что revenue в DePIN идёт не от спекуляций токеном, а от кастомеров, которые платят за продукт, создаваемый в проекте. Это большое отличие от многих других криптосегментов.

(01:47:58) Александр Селезнев: Слушай, и он идёт, да? То есть там реально есть настоящий revenue, не знаю.

(01:48:05) Евгений Пономарев: Да, настоящий есть. Мне больше всего понятен compute-овский revenue: мы драйвим выручку тем, что пытаемся перенести ноды из облаков на DePIN — Fluence как раз DePIN — revenue за сдачу в аренду GPU и AI-workloads. Проекты, которые агрегируют GPU-провайдеров и продают их AI-компаниям или на spot-рынок, генерят очень достойную выручку в год — десятки миллионов долларов; для настоящего revenue в крипте это приличные цифры.

(01:48:50) Александр Селезнев: Да, прикольно. Может, назовёшь парочку интересных, на твой взгляд, проектов в этой области?

(01:48:56) Евгений Пономарев: Смотри, я могу назвать всех наших конкурентов. Есть compute-проекты, ориентированные на AI, это Aethir и io.net. Они тоже прошли несколько итераций того, как организовать протоколы и сети так, чтобы был спрос на эти ресурсы, было легко достать ресурсы и подключить их к сети. Но если это видеокарта у кого-то дома или компьютер у кого-то дома, попробуй продать это какому-нибудь клиенту. Соответственно, они нашли какой-то product-market fit. В storage мы по-прежнему говорим про Filecoin, Storj и ещё кого-нибудь вроде Crust Network. Storj — интересный проект, он основан в 2017 году. Сначала они тоже пытались делать максимальный децентрализм, а потом у них получилась гибридная модель: они агрегируют ресурсы, получили все сертификации и идут в enterprise, продают storage дешевле, чем Amazon S3, при этом API полностью compatible, есть сертификаты и ещё фичи над этим надстроены. Они нашли value, который клиенты покупают. Я знаю точно, что в storage клиенты покупают его для бэкапов. Есть проект ICN — Impossible Cloud Network. Ресурсы, по-моему, в основном в Европе, и есть enterprise-клиенты в Европе. Они как раз продают storage ради бэкапов в enterprise. Есть проекты из области погоды, geo, агрегации геоданных. Один называется WeatherXM, по-моему, второй — Geodnet. Они на виду, потому что генерят revenue, и люди видят, что это реально, а не «мы тут токен создали и что-то фантазировали». Нет, они реально нашли клиентов, получают эти данные от своих клиентов, crowdsourced, упаковывают и продают. В целом компаний достаточно много. Просто ни у кого, например, нет миллиарда revenue. Но оно растёт, и есть ощущение, что будет и миллиард, и больше revenue. Нужно понимать, что во всех этих проектах нет максимализации децентрализации. Есть компромисс и trade-off между децентрализацией, чтобы crowdsource эти ресурсы, и теми свойствами продукта, которые нужны клиенту. Клиент — обычно какой-нибудь enterprise. Всё-таки это B2B-решение. Примерно так. Можно посмотреть на нашем YouTube-канале выступления разных проектов с нашего DePIN Day за последний год. Выступлений очень много, можно посмотреть на проекты. У нас есть подкаст, его ведёт Том, мой кофаундер. Там он тоже интервьюирует кофаундеров DePIN. Уже больше года, по-моему, там куча записей.

(01:52:23) Александр Селезнев: Прикольно. Лично меня удивляет и в хорошем смысле драйвит, что такого рода проекты действительно генерят revenue и ведут себя как нормальный бизнес, а не как наша средняя криптоистория. Супер. Женя, у меня, кажется, все вопросы закончились. Серёж, у тебя, кажется, тоже. Отлично.

(01:52:47) Александр Селезнев: Жень, тогда финально мы обычно даём гостю микрофон. Можешь заявить что угодно или призвать к чему-то. В общем, микрофон тебе. Если есть что сказать, скажи.

(01:52:58) Евгений Пономарев: Скажу, наверное, какой-нибудь call to action. Fluence сейчас в стадии закрытой альфы. Мы иногда даём доступ людям. Если кому-то из слушателей интересно, можно нам написать или подать заявку на форме на сайте, чтобы получить доступ и потестить наши VM. Они работают прекрасно. Если у вас есть сервера в дата-центрах и интересно порассуждать, как быть провайдером на Fluence, у нас тоже есть форма. Мы в неё смотрим, можно в неё написать. Постепенно будем делать всё более доступным. Welcome всем. В нашей коммьюнити всегда можно что-нибудь спросить, мы обязательно ответим. Спасибо, ребята, что пригласили. Всего лишь 8 лет нам понадобилось. Но очень рад наконец-то поговорить с вами.

(01:54:01) Александр Селезнев: 8 лет, зато каких. Все были заняты чем-то хорошим. Спасибо большое тебе, Женя, за то, что посетил нас сегодня. Огромное спасибо, Серёжа, тебе за то, что вызвался быть соведущим на этом выпуске сразу же после отпуска.

(01:54:18) Сергей Тихомиров: Спасибо, было очень интересно.

(01:54:20) Александр Селезнев: И спасибо нашим патронам, тем, кто поддерживает нас на patreon.com/basicblockradio, тем, кто поддерживает нас на boosty.to/basicblockradio.

(01:54:27) Александр Селезнев: И спасибо нашим спонсорам. Это Fluence. В очередной раз упомянем эту компанию, децентрализованную облачную платформу. Zerion — Enterprise Grade Web3 API. И Acki Nacki. Это самый быстрый возможный блокчейн.

(01:54:42) Александр Селезнев: До скорых встреч, дорогие друзья.