Скорость разработки: команда производительности Anza изнутри — интервью с Alessandro Decina

Введение

Технооптимизм, несомненно, определяет дух культуры Solana. Безграничная вера в скорость, прогресс и инновации лежит в основе каждого pull request, который попадает в mainnet. Мантра звучит как IBRL: Increase Bandwidth, Reduce Latency. Это одновременно инженерный диктат, культурный пароль и светская молитва. Если Bitcoin — собор постоянства, а Ethereum — агора нейтральности, то Solana — гоночная трасса, царство измеримой механической скорости.

Но эта скорость не спускается с небес в виде аккуратно прокомментированного diff. Её добывают, шлифуют и воплощают те, кто готов целыми днями смотреть на код. Мало кто делает это упорнее, чем Alessandro Decina — в прошлом знаток GStreamer, воспринимавший зависания видеобуфера как личное оскорбление. Сегодня он руководит командой производительности Anza из четырёх человек — командой, для которой «забота о себе» означает удаление жёлтых полос из трейса валидатора в три часа ночи. Каждый день они изучают flame graph, выбрасывают целые рабочие процессы и переписывают проверенный в продакшене код, потому что всё, что можно оптимизировать, рано или поздно будет оптимизировано.

Я хотел понять, что значит жить на такой скорости. Поэтому я встретился с Alessandro Decina и узнал, как ему удаётся делать самый быстрый существующий блокчейн ещё быстрее. Это интервью — вскрытие скорости. Мы обсудили всё: от его работы с мультимедийными конвейерами до культурных принципов, благодаря которым четыре инженера выпускают больше, чем целые организации. 

Беседа отредактирована и сокращена для ясности и краткости.

Интервью

Истоки и мировоззрение

Ichigo: Если вернуться в прошлое, вашей первой любовью были GStreamer и мультимедийные конвейеры. Какие главные уроки о задержке вы вынесли из того периода? Чему работа со звуком и видео в реальном времени научила вас в плане сокращения задержки Agave на миллисекунды? 

Decina: Прежде всего, отличная работа по сбору информации обо мне, ха-ха. Я работал над GStreamer лет 15 или около того — может, чуть дольше. На самом деле именно там я узнал буквально всё, что знаю. Я начал участвовать в проекте, когда он был открытым и только зарождался. Мне очень повезло: тогда я сблизился с его основателем. Он был, не знаю, лет на 15 старше меня и действительно очень хорош. Этот парень есть в Wikipedia — наверное, он умный. Не то что я: я лишь притворяюсь умным. Он просто решил: да ладно, я бесплатно научу тебя всему, что знаю. Так я и начал над этим работать.

Забавно, что теперь, работая над Solana, мы говорим о низкой задержке, потому что это вообще не низкая задержка. Если речь идёт об обработке звука, DPS и мультимедийном оборудовании, то всё, что мы делаем в Solana, имеет огромную задержку. Если бы отклик звука или видео занимал 400 миллисекунд, система фактически считалась бы сломанной. Так работать невозможно.

В какой-то момент я начал работать с драйверами Linux и оборудованием для кодирования и декодирования видео и звука. По сути, многое из того, чем я занимаюсь сегодня, ничем не отличается от моей работы в те годы. При работе с оборудованием задержка означает, что где-то есть очередь. Вы находите эту очередь. Пытаетесь свести её к минимуму, сделать как можно короче и следите, чтобы в ней никогда не заканчивались данные.

Например, моя нынешняя работа над XDP очень похожа на работу кольцевых аудиобуферов. Даже во время нашего разговора множество пакетов поступает не по порядку. Где-то есть кольцевой буфер, который восстанавливает их порядок, и очень важно следить, чтобы в нём не заканчивались данные.

Такое чувство, что последние 20 лет я занимаюсь одним и тем же.

Как говорится, всё то же самое, только день другой. Я также заметил, что вы работали в Spotify и немного с Firefox—

Нет, работа с Firefox была лишь интеграцией для хакатона. Ха-ха, я настолько стар, что написал для Firefox оригинальный тег video, который использовал GStreamer.

Ничего себе, ха-ха. Выходит, все дороги ведут к GStreamer? 

GStreamer действительно научил меня многопоточному программированию. Именно благодаря ему я оказался в этой экосистеме. Некоторые пишут на Assembly и используют всевозможные низкоуровневые хаки. А я думаю: да, я давно этим занимаюсь. И я понял, что без языка со строгой системой типов и хорошим компилятором вы в итоге сами создадите себе проблемы. Наверняка на Assembly можно сделать что-то немного быстрее, но мне очень нужен Rust. 

Я хочу, чтобы компилятор Rust говорил мне: ты идиот — это не сработает, потому что здесь у тебя баг. До Rust я ощущал себя на 10% инженером-программистом и на 90% живым отладчиком. Я только и делал, что занимался отладкой. Поэтому думаю, что именно GStreamer и моя любовь к Rust привели меня к работе над Solana. Rust набирал популярность, вакансий с полной занятостью было не так много, а я решил работать только с Rust. 

Я слишком стар, чтобы писать на C. Мне не нужен язык без безопасной работы с памятью. Я не хочу тратить своё время впустую. Так что да, вот я здесь.

Отлично. Когда вы перешли в эту сферу, были ли у вас заблуждения о децентрализованных системах до начала работы над кодом валидатора? Что убедило вас в том, что архитектура Solana действительно способна масштабироваться? 

В итоге я присоединился к Solana почти на два года позже, потому что был занят работой над компилятором Rust. Кто-то из Solana, только начинавший работу над виртуальной машиной, прислал мне письмо: «О, я занимаюсь тем же самым. Похоже, вы продвинулись немного дальше — приходите работать с нами». Я не ответил, потому что изучил Bitcoin, затем Ethereum и понял, что там можно выполнять код, но у вас всего 10 TPS. Это несерьёзный проект, верно? С 10 TPS нельзя сделать ничего реального. 

Поэтому я не ответил на письмо. Я просто подумал: ладно, эти люди из криптоиндустрии пока несерьёзны.

Через два года со мной связался Toly, и я посмотрел на цену SOL. Я подумал: ладно, надо было открыть то письмо, ха-ха. На этот раз я всё-таки с ним поговорил. Перед разговором он показал мне какой-то код. Я посмотрел на него, и, честно говоря, код был ужасным. Это был действительно очень плохой код на Rust.

Но потом я поговорил с Toly, не погуглив его, поэтому понятия не имел, кто он такой. Он оказался умным и говорил правильные вещи. Он сказал: мы строим вот такую систему. Сейчас она работает так. Очевидно, это не передовой уровень, но наша цель — масштабироваться вместе с оборудованием. Мы создаём самый производительный блокчейн, чтобы узким местом стало оборудование. Идея в том, что чем больше оборудования вы добавляете, тем лучше система масштабируется.

И это меня убедило. Стало понятно, что это не просто сборище блокчейн-фанатиков, которые возбуждаются от мыслей о Третьей мировой войне… Меня интересует технология. Я один из тех немногих участников криптоиндустрии, кто действительно пришёл сюда ради технологии.

В инженерной культуре Solana технологии во многом определяются технооптимизмом — всей этой идеей Increase Bandwidth, Reduce Latency. Как вы лично к ней относитесь? Как она влияет на повседневную работу в Anza? 

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

Мне кажется, у нас всё наоборот. Мы говорим: ладно, есть проблема. Нерешаемых проблем не существует, кроме тех, решение которых нарушает законы физики. Это огромная культурная разница.

Если что-то сломано, мы просто говорим: хорошо, давайте сядем. Немного попрофилируем и посмотрим, в чём проблема. Поговорим с трейдерами и маркетмейкерами. Узнаем, с какими проблемами сталкиваются они. Недавно мы нашли несколько очень конкретных проблем. Большинство уже исправили. И, если честно, за два-три месяца можем исправить все остальные. 

Сегодня в Solana многое не работает. Мы знаем об этом и никогда не садились со словами: «У нас есть идеальное решение! А чтобы двигаться дальше, теперь нужно изобрести что-то новое, провести исследование или заняться чем-то ещё». Нет — это конкретные проблемы. Большинство из них совершенно глупые. 

Кроме того, в последнее время у нас не было сбоев. Лично я считаю это медвежьим сигналом. Думаю, некоторые стали немного консервативнее. Мы знаем, что можем работать намного быстрее. Мы знаем, что уже завтра можем обрабатывать блоки на 100 миллионов CU. Нужно лишь быстро довести до конца некоторые вещи. А я за то, чтобы быстро доводить до конца всё.

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

Мы знаем, как масштабировать эту систему.

Оптимизация производительности

Раз уж мы заговорили о производительности, думаю, мало кто знает, что в Anza есть отдельная команда производительности. Она как будто остаётся незаметной. Расскажите немного о структуре команды. Чем она отличается от других инженерных команд Anza? 

Да, в Anza есть разные команды. Сейчас у нас есть специалисты по консенсусу, которые сосредоточены на Alpenglow. Есть специалисты по сетям, которые в основном занимаются Gossip. Есть команда AccountsDB, работающая практически исключительно над базой данных аккаунтов. Есть команда производства блоков, которая занимается планировщиком. И, конечно, все остальные команды, о которых я забыл.

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

То есть мы не работаем над чем-то одним. Мы просто ищем следующее узкое место. Примерно раз в две недели синхронизируемся и решаем, где находимся, что делать дальше и как ускорить следующий релиз.

Есть ещё одно важное отличие: Anza старается нанимать умных людей. Не знаете Rust — ничего страшного. Не знакомы с низкоуровневым программированием — тоже ничего страшного. Мы считаем, что умного человека можно обучить большинству этих навыков в процессе работы. Но в команду производительности я обычно нанимаю людей с опытом работы с ядром или другими низкоуровневыми технологиями — этого требуют узкие места, с которыми мы сталкиваемся сейчас.

Например, в базе данных аккаунтов есть алгоритмические проблемы, которые нужно исправить. Но*,* причина, по которой в релизе 2.3 база данных аккаунтов работает примерно в десять раз быстрее, чем два месяца назад, заключается в том, что мы просто исправили способ выполнения I/O. Чтобы ускорить его, нужно понимать, как он работает. Если вы знаете базы данных только на высоком уровне, то не очень понимаете работу дисков, да вам и не нужно знать, как ядро планирует запросы I/O.

Поэтому лично я стараюсь нанимать в команду производительности больше низкоуровневых специалистов. Мне опять же неважно, знают ли они Rust, но я хочу, чтобы у них был опыт работы с C или C++ над другими низкоуровневыми задачами.

О команде производительности мало кто знает, потому что фактически она появилась только в декабре. Изначально меня наняли для работы над компилятором, но примерно во время сбоя в марте 2024 года я переключился на производительность и начал всё оптимизировать. Люди были не очень довольны, потому что однажды я просто заявил, что буду заниматься чем захочу. Так что да, ха-ха, они были недовольны, но затем мы получили отличные результаты. И люди начали подходить ко мне и спрашивать: «Ладно, может, хочешь нанять ещё людей для этой работы?» В декабре мы официально оформили направление производительности и создали команду.

Честно говоря, я предвзят, но команда производительности — лучшая команда в Anza. Безоговорочно и однозначно.

Не сомневаюсь, ха-ха. Сколько человек в команде? 

Нас четверо, и все работают полный день. Но в Twitter я шучу о присоединении Brooks и ещё нескольких человек, потому что начал предоставлять более широкий доступ к своему профилировщику. Ещё около двух месяцев назад он был доступен только специалистам по производительности. Теперь он есть у всех. Например, после того как я дал профилировщик Brooks, он занимается производительностью больше меня, ха-ха. Он полностью подсел. Теперь он просто ускоряет всё подряд.

Так что неофициально к нам относятся Brooks и ещё несколько ребят, которые тоже много занимаются производительностью. Но полный день над ней работают четверо. 

Когда вы работаете над производительностью, какие тревожные признаки при профилировании замечаете вы, но пропускает большинство инженеров? Как вы решаете, что нужно оптимизировать? 

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

Поэтому при профилировании главный тревожный признак — большое количество жёлтого цвета на flame graph: это означает, что мы проводим слишком много времени в ядре. Вероятно, кто-то использует безобидный на вид высокоуровневый API, который под капотом демонстрирует чудовищную производительность.

За последний год мы примерно в десять раз сократили объём памяти, используемой Agave, поскольку постоянно сталкивались с одной и той же проблемой. Если выделять память слишком часто, в определённый момент приходится начинать взаимодействовать с ядром. Это взаимодействие видно в профилировщике. Вы смотрите, откуда оно взялось. Видите, что эта цепочка постоянно перемалывает память. Прослеживаете её до места, где память непрерывно освобождается и выделяется в избыточном объёме, а затем исправляете проблему.

Есть и более сложные задачи. Например, мы обнаружили фундаментальную проблему архитектуры, которую я сейчас исправляю. Как известно, Solana использует конвейер с разными этапами. Предполагается, что всё распараллелено и выполняется одновременно.

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

Но, если говорить предельно откровенно, мы занимаемся глупыми вещами. Есть совершенно очевидные баги, и мы просто их исправляем.

Как вы решаете, достаточно ли для этих багов микробенчмарков или нужно полностью воспроизводить трафик mainnet? 

Думаю, большинство наших проблем с производительностью возникло из-за того, что люди писали микробенчмарки. Они ускоряли микробенчмарки. Тестировали их изолированно. А затем всё объединяли в Agave, и оказывалось, что ничто не работает так, как в микробенчмарках.

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

Отчасти поэтому мы так сильно ускоряем запуск: иначе каждый раз приходится ждать полчаса, чтобы проверить, работает ли исправление, а это раздражает.

Когда вы достигаете нынешней стадии Agave, нельзя глубоко погружаться в кроличью нору одного компонента. Возможно, такая работа интересна с интеллектуальной точки зрения, но совершенно бесполезна без учёта всей системы. На деле она ничего не продвигает вперёд. 

Если рассматривать систему целиком, почему перевод Turbine на XDP настолько важен? 

Непосредственно перед Solana я занимался сетями. Я работал в стартапе, который выполнял глубокий анализ пакетов. По сути, система перехватывала весь трафик, поступавший на NIC, анализировала его в реальном времени для блокировки вредоносных потоков, а затем возвращала в ядро. Фактически мы написали в пользовательском пространстве полноценный стек TCP и UDP с помощью Rust, Tokio и, конечно, XDP.

Когда я присоединился к Anza, было очевидно, что в какой-то момент нам понадобится XDP. Когда началась разработка Firedancer, они сказали: «Мы начнём с реализации Turbine на XDP», а я ответил, что это глупость. В этом не было смысла. Такой подход требует намного больше времени, потому что XDP объективно ужасный API. Поэтому его нужно избегать как можно дольше — пока колёса буквально не отвалятся.

А потом вы думаете: чёрт [вырезано], теперь придётся использовать XDP. Именно это и произошло с нами. Мы устраняли все остальные узкие места конвейера, пока однажды не запустили нагрузочные тесты и не увидели, что Turbine полностью перестал работать.

Мы поняли, что прежний подход явно больше не годится. Я очень, очень старался обойтись без XDP, потому что уже использовал его раньше и знал, насколько он ужасен. Я попытался создать реализацию Turbine на базе io_uring. Затем обнаружил несколько багов в io_uring. Начал их исправлять. У меня до сих пор есть несколько патчей ядра, которые я хочу отправить, но в какой-то момент я понял: я не могу потребовать, чтобы все операторы валидаторов использовали моё собственное ядро для запуска Solana.

Придётся использовать XDP — и мы это сделали. Теперь всё работает.

Ответ таков: находите следующее узкое место и исправляете его. А затем продолжаете исправлять все найденные узкие места. О завтрашних проблемах можно подумать завтра. Это мой девиз. Можно беспокоиться только о завтрашнем дне, но тогда сегодняшний будет ужасен. Сегодня в Solana всё плохо. Блоки слишком малы, Turbine создаёт слишком большую задержку, у планировщика всё ещё есть проблемы. Мы должны исправлять всё сегодня. Иначе не наступит завтра, в котором мы сможем работать так быстро.

Как вы защищаетесь от регрессий производительности? Как координируете работу с Firedancer? 

Бороться с регрессиями производительности сложно. Лично я каждый день что-нибудь профилирую в Agave — как минимум несколько раз в день, — и мы часто сталкиваемся с регрессиями, потому что написание производительного кода — отдельная профессия. Нужно уметь писать производительный код. В среднем код на Rust будет производительнее кода на Node.js, Python или чём-то подобном. Но если вы, например, работаете над AccountsDB с коллекциями из миллионов элементов, нельзя просто написать код. Эффективно проектировать алгоритмы и работать с большими наборами данных сложно. 

Поэтому иногда у нас случаются регрессии. Примерно до прошлого месяца я просто кричал почти на всех, ха-ха. Например, на Brooks из-за AccountsDB — думаю, в какой-то момент он меня ненавидел. У нас прекрасные отношения, но ещё месяц назад примерно половина нашего общения состояла из того, что я кричал на него, потому что что-то в AccountsDB стало работать медленнее.

Что касается протокола, сотрудничество с Firedancer улучшило ситуацию. Мне кажется, многие части протокола органически развивались в ответ на различные проблемы. Разработка протокола начиналась с идеи, которую выпускали в продакшен, а идеи, как это обычно бывает, не работают с первого раза. Тогда поверх них начинали добавлять новые элементы. Многие из этих дополнений были очень плохими идеями с точки зрения производительности.

Например, в Gossip существовал механизм под названием epoch slots, с помощью которого кластер фактически сообщал всем, какие валидаторы видели какие слоты. И примерно полгода назад, профилируя совсем другую систему, я случайно заметил, что с точки зрения CPU этот механизм epoch slots требует больше времени, чем непосредственное выполнение транзакций. А с точки зрения пропускной способности он потреблял в четыре раза больше ресурсов, чем Turbine. Это был просто случайный патч, который в какой-то момент добавили поверх протокола для смягчения одной проблемы.

Теперь такого больше нет. Отчасти благодаря Firedancer. Теперь, когда кто-то вносит предложение, мы должны работать с Firedancer. Очевидно, они создают другой клиент, ха-ха, поэтому им приходится планировать эту работу. Им нужно определить, сколько времени займёт реализация предложения. Каков его приоритет? Поэтому они спорят — к лучшему или худшему — со многими или почти со всеми нашими изменениями. И они очень хорошо умеют отклонять действительно плохие изменения. 

Когда выйдет Turbine с XDP, какую часть Agave вы бы оптимизировали или спроектировали заново в первую очередь, если бы у вас был месяц без встреч и конфликтов и вы могли бы заниматься чем угодно? 

Я очень хочу — мне это буквально снится — уже около двух лет я хочу переписать AccountsDB. Просто я знаю, что если начну, это буквально отнимет месяц или два моей жизни. Сейчас это не лучший способ потратить моё время. Но я это сделаю. Я всё пытаюсь заставить Brooks заняться этим, но если он не сделает, то когда-нибудь сделаю я.

Будущие разработки

Если смотреть в будущее и учитывать запланированные функции вроде Async Execution или Multiple Concurrent Leaders, что станет самой большой головной болью для команды производительности? 

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

Мне также не нравится архитектура Multiple Concurrent Leaders, ха-ха. Я понимаю, что несколько лидеров необходимы, особенно для высокочастотной торговли. Альтернативы нет. Но лично я считаю, что это появится не раньше чем через 12 месяцев. Поэтому не хочу слишком отвлекаться.

Важно, чтобы через год у нас был Alpenglow, но также важно, чтобы уже в следующем месяце мы обрабатывали сто миллионов CU. Нужно сосредоточиться на ускорении того, что есть сейчас, потому что Alpenglow — новый код и Multiple Concurrent Leaders — новый код. Есть неизвестные неизвестные. Допустим, по какой-то причине Alpenglow, как и Firedancer, отстанет от графика. Что тогда? Мы продолжим использовать нынешнюю паршивую медленную сеть? Нет, мы должны сосредоточиться на высокой скорости уже сегодня.

Советы по оптимизации производительности

Какие ресурсы вы порекомендуете человеку с опытом работы с Rust, который хочет заняться производительным кодом и профилированием?

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

Поэтому тем, кто хочет научиться работать над производительностью, я советую найти программу, которой вы пользуетесь каждый день и которую любите, профилировать её и ускорить, потому что многие программы работают очень медленно. Даже многие быстрые программы могут работать намного быстрее. Компьютеры действительно быстрые. И именно поэтому очень легко сделать что-то медленное и даже не заметить этого.

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

Ядро — такая же зависимость, как и любая другая. Когда вы над чем-то работаете и используете библиотеку, скорее всего, в какой-то момент вам придётся заглянуть внутрь неё, если что-то не работает, работает медленно или возникает другая проблема. Ядро — просто ещё одна библиотека. Поэтому,, читайте код ядра. Код ядра — один из самых простых, которые я когда-либо видел. Если посмотреть на планировщик в ядре, то концептуально он проще планировщика Solana. 

Просто откройте и прочитайте код Linux. Он написан на C, что не идеально, а всё, что взаимодействует с оборудованием, обычно проклято, ха-ха. Но большая часть Solana не работает с оборудованием напрямую. Найдите универсальный код, которым пользуетесь каждый день, например syscall, Tokio или код файловой системы. Это очень просто. Просто прочитайте его. Если потратить на это неделю, вы освоите его, как любой другой код. И почувствуете себя грёбаным гением. Будете думать: теперь я умею работать с ядром, понимаете?

Как лучше всего начать участвовать в разработке прямо сейчас?

Я предпочитаю, чтобы люди заходили в Discord и присоединялись к каналу разработки в Solana Tech Discord. Например, есть один парень, который занимается сетевыми компонентами. Недавно он просто начал обсуждение кода TPU. И, честно говоря, он понимает работу этого кода лучше большинства сотрудников Anza. То есть участвовать в разработке можно. И если вы так же хороши, как этот парень, и пришлёте мне патчи, я их солью.

Мы почти не ведём закрытую внутреннюю разработку. Поэтому, если вы не видите pull request для участка кода, который, по вашему мнению, работает медленно, хорошо его знаете,, и хотите исправить, сообщите мне в Discord. Мы создадим issue, назначим его вам, и вы всё исправите.

Я хочу, чтобы люди присылали мне патчи. Я действительно хочу развивать наше сообщество с помощью патчей.

Блиц-вопросы

Какой баг было сложнее всего исправить в этом году?

Ошибочная компиляция некоторого кода с плавающей точкой, которая всего пару месяцев назад блокировала релиз 2.2. Это был не самый сложный баг, но самый утомительный, потому что мне пришлось несколько дней читать код на Assembly.

Какую музыку вы слушаете по кругу, когда смотрите на flame graph? 

Обычно хаус или минимал-техно. Чаще всего по кругу играет Stephan Bodzin.

Какой у вас любимый дистрибутив Linux? 

Однозначно Debian. Это единственный дистрибутив, который не раздражает постоянно, ха-ха.

Какая лучшая оптимизация появится вместе с Alpenglow? 

Мы больше не будем выполнять голоса. Транзакции голосования — [вырезано]. И это прекрасно, что весь механизм голосования больше не состоит из транзакций.

Что вы думаете о ZK? 

Это отличная технология, но мне кажется, что в плане масштабирования блокчейнов она всё ещё находится преимущественно на стадии исследований. Поэтому мне она не особенно интересна. 

Июль 2026 года, через год. Какой будет продолжительность слота по вашему прогнозу?

Лично я хочу, чтобы слоты длились 200 миллисекунд, и надеюсь, что это произойдёт раньше. Я постоянно говорю Toly, что он должен превратить это в мем, чтобы оно стало реальностью. Надеюсь, к тому времени это произойдёт. Думаю, мы способны на это уже сегодня. Считаю 200 миллисекунд минимальным результатом в том смысле, что любое большее значение будет провалом, но мы можем добиться и меньшего.

Когда Agave наконец достигнет заветного миллиона TPS? 

Ха-ха, на этот вопрос короткого ответа не будет. Я постоянно спрашиваю людей: «Откуда возьмётся миллион транзакций?»

Мы достигнем миллиона TPS, когда людям понадобится отправлять миллион TPS, но, к сожалению, не думаю, что это произойдёт в ближайшее время. Я действительно сказал, что уволюсь, если Agave не достигнет миллиона TPS к октябрю. Так что, возможно, придётся состряпать липкую демонстрацию, ха-ха. 

Заключение

Alessandro Decina олицетворяет пульс культуры производительности Solana — неустанное стремление к скорости, основанное на прагматичной инженерии, а не на теоретическом совершенстве. Его команда производительности добивается результатов, намного превосходящих её численность: находит и исправляет «глупые баги», которые в совокупности приводят к системным замедлениям.

В мире, где многие команды теряются в грандиозных архитектурных замыслах, команда производительности Anza предельно сосредоточена на узких местах прямо перед собой. Профилировать, найти, исправить, повторить. Это негламурная работа с впечатляющими результатами: блокчейн действительно масштабируется вместе с оборудованием, а не в обход него.

Эта беседа раскрывает фундаментальную истину о создании высокопроизводительных систем: скорость зависит не только от хитроумных алгоритмов или передового оборудования. Она требует культурной готовности никогда не соглашаться на «достаточно хорошо», если технически можно добиться «отлично». Для Solana слоты по 200 миллисекунд, Async Execution, Multiple Concurrent Leaders и стабильная поддержка более миллиона TPS — не просто технические рубежи, а неизбежность.