Исследование более быстрого времени подтверждения транзакций Ethereum
Быстрое время подтверждения транзакций является важной частью качественного пользовательского опыта в блокчейне. В последние годы Ethereum добился значительного прогресса в этой области. В настоящее время транзакции, отправляемые пользователями в 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) предоставляют пользователям масштабируемые услуги на этой основе. L2 стремится обеспечить пользователям более быстрое время подтверждения.
Теоретически, L2 может создать свою собственную сеть "децентрализованных сортировщиков", которая будет подписывать блоки каждые несколько сотен миллисекунд. Однако требовать от всех L2 проводить декомцентрированную сортировку кажется не совсем справедливым, так как это эквивалентно созданию совершенно нового L1.
Базовое предварительное подтверждение
Базовое предположение предварительного подтверждения заключается в том, что предложители Ethereum являются сложными участниками MEV, и эта сложность используется для стимулирования их принятия ответственности за предоставление услуг предварительного подтверждения. Этот метод создает стандартизированный протокол, в рамках которого пользователи могут предложить дополнительную плату за получение мгновенной гарантии включения транзакции в следующий блок. Если предложитель нарушит свои обязательства, он будет наказан.
Этот механизм может предоставить предварительное подтверждение для L1 транзакций и основанных на L2 блокчейнов.
Будущее
Предположим, что реализована конечность с одним слотом и используется технология, подобная Orbit, для уменьшения количества валидаторов, подписывающих каждый слот, одновременно снижая порог ставки. Длительность слота может увеличиться до 16 секунд и в сочетании с предварительным подтверждением rollup или базовым предварительным подтверждением предоставит пользователям более быстрое подтверждение. Это создаст новую архитектуру эпохи-слота.
Причина, по которой архитектура epoch-slot неизбежна, заключается в том, что время, необходимое для достижения приблизительного согласия, короче, чем время, необходимое для достижения максимальной степени "экономической окончательности" соглашения. Это связано с такими факторами, как количество узлов и "качество" узлов.
Для L2 в настоящее время существует три разумные стратегии:
Технически и духовно "основан" на Ethereum, оптимизируя его базовые свойства и ценности.
Стать "сервером с каркасом блокчейна", полностью используя эффективность сервера.
Компромиссный вариант: быстрая цепочка с примерно сотней узлов, Эфир предоставляет дополнительную интероперабельность и безопасность.
Ключевой вопрос заключается в том, насколько хорошо архитектура эпохи-слота, родная для Ethereum, может работать. Если время слота удастся сократить до 1 секунды, пространство для третьей стратегии значительно уменьшится.
На данный момент мы еще далеки от окончательных ответов на эти вопросы. Сложность предложителей блоков по-прежнему вызывает неопределенность. Новые конструкции, такие как Orbit SSF, предоставляют возможности для дальнейшего исследования. Чем больше вариантов, тем лучше мы сможем обслуживать пользователей L1 и L2 и упрощать работу разработчиков L2.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
5
Поделиться
комментарий
0/400
quietly_staking
· 07-18 05:01
На самом деле, давно пора ускориться.
Посмотреть ОригиналОтветить0
RektButAlive
· 07-16 17:47
Быстрее, чтобы жить.
Посмотреть ОригиналОтветить0
DegenWhisperer
· 07-15 06:31
Будущее на уровне миллисекунд выглядит многообещающе
Ethereum на пути к ускорению: исследование решений для подтверждения транзакций на уровне миллисекунд
Исследование более быстрого времени подтверждения транзакций Ethereum
Быстрое время подтверждения транзакций является важной частью качественного пользовательского опыта в блокчейне. В последние годы Ethereum добился значительного прогресса в этой области. В настоящее время транзакции, отправляемые пользователями в 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) предоставляют пользователям масштабируемые услуги на этой основе. L2 стремится обеспечить пользователям более быстрое время подтверждения.
Теоретически, L2 может создать свою собственную сеть "децентрализованных сортировщиков", которая будет подписывать блоки каждые несколько сотен миллисекунд. Однако требовать от всех L2 проводить декомцентрированную сортировку кажется не совсем справедливым, так как это эквивалентно созданию совершенно нового L1.
Базовое предварительное подтверждение
Базовое предположение предварительного подтверждения заключается в том, что предложители Ethereum являются сложными участниками MEV, и эта сложность используется для стимулирования их принятия ответственности за предоставление услуг предварительного подтверждения. Этот метод создает стандартизированный протокол, в рамках которого пользователи могут предложить дополнительную плату за получение мгновенной гарантии включения транзакции в следующий блок. Если предложитель нарушит свои обязательства, он будет наказан.
Этот механизм может предоставить предварительное подтверждение для L1 транзакций и основанных на L2 блокчейнов.
Будущее
Предположим, что реализована конечность с одним слотом и используется технология, подобная Orbit, для уменьшения количества валидаторов, подписывающих каждый слот, одновременно снижая порог ставки. Длительность слота может увеличиться до 16 секунд и в сочетании с предварительным подтверждением rollup или базовым предварительным подтверждением предоставит пользователям более быстрое подтверждение. Это создаст новую архитектуру эпохи-слота.
Причина, по которой архитектура epoch-slot неизбежна, заключается в том, что время, необходимое для достижения приблизительного согласия, короче, чем время, необходимое для достижения максимальной степени "экономической окончательности" соглашения. Это связано с такими факторами, как количество узлов и "качество" узлов.
Для L2 в настоящее время существует три разумные стратегии:
Ключевой вопрос заключается в том, насколько хорошо архитектура эпохи-слота, родная для Ethereum, может работать. Если время слота удастся сократить до 1 секунды, пространство для третьей стратегии значительно уменьшится.
На данный момент мы еще далеки от окончательных ответов на эти вопросы. Сложность предложителей блоков по-прежнему вызывает неопределенность. Новые конструкции, такие как Orbit SSF, предоставляют возможности для дальнейшего исследования. Чем больше вариантов, тем лучше мы сможем обслуживать пользователей L1 и L2 и упрощать работу разработчиков L2.