Очень важный документ. Давайте разберем это по "целям" по одному. Начнем с быстрых слотов и быстрой финализации. Я ожидаю, что мы будем постепенно сокращать время слота, например, мне нравится формула "sqrt(2) за раз" (12 -> 8 -> 6 -> 4 -> 3 -> 2, хотя последние два шага более спекулятивны и зависят от серьезных исследований). Здесь можно двигаться быстрее или медленнее; но в целом мы будем рассматривать время слота как параметр, который мы будем уменьшать, когда будем уверены, что это безопасно, аналогично целевому значению blob. Быстрые слоты находятся в своем собственном направлении в верхней части дорожной карты и, похоже, не связаны ни с чем. Это потому, что остальная часть дорожной карты довольно независима от времени слота: нам нужно будет делать примерно одно и то же, независимо от того, составляет ли время слота 2 секунды или 32 секунды. Тем не менее, есть несколько пересечений. Одно из них - улучшения p2p. @raulvk недавно работал над оптимизированным p2p-слоем для Ethereum, который использует кодирование с удалением, чтобы значительно улучшить компромисс между пропускной способностью и задержкой. Грубо говоря: в сегодняшнем дизайне каждый узел получает полный блок от нескольких пиров и может принять и повторно передать его, как только получит первый. Если "ширина" (количество пиров, отправляющих вам блок) низка, то один плохой пир может значительно задержать получение блока. Если ширина высока, то возникает много ненужных накладных данных. С помощью кодирования с удалением вы можете выбрать настройку k-of-n, например: разбить каждый блок на 8 частей, так что с любыми 4 из них вы можете восстановить полный блок. Это дает вам многие преимущества избыточности высокой ширины без накладных расходов. У нас есть статистика, показывающая, что эта архитектура может значительно сократить время распространения блока на 95-м процентиле, что делает более короткие слоты жизнеспособными без компромиссов в безопасности (за исключением увеличенной сложности протокола, хотя здесь соотношение прироста производительности к строкам кода довольно благоприятно). Еще одной областью пересечения является более сложная структура слота, которая приходит с ePBS, FOCIL и правилом быстрой финализации. У них есть важные преимущества, но они уменьшают максимальную безопасную задержку с slot/3 до slot/5. Ведутся исследования, чтобы попытаться лучше организовать процессы, чтобы минимизировать потери (также обратите внимание: время слота ограничено не только задержкой слота, но и фиксированной частью задержки ZK-просителя), но здесь есть некоторые компромиссы. Один из способов, который мы исследуем, чтобы компенсировать это, - изменить архитектуру так, чтобы только ~256-1024 случайно выбранных аттестаторов подписывали каждый слот. Для функции выбора форка (не финализирующей) это совершенно достаточно. Меньшее количество подписей позволяет нам убрать фазу агрегации, сокращая слоты. Быстрая финализация более сложна (конечный протокол, на мой взгляд, проще, чем статус-кво Gasper, но путь изменений сложен). Сегодня финализация занимает в среднем 16 минут (12с слоты * 32 слота эпохи * 2.5 эпохи). Цель состоит в том, чтобы отделить слоты и финализацию, чтобы мы могли рассматривать их отдельно, и мы стремимся использовать алгоритм BFT с финализацией за один раунд (вариант Minimmit) для финализации. Таким образом, время финализации в конечной игре может составлять, например, 6-16 секунд. Поскольку это очень инвазивный набор изменений, план состоит в том, чтобы объединить самый крупный шаг в каждом изменении с переключением криптографии, в частности, на постквантовые подписи на основе хешей и на максимально дружелюбный к STARK хеш (существуют три возможных ответа на недавние атаки Poseidon2: (i) увеличить количество раундов или ввести другие контрмеры, такие как слой Monolith, (ii) вернуться к Poseidon1, который даже более "линди", чем Poseidon2 и не имел недостатков, (iii) использовать BLAKE3 или другие максимально дешевые "традиционные" хеши. Все это исследуется). Кроме того, есть план ввести многие из этих изменений поэтапно, например, "финализация за 1 эпоху" означает, что мы изменяем текущий консенсус, чтобы перейти от финализации в стиле FFG к финализации в стиле Minimmit. Одна возможная траектория времени финализации: 16 мин (сегодня) -> 10м40с (8с слоты) -> 6м24с (финализация за одну эпоху) -> 1м12с (8-слотовые эпохи, 6с слоты) -> 48с (4с слоты) -> 16с (minimmit) -> 8с (minimmit с более агрессивными параметрами). Одним из интересных последствий поэтапного подхода является то, что существует путь к тому, чтобы сделать слоты устойчивыми к квантовым атакам гораздо раньше, чем сделать финализацию устойчивой к квантовым атакам, так что мы вполне можем быстро перейти в режим, когда, если квантовые компьютеры внезапно появятся, мы потеряем гарантию финализации, но цепочка продолжит работать. Резюме: ожидайте постепенного сокращения как времени слота, так и времени финализации, и ожидайте, что эти изменения будут переплетены с заменой структуры слота и консенсуса Ethereum по компонентам в стиле "корабля Тесея" на более чистую, простую, устойчивую к квантовым атакам, удобную для провайдеров, формально проверенную альтернативу.