В статье на платформе X Виталик Бутерин заявил, что теперь он больше склоняется к использованию нативных роллап-процессов, чем раньше. Одной из главных причин его пре-опционального подхода было то, что нативные роллап-прекомпиляции должны были выбирать между «режимом ZK» и «оптимистическим режимом». ZK-EVM был недостаточно зрелым в режиме ZK, поэтому, если мы предоставляли L2 два варианта: «использование полностью доверенных доказательств Ethereum, вывод средств занимает 2-7 дней» или «мгновенный вывод средств, но доказательства нужно обрабатывать самостоятельно», L2 обычно выбирал первый вариант. Это сильно вредило компонуемости Ethereum, что привело к внедрению большего количества мостов с мультиподписью и т.д. Однако теперь, похоже, сроки полного принятия ZK на L1 в Ethereum фактически совпадают с реальными сроками добавления нативных роллап-прекомпиляций, так что эта проблема решена. Кроме того, я вижу все больше работ, использующих синхронную компонуемость как одно из основных преимуществ концепции «зачем нужен L2?». Я также предложил метод: https://ethresear.ch/t/combining-preconfirmations-with-based-rollups-for-synchronous-composability/23863, который объединяет предварительные подтверждения на основе роллапов с предварительными подтверждениями L2 с низкой задержкой для достижения синхронной компонуемости. Поэтому я считаю, что это правильное направление. Думаю, нам не следует лениться и нужно приложить больше усилий для поиска наилучшего способа реализации этого предварительного подтверждения. Ключевое свойство, которое я хочу видеть, заключается в том, что если вы создаете EVM + роллап с новыми функциями, вы должны иметь возможность использовать собственные предварительные подтверждения роллапов на EVM, используя при этом собственный доказывающий механизм для обработки новых функций. Рассмотрите возможность использования **таблицы поиска** для стандартизации связи между ними.