Обсуждение практических решений для улучшения времени подтверждения транзакций Ethereum
В последние годы Эфир значительно продвинулся в скорости подтверждения транзакций. Благодаря EIP-1559 и стабильному времени создания блоков после перехода на механизм PoS, транзакции, отправляемые пользователями на L1, обычно могут быть подтверждены в течение 5-20 секунд, что в целом сопоставимо с опытом оплаты кредитной картой. Тем не менее, имеет смысл продолжать улучшать пользовательский опыт, и некоторые приложения даже требуют времени отклика менее одной секунды. В этой статье будут рассмотрены несколько жизнеспособных решений для повышения скорости подтверждения транзакций в Ethereum.
Обзор существующих технологий
Однослотовая окончательность
В настоящее время консенсус Gasper в Ethereum использует архитектуру слотов и периодов. Каждые 12 секунд создается слот, и некоторые валидаторы голосуют за голову цепочки, у всех валидаторов есть возможность проголосовать один раз в течение 32 слотов (6,4 минуты). Эти голоса интерпретируются как сообщения в алгоритме консенсуса, аналогичном PBFT, и через два периода (12,8 минуты) обеспечивается окончательность с сильной экономической гарантией.
Этот метод имеет две основные проблемы: во-первых, высокая сложность, существует множество взаимодействий между механизмом голосования по слотам и механизмом окончательности по периодам; во-вторых, время окончательного подтверждения в 12,8 минуты слишком долго и не соответствует ожиданиям пользователей.
Однослотовая окончательность (SSF) заменила эту архитектуру с помощью механизма, аналогичного Tendermint, позволяя достичь окончательного подтверждения блока N до генерации блока N+1. SSF сохраняет механизм "неактивной утечки", позволяя цепи продолжать работу и восстанавливаться, даже если более 1/3 валидаторов офлайн.
Основная проблема SSF заключается в том, что каждый ставящий должен каждые 12 секунд публиковать два сообщения, что создает огромную нагрузку на сеть. Хотя существуют некоторые меры по смягчению, такие как недавнее предложение Orbit SSF, пользователи все равно должны ждать от 5 до 20 секунд, чтобы подтвердить транзакцию.
Предварительное подтверждение Rollup
В последние годы Ethereum придерживается дорожной карты, сосредоточенной на rollup, проектируя L1 как базовый уровень, поддерживающий доступность данных и другие функции для использования протоколами L2 (такими как rollups, validiums и plasmas), чтобы предоставлять пользователям услуги с такой же безопасностью, как у Ethereum, в большем масштабе.
Это привело к разделению акцентов внутри экосистемы Ethereum: L1 сосредотачивается на антикоррупции, надежности и стабильности, а также на поддержании и улучшении основных функций; L2 же более непосредственно обслуживает пользователей через различные культуры и технологии. Тем не менее, L2 стремится предоставить пользователям время подтверждения быстрее 5-20 секунд.
Теоретически, создание сети децентрализованных сортировщиков является обязанностью L2. Небольшая группа валидаторов может подписывать блоки каждые несколько сотен миллисекунд и ставить активы в качестве залога. Заголовки этих L2 блоков в конечном итоге будут опубликованы на L1.
Однако требование о том, чтобы все L2 реализовали децентрализованный порядок, кажется не совсем справедливым, это эквивалентно требованию, чтобы rollup выполнил практически такую же работу, как создание совершенно нового L1. Поэтому было предложено, чтобы все L2 (и L1) использовали общую предварительную механизмы подтверждения в рамках Эфира: базовая предварительная проверка.
Базовое предварительное подтверждение
Базовый метод предварительного подтверждения предполагает, что предложитель Ethereum является сложным участником, связанным с MEV. Он использует эту сложность, побуждая этих предложителей принимать на себя ответственность за предоставление услуг предварительного подтверждения.
Этот метод создает стандартизированный протокол, позволяющий пользователям платить дополнительную плату за мгновенную гарантию включения транзакции в следующий блок, а также за обязательство по выполнению результатов этой транзакции. Если предложитель нарушит обязательство, он столкнется с наказанием.
Этот механизм подходит не только для L1-транзакций, но и для rollups, основанных на Ethereum, все L2-блоки фактически являются L1-транзакциями, поэтому тот же механизм может предоставлять услуги предварительного подтверждения для любого L2.
Возможная архитектура будущего
Предположим, мы реализуем окончательность одного слота и используем технологии, подобные Orbit, чтобы уменьшить количество валидаторов, подписывающих каждый слот, при этом сохраняя достаточную степень децентрализации, чтобы снизить порог для стейкинга. Длительность слота может увеличиться до 16 секунд, после чего мы используем предварительное подтверждение rollup или базовое предварительное подтверждение, чтобы предоставить пользователям более быстрое подтверждение. В конечном итоге мы получаем архитектуру циклов и слотов.
Эта архитектура трудно избежать, потому что время, необходимое для достижения общего консенсуса по какому-либо вопросу, намного меньше, чем время, необходимое для достижения максимальной "экономической окончательности". Причины включают:
"Приблизительное согласие" требует лишь небольшого количества узлов, тогда как экономическая конечность требует участия большинства узлов.
После превышения определенного масштаба количества узлов, время, необходимое для сбора подписей, значительно увеличится.
В текущем Эфире 12-секундный интервал делится на три подинтервала: выпуск и распространение блоков, доказательство, агрегация доказательств. Если значительно уменьшить количество доказателей, мы можем сократить до двух подинтервалов, что позволит достичь времени интервала в 8 секунд. Если мы сможем полагаться на специализированный поднабор узлов для достижения соглашения (при этом все еще используя полный набор валидаторов для определения окончательности), время может быть сокращено до примерно 2 секунд.
Таким образом, архитектура циклов-слотов кажется неизбежной, но между различными реализациями существуют различия. Стоит исследовать направление, направленное на установление более сильного разделения внимания между двумя механизмами, а не тесной связи, как в Gasper.
Выбор стратегии L2
В настоящее время существует три разумные стратегии для L2:
В техническом и концептуальном плане они "основываются" на Ethereum. Эти rollup можно рассматривать как "брендированные шардирования", которые также могут проводить множество экспериментов с новыми проектами виртуальной машины и другими технологическими улучшениями.
Стать "сервером с блокчейн-каркасом". Получить большую часть преимуществ от занесения в блокчейн, добавив доказательства корректности STARK, обеспечив права выхода пользователей, поддерживая коллективный выбор и т.д., одновременно сохраняя преимущества эффективности сервера.
Компромиссный метод: создание быстрой цепи с сотней узлов, одновременно используя Эфир для обеспечения дополнительной интероперабельности и безопасности. Это текущая фактическая дорожная карта многих проектов L2.
Для некоторых приложений (таких как ENS, хранение ключей, некоторые платежные протоколы) времени блока в 12 секунд достаточно. Для других приложений единственным решением является архитектура циклов-слотов. В этой архитектуре "цикл" — это SSF Эфира, а "слот" в разных случаях различен:
Эфир нативная цикло-слотовая архитектура
Предварительное подтверждение сервера
Предварительное подтверждение комитета
Ключевой вопрос заключается в том, насколько хорошо может работать первый вариант. Если он будет успешным, значение третьего варианта уменьшится. Второй вариант всегда будет существовать, поскольку все решения, "основанные" на Эфире, не подходят для таких решений, как plasmas и validiums, которые используют данные L2 вне цепи. Если нативная архитектура Эфира с периодами и слотами сможет сократить время слота до 1 секунды, пространство для третьего варианта значительно сократится.
На данный момент мы далеки от окончательных ответов на эти вопросы. Одной из ключевых неопределенностей является то, насколько сложными станут предложители блоков. Новые концепции, такие как Orbit SSF, предоставляют нам больше пространства для исследований, например, использование Orbit SSF в качестве периода в архитектуре период-слота. Чем больше у нас есть вариантов, тем лучше мы сможем обслуживать пользователей L1 и L2, одновременно упрощая работу разработчиков L2.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
5
Поделиться
комментарий
0/400
¯\_(ツ)_/¯
· 13ч назад
Эта скорость даже хуже, чем у pow?
Посмотреть ОригиналОтветить0
LightningAllInHero
· 08-02 19:40
Снова мучают скорость подтверждения... Никакого толку.
Посмотреть ОригиналОтветить0
rekt_but_resilient
· 08-02 19:33
L2 это для того, чтобы было быстрее.
Посмотреть ОригиналОтветить0
ValidatorViking
· 08-02 19:30
эти временные рамки окончательности все еще делают рagnarök быстрым... инфраструктуре узлов необходимо серьезное боевое тестирование перед любыми модными изменениями консенсуса, если честно
План ускорения подтверждения транзакций Ethereum: всестороннее обсуждение от SSF до предварительного подтверждения L2
Обсуждение практических решений для улучшения времени подтверждения транзакций Ethereum
В последние годы Эфир значительно продвинулся в скорости подтверждения транзакций. Благодаря EIP-1559 и стабильному времени создания блоков после перехода на механизм PoS, транзакции, отправляемые пользователями на L1, обычно могут быть подтверждены в течение 5-20 секунд, что в целом сопоставимо с опытом оплаты кредитной картой. Тем не менее, имеет смысл продолжать улучшать пользовательский опыт, и некоторые приложения даже требуют времени отклика менее одной секунды. В этой статье будут рассмотрены несколько жизнеспособных решений для повышения скорости подтверждения транзакций в Ethereum.
Обзор существующих технологий
Однослотовая окончательность
В настоящее время консенсус Gasper в Ethereum использует архитектуру слотов и периодов. Каждые 12 секунд создается слот, и некоторые валидаторы голосуют за голову цепочки, у всех валидаторов есть возможность проголосовать один раз в течение 32 слотов (6,4 минуты). Эти голоса интерпретируются как сообщения в алгоритме консенсуса, аналогичном PBFT, и через два периода (12,8 минуты) обеспечивается окончательность с сильной экономической гарантией.
Этот метод имеет две основные проблемы: во-первых, высокая сложность, существует множество взаимодействий между механизмом голосования по слотам и механизмом окончательности по периодам; во-вторых, время окончательного подтверждения в 12,8 минуты слишком долго и не соответствует ожиданиям пользователей.
Однослотовая окончательность (SSF) заменила эту архитектуру с помощью механизма, аналогичного Tendermint, позволяя достичь окончательного подтверждения блока N до генерации блока N+1. SSF сохраняет механизм "неактивной утечки", позволяя цепи продолжать работу и восстанавливаться, даже если более 1/3 валидаторов офлайн.
Основная проблема SSF заключается в том, что каждый ставящий должен каждые 12 секунд публиковать два сообщения, что создает огромную нагрузку на сеть. Хотя существуют некоторые меры по смягчению, такие как недавнее предложение Orbit SSF, пользователи все равно должны ждать от 5 до 20 секунд, чтобы подтвердить транзакцию.
Предварительное подтверждение Rollup
В последние годы Ethereum придерживается дорожной карты, сосредоточенной на rollup, проектируя L1 как базовый уровень, поддерживающий доступность данных и другие функции для использования протоколами L2 (такими как rollups, validiums и plasmas), чтобы предоставлять пользователям услуги с такой же безопасностью, как у Ethereum, в большем масштабе.
Это привело к разделению акцентов внутри экосистемы Ethereum: L1 сосредотачивается на антикоррупции, надежности и стабильности, а также на поддержании и улучшении основных функций; L2 же более непосредственно обслуживает пользователей через различные культуры и технологии. Тем не менее, L2 стремится предоставить пользователям время подтверждения быстрее 5-20 секунд.
Теоретически, создание сети децентрализованных сортировщиков является обязанностью L2. Небольшая группа валидаторов может подписывать блоки каждые несколько сотен миллисекунд и ставить активы в качестве залога. Заголовки этих L2 блоков в конечном итоге будут опубликованы на L1.
Однако требование о том, чтобы все L2 реализовали децентрализованный порядок, кажется не совсем справедливым, это эквивалентно требованию, чтобы rollup выполнил практически такую же работу, как создание совершенно нового L1. Поэтому было предложено, чтобы все L2 (и L1) использовали общую предварительную механизмы подтверждения в рамках Эфира: базовая предварительная проверка.
Базовое предварительное подтверждение
Базовый метод предварительного подтверждения предполагает, что предложитель Ethereum является сложным участником, связанным с MEV. Он использует эту сложность, побуждая этих предложителей принимать на себя ответственность за предоставление услуг предварительного подтверждения.
Этот метод создает стандартизированный протокол, позволяющий пользователям платить дополнительную плату за мгновенную гарантию включения транзакции в следующий блок, а также за обязательство по выполнению результатов этой транзакции. Если предложитель нарушит обязательство, он столкнется с наказанием.
Этот механизм подходит не только для L1-транзакций, но и для rollups, основанных на Ethereum, все L2-блоки фактически являются L1-транзакциями, поэтому тот же механизм может предоставлять услуги предварительного подтверждения для любого L2.
Возможная архитектура будущего
Предположим, мы реализуем окончательность одного слота и используем технологии, подобные Orbit, чтобы уменьшить количество валидаторов, подписывающих каждый слот, при этом сохраняя достаточную степень децентрализации, чтобы снизить порог для стейкинга. Длительность слота может увеличиться до 16 секунд, после чего мы используем предварительное подтверждение rollup или базовое предварительное подтверждение, чтобы предоставить пользователям более быстрое подтверждение. В конечном итоге мы получаем архитектуру циклов и слотов.
Эта архитектура трудно избежать, потому что время, необходимое для достижения общего консенсуса по какому-либо вопросу, намного меньше, чем время, необходимое для достижения максимальной "экономической окончательности". Причины включают:
В текущем Эфире 12-секундный интервал делится на три подинтервала: выпуск и распространение блоков, доказательство, агрегация доказательств. Если значительно уменьшить количество доказателей, мы можем сократить до двух подинтервалов, что позволит достичь времени интервала в 8 секунд. Если мы сможем полагаться на специализированный поднабор узлов для достижения соглашения (при этом все еще используя полный набор валидаторов для определения окончательности), время может быть сокращено до примерно 2 секунд.
Таким образом, архитектура циклов-слотов кажется неизбежной, но между различными реализациями существуют различия. Стоит исследовать направление, направленное на установление более сильного разделения внимания между двумя механизмами, а не тесной связи, как в Gasper.
Выбор стратегии L2
В настоящее время существует три разумные стратегии для L2:
В техническом и концептуальном плане они "основываются" на Ethereum. Эти rollup можно рассматривать как "брендированные шардирования", которые также могут проводить множество экспериментов с новыми проектами виртуальной машины и другими технологическими улучшениями.
Стать "сервером с блокчейн-каркасом". Получить большую часть преимуществ от занесения в блокчейн, добавив доказательства корректности STARK, обеспечив права выхода пользователей, поддерживая коллективный выбор и т.д., одновременно сохраняя преимущества эффективности сервера.
Компромиссный метод: создание быстрой цепи с сотней узлов, одновременно используя Эфир для обеспечения дополнительной интероперабельности и безопасности. Это текущая фактическая дорожная карта многих проектов L2.
Для некоторых приложений (таких как ENS, хранение ключей, некоторые платежные протоколы) времени блока в 12 секунд достаточно. Для других приложений единственным решением является архитектура циклов-слотов. В этой архитектуре "цикл" — это SSF Эфира, а "слот" в разных случаях различен:
Ключевой вопрос заключается в том, насколько хорошо может работать первый вариант. Если он будет успешным, значение третьего варианта уменьшится. Второй вариант всегда будет существовать, поскольку все решения, "основанные" на Эфире, не подходят для таких решений, как plasmas и validiums, которые используют данные L2 вне цепи. Если нативная архитектура Эфира с периодами и слотами сможет сократить время слота до 1 секунды, пространство для третьего варианта значительно сократится.
На данный момент мы далеки от окончательных ответов на эти вопросы. Одной из ключевых неопределенностей является то, насколько сложными станут предложители блоков. Новые концепции, такие как Orbit SSF, предоставляют нам больше пространства для исследований, например, использование Orbit SSF в качестве периода в архитектуре период-слота. Чем больше у нас есть вариантов, тем лучше мы сможем обслуживать пользователей L1 и L2, одновременно упрощая работу разработчиков L2.