Sei выпустила новый белый документ, в котором представлено последнее обновление Giga. Большинство читателей считают, что 17 страниц глубокого технического содержания трудно читать. Поэтому в этой статье будет объяснено содержание этого обновления и то, как можно улучшить производительность блокчейна на разных уровнях.
О генерации блоков с асинхронным выполнением
Основные идеи и основы Giga следующие:
Если наш список транзакций упорядочен и начальное состояние блокчейна согласовано, и все честные узлы обрабатывают эти транзакции в одном и том же порядке, тогда узлы достигнут одного и того же конечного состояния.
В этом случае результат зависит только от начального состояния и порядка транзакций. Это означает, что консенсус необходимо достичь только по порядку транзакций внутри блока, и каждый узел может независимо вычислять конечное состояние.
В этой модели консенсус отделен от исполнения, что позволяет блокам выполняться асинхронно.
Как только блок окончательно подтвержден, узлы обрабатывают его и отправляют его состояние в последующих блоках.
Затем блок проверяется с помощью консенсуса состояния, чтобы убедиться, что все узлы вычислили правильное конечное состояние.
Важно отметить, что выполнение и консенсус (генерация) происходят параллельно. Узлы, выполняя вычисления блока, также получают другие блоки.
Таким образом, блоки фактически выполняются в общем порядке (а не параллельно), и процесс генерации блоков действительно происходит параллельно с консенсусом. Однако для любого данного блока эти процессы полностью асинхронны.
Очевидно, что одновременно достичь консенсуса и выполнить один и тот же блок кажется невозможным. Таким образом, при выполнении блока n узел будет получать блок n+1 для следующего шага.
Если консенсус отклоняется (например, если треть узлов в сети ведет себя злонамеренно), цепочка приостанавливается, что похоже на стандартный BFT протокол.
Транзакции, выполненные с ошибкой внутри блока, не делают этот блок недействительным, они просто остаются в состоянии ошибки, поскольку создание блока и выполнение разделены, и окончательное состояние текущего блока будет зафиксировано в последующих блоках.
Как реализована модель с множеством предложителей и что такое Autobahn?
Данный консенсусный протокол сам по себе называется «Autobahn» (как немецкое автобан без ограничения скорости). Autobahn разделяет доступность данных и сортировку транзакций, за которым стоит интересная модель.
Как и на любой автомагистрали, существует несколько полос, и каждый узел имеет свой собственный канал. Узлы используют эти каналы для выдвижения предложений о сортировке транзакций. Предложение — это просто упорядоченная совокупность транзакций.
Автобан иногда выполняет операцию «tipcut», то есть агрегирует несколько предложений для окончательного определения порядка транзакций.
Как уже говорилось ранее, у каждого валидатора есть свой канал для предложения пакетных транзакций.
Когда узел получает действительное предложение, он отправляет голосование, чтобы подтвердить, что предложение было получено.
После сбора предложений и голосования будет сформирован доказательство полезности (PoA), чтобы гарантировать, что данные были получены по крайней мере одним честным узлом в сети.
Время срабатывания Tipcut указывается в миллисекундах, и в конечном итоге несколько предложений из Autobahn будут «cut.».
Предложители имеют стимул ждать выпуска блока и, если возможно, выпускать отдельный блок, но ограничение по времени выполнения для каждого блока (аналогично ограничению Gas) немного изменяет эту динамику.
Предложение на одном канале обычно соответствует одному блоку, что означает, что когда происходит Tipcut, несколько блоков могут быть одновременно обрезаны.
После этого лидер данного слота отправит Tipcut другим узлам для завершения сортировки. Узлы фактически уже готовят следующий Tipcut, одновременно голосуя за отдельный Tipcut.
Пропущенные узлы партии могут асинхронно получать информацию от валидаторов, перечисленных в PoA: это и есть суть необходимости доступности данных.
При синхронных условиях, если лидер правильный, Autobahn завершит подтверждение предложений за два раунда связи. Если лидер выходит из строя, механизм выберет нового лидера для поддержания процесса.
Следующее предложение tip-cut может фактически начаться на стадии подачи текущего tip-cut, тем самым уменьшая задержку, так как выполнение происходит параллельно с генерацией.
На самом деле, вся модель является моделью с несколькими предложителями, где множество узлов могут одновременно делать предложения по сортировке своих блоков. Каждый валидатор предлагает свой блок и получает доказательства (PoA) от сети о наличии этих блоков, что помогает повысить пропускную способность сети и общую эффективность.
Параллельное выполнение и его области применения
Как уже упоминалось ранее, процесс выполнения блоков и консенсус происходят параллельно, хотя сами блоки фактически выполняются последовательно. Вы можете задаться вопросом, является ли это настоящим параллельным выполнением.
Ответ как утвердительный, так и отрицательный.
Хотя блоки выполняются последовательно, транзакции внутри блока действительно могут выполняться параллельно. Если транзакции не изменяют (не записывают) одно и то же состояние, и результат одной транзакции не влияет на другую транзакцию, то их можно выполнять параллельно.
Говоря кратко, их пути выполнения не должны зависеть друг от друга. У Giga нет пула памяти, транзакции сразу включаются узлами.
Giga предполагает, что между большинством транзакций нет конфликтов, и обрабатывает эти транзакции одновременно на нескольких ядрах процессора.
Изменения каждой транзакции временно хранятся в приватном буфере и не применяются немедленно к блокчейну.
После завершения обработки система проверит, существует ли конфликт между этой транзакцией и предыдущими транзакциями.
Если возникают конфликты, эта транзакция будет обработана заново. Если конфликтов нет, изменения будут применены к блокчейну и окончательно зафиксированы.
Также могут возникать ситуации с высокочастотными конфликтами, при которых система переключается на обработку одного транзакции за раз, чтобы обеспечить продвижение транзакции.
Проще говоря, параллельное выполнение распределяет транзакции по нескольким ядрам, позволяя тем транзакциям, которые не конфликтуют, выполняться одновременно.
Проблемы хранения и оптимизация
Из-за большого объема торгов данные должны быть как безопасными, так и легкодоступными, поэтому их способ хранения должен немного отличаться от традиционного хранения в блокчейне. Giga хранит данные в простой формате ключ-значение, что является относительно плоской структурой, что помогает сократить количество необходимых обновлений или проверок при изменении данных.
Кроме того, Giga использует многоуровневый подход к хранению: последние данные остаются на твердотельных накопителях (высокоскоростные), в то время как менее используемые данные переносятся в более медленные и экономичные системы хранения.
Если узел выходит из строя, он может воспроизвести журнал, чтобы восстановить правильное состояние, и применить обновления к RocksDB (специальная база данных) для организации данных.
Система хранения использует криптографический аккумулятор для доказательства правильности данных без необходимости сложных вычислений. Аккумулятор обновляется пакетами, что позволяет валидаторам и легким узлам быстро согласовывать текущее состояние блокчейна.
Что значит стать многопредставителем EVM L1 блокчейна?
Инфраструктура L1 может быть улучшена различными способами, а разные L1 сталкиваются с различными техническими вызовами, от экономических проблем, таких как MEV, до технических вопросов, таких как управление состоянием.
Будучи первой L1 цепью, поддерживающей множество предложителей, это довольно сложно, особенно для EVM L1, поскольку изначальная цель дизайна EVM не поддерживать систему с несколькими предложителями.
Однако Sei пытается использовать различные методы, чтобы сохранить EVM и многие инструменты, которые привыкли использовать разработчики.
Параллельное выполнение транзакций, достижение консенсуса в процессе выполнения и параллельная работа нескольких предложителей помогают повысить производительность, пропускная способность выполнения может увеличиться примерно в 50 раз. Однако эти улучшения также могут столкнуться с некоторыми рисками, упомянутыми выше.
Это второе крупное обновление Sei, ранее Sei преобразовалась из сети Cosmos в EVM-сеть, а теперь Sei выпустила клиент выполнения, оптимизированный по скорости.
Следующее развитие и последующие эффекты этих оптимизационных мер заслуживают внимания.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Интерпретация нового вайтпейпера Sei: какие технологические инновации вводит Giga обновление?
Автор: Павел Парамонов, основатель Hazeflow
Перевод: PANews
Sei выпустила новый белый документ, в котором представлено последнее обновление Giga. Большинство читателей считают, что 17 страниц глубокого технического содержания трудно читать. Поэтому в этой статье будет объяснено содержание этого обновления и то, как можно улучшить производительность блокчейна на разных уровнях.
О генерации блоков с асинхронным выполнением
Основные идеи и основы Giga следующие:
Если наш список транзакций упорядочен и начальное состояние блокчейна согласовано, и все честные узлы обрабатывают эти транзакции в одном и том же порядке, тогда узлы достигнут одного и того же конечного состояния.
В этом случае результат зависит только от начального состояния и порядка транзакций. Это означает, что консенсус необходимо достичь только по порядку транзакций внутри блока, и каждый узел может независимо вычислять конечное состояние.
В этой модели консенсус отделен от исполнения, что позволяет блокам выполняться асинхронно.
Как только блок окончательно подтвержден, узлы обрабатывают его и отправляют его состояние в последующих блоках.
Затем блок проверяется с помощью консенсуса состояния, чтобы убедиться, что все узлы вычислили правильное конечное состояние.
Важно отметить, что выполнение и консенсус (генерация) происходят параллельно. Узлы, выполняя вычисления блока, также получают другие блоки.
Таким образом, блоки фактически выполняются в общем порядке (а не параллельно), и процесс генерации блоков действительно происходит параллельно с консенсусом. Однако для любого данного блока эти процессы полностью асинхронны.
Очевидно, что одновременно достичь консенсуса и выполнить один и тот же блок кажется невозможным. Таким образом, при выполнении блока n узел будет получать блок n+1 для следующего шага.
Если консенсус отклоняется (например, если треть узлов в сети ведет себя злонамеренно), цепочка приостанавливается, что похоже на стандартный BFT протокол.
Транзакции, выполненные с ошибкой внутри блока, не делают этот блок недействительным, они просто остаются в состоянии ошибки, поскольку создание блока и выполнение разделены, и окончательное состояние текущего блока будет зафиксировано в последующих блоках.
Как реализована модель с множеством предложителей и что такое Autobahn?
Данный консенсусный протокол сам по себе называется «Autobahn» (как немецкое автобан без ограничения скорости). Autobahn разделяет доступность данных и сортировку транзакций, за которым стоит интересная модель.
Как и на любой автомагистрали, существует несколько полос, и каждый узел имеет свой собственный канал. Узлы используют эти каналы для выдвижения предложений о сортировке транзакций. Предложение — это просто упорядоченная совокупность транзакций.
Автобан иногда выполняет операцию «tipcut», то есть агрегирует несколько предложений для окончательного определения порядка транзакций.
Как уже говорилось ранее, у каждого валидатора есть свой канал для предложения пакетных транзакций.
Когда узел получает действительное предложение, он отправляет голосование, чтобы подтвердить, что предложение было получено.
После сбора предложений и голосования будет сформирован доказательство полезности (PoA), чтобы гарантировать, что данные были получены по крайней мере одним честным узлом в сети.
Время срабатывания Tipcut указывается в миллисекундах, и в конечном итоге несколько предложений из Autobahn будут «cut.».
Предложители имеют стимул ждать выпуска блока и, если возможно, выпускать отдельный блок, но ограничение по времени выполнения для каждого блока (аналогично ограничению Gas) немного изменяет эту динамику.
Предложение на одном канале обычно соответствует одному блоку, что означает, что когда происходит Tipcut, несколько блоков могут быть одновременно обрезаны.
После этого лидер данного слота отправит Tipcut другим узлам для завершения сортировки. Узлы фактически уже готовят следующий Tipcut, одновременно голосуя за отдельный Tipcut.
Пропущенные узлы партии могут асинхронно получать информацию от валидаторов, перечисленных в PoA: это и есть суть необходимости доступности данных.
При синхронных условиях, если лидер правильный, Autobahn завершит подтверждение предложений за два раунда связи. Если лидер выходит из строя, механизм выберет нового лидера для поддержания процесса.
Следующее предложение tip-cut может фактически начаться на стадии подачи текущего tip-cut, тем самым уменьшая задержку, так как выполнение происходит параллельно с генерацией.
На самом деле, вся модель является моделью с несколькими предложителями, где множество узлов могут одновременно делать предложения по сортировке своих блоков. Каждый валидатор предлагает свой блок и получает доказательства (PoA) от сети о наличии этих блоков, что помогает повысить пропускную способность сети и общую эффективность.
Параллельное выполнение и его области применения
Как уже упоминалось ранее, процесс выполнения блоков и консенсус происходят параллельно, хотя сами блоки фактически выполняются последовательно. Вы можете задаться вопросом, является ли это настоящим параллельным выполнением.
Ответ как утвердительный, так и отрицательный.
Хотя блоки выполняются последовательно, транзакции внутри блока действительно могут выполняться параллельно. Если транзакции не изменяют (не записывают) одно и то же состояние, и результат одной транзакции не влияет на другую транзакцию, то их можно выполнять параллельно.
Говоря кратко, их пути выполнения не должны зависеть друг от друга. У Giga нет пула памяти, транзакции сразу включаются узлами.
Giga предполагает, что между большинством транзакций нет конфликтов, и обрабатывает эти транзакции одновременно на нескольких ядрах процессора.
Изменения каждой транзакции временно хранятся в приватном буфере и не применяются немедленно к блокчейну.
После завершения обработки система проверит, существует ли конфликт между этой транзакцией и предыдущими транзакциями.
Если возникают конфликты, эта транзакция будет обработана заново. Если конфликтов нет, изменения будут применены к блокчейну и окончательно зафиксированы.
Также могут возникать ситуации с высокочастотными конфликтами, при которых система переключается на обработку одного транзакции за раз, чтобы обеспечить продвижение транзакции.
Проще говоря, параллельное выполнение распределяет транзакции по нескольким ядрам, позволяя тем транзакциям, которые не конфликтуют, выполняться одновременно.
Проблемы хранения и оптимизация
Из-за большого объема торгов данные должны быть как безопасными, так и легкодоступными, поэтому их способ хранения должен немного отличаться от традиционного хранения в блокчейне. Giga хранит данные в простой формате ключ-значение, что является относительно плоской структурой, что помогает сократить количество необходимых обновлений или проверок при изменении данных.
Кроме того, Giga использует многоуровневый подход к хранению: последние данные остаются на твердотельных накопителях (высокоскоростные), в то время как менее используемые данные переносятся в более медленные и экономичные системы хранения.
Если узел выходит из строя, он может воспроизвести журнал, чтобы восстановить правильное состояние, и применить обновления к RocksDB (специальная база данных) для организации данных.
Система хранения использует криптографический аккумулятор для доказательства правильности данных без необходимости сложных вычислений. Аккумулятор обновляется пакетами, что позволяет валидаторам и легким узлам быстро согласовывать текущее состояние блокчейна.
Что значит стать многопредставителем EVM L1 блокчейна?
Инфраструктура L1 может быть улучшена различными способами, а разные L1 сталкиваются с различными техническими вызовами, от экономических проблем, таких как MEV, до технических вопросов, таких как управление состоянием.
Будучи первой L1 цепью, поддерживающей множество предложителей, это довольно сложно, особенно для EVM L1, поскольку изначальная цель дизайна EVM не поддерживать систему с несколькими предложителями.
Однако Sei пытается использовать различные методы, чтобы сохранить EVM и многие инструменты, которые привыкли использовать разработчики.
Параллельное выполнение транзакций, достижение консенсуса в процессе выполнения и параллельная работа нескольких предложителей помогают повысить производительность, пропускная способность выполнения может увеличиться примерно в 50 раз. Однако эти улучшения также могут столкнуться с некоторыми рисками, упомянутыми выше.
Это второе крупное обновление Sei, ранее Sei преобразовалась из сети Cosmos в EVM-сеть, а теперь Sei выпустила клиент выполнения, оптимизированный по скорости.
Следующее развитие и последующие эффекты этих оптимизационных мер заслуживают внимания.