Свернутая и разделенная SVM: Углубленный анализ

Введение

По мере широкого распространения технологии блокчейн проблемы масштабируемости на цепочке становятся все более актуальными, особенно в экосистемах с публичной цепочкой, таких как Ethereum. Как добиться высокой пропускной способности и низкой стоимости транзакций, обеспечив при этом децентрализацию и безопасность, стало одной из главных задач. Rollup, как решение второго уровня (L2), привлекло широкое внимание. Среди них Optimistic Rollup является широко используемой репрезентативной схемой, а Optimism — ее флагманским проектом.

В этой статье мы рассмотрим Optimism в качестве примера, начиная с механизма работы Optimistic Rollup и заканчивая глубоким анализом его механизмов обеспечения безопасности. Цель состоит в том, чтобы помочь читателям досконально разобраться в основополагающих принципах деривации и развязки блоков, а затем изучить конкретные конструктивные и архитектурные преимущества развязанной SVM SOON. Это позволит читателям получить глубокое понимание концепции и принципов Decoupled SVM.

Чтобы заложить прочный фундамент для последующих обсуждений, мы начнем с анализа основ Rollup, чтобы понять, как гарантируется фундаментальная безопасность Optimistic Rollup. Rollup — это мейнстримное решение для масштабирования, которое снижает стоимость взаимодействия пользователей с блокчейном. Однако мало кто досконально изучил технические принципы и вопросы безопасности, лежащие в основе Rollup, а комплексные анализы с общей точки зрения встречаются редко. Сегодня мы подробно рассмотрим принципы работы и глубинные проблемы.

Архитектура оптимистического сворачивания — оптимизм как пример

Ключевые компоненты архитектуры оптимистического сворачивания

Перед L2 стоит очень важная проблема: как вывести блоки из L1?

Причина, по которой извлечение блоков так важно, заключается в том, что L2 по сути является расширением L1. L2 не может самостоятельно вести бухгалтерскую книгу без L1, и легитимность бухгалтерской книги L2 также должна быть записана на L1 таким образом, чтобы децентрализованный консенсус L1 мог ее подтвердить.

Прежде чем погрузиться в специфику деривации, давайте сначала рассмотрим отношения между L1 и L2. Как именно общаются L2 и L1, и какова взаимосвязь между этими данными?

Ключевые данные, которые L2 передает L1 для хранения, включают в себя:

• DA Commitment: Это означает, что данные транзакции L2 были опубликованы, гарантируя, что последующие проверяющие смогут получить доступ и проверить эти данные.
• Корень состояния: Отражает состояние цепочки после выполнения L2;
• Blob (обычно размещается в отдельном слое DA): Это данные блоба, представленные L2 и служащие доказательством доступности данных.

Эти сохраненные данные гарантируют завершенность транзакций L2 и служат основой для будущих проверок и проблем.

Системам L2 необходимо прослушивать ключевые данные транзакций из L1, чтобы обеспечить синхронизацию и согласованность с L1. К основным данным, которые прослушивает L2, относятся:

• Транзакции по пополнению и снятию средств: L2 должна постоянно отслеживать операции по пополнению и снятию средств на L1, поскольку подтверждение этих операций на L1 напрямую влияет на состояние счета пользователя на L2. L2 должен синхронизировать эти транзакции в реальном времени, чтобы обеспечить безопасность и последовательность в движении средств между L1 и L2.
• Пакетные данные транзакций, представленные L2: Это пакетные данные, которые L2 отправляет в L1 и которые содержат детали транзакций. Они позволяют L1 или независимым верификаторам воспроизводить эти транзакции и выполнять проверку состояния.

Включает в себя:

• Транзакции ввода и вывода средств: L2 должна постоянно отслеживать транзакции по пополнению и снятию средств на L1, поскольку подтверждение этих транзакций на L1 напрямую влияет на состояние счетов пользователей на L2. L2 должен синхронизировать эти транзакции в режиме реального времени, чтобы обеспечить безопасность и согласованность в потоке средств между L1 и L2.
• Пакетные данные транзакций, представленные L2: Это пакетные данные, которые L2 отправляет в L1 и которые содержат детали транзакций. Они позволяют L1 или

Почему все устроено именно так?

Мы можем разделить данные, которые L2 передает L1, на два основных типа для понимания:

Первый тип — это информация о партиях транзакций. Эта пакетная информация особенно важна, поскольку она помогает независимым верификаторам воспроизводить транзакции L2. Верификаторы могут использовать эту пакетную информацию для повторного вычисления независимого корня состояния и проверки его соответствия корню состояния, который L2 передал L1. Это ключевой момент в обеспечении того, что L2 не может «вести себя неправильно» по своему усмотрению. Если данные, предоставленные L2, являются незаконными или мошенническими, независимые верификаторы после повторного воспроизведения и получения другого корня состояния могут предоставить доказательство ошибки и инициировать вызов, требующий отката блока.

Второй тип — корень состояния. Корень состояния отражает состояние цепи после выполнения транзакций L2, включая остатки на счетах, состояние контрактов и т. д. Эти данные передаются в L1 для верификации данных. Если независимые верификаторы вычисляют другой результат, они могут инициировать вызов. Поэтому L2 должна убедиться, что данные, переданные в L1, полностью корректны; в противном случае она может столкнуться с проблемами и штрафами со стороны проверяющих.

Основные данные, которые L2 прослушивает от L1, — это транзакции по пополнению и снятию средств. Депозиты и снятия средств на L1 должны быть отражены в статусах счетов на L2. Это обеспечивает безопасность и согласованность межцепочечных операций с фондами. L2 также должен прослушивать пакетные данные транзакций.

Может возникнуть вопрос: раз L2 сам отправляет эти данные, зачем ему еще нужно их прослушивать?

Даже если транзакции L2 сначала упаковываются и отправляются в L1, L2 должен обеспечить согласованность, подтвердив, что данные действительно были успешно отправлены и доступны. Хотя данные были первоначально упакованы и переданы L2 в L1, L2 все равно должен прослушать эти данные партии еще раз от L1, чтобы подтвердить, что они были записаны правильно. Этот процесс, по сути, является гарантией безопасности. Если переданные данные не записаны на L1, L2 не может обеспечить безопасность системы.

В этот момент может возникнуть другой вопрос: почему L2 не нужно ждать, пока L1 подтвердит представленные данные, прежде чем продолжать производство блоков? В этом и заключается суть «оптимистического предположения» в Optimistic Rollup: оптимистическое выполнение. L2 не нужно ждать подтверждения L1 на каждом шаге, вместо этого он продолжает производить блоки и обрабатывать транзакции самостоятельно, предполагая, что все транзакции легальны и действительны. Это значительно повышает эффективность системы, позволяя избежать длительных задержек, связанных с процессом проверки. Каждый блок L2 предполагает, что транзакции действительны, и периодически отправляет данные о транзакциях партиями в L1, пока верификатор не обнаружит проблему, не представит доказательство неисправности и не инициирует вызов.

Теперь мы можем понять, что L2 является производной от L1.

Инженерная реализация — пример Optimism
В настоящее время основными компонентами Optimism являются: op-node, op-geth, op-batcher и op-proposer.

• op-node: Это узел-координатор в системе. Он взаимодействует с L1 (основной сетью Ethereum), получая заголовки блоков и информацию о транзакциях из L1, и одновременно управляет логикой перехода состояний в сети L2. Оп-узел действует как мост между L1 и L2, помогая передавать данные блоков из L1 в сеть L2. Кроме того, это основной узел, который координирует работу различных компонентов.
• op-geth: Это узел, который реализует виртуальную машину Ethereum (EVM) на Optimism. Он отвечает за выполнение смарт-контрактов и транзакций на L2. По сути, все смарт-контракты и среды исполнения, работающие на L2, обрабатываются op-geth, который служит основным механизмом исполнения.
• op-batcher: Этот компонент отвечает за отправку транзакций, упакованных на L2, на L1. Он собирает транзакции пользователей, упаковывает их в пакет и отправляет пакет в Ethereum L1 через L1-RPC. Этот пакет данных не выполняется немедленно, а хранится на L1, и обновления состояния L2 зависят от этих пакетов.
• op-proposer: Этот компонент отвечает за отправку корней состояния L2 в L1. Всякий раз, когда в сети L2 происходит изменение состояния (например, выполнение транзакций), op-proposer периодически отправляет эти изменения состояния в L1.

Узел op-node и op-geth вместе образуют то, что обычно называют Sequencer, а op-batcher и op-proposer в основном отвечают за обеспечение верифицируемости данных транзакций, о которых мы говорили ранее, уделяя основное внимание безопасности по проекту.

В этот момент может возникнуть другой вопрос: зачем нужны и op-batcher, и op-proposer, хотя они оба передают данные в L1? Как мы уже говорили, op-batcher подает только «сырье» (партии транзакций), в то время как конечный «продукт» (корень состояния) генерируется механизмом исполнения (op-geth) на L2 и в конечном итоге подается на L1 op-proposer’ом.

Таким образом, хотя данные, предоставляемые op-batcher, важны, он не управляет передачей состояния от L2 к L1 напрямую. Вместо этого он просто предоставляет данные транзакции, которые могут быть воспроизведены независимыми верификаторами. Секвенсор (op-node + op-geth), в предположении оптимистичного выполнения, производит блоки независимо и периодически предоставляет данные транзакций и результаты op-batcher’у и op-proposer’у.

В кратком изложении:

• op-node: Координирует синхронизацию данных между L1 и L2.
• op-geth: Выполняет транзакции и контракты на L2.
• op-batcher: Отправляет партии транзакций на L2 для обеспечения верифицируемости данных.
• op-proposer: Периодически отправляет корень состояния L2 в L1, чтобы обеспечить обновление состояния и согласованность данных.

Из предыдущих обсуждений мы можем понять, как гарантируется безопасность L2. Хотя мы специально не обсуждали доказательства отказов, основные условия для них уже неявно отражены в архитектуре L2. Безопасность системы L2 зависит от независимых верификаторов, которые воспроизводят данные транзакций, представленные L2, чтобы проверить их корректность и, впоследствии, при необходимости, поставить под сомнение.

В системе Optimistic Rollup предполагается, что данные транзакций и корни состояний, переданные из L2 в L1, корректны, и система не проводит немедленной полной проверки. Это оптимистичное предположение позволяет L2 продолжать эффективную обработку транзакций и генерировать блоки, не дожидаясь индивидуальной проверки каждой транзакции. Благодаря увеличению пропускной способности и снижению стоимости транзакций система становится высокоэффективной.

В процессе проверки, если подтверждается, что в корне состояния есть проблемы, L1 запускает механизм отката, отменяя ошибочный блок и наказывая сущность L2. Верификатор, предоставивший доказательство ошибки, получает вознаграждение в соответствии с дизайном системы, что стимулирует больше верификаторов активно участвовать в контроле безопасности системы.

В этом заключается существенное различие между Rollups и суверенными блокчейнами. Оптимистичные Rollups сосредоточены на верифицируемости данных, сначала предполагая, что данные верны, а затем ожидая, пока независимые верификаторы поставят их под сомнение. В отличие от них, суверенные блокчейны сосредоточены на создании децентрализованных узлов и механизмов консенсуса.

Отделение уровня исполнения от уровня консенсуса

Далее мы углубимся в концепцию разделения. На примере Optimism, проведя предыдущий анализ, мы видим, что в результате разработки Optimism блокчейн L2 отделяется от механизма консенсуса L1, при этом сохраняется механизм верификации для обеспечения безопасности. По сути, это и есть разделение. Основная идея разделения заключается в том, чтобы отделить уровень исполнения от уровня консенсуса, позволив им работать независимо друг от друга. В традиционных архитектурах блокчейна исполнение и консенсус тесно связаны друг с другом, то есть транзакции должны быть подтверждены консенсусом узлов, прежде чем они будут обработаны.

Ключевая роль конвейера деривации

Хотя в процессе разделения уровней исполнения и консенсуса L2 может самостоятельно производить блоки, безопасность системы по-прежнему зависит от конвейера деривации L1.

Конвейер деривации решает потенциальные проблемы безопасности и согласованности, которые могут возникнуть во время независимого производства блоков L2. В частности, конвейер деривации обеспечивает надежную основу для генерации блоков L2. Даже если L2 не ждет подтверждения L1 в реальном времени, он может обеспечить законность и безопасность транзакций с помощью производных данных. Когда независимые верификаторы воспроизводят транзакции и обнаруживают расхождения между данными L2 и теми, что были переданы L1, конвейер деривации обеспечивает достаточную поддержку данных, позволяя получить доказательства ошибок и запустить механизм отката. Без этого процесса деривации L2 не может гарантировать верифицируемость своих данных, и доказательства ошибок станут бессмысленными. Таким образом, конвейер деривации — это не только техническая поддержка возможностей масштабирования L2, но и основной компонент, обеспечивающий безопасность

Decoupled SVM — основной исполнительный слой SOON

К этому моменту мы должны иметь относительно глубокое представление о развязке. Примером, который мы использовали выше, был оптимизм в экосистеме Ethereum. На самом деле, в Ethereum большинство решений Rollup уже достигли развязки уровня исполнения от уровня консенсуса. Однако в SVM все только начинается. SOON использует решение, схожее с Optimism, поэтому мы и использовали Optimism в качестве примера ранее. Однако SOON отделяет SVM (виртуальную машину Solana) от уровня консенсуса Solana. Здесь есть еще более сложные и глубокие вопросы, которые необходимо изучить. Хотя основная идея одна и та же, конкретная инженерная реализация и проблемы отличаются, поэтому нам нужно продолжить изучение того, как SOON отделяет основной слой выполнения SVM от Solana.

В Solana SVM тесно связана со слоем консенсуса Solana. SVM управляет выполнением смарт-контрактов и транзакций, а уровень консенсуса достигает консенсуса с помощью механизмов Tower BFT и PoH (Proof of History). Задача SOON заключается в том, чтобы отделить SVM от этой тесно интегрированной архитектуры, позволив ему работать независимо и взаимодействовать с другими механизмами консенсуса или Layer 1. Это предполагает демонтаж существующей архитектуры узла валидатора Solana, удаление компонентов, связанных с консенсусом, при сохранении основной функциональности уровня исполнения, а также перепроектирование механизма для обработки выведения блоков, предоставления данных и верификации.

Чтобы проанализировать эту проблему, мы должны сначала глубоко понять структуру валидаторов Solana.

Структура валидатора Solana
Валидаторы играют важнейшую роль в архитектуре Solana, выступая в качестве основных компонентов для достижения консенсуса, проверки транзакций и поддержания состояния сети. Валидаторы обеспечивают валидность транзакций и консенсус, запуская множество модулей. Структура валидаторов Solana довольно сложна и объединяет среду исполнения (SVM) и механизмы консенсуса (Tower BFT и PoH). Мы проанализируем ключевые модули валидатора по порядку.

• Служба Json RPC: Клиент (например, кошелек или dApp) отправляет запросы к валидатору Solana через этот сервис. Этот сервис служит внешним интерфейсом для системы Solana, обрабатывая такие запросы, как отправка транзакций, запрос состояния счета и получение информации о блокчейне.
• TPU (Transaction Processing Unit): Это основной модуль, отвечающий за прием и выполнение транзакций. Он объединяет SVM, сортирует транзакции и обрабатывает логику их выполнения. В TPU транзакции сначала сортируются и упаковываются, а затем выполняются в среде SVM. Результаты транзакций генерируют изменения состояния, которые передаются в модуль консенсуса в виде корней состояния, что в конечном итоге отражается на состоянии всей сети.
• Банковские форки: Этот модуль обрабатывает форки состояния цепочки, когда сеть испытывает расхождения в состоянии (например, когда несколько валидаторов одновременно производят блоки).
• Служба сплетен: Этот протокол управляет связью между узлами сети Solana, распространяя последнее состояние, транзакции и информацию о блоках по всей сети валидаторов. Узлы валидаторов получают блоки и транзакции от других узлов через эту службу, обеспечивая согласованность состояния сети.
• Другие процессы или модули, связанные с консенсусом: Этап воспроизведения повторно проверяет транзакции, упакованные в блоки, обеспечивая согласованность данных путем воспроизведения транзакций. Validator постоянно получает информацию о транзакциях, выполняет, проверяет и принимает информацию от других узлов, и, наконец, достигает консенсуса в рамках консенсуса Tower BFT и PoH для производства блоков.

В архитектуре Solana слой выполнения (SVM) тесно связан со слоем консенсуса. Однако для оптимистичных сворачиваний многие из этих модулей не нужны. В Optimistic Rollup после получения транзакции узел Rollup может немедленно выполнить, упаковать и выпустить блок без необходимости консенсуса. Единственное требование — периодически отправлять верифицируемые пакетные данные транзакций и информацию о корне состояния на уровень DA или L1, обеспечивая при этом доступ к транзакциям ввода и вывода средств, пакетным данным транзакций и информации о корне состояния от L1 или уровня DA. В сочетании с механизмом подтверждения ошибок этого достаточно для обеспечения безопасности.

Таким образом, чтобы отделить среду исполнения ядра Solana (SVM) от Solana, первым шагом будет удаление модулей, связанных с консенсусом, из валидатора Solana и сборка остальных. Следующий шаг — создание механизма для L2 по получению информации из L1, который представляет собой процесс деривации (подробно описанный ранее). И наконец, необходимо построить механизм доказательства ошибок. Собрав все эти элементы, SOON сможет создать чрезвычайно гибкий и безопасный оптимистический сворачиватель. Именно эту работу и проделала SOON.

Теперь стек SOON становится понятным. Если место передачи проверяемых данных заменяется выделенным слоем DA, то любой слой DA может быть использован для независимой проверки и подтверждения SOON. Если место для верификации блоков, хранения информации о корне состояния и обработки депозитов и снятия средств заменяется другим L1, любой L1 может быть использован в качестве расчетного слоя. На основе стека SOON любая организация может создать роллап, в котором будет выбран любой L1 и любой уровень DA.

Далее мы подробно расскажем о том, как реализуется Decoupled SVM с инженерной точки зрения.

Реконструкция исполнительного слоя
В архитектуре SOON модули традиционного валидатора Solana, связанные с консенсусом, были значительно упрощены или полностью удалены, а основное внимание уделяется выполнению транзакций, обновлению состояния и отправке данных. Уровень консенсуса больше не занимается непосредственно проверкой и сортировкой транзакций, что высвобождает значительное количество вычислительных ресурсов и делает систему более эффективной.

SOON сохраняет основные модули для обработки, упаковки и передачи транзакций. Ниже приведены некоторые ключевые модули, которые были реконструированы и оптимизированы:

TPU (блок обработки транзакций)

TPU — это основной компонент уровня исполнения SOON, отвечающий за прием, сортировку, выполнение транзакций и генерацию обновлений состояния. В реструктурированном валидаторе TPU продолжает служить в качестве основного механизма выполнения. В SOON TPU обрабатывает входящие транзакции, вызывая API Anza SVM для выполнения смарт-контрактов и изменения состояния. TPU выполняет следующие функции:

• Получение и сортировка транзакций: TPU получает и сортирует запросы на транзакции из сети, упаковывая их в пакеты и обеспечивая выполнение транзакций в заранее определенном порядке.
• Вызов API SVM: Каждая транзакция отправляется в SVM для выполнения.
• Генерация корней состояний: После выполнения транзакций TPU генерирует корни состояний, которые служат снимками состояния системы. Эти корни состояний передаются на уровень консенсуса или во внешнее хранилище с помощью механизма деривации.

Подробный поток обработки транзакций в TPU выглядит следующим образом:

• Этап проверки подписи (SigVerifyStage): Этот этап проверяет подпись каждой транзакции, гарантируя, что подпись транзакции действительна, прежде чем попасть в поток выполнения.
• Банковский этап: После проверки подписи транзакции переходят на этап BankingStage, который управляет обновлениями счета и состояния на основе содержимого транзакций. Хотя этот этап обрабатывает логику транзакций, он фактически не выполняет транзакции, а вычисляет соответствующие изменения состояния.
• SVM Executor: Этот этап отвечает за выполнение реальных смарт-контрактов или инструкций в транзакциях. SVM выполняет вызовы и исполнение контрактов на основе предыдущего состояния счета и содержания транзакций.
• Компоненты ввода: Этот заключительный этап обрабатывает записи транзакций. Он упаковывает выполненные транзакции, которые привели к изменению состояния, и записывает их в блокчейн, фиксируя как сами транзакции, так и изменения состояния в блокчейне.

Уровень деривации и конвейер деривации

SOON реструктурировала инженерный уровень деривации блоков и разработала полную систему интерфейсов для поддержки ключевых процессов, таких как деривация, упаковка и доказательство ошибок. В этом разделе мы подробно расскажем, как уровень деривации SOON получает и обрабатывает данные с уровня 1 (L1) и интегрирует их в процессы производства блоков на уровне 2 (L2), обеспечивая согласованность и безопасность системы.

Архитектура и дизайн интерфейса деривационного слоя

В процессе выведения блоков в SOON производство блоков L2 опирается на ключевую информацию, полученную из L1. Эта информация включает заголовки блоков L1, транзакции депозитов, информацию о партиях доступности данных и многое другое. Эти данные анализируются и упаковываются в блоки L2 для завершения окончательного производства блоков. Конкретный процесс выглядит следующим образом:

Деривация

Первым шагом в процессе деривации является получение последнего заголовка блока из L1 и извлечение ключевой информации, необходимой для деривации. Эта информация включает в себя:

• Заголовок блока: Метаданные блока, используемые для подтверждения временной метки блока и основной информации.
• Депозитные транзакции: Межцепочечные депозитные операции, происходящие на L1, должны быть отражены в счетах на L2.
• Пакетная информация о доступности данных: Важнейшая информация о доступности данных для обеспечения корректного доступа к данным на L2 и их проверки валидаторами.

Благодаря реализации признака PayloadAttribute эта ключевая информация разбирается и сохраняется в struct, подготавливая ее для последующей упаковки в блок.

Упаковка

После разбора и получения производной информации от L1, L2 необходимо упаковать эту информацию с обычными транзакциями, представленными клиентами L2 (т.е. транзакциями, инициированными пользователями на L2). Этот процесс упаковки реализуется с помощью трейта BlockPayload, который объединяет все транзакции и информацию заголовка блока в единую структуру данных. В процессе упаковки система обрабатывает транзакции из различных источников, включая:

• Данные, полученные из L1: Такие как заголовки блоков, транзакции депозитов и т. д.
• Локальные транзакции L2: Обычные транзакции, отправленные пользователями на L2, которые попадают в процесс упаковки через TransactionStream L2.

Наконец, эти транзакции объединяются в стандартизированную полезную нагрузку блока, которая готова к исполнению и обработке.

Транспортировка и производство

Упакованный BlockPayload отправляется в основной модуль SOON — Engine, который представляет собой модуль ядра, реализующий интерфейс EngineAPI. Модуль Engine отвечает за выполнение упакованных транзакций на виртуальной машине SVM (Solana Virtual Machine) и генерацию финального блока. В ходе этого процесса система обрабатывает выполнение транзакций, реорганизацию (Reorg) и подтверждение финального блока.

Выполнение транзакций

В движке BlockPayload передается на SVM для выполнения.

С помощью функции new_block в интерфейсе EngineAPI система может сгенерировать новый блок на основе полученной BlockPayload и добавить его в блокчейн L2. Во время этого процесса SVM обеспечивает корректность выполнения транзакций и проверяет обновления состояния.

Реорганизация блока

В некоторых случаях системе может потребоваться реорганизация блокчейна L2, что обычно происходит, когда в L1 происходит реорганизация, требующая от L2 синхронизации с состоянием L1. Функция reorg в интерфейсе EngineAPI запускает операцию реорганизации, сбрасывая цепочку L2, чтобы она соответствовала состоянию L1. Этот механизм гарантирует, что состояние цепочки L2 остается согласованным с L1, предотвращая несоответствия, вызванные реорганизацией L1.

Финализация блока

Последним шагом в производстве блоков является подтверждение и финализация блока. Используя функцию finalize в интерфейсе EngineAPI, система может пометить сгенерированный блок как завершенный и записать его в блокчейн L2. Этот процесс гарантирует, что блок не будет изменен в дальнейшем, гарантируя окончательность транзакций.

Доказательства отказов и механизм вызовов

Деривационный уровень SOON не только поддерживает производство и реорганизацию блоков, но и обеспечивает безопасность системы с помощью механизма защиты от сбоев. Независимые валидаторы могут воспроизводить транзакции L2 на основе корня состояния и партий транзакций, переданных через деривационный слой, чтобы проверить корректность данных. Если обнаруживаются расхождения между представленными L2 данными и фактическими результатами выполнения, проверяющие могут инициировать вызов, представив доказательство ошибки.

Доказательства отказов и механизм вызовов

Деривационный слой SOON не только поддерживает добычу и реорганизацию блоков, но и обеспечивает безопасность системы благодаря механизму защиты от сбоев. Независимые валидаторы могут воспроизводить транзакции L2 на основе корня состояния и партий транзакций, переданных через деривационный уровень, чтобы проверить корректность данных. Если обнаружатся расхождения между представленными L2 данными и фактическими результатами выполнения, проверяющие могут инициировать вызов, отправив доказательство неисправности.

Процесс доказательства ошибок:

1. Валидаторы воспроизводят транзакции: Используя данные транзакций, полученные из L1, проверяющие могут воспроизвести транзакции L2, вычислить корень состояния и сравнить его с представленными результатами.
2. Предоставление доказательства неисправности: Если обнаружено несоответствие, валидаторы могут отправить доказательство ошибки через L1, запросив откат системы.
3. Откат и реорганизация блока: После проверки доказательства ошибки система запускает механизм отката блока, отменяет ошибочный блок и использует механизм деривации для обеспечения согласованности данных.

SOON разработала полный интерфейс для реализации механизмов деривации блоков, упаковки транзакций, выполнения и защиты от сбоев. В сочетании с предыдущей реструктуризацией уровня исполнения, Decoupled SVM была полностью реализована, отделив основной уровень исполнения от уровня консенсуса.

Заключение и перспективы

После глубокого анализа технической архитектуры Decoupled SVM мы можем ясно видеть, что преимущества разделения значительно повышают безопасность, производительность и гибкость системы на разных уровнях. Отделив SVM от слоя консенсуса, SOON не только раскрывает исполнительную мощь SVM, достигая высокой пропускной способности (TPS), но и закладывает прочный фундамент для будущей масштабируемости и кросс-цепочечных операций.

Одним из основных преимуществ Decoupled SVM является повышенная безопасность. Благодаря разделению уровней исполнения и консенсуса валидаторы могут независимо воспроизводить транзакции L2 и проверять результаты, обеспечивая верифицируемость данных. Механизм деривации также позволяет пользователям не беспокоиться о пополнении и снятии активов, поскольку в процесс включаются транзакции по пополнению L1.

С точки зрения производительности, Decoupled SVM значительно повышает возможности параллельной обработки данных в системе. Поскольку SVM больше не зависит от подтверждения в реальном времени со стороны уровня консенсуса, она может самостоятельно обрабатывать и быстро выполнять транзакции, генерируя блоки. Такое разделение значительно снижает нагрузку на уровень консенсуса и раскрывает потенциал производительности SVM, позволяя ему сосредоточиться на параллельном выполнении транзакций и достижении сверхвысокой пропускной способности. Этот эффективный механизм обработки особенно важен для систем L2, где Decoupled SVM может значительно повысить скорость отклика системы и общую вычислительную мощность в высококонкурентных блокчейн-приложениях.

С архитектурной точки зрения Decoupled SVM демонстрирует замечательную гибкость. После развязки можно выбрать любой слой DA (Data Availability) и расчетный слой L1 или даже объединить слой DA с L1 для реализации стека SOON. Благодаря такой конструкции SVM может легко интегрироваться с различными сетями первого уровня (например, TON, BTC или другими публичными цепочками) и решениями по обеспечению доступности данных. Это не только повышает масштабируемость системы, но и обеспечивает большую гибкость для развертывания различных решений масштабирования второго уровня в будущем.

Приводя подробный анализ в этой статье, мы стремимся продемонстрировать технические преимущества Decoupled SVM, в частности его выдающиеся характеристики с точки зрения безопасности, производительности и гибкости.

В будущем стек SOON на основе Decoupled SVM будет играть важную роль в решениях для кросс-цепочек, масштабирования второго уровня и обеспечения доступности данных. Архитектура с развязкой не только применима к существующим экосистемам блокчейна, но и обеспечивает идеальную инфраструктуру для новых кросс-цепочечных протоколов и многоцепочечных приложений. SVM может служить основной виртуальной машиной для различных приложений второго уровня и кросс-цепочек, гибко адаптируясь к различным механизмам консенсуса и сетям первого уровня для удовлетворения потребностей различных отраслей. В сочетании с готовящимися продуктами для взаимодействия потенциал экосистемы SVM будет еще больше расширен.

О SOON

Стек SOON — это наиболее эффективный ролл-ап виртуальной машины Solana (SVM), обеспечивающий высокую производительность на любой экосистеме L1. На уровне исполнения используется отсоединенная виртуальная машина Solana (SVM), в отличие от форк фреймворка SVM, используемого большинством проектов SVM. Конвейер деривации и игра в споры реализованы в соответствии со спецификациями OP Stack. Миссия SOON — создать самый высокопроизводительный стек с использованием SVM, ускорить внедрение SVM, снизить стоимость в 10 раз и раскрыть возможности использования в различных экосистемах.

SOON также запустит SOON Mainnet на базе Ethereum. В майнете SOON, благодаря стеку SOON, используется Decoupled SVM, что отличает его от всех других проектов SVM, использующих форкированные SVM. Развязанные SVM позволяют доказать мошенничество, что повышает безопасность и снижает потери DA blobspace. Как стимулирующий и исполнительный уровень, майнет SOON будет играть ключевую роль в привлечении и удержании разработчиков в экосистеме SVM.

SOON сотрудничает с Anza, студией разработчиков из Solana Labs. Спецификации SVM в репозитории Agave от Anza служат эталоном реализации для SOON. Команда имеет большой опыт работы с криптовалютами и способна выполнять поставленные задачи. Сооснователь и генеральный директор Джоанна Зенг работает в криптовалюте с 2017 года и возглавляла BD и партнерство в Coinbase, Optimism и Aleo. Технический сооснователь Эндрю Чжоу (Andrew Zhou) известен как разработчик смарт-контрактов и L1s с 5-летним опытом работы с Rust и 6-летним опытом работы с Golang.

SOON поддерживают самые уважаемые инвесторы-ангелы в этой сфере, включая Толи, Анатолия «Toly» Яковенко, сооснователя Solana Labs; Лили Лю, президента Solana Foundation и основателя Anagram Ventures; Джонатан Кинг, директор Coinbase Ventures; Мустафа Аль-Бассам, соучредитель Celestia Labs; Амрит Кумар, соучредитель AltLayer; Прабал Банерджи, соучредитель Avail, и другие известные строители.