Solana може отримати турбо-прискорення, оскільки Firedancer націлюється на обмеження блоків

Цього тижня імпульс продуктивності Solana набрав нового Індикатор імпульсу, оскільки інженери, що стоять за Firedancer, альтернативним високопродуктивним клієнтом валідатора під керівництвом Jump, подали новий документ з покращення Solana (SIMD-0370) для видалення обмеження обчислювальних одиниць (CU) на рівні блоку мережі — зміну, яку вони вважають надлишковою після Alpenglow і яка негайно призведе до підвищення пропускної здатності та зменшення затримки при сплесках попиту.

Наступний турбо-буст для Solana

Запит на злиття, створений "Командою Firedancer" і відкритий 24 вересня 2025 року, чітко сформульований як пропозиція "після Alpenglow". У Alpenglow вузли голосування транслюють SkipVote, якщо вони не можуть виконати запропонований блок у відведений час. Оскільки повільні блоки автоматично пропускаються, автори стверджують, що окреме обмеження CU на блок, що забезпечується протоколом, є непотрібним.

"У Alpenglow вузли голосування транслюють SkipVote, якщо вони не встигають виконати блок вчасно... Тому цей SIMD видаляє обмеження обчислювальних одиниць блоку", — зазначається в документі, описуючи обмеження як зайве за оновленими правилами планування.

Крім технічної чистоти, автори пропонують більш чітке економічне узгодження. Поточне обмеження CU на рівні блоку, на їхню думку, порушує стимули, обмежуючи потужність через протокол, а не через вдосконалення апаратного та програмного забезпечення. Його видалення дозволить виробникам заповнювати блоки до рівня, який їхні машини можуть безпечно обробляти та поширювати, висуваючи конкуренцію клієнтів та апаратного забезпечення на перший план.

"Потужність мережі визначається не можливостями апаратного забезпечення, а довільним обмеженням обчислювальних одиниць блоку", — пишуть вони, перш ніж окреслити, чому зняття цього обмеження перебудує стимули як для клієнтів-валідаторів, так і для розробників програм.

Ранні коментарі до перегляду коду від основних учасників та клієнтських команд підкреслюють як короткостроковий вплив на користувачів, так і межі змін. Один рецензент підсумував практичну перевагу: "Видалення обмеження сьогодні має відчутні переваги для екосистеми та кінцевих користувачів... без очікування на розробку майбутньої архітектури мережі". Інший підкреслив, що деякі обмеження блоків залишаться, посилаючись на "максимальне обмеження фрагментів", тоді як інші запропонували, щоб мережа, ймовірно, зберегла обмеження CU на транзакцію поки що і розглядала будь-які зміни там як окрему, більш далекосяжну дискусію.

Міркування щодо безпеки та життєздатності займають важливе місце. Рецензенти попросили пропозицію чітко пояснити, чому безпека зберігається, навіть якщо блок занадто важкий для своєчасного поширення; відповідь Alpenglow полягає в тому, що такі блоки просто не отримують голосів, тобто вони пропускаються — підтримуючи прогрес без штрафів для мережі. Автори Firedancer погоджуються, що вирішальним захисним бар'єром є час і бюджет поширення, а не статична стеля CU.

Пропозиція також розглядає часте занепокоєння в дебатах про пропускну здатність: координацію. Якщо один виробник блоків агресивно оновлює апаратне забезпечення, тоді як інші відстають, чи ризикує мережа втратами через пропущені блоки? Один рецензент зазначає, що надто амбіційні виробники вже самокалібруються, оскільки пропущені блоки означають пропущені винагороди, природно обмежуючи розмір блоку до того, що однолітки можуть прийняти вчасно. Документ далі стверджує, що без обмеження CU ринкові сили керують потужністю: виробники та клієнтські команди, які оптимізують виконання, мережеву роботу та планування, виграють більше блоків і комісій, розширюючи межі відповідно до попиту.

Важливо, що SIMD-0370 є сумісним з майбутнім. Поточні проекти для кількох одночасних пропонентів — довгостроковий пункт дорожньої карти для Solana — іноді припускають обмеження блоків, а іноді ні. Рецензенти підкреслюють, що видалення поточного обмеження не виключає архітектури з одночасними пропонентами пізніше; воно просто розблоковує покращення, які "можуть бути реалізовані сьогодні".

Хоча обговорення на GitHub надає технічну суть, Anza — клієнтська команда Solana, що стоїть за Agave — також посилила пропозицію в соціальних каналах, сигналізуючи про широку увагу клієнтських команд до змін та їх наслідків для користувачів.

Що зміниться для користувачів і розробників, якщо SIMD-0370 буде впроваджено? У пікові періоди — аірдропи, майнінг, волатильність ринку — блоки могли б нести більше обчислень, якщо вони можуть бути виконані та поширені в межах часу слоту, потенційно підвищуючи стійку пропускну здатність і згладжуючи сплески комісій.

Для розробників Solana більший запас і сильніші стимули для оптимізації клієнта/апаратного забезпечення могли б зменшити затримку для вимогливих робочих навантажень, хоча й з постійною потребою оптимізувати програми для паралелізму та локальності. Для валідаторів конкурентна перевага ще більше схилятиметься до ефективності виконання, продуктивності мережі та розумної політики побудови блоків, яка балансує дохід від комісій з ризиком створення блоку настільки важкого, що він буде пропущений.

Як і всі SIMD, зміна підлягає перегляду спільнотою, впровадженню та координації розгортання серед клієнтів-валідаторів. Але напрямок ясний. Після Alpenglow, дизайнери Solana вважають, що бюджет часу слоту є реальним обмежувачем.

На момент публікації Solana торгувалася за $205.38.