Дуже важливий документ. Давайте пройдемося по цій «мети» по черзі. Почнемо з швидких слотів і швидкої фінальності. Очікую, що ми поступово скоротимо час у слотах, наприклад. Мені подобається формула «sqrt(2) за раз» (12 -> 8 -> 6 -> 4 -> 3 -> 2, хоча останні два кроки більш спекулятивні і залежать від ґрунтовних досліджень). Тут можна їхати швидше або повільніше; Але головний рівень полягає в тому, що ми розглядаємо час слоту як параметр, який зменшуємо, коли впевнені, що це безпечно, подібно до цілі Blob. Швидкі слоти розташовані у своїй смузі на верхній частині дорожньої карти і, здається, ні до чого не з'єднуються. Це тому, що решта дорожньої карти досить незалежна від часу слоту: нам потрібно робити приблизно те саме, незалежно від того, чи триває слот 2 секунди, чи 32 секунди Проте є кілька перехрестя. Одна з них — покращення p2p. @raulvk нещодавно працює над оптимізованим p2p-шаром для Ethereum, який використовує кодування стирання для суттєвого покращення компромісу між пропускною здатністю та затримкою. Грубо кажучи: у сучасному дизайні кожен вузол отримує повне блочне тіло від кількох пірів і може приймати та повторно транслювати його, щойно отримує перший. Якщо «ширина» (кількість пірів, які надсилають вам блок) низька, то один несправний пір може суттєво затримати отримання блокування. Якщо ширина велика, накопичується багато зайвих витрат на дані. У кодуванні стирання можна вибрати k-of-n конфігурацію, наприклад: розділити кожен блок на 8 частин, щоб з будь-яких чотирьох з них можна було відновити весь блок. Це дає багато переваг надлишковості великої ширини без додаткових витрат. Ми маємо статистику, яка показує, що така архітектура може суттєво скоротити час поширення блоків у 95-му процентилі, роблячи коротші слоти життєздатними без компромісів для безпеки (за винятком підвищеної складності протоколу, хоча тут співвідношення приросту продуктивності до рядків коду досить сприятливе) Ще одна зона перетину — це складніша структура слотів, яка супроводжується ePBS, FOCIL та правилом швидкого підтвердження. Вони мають важливі переваги, але знижують максимальну безпечну затримку з слоту/3 до слоту/5. Тривають дослідження, щоб краще налагодити конвеєр для мінімізації втрат (також зверніть увагу: час слотів обмежений не лише затримкою слотів, а й фіксованою вартістю затримки ZK Pover), але тут є певні компроміси. Один із способів, яким ми досліджуємо, щоб це компенсувати, — це перехід на архітектуру, де лише ~256-1024 випадково обраних attesters підписуються на кожному слоті. Для функції вибору форка (нефіналізуючої системи) цього цілком достатньо. Менша кількість підписів дозволяє прибрати фазу агрегації, скоротивши слоти. Швидка фінальність складніша (на мою думку, остаточний протокол простіший за Гаспера, але шлях зміни складний). Сьогодні фінальність триває в середньому 16 хвилин (слоти 12 секунди * 32 епохи слотів * 2,5 епохи). Мета — розділити слоти та фінальність, щоб ми могли розглянути обидва окремо, і ми прагнемо використати алгоритм BFT з однораундовою фінальністю (варіант Minimmit) для завершення. Отже, фінальність фіналу може бути, наприклад. 6-16 сек. Оскільки це дуже інвазивний набір змін, план полягає в тому, щоб об'єднати найбільший крок у кожній зміні з перемиканням криптографії, зокрема до постквантових хеш-підписів і максимально дружнього до STARK хешу (існує три можливі відповіді на нещодавні атаки Poseidon2: (i) збільшити кількість раундів або запровадити інші контрзаходи, такі як монолітний шар, (ii) повернутися до Poseidon1, який ще більш лінійний, ніж Poseidon2, і не має недоліків, (iii) використовуйте BLAKE3 або інший максимально дешевий «звичайний» хеш. Усі вони зараз досліджують). Крім того, є план впровадження багатьох із цих змін поетапно, наприклад, «1-епохічна фінальність» означає, що ми коригуємо поточний консенсус, щоб змінити фіналізацію у стилі FFG на фіналізацію у стилі Мінімміт. Одна з можливих траєкторій фінального часу: 16 хв (сьогодні) -> 10х40с (слоти 8с) -> 6хв24с (фінальність у епоху) -> 1хв12с (8-слотні епохи, 6-секундні слоти) -> 48-х (4-ті слоти) -> 16-ти (мінімміт) -> 8 (мінімум з більш агресивними параметрами) Цікавим наслідком інкрементального підходу є те, що існує шлях зробити слоти квантово-стійкими набагато раніше, ніж зробити фінальність квантово-стійкими, тож ми можемо досить швидко перейти до режиму, коли, якщо раптово з'являться квантові комп'ютери, ми втрачаємо гарантію остаточності, але ланцюг продовжує працювати. Резюме: очікуйте поступового скорочення як часу слоту, так і фінального часу, і очікуйте, що ці зміни будуть тісно переплетені з компонентною заміною структури слотів і консенсусу Ethereum у стилі «корабля Тесея» на чистішу, простішу, квантово-стійку, дружню до перевірки, повну формально перевірену альтернативу.