(00:00:05) Иван Иваницкий: Всем привет! С вами подкаст «Базовый Блок». Это подкаст про блокчейн, у микрофона Иван Иваницкий.

(00:00:14) Сергей Тихомиров: Привет, друзья! И я, Сергей Тихомиров. Это выпуск номер 203, в котором мы продолжаем и, вероятнее всего, завершаем обзор Берлинской блокчейн-недели. Сегодня мы поговорим про конференцию Protocol Berg, которую я посетил 12 и 13 июня. Очень интересная техническая конференция с большим количеством докладов, некоторые из которых мы разберем подробно. Прежде чем мы начнем, хочу сказать спасибо тем, кто поддерживает наш подкаст. Это наши патроны на Patreon и Boosty. Если хотите нас поддержать, заходите на patreon.com/basicblockradio, boosty.to/basicblockradio и поддерживайте нас. Мы очень вам за это благодарны. А также мы благодарны нашим спонсорам.

(00:00:53) Сергей Тихомиров: Нас поддерживает GOSH, кор-разработчик блокчейна Acki Nacki, основанного на новом протоколе, достигающем консенсуса за две итерации, самым быстрым из теоретически возможных. GOSH готовится к запуску Mainnet в ближайшие месяцы. В коммьюнити GOSH более 4 миллионов участников. Заключены партнерства с Oracle и Amper Computing. Основные направления развития – мобильный гейминг, biodiversity-активы, мемкоины и DePIN. Спасибо, GOSH.

(00:01:24) Сергей Тихомиров: Также нас поддерживает Fluence. Это облачная платформа на базе децентрализованной инфраструктуры, которая предоставляет более дешевую и отказоустойчивую альтернативу традиционным облачным решениям, таким как AWS, DigitalOcean или Hetzner. С помощью Fluence вы получаете доступ к глобальной сети независимых провайдеров, можете быстро запускать виртуальные серверы и разворачивать рабочие нагрузки по всему миру. При этом значительно снижаете расходы и не зависите от одного провайдера. Спасибо, Fluence.

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

(00:02:20) Сергей Тихомиров: Начнем наш выпуск. Мы уже начали обозревать Берлинскую блокчейн-неделю в выпуске номер 201. Пришло время поговорить про Protocol Berg. Это конференция, которую я лично очень люблю. Мне кажется, это прекрасный ивент. Она проходит во второй раз и прошла в 2025 году в Берлине. Конференция посвящена всевозможным децентрализованным протоколам и связанной с этим тематике. Что мне особенно нравится: она, во-первых, техническая, а во-вторых, старается поддерживать очень высокое соотношение сигнала к шуму. Там нет спонсорских стендов, плакатов, проплаченных докладов — насколько я, по крайней мере, могу судить. Весь контент конференции очень содержательный. Но это не означает, что все доклады мне настолько понравились, что хочется их пересказать. Были доклады не совсем по моей тематике. Где-то я не все понял. Где-то, может быть, выступающий не суперчетко презентовал свою идею. Но в целом по соотношению контента к необязательному обвесу, мне кажется, это лучшая конференция из тех, на которых я был.

(00:03:34) Иван Иваницкий: А как им это удается, кстати? Кто спонсирует эту конференцию?

(00:03:38) Сергей Тихомиров: В конце, забегая вперед — это интересно, можно было записать, но я, к сожалению, не записал. На последнем докладе команда организаторов делала отчет и вкратце рассказывала, как они организовали конференцию. Они упоминали бюджет и кто задонатил. Я боюсь соврать — наверняка это можно посмотреть, и, возможно, мы даже посмотрим и приложим в шоуноты, кто именно: какой-то из фаундейшенов задонатил на организацию. Зато я запомнил, какой был бюджет всего мероприятия: порядка 150 тысяч евро, из которых 100 тысяч задонатила одна организация, какой-то фаундейшен. Я, к сожалению, забыл какой. Большое вам спасибо. Но то, что я даже забыл, какой именно, как раз говорит о том, что это не сказалось на контенте: они не были спонсором в привычном виде, где логотип на всех материалах. Еще сколько-то тысяч евро они собрали небольшими донатами, и сколько-то оставалось с предыдущих ивентов. И, как я понимаю, некая дыра все равно осталась, и они призывали закрыть ее пожертвованиями присутствующих на конференции. Кстати, не знаю, на твой взгляд, насколько это много или мало. Блокчейн-экосистема несколько сбивает перспективу: у нас DeFi-протоколы орудуют невозможными миллиардами. Докладчик выходит на сцену и говорит, что через такой-то DeFi solver проходит столько-то миллионов в день или в час. А потом выясняется, что вся организация двухдневной конференции стоит меньше, чем какие-нибудь потоки через Uniswap за час. Я фантазирую немножко, но понятно, что масштабы другие.

(00:05:11) Иван Иваницкий: Мне кажется, она столько и должна стоить, если ориентироваться на цены аренды — еда там была или нет, я не знаю, еда была — и, с другой стороны, на sponsorship package каких-то других крупных конференций. В принципе, звучит как разумная цифра.

(00:05:28) Сергей Тихомиров: Да, цифра вполне была разумная. Что еще следует сказать: билеты были бесплатные и, как я понял, по invite. Мне немножко сложно судить, потому что я подался в качестве докладчика, и мой доклад приняло жюри. Я презентовал — возможно, вкратце тоже про это расскажем — презентацию про Waku Service Marketplace, нашу идею децентрализованной сети сервисов на базе сети Waku. У меня был короткий 10-минутный доклад. То есть я в любом случае получил билет как спикер. Но даже посетителям, которые просто хотели послушать доклады, как я понимаю эту механику, платить за билет было не нужно — билеты раздавались по invite. Была выделена квота, в том числе и спикерам. У меня было два промокода, которые я, как ни странно, не нашел, кому отдать: что-то запостил туда-сюда, желающих не нашлось. Но думаю, большая часть билетов распределяется через эти квоты: спикеры приглашают коллег, друзей или еще кого-то. В итоге такая политика приводит к тому, что и доклады очень содержательные, и публика не случайная. В коридорах можно поговорить с кем-то, и разговор, как правило, интересный. Такой вайб довольно тесного коммьюнити — сравнивая с тем же Devcon, о котором мы записывали выпуск и который посетили в прошлом году. Devcon, наоборот, рассчитан на очень широкую аудиторию: гигантский конференц-центр, десятки тысяч участников со всех континентов. Здесь было гораздо более камерное мероприятие. Количество участников тоже называли, но я забыл — мне кажется, что-то вроде сотен, вряд ли тысячи. Такие порядки величины.

(00:07:04) Сергей Тихомиров: С точки зрения организации мне тоже все понравилось. Интересное место, где проводилась конференция. Оно называется Colosseum, кинотеатр «Колизей». Это исторический кинотеатр с интересной судьбой в районе Prenzlauer Berg в Берлине. Изначально на этом месте, в конце XIX века, когда в Берлине появился трамвай на конной тяге, были конюшни для лошадей, которые его тащили — депо конного трамвая. Потом его перестроили в кинотеатр. Здание функционировало как кинотеатр, в ковид закрылось, потом было восстановлено и переоткрылось буквально в 2023 году. Архитектура интересная. Я никогда не был внутри: много раз проходил мимо, но впервые побывал. Снаружи выглядит как архитектура 1920-х годов — я не тот термин употребляю: модернистская архитектура, вряд ли, что-то путаю. А когда заходишь внутрь, попадаешь во внутренний дворик, и там видны кирпичные небольшие здания того конного депо. То есть кинотеатр 1920-х годов как бы надстроен над существующими конюшнями. Мне очень нравятся такие слои истории: они сохраняются и существуют друг внутри друга. Сейчас там многозальный кинотеатр: помимо обычных показов, там в числе прочего показывают некоторые фильмы Берлинского кинофестиваля, и он еще функционирует как площадка для ивентов. Ее можно арендовать для конференции, что и сделали организаторы — за что им отдельное спасибо. Интересно, когда конференция проводится не в рандомном месте, а в красивой исторической локации. Еще по организации скажу общее, что мне тоже понравилось. Было плотное расписание, и слоты для докладов были, как правило, либо 10, либо 20 минут. Было три параллельных трека с докладами, плюс еще один зал отвели на воркшопы и более продолжительные, более практико-ориентированные события. Я на один такой воркшоп зашел, заглянул и не скажу, что это было суперинтересно, поэтому не буду останавливаться. Но с точки зрения посетителя все было удобно: у меня есть мое расписание. Впрочем, на Devcon была такая же механика. Можно отметить, занести в избранное доклады: ты видишь расписание с параллельными треками, отмечаешь, куда хочешь сходить, а потом на месте просто смотришь — следующий доклад в этом зале, в этом зале и так далее. Плотное расписание практически всегда соблюдали: я не помню, чтобы оно сильно отклонялось. С точки зрения слушателя я в очередной раз убедился, что 10 минут для большого количества докладов совершенно достаточно. Все равно все подробности не получится раскрыть, а за 10 минут вполне можно заинтересовать своей идеей, описать решенную проблему, если об этом идет речь. Главное — дать резюме за 10 минут. Если люди заинтересуются, они потом найдут, где почитать и где посмотреть более развернутые материалы. Уже к 20-минутной отметке для 20-минутных докладов я, правда, начинал скучать: людям свойственно слишком глубоко углубляться в свою экспертизу. Понятно, что если ты год решал задачу, тебе хочется поскорее проскочить то, что за этот год стало очевидным, и перейти к результатам. Но слушателям, мне в том числе, нужно определенное время, чтобы понять, какую проблему мы вообще решаем. Поэтому мой совет докладчикам и себе как будущему докладчику: нужно больше времени уделять формулировке задачи и ставить главной целью, чтобы слушатели поняли хотя бы, что мы пытаемся решить, и уже во вторую очередь — что именно было сделано. В общем, 10 минут почти всегда достаточно, 20 — в 95% случаев достаточно. Более длинные слоты по 50 минут — таких докладов было два, и мы на них тоже остановимся подробнее. Доклад Виталика был в слоте 50 минут, хотя Виталик говорил гораздо меньше и в оставшееся время отвечал на вопросы. На слот 50 минут был доклад у Гэвина Вуда, который, наоборот, сильно вылез за тайминг и произвел на меня не очень хорошее личное впечатление — как будто человек не уважает время слушателей. Он что-то ковырялся в своем демо на сцене, ничего не работало, и сильно вылез за хронометраж. Возможно, подозревая это, организаторы поставили доклад самым последним, чтобы никого не задерживал. А Виталик, наоборот: ему тоже был слот на 50 минут, он справился минут за 25 и в оставшееся время просто отвечал на вопросы. Про доклад Виталика хотелось бы подробнее поговорить — мы это скоро сделаем.

(00:11:23) Иван Иваницкий: Да, ты, кстати, сказал, что в докладе имеет смысл существенную часть посвятить постановке задачи и только потом переходить к тому, как она была решена. В этом безусловно есть смысл, но мне в голову приходят несколько примеров докладов, когда все время ушло на постановку задачи, и что было сделано, не успеваешь понять: докладчик успел поговорить одну минуту в конце. С одной стороны, есть какой-то баланс. С другой — целеполагание в докладе, которое мне кажется более правильным: с учетом аудитории, перед которой ты говоришь, исходно ставить перед собой вопрос, чем я могу быть полезен этой аудитории. Это может быть не твоя постановка задачи и не твое решение. Они могут быть в разных пропорциях. Но такая постановка вопроса, мне кажется, приводит к более интересным результатам.

(00:12:19) Сергей Тихомиров: Да, соглашусь. Вообще полезно перед тем, как что-то делать, задать себе вопрос, зачем ты это делаешь и чего пытаешься добиться. В целом у меня сложилось впечатление, что на таких глубоких конференциях с техническими докладами все копают какую-то свою область и в ней становятся большими экспертами. И как будто мета-задача докладчика, когда он выходит на сцену, — произвести впечатление, что мы в нашей компании суперглубокие эксперты вот в этой области. Я додумываю, конечно, не знаю наверняка. И вот proof-of-work, доказательство того, что мы поработали и что-то придумали. А для меня как слушателя, чтобы это сработало, нужно понять задачу: почему это нужно, почему это сложно, почему кто-то раньше, наверное, пытался и у него не получилось, а вот именно эти чуваки пытались, у них получилось, и поэтому они крутые. Короче, мысль понятна, можем перейти к более предметному разговору про доклады. Не думаю, что имеет смысл соблюдать хронологию, и не так важно, в какой именно день и час доклады были представлены. Предлагаю с места в карьер перейти к докладу Виталика. Он был на второй день, но тем не менее: Виталик рассказал про свое предложение заменить EVM на RISC-V. Вот такие дела.

(00:13:30) Сергей Тихомиров: В чем идея? Идея в том, что EVM, наша любимая виртуальная машина, на которой работает Ethereum и где исполняются смарт-контракты, не совсем оптимальна под современные юз-кейсы. Когда ее разрабатывали, еще не настолько глубоко думали про Zero Knowledge — по крайней мере, уж точно не в таком практическом ключе, как сейчас. В результате EVM получилась не очень дружелюбной для Zero Knowledge, а Zero Knowledge рассматривается как один из главных способов увеличивать масштабируемость Ethereum в среднесрочной перспективе. Как я понял из доклада Виталика, с одной стороны команда Ethereum Foundation, разработчики Ethereum и EVM, рассматривают некоторые краткосрочные изменения для увеличения пропускной способности и вообще масштабирования. С помощью таких точечных изменений можно добиться ограниченного результата. Хотелось бы в средней и долгосрочной перспективе добиться того, чтобы все было завернуто в ZK. И тут я, возможно, перефразирую или добавляю понимание из других докладов: в целом архитектура блокчейнов изначально была построена на том, что безопасность проистекает из того, что все узлы валидируют все транзакции. Именно потому, что мой полный узел Bitcoin, например, прокручивает все биткоин-транзакции, я убеждаюсь, что все валидно, и отсюда проистекает безопасность. А с помощью Zero Knowledge можно добиться как будто бы такого же эффекта, только без повторения исполнения. Вместо того чтобы буквально повторять все исполнение, у меня будет короткий proof, который я проверяю и убеждаюсь, что все валидно, без буквального переисполнения всех транзакций. Это то, что пытаются делать — или делают с какой-то степенью успешности — ZK-rollup, уже с большим количеством звездочек, поскольку все это пока довольно централизовано устроено, о чем мы тоже позже поговорим. Но в принципе нет фундаментальной причины, почему бы Ethereum не мог делать так же. Итак, это одна из мотиваций. Вторая — что EVM довольно сложна, за годы разработки наслоилось многое: например, добавляли precompiles, которые на практике оказались не так популярны, как замышляли разработчики. Замена виртуальной машины целиком на RISC-V — уже существующую и популярную в других юз-кейсах — позволит Ethereum стандартизироваться и упроститься.

(00:15:58) Иван Иваницкий: Ты сказал, что ZK вместо дублирования исполнения на всех узлах просто кладет proof, и Ethereum мог бы делать так же. Что ты имеешь в виду, учитывая, что этот proof в итоге кладется на Ethereum? В контексте Ethereum куда тогда клался бы этот proof?

(00:16:19) Сергей Тихомиров: Нет, proof будет класться на Ethereum. Вопрос в том, что не нужно будет переисполнять все транзакции, чтобы убедиться в корректности происходящего. Сейчас я, может быть, уже додумываю и дофантазирую, но идея в том, что вместо того чтобы поддерживать state и применять к нему транзакции одну за другой — что очень сложно computational, это просто долго занимает, — на чейне будет список транзакций и какой-то очередной state. Или даже не так: будет очередной state и proof того, что он корректно получен с предыдущего state. И так рекурсивно, turtles all the way down, до genesis block или до какого-то checkpoint довольно давней истории, и не нужно будет все это переисполнять. Это один аспект. Второй, родственный, тоже в контексте ZK: почему нам может хотеться заменить EVM на RISC-V. Сейчас в существующих ZK-EVM — модификациях EVM, заточенных под то, чтобы быть эффективно provable в ZK, — proving все равно занимает большую часть всего. Возвращаюсь к докладу Виталика. Некоторые модификации, которые ZK-EVM делают по сравнению с обычным EVM, заменяют в частности хэш-функцию: вместо Keccak — Poseidon, которая более ZK-friendly, и меняют структуру хранения данных. То, что раньше было RLP, Recursive Length Prefix, превращается в SSZ. Я не уверен, что сходу расшифрую эту аббревиатуру; в общем, какая-то другая структура хранения стейта, более дружественная к ZK. И после того, по словам Виталика, как такие модификации могут быть применены, следующим bottleneck становится доказательство execution, то есть генерация ZK-proof. И мы бы могли, по словам Виталика, получить следующее стократное увеличение производительности путем замены EVM на RISC-V. Здесь немного моей экспертизы не хватает: может быть, кто лучше понимает теорию компиляторов и архитектуру, проинтерпретирует это лучше, но я как будто цитирую близко к тексту. Вообще избавление от такой абстракции, как виртуальная машина, поможет получить самый буст по перформансу. Сейчас, по словам Виталика, большинство современных ZK-EVM пишутся на каком-то высокоуровневом языке и компилируются куда-то: в RISC-V, в WASM, в Cairo ISA или в какие-то другие ISA. ISA — это Instruction Set Architecture, набор низкоуровневых инструкций, заточенных под определенную архитектуру процессора. Дальше Виталик описал свой мыслительный процесс, где рассматриваются два главных вопроса. Во-первых, насколько RISC-V будет оптимален в долгосрочной перспективе: да, мы сейчас сможем посвятить ближайшие несколько лет переходу на RISC-V, но не получится ли так, что через пять лет выяснится, что какая-то следующая виртуальная машина еще оптимальнее, и опять захочется все переделать и заменить? По словам Виталика, это в принципе валидные возражения, и можно про это подумать. Не то чтобы Виталик как диктатор, пусть даже benevolent, бил кулаком по столу и говорил, что мы точно переходим на RISC-V. Это предложения, и он предлагает продумать, обсудить; возможно, у кого-то будут альтернативы. И второй вопрос: если переходить, допустим, на RISC-V, как устроить процесс перехода, из каких стадий он может состоять, чтобы минимально подвергнуть риску Ethereum и его текущую работу. Подробно пересказывать не буду, потому что это непросто без визуальной диаграммы, и, честно говоря, я не до конца понимаю архитектурные следствия таких решений. Но как описывает Виталик: после того как выбор будет сделан в пользу определенной виртуальной машины вроде RISC-V, она сначала внедрится в ограниченном наборе сценариев. Например, постепенно заменят precompiles: те, что вызываются в смарт-контракте, вместо исполнения на EVM будут исполняться на новой виртуальной машине. Потом новая виртуальная машина станет напрямую доступна разработчикам, они начнут работать с ее логикой. И постепенно она полностью заменит EVM — в перспективе, как я понимаю, нескольких лет.

(00:20:53) Иван Иваницкий: Ты упомянул термин ISA, Instruction Set Architecture, и до этого сказал, что, возможно, будет иметь смысл уйти от такой абстракции, как виртуальная машина. Для меня без контекста эти две вещи звучат одинаково. Можешь пояснить, в чем разница между VM и ISA?

(00:21:07) Сергей Тихомиров: Не гарантирую, что сейчас на сто процентов точно описываю происходящее. Как будто в текущей архитектуре EVM — это дополнительный уровень абстракции, который мапится на архитектуру, на которой эта EVM работает. Сейчас, когда пытаюсь это объяснить, я не понимаю полностью, почему RISC-V — это не то же самое. Возможно, здесь нужно покопать глубже. Мы приложим ссылки в описании на пост Виталика, где он подробно описывает это предложение с плюсами и минусами. Но на твой вопрос есть формальный и довольно бесполезный ответ: Instruction Set Architecture — это язык, на котором оперирует некоторая машина, физическая или виртуальная. А виртуальная машина — это абстракция процессора, которая оперирует на базе или в качестве имплементации на базе какой-то другой машины, опять-таки физической или виртуальной, на какой-то другой архитектуре. Но как будто этот ответ не очень полезен в нашей ситуации.

(00:22:03) Иван Иваницкий: Если я правильно проинтерпретировал, то ISA привязана уже к конкретным инструкциям, доступным физической машине. А VM имеет свой набор инструкций, одинаковый для всех физических машин, на которых она в итоге будет работать. Но, честно говоря, мои знания в этой области настолько скудны, что я даже не уверен в корректности вопроса.

(00:22:26) Сергей Тихомиров: Да, я в свою очередь не уверен в корректности ответа. Так что адресуем всех к первоисточнику. Опять-таки наша цель здесь не столько с такой же глубиной, с которой это может сделать Виталик, рассказать про все тонкости, сколько обозначить проблему и направить интересующихся слушателей на первоисточник, где можно подробнее про это почитать. Последнее, что скажу, отвечая на вопрос, что изменится для разработчиков смарт-контрактов: Виталик сказал, что в принципе, возможно, изменится не так много. Контракты по-прежнему будут писаться на Solidity и Vyper и компилироваться уже в новую архитектуру RISC-V. Также, возможно, можно будет писать смарт-контракты на языках общего употребления вроде Rust, хотя лично Виталик небольшой фанат. Он говорил — не помню, в этом докладе или в каком-то blogpost, — что вот простой контракт на Solidity, простой на Vyper и такой же на Rust: на Rust он выглядит гораздо уродливее, там больше boilerplate. Так что Виталик говорит, что Solidity на самом деле неплохой язык, довольно наглядный, и возможность писать на нем должна остаться. А модификация Solidity под новую потенциальную архитектуру вроде RISC-V облегчается тем, что RISC-V уже довольно популярна сама по себе, и под нее существуют компиляторы и бэкенды для компиляторов. Приделать конвертацию Solidity в некоторое промежуточное представление, которое уже существующими тулами конвертируется в код для RISC-V, будет не так сложно. То есть это не описание целиком всей цепочки компиляторов с нуля.

(00:23:57) Иван Иваницкий: А можешь дать немного бэкграунда: что такое RISC-V и откуда он взялся?

(00:24:03) Сергей Тихомиров: Подробности я, наверное, рассказать не могу. Знаю, что это архитектура для процессоров, которые уже используются в определенных юз-кейсах, как я сейчас подсматриваю на ходу в Википедию. Проект начался в 2010 году и следует подходу, который характеризуется как RISC. RISC означает Reduced Instruction Set Computer, компьютер с уменьшенным набором инструкций. В целом в архитектуре процессоров или виртуальных машин есть trade-off: либо много относительно низкоуровневых инструкций в языке, которым оперирует машина, либо относительно небольшой набор, но каждый делает относительно высокоуровневую вещь. Высокоуровневые и низкоуровневые — все это в том регистре, где мы размышляем, должна ли у нас быть инструкция «перенеси из такого-то регистра в такой-то», или инструкция, которая складывает два числа. Я опять немного фантазирую; понятно, мы все еще на очень низком уровне in the grand scheme of things, но на этом очень низком уровне есть свои градации низкоуровневости.

(00:25:08) Иван Иваницкий: Если мне правильно удалось поместить это знание в контекст уже существующих знаний, то RISC-V получается альтернативой x64 либо ARM в архитектуре. Так ли это?

(00:25:20) Сергей Тихомиров: Я понимаю, что это так, да. Давайте завершим пересказ первой страницы Google в прямом эфире и поговорим про другие доклады. В целом давай обменяемся более высокоуровневыми мнениями: как мы смотрим на то, что Ethereum и на execution layer, как мы обсудили выше, и на consensus layer — как нам в Бангкоке презентовал Джастин Дрейк (Justin Drake) свой проект BeamChain, который обновляет консенсусный уровень на перспективу ближайших пяти лет. Как мы относимся к тому, что разработчики Ethereum отнюдь не считают его завершенным проектом и предлагают коренные изменения базовых элементов архитектуры. Казалось бы, консенсус уже есть, он работает, execution есть, он работает, вроде ничего не сломалось. «Чини то, что не сломано», сказал бы скептик. А разработчики Ethereum, очевидно, не скептики, а оптимисты, и говорят: а давайте сделаем еще лучше, потому что мы знаем как. Вот план на пять лет.

(00:26:20) Иван Иваницкий: Сама эта концепция, мне кажется, верная и вплоть до очевидности. Другой вопрос: корректный ли это приоритет для развития Ethereum, или есть вещи более важные? Они, видимо, решили, что нет. У меня тоже нет понимания, что что-то другое может быть более важным. Но смотреть на Ethereum как на что-то уже сложившееся и завершенное, мне кажется, безусловно рано.

(00:26:45) Сергей Тихомиров: Да, мне интересно: масштабные изменения — это шаги к более или менее понятной конечной цели, просто это много времени занимает, или это такое состояние души Виталика и разработчиков Ethereum, что через пять лет, когда внедрятся RISC-V и BeamChain, на горизонте появится что-то еще новое, и разработчики скажут: «О, а мы знаем, как сделать еще лучше — почему бы нам не сделать еще лучше?» Они, в принципе, могут быть и правы. Я к тому, что, сравнивая это с консервативной Bitcoin-разработкой, мой concern в том, что в какой-то момент пространство возможных улучшений становится настолько большим, что сложно поддерживать сфокусированную стратегию и оптимизировать на четко поставленную цель. Я могу представить сообщество людей, которым по кайфу разрабатывать, внедрять и исследовать такие штуки: это очень интересно, и они этим занимаются просто потому, что им по кайфу. Для конкретного предложения может быть действительно хорошо обосновано, почему оно нужно и почему улучшит scalability и другие качества. Но как будто есть момент, когда такого становится слишком много, и само техническое улучшение становится самоцелью — в противовес следованию цели пользы для юзера.

(00:28:05) Иван Иваницкий: Да, я тоже об этом задумывался в контексте пользы для юзера. Мне кажется, даже если финальной целью ставим пользу для юзера, ответ на вопрос «что делать» будет разным в зависимости от того, на какую перспективу мы смотрим. Условно, они смотрят на пять лет и оптимизируются под всякие юз-кейсы — ZK-юз-кейсы, грубо говоря, даже не на конечного юзера ориентированные. Что правильно, учитывая, что это экосистема, а не B2C-продукт. А если бы они оптимизировались на масштабе одного года, то, возможно, нужно было бы делать что-то для мемкоинов или чего-то еще. Ну, мемкоинов уже поздно, вероятно, но условно. Другой вопрос: есть ли у них, у нас эти пять лет? Я надеюсь, что есть, но не уверен в этом на сто процентов.

(00:28:54) Сергей Тихомиров: Да, всякое может случиться. Наверняка многие слушатели читали отчеты про то, как AI захватит мир, с hockey stick-графиками, уходящими в бесконечность в 2028 году, так что непонятно, сколько нам времени осталось.

(00:29:06) Иван Иваницкий: А, нет, я даже не про это. Я просто про количество денег у Ethereum Foundation.

(00:29:12) Сергей Тихомиров: А, окей, значит, тут можно разные интерпретации. У меня есть еще парочка, но я их пока придерживаю при себе. Давайте поговорим еще про некоторые доклады. Кратко упомяну доклад Тима Бейко про то, как работает Ethereum governance. Как же он работает на самом деле: кто принимает решение, какие EIP нам принимать и какой код вливать? Тим Бейко привел несколько примеров EIP, которые обсуждались или внедрялись в последнее время. Насколько я понял, главный пойнт, который он пытался представить: процесс у нас долгий и несколько хаотичный — в том смысле, что нет четко прописанного процесса. Или так: есть четко прописанный процесс, но в зависимости от специфики конкретного предложения он может варьироваться. В частности, приводился пример EIP-2537, который добавляет precompile для агрегации подписей BLS, что-то в этом духе. Общая идея: этот proposal не вызывает особого противоречия — все более-менее согласны, что это действительно полезный precompile, криптография и так далее. Но первая его версия была создана в 2019 году; потом по какой-то первоначальной версии он был предложен в очередной hard fork и вроде как включен — мои заметки тут немного противоречат друг другу. В общем, внедрение этого как будто бы не вызывающего больших сомнений EIP заняло 5–6 лет. Другой EIP, который рассматривали, — EIP-7691, про увеличение количества blobs в каждом блоке. Blobs, напомню, — это структуры данных в каждом блоке Ethereum, куда, например, rollups могут класть свои данные и обеспечивать data availability. Это более дешевый способ, чем calldata, которая использовалась для этой цели раньше. Blobs хранятся только около трех недель, потом удаляются, и к ним нельзя обращаться из EVM — то есть это просто хранилище данных. Этот EIP приводился как пример: как я понял, было принято какое-то исследование, которое считало, какое было бы оптимальное количество blobs в зависимости от внешних условий. Вывод был в том, что нужно целиться в 6 blobs, а не в 3. И соответствующий EIP был принят. Не углубляясь в детали других упомянутых EIP, еще один интересный случай, который докладчик упомянул. Он говорит: мы запланировали собрание Ethereum core-разработчиков в Берлине в ходе берлинской блокчейн-недели, поскольку все равно все или многие слетаются в Берлин. Была закрытая встреча разработчиков Ethereum с целью обсудить и попрототипировать протоколы интероперабельности и связанные вещи. Agenda этого собрания уже была установлена. И тут внезапно появляются два EIP, которые как будто бы требуют обсуждения и сами по себе не очень большие. Я назову номера — EIP-7939 и EIP-7909, — но в чем они заключаются, сходу не скажу; интересующиеся могут посмотреть. Возникает вопрос, говорит докладчик Тим Бейко, с точки зрения организаторов: должны ли мы реагировать на то, что какое-то предложение всплыло в Twitter в последние три дня, условно говоря, или следовать своей agenda, не обращать на это внимания и обсуждать то, что запланировали? Какие здесь аргументы за и против? С одной стороны, случай, когда разработчикам можно собраться на несколько дней в одном физическом помещении и поговорить с глазу на глаз, — очень ценная возможность, которую хочется использовать с максимальной эффективностью. А какие вещи будут максимально эффективны, какие вопросы требуют такого обсуждения — виднее тем, кто в контексте и хорошо понимает, что сейчас происходит. С другой стороны, разработчики core protocol должны, в числе прочего, убеждать сторонних наблюдателей в своей легитимности. Не должно оставаться впечатление, как говорит докладчик, что окей, у нас есть процесс EIP, и каждый может предложить EIP, но при этом разработчики собираются на закрытые встречи с глазу на глаз и там на самом деле решают, что происходит, а весь остальной процесс — декорация для проформы. Не должно оставаться впечатление, что есть внешний процесс и какой-то внутренний процесс. Четкого ответа, где найти баланс, докладчик не дал. Я не думаю, что такой ответ вообще может быть. Но в целом, как он подытожил, цель governance и усилий по систематизации project management core-разработки Ethereum состоит в том, чтобы с одной стороны обеспечить максимальную производительность людей, которые уже в контексте, — core-разработчиков, которые реально могут что-то сделать, — и при этом для внешних наблюдателей с меньшим количеством контекста дать предсказуемость и понимание, как эта система работает. Например, даже если не говорить про совсем пользователей-пользователей, которые сами ни в какой разработке не участвуют, в качестве внешних наблюдателей имеются в виду команды rollups, которым интересно, как развивается Ethereum, на котором они строят свои протоколы и продукты. В командах L2, условно говоря, есть люди, которые читают Ethereum-форумы, следят, где продвигаются EIP, и у них должно быть понимание, куда развивается Ethereum. В том числе на них должна ориентироваться коммуникация core-разработчиков, чтобы этим наблюдателям, которые тоже что-то пилят, было понятно, чего ожидать и как, возможно, повлиять на процесс.

(00:34:40) Иван Иваницкий: Да, ты сказал фразу, что не должно складываться впечатление, будто есть процесс внешний и процесс внутренний. Но мне кажется, такое впечатление как раз должно складываться, потому что так обстоят дела: когда разработчики встречаются живьем, в любом случае есть этот внутренний процесс. Я говорю это в том числе потому, что в компании, в которой я работаю, я работаю удаленно, а разработчики сидят в одном офисе. И мало того, что ты иногда не можешь узнать, о чем они поговорили, — иногда ты можешь не знать даже о самом факте разговора. То есть ты можешь даже не знать, что нужно запросить summary о том, о чем вы поговорили. И все равно summary не будет так полезен, как присутствовать при разговоре. Здесь действительно придется предпринимать активные и целенаправленные действия, чтобы внешние люди не только имели представление о том, как происходит внутренний процесс, но главное — имели возможность влиять на этот процесс. Она в любом случае не будет такой же большой, как у самих разработчиков, но должна быть существенной. Хорошо, что в Ethereum об этом говорят; я надеюсь, что в какой-то степени они преуспеют. Но можно гарантировать, что не на сто процентов — просто потому что это очень сложно сделать.

(00:35:52) Сергей Тихомиров: Ну что, перейдем к следующему докладу, который я хотел бы осветить. Доклад, возможно, несколько нетипичный, но мне он показался очень интересным, и статья, на которой он основан, тоже показалась очень интересной. Хотя я ее не читал, скажем так: я прочитал abstract, положил ее в закладки «прочитать когда-нибудь потом», и, конечно же, это «потом» не наступило в течение года. Я просто дождался конференции, где сам автор этой статьи придет и расскажет со слайдами, что же у него там, что они нарисовали. Я знаком с автором, который презентовал статью, его зовут Иштван Андраш Сереш. Мне кажется, я правильно читаю венгерские имена: там S произносится как «ш», поэтому Soros — это не Сорос, а Шорош, если я правильно помню, но не важно. В общем, исследователь с коллегами. Мы с ним знакомы по работе над Lightning Network: мы участвовали в написании главы про Security and Privacy для книги Андреаса Антонопулоса и соавторов про Lightning, Mastering the Lightning Network. Он тоже писал: Иштван писал статьи про Lightning и сейчас пишет статьи, в том числе про Ethereum. В чем суть, в чем мораль, метанаблюдение. В стародавние времена, когда proof-of-stake только разрабатывался, был популярен такой жанр: биткоинеры пишут статьи или blogpost на предмет того, что proof-of-stake никак не может работать, и приводят очень убедительные аргументы, почему это так — им же можно манипулировать вот так, им же можно манипулировать вот сяк. С proof-of-work такое не проходит, потому что у вас к этому привязана реальная физическая энергия, а с proof-of-stake вот так и так его можно обхитрить. Писали биткоинеры, на что условные Ethereum-разработчики или proof-of-stake-разработчики писали еще в пять раз более длинное объяснение, почему на самом деле это можно обойти, почему на самом деле все заработает. И как будто бы практика показала сейчас, что Ethereum работает, у нее есть proof-of-stake, его как будто не сломали, и множество других сетей работают на proof-of-stake. Как будто бы proof-of-stake сейчас стал, собственно, стандартом, и никто на proof-of-work сети свои не запускает. У меня исходя из этого просто эмпирического наблюдения создалось впечатление, что окей, наверное, разработчики proof-of-stake как-то придумали, как обойти те вопросы, которые поднимали биткоинеры 10 лет назад. Может быть, не в ста процентах случаев, может быть, не с какой-то теоретической криптографической security, но достаточно хорошо, чтобы это работало на практике. В частности, когда я какое-то время назад краем уха услышал, как работает выбор валидаторов в Ethereum на proof-of-stake с помощью протокола RANDAO, мысль о том, что этим процессом можно манипулировать, пришла мне в голову. Но потом я прочитал аббревиатуру VDF и подумал: окей, наверное, есть какая-то хитрая криптография, которая обеспечивает безопасность всего этого процесса. Наверное, умные криптографы подумали, решили это, все внедрили — и я не особо закапывался в детали. Но за меня закопались в детали исследователи из одного из университетов Будапешта и рассказали следующий поразительный факт. В Ethereum на proof-of-stake есть понятие слота, есть понятие эпохи. Эпоха состоит из 32 слотов. На каждый слот есть валидатор, который отвечает за производство блока в этом слоте. Валидаторы выбираются на следующую эпоху в предыдущей эпохе — ну, не совсем так: они выбираются через одну, в n-й эпохе определяются валидаторы на n плюс вторую эпоху, почему-то так это сделано. И как устроен этот процесс? Еще я не могу сказать это издалека, как устроен этот процесс в proof-of-work. В proof-of-work у нас есть рандомный процесс в виде генерации соответствующих хэшей. Я думаю, все про него наслышаны, да, я понимаю, как он работает. По сути, что происходит в Bitcoin, когда генерируется хэш, когда майнер выбирает хэш: этот хэш и связанный с ним proof-of-work одновременно является доказательством работы, а также является рандомной лотереей, которая предоставляет право генерации блока в данном слоте. Если мы заимствуем терминологию proof-of-stake и переносим на proof-of-work: вот есть какой-то слот, текущий блок — кто же будет производителем блока в этом слоте? Это определяет найденный майнерами хэш. В proof-of-stake нам тоже нужна рандомность, для того чтобы валидаторы и производители блоков... Здесь опять-таки мы забыли про весь pipeline, забыли про билдеров, эти аукционы, PBS, pipeline — про это все забыли временно. Мы говорим про такой ванильный proof-of-stake. Чтобы тоже был валидатор, нужна какая-то рандомность. И как в итоге рандомность генерируется на практике? У нас валидаторы в n-ом слоте делают некоторый commitment посредством BLS-подписей. BLS-подписи так устроены, что они детерминистичные и уникальные, то есть их нельзя перебирать. В итоге в конце данной эпохи валидаторы этой эпохи раскрывают свои секретные числа, подписи к которым они уже предоставили. Производится операция XOR над всеми этими раскрытыми случайными числами, и результирующее случайное число определяет, кто будет валидаторами через одну эпоху, — распределяют эти 32 слота. Идея состоит в том, что этот процесс вроде как должен быть рандомным. Но выясняется довольно предсказуемо, на мой по крайней мере взгляд, что есть теоретико-игровая атака на этот механизм. А именно, в простой формулировке: последний валидатор может предрассчитать результирующее случайное число и стратегически решить, хочет ли он свое число раскрывать или нет. Это в принципе атака, которая характерна для всех commit-reveal схем, где есть несколько участников: они коммитятся на какие-то случайные числа и потом их раскрывают. Но последний участник, который должен по идее раскрыть свое число, уже видит все предыдущие раскрытые числа и понимает, какой будет результат, если он раскроет, и какой будет результат, если он не раскроет. А соответственно, в данном юз-кейсе результирующее случайное число определяет выбор валидаторов в каком-то следующем слоте. Соответственно, последний валидатор может предрассчитать: окей, какое будет распределение, если я раскрою, какое будет распределение, если я не раскрою. Может такое случиться, что, например, если я последний валидатор, я не раскрою свое число — и так случайно получается, что у меня будет на слот больше в через-следующей эпохе. Ну, я возьму и не раскрою. Обобщу немножко — и не знаю, может, какой-нибудь вопрос задашь. Получается, что в идеале мы хотели бы, чтобы валидатор, у которого допустим есть 20 процентов стейка, имел матожидание 20 процентов слотов, которыми он будет владеть. И это может быть не так: если валидатор будет действовать стратегически рационально в соответствии с этой стратегией, он может немножко увеличивать свою долю в матожидании, свою долю слотов выше, чем честная доля стейка. Это несколько похоже на selfish mining, где тоже майнеры в Bitcoin могут делать не совсем то, что как будто бы они должны по протоколу, увеличивая в итоге свою долю участия в протоколе и вследствие этого свою долю награды, которую протокол раздает.

(00:42:42) Иван Иваницкий: Если я правильно понимаю, то by design протокол и в случае Bitcoin, и в случае Ethereum такой, что участники должны делать именно то, что им выгодно, потому что мы не можем их заставить, но мы можем ожидать, что они будут делать то, что для них выгодно. Перекладывая это соображение на этот случай, я могу задать вопрос: а если так будут делать все валидаторы? То есть когда ты становишься последним валидатором списка вот этих ребят, которые предлагают случайные числа, известно, что ты либо раскрываешь, либо не раскрываешь свое случайное число в зависимости от того, что тебе выгоднее. Есть подозрение, что будет сдвигаться вот эта цифра матожидания относительно процента стейка, но по крайней мере схема в целом не будет сдвинута в пользу какого-то конкретного валидатора.

(00:43:33) Сергей Тихомиров: Я так понимаю проблематику. Я не уверен, что именно ответ на этот вопрос был напрямую дан в статье, но мое понимание в том, что такого рода механики увеличивают централизацию. То есть в пределе они приводят к тому, что участники даже с небольшим перевесом изначальным вдоль стейка или вдоль майнинговой мощности будут все больше и больше ее захватывать. В частности, в этой статье были приведены расчеты, что валидатор с 25 процентами стейка вроде как может получить 26,6 процентов слотов.

(00:44:07) Иван Иваницкий: Но вообще звучит как не очень серьезная атака. То есть понятно, что хочется, чтобы было на 100 процентов честно. Ну нет, нет, конечно: с точки зрения, когда мы начинаем считать прибыль конкретного, своего особенно валидатора, это все превращается в конкретные цифры в деньгах и становится чуть более вещественным. Но у меня вот какой еще вопрос есть: а вот в этом списке валидаторов, кто становится последним валидатором, как это определяется? То есть учитывая, что у него получается больше полномочий, чем у всех предыдущих, и как будто бы это не распространяется на предпоследнего, а только на последнего.

(00:44:46) Сергей Тихомиров: Кто будет последним, определяется этим самым рандомом. То есть рандом определяет, кто будет валидатором и в каком порядке в слоте через следующий. Соответственно, понятно. А про последнего и предпоследнего — честно, на это отвечает тоже статья и доклад. То, что я описывал раньше, — это самый простой вариант атаки: просто последний и все, раскрываешь или не раскрываешь. Но есть еще более сложный вариант атаки, или можно сказать схожая атака, которая как раз еще больше похожа на selfish mining. Там предполагается, что у тебя как у валидатора с какой-то существенной долей стейка есть несколько слотов в рамках одной эпохи, и ты можешь стратегически решать в рамках одной эпохи, будешь ли ты блок производить или будешь пытаться пропустить свой слот. В общем, механика похожа на selfish mining. И выясняется, что тоже это можно посчитать и понять, что в некоторой конфигурации — например, допустим, есть Алиса и Боб, и Алиса... Это даже непонятно называть злоумышленником или нет, но в общем рациональный майнер, рациональный валидатор, который следует этой стратегии. И так распределили слоты, что слоты идут Алиса, Боб, Алиса. Когда Алиса добыла свой блок или может сгенерировать свой блок в первом своем слоте, она в принципе может сделать вид, что она этот слот пропустила, так чтобы Боб дальше сгенерировал свой... Сейчас я немножко запутываюсь, честно говоря. Но вот те, кто помнит selfish mining, где были похожие механики: майнер добывает блок, а дальше вроде как по наивному пониманию протокола он должен его раскрыть, потому что это как будто бы должно увеличивать его матожидание выигрыша. Но на самом деле, если аккуратно все посчитать, выясняется, что вот эта опциональность — что я могу раскрывать или могу не раскрывать в зависимости от действия моего оппонента, другого валидатора или другого майнера, — оказывается, что эта опциональность, если она стратегически применена, дает в матожидании больше выигрыша, чем было бы при честном распределении.

(00:46:39) Иван Иваницкий: А можешь, пожалуйста, напомнить, каким образом selfish mining не вписывается в исходный design proof-of-work?

(00:46:45) Сергей Тихомиров: Исходный design proof-of-work предполагает — или опять-таки его наивная интерпретация заключается в том, — что как только я как майнер добыл блок, в моих интересах сделать так, чтобы об этом блоке узнали как можно быстрее все остальные. Потому что если я придерживаю свой блок, я повышаю риск того, что в это время кто-то другой добудет блок на той же высоте, и в итоге мой блок перешибет, и войдет не мой блок, а чей-то другой. Но выясняется, что если посчитать аккуратно все вероятности: с одной стороны, я беру на себя такой риск, с другой стороны, если я добыл блок, не раскрыл его и начал майнить следующий блок на базе моего, получается, что в этой ветке истории у меня есть преимущество, потому что я раньше начал майнить на своем блоке. Есть своя очередь, когда кто-то другой... В общем, все остальные. Давай так сформулируем: если моя ветка, которую я изначально не раскрыл, в итоге выиграет, то получается, что на этой ветке у меня было преимущество, а все остальные майнеры, пока я секретно майнил на этой ветке, майнили в пустоту, потому что их ветки в итоге проиграют. И вопрос в том, где находится баланс и куда складываются вероятности: какая вероятность того, что выиграет моя ветка, выиграет чужая ветка. Дальше матан, матан, матан — вывод: нужно придерживать блоки при каких-то определенных условиях.

(00:47:58) Иван Иваницкий: То есть если упрощать, у меня сокращается вероятность, что мой следующий блок войдет в цепочку, но при этом я получаю некоторую вероятность, что следующие два блока будут мои, соответственно следующие две награды мои, и, вероятно, дальше еще потенциально третья, но там, наверное, уже маленькая вероятность.

(00:48:17) Сергей Тихомиров: Да, да, я бы так охарактеризовал. В общем, обобщая, что мне показалось интересным в этом докладе. Во-первых, еще расскажу из того, что докладчик рассказал: они провели исследование и анализ данных на реальном блокчейне Ethereum, стали выяснять, были ли такие атаки на практике применены, и пришли к выводу, что короткий ответ — нет. Есть пара случаев, где вроде как это могла бы быть такая атака, но есть вероятность, что это просто случайно так получилось. В общем и целом, если смотреть, то как будто бы известные игроки, которые, собственно, являются большими валидаторами, большими стейкерами и так далее, не рискуют своей репутацией и не пытаются вот таким крохоборством заниматься — типа вместо 25% получить 26,5%. Но при этом это же все видно, да, и видно, кто не раскрыл свой последний слот. В общем, гипотеза в том, что поскольку большие игроки в стейкинге все равно все известны, они просто не рискуют своей репутацией и не хотят ставить под угрозу свой бизнес. Но при этом докладчик еще сказал, что они подавались на грант от Ethereum Foundation с целью исследовать глубже этот вопрос и, возможно, предложить какое-то решение и противодействие таким атакам, но их предложение не было принято, не дали им грант в итоге — что тоже, не знаю, показательное или нет. В общем, смешанные чувства. С одной стороны, я почему-то думал, что такая базовая атака тем или иным способом все как-то починена, а выяснилось, что просто на это забили и ничего не починили. Я не знаю, это возможно или нет. Опять-таки, может быть, криптографы профессиональные на это ответят, но вопрос лучше: есть ли криптографические техники, которые помогут починить эту проблему. Но я думаю, что такие техники, если они есть, они были применены — оказывается, что нет. Но при этом также оказывается, что на практике такого рода атаки не происходят, и, может быть, это просто и no big deal: можно просто принять, что да, система работает с такой потенциальной атакой, никто это не эксплуатирует, и вместо этого мы будем заниматься какими-то другими вещами.

(00:50:18) Иван Иваницкий: Забавно, что конструирование случайности на блокчейне в итоге страдает от недостатка случайности на блокчейне.

(00:50:25) Сергей Тихомиров: Для меня это не удивительно: то же говорили сторонники proof-of-work — что в proof-of-work случайность настоящая, потому что она так или иначе проистекает из физического процесса. Понятно, можно придираться к формулировкам: мы все равно исходим из предположения, что SHA-256 нельзя взломать в том смысле, что его output действительно случайно распределен. Но на этом предположении, в общем-то, все основывается: мы очень много где предполагаем, что хэш-функции работают так, как они должны работать. А в proof-of-stake как будто мы опираемся еще и на другие предположения и добываем рандомность из самой системы. Это такой циклический аргумент, и опять-таки интересно подумать, в чем биткоинеры были правы, а в чем — нет. Возможно, они были правы по сути, но их concerns не так влияют на реальный мир, как они опасались или как пытались нас предостеречь. То есть: может ли система добывать рандомность из самой себя? А чего стоит ваш стейк, если он в ваших же токенах, безопасность которых и обеспечивает их ценность? К слову, там был и другой аргумент: в Bitcoin-майнинге профессиональные майнеры уже закупились оборудованием — если они атакуют Bitcoin, оборудование подешевеет и станет бесполезным, поэтому они уже застейкали физическое оборудование. А в proof-of-stake системах ты стейкаешь ту же монету, безопасность которой обеспечиваешь. На что Ethereum говорит: «да и что». И так работает не только Ethereum, а в общем-то все остальные proof-of-stake проекты.

(00:51:59) Иван Иваницкий: У меня тоже возник вопрос «да и что»: если ты ее застейкал, получается, что ты заинтересован в ее безопасности даже в большей степени, чем если просто холдишь.

(00:52:05) Сергей Тихомиров: Этот аргумент тоже работает, конечно. Еще такой мета-вывод или мета-наблюдение, которое у меня возникло по итогам прослушивания этого доклада: когда исследователи разрабатывают криптографические и криптоэкономические протоколы, довольно часто — и это хорошо — люди исходят из довольно строгих предположений. Что у нас независимые рациональные акторы. Что у нас полностью анонимная система майнеров или валидаторов: никто друг друга не знает, никто не договаривается и не сговаривается, все просто считают, как калькуляторы, свои expected returns и действуют в соответствии с ними. А на деле выясняется, что и в Bitcoin есть олигополия майнинг-пулов, и в Ethereum — олигополия стейкинг-пулов. К обоим утверждениям можно приделать кучу звездочек и рассуждать, кто такие на самом деле майнеры, что такое на самом деле стейкинг, и Lido — это один стейкер или 100 тысяч стейкеров. Но так или иначе это все реальные entity, по крайней мере большие сущности, у которых десятки процентов стейка или майнинговой мощности и которые реально могут такие атаки применить и на что-то повлиять. Это компании, организации или люди, которые за кулисами друг с другом разговаривают. Не обязательно называть это сговором или чем-то злонамеренным: они просто друг друга знают, строят репутацию в сообществе и не хотят разрушать ее ради полутора процентов какой-то прибыли. Может быть, это просто естественный порядок, которым оперирует человеческое общество. Может, нам и не нужно закладываться на то, что все — такие шифропанки в черной маске, как хакеры на стоковых фотографиях, которые стучат по клавишам перед черно-зеленым экраном. А это просто люди и компании: на конференции съезжаются, друг с другом разговаривают и оказывают друг на друга некоторое социальное давление — давайте не разрушать экосистему, которую мы все вместе с таким трудом строим, не будем ради краткосрочной выгоды, пусть даже она есть на бумаге, если чисто математически посчитать. Если мы будем работать не обязательно прямо совместно, но хотя бы не атакуя друг друга напрямую, мы все вместе построим что-то большее, чем если будем такими строгими рациональными акторами.

(00:54:24) Иван Иваницкий: Плюс если говорить про этот переход от 25% к 26,6%: он все равно требует ресурсов на разработку. Даже если репутационные риски мы отложим в сторону — чего, видимо, не можем сделать — остается вопрос: оправданы ли эти затраты ради 1,6%? И то эти 1,6% — в случае, если у нас уже есть 25% стейка, а если меньше, то выгода соответственно непропорционально меньше.

(00:54:55) Сергей Тихомиров: Да, в итоге на практике люди приходят к выводу, что оно того не стоит. Еще одна тема на конференции — несколько докладов было в этой тональности, я бы так это обозначил: люди говорили про MEV, про order flow и про различные инфраструктурные вещи — как бы транзакции быстрее распространялись и быстрее доходили туда, куда им нужно. Я несколько обобщаю несколько докладов, в подробности здесь, наверное, не очень получится углубиться, но TLDR: люди активно думают и разрабатывают решения, как все ускорить, при этом — моя уже интерпретация — постепенно, или даже не так постепенно, забивая на децентрализацию. Условно говоря, изначальная архитектура была такой: транзакции должны распространиться по всей сети, чтобы все узлы знали о новой транзакции. Современный высокопроизводительный блокчейн говорит: нет, давайте это не будем делать, это слишком затратно. В результате работы механизма, похожего на RANDAO, о котором мы говорили раньше, все и так знают, какой будет следующий валидатор в следующем слоте — так давайте засылать транзакции прицельно прямо к нему, потому что мы и так знаем, что именно он будет их обрабатывать, или к нескольким следующим валидаторам. Понятно, что это несколько централизует весь процесс вокруг этих валидаторов, но зато это быстро. Одно направление мысли, которое активно развивается. Второе направление, которое тоже активно развивается и на котором, как я понимаю, уже построены и Solana, и другие альтернативные высокопроизводительные блокчейны — в частности упоминался Monad: давайте исполнять транзакции параллельно. Почему так медленно все исполняется на EVM или на других, скажем так, более зрелых протоколах? Потому что все исполняется друг за другом. А почему друг за другом? Потому что есть зависимость по стейту: мы не знаем, какой стейт изменит транзакция номер N, поэтому пока она не завершится, мы не можем запускать транзакцию номер N + 1. Окей, говорит условная Solana, а давайте обязуем каждую транзакцию заранее анонсировать, какую часть стейта она собирается потрогать или изменить. Тогда мы будем знать, как распределять транзакции, и те, которые заведомо не конфликтуют, распихаем по разным тредам и исполним параллельно. Замечательно — нет, правда замечательно: если это работает, то круто. Также люди думают, как быстрее распространять по сети блоки или вообще данные. В частности, в направлении: давайте порежем блоки на маленькие кусочки, возможно с какой-то избыточностью — условно говоря, порезали на 10 кусочков, и любые 7 позволяют восстановить изначальные данные. И эти кусочки будем стратегически распространять по определенным узлам в определенном порядке, чтобы они собирались в разных местах параллельно. И last but not least: давайте просто увеличим hardware requirements и потребуем, чтобы в нашем новом блокчейне узлы были еще более жирными — с еще большим количеством памяти, процессоров и так далее. Мне показался любопытным, в частности, доклад человека из компании X1 Labs. Как я понял из его доклада, они запускают или собираются запустить новый layer-1 блокчейн и выбирали для него технологический стек. Мне понравился их подход: виртуальных машин много, блокчейнов много — давайте выберем стек, на котором запускать наш новый блокчейн. Что интересует в первую очередь? Производительность: как я понял, предполагается высокопроизводительный блокчейн. Давайте возьмем уже развернутые текущие блокчейны и нагрузим их по максимуму: развернем какой-нибудь свой токен, отправим триллион — ну сколько-то, много — транзакций и посмотрим, как текущие блокчейны справятся с этой нагрузкой. Забавно, что они даже попытались так застресс-тестить Bitcoin: запустили свой токен в формате BRC-20, невероятно подняли комиссию на Bitcoin и убедились, что Bitcoin им не подходит. Также что-то запустили на EVM, заняли большое количество стейта на EVM, и на Base, и на Cosmos, и на Solana — в общем, всех заспамили. Может, термин чуть жестковат, но кучу транзакций отправили во все блокчейны, померили, что где работает и как поднимаются комиссии. Как я понял, итог: больше всего им понравилась Solana — она лучше всего способна выдерживать такого рода нагрузку. Мысль, которую я записал и которая мне тоже показалась интересной на подумать, — про централизацию block building в Ethereum и вообще централизацию широко понимаемых валидаторов на высокопроизводительных блокчейнах. Есть довольно распространенное направление критики: у вас, конечно, очень быстрый блокчейн, но чтобы стать его полноценным участником — валидирующим узлом или производителем блоков — нужен супермощный компьютер, это может существовать только в дата-центрах. Соответственно, мы централизуемся вокруг дата-центров, все под контролем AWS, Hetzner, DigitalOcean или других облачных провайдеров — и, соответственно, все плохо.

(01:00:02) Иван Иваницкий: Здесь, видимо, хороший момент, чтобы упомянуть нашего спонсора Fluence.

(01:00:05) Сергей Тихомиров: Да, да, разворачивайте производительные блокчейны на Fluence — интересно, потянет он или нет, если развернуть Solana-узлы и отправить миллиард транзакций, что будет. Интересно, кстати, стресс-тест произвести. Так или иначе, автор доклада говорит, что увеличение требований по hardware вообще не проблема. Потому что в реальной жизни, если посмотреть на структуру расходов валидаторов, расходы на hardware не являются ее основной частью. Основной барьер к тому, чтобы стать валидатором на Ethereum, на Solana и так далее, — это то, что нужно принести стейк. Именно финансовые барьеры здесь определяющие. Докладчик про Solana в этом ключе говорил, что распространяется антисолановский fud по поводу того, что для Solana нужны очень высокие спеки hardware, а на деле более 90 процентов затрат валидаторов — это то, что, видимо, в терминологии Solana называется vote cost, то есть, грубо говоря, стейк. При этом наблюдается перераспределение стейка в сторону больших валидаторов, то есть централизация по этому направлению. И что вызывает, как я понял, обеспокоенность у докладчика: из 1400 валидаторов только 400 сами окупаются. К этому утверждению можно задать очень много вопросов, но это цитата, которую я записал из доклада: только относительно небольшая часть валидаторов реально окупает свою работу. Я, видимо, продолжаю мысль — наверное, это хотел сказать автор в итоге: большие валидаторы выживают и процветают, а маленькие проигрывают в конкуренции. Мысль, которую предлагаю подумать: насколько вообще определяющими являются затраты на hardware в сравнении с финансовыми затратами на стейк, и так ли нужно беспокоиться о затратах на hardware, если вход на рынок валидаторов все равно закрыт финансовым барьером — что-то про staking pool, Lido. Потрясающе.

(01:02:00) Сергей Тихомиров: О чем еще хотелось бы поговорить — про нашу любимую тему, которую мы освещаем регулярно: централизация rollups и то, насколько rollups не децентрализованы. Наша любимая организация — моя, по крайней мере, любимая — L2Beat была представлена на конференции. И Басти из этой компании — не знаю, правильно ли назвать ее компанией — из L2Beat провел такую… «фейковую» — неправильное слово. В общем, заголовок его доклада был Golden Raspberry Awards of Ethereum Scaling. Golden Raspberry — это как Шнобелевская премия, как Оскар, но смешной пародийный, сатирический Оскар для тех, кто на самом деле какую-то фигню снял. Так и здесь у нас такой пародийный Оскар за scaling, который на самом деле не scaling — ну, то есть он может быть и scaling, но он не децентрализованный. Пока мы записывали этот выпуск и монтировали его, уже произошла знаменитая re-categorization на L2Beat — буквально даже когда мы записываем этот выпуск, она произошла, а на момент доклада еще не произошла. Идея в том, что L2Beat переклассифицировал проекты, которые показывает на своей главной странице, и перестал считать rollups то, у чего нет никакой proof system. В общем, критерии стали более строгими, чтобы хотя бы попасть на эту главную страницу. А если ты централизованный, то уходишь на вкладку Others и там тусишь с другими централизованными чуваками. В частности, какие были номинации и кто в них победил? Номинация Most Overloaded Security Council, победитель — StarkNet. Собственно, в чем история? Что такое Security Council? Все знают, что есть Security Council у Организации Объединенных Наций, но у rollups тоже есть свой совет безопасности. Что обычно имеется в виду? Это некоторый multisig, который должен обладать полномочиями на случай экстренных событий. Например, если выяснится, что rollup взломали и высасывают из него деньги, Security Council вступает в дело и, например, останавливает rollup, замораживает деньги, обновляет код смарт-контракта — делает что-нибудь экстренное. При этом предполагается, что такого рода полномочия должны активироваться только в случае реальной угрозы всей системе, а на обычную каждодневную операцию не должны оказывать влияния. Но у StarkNet, похоже, это не так. У них есть multisig, у них есть Security Council: действительно, там 12 ключей, и консенсус 9 из 12 действительно может использоваться для экстренных обновлений. Но при этом на том же multisig с теми же ключами консенсус 3 из 12 просто финализирует состояние — то есть просто оперирует rollup. И rollup не считает свой стейт финализированным, если 3 из 12 ключей его не подписали. Это как будто нарушает изначальное видение rollups, которые должны, по мысли автора доклада — и, в общем-то, я с ним согласен — по максимуму наследовать безопасность из базового уровня. То есть не должно быть, по идее, никакой прослойки между гарантией безопасности первого уровня и гарантией безопасности rollup, кроме вот этой механики оспаривания, механики вывода, которые, я думаю, мы тоже много раз обсуждали. Окей, действительно, мне кажется разумным хотя бы на первом этапе иметь этот Security Council для обновлений и каких-то экстренных действий. Но мне действительно кажется несколько странным, что мы не просто доверяем этому совету на экстренные случаи, а доверяем ему каждый день: каждый блок подписывается участниками этого совета. Немножко странно. Мораль автора доклада: Security Council окей для экстренных обновлений, но не окей для того, чтобы подписывать блоки.

(01:05:32) Иван Иваницкий: А что конкретно произойдет, если они не подпишут блок?

(01:05:35) Сергей Тихомиров: Видимо, rollup тогда никуда не продвинется. Я немножко додумываю, но если rollup ожидает, что каждый state transition будет подписан quorum из этого multisig, и он не будет подписан, то он не финализируется. Если участники, которые предполагалось, что подпишут, не подписали, дальше какое-то другое подмножество трех из 12 ключей вступит в игру и таки подпишет этот блок. Я думаю, здесь concern в том числе и цензурный, и с точки зрения sequencing. В общем-то, этот multisig, эти три из 12 операторов, в целом полностью контролируют то, что происходит в rollup — по крайней мере с точки зрения цензуры. Понятно, что они не могут произвести невалидный state transition — не могут. Но они могут кого угодно не пустить или переупорядочить транзакции так, как им хочется.

(01:06:29) Иван Иваницкий: А в чем необходимость существования этого Security Council?

(01:06:32) Сергей Тихомиров: Видимо, просто — я тоже сейчас немножко фантазирую и додумываю — может быть, разработчики посчитали, что раз уже есть Security Council, можно его просто переиспользовать, чтобы не пропустить какой-то невалидный state transition. Я на самом деле не очень понимаю — сейчас пытаюсь это объяснить, у меня нет полного понимания. Формально это же ZK rollup, правильно? Как будто бы ZK должен обеспечивать безопасность переходов состояния. Но на практике — это не из доклада, а просто какое-то общее знание, которое у меня есть — ZK proofs не производятся под каждый блок. Как раз отдельный большой аспект, который обсуждался на другой конференции, которую мы, возможно, вкратце упоминали в прошлом выпуске: House of ZK Proofs Summit. Была такая однодневная конференция, где очень подробно обсуждалась перспектива так называемого real-time proving: как бы нам успеть произвести ZK proof за то время, пока производится следующий блок. На деле сейчас это не так. Может быть, сейчас, пока я пытаюсь это объяснить, я таки выплыл на какое-то разумное объяснение. Представь: у нас ZK rollup, производятся блоки, но ZK proofs, которые докажут корректность этих блоков, подъедут только послезавтра или через три часа. А мы хотим, чтобы стейт уже финализировался, чтобы люди могли рассчитывать, что их деньги пришли или ушли куда нужно. Поэтому у нас будет Security Council, который в ожидании этого ZK proof будет подписывать: этот стейт валидный, мы проверили, trust me, bro. А потом подъедет ZK proof и действительно все заверит — и тогда уже будут криптографические гарантии безопасности. Окей, следующая номинация — самая долгая пауза. Не очень понятно объяснил, в общем. Superchain получил эту номинацию. Как я понимаю, речь о том, что в optimistic rollups есть период оспаривания: период, за который rollup не считается полностью финализированным, и противоположной стороне предоставляется возможность оспорить какой-то переход состояний. В случае Superchain эта возможная пауза, как я понял — может, я что-то не понял и сейчас говорю не о том — будто была вообще бесконечной, а стала 6 месяцев. Может быть, я не понял докладчика: здесь звучит как-то странно, особенно бесконечная пауза звучит странно. Но, опять-таки, мораль, как я понял: нужно делать так, чтобы этот период был все-таки какой-то разумной длины. Нужно, конечно, обеспечить возможность оспаривания, но не месяцами же. Потому что получается, что у нас полгода, строго говоря, нельзя считать деньги пришедшими или ушедшими куда нужно.

(01:08:55) Иван Иваницкий: Да, но мне, честно говоря, и более-менее стандартная одна неделя плохо понятна. Условно, если эти деньги пришли: если я правильно понимаю, в ряде случаев я еще не могу их использовать эту неделю, в ряде случаев могу использовать, но если на самом деле произойдет оспаривание и они не пришли — то произойдет reorg или нет? Плюс я с какого-то — может, не помню, с какого — чейна бриджил токены и ждал неделю: не то чтобы это был хороший user experience. А если мы говорим про бесконечность или 6 месяцев — звучит очень много.

(01:09:30) Сергей Тихомиров: Поправьте нас, если мы вдруг что-то не так поняли, может, это вообще не про то речь, но мне кажется, это именно про то. Еще одна номинация, Least Available Data, получает приз EigenDA. Как следует из названия, EigenDA — это что-то про Data Availability. И люди придумывают всевозможные аббревиатуры, чтобы, скажем так, скрыть элементы централизации, которые они привносят в архитектуру. Как у нас там есть Security Council теперь — типа multisig, который подписывает state. Так и в случае с Data Availability у нас есть аббревиатура Data Availability Committee, то есть комитет по доступности данных: тоже некоторый multisig или некоторая совокупность акторов, которые по идее должны обеспечивать доступность данных. Но кто сказал, что в этом комитете должно быть больше одного человека или больше одной организации? Ну, это просто одна организация. В общем, из моих заметок не очевидно, честно говоря, для меня сейчас, что из этого относится конкретно к EigenDA, а что просто к бомбежу докладчика про то, как делать не нужно и как многие делают. Но в общем-то идея в том, что когда мы говорим про Data Availability, Data Availability подразумевает, что данные должны быть доступны. Что такое «доступны»: в идеале, конечно, хорошо бы, чтобы не один какой-то человек и не одна организация контролировали эти данные и давали к ним доступ. Также, я думаю, многие наслышаны про так называемые DA layers — какие-то отдельные проекты, блокчейны, сети, как их ни назови, которые обеспечивают доступность данных. Но здесь тоже, как правило, аккуратно обходится вопрос: строго говоря, как независимый юзер Ethereum rollup — представь, что у нас есть Ethereum rollup, который с одной стороны привязан к Ethereum тем способом, что туда можно отправлять disputes, но данные, с помощью которых эти disputes можно отправлять, хранятся не на Ethereum, а где-то еще, на каком-то data availability layer. И это означает для пользователя, если он действительно хочет в полной мере пользоваться гарантией безопасности, что у него должен быть доступ не только к Ethereum-ноде, но еще и к ноде вот этого data availability layer. И докладчик говорит: давайте смотреть на эти конструкции с точки зрения, скажем так, Ethereum-центричной. Вот у меня есть rollup на Ethereum — понятно, что мне, наверное, нужен доступ к Ethereum-ноде, чтобы в полной мере им пользоваться. А что еще мне нужно? Доступ еще к каким нодам нужен, как его получить, кто будет этим управлять? В общем, каждый дополнительный слой, который мы привлекаем, делает ситуацию сложнее для пользователя. Ну и четвертая, последняя номинация, Least Proven Proof System, получает проект под названием Metis — проект, про который я ничего не слышал раньше, но, похоже, он придумал гениальную историю. Это правда смешно, мне кажется: у него формально есть proof-система, но она не привязана собственно к rollup. И что это означает с точки зрения пользователя: пользователь может поиграть в challenge-игру и оспорить на первом уровне неправомерный переход состояния на втором уровне, но чтобы это решение первого уровня вступило в силу, ему нужно прийти к multisig, который контролирует второй уровень, и сказать: уважаемый второй уровень, вот решение суда, которое я получил на первом уровне, пожалуйста, верните мне мои деньги. То есть как будто ты подаешь на кого-то в суд — условно на мошенников, которые у тебя забрали деньги, — а потом к ним же идешь с решением суда. Ну, понятно… нет, какая-то аналогия мне сломалась по ходу. Короче говоря, что хочет сказать докладчик: если мы делаем систему оспаривания на первом уровне, так она должна enforce-иться автоматически. Не нужно делать системы, где чтобы законфорсить решение первого уровня, нужно еще у кого-то спрашивать разрешение — нужно просто, чтобы оно происходило автоматически. Не для этого ли нам нужен первый уровень — чтобы смарт-контракты, а это же в конечном итоге смарт-контракты, самостоятельно исполнялись? А люди придумывают всевозможные ухищрения, как сделать вид, что это так и работает, когда на самом деле это так не работает.

(01:13:21) Иван Иваницкий: Как раз с MetisChain я и выводил токены, типа USDT, 7 дней.

(01:13:26) Сергей Тихомиров: Так что теперь ты знаешь: даже если бы что-то пошло не так и ты это оспорил на первом уровне, тебе бы все равно пришлось идти к администраторам MetisChain, чтобы получить деньги.

(01:13:36) Иван Иваницкий: Честно говоря, я очень рад, что узнал об этом только сейчас.

(01:13:39) Сергей Тихомиров: Да, вот так. Еще был Q&A, где спросили, помимо прочего: окей, L2Beat, конечно, прикольная организация, все здорово делаете, а кто вам-то деньги платит? На что докладчик ответил, что они существуют на гранты и донаты. И что — как у меня записано, я, может быть, сейчас уже не совсем точно перевожу слова спикера, пересказываю — он сказал что-то в духе того, что даже какие-то dystopian entities могут, в принципе, нам донатить, но это не оказывает влияния на нашу редакционную политику. Что-то в этом духе он ответил. Это, конечно, интересно. Хотелось бы, чтобы они не заскамились, потому что мне очень нравится то, что они делают. И пока как будто кажется, что они действительно такой нейтральный арбитр и докапываются до вещей, до которых мало кто докапывается.

(01:14:23) Иван Иваницкий: Забавно, что этот вопрос с одной стороны как будто выглядит как ad hominem, но с другой стороны, конечно же, полностью валиден. Плюс очень большое любопытство у меня вызвало, что это за dystopian entities. Я так понимаю, если задать им этот вопрос, они отвечать не будут.

(01:14:39) Сергей Тихомиров: Опять, я, может быть, сейчас уже немножко искажённо пересказываю слова, но я так это прочитал и в моменте понял: не то что уже есть какие-то entities, просто мы вам не скажем какие, а что теоретически, даже если какой-то плохой актор нам даст денег, мы не будем следовать его указаниям. Я это прочитал так.

(01:14:57) Иван Иваницкий: Кстати, я задумываюсь, насколько это валидный take. Предположим, этот dystopian entity даст им очень много денег и даже ничего не скажет о том, как в связи с этим менять редакционную политику. Но они условно будут понимать, что от них могло бы ожидаться, и в любом случае будут думать: а как же нам теперь написать, чтобы через год или через два получить вторую порцию этого же огромного гранта. Здесь как раз его слова — что мы не будем менять редакционную политику абсолютно точно, вне зависимости от того, кто нам будет донатить — вызывают у меня больше подозрений. Потому что с какого-то момента, с какого-то размера цифры, точно будете.

(01:15:42) Сергей Тихомиров: Не уверен, что мне есть что ответить — это извечный вопрос. Видимо, можно сказать: если вы не хотите, чтобы ваш любимый проект спонсировал dystopian entity, то спонсируйте его сами и шлите донаты. Может быть, такое надо сделать.

(01:15:55) Иван Иваницкий: Типа, будьте сами dystopian entity.

(01:15:58) Сергей Тихомиров: Да. I am the danger, как говорится. Ну что, давай еще пару тем быстренько покроем. Тема, которая мне лично кажется очень интересной, — это роллапы на Bitcoin. Мне кажется, мы вкратце тоже про это упоминали, может быть, сейчас помянем еще раз. Такой проект, как Citrea, был представлен на Protocol Berg, где на докладе представителей Citrea шла речь о роллапах на Bitcoin.

(01:16:30) Сергей Тихомиров: Собственно, в чем идея, которая мне кажется очень элегантной — наверное, не совсем правильное слово. Давайте расскажу по порядку. Многие из нас хотели бы иметь ZK rollup на Bitcoin, потому что с одной стороны сама конструкция ZK rollup очень — тут уж я точно скажу — элегантна. Мы при помощи криптографии обеспечиваем валидность. Валидность инфорсится первым уровнем, а второй уровень обеспечивает нам масштабируемость при сохранении валидности, обеспеченной криптографией на первом уровне. Мне кажется, супер круто. И Bitcoin — это супер круто из-за своей безопасности, консервативности, proof-of-work, секьюрити и так далее. И люди уже несколько лет думали, как скрестить эти два аспекта, как сделать ZK rollup на Bitcoin.

(01:17:05) Сергей Тихомиров: Конечно, главное препятствие заключается в том, что Bitcoin не умеет валидировать ZK proof на первом уровне. В Ethereum прямо есть opcode, валидирующий ZK proof, и таким образом может работать ZK rollup, где обновление стейта ZK rollup может финализироваться на первом уровне просто по конструкции — только если соответствующий zero-knowledge proof пройдет проверку. Все замкнуто на самой системе L1. В Bitcoin нет соответствующего opcode, и хотя были попытки какого-то research на эту тему, я не хочу сказать, что это безнадежное дело. Понятно, что возможно еще пять лет пройдет и напишут BIP, еще десять лет пройдет и его как-нибудь внедрят, но рассчитывать на это в краткосрочной перспективе я бы не стал. Как можно обойти это ограничение? И появляется проект BitVM, который предлагает решение. Собственно, на этой базе и построена Citrea, и видимо другие проекты тоже на этом построены. Идея в том, что эта конструкция совмещает в себе элементы ZK Layer 2 и оптимистичного Layer 2.

(01:18:04) Сергей Тихомиров: В частности, предполагается, что Layer 2 будет генерировать ZK proof корректности своего перехода состояний. И эти ZK proof будут действительно верифицироваться на Bitcoin, но без специального opcode. А как же они будут верифицироваться? Люди думали-думали и сумели написать верификатор для ZK proof на языке Bitcoin Script — прямо на том языке, которым менеджатся транзакции в Bitcoin. Очень низкоуровневом, без понятия переменной, здесь все происходит на стеке. Как-то у них это получилось написать. Проблема в том, что этот верификатор занимает 800 мегабайт, и никаких надежд положить его он-чейн на Bitcoin нет. Чтобы обойти это ограничение, этот verifier разбивается на маленькие кусочки, и только тот кусочек, где возник потенциальный конфликт — мы рассматриваем ситуацию, где возник конфликт и нужно его оспорить, — кладется он-чейн на первый уровень и исполняется там. Не скажу даже, что это звучит просто, но в целом звучит разумно. Понятно, что есть большое количество технических челленджей, которые предстоит решить, чтобы это все заработало и стало реальностью. И доклад был про некоторые такие технические челленджи: про то, как Bitcoin используется для data availability, как он используется для этой верификации proof. Там отдельная еще история, куда именно нужно класть в Bitcoin данные, которые описывают state rollup. Я не уверен, что есть какой-то вывод из этого всего. В общем, мне интересно следить за такого рода проектами. Хотелось бы, чтобы на Bitcoin принесли что-то, что хотя бы отдаленно напоминает бурно развивающийся второй уровень на Ethereum. Пусть, как мы объяснили чуть выше, многие проекты и протоколы второго уровня на Ethereum довольно централизованы. Но оптимист бы здесь сказал, что эта централизация — временное явление, и от него в принципе можно отказаться. В принципе, можно спрашивать себя, есть ли мотивация у разработчиков вторых уровней на Ethereum действительно децентрализовываться. Но по крайней мере технические методы это сделать просматриваются. То есть в принципе можно сделать. Сделать что-то похожее на Bitcoin — мне было бы интересно за этим понаблюдать. Но пока что все это находится в довольно ранних стадиях разработки. Хотя, как я понимаю, это работает на testnet, на Mainnet пока не работает. И общая монструозность этой конструкции приводит к тому, что она окупается только для довольно больших сумм в биткоинах. То есть нужно довольно много биткоинов принести, чтобы это имело смысл. У меня не совсем сложилась арифметика в голове: не совсем понимаю, что именно дорого в этой системе и почему она может поддерживать только большие депозиты. Там где-то есть какой-то bottleneck, я предполагаю, который, возможно, плохо масштабируется от количества разных депозитов, поэтому мы хотим небольшое количество очень больших по сумме депозитов. Опять-таки, это само по себе не означает, что система будет бесполезна. Она, возможно, будет полезна просто для больших, возможно институциональных игроков, которые, как мы рассказывали в выпусках про доклад Messari, активно приходили в 2024 году и продолжают, как я предполагаю. Как минимум не уходят в 2025-м, а может и приходят тоже. Возможно, это история для них.

(01:21:16) Иван Иваницкий: Со своей стороны скажу, что оптимистичные ZK-роллапы на Bitcoin звучат очень впечатляюще и звучат как что-то, что имеет смысл забилдить даже просто because we can — без какого-то потенциального применения, а оно как будто бы здесь может быть.

(01:21:35) Иван Иваницкий: И вопрос, который у меня возник — мы, кстати, обсуждали его с тобой несколько дней назад за обедом. Я так понимаю, что Citrea — это EVM, но при этом бриджей на другие EVM там пока нет. Но учитывая, что это EVM, они могут быть. И дальше получается: если сама Citrea бриджит биткоин с Bitcoin на Citrea, и он становится ERC-20 у них, то потом не должно быть особых проблем забриджить его куда угодно — на Ethereum, на Polygon. И таким образом мы получим настоящий технически wrapped биткоин на Ethereum, что звучит довольно прикольно.

(01:22:15) Сергей Тихомиров: Да, согласен. Тут у меня, видимо, не хватает познаний в том, как реально работают бриджи на практике. Но конструкция, которую ты описываешь, как будто бы такова: чтобы потенциально сказать, что мой биткоин пришел из настоящего Bitcoin через Citrea на Ethereum или Polygon, я должен доверять двум мостам и принимать их модели безопасности. Возможно, это действительно feasible. Строго говоря, я не знаю. Я предлагаю всем желающим обратиться к документации Citrea и понять, что именно они имплементируют и как это возможно совмещается с другими EVM-проектами.

(01:22:51) Иван Иваницкий: Я, кстати, не знаю, как устроен тот wrapped биткоин, который сейчас существует на Ethereum, на Polygon. На Ethereum точно вроде есть, но мне почему-то кажется, что он устроен так: просто кто-то залочил у себя — или даже не залочил, а просто держит у себя — биткоин и говорит «честно-честно, вот этот wrapped биткоин обеспечен настоящим». Но я вообще ничего про это не читал, поэтому это предположение пальцем в потолок.

(01:23:17) Сергей Тихомиров: У меня точно такое же предположение. Я не слышал, чтобы какая-то другая, более децентрализованная модель реально внедрилась в практику, но опять-таки, может, я что-то пропустил.

(01:23:27) Иван Иваницкий: И по сравнению с такой моделью даже опора на модели безопасности двух бриджей звучит как более технически убедительное решение.

(01:23:38) Сергей Тихомиров: Наверное, последняя тема, которую мы осветим. В целом уже даже в этом выпуске мы упоминали главные тейки, но повторюсь и сошлюсь на пару докладов про ZK proving и interoperability между L2. Как я опять-таки понял из нескольких докладов, посвященных смежным темам, проблема в том, что Ethereum сделал ставку на rollup и на протоколы второго уровня. В результате мы имеем фрагментацию ликвидности и распределение юзеров по разным протоколам второго уровня и, что возможно самое главное, плохой UX при взаимодействии между этими уровнями. То есть история про то, что у меня что-то есть на Base, а я хочу что-то сделать на Arbitrum, — все это супер неинтуитивно для юзера. И люди активно думают над тем, как синхронизировать rollup и системы второго уровня между собой. В частности, сделать это при помощи ZK. Потому что в принципе не было бы такой большой проблемой какие-то токены залочить на одном rollup и разлочить на другом, если бы оба этих rollup могли убедиться в валидности переходов и там и сям. И эта валидность в принципе могла бы обеспечиваться zero-knowledge proof и криптографически действительно может быть так. Проблема в том, что proof долго производить. И люди активно над этим думают. Я пару докладов назову. Был доклад человека из компании ZK Cloud. Был доклад человека из Celestia. И большая часть докладов и панелей на уже упомянутой конференции House of ZK Proofs Conference — я немножко путать могу ее название — была посвящена именно этому. Как бы нам сделать так, чтобы разные системы достаточно быстро умели производить zero-knowledge proof и убеждать другие системы в валидности своего перехода состояний, чтобы та другая система могла какие-то токены залочить, разлочить и что-то по этому поводу сделать.

(01:25:31) Сергей Тихомиров: В этом смысле одну еще идею отмечу как раз из доклада ZK Cloud, где они разрабатывают в целом сеть prover-ов. И не только они это делают. Люди думают над тем, как сделать децентрализованную сеть, похожую на майнинг по механике, возможно отчасти на стейкинг, где люди предоставляли бы свою вычислительную мощность с целью производить proof для каких-то транзакций. В целом это отчасти похоже на майнинг. И идея о том, как увеличить эффективность такой системы, в частности проистекает из того, как нам сделать так, чтобы уменьшить количество впустую потраченного compute. Строго говоря, проведя аналогию между майнингом и стейкингом: в майнинге у нас одновременно над одним и тем же блоком работают все майнеры. Они тратят свою вычислительную энергию, а в итоге блок добывает только один из них. Можно спорить с этим тезисом, но тезис может быть: это все впустую потраченные вычислительные циклы. Почему бы нам не сделать так, чтобы только один майнер производил эти вычисления и добывал блок? Что-то похожее сделано в proof-of-stake, где у нас известен валидатор на определенный slot, и только он производит блок — и все хорошо, наверное. Также и в терминах сетей prover-ов люди думают над тем, как сделать так, чтобы конкурирующие prover-ы не производили одновременно proof для одного и того же, а чтобы как-то выбрать одного, и только он один работал, а остальные отдыхали или делали что-то другое. И здесь тоже можно рассматривать системы, схожие с proof-of-stake. Давайте prover-ы принесут какой-то stake, мы их застейкаем и будем выбирать рандомно взвешенного по stake prover-а, который в следующем условно slot-е будет производить доказательства того, что нужно.

(01:27:15) Сергей Тихомиров: Конечно, здесь встречаются технические сложности. Не только у нас барьер на вход в виде высоких требований к оборудованию — потому что оборудование, которое может производить proof особенно быстро, довольно ресурсоемкое. Так еще, если мы будем требовать stake от prover-ов, это еще более ограничит круг возможных участников и приведет к централизации. Также, если мы будем требовать от prover-ов приносить какой-то stake, то — это отчасти reiteration предыдущего пункта, но рассмотренное под другим углом — они еще и теряют opportunity cost. В том смысле, что если у тебя есть свободные, не знаю, тысяча долларов или миллион, ты мог бы их принести на банковский депозит, вложить в US Treasuries, вложить в Uniswap pool или куда угодно в DeFi, и тебе бы какие-то проценты капали. А здесь ты должен запирать их в сети prover-ов, и хорошо бы, чтобы эта сеть тоже давала тебе сопоставимый доход, иначе у тебя не будет никакого аргумента так делать. И restaking упоминался в этом докладе как возможный выход, возможный элемент архитектуры. Очень много говорили про EigenLayer в прошлом году — не знаю, сейчас говорят или нет, может быть не в такой степени, но в принципе идея отчасти понятная. Давайте один и тот же stake, один и тот же финансовый, экономический commitment разделим, чтобы он обеспечивал безопасность сразу нескольких вещей. Здесь автор доклада говорит: окей, мы можем посчитать, в частности для EigenLayer взять общий TVL всех AVS — непонятно сказал. В общем, AVS — это тоже термин EigenLayer, собственно сервисы, которые валидируются при помощи restaking. Короче, что пытался сказать автор — а я сейчас пытаюсь очень неуклюже пересказать — что довольно предсказуемо при restaking безопасность распределяется. И если у вас был один доллар, вы его застейкали, а потом зарестейкали и еще раз зарестейкали, то у вас не получилось в каждом из протоколов безопасность, соответствующая одному доллару. Она очевидно ниже: этот доллар разделился в обеспечении безопасности между разными вещами. И в частности, если провести такой быстрый подсчет — какой у нас общий TVL всех проектов, безопасность которых обеспечивается EigenLayer, в сопоставлении с TVL самого EigenLayer — получается коэффициент примерно 13. То есть, как я это читаю, если в EigenLayer лежит 13 долларов, то на самом деле безопасность, которую покупает каждый из проектов, соответствует всего лишь одному доллару. В общем, про это нужно помнить.

(01:29:43) Иван Иваницкий: Да, меня с самого начала смущала эта хитрость с restaking и использованием одного и того же stake для безопасности разных вещей. То, что ты сейчас сказал, на верхнем уровне вроде понятно, но можешь ли ты сформулировать это в терминах конкретной атаки? Что значит, что этот доллар распределяется?

(01:30:07) Сергей Тихомиров: Я бы сформулировал так: повышаются риски. Если ты стейкаешь в Ethereum, то берешь на себя риск, что тебя заслэшат, если ты сделаешь double sign, например. Или если твой staking pool provider, через которого ты стейкаешь, сделает double sign или приведет какую-то другую атаку на протокол. В принципе, вероятность этого в таком устоявшемся протоколе с большим количеством профессиональных участников, как Ethereum, как будто небольшая — какие-то доли процента, допустим; я на самом деле не знаю сколько.

(01:30:37) Сергей Тихомиров: А потом ты берешь тот же stake и в такой же роли используешь его для гораздо менее устоявшегося протокола, где меньше участников, они менее профессиональные, и больше риск, что весь этот протокол — это скам. Ты используешь тот же капитал для обеспечения менее безопасного протокола и как будто повышаешь свои риски: обратные вероятности умножаются. Если изначально у тебя был один процент того, что что-то пойдет не так, у тебя 99% вероятности, что все пойдет так.

(01:31:09) Сергей Тихомиров: Дальше ты то же самое переиспользуешь в протоколе, где уже 10% вероятность, что что-то пойдет не так, и соответственно 90%, что все пойдет так. Вероятность того, что все будет хорошо в конце, — это 99 на 90, и это уже около 90%, если посчитать. Вероятности умножаются, поэтому риск накапливается.

(01:31:27) Иван Иваницкий: Да, а что значит «все будет хорошо в конце»? Условно, если этот риск реализовался на протоколе, где я зарестейкал, что это значит для протокола, на котором я исходно застейкал — например, Ethereum, где профессиональные участники?

(01:31:42) Сергей Тихомиров: Честный ответ — я не знаю, боюсь соврать, но хочется сказать, что если тебя заслэшат, ты потеряешь свой капитал. Скорее всего, это не так просто и происходит через опосредованный уровень — токены restaking-протокола, и, наверное, они слэшатся в какой-то пропорции, что-то в этом духе. Не буду фантазировать. Если вы понимаете лучше, как это устроено, поясните, пожалуйста, в чате или приходите на подкаст, чем черт не шутит — от всей темы restaking на подкасте было бы интересно.

(01:32:12) Иван Иваницкий: Да, было бы круто, потому что это не первый раз, когда я задаюсь этим вопросом, и это одна из немногих тем, где мой мозг реально буксует и я не понимаю, что там происходит. В том числе потому, что я не разбирался в этом особенно глубоко.

(01:32:25) Сергей Тихомиров: Ну что, я думаю, на этом можно завершать. Я рассказал обо всех докладах, которые мне хотелось осветить подробно. Еще несколько докладов тоже в целом были интересные. Посмотрите оглавление конференции — думаю, вы найдете для себя много интересного по своим предпочтениям. Записи, к сожалению, пока нет. Конференция шла прямой трансляцией в видео, но на сайте записи пока нет. Думаю, они появятся: с прошлых ивентов того же департамента децентрализации записи рано или поздно появляются, может, спустя месяцы — но keep an eye on it, как говорится. Спасибо большое, Ваня, за вопросы.

(01:33:03) Иван Иваницкий: Да, спасибо большое, Сергей, что выбрал интересную конфу, сходил на нее, выбрал интересные доклады и так содержательно их просуммировал.

(01:33:13) Сергей Тихомиров: Да, спасибо большое. Спасибо организаторам конференции за организацию. Я с нетерпением жду следующих ивентов от этой команды и постараюсь на них сходить. И если это покажется интересным и уместным — рассказать об этом в том числе в нашем подкасте. Завершаем этот выпуск. Спасибо большое за внимание. Заходите в ББ-Чат в Телеграме, заходите к нам на сайт basicblockradio.com — там есть все ссылки на наши платформы, все выпуски, гости и так далее.

(01:33:47) Сергей Тихомиров: Мы говорим спасибо нашим патронам на Patreon и Boosty, а также нашим спонсорам. Это Acki Nacki, the fastest blockchain possible. Это Zerion, Enterprise-grade Web3 API, и Fluence, децентрализованная облачная платформа. До новых выпусков. Всем пока.