Sei выпустила новый белый документ, в котором представлено последнее обновление Giga. Большинство читателей считают, что техническое содержание на 17 страницах сложно для восприятия. Поэтому в этой статье будет объяснено содержание этого обновления и то, как улучшить производительность блокчейна на разных уровнях.
1. О генерации блоков с асинхронным выполнением
Основные идеи и основы Giga следующие:
"Если наш список транзакций упорядочен и начальное состояние блокчейна согласовано, и все честные узлы обрабатывают эти транзакции в одном и том же порядке, то узлы достигнут одного и того же конечного состояния."
В этом случае результат зависит только от начального состояния и порядка транзакций. Это означает, что консенсус необходимо достичь только по порядку транзакций внутри блока, и каждый узел может независимо вычислить конечное состояние.
В этой модели разделяются консенсус и выполнение, что позволяет блокам асинхронно исполняться.
Как только блок окончательно подтвержден, узлы будут обрабатывать его и отправлять его состояние в последующих блоках.
Затем блок проверяется через консенсус состояния, чтобы убедиться, что все узлы рассчитали правильное конечное состояние.
Одной из важных деталей здесь является то, что выполнение и консенсус (генерация) происходят параллельно. Узлы, выполняя вычисления блока, также получают другие блоки.
Таким образом, блоки фактически выполняются в общем порядке (а не параллельно), в то время как процесс генерации блока действительно происходит параллельно с процессом консенсуса. Однако для любого данного блока эти процессы полностью асинхронны.
Очевидно, что одновременно достигать консенсуса и выполнять один и тот же блок невозможно. Поэтому при выполнении блока n узел будет получать блок n+1 для следующего шага.
Если консенсус будет нарушен (например, если треть узлов в сети будет действовать злонамеренно), цепочка приостановится, что похоже на стандартный BFT-протокол.
Транзакции, которые не были выполнены в блоке, не делают этот блок недействительным, они просто сохраняют состояние неудачи, поскольку создание и выполнение блока разделены, и окончательное состояние текущего блока будет зафиксировано в последующих блоках.
2.Как реализована модель с несколькими предложителями и что такоеAutobahn?
Данный консенсусный протокол называется «Autobahn» (как безлимитная немецкая автомагистраль). Autobahn отделяет доступность данных от сортировки транзакций, за чем стоит интересная модель.
Как и на любом шоссе, существует несколько полос, и у каждого узла есть свой собственный канал. Узлы используют эти каналы для внесения предложений о сортировке транзакций. Предложения представляют собой просто упорядоченную коллекцию транзакций.
Автобан иногда выполняет операцию "tipcut", то есть агрегирует несколько предложений для окончательного определения порядка транзакций.
Как уже упоминалось ранее, у каждого валидатора есть свой канал для предложения партий транзакций.
Когда узел получает действительное предложение, он отправляет голосование для подтверждения того, что предложение было получено.
После сбора предложений для голосования будет создано доказательство полезности (PoA), которое гарантирует, что данные были получены хотя бы одним честным узлом в сети.
Время возникновения Tipcut указывается в миллисекундах, и в конечном итоге несколько предложений от Autobahn будут "cut.".
Предложители имеют стимул ждать публикации блока и, при возможности, публиковать отдельный блок, но ограничение по времени выполнения для каждого блока (аналогично ограничению Gas) немного изменяет эту динамику.
Предложение на одном канале обычно эквивалентно одному блоку, что означает, что при возникновении Tipcut несколько блоков будут одновременно обрезаны.
После этого лидер данного слота отправит Tipcut другим узлам для завершения сортировки. Узлы фактически уже готовят следующий Tipcut, одновременно голосуя за отдельный Tipcut.
Узлы, пропустившие пакет, могут асинхронно получать данные от валидаторов, перечисленных в PoA: именно это и является основной причиной необходимости доступности данных.
При синхронных условиях, если лидер правильный, Autobahn завершит подтверждение предложения за два раунда связи. Если лидер выходит из строя, этот механизм выберет нового лидера для поддержания процесса.
Следующее предложение tip-cut может фактически начаться на этапе подачи текущего tip-cut, тем самым уменьшая задержку, поскольку выполнение происходит параллельно с генерацией.
На самом деле, вся модель представляет собой модель с несколькими предложителями, в которой множество узлов могут одновременно выдвигать предложения для сортировки своих блоков. Каждый валидатор предлагает свой блок и получает доказательства (PoA) от сети, которые помогают повысить пропускную способность и общую эффективность сети.
3.Параллельное выполнение и его применение
Как уже упоминалось, процесс выполнения блоков и консенсус происходят параллельно, хотя сам блок фактически выполняется последовательно. Вы можете задаться вопросом, является ли это настоящим параллельным выполнением.
Ответ одновременно утвердительный и отрицательный.
Хотя блоки выполняются последовательно, транзакции внутри блока на самом деле могут выполняться параллельно. Если транзакции не изменяют (не записывают) одно и то же состояние и результат одной транзакции не влияет на другую транзакцию, то они могут выполняться параллельно.
Короче говоря, их пути выполнения не должны зависеть друг от друга. У Giga нет пула памяти, транзакции немедленно включаются узлами.
Giga предполагает, что между большинством сделок нет конфликтов, и обрабатывает эти сделки одновременно на нескольких ядрах процессора.
Изменения каждой транзакции временно хранятся в частном буфере и не применяются немедленно к блокчейну.
После завершения обработки система проверит, существует ли конфликт между этой транзакцией и предыдущими.
Если возникнут конфликты, транзакция будет повторно обработана. Если конфликтов нет, изменения будут применены к блокчейну и окончательно подтверждены.
Также могут возникнуть ситуации с высокочастотными конфликтами, в таких случаях система переключается на обработку одной транзакции за раз, чтобы обеспечить продвижение транзакции.
Проще говоря, параллельное выполнение распределяет транзакции по нескольким ядрам, позволяя тем транзакциям, которые не конфликтуют, выполняться одновременно.
4.Проблемы хранения и оптимизация
Из-за большого объема транзакций данные должны быть как безопасными, так и легкодоступными, поэтому способ их хранения должен немного отличаться от традиционного хранения в блокчейне. Giga хранит данные в простом формате «ключ-значение», что является относительно плоской структурой, что помогает сократить количество обновлений или проверок, необходимых при изменении данных.
Кроме того, Giga использует иерархическое хранилище: недавние данные хранятся на SSD (высокая скорость), в то время как менее используемые данные перемещаются в более медленные и экономически эффективные системы хранения.
Если узел崩崩, он может воспроизвести журнал, чтобы восстановить правильное состояние, и применить обновления к RocksDB (специальной базе данных) для организации данных.
Эта система хранения использует криптографический аккумулятор, который может доказать правильность данных без тяжелых вычислений. Аккумулятор обновляется пакетным способом, что позволяет проверяющим и легким узлам быстро согласовать текущее состояние блокчейна.
5.Что означает стать многоподписчиком на EVM L1 блокчейне?
Инфраструктура уровня 1 может быть улучшена различными способами, и разные уровни 1 сталкиваются с различными техническими вызовами, от экономических вопросов, таких как MEV, до технических вопросов, таких как управление состоянием.
Будучи первой L1 цепью, поддерживающей множество предложений, это довольно сложно, особенно для EVM L1, поскольку изначальная цель дизайна EVM не заключалась в поддержке системы с множеством предложений.
Однако Sei пытается использовать разные подходы для сохранения EVM и множества инструментов, к которым привыкли многие разработчики.
Параллельное выполнение транзакций, достижение консенсуса в процессе выполнения и параллельные операции нескольких предложителей помогают повысить производительность, и throughput может увеличиться примерно в 50 раз. Однако эти улучшения также могут столкнуться с некоторыми рисками, упомянутыми выше.
Это второе крупное обновление Sei; ранее Sei преобразовалась из цепочки Cosmos в цепочку EVM, и теперь Sei представила клиент выполнения, оптимизированный для скорости.
Следующее развитие и последующие результаты этих оптимизационных мер заслуживают внимания.
Связанные материалы: Исследование производительности, соответствия и взаимной совместимости блокчейна Sei
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
1 Лайков
Награда
1
1
Поделиться
комментарий
0/400
IELTS
· 20ч назад
#MOODENG & COOKIE上涨##Staked TRX ETF申请##山寨行情即将到来吗# bsv режим ETH ethw и т.д. #比特币突破11万美元# купить режим
Интерпретация нового Вайтпейпера Sei: какие технологические инновации вводит Giga-апгрейд?
Автор: Павел Парамонов, основатель Hazeflow
Перевод: Felix, PANews
Sei выпустила новый белый документ, в котором представлено последнее обновление Giga. Большинство читателей считают, что техническое содержание на 17 страницах сложно для восприятия. Поэтому в этой статье будет объяснено содержание этого обновления и то, как улучшить производительность блокчейна на разных уровнях.
1. О генерации блоков с асинхронным выполнением
Основные идеи и основы Giga следующие:
"Если наш список транзакций упорядочен и начальное состояние блокчейна согласовано, и все честные узлы обрабатывают эти транзакции в одном и том же порядке, то узлы достигнут одного и того же конечного состояния."
В этом случае результат зависит только от начального состояния и порядка транзакций. Это означает, что консенсус необходимо достичь только по порядку транзакций внутри блока, и каждый узел может независимо вычислить конечное состояние.
Одной из важных деталей здесь является то, что выполнение и консенсус (генерация) происходят параллельно. Узлы, выполняя вычисления блока, также получают другие блоки.
Таким образом, блоки фактически выполняются в общем порядке (а не параллельно), в то время как процесс генерации блока действительно происходит параллельно с процессом консенсуса. Однако для любого данного блока эти процессы полностью асинхронны.
Очевидно, что одновременно достигать консенсуса и выполнять один и тот же блок невозможно. Поэтому при выполнении блока n узел будет получать блок n+1 для следующего шага.
Если консенсус будет нарушен (например, если треть узлов в сети будет действовать злонамеренно), цепочка приостановится, что похоже на стандартный BFT-протокол.
Транзакции, которые не были выполнены в блоке, не делают этот блок недействительным, они просто сохраняют состояние неудачи, поскольку создание и выполнение блока разделены, и окончательное состояние текущего блока будет зафиксировано в последующих блоках.
2. Как реализована модель с несколькими предложителями и что такое Autobahn ?
Данный консенсусный протокол называется «Autobahn» (как безлимитная немецкая автомагистраль). Autobahn отделяет доступность данных от сортировки транзакций, за чем стоит интересная модель.
Как и на любом шоссе, существует несколько полос, и у каждого узла есть свой собственный канал. Узлы используют эти каналы для внесения предложений о сортировке транзакций. Предложения представляют собой просто упорядоченную коллекцию транзакций.
Автобан иногда выполняет операцию "tipcut", то есть агрегирует несколько предложений для окончательного определения порядка транзакций.
Предложители имеют стимул ждать публикации блока и, при возможности, публиковать отдельный блок, но ограничение по времени выполнения для каждого блока (аналогично ограничению Gas) немного изменяет эту динамику.
Предложение на одном канале обычно эквивалентно одному блоку, что означает, что при возникновении Tipcut несколько блоков будут одновременно обрезаны.
После этого лидер данного слота отправит Tipcut другим узлам для завершения сортировки. Узлы фактически уже готовят следующий Tipcut, одновременно голосуя за отдельный Tipcut.
Узлы, пропустившие пакет, могут асинхронно получать данные от валидаторов, перечисленных в PoA: именно это и является основной причиной необходимости доступности данных.
При синхронных условиях, если лидер правильный, Autobahn завершит подтверждение предложения за два раунда связи. Если лидер выходит из строя, этот механизм выберет нового лидера для поддержания процесса.
Следующее предложение tip-cut может фактически начаться на этапе подачи текущего tip-cut, тем самым уменьшая задержку, поскольку выполнение происходит параллельно с генерацией.
На самом деле, вся модель представляет собой модель с несколькими предложителями, в которой множество узлов могут одновременно выдвигать предложения для сортировки своих блоков. Каждый валидатор предлагает свой блок и получает доказательства (PoA) от сети, которые помогают повысить пропускную способность и общую эффективность сети.
3. Параллельное выполнение и его применение
Как уже упоминалось, процесс выполнения блоков и консенсус происходят параллельно, хотя сам блок фактически выполняется последовательно. Вы можете задаться вопросом, является ли это настоящим параллельным выполнением.
Ответ одновременно утвердительный и отрицательный.
Хотя блоки выполняются последовательно, транзакции внутри блока на самом деле могут выполняться параллельно. Если транзакции не изменяют (не записывают) одно и то же состояние и результат одной транзакции не влияет на другую транзакцию, то они могут выполняться параллельно.
Короче говоря, их пути выполнения не должны зависеть друг от друга. У Giga нет пула памяти, транзакции немедленно включаются узлами.
Также могут возникнуть ситуации с высокочастотными конфликтами, в таких случаях система переключается на обработку одной транзакции за раз, чтобы обеспечить продвижение транзакции.
Проще говоря, параллельное выполнение распределяет транзакции по нескольким ядрам, позволяя тем транзакциям, которые не конфликтуют, выполняться одновременно.
4. Проблемы хранения и оптимизация
Из-за большого объема транзакций данные должны быть как безопасными, так и легкодоступными, поэтому способ их хранения должен немного отличаться от традиционного хранения в блокчейне. Giga хранит данные в простом формате «ключ-значение», что является относительно плоской структурой, что помогает сократить количество обновлений или проверок, необходимых при изменении данных.
Кроме того, Giga использует иерархическое хранилище: недавние данные хранятся на SSD (высокая скорость), в то время как менее используемые данные перемещаются в более медленные и экономически эффективные системы хранения.
Если узел崩崩, он может воспроизвести журнал, чтобы восстановить правильное состояние, и применить обновления к RocksDB (специальной базе данных) для организации данных.
Эта система хранения использует криптографический аккумулятор, который может доказать правильность данных без тяжелых вычислений. Аккумулятор обновляется пакетным способом, что позволяет проверяющим и легким узлам быстро согласовать текущее состояние блокчейна.
5. Что означает стать многоподписчиком на EVM L1 блокчейне?
Инфраструктура уровня 1 может быть улучшена различными способами, и разные уровни 1 сталкиваются с различными техническими вызовами, от экономических вопросов, таких как MEV, до технических вопросов, таких как управление состоянием.
Будучи первой L1 цепью, поддерживающей множество предложений, это довольно сложно, особенно для EVM L1, поскольку изначальная цель дизайна EVM не заключалась в поддержке системы с множеством предложений.
Однако Sei пытается использовать разные подходы для сохранения EVM и множества инструментов, к которым привыкли многие разработчики.
Параллельное выполнение транзакций, достижение консенсуса в процессе выполнения и параллельные операции нескольких предложителей помогают повысить производительность, и throughput может увеличиться примерно в 50 раз. Однако эти улучшения также могут столкнуться с некоторыми рисками, упомянутыми выше.
Это второе крупное обновление Sei; ранее Sei преобразовалась из цепочки Cosmos в цепочку EVM, и теперь Sei представила клиент выполнения, оптимизированный для скорости.
Следующее развитие и последующие результаты этих оптимизационных мер заслуживают внимания.
Связанные материалы: Исследование производительности, соответствия и взаимной совместимости блокчейна Sei