SEI представляет механизмы, включающие асинхронное выполнение, консенсус с несколькими предложениями, параллелизм транзакций и оптимизацию хранилища в обновлении Giga. Эта статья написана Павлом Парамоновым, основателем Hazeflow, и скомпилирована, скомпилирована и предоставлена Феликсом, PANews. (Синопсис: $SEI 70% за один месяц!) Запуск предложения SIP-3: переход на чистый EVM с целью 100 000 транзакций в секунду) (Предыстория добавлена: MetaMask будет поддерживать «первую цепочку без EVM» в сети Solana кошелек MetaMask из зоны комфорта Ethereum в мае) Sei выпустила новую белую книгу, в которой представлено последнее обновление Giga. Большинству читателей трудно прочитать 17 страниц с углубленным техническим содержанием. Поэтому в этой статье мы расскажем, что это за обновление и как повысить производительность блокчейна на разных уровнях. 1. Основные идеи и основы генерации блоков giga для асинхронного выполнения заключаются в следующем: «Если наш список транзакций в порядке и начальное состояние блокчейна согласовано, и все честные узлы обрабатывают эти транзакции в одинаковом порядке, то узлы достигнут одного и того же конечного состояния». В этом случае результат зависит только от исходного состояния и порядка транзакций. Это означает, что консенсусу нужно только договориться о порядке транзакций внутри блока, и каждый узел может рассчитать итоговое состояние самостоятельно. В этой модели консенсус отделен от выполнения, что позволяет блокам выполняться асинхронно. После того, как блок завершен, узел обрабатывает его и фиксирует его состояние в последующих блоках. Затем блок проверяется на основе консенсуса состояния, чтобы убедиться, что все узлы вычислили правильное конечное состояние. Важной деталью здесь является то, что выполнение и консенсус (генерация) происходят параллельно. Когда узел выполняет вычисление одного блока, он также получает другие блоки. В результате блоки фактически выполняются в общем порядке (а не параллельно), в то время как сам процесс генерации блоков происходит параллельно с консенсусом. Однако для любого конкретного блока эти процессы являются полностью асинхронными. Очевидно, что достижение консенсуса и одновременное выполнение одного и того же блока представляется невозможным. Таким образом, при выполнении блока n узел получает блок n+1 для следующего шага. Если консенсус искажен (например, треть узлов в сети действует злонамеренно), цепочка приостанавливается, как и стандартный протокол BFT. Выполнение неудачной транзакции в блоке не аннулирует блок, а просто остается в незавершенном состоянии, поскольку генерация и выполнение блока разделены, а окончательное состояние текущего блока фиксируется в последующих блоках. 2 Как реализована модель мульти-офпонсера и что такое автобан? Сам протокол консенсуса называется «Autobahn» (как немецкий автобан без ограничения скорости). Autobahn отделяет доступность данных от упорядочивания транзакций, и за этим стоит интересная модель. Так же, как и полосы любой автомагистрали, здесь есть несколько полос, каждая из которых имеет свой проезд. Узлы используют эти каналы для внесения предложений относительно порядка транзакций. Предложение — это просто упорядоченный набор транзакций. Автобан иногда выполняет операцию «tipcut», когда несколько предложений агрегируются для окончательного определения порядка транзакций. Как уже упоминалось ранее, у каждого валидатора есть свой канал для предложения большого количества транзакций. Когда узел получает действительное предложение, он отправляет голос, чтобы подтвердить, что предложение было получено. После того, как предложение выносится на голосование, формируется доказательство доступности (PoA), гарантирующее, что данные были получены по крайней мере одним честным узлом в сети. Сокращение чаевых происходит за миллисекунды, и в конечном итоге несколько предложений от Autobahn «обрезаются». У тех, кто предлагает предложение, есть стимул ждать освобождения блоков и освобождать отдельные блоки, где это возможно, но ограничение времени выполнения для каждого блока (аналогично лимиту газа) немного меняет эту динамику. Предложение на канале обычно эквивалентно блоку, что означает, что при переходе чаевых несколько блоков отсекаются одновременно. После этого лидер слота передает срез на другие узлы для завершения сортировки. Узел фактически голосует за один tipcut в то же время, когда он уже готовит следующий tipcut. Узлы, которые пропускают пакеты, могут быть получены асинхронно от валидаторов, перечисленных в доверенности: в этом и заключается суть потребности в доступности данных. В синхронных условиях, если ведущий прав, Autobahn завершает подтверждение предложения в два раунда связи. Если лидер терпит неудачу, механизм выбирает нового лидера, чтобы поддерживать программу в порядке. Следующее предложение по вырезанию может быть запущено на этапе фиксации текущего запроса, что сокращает задержку, поскольку выполнение происходит параллельно со сборкой. По сути, вся модель представляет собой модель с несколькими предложениями, в которой многие узлы могут одновременно вносить предложения по упорядочиванию своих блоков. Каждый валидатор предлагает свои собственные блоки и получает доказательство того, что сеть владеет этими блоками (PoA), что помогает повысить пропускную способность и общую эффективность сети. 3 Параллельное выполнение и его применение Как упоминалось ранее, процесс выполнения блоков происходит параллельно с консенсусом, хотя сами блоки на самом деле выполняются последовательно. Возможно, вы задаетесь вопросом, является ли это истинным параллельным выполнением. Ответ и да, и нет. Хотя блоки выполняются последовательно, транзакции внутри блоков действительно могут выполняться параллельно. Если транзакции не изменяют (не записывают) одно и то же состояние, и результат одной транзакции не влияет на другую, то они могут выполняться параллельно. Короче говоря, их пути выполнения не должны зависеть друг от друга. У Giga нет мемпула, и транзакции сразу включаются нодой. Giga предполагает, что между большинством транзакций нет конфликтов и обрабатывает их одновременно на нескольких ядрах процессора. Изменения в каждой транзакции временно хранятся в частном буфере и не применяются сразу к блокчейну. Когда обработка завершена, система проверяет, не конфликтует ли транзакция с предыдущими транзакциями. В случае возникновения конфликта транзакция будет обработана повторно. Если конфликтов нет, его изменения вносятся в блокчейн и дорабатываются. Также могут возникать высокочастотные коллизии, и в этом случае система переключается на обработку одной транзакции за раз, чтобы обеспечить продвижение транзакции. Проще говоря, параллельное выполнение распределяет транзакции между несколькими ядрами, позволяя тем транзакциям, которые не конфликтуют, выполняться одновременно. 4. Проблемы хранения и оптимизация Из-за большого объема транзакций данные должны быть безопасными и легкодоступными, поэтому они должны храниться немного иначе, чем традиционное хранение в блокчейне. Gigas хранит данные в простом формате ключ-значение, относительно плоской структуре, которая помогает снизить потребность в многочисленных обновлениях или проверках при изменении данных. Кроме того, Giga использует многоуровневое хранилище: последние данные хранятся на твердотельных накопителях (высокая скорость), в то время как менее используемые данные переносятся в более медленные и экономичные системы хранения. В случае сбоя узла он может воспроизвести журналы, чтобы восстановить правильное состояние и применить обновления к RocksDB, специализированной базе данных, для организации данных. В системе хранения используется криптографический аккумулятор, который доказывает правильность данных без тяжелых вычислений. Аккумуляторы обновляются партиями, что позволяет валидаторам и легким узлам быстро согласовывать текущее состояние блокчейна. 5. Станьте многопрофильным EVM L1 блоком...
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Интерпретация нового вайтпейпера Sei: Какие технологические инновации вводит Giga обновление?
SEI представляет механизмы, включающие асинхронное выполнение, консенсус с несколькими предложениями, параллелизм транзакций и оптимизацию хранилища в обновлении Giga. Эта статья написана Павлом Парамоновым, основателем Hazeflow, и скомпилирована, скомпилирована и предоставлена Феликсом, PANews. (Синопсис: $SEI 70% за один месяц!) Запуск предложения SIP-3: переход на чистый EVM с целью 100 000 транзакций в секунду) (Предыстория добавлена: MetaMask будет поддерживать «первую цепочку без EVM» в сети Solana кошелек MetaMask из зоны комфорта Ethereum в мае) Sei выпустила новую белую книгу, в которой представлено последнее обновление Giga. Большинству читателей трудно прочитать 17 страниц с углубленным техническим содержанием. Поэтому в этой статье мы расскажем, что это за обновление и как повысить производительность блокчейна на разных уровнях. 1. Основные идеи и основы генерации блоков giga для асинхронного выполнения заключаются в следующем: «Если наш список транзакций в порядке и начальное состояние блокчейна согласовано, и все честные узлы обрабатывают эти транзакции в одинаковом порядке, то узлы достигнут одного и того же конечного состояния». В этом случае результат зависит только от исходного состояния и порядка транзакций. Это означает, что консенсусу нужно только договориться о порядке транзакций внутри блока, и каждый узел может рассчитать итоговое состояние самостоятельно. В этой модели консенсус отделен от выполнения, что позволяет блокам выполняться асинхронно. После того, как блок завершен, узел обрабатывает его и фиксирует его состояние в последующих блоках. Затем блок проверяется на основе консенсуса состояния, чтобы убедиться, что все узлы вычислили правильное конечное состояние. Важной деталью здесь является то, что выполнение и консенсус (генерация) происходят параллельно. Когда узел выполняет вычисление одного блока, он также получает другие блоки. В результате блоки фактически выполняются в общем порядке (а не параллельно), в то время как сам процесс генерации блоков происходит параллельно с консенсусом. Однако для любого конкретного блока эти процессы являются полностью асинхронными. Очевидно, что достижение консенсуса и одновременное выполнение одного и того же блока представляется невозможным. Таким образом, при выполнении блока n узел получает блок n+1 для следующего шага. Если консенсус искажен (например, треть узлов в сети действует злонамеренно), цепочка приостанавливается, как и стандартный протокол BFT. Выполнение неудачной транзакции в блоке не аннулирует блок, а просто остается в незавершенном состоянии, поскольку генерация и выполнение блока разделены, а окончательное состояние текущего блока фиксируется в последующих блоках. 2 Как реализована модель мульти-офпонсера и что такое автобан? Сам протокол консенсуса называется «Autobahn» (как немецкий автобан без ограничения скорости). Autobahn отделяет доступность данных от упорядочивания транзакций, и за этим стоит интересная модель. Так же, как и полосы любой автомагистрали, здесь есть несколько полос, каждая из которых имеет свой проезд. Узлы используют эти каналы для внесения предложений относительно порядка транзакций. Предложение — это просто упорядоченный набор транзакций. Автобан иногда выполняет операцию «tipcut», когда несколько предложений агрегируются для окончательного определения порядка транзакций. Как уже упоминалось ранее, у каждого валидатора есть свой канал для предложения большого количества транзакций. Когда узел получает действительное предложение, он отправляет голос, чтобы подтвердить, что предложение было получено. После того, как предложение выносится на голосование, формируется доказательство доступности (PoA), гарантирующее, что данные были получены по крайней мере одним честным узлом в сети. Сокращение чаевых происходит за миллисекунды, и в конечном итоге несколько предложений от Autobahn «обрезаются». У тех, кто предлагает предложение, есть стимул ждать освобождения блоков и освобождать отдельные блоки, где это возможно, но ограничение времени выполнения для каждого блока (аналогично лимиту газа) немного меняет эту динамику. Предложение на канале обычно эквивалентно блоку, что означает, что при переходе чаевых несколько блоков отсекаются одновременно. После этого лидер слота передает срез на другие узлы для завершения сортировки. Узел фактически голосует за один tipcut в то же время, когда он уже готовит следующий tipcut. Узлы, которые пропускают пакеты, могут быть получены асинхронно от валидаторов, перечисленных в доверенности: в этом и заключается суть потребности в доступности данных. В синхронных условиях, если ведущий прав, Autobahn завершает подтверждение предложения в два раунда связи. Если лидер терпит неудачу, механизм выбирает нового лидера, чтобы поддерживать программу в порядке. Следующее предложение по вырезанию может быть запущено на этапе фиксации текущего запроса, что сокращает задержку, поскольку выполнение происходит параллельно со сборкой. По сути, вся модель представляет собой модель с несколькими предложениями, в которой многие узлы могут одновременно вносить предложения по упорядочиванию своих блоков. Каждый валидатор предлагает свои собственные блоки и получает доказательство того, что сеть владеет этими блоками (PoA), что помогает повысить пропускную способность и общую эффективность сети. 3 Параллельное выполнение и его применение Как упоминалось ранее, процесс выполнения блоков происходит параллельно с консенсусом, хотя сами блоки на самом деле выполняются последовательно. Возможно, вы задаетесь вопросом, является ли это истинным параллельным выполнением. Ответ и да, и нет. Хотя блоки выполняются последовательно, транзакции внутри блоков действительно могут выполняться параллельно. Если транзакции не изменяют (не записывают) одно и то же состояние, и результат одной транзакции не влияет на другую, то они могут выполняться параллельно. Короче говоря, их пути выполнения не должны зависеть друг от друга. У Giga нет мемпула, и транзакции сразу включаются нодой. Giga предполагает, что между большинством транзакций нет конфликтов и обрабатывает их одновременно на нескольких ядрах процессора. Изменения в каждой транзакции временно хранятся в частном буфере и не применяются сразу к блокчейну. Когда обработка завершена, система проверяет, не конфликтует ли транзакция с предыдущими транзакциями. В случае возникновения конфликта транзакция будет обработана повторно. Если конфликтов нет, его изменения вносятся в блокчейн и дорабатываются. Также могут возникать высокочастотные коллизии, и в этом случае система переключается на обработку одной транзакции за раз, чтобы обеспечить продвижение транзакции. Проще говоря, параллельное выполнение распределяет транзакции между несколькими ядрами, позволяя тем транзакциям, которые не конфликтуют, выполняться одновременно. 4. Проблемы хранения и оптимизация Из-за большого объема транзакций данные должны быть безопасными и легкодоступными, поэтому они должны храниться немного иначе, чем традиционное хранение в блокчейне. Gigas хранит данные в простом формате ключ-значение, относительно плоской структуре, которая помогает снизить потребность в многочисленных обновлениях или проверках при изменении данных. Кроме того, Giga использует многоуровневое хранилище: последние данные хранятся на твердотельных накопителях (высокая скорость), в то время как менее используемые данные переносятся в более медленные и экономичные системы хранения. В случае сбоя узла он может воспроизвести журналы, чтобы восстановить правильное состояние и применить обновления к RocksDB, специализированной базе данных, для организации данных. В системе хранения используется криптографический аккумулятор, который доказывает правильность данных без тяжелых вычислений. Аккумуляторы обновляются партиями, что позволяет валидаторам и легким узлам быстро согласовывать текущее состояние блокчейна. 5. Станьте многопрофильным EVM L1 блоком...