Оптимизация времени подтверждения транзакций 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. Это привело к разделению акцентов: L1 сосредоточен на антикоррупции, надежности и улучшении основных функций, в то время как L2 более непосредственно ориентирован на потребности пользователей.
Теоретически, создание децентрализованной сети сортировщиков является ответственностью L2. Небольшая группа валидаторов может подписывать блоки каждые несколько сотен миллисекунд и ставить активы в качестве гарантии. Эти заголовки блоков L2 в конечном итоге будут опубликованы на L1.
Тем не менее, требование о том, чтобы все L2 реализовали децентрализованный порядок, кажется не совсем разумным, это эквивалентно созданию совершенно нового L1. Поэтому была предложена идея о том, чтобы все L2 (даже L1) делили одну систему предварительного подтверждения: базовое предварительное подтверждение.
Базовое предварительное подтверждение
Основная предварительная проверка использует сложность предложителя Эфира, чтобы побудить их взять на себя ответственность за предоставление услуг предварительной проверки. Пользователи могут платить дополнительную плату, чтобы получить немедленную гарантию того, что транзакция будет включена в следующий блок. Если предложитель нарушит свои обязательства, он понесет наказание.
Этот механизм применим не только к L1 транзакциям, но и для "основанных на" Ethereum rollups, так как все L2 блоки по сути являются L1 транзакциями, и поэтому могут пользоваться теми же предварительными услугами подтверждения.
Будущее
Предположим, мы реализовали окончательность с одним слотом и использовали технологии, подобные Orbit, чтобы уменьшить количество валидаторов для проверки каждой подписи, одновременно увеличив продолжительность слота до 16 секунд. В сочетании с предварительным подтверждением rollup или базовым предварительным подтверждением мы можем предоставить пользователям более быстрый опыт подтверждения. Эта архитектура может называться структурой "эпоха-слот".
Появление такой структуры имеет свои глубокие причины: время, необходимое для достижения общего согласия по какому-либо вопросу, обычно меньше, чем время, необходимое для достижения максимальной "экономической окончательности". Влияющие факторы включают количество участвующих узлов и "качество" узлов.
Для L2 в настоящее время существуют три жизнеспособные стратегии:
Технически и концептуально полностью "основан" на Ethereum, может рассматриваться как "брендированный шард" или для более смелых технических инноваций.
В качестве "сервера с блокчейн-структурой" с использованием технологий, таких как доказательства эффективности STARK, сохраняйте эффективность сервера, получая при этом основные преимущества от размещения в блокчейне.
Компромиссный вариант: создать быструю цепочку, состоящую примерно из ста узлов, полагаясь на Эфир для предоставления дополнительной интероперабельности и безопасности.
Для различных сценариев применения время блока в 12 секунд может быть достаточным. Для приложений, требующих более быстрой подтверждения, архитектура "эпоха-слот" кажется единственным решением. Ключевым моментом является то, в какой степени мы можем оптимизировать эту архитектуру, особенно если мы сможем сократить время слота до 1 секунды, тогда привлекательность третьей стратегии значительно уменьшится.
На данный момент мы ещё далеки от окончательных ответов на эти вопросы. Сложность предложителей блоков по-прежнему вызывает большую неопределённость. Новые конструкции, такие как Orbit SSF, предоставляют возможности для дальнейшего исследования. Чем больше у нас есть вариантов, тем лучше мы сможем обслуживать пользователей L1 и L2, одновременно упрощая работу разработчиков L2.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Ускорение подтверждения транзакций в Эфире: от окончательности в одном слоте к исследованию механизма предварительного подтверждения
Оптимизация времени подтверждения транзакций 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. Это привело к разделению акцентов: L1 сосредоточен на антикоррупции, надежности и улучшении основных функций, в то время как L2 более непосредственно ориентирован на потребности пользователей.
Теоретически, создание децентрализованной сети сортировщиков является ответственностью L2. Небольшая группа валидаторов может подписывать блоки каждые несколько сотен миллисекунд и ставить активы в качестве гарантии. Эти заголовки блоков L2 в конечном итоге будут опубликованы на L1.
Тем не менее, требование о том, чтобы все L2 реализовали децентрализованный порядок, кажется не совсем разумным, это эквивалентно созданию совершенно нового L1. Поэтому была предложена идея о том, чтобы все L2 (даже L1) делили одну систему предварительного подтверждения: базовое предварительное подтверждение.
Базовое предварительное подтверждение
Основная предварительная проверка использует сложность предложителя Эфира, чтобы побудить их взять на себя ответственность за предоставление услуг предварительной проверки. Пользователи могут платить дополнительную плату, чтобы получить немедленную гарантию того, что транзакция будет включена в следующий блок. Если предложитель нарушит свои обязательства, он понесет наказание.
Этот механизм применим не только к L1 транзакциям, но и для "основанных на" Ethereum rollups, так как все L2 блоки по сути являются L1 транзакциями, и поэтому могут пользоваться теми же предварительными услугами подтверждения.
Будущее
Предположим, мы реализовали окончательность с одним слотом и использовали технологии, подобные Orbit, чтобы уменьшить количество валидаторов для проверки каждой подписи, одновременно увеличив продолжительность слота до 16 секунд. В сочетании с предварительным подтверждением rollup или базовым предварительным подтверждением мы можем предоставить пользователям более быстрый опыт подтверждения. Эта архитектура может называться структурой "эпоха-слот".
Появление такой структуры имеет свои глубокие причины: время, необходимое для достижения общего согласия по какому-либо вопросу, обычно меньше, чем время, необходимое для достижения максимальной "экономической окончательности". Влияющие факторы включают количество участвующих узлов и "качество" узлов.
Для L2 в настоящее время существуют три жизнеспособные стратегии:
Для различных сценариев применения время блока в 12 секунд может быть достаточным. Для приложений, требующих более быстрой подтверждения, архитектура "эпоха-слот" кажется единственным решением. Ключевым моментом является то, в какой степени мы можем оптимизировать эту архитектуру, особенно если мы сможем сократить время слота до 1 секунды, тогда привлекательность третьей стратегии значительно уменьшится.
На данный момент мы ещё далеки от окончательных ответов на эти вопросы. Сложность предложителей блоков по-прежнему вызывает большую неопределённость. Новые конструкции, такие как Orbit SSF, предоставляют возможности для дальнейшего исследования. Чем больше у нас есть вариантов, тем лучше мы сможем обслуживать пользователей L1 и L2, одновременно упрощая работу разработчиков L2.