Solana урезает лимиты вычислений на блок, чтобы новый разгон до 350 мс не перегрузил сеть

Цель Solana — сократить время слота в основной сети до 350 мс, что вступит в силу в эпохе 1020, по сравнению с текущим целевым значением в 400 миллисекунд. Функция активировалась в начале эпохи 1019, но задержка на одну эпоху означает, что сеть сохраняет свои текущие параметры до следующей эпохи. На практике блоки получают более короткий целевой интервал производства без увеличения допустимого объема вычислений в секунду.

Развертывание уже продвинулось дальше в других местах. Testnet работает с эффективным целевым значением 200 мс, в то время как Devnet — с 300 мс и активировал шлюз на 250 мс, но еще не сделал его эффективным. В списке изменений от 6 августа Solana был указан только шаг до 350 мс для двух тестовых кластеров, что показывает, как быстро продвинулись последующие этапы.

Аккаунт функции 350 мс в основной сети активировался на слоте 440 208 000, первом слоте эпохи 1019. В соответствии с задержкой, предусмотренной в SIMD-0525, основная сеть остается с эффективным целевым значением 400 мс на протяжении этой эпохи и переходит на 350 мс в эпохе 1020.

SIMD-0525 остается черновиком. Активация функции показывает, что конкретное изменение кластера распространяется по сети, а не то, что полный дизайн на 200 мс стал принятым окончательным стандартом. Цифры также являются целевыми значениями времени, которые отличаются от наблюдаемого производства блоков, задержки подтверждения и экономической завершенности.

Арифметика сохраняет потолок вычислений неизменным

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

В списке изменений от 30 июля Solana сообщалось, что основная сеть уже активировала максимальный лимит блока в 100 миллионов вычислительных единиц (CU). SIMD-0525 показывает, как этот максимум в 400 мс будет сочетаться с этапами времени слота: 87,5 млн CU при 350 мс, 75 млн при 300 мс, 62,5 млн при 250 мс и 50 млн при 200 мс.

Каждая строка дает примерно 250 миллионов CU теоретического максимального бюджета блока в секунду. Таким образом, сокращение целевого времени слота вдвое оставляет потолок вычислительной мощности блока в примере практически неизменным.

Этот потолок не является прогнозом пропускной способности транзакций. Фактическое использование зависит от рабочей нагрузки и состояния сети, а цифра в 100 миллионов является примером композиции для максимальных CU блока, а не универсальным базовым уровнем для каждого лимита.

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

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

Solana по-прежнему будет назначать четыре последовательных слота каждому лидеру. При 400 мс на слот это дает номинальное окно лидера в 1,6 секунды. При 200 мс окно сокращается до 0,8 секунды.

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

Таким образом, валидаторы сталкиваются с более жесткими допусками при передаче и распространении. Голосование и события gossip происходят чаще в одном и том же интервале реального времени, в то время как упаковка блоков и Turbine должны обеспечивать соблюдение меньших бюджетов, учитывающих слоты, после каждого отложенного перехода. Поэтапный дизайн сочетает свою цель по задержке с живым тестом координации на каждом шаге.

Время эпохи также сжимается. SIMD-0525 сохраняет каждую эпоху на уровне 432 000 слотов, поэтому номинальная продолжительность падает с примерно 48 часов при 400 мс до 24 часов при 200 мс. Количество слотов остается фиксированным, но его значение в реальном времени меняется.

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

RPC-клиенты, обозреватели и другие сервисы вне сети могут использовать расстояние между слотами для оценки свежести или прошедшего времени. Долгосрочное направление предложения заключается в том, чтобы программное обеспечение получало эффективные параметры времени от кластера, а не рассматривало константу времени компиляции как постоянную.

Пропуск валидатора Alpenglow (VAT) иллюстрирует экономическую версию этого несоответствия. Масштабирование в SIMD-0525 применяется только в том случае, если активен зависимый механизм VAT Alpenglow. В этом случае предлагаемая плата снижается с 1,6 SOL за эпоху при 400 мс до 0,8 SOL за эпоху при 200 мс, сохраняя приблизительную цель в 0,8 SOL в день. Имеющиеся данные не подтверждают, что сбор VAT активен на каком-либо кластере.

Для основной сети непосредственным изменением является 350 мс в эпохе 1020, а не прямой переход к 200 мс. Solana пытается ускорить ротацию возможностей планирования, сохраняя при этом потолки ресурсов примерно постоянными. Оставшийся риск заключается в том, смогут ли валидаторы и окружающая инфраструктура сохранить свои пределы координации по мере сокращения каждого этапа.

Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.