Optimism нацеливается на 200-миллисекундные субблоки в OP Mainnet, сокращая интервал предварительного подтверждения с 250 миллисекунд в рамках поэтапного обновления, запланированного на 31 августа. Субблоки, ранее называвшиеся Flashblocks, представляют собой инкрементальные обновления, которые секвенсор отправляет, пока еще формирует обычный блок, предоставляя приложениям обратную связь до того, как этот блок будет запечатан.
Ускорение на 20% несет в себе скрытый риск несовместимости. Уведомление Optimism о миграции сообщает, что четыре поля останутся в каждом передаваемом полезном нагрузке, но перестанут нести полезные данные: state_root, block_hash и withdrawals_root будут содержать нулевые значения, а withdrawals будет пустым списком.
Тип полезной нагрузки остается ExecutionPayloadFlashblockDeltaV1, поэтому программное обеспечение может продолжать разбор потока без возникновения ошибки. Поля, включая receipts_root и logs_bloom, по-прежнему будут содержать реальные значения. Такое сочетание делает миграцию легко упускаемой из виду в системах, которые считают успешное декодирование доказательством того, что каждое поле значимо.
Почему 200-миллисекундные субблоки делают границу провайдера значимой
Субблоки — это предварительные подтверждения, а не финализированные блоки или подтверждения состояния. Техническое объяснение Optimism гласит, что прямые потребители потока должны рассматривать обнуленный корень состояния и хеш блока как отсутствующие и получать предварительно подтвержденное состояние, выполняя транзакции, передаваемые в потоке.
Большинство приложений находятся на более безопасной стороне этой границы. Они подключаются к RPC-провайдеру с поддержкой субблоков и используют стандартные методы Ethereum, часто с тегом pending. Правильно настроенный провайдер или узел поддерживает собственное представление состояния, поэтому такие вызовы, как eth_getBalance, могут возвращать производные предварительно подтвержденные данные, не полагаясь на используемый корень состояния в сырой полезной нагрузке, согласно руководству по интеграции Optimism.
Таким образом, аудит в первую очередь ложится на приложения, которые сами обрабатывают WebSocket-поток, и на RPC-провайдеров, передающих сырые поля клиентам. Операторам необходимо найти чтения четырех затронутых полей, считать корни-заполнители и хеш бока недоступными и не допустить попадания этих значений в последующие состояния, балансы или входные данные для доказательств. Провайдеры, ретранслирующие сырые полезные нагрузки, также должны уведомить своих потребителей.
Более быстрый темп уже виден в документации провайдеров. Руководство Alchemy по OP Mainnet описывает обновления с интервалом 200 мс через существующие конечные точки Optimism RPC, в то время как уведомление QuickNode применяет миграцию к своим компонентам JSON-RPC для Optimism Mainnet и Sepolia.
Optimism сообщает, что цель на 31 августа для 200-миллисекундных субблоков может быть сдвинута, и что развертывание происходит постепенно, поэтому задокументированного времени завершения по всей сети нет. Его страница статуса на момент проверки показывала системы работающими и отсутствие уведомлений об инцидентах. Официальные уведомления и уведомления провайдеров представляют поля с нулевыми значениями как риск миграции, требующий профилактической работы, а не как свидетельство того, что балансы или доказательства уже были повреждены.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
