Обсуждение практических решений для повышения скорости подтверждения транзакций в Ethereum
Ethereum в последние годы добился значительных успехов в скорости подтверждения транзакций. В настоящее время транзакции, отправленные пользователями на L1, обычно подтверждаются в течение 5-20 секунд, что сопоставимо с опытом оплаты кредитной картой. Однако дальнейшее улучшение пользовательского опыта по-прежнему необходимо, некоторые приложения даже требуют сокращения задержки до нескольких сотен миллисекунд. В этой статье будут рассмотрены некоторые жизнеспособные варианты улучшения времени подтверждения транзакций в Ethereum.
Обзор существующих технологий и идей
Однослотовая окончательность
Текущий механизм согласования Gasper, используемый в Ethereum, использует архитектуру с одним слотом и эпохами. Каждые 12 секунд - это один слот, часть валидаторов голосует за заглавие цепи, в течение 32 слотов (6,4 минуты) все валидаторы имеют возможность проголосовать один раз. Эти голоса затем интерпретируются как сообщения, аналогичные алгоритму согласования PBFT, а через две эпохи (12,8 минуты) предоставляется сильная экономическая гарантия, называемая окончательностью.
Однако у этого метода есть две основные проблемы: высокая сложность и слишком длительное время окончательного подтверждения в 12,8 минуты. Для решения этих проблем была предложена односеточная окончательность (Single Slot Finality, SSF), которая представляет собой механизм, аналогичный консенсусу Tendermint, то есть окончательное подтверждение текущего блока завершается до генерации следующего блока.
Основная проблема SSF заключается в том, что каждый ставщик должен каждые 12 секунд отправлять два сообщения, что создает огромную нагрузку на сеть. Несмотря на некоторые инновационные идеи, такие как предложение Orbit SSF, которые пытаются смягчить эту проблему, пользователям все равно необходимо ждать от 5 до 20 секунд для подтверждения транзакции.
Предварительное подтверждение Rollup
С учетом того, что Ethereum принимает стратегию развития с центром на rollup, L2-протоколы (такие как rollups, validiums и plasmas) могут предоставлять пользователям масштабируемые услуги с такой же безопасностью, как и в Ethereum. Это привело к распределению ролей внутри экосистемы Ethereum: L1 сосредоточен на защите от цензуры, надежности и поддержании и улучшении основных функций, в то время как L2 стремится напрямую удовлетворять потребности пользователей с помощью различных технологий и культур.
Теоретически, L2 может создать свою собственную сеть "децентрализованных сортировщиков", в которой небольшая группа валидаторов подписывает блоки каждые несколько сотен миллисекунд, используя свои залоговые активы в качестве гарантии. Заголовки этих L2 блоков в конечном итоге будут опубликованы на L1.
Однако требование ко всем L2 создать децентрализованную сеть сортировки кажется маловероятным, это эквивалентно требованию от rollup выполнить почти ту же работу, что и создание совершенно нового L1. Поэтому было предложено, чтобы все L2 (а также L1) делили одну предварительную механизм подтверждения в пределах Эфира: базовое предварительное подтверждение.
Базовое предварительное подтверждение
Базовый метод предварительного подтверждения предполагает, что участники-инициаторы Ethereum являются высококвалифицированными участниками. Этот метод использует их профессионализм, мотивируя этих инициаторов взять на себя ответственность за предоставление услуг предварительного подтверждения.
Основная идея заключается в создании стандартизированного протокола, который позволяет пользователям платить дополнительные сборы для получения немедленной гарантии, что их транзакция будет включена в следующий блок, а также для получения подтверждения результата выполнения транзакции. Если предложитель нарушает свои обязательства, он столкнется с наказанием.
Этот механизм применим не только к L1-транзакциям, но и к rollups, основанным на Ethereum, все L2-блоки по сути являются L1-транзакциями, поэтому тот же механизм также может предоставлять услуги предварительного подтверждения для любых L2.
Направления будущего развития
Предположим, мы реализовали конечность в одном слоте и используем технологии, подобные Orbit, чтобы уменьшить количество валидаторов в каждом слоте, при этом сохраняя достаточный уровень децентрализации для снижения порога для стейкинга. Длительность слота может увеличиться до 16 секунд, после чего мы можем использовать предварительное подтверждение rollup или базовое предварительное подтверждение, чтобы предоставить пользователям более быстрое подтверждение. Таким образом, мы в конечном итоге получаем архитектуру epoch-slot.
Эта архитектура трудно избежать, в первую очередь потому, что время, необходимое для достижения приблизительного согласия по какому-либо вопросу, намного меньше, чем время, необходимое для достижения максимальной "экономической окончательности". Основные причины включают:
"Приблизительное согласие" требует участия лишь небольшого числа узлов, в то время как экономическая окончательность требует участия большинства узлов.
После достижения определенного количества узлов время, необходимое для сбора подписей, значительно увеличится.
Таким образом, архитектура эпохи и слота кажется правильным направлением развития, но различные способы реализации могут иметь разные эффекты. Стоит дополнительно исследовать установление более сильного разделения внимания между двумя механизмами, а не такую тесную связь, как в Gasper.
Стратегия развития L2
Для L2 в настоящее время существуют три разумные стратегии развития:
В техническом и концептуальном плане "основан" на Ethereum, оптимизируя его базовые технологические характеристики и ценности.
Стать "сервером с блокчейн-скелетом", максимально используя эффективность централизованных серверов, одновременно обеспечивая безопасность и децентрализацию за счет добавления элементов блокчейна.
Компромиссный вариант: создать быструю цепочку с примерно сотней узлов, одновременно используя Эфир для обеспечения дополнительной совместимости и безопасности.
Для различных сценариев применения эти три стратегии имеют свои преимущества. Ключевым вопросом является то, насколько мы можем оптимизировать встроенную в Ethereum архитектуру эпох и слотов. Если удастся сократить время слота до 1 секунды, то пространство для третьей стратегии может значительно уменьшиться.
В настоящее время мы еще далеки от окончательных ответов на эти вопросы. Существуют значительные неопределенности, связанные со сложностью предложений блоков и потенциалом новых дизайнов, таких как Orbit SSF. Продолжение исследования и совершенствования этих решений поможет предоставить пользователям L1 и L2 лучший опыт, а также упростит работу разработчиков L2.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
4
Репост
Поделиться
комментарий
0/400
NotAFinancialAdvice
· 10ч назад
tps еще нужно ускорить
Посмотреть ОригиналОтветить0
BugBountyHunter
· 10ч назад
Скорость交易 все еще недостаточно быстрая.
Посмотреть ОригиналОтветить0
AirdropF5Bro
· 10ч назад
Нет рынка, жестко f5 Аирдроп
Посмотреть ОригиналОтветить0
pvt_key_collector
· 11ч назад
Какой смысл в быстрой скорости? Сначала выжить, а потом поговорим.
Обсуждение решений по ускорению Ethereum: окончательность в одном слоте, предварительное подтверждение Rollup и базовое предварительное подтверждение
Обсуждение практических решений для повышения скорости подтверждения транзакций в Ethereum
Ethereum в последние годы добился значительных успехов в скорости подтверждения транзакций. В настоящее время транзакции, отправленные пользователями на L1, обычно подтверждаются в течение 5-20 секунд, что сопоставимо с опытом оплаты кредитной картой. Однако дальнейшее улучшение пользовательского опыта по-прежнему необходимо, некоторые приложения даже требуют сокращения задержки до нескольких сотен миллисекунд. В этой статье будут рассмотрены некоторые жизнеспособные варианты улучшения времени подтверждения транзакций в Ethereum.
Обзор существующих технологий и идей
Однослотовая окончательность
Текущий механизм согласования Gasper, используемый в Ethereum, использует архитектуру с одним слотом и эпохами. Каждые 12 секунд - это один слот, часть валидаторов голосует за заглавие цепи, в течение 32 слотов (6,4 минуты) все валидаторы имеют возможность проголосовать один раз. Эти голоса затем интерпретируются как сообщения, аналогичные алгоритму согласования PBFT, а через две эпохи (12,8 минуты) предоставляется сильная экономическая гарантия, называемая окончательностью.
Однако у этого метода есть две основные проблемы: высокая сложность и слишком длительное время окончательного подтверждения в 12,8 минуты. Для решения этих проблем была предложена односеточная окончательность (Single Slot Finality, SSF), которая представляет собой механизм, аналогичный консенсусу Tendermint, то есть окончательное подтверждение текущего блока завершается до генерации следующего блока.
Основная проблема SSF заключается в том, что каждый ставщик должен каждые 12 секунд отправлять два сообщения, что создает огромную нагрузку на сеть. Несмотря на некоторые инновационные идеи, такие как предложение Orbit SSF, которые пытаются смягчить эту проблему, пользователям все равно необходимо ждать от 5 до 20 секунд для подтверждения транзакции.
Предварительное подтверждение Rollup
С учетом того, что Ethereum принимает стратегию развития с центром на rollup, L2-протоколы (такие как rollups, validiums и plasmas) могут предоставлять пользователям масштабируемые услуги с такой же безопасностью, как и в Ethereum. Это привело к распределению ролей внутри экосистемы Ethereum: L1 сосредоточен на защите от цензуры, надежности и поддержании и улучшении основных функций, в то время как L2 стремится напрямую удовлетворять потребности пользователей с помощью различных технологий и культур.
Теоретически, L2 может создать свою собственную сеть "децентрализованных сортировщиков", в которой небольшая группа валидаторов подписывает блоки каждые несколько сотен миллисекунд, используя свои залоговые активы в качестве гарантии. Заголовки этих L2 блоков в конечном итоге будут опубликованы на L1.
Однако требование ко всем L2 создать децентрализованную сеть сортировки кажется маловероятным, это эквивалентно требованию от rollup выполнить почти ту же работу, что и создание совершенно нового L1. Поэтому было предложено, чтобы все L2 (а также L1) делили одну предварительную механизм подтверждения в пределах Эфира: базовое предварительное подтверждение.
Базовое предварительное подтверждение
Базовый метод предварительного подтверждения предполагает, что участники-инициаторы Ethereum являются высококвалифицированными участниками. Этот метод использует их профессионализм, мотивируя этих инициаторов взять на себя ответственность за предоставление услуг предварительного подтверждения.
Основная идея заключается в создании стандартизированного протокола, который позволяет пользователям платить дополнительные сборы для получения немедленной гарантии, что их транзакция будет включена в следующий блок, а также для получения подтверждения результата выполнения транзакции. Если предложитель нарушает свои обязательства, он столкнется с наказанием.
Этот механизм применим не только к L1-транзакциям, но и к rollups, основанным на Ethereum, все L2-блоки по сути являются L1-транзакциями, поэтому тот же механизм также может предоставлять услуги предварительного подтверждения для любых L2.
Направления будущего развития
Предположим, мы реализовали конечность в одном слоте и используем технологии, подобные Orbit, чтобы уменьшить количество валидаторов в каждом слоте, при этом сохраняя достаточный уровень децентрализации для снижения порога для стейкинга. Длительность слота может увеличиться до 16 секунд, после чего мы можем использовать предварительное подтверждение rollup или базовое предварительное подтверждение, чтобы предоставить пользователям более быстрое подтверждение. Таким образом, мы в конечном итоге получаем архитектуру epoch-slot.
Эта архитектура трудно избежать, в первую очередь потому, что время, необходимое для достижения приблизительного согласия по какому-либо вопросу, намного меньше, чем время, необходимое для достижения максимальной "экономической окончательности". Основные причины включают:
Таким образом, архитектура эпохи и слота кажется правильным направлением развития, но различные способы реализации могут иметь разные эффекты. Стоит дополнительно исследовать установление более сильного разделения внимания между двумя механизмами, а не такую тесную связь, как в Gasper.
Стратегия развития L2
Для L2 в настоящее время существуют три разумные стратегии развития:
Для различных сценариев применения эти три стратегии имеют свои преимущества. Ключевым вопросом является то, насколько мы можем оптимизировать встроенную в Ethereum архитектуру эпох и слотов. Если удастся сократить время слота до 1 секунды, то пространство для третьей стратегии может значительно уменьшиться.
В настоящее время мы еще далеки от окончательных ответов на эти вопросы. Существуют значительные неопределенности, связанные со сложностью предложений блоков и потенциалом новых дизайнов, таких как Orbit SSF. Продолжение исследования и совершенствования этих решений поможет предоставить пользователям L1 и L2 лучший опыт, а также упростит работу разработчиков L2.