Коротко: команда Firedancer (Jump Crypto) предложила после апгрейда Alpenglow полностью убрать фиксированный лимит вычислений в блоке Solana — сейчас это 60 млн CU на блок. Вместо админ-потолка предлагается динамический подход: производитель формирует столь «тяжёлый» блок, сколько успеют обработать быстрые валидаторы; медленные могут такой блок пропустить. Это способ повысить реальную пропускную способность, но тема тут же упирается в баланс производительность ↔ децентрализация.  

Контекст: что такое CU и зачем вообще стоял потолок

Compute Unit (CU) — «вес» вычислений транзакции. Чем контракт сложнее, тем больше CU он «съедает». Жёсткий лимит 60 млн CU на блок нужен, чтобы узлы не «захлебнулись» при пиках нагрузки; весной в экосистеме обсуждали более мягкий вариант — просто поднять планку до 100 млн CU. Новая инициатива идёт дальше: не просто поднять, а снять фиксированный предел.  

Почему «после Alpenglow»

Alpenglow — крупнейшее обновление протокола, цель которого — довести реальную финальность до порядка 100–150 мс (вместо ≈12,8 с до апгрейда), упростить форк-выбор и вынести голосование из «горячего пути». Идея «раскрытия» блоков привязана именно к этой фазе: при субсекундной финальности сеть способна устойчивее переваривать большие блоки без деградации UX. Сообщество валидаторов ранее демонстрировало близкое к единогласному одобрение курса на Alpenglow.  

Как будет работать режим без фикс-потолка

• Производитель блока упаковывает больше операций (выше доход с комиссий и чаевых).
• Быстрые валидаторы успевают применить блок и проголосовать.
• Медленные валидаторы скипают избыточно «тяжёлый» блок — теряют долю дохода и получают стимул обновить «железо»/клиент.

Ранее обсуждался промежуточный шаг — до 100 млн CU (SIMD-0286). Предложение Firedancer (SIMD-0370) — уже архитектурная смена логики, где рынок (комиссии и пропуски) сам подталкивает участников к апгрейду.  

Фи-рынки и приоритизация: почему это не превратится в «хаос»

Чтобы «раскрытые» блоки не сломали предсказуемость, в Solana уже есть механизмы сглаживания пиков: локальные фи-рынки (по аккаунтам/ресурсам) и stake-weighted QoS (пропускная способность на узел растёт вместе со стейком). В итоге перегрев одного «горячего» аккаунта не расплескивается на всю сеть, а валидаторы с большей ответственностью получают гарантированный канал на лидера.

Кому это выгодно прямо сейчас

• Ончейн-торговле и DeFi. Плотная упаковка операций снижает очереди и дроп транзакций, уменьшает «пилу» комиссий в пики (минты, листинги, сейлы).
• Играм и social/real-time dApp. Снижается латентность и улучшается предсказуемость отклика, появляется «голова» под сложные игровые ходы в одном слоте.
• DePIN/IoT-кейсам. Можно безопаснее собирать всплески телеметрии и расчётов без длинных хвостов подтверждений.

Риски и вопросы, которые нельзя игнорировать

• Требования к оборудованию. Чем «тяжелее» блоки, тем заметнее разрыв между топ-конфигурациями и «минималками». Риск — сжатие набора валидаторов и ухудшение децентрализации. 
• Безопасность «скипа». Нужно гарантировать, что массовые пропуски тяжелых блоков не ударят по живучести сети и не создадут новых векторов для атаки (например, целевого «перегруза» отдельных сегментов валидаторов).  
• Эффект на MEV и очередность. Чем выше вместимость, тем больше стратегий арбитража и сэндвича поместится в блок. Требуются правила/рынки, которые не вытеснят обычных пользователей.

Сравнение подходов: «прибавить до 100 млн» vs «раскрыть полностью»

Исторически в мае обсуждался подъём лимита до 100 млн (SIMD-0286); текущая повестка — более радикальный подход Firedancer (SIMD-0370). 

Что именно меняет Alpenglow под капотом

Alpenglow пересобирает «критический путь» консенсуса: убирает узкие места, сокращает голосования в горячем контуре, добавляет более эффективный порядок финализации и форк-селекции. В результате сеть получает целевые 100–150 мс финальности и запас по пропускной способности при тех же физических ограничениях — это и открывает окно для «раскрытия» блоков.  

Рекомендации для валидаторов

• Производительность. Проверить CPU (высокая однопоточная + векторизация), ОЗУ, NVMe и сетевые интерфейсы. Протестировать пиковые «batched» нагрузки — не только TPS, но и «CU-плотность» блока.
• Клиент. Следить за развитием альтернативных реализаций (включая Firedancer) и их телеметрии. Своевременно обновлять флаги и параметры.
• Наблюдаемость. Настроить алерты по пропускам слотов, времени применения блоков, проценту «скипа» и деградации throughput.
• Резерв и отказы. Аудит избыточности: ingress, диски, маршрутизация, DoS-профиль.

Рекомендации для разработчиков dApp

• Оптимизация по CU. Даже при «раскрытых» блоках дорогие инструкции будут конкурировать — пересмотрите «горячие места» контрактов.
• Планирование пиковой нагрузки. Во время минтов/сейлов используйте очереди, батчи и контроль повторов; тестируйте UX при «больших» блоках.
• Комиссии и приоритизация. Учтите влияние локальных фи-рынков и stake-weighted QoS на вероятность включения транзакций. 

Чего ждать пользователям

При успешной реализации связки Alpenglow + «раскрытые» блоки повседневный UX станет ближе к веб-уровню: меньше «pending», меньше внезапных дропов в пике и более предсказуемые окна подтверждения. При этом возможны короткие периоды «раскачки», когда часть провайдеров инфраструктуры будет обновляться и подстраиваться под новые параметры.

FAQ (коротко)

См. также по теме (вики 24k)

• Proof-of-Stake: как работает консенсус
• Комиссии за вычисления (gas/CU)
• Комиссии в блокчейне