Solana начала переход на более короткие целевые интервалы производства блоков. Функция 350-миллисекундного слота уже активирована на слоте 440 208 000, то есть в первом слоте эпохи 1019, однако из-за задержки, предусмотренной в SIMD-0525, сеть сохранит действующий целевой показатель 400 мс до эпохи 1020, после чего перейдёт на 350 мс. Полный путь предполагает поэтапное сокращение до 350, 300, 250 и 200 мс. На тестовых кластерах продвижение уже дальше: тестнет работает с эффективным целевым показателем 200 мс, Devnet использует 300 мс и активировал порог 250 мс, который пока не стал эффективным.
Ключевое ограничение состоит в том, что более короткие слоты не должны повышать вычислительную нагрузку на валидаторов. В июльском журнале изменений Solana уже активировала максимальный лимит блока 100 млн вычислительных единиц (CU). По расчётам SIMD-0525, при сокращении целевого слота максимум на блок снижается: 87,5 млн CU при 350 мс, 75 млн при 300 мс, 62,5 млн при 250 мс и 50 млн при 200 мс. Таким образом, теоретический бюджет остаётся на уровне около 250 млн CU в секунду, то есть потолок вычислительных ресурсов не растёт, а лишь перераспределяется на более частые события планирования. Этот потолок не является прогнозом реальной пропускной способности: фактическая нагрузка зависит от типа операций и состояния сети.
Одновременно предложение сокращает послотовые бюджеты на запись аккаунтов, голоса, выделение данных, data-shred, coding-shred и разделённые вознаграждения. Цель — создать более частые возможности включения транзакций, не удваивая незаметно ресурсы, которые валидаторы должны обрабатывать каждую секунду. За лидером по-прежнему закрепляются четыре последовательных слота. При 400 мс окно лидера составляет 1,6 секунды, при 200 мс — 0,8 секунды. Это снижает время, в течение которого один лидер контролирует порядок, но также уменьшает запас на получение предыдущего блока, его повторное выполнение, построение нового блока и голосование.
Длительность эпохи из 432 000 слотов сокращается с примерно 48 часов при 400 мс до 24 часов при 200 мс. Валидаторы при 200 мс будут голосовать примерно вдвое чаще за единицу времени, что увеличивает активность и одновременно ужесточает окна синхронизации. Отмечается и проблема совместимости: часть SDK и внешних сервисов по-прежнему оценивает время, умножая число слотов на 400 мс, поэтому после ускорения такие оценки могут расходиться с реальным состоянием кластера.
Экономическая часть затрагивает механизм Alpenglow Validator Admission Ticket: если он активен, предлагаемая плата снизится с 1,6 SOL за эпоху при 400 мс до 0,8 SOL при 200 мс, что сохраняет ориентир около 0,8 SOL в сутки. Однако подтверждений того, что сбор VAT уже работает на каком-либо кластере, в опубликованных данных нет. Пока SIMD-0525 остаётся черновиком, а опубликованный 19 августа анализ Solana описывает инженерные и экономические компромиссы предлагаемого изменения. Более короткие слоты могут позволить информации чаще попадать в каноническое состояние и снизить зависимость от устаревших цен, но влияние на сэндвич-атаки неоднозначно и зависит от латентности реакции, конкуренции и пользовательского проскальзывания.
Таким образом, немедленное изменение на Mainnet — это 350 мс в эпоху 1020, а не одномоментный переход к 200 мс. Solana стремится ускорить ротацию возможностей включения транзакций, сохраняя ресурсные потолки приблизительно постоянными. Основной риск — смогут ли валидаторы и окружающая инфраструктура удержать координационные допуски на каждом новом этапе.
