(00:00:00) Митя Горошевский: Тот, кому выпадает монетка, проверяет транзакции этого блока — это и называется Acki Nacki. Acki Nacki, понятно, это acknowledgement, not-acknowledgement. Мы запустились с 250 с чем-то нод на трёх континентах, в разных дата-центрах — это реально децентрализованная сеть. Наша токеномика — попытка смоделировать proof-of-work на proof-of-stake. Если вы используете вероятностную криптографию, зачем вам детерминизм на уровне консенсуса? Подпись валидатора уже сама по себе недетерминирована. Дальше вы можете использовать сеть как обычный cloud computer: писать игры и любые приложения, которые сейчас пишете на кластере, только они будут децентрализованы. У вас быстрый, децентрализованный и дешёвый cloud. А на трейдах, когда каждый блок из-за этого задерживается на три секунды, мы не готовы. Мы никуда не уперлись — Acki Nacki это доказывает. Не должно быть принципиальной невозможности сделать блок за 300 миллисекунд. Не должно быть принципиальной невозможности в блокчейне финализировать быстрее одной секунды. Не должно быть принципиальной невозможности сделать блокчейн на миллионы транзакций. Мы это делаем. Для всех этих юз-кейсов Acki Nacki — лучший блокчейн.

(00:01:12) Иван Иваницкий: Привет, друзья! С вами подкаст «Базовый Блок», и сегодня у нас в студии, как всегда, Сергей Тихомиров. Привет, Сергей.

(00:01:19) Сергей Тихомиров: Привет, Иван.

(00:01:20) Иван Иваницкий: И наш сегодняшний гость — Митя Горошевский, кофаундер GOSH, одного из наших спонсоров, которого мы регулярно объявляем в выпусках. Привет, Митя.

(00:01:30) Митя Горошевский: Привет, привет.

(00:01:31) Иван Иваницкий: Это выпуск 212, и прежде чем мы перейдём к разговору, я хотел бы поблагодарить наших спонсоров.

(00:01:37) Иван Иваницкий: Естественно, начнём с GOSH — кор-разработчик блокчейна Acki Nacki, основанного на новом протоколе, который достигает консенсуса за две итерации — самый быстрый из теоретически возможных. GOSH уже запустил Mainnet. В коммьюнити более 4 миллионов участников, заключены партнёрства с Oracle и Amper Computing. Основные направления развития — мобильный гейминг, биодайверсити-активы, мемкоины и DePIN.

(00:02:02) Иван Иваницкий: Также наш спонсор — Fluence, облачная платформа на базе децентрализованной инфраструктуры. Она даёт более дешёвую и отказоустойчивую альтернативу традиционным облачным решениям вроде AWS, Digital Ocean или Hetzner. С помощью Fluence вы получаете доступ к глобальной сети независимых провайдеров, можете быстро запускать виртуальные серверы и разворачивать рабочие нагрузки по всему миру, при этом значительно снижаете расходы и не зависите от одного провайдера.

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

(00:03:03) Иван Иваницкий: Ещё наш спонсор — 1inch: сервис обслуживает 23 миллиона пользователей и проводит свыше 1 миллиарда сделок в сутки в долларах. Свежая аналитика The Block показывает, что у сервиса около 60% всех объёмов DeFi-агрегации. 1inch уже даёт выгодные обмены в Ethereum, Solana, Optimism, Avalanche; кроссчейн с Solana выйдет скоро. Хотите встроить это в своё приложение — все API ждут вас на 1inch.dev. Для личного пользования есть мобильный кошелёк с вашими ключами и удобный мониторинг активов в портфолио. Заходите на 1inch.io. И помимо этого я хотел бы поблагодарить наших патронов на Patreon и Boosty.

(00:03:42) Иван Иваницкий: На этом перейдём к разговору. Передаю слово Сергею для блока технических вопросов.

(00:03:51) Сергей Тихомиров: Да, спасибо, Иван, спасибо, Митя, что снова зашёл к нам в гости. Мы уже записывали выпуск номер 140: для тех, кому интересны история и ранние этапы карьеры Мити, можно послушать тот выпуск. Прежде всего поздравлю вас с запуском Mainnet. Расскажи в двух словах, всё ли прошло так, как запланировано — дальше мы углубимся в технические детали того, что вы запустили.

(00:04:14) Митя Горошевский: Да, прошло всё, конечно, с приключениями — вообще не так, как запланировано. Запланировано было запуститься ещё 29 февраля. Мы очень долго закрывали финансирование, продавали ноды. Фонды мы в принципе привлекли до февраля, но оставалась вся документация, которую нужно было закрыть, подписать и так далее. А потом началась отдельная история. Мы продавали ноды и токены, у нас такой прям super fair launch, поэтому нужно было соединить покупателей с провайдерами, они должны были засетапить себе ноды — вся эта инфраструктура. Инфраструктура в Acki Nacki — отдельный огромный пласт, совсем не так просто, как в медленных блокчейнах, и это тоже был отдельный цирк, который занял буквально полгода, когда деньги уже были у нас и всё было подписано. После этого началось самое интересное. Но мы прошли через это. Мы запустились с 250 с чем-то нод на трёх континентах в разных дата-центрах — реально децентрализованная сеть. Наша инфраструктурная команда отработала на пятёрку с плюсом. Средняя финализация в сети — 750 миллисекунд на протяжении всего этого времени; скоро будет два месяца, и с точки зрения инфраструктуры не было никаких сбоев. В этом плане всё прошло замечательно.

(00:05:53) Сергей Тихомиров: Я буду вплетать в свои вопросы вопросы слушателей из ББ-чата. Спасибо большое тем, кто оставил вопросы. Один из них: сколько сейчас пользователей в сети — ежедневных активных, ежемесячных активных — и как вы планируете наращивать пользовательскую базу.

(00:06:04) Митя Горошевский: Мы метрики ведём немного по-другому. Нас сейчас не так интересует «мало пользователей», потому что главное было, чтобы сеть стабильно работала и все сервисы были как надо. Мы особо не пушили. Думаю, у нас где-то в районе 20 тысяч пользователей — нет, не неактивных: все активные — это майнеры, которые сейчас майнят. Два миллиона контрактов задеплоили в сеть. Средний TPS что-то в районе 30, практически не падает; пустых блоков почти не бывает. Это вся пользовательская активность, другой нет. Помимо этого есть пользователи из коммьюнити, которые до сих пор не конвертировались в кошельки, потому что установка кошелька как отдельного приложения для большинства — практически неподъёмная задача. Пользователи, которые у нас были изначально, — не совсем типичные крипто-пользователи. Последний год мы как раз привлекали массы пользователей, которые до того к крипте не имели отношения — отдельный интересный experience. Сейчас вторая серия: как сделать из этих людей настоящих пользователей крипты. Они пользователи приложения, в котором говорится про крипту.

(00:07:30) Сергей Тихомиров: Можешь на high level описать позиционирование Acki Nacki — для кого вы это делаете и как это соотносится с другими блокчейнами. У меня сейчас немного конфликтующее представление: с одной стороны вы ориентируетесь на простых ритейловых пользователей, которые, может быть, вообще не знали про крипту, а с другой — у вас партнёрство с Oracle, обсудим потом, что именно имеется в виду. Как будто фокус и на корпоративный мир.

(00:07:54) Митя Горошевский: Наш тезис в том, что технология блокчейна не дошла до maturity, до цикла, в котором мы можем сказать «окей», как с базами данных. У нас есть база данных, она очень хороша для каждого конкретного кейса, который у нас есть сейчас. Действительно есть сотни баз данных под каждый юз-кейс, и в каждом из них они доведены до не то что теоретического максимума, но мы где-то уже mature: увеличить производительность для этого кейса в два, три, пять, десять, сто раз будет очень сложно. В блокчейне мы были далеко от этого состояния. В продакшене, если говорить про децентрализацию, там не две тысячи, а три тысячи — такие цифры у Solana и так далее. Задача, которую мы решали, — сделать блокчейн настолько быстрым, чтобы мы не могли его очень быстро и очень просто ещё ускорить, чтобы это был какой-то предел развития в рамках hardware, производительности и пропускной способности сети. Вопрос в том, какие приложения и для чего такое нужно до следующего момента. Поэтому просто отвечать «это для корпоратива» и делить так — мы не делим: юз-кейсы, где нужна большая производительность, есть и там, и там, и ещё где-то. Для всех этих юз-кейсов Acki Nacki — лучший блокчейн. Мы разговариваем и с корпоративными клиентами через тот же Oracle, которые прямо сейчас упираются в производительность. Есть supply chain приложения, закрытые, о которых никто не слышал и не видел, но они существуют, и там, например, нужна производительность от 50 тысяч — и буквально никто не может этого дать, ни одна блокчейн-технология, кроме нас. Мы разговариваем с этими кейсами. Если с другой стороны взять игру для ритейла, то никакую real-time игру на блокчейне сегодня вы тоже не сделаете без такого блокчейна, как Acki Nacki. Объединяются эти кейсы одним: и там, и там нужна производительность.

(00:10:23) Сергей Тихомиров: Сюда вплету вопрос слушателя. Для меня он звучит загадочно, но, может, ты прольёшь на это свет. Почему было выбрано позиционирование Acki Nacki как «второго Bitcoin»? Это правда? Что имеется в виду, как ты думаешь?

(00:10:36) Митя Горошевский: Да, я знаю, что имеется в виду, потому что наша токеномика — попытка смоделировать proof-of-work на proof-of-stake. Как было до сегодняшнего дня: возьмите любые токеномики proof-of-stake блокчейнов — они брали, даже Solana взяла curve выпуска монет Bitcoin, более или менее похожий, и на этом всё останавливалось. Не было попытки сказать, что наш токен должен быть ультимативным store-of-value, и для этого повторить токеномику Bitcoin — просто потому что в токеномике Bitcoin есть вещи, которые в proof-of-stake очень трудно симулировать. Возьмём расход на электричество. Это дилемма, которая постоянно есть у майнера Bitcoin: продолжать майнить в убыток или остановить майнеры. Покупка майнеров — вложение, которое нельзя, как в proof-of-stake, вложил стейк, вынул, тут же продал и вышел. Попробуйте продать ASIC'и и всё оборудование, которое уже два года майнило — тяжёлый рынок, не пошёл за угол и не продал за две секунды. Это часть экономики Bitcoin. Если взять Bitcoin как токеномику, это самая успешная токеномика, более успешной у нас нет, потому что измеритель успеха токеномики — рост цены. Как меня учили, в конце любой экономической задачки всегда стоит цена.

(00:12:20) Сергей Тихомиров: Если считать, что изначально цена всех этих токенов была ровно ноль, то рост до любого ненулевого значения — это рост в бесконечное число раз.

(00:12:25) Митя Горошевский: Конечно, мы можем сравнить цену Bitcoin за какой-то период с ценами других криптоактивов за тот же период. Можно сравнить капитализацию, можно сравнивать разные вещи. Но у нас сегодня по кейсу даже капитализация — самый простой показатель. Мы далеко ушли: Bitcoin — успешный кейс, а про всё остальное я не уверен. Пока нет уверенности, потому что если взять достаточно большой период, лет десять, я не знаю, насколько этот кейс уверенный. Чем это сильно отличается от какого-нибудь другого distressed-актива? Какая цена на какой-нибудь токен — какой там вообще кейс, commodity это или utility, что это такое и зачем нужен? Поэтому все пытаются позиционироваться: Ethereum сейчас пытается позиционироваться как settlement layer. Вроде они последнее время от world computer перешли к settlement layer. Какой-то странный манёвр был, может, это не имеет большого значения. Но если вы анализируете сравнение Bitcoin с Ethereum, юз-кейс у Ethereum понятен — DeFi и всё, что с этим связано. Но токеномика Ethereum такова: где основание полагать, что цена Ethereum вообще будет расти или куда она будет двигаться?

(00:13:29) Сергей Тихомиров: А в Bitcoin такого основания полагать нет. Вот там недавно вроде упал.

(00:13:33) Митя Горошевский: Раз вы сейчас говорите про то, что курс меняется — как это по-русски называется — это не проблема. Вы же берёте большой отрезок времени. Надо брать на большом отрезке.

(00:13:48) Сергей Тихомиров: В этом контексте как Acki Nacki себя позиционирует?

(00:13:50) Митя Горошевский: Мы просто взяли Bitcoin и попытались смоделировать Bitcoin-токеномику на proof-of-stake. Это пятьдесят страниц токеномики с достаточно непростой математикой, потому что задача оказалась очень сложной. Просто взять и перенести Bitcoin proof-of-work на proof-of-stake токеномику оказалось очень тяжёлой задачей. Реально мы бились год, но сделали всё, что могли, чтобы это произошло. Вы должны найти аналогичную дилемму, аналогичную Bitcoin-майнеру, в proof-of-stake системе. Это непростая задача.

(00:14:25) Иван Иваницкий: Если не закапываться во все подробности, но сказать конкретно про ту особенность, что майнер Bitcoin покупает оборудование, которое ему потом трудно будет продать — как вы симулируете эту вещь?

(00:14:40) Митя Горошевский: Мы пытались найти аналогию экономических механизмов. Например, у нас есть понятие min stake. У нас есть понятие количества нод, которые нужны в сети, которое можно взять из load, может быть, фактора децентрализации плюс фактора необходимых компьютерных ресурсов для сети. Потому что наша сеть нелинейно масштабируется: чем больше транзакций нужно произвести, тем больше компьютеров нужно в сеть. Это мы добились за счёт нашего суперэффективного протокола консенсуса. Поэтому в сети мы можем понимать, сколько нам нод нужно в данный момент времени. Из этого мы можем построить оптимальную цену, оптимальный min stake — минимальный stake, который нужен, чтобы начать майнить. Дальше нам нужно создать дилемму, где ты всё время спрашиваешь себя: я продолжаю майнить или нет? В обычных proof-of-stake это никак не делается. Ты можешь майнить любым кусочком стейка. Если надо, можешь продать пять процентов своего стейка и продолжать майнинг девяноста пятью процентами. Мы попытались сделать так, что если ты выходишь, ты выходишь целиком, частично выйти нельзя. Это пример одной из таких механик. Таким образом мы создаём дилемму: я хочу продолжать майнить — я должен весь стейк держать в сети. Это достигается за счёт компрессии free float. Минимальный stake очень близко расположен к curve намайненных токенов. Твой stake: если бы ты продолжал майнить всё это время, ты бы набрал stake, который тебе хватает до минимума, но у него почти нет сверху headroom, который можешь продать, сохранив min stake. Этот min stake всё время растёт вместе с увеличением числа токенов. За счёт этой линии компрессии мы всё время сохраняем дилемму: да, ты можешь продать больше, чем этот free float, но free float очень узкий — тебе хватит, возможно, заплатить за сервер, а всё остальное, что ты накопил, ты решаешь каждый раз: хочешь выйти — пожалуйста, но тогда целиком. А это значит, что чтобы зайти заново, тебе нужно будет купить stake, который уже больше, потому что min stake растёт всё время. Следующую минуту тебе уже нужно будет купить больше stake, чтобы зайти в майнинг.

(00:17:08) Сергей Тихомиров: Можешь, пожалуйста, рассказать про историю проекта: есть ли у него какая-то связь с TON, FreeTON, или это полностью с нуля всё новое?

(00:17:18) Митя Горошевский: Связь есть. Во-первых, я в этот проект пришёл из TON, из FreeTON. Я был CTO TON Labs до того, как начал GOSH. Потом ушёл из TON Labs и создал GOSH. GOSH изначально был проектом git-on-chain — смарт-контракты, которые изначально бежали на форке Everscale; FreeTON можно считать TON, неважно. Если брать историю консенсуса Acki Nacki, основной механизм этого консенсуса я предложил четыре года назад, ещё когда работал в TON Labs. Я его предложил — там такой кусочек, но это был прям core. У меня даже есть аудиозапись, где я первый раз презентую эту идею. Изначально это было сделано, чтобы увеличить безопасность в сети TON. Это не был полноценный консенсусный алгоритм, это был некий гаджет, который можно было навернуть сверху masterchain TON и таким образом увеличить безопасность всех этих чейнов, threads — назовите как хотите. Суть в том, что у них проблема с безопасностью, потому что там очень маленький subset участников в каждой из них, и её легко сломать. Эти threads TON очень легко ломаются — probabilistically. Если у вас нода попадает при определённом количестве нод, которое у вас есть как у члена сети, вы достаточно быстро можете оказаться в сообществе только из ваших нод и просто подделать транзакцию. Чтобы улучшить это, TON сделал свои гаджеты. Я предложил такой механизм. Этот механизм был положен в основу консенсуса на четыре года. Когда мы уже перешли и стали делать GOSH, я вернулся к этой теме, потому что мы очень быстро легли на форке: git-on-chain — вы загружаете репозиторий какого-нибудь большого проекта, условно Ruby, и сеть встаёт, потому что там сорок миллионов объектов, и привет. Не было блокчейна, который мог бы для такого юз-кейса — просто не существовало блокчейна, кроме Acki Nacki, который может это сделать. Я тогда вернулся к этой идее, и да, мы доработали её до состояния полноценного протокола консенсуса. Если брать core, основу идеи Acki Nacki, она такая: можем ли мы взять механизм консенсуса, который используется не в BFT, а в кластерных базах данных, например Raft? Raft на самом деле очень простой. Есть лидер, который посылает всему своему кластеру сообщения, они просто применяют их, и дальше, если лидер не посылает сообщения в течение определённого времени, выбирают другого лидера. У них очень быстрая смена лидера, и они начинают принимать сообщения от другого лидера. Это не BFT, понятное дело, потому что вы доверяете этому лидеру. Но тем не менее это такой протокол — более того, сокращение синхронизации кластера. Вопрос: можем ли мы создать протокол консенсуса в блокчейне, который будет децентрализован, который будет BFT, но работать приблизительно так же эффективно? Это задача, которую я ставил лично перед собой. Грубо говоря, можем ли мы взять Raft-подобный механизм и сделать его BFT?

(00:20:45) Сергей Тихомиров: Когда ты говоришь «сделать его BFT», имеется в виду сделать так, чтобы он работал в недоверенном окружении: мы делаем допущение, что у нас не более одной трети узлов злонамеренные, и при таких условиях они, сговорившись, не могут нам сломать консенсус. Тогда как Raft вообще не рассуждают в терминах злонамеренности узлов — там максимум может быть offline, кто-то вышел.

(00:21:07) Митя Горошевский: Совершенно верно. Он не BFT, он поддерживает liveness. Тут немного сложнее, потому что ты сейчас уже сказал про одну треть и всё такое. Эту одну треть ты на самом деле тащишь из классического BFT — Лэмпорта и всё остальное. Потому что мы привыкли как инженеры в computer science разговаривать в детерминизме. В терминах детерминизма Acki Nacki — это не детерминированный протокол, это probabilistic протокол консенсуса. Поэтому у нас нет таких constraints, ограничений, как одна треть. У нас нет таких ограничений, как все эти одна треть, две трети и так далее. Мы можем, поскольку это пятьдесят один процент, он просто доказывается: грубо говоря, если у вас меньше пятидесяти одного процента, то скорее всего не правы вы. Поэтому пятьдесят плюс один процент — это естественное просто большинство. На Bitcoin же тоже пятьдесят один процент консенсус в целом, и он тоже не детерминирован, он тоже вероятностный, как Acki Nacki. Нельзя сделать детерминированный протокол консенсуса за определённое количество шагов коммуникации, обмена сообщениями. Есть доказательства, есть теорема из доказательств. Поэтому если вы хотите снизить это количество шагов, а это была наша задача, вы никак не можете оставаться в территории детерминизма, вы должны двигаться в сторону вероятности. Остаётся только вопрос: с какой вероятностью вы готовы жить, и всё.

(00:22:52) Сергей Тихомиров: Уточняющий вопрос. У меня было такое представление, что когда мы находимся в мире блокчейнов, у нас всё в общем-то вероятностное. Даже те протоколы, которые построены на базе BFT, они всё равно навешивают сверху взвешивание по стейку или что-то такое, и в итоге всё равно где-то бросается какая-то случайная монетка, чтобы выбрать валидатора, который произведёт блок, и так далее. Почему вообще имеет смысл смотреть на детерминистичные консенсусы в блокчейн-мире? Как будто бы все блокчейны недетерминистичные по своей природе, или я где-то не прав?

(00:23:28) Митя Горошевский: Сергей, вы не просто не правы — вы сто процентов правы. Именно это мы прямо пишем в статье: на самом деле вся эта история с детерминизмом абсолютно надумана по двум причинам. Во-первых, то, что вы сказали: все протоколы, proof-of-stake, неважно что вы берёте, по своей сути не являются детерминированными, на которых тем не менее вы строите свои аксиомы. Это первое. А второе — извините, вы используете криптографию, а криптография, которую вы используете, как мы знаем, вероятностная. Если вы используете вероятностную криптографию, зачем вам детерминизм на уровне консенсуса? Если эта подпись валидатора уже сама по себе не детерминирована — скажите, зачем этот бред, зачем гнаться за этим идиотизмом, простите, BFT-консенсусов, PBFT-family консенсусов, которыми абсолютно все, ну не девяносто девять процентов, блокчейнов proof-of-stake этой ерундой занимаются? При этом у этого нет никакого основания. Вообще не нужно — просто надо выкинуть, и всё, что мы сделали.

(00:24:34) Сергей Тихомиров: Перейдём, наверное, ближе к описанию Acki Nacki и как он работает. Мне кажется, имело бы смысл описать в начале, какие роли есть в протоколе, потому что в вашей документации написано, что у вас как минимум три перечисленные роли: блок-продюсер, блок-кипер и verifier. Расскажи подробнее: что это за роли, почему они разные и как они складываются вместе.

(00:24:50) Митя Горошевский: Очень простой протокол на уровне, когда всё идёт хорошо. Когда всё начинает идти не очень хорошо, он начинает быть очень сложным. Останемся пока на первом уровне. Представим, всё идёт хорошо. У вас такой же setting, как я сказал: есть кластер нод. Есть ноды, кто-то кто продюсит блоки. Обычно в протоколах консенсуса пытаются ротировать блок-продюсера, sequencer — назовите как угодно, чтобы он не стал malicious, чтобы вероятность того, что он станет malicious, уменьшалась, и так далее. А мы сказали: нет, так мы не будем. Если мы будем всё время ротировать блок-продюсера, мы стреляем себе в ногу. Ротировать блок-продюсера — дорогое удовольствие, блоки не могут выходить так часто, как мы хотим. А мы пускаем блоки каждые триста тридцать миллисекунд. Поэтому мы сделаем как в Raft: у нас будет постоянный блок-продюсер, и пусть он будет malicious. Представим блок-продюсера, который хочет быть malicious. Он посылает блоки какому-то набору всех остальных нод, блок-киперам. Теперь нам нужно сократить время, которое блок-кипер вернёт, сократить количество сообщений. Потому что в обычном BFT получающие блок дальше начинают пересылать друг другу сообщения, чтобы договориться: мы принимаем этот блок или нет. А у нас они ни о чём не договариваются. Они просто посылают, если по определению принимают этот блок, если он проходит простые проверки. То есть он действительно является блоком от хэша предыдущего блока и так далее, включается Merkle tree. Вот они проверили, что он включился в Merkle tree.

(00:26:26) Сергей Тихомиров: Вот эта проверка — она включает в том числе исполнение транзакций?

(00:26:28) Митя Горошевский: Нет, это важный момент: речь не только про headers. Если по headers всё сошлось, они посылают Ack обратно тому же malicious блок-продюсеру. Они даже не шлют их друг другу — только ему, первое и второе сообщение. В этот момент происходит ещё одна вещь. Когда они получают блок, каждый для себя на основе своего приватного BLS-ключа быстро считает функцию от хэша блока и выясняет, кто из них должен проверить транзакции этого блока. Того, кому выпала монетка проверять транзакции, называют Acki Nacki — от Ack, acknowledgement, и not acknowledgement. Если монетка выпала ему, блок-кипер становится Acki Nacki: он проверяет блок, и если в блоке всё ok, посылает Ack обратно так же; если не ok — посылает Nack всем.

(00:27:26) Сергей Тихомиров: Уточни по терминологии: блок-кипер — это сейчас все они? Все являются блок-киперами?

(00:27:31) Митя Горошевский: Все блок-киперы, никто не говорил, что один. Там есть рандомная функция — подмножество. Оно может быть и нулевым: есть вероятность, что никто не проверит блок. На чём вообще основана security-гарантия безопасности? На том, что блок-продюсер никогда не может узнать, кто из блок-киперов и сколько из них станут вериферами следующего блока. Он не может намайнить блок, в котором детерминированно манипулировал бы тем, проверит кто-то его транзакции или нет. Он может только подкинуть монетку и выпустить malicious-блок. Дальше вероятность того, пройдёт ли этот блок верификацию, зависит от формулы рандома — грубо говоря, по модулю делим оставшихся блок-киперов и смотрим, кто станет baseline Acki Nacki. Всю статью мы доказываем security properties на основе анализа вероятностей. Нужно, чтобы другие ноды сговорились с этим malicious блок-продюсером: если он один, это бесполезно — все звёзды превратятся в чёрные дыры быстрее, чем он найдёт блок. Сколько ему нужно сообщников и при какой вероятности выпадения Acki Nacki с большой вероятностью его блок не пройдёт эту верификацию? Это всё параметры сети — вы можете их выставить сами. Блок-киперы в любой момент выставляют, с какой вероятностью они хотят, чтобы сеть работала безопасно. Можно выставить любую вероятность — такую, чтобы за всё это количество лет malicious-блок не прошёл: все вериферы попали бы только в его subset сообщников, как мы говорили про солнце и чёрную дыру.

(00:29:32) Сергей Тихомиров: Идея мне кажется более-менее понятна. Единственное, чего я не понял в твоём объяснении: ты говоришь, блок-кипер выбирает вероятность — они все выбирают одну вероятность или каждый для себя?

(00:29:53) Митя Горошевский: В конце концов все выбирают одну вероятность. Вероятность допустимой атаки — характеристика сети, property, которое вы выставляете в сеть. Все блок-киперы договариваются, с какой вероятностью они хотят работать сейчас. Чем меньше вероятность атаки, тем больше вериферов нужно.

(00:30:10) Митя Горошевский: В среднем, опять же в среднем. Это значит некое замедление. Дилемму безопасность против скорости постоянно решает блок-кипер. В пределе можно сделать сто процентов.

(00:30:20) Сергей Тихомиров: И тогда это будет означать, что ни один блок не пройдёт непроверенным — все проверят.

(00:30:25) Митя Горошевский: Всеми, да. В пределе атака тогда детерминированно невозможна. Как только вы уменьшаете этот параметр, вы естественно повышаете вероятность атаки. Мы считали, условно, 49 процентов malicious при определённом общем количестве нод и сколько нужно вериферов для такой-то вероятности. Это работает ещё и потому, что важно отметить: когда блок считается финальным? Есть второй параметр. Блок финален, когда блок-продюсер получил определённое количество аттестаций — процент аттестаций. Когда блок-продюсер получает...

(00:31:05) Сергей Тихомиров: Аттестации — то же самое, что Ack?

(00:31:08) Митя Горошевский: Да, но аттестация верифера здесь не имеется в виду. Это аттестации, что блок получен и header у него правильный, которые все блок-киперы посылают блок-продюсеру. Как только вы получили нужное количество аттестаций — снова параметр сети, например 60, 40, 50 процентов, но меньше 50 невозможно, или 75 процентов — он включает все аттестации в следующий блок и посылает его; в нём есть аттестация на предыдущий. Он собирает и каждый раз высылает. Как только у блок-продюсера набирается количество аттестаций, нужное для финализации, он финалит этот блок.

(00:31:44) Сергей Тихомиров: Правильно понимаю: когда мы говорим про любые проценты, здесь имеем в виду взвешенные по стейку?

(00:31:48) Митя Горошевский: Нет, здесь только ноды.

(00:31:50) Сергей Тихомиров: Что мешает запустить миллиард нод?

(00:31:51) Митя Горошевский: Min stake.

(00:31:52) Сергей Тихомиров: То есть они не взвешены по стейку.

(00:31:53) Митя Горошевский: Но их всё равно не допустят просто стать нодами.

(00:32:01) Сергей Тихомиров: Ещё вопрос, не знаю, насколько релевантен. Каждый раз, когда речь про то, что мы рандомно выберем подмножество узлов для валидации, у меня вопрос: какой источник рандомности и можно ли им манипулировать. Помню, на нашем подкасте мы разбирали статью про RANDAO и атаки на RANDAO в Ethereum — там показывали, что рандомность можно сдвигать при некоторых условиях. Правильно ли, что здесь источник рандомности — BLS-подписи? Вообще верна ли такая аналогия?

(00:32:33) Митя Горошевский: У нас нет общего рандома. Важно именно это: каждый валидатор, каждый блок-кипер принимает решение для себя на основе своего приватного ключа и рандома, который он сгенерировал. Никакого общего рандома — мы не договоримся о рандоме. Понятно, что валидатор, когда генерирует ключи, берёт рандом откуда-то. В ноде стоят стандартные, достаточно хорошие локальные алгоритмы для этого рандома, но при желании можно поставить рядом небольшой урановый реактор или что-то в этом роде.

(00:33:14) Сергей Тихомиров: Я пытаюсь понять, имеет ли смысл кому-либо в системе перебирать ключи, перегенерировать их, «майнить» айдишники, чтобы чего-то добиться. Возможно ли такое направление атаки или нет?

(00:33:33) Митя Горошевский: Я этого не вижу — это как перебирать ключи для вашего приватного кошелька. Можно, наверное, но есть ли вектор атаки? Есть, если вы пользуетесь очень плохим алгоритмом. Если мы говорим про современную криптографию, и если сейчас особенно оставить за скобками последние хайпы Виталика про квантовый компьютер и всё прочее, я не вижу здесь вектора атаки. Опять же, всё происходит дискретно: каждый выбирает для себя, генерирует для себя, нет RANDAO, нет совместных определений рандома.

(00:34:11) Сергей Тихомиров: Насколько я понимаю, атака, от которой мы защищаемся, — это когда блок-продюсер кладёт в блок заведомо невалидную транзакцию; это понятно, как проверить. А защищаемся ли мы от цензурных атак? В классическом консенсусе, скажем, в Bitcoin и, видимо, в Ethereum с proof-of-stake, есть ещё не менее важный, как мне кажется, аспект безопасности: блок-продюсеры, как их ни называй, ротируются, и поэтому сложно последовательно держать цензуру на длинном отрезке времени. Как вы к этому подходите?

(00:34:45) Митя Горошевский: Начнём с того, что у нас они не «никогда не ротируются». Как в Raft: если лидер перестаёт работать или по другим причинам сеть решает больше не принимать от него блоки, его легко сменить. Ротация у нас и так периодически происходит сама по себе, просто иногда бывают сетевые задержки и прочее. Но вот ротация ноды в протоколе консенсуса — защищает ли она вас от цензуры и от какой именно? Это цензура в вакууме, когда без объяснения причин нода вдруг решила кого-то отфильтровать?

(00:35:21) Митя Горошевский: Давайте спросим: зачем она это делает? Почему вообще решила кого-то цензурировать? Наверное, потому что с этим связана выгода. Какая? Например, она производит блок для какого-нибудь DEX и может взять сообщения, которые «не пришли», сделать MEV, в этот MEV ещё и sandwich-атаку — почему бы нет? Вот с этим и борются многие консенсусы: по сути дают ей возможность провести только одну sandwich-атаку.

(00:35:52) Сергей Тихомиров: Согласен, это возможный и, скорее всего, более релевантный на практике сценарий. Но я вижу и другой — в духе того, что наше правительство добавило в санкционный список какую-то страну или организацию, а наша нода работает под юрисдикцией этой страны, и мы не хотим портить отношения с властями. Хорошо бы иметь в запасе другие ноды, которые смогли бы подтвердить такую транзакцию, если она по правилам протокола валидна.

(00:36:17) Митя Горошевский: Вы выпускаете блок в Ethereum, сидите где-нибудь в Иране — от того что протокол запретит вам цензурировать, вы перестанете? Нет: вы просто не выпустите этот блок, скажете «я не буду выпускать этот блок» или «не буду включать эту транзакцию». Протокол не спасает от цензуры на конкретной ноде. Это, правда, довольно надуманная конструкция, как мне кажется. Есть распределённая сеть. Транзакции в неё тоже как-то попадают — как, например, в Ethereum? Они что, сразу идут к sequencer? Нет: сначала часто в Infura. Давайте посмотрим: не станет ли Infura первым пунктом цензурирования, прежде чем транзакции вообще дойдут до блок-продюсера?

(00:37:10) Сергей Тихомиров: Справедливое замечание. А в Acki Nacki как они попадают?

(00:37:14) Митя Горошевский: В Acki Nacki — через блок-менеджеров; мы первые, кто добавил RPC-ноду в консенсус именно из-за этого. Есть отдельный тип нод — блок-менеджеры: по сути индексаторы протокола, плюс они доставляют сообщения в сеть. Они подписывают сообщения, которые пользователь хочет доставить, и получают за это 10 процентов награды блока. Это как раз для того, чтобы пользователь, если видит, что сообщение не доставляют, мог сменить блок-менеджера: это не sequencer, любой из них может доставить сообщение в сеть. Что касается практической мотивации sequencer что-то цензурировать — моего первого примера с sandwich на DEX — Acki Nacki решает это отсутствием MEV на уровне протокола. Просто нет MEV, и всё.

(00:38:23) Сергей Тихомиров: Если можно в принципе убрать MEV, почему все так не делают?

(00:38:26) Митя Горошевский: Потому что для этого нужен синхронный блокчейн. В TON, например, с MEV тоже будет сложно — это синхронный блокчейн. Обычно архитектура смарт-контрактов на Acki Nacki устроена так — на TON не буду углубляться: сообщения пользователя идут через его кошелёк в другой контракт. Сначала пользователь шлёт сообщение на свой кошелёк, и только потом из кошелька оно попадает, скажем, на DEX. Пока сообщение идёт на ваш кошелёк, sandwich-атака невозможна: это ваш кошелёк, конкурентов там нет. Когда оно уже на кошельке, дальше оно идёт внутренним сообщением до контракта DEX, а порядок внутренних сообщений менять нельзя — это зашито в протоколе. Там, где мог бы быть MEV, extraction нет; а когда extraction нужен, вы уже не можете его сделать.

(00:39:27) Иван Иваницкий: Примерно в эту сторону хотел задать вопрос не про MEV, а про децентрализацию, соответствие законам и отношения с регуляторами. На сайте есть формулировка — возник вопрос: с чьими конкретно законами и какими, например? Как эти законы требуют децентрализации? И какие технические усилия пришлось приложить, чтобы им соответствовать?

(00:39:51) Митя Горошевский: Конечно, глобальных законов, которые прямо требуют децентрализации, нет — жаль, что Стамбульской конвенции не существует. Но мы знаем MiCA в Европе, американские прецеденты, наш замечательный Tornado Cash и прочие юридические изыски. Если всё это разобрать, вы понимаете: Роман сейчас не сидел бы в тюрьме, если бы Tornado Cash был по-настоящему децентрализован. Это юридический факт. Ребята из Samurai не сидели бы в тюрьме, если бы Samurai был по-настоящему децентрализованным privacy-preserving кошельком. То же с обвинениями, которые SEC в последнее время снимает — да, Трамп и всё такое, но то, что сделали SEC, мне кажется, как раз деполитизировано. Их наезды на протоколы в целом про деполитизацию. Но если взять юридическую основу того, что говорил Генслер — извините за это слово в эфире — «достаточная децентрализация» по правилам вроде 257 или 486: понятие аморфное, но можно говорить о том, какой уровень контроля разработчик имеет над сетью. Когда Bitcoin Core выкатывает апдейт — насколько это «нажали кнопку и сеть побежала», или нет?

(00:42:06) Сергей Тихомиров: Нет. That's the whole point. Каждый обновляется, когда хочет, и совместимость не ломается — в отличие от многих других, правильно?

(00:42:12) Митя Горошевский: Мы идём примерно в том же направлении. Понятно, мы общаемся с валидаторами, выпускаем релизы и говорим: вот software update, поставьте на ноду. Валидаторы обычно ставят, тем более сейчас в апдейтах ничего плохого нет. Но суть в том, что это не как в Ethereum: у нас нет механизма «не поставишь апдейт — будет ой-ей-ей». Не хотят — не ставят. Нас уже посылали: «нет, не буду ставить ваш апдейт, у меня проблемы» — и не поставил. Мы какое-то время жили без этого апдейта.

(00:43:11) Сергей Тихомиров: К месту, кажется, вопрос от слушателя. Цитирую буквально: «расскажите о децентрализации сети Acki Nacki». В Twitter заявляли, что сеть радикально децентрализована, но по IP-адресам нод видно всего несколько крупных кластеров валидаторов. Как это работает? Вы стейкаете партнёров на ноды под вашим управлением?

(00:43:35) Митя Горошевский: Под нашим управлением есть некоторое количество нод, в том числе у дивизиона TVM Labs — ноды некоторых владельцев. Но мы не владеем их стейками: они не делегируют нам стейк, они делегируют нам лицензию — стейки лежат у них на кошельке, право только у них. Здесь стоит точнее объяснить, что такое лицензия. Когда делали node sale и думали с юридической точки зрения, что это такое, решили: это продажа software-лицензии. Как продать лицензию на open source и зачем ей value? Мы сделали так: два года валидаторами могут быть не только те, кто купил стейк — нужно ещё купить лицензию. Мы выпустили 10 тысяч лицензий блоккиперов и 10 тысяч лицензий блок-менеджеров и открыли продажу до запуска сети. Блоккиперов продали пять тысяч. Только с этой лицензией следующие два года можно валидировать. Лицензию можно перепродать, но получить её нужно от нас. Лицензия, под которой существует Acki Nacki, — Business License, через два года она автоматически станет GPL: тогда любой сможет по GPL, купив min stake, запустить ноду, а пока в эти два года — только владельцы лицензии. Лицензии — не NFT он-чейн, который мы выписываем покупателю.

(00:45:20) Сергей Тихомиров: Правильно ли я понимаю, что в ноде технически захардкожен список license id, и каждая нода проверяет, что сообщение от другой ноды подписано нужным license id из допустимого диапазона?

(00:45:32) Митя Горошевский: Не совсем так. Просто без license нельзя поставить stake. License по сути — это кошелёк, и stake можно сделать только с такого кошелька. Если такого кошелька нет, вы не сможете stake.

(00:45:49) Сергей Тихомиров: Знаменитый теглайн, который мы повторяем перед каждым выпуском: консенсус за две итерации. Из сказанного ранее я понял, что две итерации — всё-таки оптимистичный случай. Давай, может, немного поговорим о неоптимистичном: что это и что происходит?

(00:46:08) Митя Горошевский: Когда всё идёт хорошо, блок-продюсер выпускает блоки примерно каждые 330 миллисекунд, получает аттестации, и за секунду или меньше в следующих двух-трёх блоках набирается нужное число аттестаций, и блок финализируется. Тогда ничего не меняется, кроме смены Acki Nacki на каждый блок. Проблема возникает, если блок-продюсер перестал выпускать блоки: его нужно ротировать и понять, кто следующий. Следующий обычно есть, ротация проходит очень быстро, с консенсусом тут проблем нет. Проблемы с консенсусом начинаются, когда большие сегменты нод вылетают: при смене блок-продюсера один продолжает строить цепь для части сети, а для другой части его уже ротируют — получается форк. Один блок-продюсер на одной части, новый на другой, дальше сеть может распасться на множество подсетей, у каждой свой блок-продюсер. Разрулить это — ад. В этот момент включается fork resolution — самая сложная часть таких протоколов. Уже не про скорость, а про гарантии и корректность.

(00:47:53) Сергей Тихомиров: Фундаментально в этот момент нужно провести голосование, взвешенное по стейку: какая ветка правильная. Чтобы провести такое голосование в какой-то форме, нужно много коммуникации между участниками.

(00:48:03) Митя Горошевский: Сергей, я даже не хочу туда ходить. Давайте я приведу простой пример. Мы написали научную работу и подали её по fork resolution в Acki Nacki в начале года, и подали её на блокчейн-конференцию под Springer Nature, тоже из серии computer science. Она прошла ревью трёх или четырёх независимых профессоров computer science, и мы сняли её с публикации, потому что она была неверной.

(00:48:24) Сергей Тихомиров: То есть вы потом сами нашли ошибку?

(00:48:26) Митя Горошевский: Мы нашли ошибку в fork resolution и сняли статью с публикации. Дело не в том, что мы молодцы, а в том, насколько это реально сложно. В итоге мы придумали протокол fork resolution, он правда очень сложный. Я даже не хочу туда ходить, потому что сходу я уже, наверное, все нюансы не вспомню: последнее время этим особо не занимался. Мне самому нужно обновлять там все детали. Механизмы этого мы ещё не публиковали, опубликуем обязательно, в том числе в Springer. Свою работу подадим. Из-за того что мы замотались запуском сети, у нас просто не было времени оформить всё это в виде работы, но мы обязательно это сделаем. В следующем году она наверняка опубликуется в Springer, потому что это нетривиально. Почему нетривиально? Если брать big picture: когда у вас недетерминированный протокол консенсуса, на самом деле, наверное, возможно. Почему никто не сделал это раньше, или почему были трудности? Когда у вас недетерминированный вероятностный протокол консенсуса, перейти к детерминированному — это просто огромная теоретическая проблема. На самом деле это не так просто, как вам кажется. «Ну мы здесь BFT просто применим, две трети, и всё, пошло-поехало»? Да чёрта с два. На этом переходе из Acki Nacki протокола в какой-нибудь PBFT доказать переход просто очень сложно.

(00:49:57) Сергей Тихомиров: Хорошо, тогда больше не буду.

(00:50:02) Митя Горошевский: Можно сейчас разговаривать часа три про это. И на этом...

(00:50:06) Сергей Тихомиров: В моей, по крайней мере, голове блокчейны придуманы для случаев, когда всё не совсем хорошо. Когда всё хорошо, все работают без блокчейнов. В целом суть блокчейнов в том, как он разрешает конфликты и как разруливает ситуации, где что-то пошло не так.

(00:50:22) Митя Горошевский: Ещё раз, очень просто: большинство просто берёт PBFT и всё, потому что PBFT изначально, вы изначально берёте assumption, что у вас, например, форков нет, как в TON. Там нет форков, PBFT, вы не допускаете форков сразу. В чём tradeoff? Tradeoff очень простой. Message complexity, сложность, количество пересылок сообщений в консенсусе вы можете изначально задать таким, при котором ваш fork resolution будет тривиальным. Но девяносто девять процентов времени консенсус работает в нормальном виде, ничего не происходит, никаких форков, а вы оптимизируете под fork resolution. Что вы сделали с точки зрения инженерии, с точки зрения науки? Вы всё сделали замечательно, у вас всё просто, termination, всё работает. С точки зрения инженерной вы сделали консенсус, который работает, которому финальный за три секунды, всё просто. Наш tradeoff заключается в том, что мы оптимизируем консенсус под его оптимистическую работу и готовы сделать титанические усилия, когда всё идёт не так: перевести протокол в детерминированный, разрулить все форки. Пусть это займёт кучу сообщений, пусть в десять или в двадцать раз больше сообщений, чем нужно было бы в обычном PBFT. Но так как время, когда это происходит в сети, раз в год условно, при плохом раскладе, мы готовы на это. Раз в год блок замедлится, пусть даже на полчаса, OK, чтобы разрулить форки. Предположим, всё совсем плохо, и it's fine. А вот tradeoff, когда каждый блок из-за этого на три секунды задерживается, мы не готовы. Вот такая логика.

(00:52:00) Сергей Тихомиров: Нет, она такая немножко сомнительная, потому что блок «правильный» же отвечает в том смысле, что может быть да, а может и не совсем.

(00:52:08) Митя Горошевский: Мы же берём из допущения изначально, что он как раз может быть malicious. У нас все остальные механизмы построены так, что мы не дадим ему быть malicious. А в случае известных сетей там как раз всё наоборот: ты не можешь быть malicious, потому что если ты malicious, остальные механизмы построятся так, что будут только помогать тебе быть более malicious.

(00:52:27) Сергей Тихомиров: Насколько тебе кажется корректной аналогия с эфириумной rollup-centric roadmap, которую мы обсуждали, когда она была на более ранних стадиях: не беда, если у нас sequencer роллапа malicious, потому что если что, L1 нас рассудит, и поэтому мы можем сделать ставку на перформанс на L2, а конфликты спихнуть на L1. Я некоторую рифму в этом вижу.

(00:52:47) Митя Горошевский: Представьте, что есть роллап, который весь насквозь malicious, как Rio de Janeiro, приблизительно фавелы. Вот вы такой роллап в фавелах, где в каждом блоке кто-то пытается что-то malicious сделать. Вы будете пользоваться таким роллапом? Вам поможет то, что через тринадцать минут что-то там на Ethereum скажет: «это было malicious, и вот это тоже было malicious, а кстати вот это тоже было malicious»? У вас роллап будет работать раз в тринадцать минут. Кто-нибудь будет пользоваться этим роллапом? Нет. То есть есть assumption, что все хорошие ребята. Если в этом assumption жить, тогда OK сбрасывать это на Ethereum. Это опять же доведение до абсурда: сеть, в которой нет финализации, а финализация больше чем через тринадцать минут — это хуже, чем в Bitcoin, и значит её просто нет в Bitcoin.

(00:53:35) Сергей Тихомиров: В Bitcoin один блок — это тоже не финализация.

(00:53:38) Митя Горошевский: Вот такая модель у нас. Я не знаю зачем, просто зачем, я не понимаю смысла. В Acki Nacki, пожалуйста, пользуйтесь: финализация у вас есть, sequencer может быть malicious, всё то же самое, только финализация меньше чем за секунду, в то время как там вам надо ждать, ещё на сети отправлять, gas платить что-то через тринадцать минут. Там это через тринадцать минут тоже только...

(00:54:05) Сергей Тихомиров: Предлагаю закруглить разговор про консенсус и немного поговорить про execution. Расскажи про вашу виртуальную машину, языки контрактов, на чём их писать, чем это отличается от других виртуальных машин, с которыми слушатели могут быть знакомы.

(00:54:20) Митя Горошевский: Изначально мы взяли просто TON Virtual Machine. Почему TON Virtual Machine? Потому что это единственная виртуальная машина из более-менее известных асинхронных. Поскольку у нас блокчейн асинхронный, не было ни одной виртуальной машины, которую можно было из коробки взять и использовать, поэтому мы взяли TON Virtual Machine. У нас был уже написанный TON Labs компилятор Solidity для TON Virtual Machine, мы это использовали. Но проблема в том, что TON Virtual Machine ужасно медленная, как и любая виртуальная машина такого плана, в этом смысле она ничем не отличается, они все очень медленные. Нам для самого быстрого блокчейна это немножечко не нравилось. Первое, что мы сделали ещё до запуска: добавили инструкцию в TON Virtual Machine, которая называлась runwasm, что, я думаю, само по себе говорит, что она делает.

(00:55:16) Сергей Тихомиров: Немного подробнее, что и почему это важно?

(00:55:18) Митя Горошевский: Конечно. Мы взяли WASM и из него сделали виртуальную машину, как в своё время Near, и в принципе похоже на Solana, только Solana взяла не WASM, а BPF, Berkeley Packet Filter. Мы тоже думали: Berkeley Packet Filter или WASM, но очень быстро склонились к полному WASM, потому что экосистема больше, это очевидно лучший вариант. Только в отличие от всех блокчейнов, которые используют Wasm так или иначе, они поскольку раньше нас это начали делать, у них не было готовых технологий, пришлось изобретать, им пришлось изобретать велосипеды: газ нужно было подсчитывать по-своему и ещё что-то. Мы взяли стэк Wasmtime runtime, который в принципе всю работу сделал за нас. Он поддерживается огромным коммьюнити и работает очень быстро, практически нативный код. Мне непонятно, зачем сейчас звать RISC-V, это тоже кажется иногда, что Виталик эти идеи просто чтобы задурить голову своему коммьюнити, вот теперь quantum история. Не получается у нас сделать быстрый блокчейн, есть какие-то новые протоколы, новые чего-то, давайте поставим себе странную цель, главное чтобы никто другой этим не занимался. Возьмём RISC-V, почему RISC-V, почему не x86 тогда какой-нибудь, почему не Wasm в конце концов. Нет, мы возьмём RISC-V, или займёмся какой-нибудь эзотерической криптографией, потому что она quantum-resistant, а quantum компьютер наступит буквально на следующий день, чего конечно не произойдёт, и так далее. Ладно, это лирическое отступление. В общем, взяли Wasm, взяли Wasmtime, он отлично работает со скоростью практически нативного исполнения. Для начала просто прицепили: чтобы не писать всю часть, связанную с пересылкой сообщений синхронно, для этого мы используем TVM. Но если вы хотите сделать computation, просто вызываете run Wasm, кидаете туда всё, что нужно считать, оно считается за микросекунды, и привет, возвращаете результат. Следующий этап, который мы сейчас прямо делаем, отчасти объясняет, почему сейчас не боремся за разработчиков, не бежим: «разработчики, скорее-скорее, бегите, пишите контракт». Потому что буквально через достаточно короткое время мы полностью избавляемся от TON Virtual Machine, остаётся только Wasm и нативные адреса. Wasm — это будет отдельный address space, да. TON Machine будет продолжать существовать, мы не будем удалять, зачем, но вы сможете всё сделать, включая address space, который будет работать намного быстрее. Если сейчас на TON Virtual Machine мы можем условно полторы тысячи транзакций в блок, в один тред предположим, просто за счёт неэффективности виртуальной машины и неэффективности хранения стейта, которые есть в TON, вместо этого у вас будет Wasm, который за то же время сделает пятнадцать тысяч операций и пятнадцать тысяч сообщений, там сто пятьдесят тысяч сообщений в одном треде. Производительность увеличивается в разы.

(00:58:34) Сергей Тихомиров: Можно немного побольше рассказать про понятие асинхронности? Для меня не совсем очевидно, что это значит на практике, чем отличается от того же Ethereum или от других существующих блокчейнов.

(00:58:50) Митя Горошевский: У нас может быть много block producer'ов по сути. Каждый BP, block producer, можно так, block producer. Если блоки, которые пускает один block producer, становятся слишком жирными, набиты транзакциями и больше не влезают, выделяется просто новый тред, и другой block producer начинает производить параллельно с ним блоки, и так далее. Так она масштабируется. В принципе это взято из TON, тут такая же архитектура в этом смысле похожая, только всё остальное другое. Эта идея одна у нас, потому что по-другому они делятся и по-другому выделяются, но это неважно. Первая в этой идее, которую Николай Дуров придумал: можете взять и блоки начать пускать параллельно, если у вас кончается место, и отделить их адресами. Это address space. Если вы берёте адреса у Дурова, это совсем просто: берёте весь address space и делите его пополам, за одну половину отвечает один, за другую половину отвечает другой. Соответственно они оперируют только с той частью стейта, которая ложится на выделенные адреса, а кросс между этими половинками — сообщениями. Общение между адресами сделано с помощью сообщений, а эти сообщения могут двигаться между тредами. Я могу в свой блок как block producer включить сообщения моего смарт-контракта в адрес другого смарт-контракта, которым занимается другой block producer. Он прочитает из моего блока это сообщение и обязан включить его в следующий блок, который он делает. И это происходит детерминированно, он не может не включить. Если он не включит, блок будет девалидирован.

(01:00:24) Сергей Тихомиров: Блоки могут производиться параллельно, они всё равно логически выстраиваются в единую цепочку в конце концов, просто их генерация и sequencing происходят. Блок 115 и блок 116 составляются параллельно или нет?

(01:00:34) Митя Горошевский: Нет, они абсолютно параллельны в этом смысле, потому что речь об асинхронности. У вас есть сообщение, которое вы послали, но оно выполнится в следующем блоке: в том же блоке оно не может выполниться, вы его только что отправили. Block producer включит его, когда оно до него дойдёт, и добавит в свою цепочку сообщение к своему контракту изнутри. У сообщения есть логическое время, и он не может включать эти сообщения в произвольном порядке. Всё должно идти именно в этом порядке, пропускать нельзя.

(01:01:09) Сергей Тихомиров: Хотелось бы понять, как у вас устроена оплата за исполнение, кто это делает и как работает газ.

(01:01:17) Митя Горошевский: Одна из вещей, которые мы хотели сделать, — freemium-модель газа. Это когда вы не платите, пока не начинаете забирать дополнительные ресурсы. Я всегда привожу пример AWS: вы заказываете сервер, и на старте вам дают бесплатный instance. AWS может себе это позволить, потому что у него огромный парк кластерных машин, за которые клиенты уже заплатили. Часть мощности всегда простаивает — никто не загружает процессор на 100%, — и эти уже оплаченные остатки AWS отдаёт бесплатно, чтобы привлечь новых пользователей. Когда вы переходите на платный тариф, вы начинаете платить — логично. Мы хотели и сделали то же самое. Когда вы запускаете свою dapp на Acki Nacki, вы ничего не платите за транзакции. Почему? Block space, в который вы встраиваетесь, уже оплачен: валидаторы уже оплатили эти машины. Они обычно покупают железо в собственность, иногда берут cloud и платят раз в месяц. Если в этом block space нет транзакций, мощность просто пропадает — значит, мы можем отдать её вам бесплатно. Когда ваши транзакции заполняют block space и тред хочет splitиться, ему не хватает места, — в этот момент вы начинаете платить. Мы сделали так, что можно заплатить централизованно: есть контракт, куда разработчик может закинуть деньги и оплатить газ за своих пользователей. Плата за газ очень маленькая, потому что всё устроено эффективно. С Wasm это будет буквально как cloud compute, потому что верификация в Acki Nacki идёт у случайного subset'а валидаторов — по сути это не отличается от cloud-кластера, разве что кластер по размеру чуть «ездит»: то пять машин, то три, то две, но это никто не видит. Физически он не тратит больше ресурсов, чем обычный кластер, значит мы можем брать столько же, сколько берёт кластер. Сегодня купить валидаторы для Acki Nacki в cloud стоит примерно 300–350 долларов в месяц. Эти 350 долларов с Wasm дадут вам, не знаю, порядка 15 тысяч транзакций в секунду. Посчитайте, сколько стоит кластер и сколько должен стоить compute — так он и будет стоить. Может быть небольшая наценка за управление нодой, но в принципе: 400 в месяц, разделить на 15 тысяч транзакций в секунду — получите, сколько должна стоить одна транзакция. Это даже не копейки. И в этом была цель Acki Nacki: сделать настолько быстрый блокчейн, который не просто приближает его к обычному cloud compute, а делает практически идентичным. Дальше вы используете его как обычный cloud computer: пишете игры, любые приложения, которые сейчас крутите на кластере, только они будут децентрализованы. Это бонус, а не trade-off «здесь децентрализация, но медленно и дорого, а здесь кластер быстрый и дешёвый, но централизованный». Больше так выбирать не надо: быстрый, децентрализованный и дешёвый cloud — одно звено одной цепи.

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

(01:05:20) Митя Горошевский: Большую. Это как раз звенья одной цепи. Зачем блокчейну токен? По сути для двух вещей. Первое — безопасность: стейк ради безопасности, ваш стейк должен стоить всё больше, идеально чтобы цена стремилась к бесконечности. Второе — оплата газа, то есть компьютерных ресурсов валидаторов. А вот это вы наоборот хотели бы минимизировать, чтобы разработчики пользовались сетью и забивали block space. Теперь скажите: зачем объединять в один токен, если у него две «половинки» с противоположной направленностью? Какой в этом смысл, кто это придумал? Даже в Bitcoin не совсем так: у Накамото нет «газа» в нашем смысле, вы не платите газ. Есть fee с транзакции — доля от суммы; ею хоть как-то можно управлять, процент можно делать меньше. А газ — когнитивный диссонанс. Поэтому эти игры мы играть не будем, сделаем два токена. Один пусть стейкается и даёт appreciation цены, другой сделаем так, чтобы цена при необходимости падала, но в крайнем случае не росла. Первый — NACKL с limited supply, всё как у Bitcoin, им мы стейкаем. Второй — SHELL, им платите за computer resource; мы называем его unstable token или «stable or less». Символ такой — «меньше или равно»: вы всегда сможете купить у протокола 100 токенов за один USDC, а продать — за сколько получится. Раз купить у протокола всегда можно за один USDC сто штук, дороже вы его никому не продадите, максимум — дешевле. Ещё нюанс: мы делаем accumulator-контракт, куда складываются все USDC, заплаченные за этот токен. Они никому не уходят, остаются в accumulator, а им владеют все держатели NACKL. В любой момент вы можете взять свой NACKL — скажем, у вас один процент всех NACKL, — сжечь его в accumulator-контракте и получить один процент USDC, лежащих там, в любой момент времени. Так NACKL обеспечен деньгами, которые люди заплатили за compute, и мы утверждаем, что этот пул будет только расти. Почему? Цена NACKL никогда не будет меньше накопленных USDC — это не имеет экономического смысла. Напротив, будет премиум как у обычной акции, stock-to-flow ratio. Вам никогда не будет выгодно сжигать NACKL, значит USDC в accumulator будет только копиться, и обеспечение NACKL снизу будет расти. Более того, я сделаю prediction: наш SHELL, unstable coin, на самом деле будет стремиться к стабильности. Что для этого делаем: если вы купили SHELL и они вам больше не нужны, можете продать на бирже дешевле — меньше доллара, меньше цента за штуку. А можете положить в тот же пул, который выдаёт SHELL за USDC: когда следующий покупатель придёт за SHELL, первыми за один цент он купит ваши, и вы получите ровно столько же, сколько отдавали. Так вы меняете время на деньги: есть время — рано или поздно вернёте сумму; нет времени — продаёте дешевле.

(01:08:54) Сергей Тихомиров: Отлично. Как вы смотрите на ZK и приватность: используете ли вы ZK, собираетесь ли?

(01:09:00) Митя Горошевский: Поскольку выпуск выйдет уже после запуска нашего DEX, я могу про него рассказать — мы его сегодня всё равно анонсируем. Это и будет ответ на ваш вопрос. Мы запускаем DEX под названием DarkOrderDEX, домен dex.do — полностью приватный order book exchange, впервые в истории. Начнём с settlement layer. У DEX есть ZK-прослойка, по духу похожая на Zcash, только проще: не нужно доказывать Merkle, можно обойтись проще. На текущих блокчейнах у Zcash и других протоколов с private-платежами приходится наворачивать сверху огромную complexity — Merkle-деревья и прочее, очень тяжело доказывать. В Acki Nacki ничего этого не нужно: у нас content-addressable блокчейн, адрес детерминирован, всё становится намного проще. Есть этот ZK-уровень, bridge с Ethereum плюс bridge изнутри Acki Nacki — снова аккумулятор, куда вы заводите, например, средства, которые хотите торговать. Дальше они заходят уже анонимизированно, через shielded-адреса: вы доказываете в ZK, что положили туда деньги, и попадаете в private layer. На этом private layer у вас уже есть средства.

(01:10:43) Митя Горошевский: Дальше — order book контракт внутри Wasm: для каждой пары отдельный Wasm, буквально как у NASDAQ, поэтому скорость будет как у NASDAQ. При этом наш кластер уже больше, чем у NASDAQ: у них около 70 машин, у нас уже 250 — теоретически можем быть быстрее. В order book вы шлёте чанки без владельца, все shielded. Так мы не показываем индивидуальные объёмы — ровно то, что скрывают централизованные биржи. На стакане NASDAQ вы не видите индивидуальных объёмов, только общий объём на продажу и покупку и объём по цене. Индивидуальные объёмы скрываем так же. Плюс скрываем цену стакана. Не через ZKP: с ZKP это практически невозможно и дорого, order book должен работать на уровне микросекунд. Здесь мы используем TEE, но TEE сам matching не проводит, order book не в TEE, мы TEE не trust'им — его может запустить кто угодно. TEE выдаёт специальные метки на цену — это order-preserving encryption. Слышали? Разрабатывался он в том числе с участием Дэна Боне (Dan Boneh) ещё давно: внутри базы данных можно упорядочить приватные данные по размеру. Проблема в том, что все эффективные order-preserving encryption до сегодняшнего дня были дырявые — за малое число запросов на них можно атаковать и раскрыть order. Мы используем чуть другую схему, прямой order-preserving. Когда хотите поставить ордер, обращаетесь в TEE, он выдаёт шифрованную метку вашей цены, и вы идёте в order book с этой меткой. В order book всё происходит моментально, matching тоже — он просто сравнивает цифры. В TEE параметризована модель безопасности: он знает, когда менять эпохи. Как только есть опасность, что вы успеете «сосчитать» цены, эпоха сменится, и следующая метка будет уже в другой эпохе. Трейдеру нужно следить и переставлять ордера, если эпоха кончилась — матчатся они только внутри своей эпохи.

(01:13:40) Митя Горошевский: У этого есть интересные побочные эффекты. Два слова: в том же order book можно делать dark pool'ы — заказать свою приватную эпоху, раздать её своему кругу трейдеров, группе или конкретному counterparty, и не зная цены counterparty договориться о сделке прямо внутри order book, не матча ни с кем другим. Вы не сдвинете цену в стакане, а цену стакана вы вообще не видите — только матчи приватных меток. Откуда хотя бы исторически брать цены для стакана? Как в NASDAQ: трейдер не обязан публиковать цену, но если скажет всю информацию, заплатит меньше комиссии. Всё это чтобы избежать атак, которые мы постоянно видим на децентрализованных биржах. Возьмите Hyperliquid: всё видно, постоянно двигают цену — buy wall, sell wall, куча атак. На нашем DEX такие атаки невозможны. Последнее утверждение: я считаю, что нельзя сделать децентрализованный exchange, который реально конкурирует с NASDAQ или даже с Binance, не обеспечив такую приватность. Нет централизованной биржи, где эта приватность по умолчанию и более того законом не обеспечена.

(01:15:15) Сергей Тихомиров: Круто. Моё дилетантское понимание — поправь, если неправ: по большому счёту мы используем TEE как sequencer в каком-то смысле, для обеспечения порядка событий?

(01:15:29) Митя Горошевский: Нет, потому что ему не важен порядок ваших ордеров, ему важна только цена ордера. Он просто шифрует вашу цену. Больше ничего — это просто шифровальщик. Представьте, что у вас могла бы быть такая приватная функция: в принципе она возможна, это называется indistinguishability obfuscation. Если коротко про IO: в теории IO возможно, но на практике на построение уходят часы, порядка пяти. Если бы IO было доступно в нужные сроки, мы могли бы сделать всё через IO, но поскольку сегодня IO практически недоступно за разумное время, мы используем TEE, чтобы обфусцировать вашу цену, и всё. Это просто выдача метки цены, сервис шифрования цены.

(01:16:19) Сергей Тихомиров: TEE здесь воспринимается как промежуточное решение на пути к ZK, или это не связано с ZK, или ZK этого не может сделать?

(01:16:30) Митя Горошевский: Это невозможно с ZK. Я как раз сказал: это можно сделать в IO. Это можно делать и с FHE, fully homomorphic encryption.

(01:16:38) Сергей Тихомиров: Про FHE у нас был выпуск, слушайте наш архив.

(01:16:40) Митя Горошевский: Все наши криптографы, которые работают над FHE, с бэкграундом PhD в FHE, так что тематика в принципе похожая. Теоретически можно было бы сделать и так, но тогда забудьте про микросекундный execution. Нам нужно конкурировать с NASDAQ, поэтому TEE.

(01:16:58) Сергей Тихомиров: Класс, спасибо. Передаю микрофон Ивану и перенесёмся в более business-oriented мир.

(01:17:05) Иван Иваницкий: Спасибо, Сергей. Начать хотелось бы с пары вопросов про партнёрство: в объявлении про GOSH как спонсора подкаста Базовый Блок мы их упоминаем, и слушателям стоит понимать, что происходит. Можешь рассказать, как выглядит партнёрство с Oracle?

(01:17:25) Митя Горошевский: Изначально мы планировали запускать часть валидаторов в Oracle Cloud, но очень быстро выяснили, что этот cloud нам не подходит. Он и не позиционируется под блокчейн и под наши задачи: весь их cloud заточен под AI, под искусственный интеллект, там ARM. Мы вместе с ними делали сравнительные анализы процессоров AMD, Intel и ARM на их серверах, и результаты нас не впечатлили, поэтому от этой идеи достаточно быстро отказались. Тем не менее они всё время продают наши решения как корпоративные — или, скорее, для government и defense industries — и продвигают Acki Nacki как ультимативное решение для таких задач. Такое партнёрство у нас есть. К сожалению, я не могу рассказывать о нём больше из‑за характера клиентов.

(01:18:31) Иван Иваницкий: Имеется в виду Acki Nacki как технология, а не конкретно тот блокчейн?

(01:18:36) Митя Горошевский: Конечно, Acki Nacki как технология. Хотя не совсем так: некоторые из этих решений требуют open блокчейн. Часть системы, наоборот, хочет валидироваться на публичном блокчейне — показывать ту часть, которая не публична, в виде public attestations. Представь: есть какой‑то закрытый кластер ЦРУ — я не говорю, что мы работаем с ЦРУ, это просто пример — он отчитывается конгрессу. В этом кластере что‑то происходит, они отчитываются в нашем блокчейне, что внутри хранят какую‑то информацию, но наружу нужно отчитываться конгрессу, чтобы была публично доступная информация. Какие‑то метаданные они хотят вынести в публичный блокчейн — тогда они используют публичный блокчейн.

(01:19:37) Иван Иваницкий: Очень интересная тема, раскрывать её дальше, конечно, не будем. Правильно ли я понимаю, что то, что вы изначально хотели сделать на Oracle, вы в итоге сделали с OVHcloud?

(01:19:48) Митя Горошевский: Нет. У нас есть валидаторы на OVHcloud, но большинство валидаторов, включая нас, на собственном железе и в своих дата‑центрах — это несравнимо по деньгам и по безопасности. Один из партнёров — NetX, большой IP exchange: люди продают трафик между ISP, между интернет‑провайдерами. У нас с ними партнёрство: если вы берёте кластер нод Block Keeper Acki Nacki — для одной ноды это бессмысленно, но для кластера — можете запросить подключение к NetX в вашем дата‑центре и получить очень быстрый интерконнект. У нас есть специальное оборудование у валидатора, которое концентрирует и управляет трафиком между нодами. Это примерно то, что Solana, кажется, сейчас тоже начала делать: есть проекты, которые пытаются заниматься инфраструктурой, потому что понимают, что когда все валидаторы сидят в одном дата‑центре во Франкфурте, децентрализации это может вредить. Разнести по разным дата‑центрам у нас долго не получалось: трафик такой, что дата‑центры просто не выдерживают, и деньги, которые ты платишь. Мы решили это на уровне инфраструктуры и партнёрства с провайдерами интерконнектов. Поэтому трафик Acki Nacki, несмотря на огромную пропускную способность, умещается в разумные пределы между дата‑центрами, мы не убиваем каналы.

(01:21:36) Сергей Тихомиров: Тогда какая часть и почему работает на OVH Cloud?

(01:21:42) Митя Горошевский: Я не знаю почему — в принятие децентрализованной сети карман не лезу. Мы давно партнёры с OVH Cloud. Сами мы используем OVH Cloud, но не для валидаторов: для разработки, например. У них самый дешёвый Bare Metal. Не хочу делать рекламу OVH Cloud, хотя они партнёры, и в блокчейне это, наверное, и так все знают. Если вы занимаетесь блокчейном, OVH Bare Metal — не Cloud, именно Bare Metal — одно из лучших решений на рынке по цене и производительности. Отличные серверы, хорошая connectivity, очень вменяемые цены. Но это всё ещё в разы дороже, чем купить refurbish‑сервер и поставить в дата‑центр. Конечно, нужна экспертиза: купить по нормальной цене, настроить, выбрать дата‑центр и так далее.

(01:22:38) Иван Иваницкий: А как выглядит партнёрство с Amper Computing?

(01:22:41) Митя Горошевский: Это часть того же партнёрства. Изначально мы планировали с Amper: работали с инженерами Amper и Oracle над собственным проверочным решением и развёртыванием у них в Cloud. Надо понимать, что все контракты, через которые Oracle нас представляет, — это Oracle. Не секрет, что огромная часть бизнеса Oracle Cloud — работа с государственными структурами, в том числе, но не только. Когда они представляют наше решение, оно естественно бежит на их Cloud. А их Cloud в большой части построен на Amper — не весь, там есть и не Amper. Большую часть держат на Amper, Larry Ellison лично вложился в Amper. Не знаю, продали они уже или нет, вроде собирались продать SoftBank или кому‑то ещё, но суть не в этом. Когда мы активно этим занимались и проверяли в прошлом году, Amper была одним из партнёров: все эти частные решения, которые продаются через Oracle, используют Oracle Cloud для развёртывания.

(01:24:03) Иван Иваницкий: Есть ли ещё какие‑то условно enterprise‑партнёрства, про которые было бы интересно упомянуть?

(01:24:04) Митя Горошевский: Пока что я бы воздержался. Мы много говорили о биодиверсити: есть партнёры в Швейцарии в этой области, у них очень большие клиенты. Просто не уверен, что могу называть названия.

(01:24:20) Иван Иваницкий: Если не упоминать названий, можешь в двух словах пояснить, что такое биодиверсити и что в этом контексте может принести блокчейн?

(01:24:30) Митя Горошевский: Биодиверсити — следующий этап после carbon credit. Тема сильно разгонялась как защита климата, были даже блокчейн‑проекты, но, к сожалению, она почти полностью дискредитировала себя из‑за огромного количества фрода, мошенничества. Делалось централизованно, в основном через пару провайдеров, которые выдавали сертификаты на эти кредиты. Что они там выдавали — это было написано у них в базе данных, и всё. Поскольку это публичный интерес и доверие потеряно, теперь все хотят блокчейн, причём сами приходят и говорят: нам нужен блокчейн. Carbon credit тоже себя дискредитировали и не очень отражают суть борьбы за сохранение природы: чтобы сохранить природу, недостаточно бороться с gas emissions, нужно бороться за природу. За природу как раз и борется биодиверсити: она включает всю биосферу. Берёте участок планеты — лес в Колумбии — и пытаетесь его сохранить: всё, что вы сохранили, против того, что могли бы потерять. Непросто, но у нас леса вырубают под сельхозугодья постоянно. В Румынии, например, находят самый большой, по‑настоящему дикий лес в Европе — по сути единственный такой, один на всю Европу. Тем не менее приходят конгломераты, как везде: фермерские хозяйства предлагают купить деревню, лес, посеять, пожать, а местным работать. Если это не национальный парк — а всю страну парком не сделаешь — разрешения всё равно получают и начинают вырубать. Биодиверсити — когда мы приходим в деревню и говорим: не надо, вы можете заработать на этой земле столько же или больше, просто оставив её как есть, со всей вашей биодиверсити. Но сначала нужно понять, какая у вас биодиверсити. Приезжают учёные с пробирками и начинают измерять: какие цветочки и деревья растут, сколько в почве букашек бегает. Я не шучу — я это лично смотрел. Мы этим занимаемся, надо было как‑то токенизировать. Там тома по триста страниц на какое‑то количество гектаров леса в Румынии, где учёные расписывают всю эту биодиверсити. Всё подсчитано, и на основе подсчёта другие учёные по сути токенизируют: дают количество кредитов на конкретный лес. Чем больше биодиверсити, тем больше кредитов. Поскольку это лес, CO2 emissions тоже компонент. Дальше приходит большая организация, которая что‑то производит и выбрасывает в атмосферу, или строит фабрики. В Англии, например, вышел закон: если хотите построить фабрику где‑то в лесу, нужно купить биодиверсити‑кредитов. Считается не только то, что в лесу, но и что с ним произойдёт, насколько уменьшится биоразнообразие, если почву переведут в сельхозугодья. Эти кредиты идут в зачёт того, сколько вы спасли. Дальше начинается токеномика. Почему блокчейн? Потому что это всё ещё сложнее, чем CO2: CO2 в общем померить проще, его даже из космоса можно, а это из космоса так просто не померишь. Там и датчики сложные, и следить трудно. Целая тяжёлая наука, университеты, учёные. Есть компании, готовые платить. Рынок только зарождается: биодиверсити по объёму к CO2‑кредитам — пока около одного процента, но растёт очень быстро.

(01:28:58) Сергей Тихомиров: Да, спасибо за экскурсию.

(01:29:01) Митя Горошевский: При этом то, что я только что сказал, может быть не совсем правдой: я мог упустить какие-то детали, извините. Я не учёный в этой области и наверняка что-то мог напутать, но в целом картина такая.

(01:29:10) Иван Иваницкий: Да, спасибо. Следующий вопрос связан с другим вашим продуктом. Если я правильно понимаю, их можно разделять на Acki Nacki и GitonChain. Хотелось бы узнать, что это такое и какой сейчас статус. В частности, у нас есть вопрос от слушателя CypherSnake, который звучит так: какая продуктовая модель у GitonChain, есть ли у команды видение того, что именно может заставить разработчиков пересаживаться на него, учитывая что баны GitHub носят точечный характер, чем это отличается от идеи условного Codeberg, открытой альтернативы GitHub, именно как продукт, а не как tech stack.

(01:29:48) Митя Горошевский: Давайте так: любые баны носят точечный характер, возможно, в том числе потому что есть альтернативы, в которых вас никто не забанит. Вам так не кажется? Если бы их не было, возможно, баны были бы совсем не точечными. Мы это наблюдаем, например, в банковской области: вам просто может не открыть счёт ни один банк, потому что вы «какой-нибудь не такой». Вы занимаетесь криптой — и привет, счета нет. Почему? Потому что все банки в сговоре, причём в официальном, через центробанк или другую контрольную организацию. Спустили разнарядку: cryptocurrency — нет, и всё. Если бы не было блокчейна и крипты, чем бы вы занимались дальше? Может быть, мы видим обратную картину: банкам «дают по голове», и это возможно происходит потому, что у вас есть cryptocurrency. Все знают, и тот же центробанк знает: если вы не будете открывать счета, люди уйдут в крипту. Насчёт цензуры и «точечного» характера вопрос двоякий — и о том, чем он вызван. Что касается статуса проекта: сейчас он не развивается, потому что мы заняты. Но у нас, как я уже говорил, около сотни инженеров; всё существующее бежит на своей собственной сети, она абсолютно централизована, мы просто поддерживаем проект, чтобы не закрывать его. В какой-то момент, когда дойдут руки, перенесём его на Acki Nacki. Почему? До этого вы этим проектом по сути не могли пользоваться: он был очень медленный, фото нормально не загрузить, работать как с GitHub было невозможно. А теперь внимание: у нас блокчейн работает как дата-центр, base cloud cluster. В нём вы разворачиваетесь. Посмотрим: если не будет никакой разницы между GitHub и полностью децентрализованным git, в отличие от протокола, которому вы должны поверить, который бежит на каких-то серверах, непонятно, бегут они или нет и когда перестанут, и всего того, что сейчас даётся как альтернатива GitHub, пусть и приятная, — тогда, может быть, появятся люди. Для нас этот проект идеологический: мы не собираемся на нём зарабатывать. Нам изначально кажется, что нельзя нормально разрабатывать блокчейн на централизованном git. Децентрализованный блокчейн, децентрализованная инфраструктура и централизованные апдейты из кода на git, даже при всех наших хэшах, не выглядят хорошим и даже приемлемым решением. Поэтому мы обязательно сделаем хотя бы то, чтобы software сети Acki Nacki апдейтился из децентрализованного git на самой сети.

(01:32:43) Иван Иваницкий: Спасибо. Там ещё остался кусок вопроса: чем это отличается от идеи условного Codeberg, открытой альтернативы GitHub.

(01:32:48) Митя Горошевский: Я ответил: все эти альтернативы в общем не на блокчейне. Они на инфраструктуре, по которой нет консенсуса: непонятно, есть она или нет, что с ней будет завтра. Кто на самом деле владеет этими серверами, кто ими заведует, и чем вы защищены от того, что заведующий не сделает что-то плохое со всей вашей «сетью» серверов? Представим, что кто-то захватил их все, их три, и все три захватили. Что тогда происходит с апдейтом, который вы выкатываете? Там, понимаете, совсем другая...

(01:33:25) Иван Иваницкий: Совсем другую следующую тему хотелось бы обсудить. У вас на сайте также упомянуты направления медиа и game development. Хотелось бы узнать, насколько это существенная часть того, что вы делаете, какой выхлоп она даёт и как сочетается с основным направлением работы.

(01:33:39) Митя Горошевский: Отличный вопрос, я даже не думал, что вы его зададите, и очень рад, потому что это я очень люблю. Acki Nacki — это не только сеть, но и лор, и в каком-то смысле мем, но больше чем мем: мем — одна картинка, одна штука, а Acki Nacki — целая вселенная. Всё началось с того, что, объясняя консенсус на первых выступлениях, я придумал героев, которые на мультяшном уровне, грубо говоря, показывают, что происходит. Потом мы подумали: это очень заходит, давайте развивать как маркетинг. Сначала это был просто маркетинг, а сейчас вылилось в полноценное направление. Недавно мы выпустили короткие видео-анонсы мультсериала Acki Nacki Lifecam про вселенную Acki Nacki и истории, которые там происходят. У нас полноценная 3D animation studio, которая делает этот сериал. Ещё одно пятиминутное видео выйдет перед Рождеством, первая серия планируется в начале года. Так это и развилось. Мне кажется, слово «маркетинг» в контексте децентрализованной сети звучит странно. Но что такое маркетинг? Это истории, это рассказ истории. Если истории нет, маркетинга нет. Мы решили: раз занимаемся маркетингом, давайте делать это прикольно, по-максимуму интересно для всех. «По сто сетей» — хорошо, но ужасно попахивает over-коммерциализацией, будто продаём шампунь. Acki Nacki — прикольный персонаж, персонажи вокруг него дают игровой лор, и мы делаем игры, которые уже играются на блокчейне: Pop It game, Pop Coin и прочее. Pop Coin — не просто мем-коин, а часть игрового мира, который мы растим. Наверное, в ближайшие дни выпустим B Engine — наш mining engine для мобильных верификаторов, для обычных людей, которые с телефона майнят NACKL. Мы сегодня этого почти не касались, возможно, уже не коснёмся, но такие штуки есть. Они получают 22,5 процента rewards всей сети за то, что по экрану доказывают криптографию, random, и делают это, играя в игры. Сейчас они играют в одну социальную игру: тапают на картинках, выбирая, какую заминтить как Pop Coin. Скоро выпустим это как B Engine, и любой мобильный game developer сможет встроить это в приложение, майнить NACKL и давать майнить NACKL через свои игры. Чтобы это выпустить, нам параллельно нужен был облегчённый кошелёк, который можно встроить прямо в приложение: функциональность ограничена, но криптографически он достаточно стойкий. Он сделан через ZK-login, как основной кошелёк, контракт мультифакторный в Acki Nacki. При логине используется TLS 1.3, Google, для Telegram мы сейчас тоже делаем. Можно один из факторов сделать ZK плюс пароль — и этого достаточно, seed-фраза не нужна. Более того, этими двумя факторами можно даже сменить seed-фразу, если потеряли. На той же базе сделан облегчённый кошелёк для встраивания в мобильные игры, и NACKL сразу видны в приложении.

(01:37:44) Сергей Тихомиров: Следующий вопрос нам также оставил слушатель Apparently: у проекта нет воспроизводимых билдов, которые можно проверить. Почему после запуска сети вы распространяете ноду только через Docker-образы, в то время как source ноды не собирается? Такой шаг наводит на мысль о степени готовности протокола. Уточните причину вашего решения.

(01:38:00) Митя Горошевский: Всё прекрасно собирается, просто нужны руки, которые растут из плеч.

(01:38:04) Сергей Тихомиров: То есть source code существует, его можно собрать и присоединиться к сети на базе этого source code, а не через ваш Docker-образ?

(01:38:12) Митя Горошевский: Конечно. Наш Docker-образ собран из тех же исходников скриптами, которые написали люди с теми самыми «руками». Валидаторы тоже собирают из того же репозитория. Открыт только один репозиторий, доступ к закрытым — только у нас.

(01:38:33) Сергей Тихомиров: Ещё один вопрос: какие гарантии отсутствия abuse блокчейна Acki Nacki? Что будет, если верификаторы в вашей схеме не успеют проверить блок за 300 миллисекунд?

(01:38:40) Митя Горошевский: На самом деле неважно, успеет или нет. Главное, чтобы нельзя было предсказать, успеет он или нет. И 300 миллисекунд, кстати, не так важны: он не обязан уложиться ровно в 300 миллисекунд, он должен успеть так, чтобы его NACKL включился в ближайшее количество блоков до финальности. В обычной сети это три блока. Если с сетью начинаются проблемы, это время растёт пропорционально проблемам. На совсем проблемной сети вы, кстати, будете продолжать видеть блоки каждые 300 миллисекунд, как правило, если только не происходит что-то совсем экстремальное. Блоки продолжают выходить, просто они будут финализироваться, и зачастую в какой-то момент финализация «откатится» назад. Но это если на сети начинаются проблемы.

(01:39:32) Сергей Тихомиров: Здесь мы опять, как обсуждали выше, приходим к пессимистичному случаю: сильно усложняется картина того, что начинает происходить. Ещё один вопрос задаёт Sam Friday, мне кажется, мы как раз этот аспект не обсуждали. Вопрос: без возможности деплоить смарт-контракты Acki Nacki выглядит как частная permissioned-сеть. Когда вы планируете разрешить пользователям деплоить смарт-контракты? От себя добавлю: для меня не было очевидно, что их нельзя деплоить. Их правда нельзя?

(01:39:55) Митя Горошевский: Потому что у нас пока невозможно купить Shell. Их ещё нужно туда продавать, Shell надо продавать за USDC, а чтобы продавать что-то за USDC, USDC нужно как-то прикрутить к платформе. Напомню всем, кто об этом говорит: на Solana в первые три месяца после старта тоже нельзя было ничего задеплоить. И не только на Solana — это нормальная практика. Просто нужно подождать, пока мы прикрутим все инструменты. Когда прикрутим Shell и accumulator-контракт, в любом случае это не займёт дольше, чем у Solana. Timeline — не месяцы, а недели.

(01:40:42) Сергей Тихомиров: Отлично. И последний вопрос, open-ended и на более позитивной ноте от пользователя ME: как быстрее всего достичь global mainstream adoption?

(01:40:48) Митя Горошевский: На этот вопрос нет ответа. Если бы я его знал, наверное, всё уже было бы достигнуто. Кстати, прошлые вопросы тоже не были такими уж негативными, всё в принципе в позитивном ключе. Лучшая технология может проиграть, такое было в истории: технологии, опережавшие своё время, не выстрелили. Возьмём бытовой пример: Sony делала прекрасную технологию съёмки видео высокой резолюции ещё в 1990-е годы, и она не пошла. Но мы же не продолжаем пользоваться VHS-кассетами. Нужна была технология высокой резолюции — она появилась, просто другим путём. Вопрос, есть ли другой путь. Блокчейн будет нужен, мы никуда не уперлись. Acki Nacki доказывает, что не было принципиальной невозможности сделать блок за 300 миллисекунд, финализацию меньше секунды, блокчейн на миллионы транзакций. Это просто ещё не было сделано, мы это делаем. У Acki Nacki такая задача. Теперь вопрос: можно ли сделать иначе, чтобы мы проиграли? Возможно. Пока прямых конкурентов Acki Nacki по показателям нет. Может, появятся. Но поскольку теоретически меньше двух сообщений в протоколе консенсуса не получится, какие бы технологии ни использовали, лучше Acki Nacki не будет. Может, будет также.

(01:42:23) Иван Иваницкий: Что ж, судя по всему, наши вопросы на этом подошли к концу. Спасибо большое, Митя, что пришёл к нам в гости и на них ответил. Было очень интересно с тобой поговорить.

(01:42:29) Митя Горошевский: Спасибо вам, были очень интересные вопросы, прям deep, это радует.

(01:42:37) Иван Иваницкий: Чуть не забыл про последний вопрос. Если у тебя есть объявления для слушателей или что-то, что хотелось бы прорекламировать, сейчас удачный момент это сделать.

(01:42:48) Митя Горошевский: Приходите в Acki Nacki. Пока можно майнить NACKL на мобильном устройстве и играть в игры. У нас интересное, очень живое коммьюнити, много людей, можно участвовать во всём и просто следить за проектом. Если хотите свои проекты или что-то пилить, у нас есть документация, можно начинать. Есть testnet, мы легко выдаём токены, можно разрабатывать. Когда откроются bridges и остальное, просто задеплоите. На разработку всё равно уйдёт время. Приходите на ackinacki.org.

(01:43:22) Иван Иваницкий: Плюс к моменту выхода выпуска, как я понял, к тому времени уже будет запущен DEX.

(01:43:29) Митя Горошевский: К этому моменту он не будет запущен, только объявлен сегодня. Можно податься в вайтлист и проявить интерес.

(01:43:40) Иван Иваницкий: На этом мы завершаем сегодняшний выпуск. Спасибо Сергею за вопросы и нашим спонсорам. Напомню: Zerion — Enterprise-grade Web3 API, Fluence — децентрализованная облачная платформа, 1inch — ведущая экосистема DeFi и Acki Nacki — the fastest blockchain possible.

(01:44:02) Иван Иваницкий: Это был Базовый Блок, выпуск номер 212. В гостях был Митя Горошевский. Спасибо и всего доброго.