Тремя основными атрибутами блокчейна являются децентрализация, безопасность и масштабируемость. Согласно теории трилеммы блокчейна, архитектура блокчейна может реализовать только две из них. Ethereum был разработан с учетом децентрализации и безопасности и поэтому плохо работает с точки зрения масштабируемости. В настоящее время Ethereum обрабатывает более 1 миллиона транзакций в день, что может привести к высоким комиссиям за транзакции и увеличить потребность в решениях для масштабирования Ethereum.

Существует несколько различных типов решений масштабирования Ethereum, каждое со своими компромиссами и моделями безопасности, включая шардинг уровня 1, каналы состояния уровня 2, Plasma, боковые цепи, Rollups и Validium. Поскольку технология шардинга медленно развивается и сложна в реализации, а боковые цепи и Validium не могут унаследовать безопасность и доступность данных от Ethereum. В итоге в экосистеме Ethereum в настоящее время в основном используется решение масштабирования Rollups.

На данный момент Beosin стал партнером по безопасности ETH Layer2, таких как Manta Network и StarkNet. В прошлом аудите ряда известных блокчейнов прошли аудит безопасности цепи Beosin, включая Ronin Network, Manta Network, Merlin Chain, Clover, Self Chain, Crust Network и т. д. Beosin теперь выпускает решение аудита для ETH Layer2, чтобы предоставить комплексные услуги аудита безопасности для экосистемы ETH Layer2.

ETH Layer2 использует Rollups для упаковки сотен транзакций в одно подтверждение на главной сети Ethereum, что позволяет разделить комиссии на всех пользователей Rollup, снижая комиссию для каждого пользователя. Данные транзакций в Rollups отправляются в Layer1, но выполнение происходит независимо Rollups. Отправляя данные транзакций в Layer1, Rollups могут наследовать безопасность Ethereum, поскольку откат транзакций Rollups требует отката данных на Layer1.

В настоящее время роллапы можно реализовать двумя основными способами:

Оптимистические роллапы: Используйте экономические стимулы и игровую теорию для подтверждения транзакций, таких как Arbitrum, Base, OP, Blast и т. д.

Zero-Knowledge Rollups: Используйте доказательства нулевого разглашения для обеспечения безопасности и конфиденциальности, такие как Scroll, Linea, zkSync, StarkNet и т.д.

Oптимистичные Роллапы

Вступление

Оптимистичные роллапы - это способ масштабирования Ethereum путем перемещения вычислений и хранения состояния вне цепи. Он выполняет транзакции вне цепи, но публикует данные транзакции на основной сети в виде calldata или blob.

Optimistic Rollups развертывает смарт-контракт на Ethereum, называемый контрактом Rollup, который управляет статусом роллапа, отслеживает балансы пользователей, а также обрабатывает депозиты, снятие средств и разрешение споров. Транзакции собираются и суммируются вне цепочки секвенсором, а несколько транзакций объединяются в блок Rollup, который содержит сводку и криптографическое доказательство нового состояния учетной записи (корень Меркла). Затем секвенсор фиксирует блок Rollup в основную цепочку, предоставляя корни Меркла и данные вызова.

Оптимистичные Rollups считаются "оптимистичными", потому что они предполагают, что офчейн-транзакции являются действительными и не публикуют доказательства действительности пакетов транзакций, передаваемых ончейн. В отличие от этого, оптимистичные Rollups полагаются на схемы доказательств мошенничества для обнаружения случаев, когда транзакции неправильно рассчитаны. После того как пакет Rollup отправлен на Ethereum, существует определенный период времени (называемый периодом оспаривания), в течение которого кто угодно может оспорить результаты транзакции Rollup, вычислив доказательство мошенничества. Доказательство мошенничества содержит детали конкретной транзакции, которую проверяющий считает мошеннической.

Как показано на рисунке ниже, период вызова большинства Оптимистичных Rollups в настоящее время составляет 7 дней, а самый короткий - 1 день.

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

Если пакет Rollup остается непринят после периода оспаривания (т.е. все транзакции были выполнены правильно), он считается действительным и принятым на Ethereum. Другие могут продолжать расширять неподтвержденные блоки Rollup, но обратите внимание, что результаты транзакций будут отменены, если транзакция будет выполнена на основе ранее опубликованной ошибки.

Наконец, пользователь должен отправить запрос на вывод средств в контракт Rollup, чтобы вывести средства с уровня 2 на уровень 1. Контракт проверит, что у пользователя достаточно средств на Rollup, и обновит их баланс на основной цепи соответственно.

Ведущие сети Layer2

1. Arbitrum

С экологическим строительством и раздачами, Arbitrum быстро стал наиболее активной сетью в ETH Layer2 с TVL превышающим 2,7 миллиарда долларов. После грандиозной раздачи, команда Arbitrum запустила программу Arbitrum Orbit: поощрение разработчиков строить Layer3, используя связанные с Arbitrum технологии. Beosin завершил аудит безопасности ArbSwap, Arbipad, чтобы помочь в развитии безопасности экосистемы Arbitrum.

1. Оптимизм

Хотя оптимизм менее экологически активен, чем арбитраж, OP Stack, запущенный Optimism в 2023 году, получил широкое признание в индустрии как полное и жизнеспособное решение для создания модульных слоев 2. Более 25 сетей Layer2 были созданы с использованием OP Stack, включая такие звездные проекты, как Base, Mantle, Manta, OP BNB и Celo. DIPX Finance и Starnet, созданные на Optimism, прошли аудит безопасности Beosin.

1. Базовый

Base - это сеть Layer2 на основе OP Stack, которая занимает второе место после Arbitrum по экологической активности и TVL. Ранее Beosin подробно проанализировал архитектуру Base и риски безопасности, а также провел аудит Surf Protocol и EDA, чтобы помочь владельцам проектов и пользователям избежать рисков безопасности.

1. Взрыв

Blast, в конце своего конкурса разработчиков «Big Bang», увидел, что его TVL взлетел до более чем 2 миллиардов долларов, заняв свое место в цепи Layer2. Beosin проанализировал сетевую безопасность Blast перед запуском основной сети. Поскольку Blast не реализует защиту от мошенничества, активы хранятся в кошельке с несколькими подписями, а не в мосте Rollup, который имеет высокую степень риска централизации. Beosin провела аудит нескольких экологических проектов Blast, таких как Wand Protocol, Zest, Kalax.

Анализ архитектуры

OP Stack, зрелая платформа для Оптимистичных Роллапов, в основном разбивает сложный процесс построения цепей оптимистичных Роллапов на упрощенный процесс путем предоставления полного набора программных компонентов, инструментов и фреймворков. Здесь мы берем фреймворк Op stack в качестве примера для анализа типичной архитектуры Оптимистичной Роллапы.

● Узел исполнения: Op-geth - это расширенный клиент исполнения для Ethereum, который обрабатывает специфические для Layer2 функции, такие как прием токенов из Layer1. В этом слое определяются все функции, ответственные за выполнение изменений состояния. Здесь переходы состояния вызываются на основе полученного входного сигнала от узлов сводки (последовательности и проверяющих) через движок API.

● Узел Rollup: включает в себя секвенсор и валидатор. Коллектор отвечает за упаковку обработанных транзакций с уровня 2 и их публикацию на уровне 1. Секвенсор определяет, как транзакции на цепочке Layer2 собираются и публикуются. Валидатор/валидатор проверяет правильность пакетной транзакции и представляет доказательства, если обнаружится мошенничество.

● Защита от мошенничества: Cannon — это обновленная версия Geth, которая отвечает за запуск EVM на этапе обнаружения и доказательства мошенничества. По сути, это ончейн-механизм разрешения споров, который координирует свои действия с секвенторами и валидаторами через API, чтобы доказать ложные транзакции.

● Пакетный коммит: Секвенсоры пакетно обрабатывают все обработанные транзакции сразу, проверяемые верификаторами, и Секвенсоры отправляют пакет обработанных транзакций на Layer1.

● Контракты моста: Развернутые на Ethereum и Layer2, позволяющие пользователям передавать сообщения и передавать активы между Layer1 и Layer2.

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

● Перевод активов в Rollup: Пользователи вносят средства на контракт моста цепи Rollup на уровне 1. Контракт моста цепи передает транзакцию на уровень 2, где создается равное количество активов и отправляется на адрес, выбранный пользователем в Optimistic Rollup.

Транзакции, создаваемые пользователями, такие как депозиты с Layer1 на Layer2, обычно ставятся в очередь до тех пор, пока секвестр не отправит их обратно в контракт Rollup. Однако, чтобы обеспечить устойчивость к цензуре, оптимистический Rollup позволяет пользователям отправлять транзакции напрямую в контракты Rollup на цепочке, если задержки транзакций превышают максимально допустимое время.

● Вывод активов из Rollup: Из-за механизма доказательства мошенничества вывод денег из Optimistic Rollup в Ethereum более сложный. Если пользователь инициирует транзакцию с уровня Layer2 на уровень Layer1 для вывода средств, управляемых на уровне Layer1, ему необходимо ждать окончания периода оспаривания, который обычно длится около 7 дней.

Когда пользователь инициирует запрос на вывод средств на Rollup, транзакция включается в следующий пакет, а активы пользователя на Rollup уничтожаются. После того, как пакет будет опубликован в Ethereum, пользователи могут рассчитать доказательство Меркла, чтобы убедиться, что их транзакция выхода включена в блок. Следующий шаг — дождаться окончания периода задержки, чтобы завершить транзакцию на Layer1 и вывести средства в основную сеть.

Чтобы избежать ожидания недели перед выводом денег из Ethereum, пользователи Optimistic Rollup могут запросить аванс от поставщика ликвидности (LP), который принимает на себя владение ожидающим выводом и выплачивает пользовательские средства на Layer1 в обмен на комиссию. Поставщики ликвидности могут проверить правильность запросов на вывод пользователей, проверив данные on-chain самостоятельно до выплаты средств. Таким образом, они могут гарантировать, что транзакция в конечном итоге будет подтверждена, обеспечивая уверенность в доверии.

Элементы аудита

Layer2 - это полная блокчейн-система, поэтому общая проверка публичных цепочек также применима к Оптимистическому Rollup, как подробно описано в приложении в конце этой статьи.

Кроме того, из-за своей специальной природы, Optimistic Rollup требует проведения ряда дополнительных проверок:

● Доказательство доступности данных: Обеспечьте наличие данных о транзакциях Layer2 на Layer1, чтобы предотвратить потерю данных.

● Механизм синхронизации данных: Проверьте, насколько надежен механизм синхронизации данных между уровнем 1 и уровнем 2 и способен ли он обрабатывать аномальные ситуации, такие как разделение сети.

● Контракт доказательства мошенничества: Проверьте, что контракт доказательства мошенничества реализован правильно.

● Механизм периода вызова: Проверьте, разумна ли длительность периода вызова и может ли быть завершено доказательство мошенничества в указанное время.

● Процесс подачи доказательств мошенничества: проверьте, что процесс подачи доказательств мошенничества защищен.

● Процесс депозита и вывода: Проверьте процесс депозита и вывода с уровня 1 на уровень 2 и с уровня 2 на уровень 1, чтобы убедиться, что процесс безопасен.

● Чек логики создания и уничтожения активов: Проверьте логику создания и уничтожения активов на Layer2, чтобы гарантировать правильное соответствие активов на Layer1.

● Механизм обеспечения ликвидности: Если существует механизм обеспечения ликвидности (LP), необходимо изучить процесс его работы и его безопасность.

Zero-Knowledge Rollups

Введение

Zero-Knowledge (ZK) Rollup - это Layer2 на основе доказательства с нулевым разглашением. Главным образом выполняется сложный расчет и генерация доказательства вне цепочки, проверка доказательства в цепочке и хранение части данных для обеспечения доступности данных.

ZK Rollup — это «гибридное решение для масштабирования», которое представляет собой протокол вне сети, который работает независимо, но получает безопасность от Ethereum. В частности, сеть Ethereum обеспечивает действительность обновлений статуса на ZK Rollups и гарантирует доступность фоновых данных каждый раз, когда статус Rollup обновляется. Состояние Rollup поддерживается смарт-контрактами, развернутыми в сети Ethereum. Чтобы обновить этот статус, узел ZK Rollups должен отправить подтверждение действительности для проверки. Доказательство действительности — это криптографическая гарантия того, что предлагаемое изменение состояния действительно является результатом выполнения данного пакета транзакций. Это означает, что ZK Rollups нужно только предоставить доказательство действительности для завершения транзакций в Ethereum, без необходимости публиковать все данные о транзакциях.

Перевод средств с ZK Rollups на Ethereum не вызывает задержек, поскольку транзакция выхода выполняется после проверки доказательства действительности контракта ZK Rollups. В отличие от этого, вывод средств из Optimistic Rollups вызывает задержки, поскольку любой может использовать доказательство мошенничества для оспаривания транзакции вывода.

Ведущие сети второго уровня

1. zkSync

zkSync, решение второго уровня, запущенное пять лет назад командой Matter Labs, использует технологию доказательства нулевого разглашения для обеспечения эффективной проверки транзакций и собрало более $200 миллионов. zkSync является одной из наиболее активных экологически Layer2 сетей, использующих ZK Rollups, и также вызывает споры. Beosin ранее проводил аудит его ведущего DeFi-проекта SyncSwap, охватывающий качество кода, логику и безопасность контракта, операционную модель и многое другое.

1. StarkNet

StarkNet использует ZK-STARK для создания Layer2 с целью увеличения скорости транзакций и снижения комиссий за транзакции. У StarkNet есть собственная виртуальная машина (Cairo VM) и язык разработки Cairo, чтобы помочь разработчикам писать умные контракты более безопасно и легко. Beosin стал официальным партнером по безопасности StarkNet, завершив аудиты безопасности для Option Dance и Reddio. 13 августа 2024 года Reddio завершил раунд затравочного финансирования под руководством Paradigm для создания высокопроизводительной параллельной сети EVM Layer2.

1. Прокрутка

Scroll масштабируется с помощью технологии нулевых доказательств, и аппаратное обеспечение ускоряет генерацию и проверку нулевых доказательств, с целью достижения совместимости EVM на уровне байт-кода. Это означает, что разработчики могут непосредственно использовать инструменты разработки Solidity и Ethereum для создания смарт-контрактов.

Анализ архитектуры

Общие фреймворки для ZK Rollups включают контракты Rollup и Bridge, коллекторы, агрегаторы, Repeaters и Roller-сети, которые генерируют нулевые доказательства. Конкретная архитектура показана на следующей фигуре:

● Контракт Rollup и контракт моста:

Контракт Rollup отвечает за обеспечение доступности данных для транзакций Rollup, проверку доказательства допустимости zkEVM и позволяет пользователям передавать активы между Ethereum и Rollup. Он получает корень состояния Уровня 2 и блок от коллатора, корень состояния хранится в состоянии Ethereum, а данные блока Уровня 2 сохраняются как calldata Ethereum.

Мостовые контракты развертываются на Ethereum и Layer2, что позволяет пользователям передавать сообщения и передавать активы между Layer1 и Layer2.

● Секвенсор: Секвенсор предоставляет интерфейс JSON-RPC и принимает транзакции Layer2, периодически извлекает пакет транзакций из пула памяти для выполнения, генерирует новые блоки Layer2 и корни состояний. Его реализация обычно основана на Go-Ethereum (Geth), что обеспечивает лучшую совместимость и высокую безопасность.

● Координатор: Координатор уведомляется, когда коллектор генерирует новый блок и получает исполнительную трассу этого блока от коллектора. Затем исполнительная трасса отправляется на случайно выбранный роллер в сети Roller, который генерирует доказательство правильности.

● Релейер: Повторитель отслеживает контракты Rollup и мостовые контракты, развернутые на Ethereum и Layer2. Основные обязанности: 1) Отслеживание доступности данных и проверка блоков Layer2 путем мониторинга контрактов Rollup; 2) Мониторинг событий депозита и вывода Ethereum и участия моста Layer2 и ретрансляция сообщений на другой конец.

● Сеть Roller: Roller в сети Roller действует в качестве подтверждающего и отвечает за генерацию доказательства достоверности для ZK Rollup. След выполнения блока сначала получается от координатора, преобразуется в свидетеля цепи, затем для каждого zkevm с использованием аппаратного ускорения генерируется доказательство, и, наконец, используется агрегация доказательств для объединения нескольких доказательств в одно общее доказательство.

При технической архитектуре ZK Rollups важно обеспечить безопасность активов пользователя во время передачи между L1 и L2. В следующем разъясняется, как пользователи могут получить доступ к активам между этими двумя слоями, а также как система поддерживает целостность и безопасность этих транзакций.

● Перенос активов на Rollup: Пользователи входят в Rollup, внося токены на контракт ZK Rollups, развернутый на слое сетевой цепи. Эта транзакция должна быть отправлена на контракт Rollup со стороны проекта.

Если очередь ожидания депозита начинает заполняться, операторы ZK Rollups принимают эти транзакции депозита и отправляют их в контракт Rollup. После того, как средства будут зачислены на Rollup, пользователь может начать обработку транзакций.

Пользователи могут проверить баланс на Rollup, захешировав свою учетную запись, отправив хеш-значение в контракт Rollup и предоставив доказательство Меркла, которое подтверждает текущее состояние корня.

● Вывод активов из Rollup: Пользователь инициирует транзакцию вывода, отправляя активы на своем Rollup на указанный счет для уничтожения. Если оператор добавляет транзакцию в следующую пакет, пользователь может подать запрос на вывод на цепной контракт. Запросы на вывод включают:

1. Доказательство Меркла, которое доказывает, что транзакция пользователя добавлена к уничтоженному счету в пакете транзакций

2. Данные транзакции

3. Пакетная обработка корня

4. Адрес сети Layer1 для получения депозитных средств

Контракт Rollup хэширует данные транзакции, проверяет наличие корневого хэша пакета и с использованием доказательства Меркла проверяет, является ли хэш транзакции частью корневого хэша пакета. Контракт выполняет выходную транзакцию и отправляет средства на адрес в сети Layer1, выбранный пользователем.

Элементы аудита

Layer 2 - это полная система блокчейна, поэтому общие проверочные элементы для блокчейнов также применяются к ZK Rollup, как подробно описано в приложении в конце этой статьи.

Кроме того, из-за своей особенной природы ZK Rollup требуется провести дополнительные проверки:

● Доказательство безопасности системы: Проверьте безопасность и правильность используемых схем доказательства с нулевым разглашением (например, Groth16, Plonk, Halo2, zk-STARK и т. д.).

● Безопасность цепей: Проверьте возможные уязвимости при проектировании и реализации схем, в основном включая следующие:

1. Подзадачи недостаточно определены

2. Перегруженные схемы

3. Недетерминированные цепи

4. Арифметические переполнения / недостатки арифметики переполнения / недостатки

5. Несовпадение длин битов

6. Неиспользуемые общедоступные входы оптимизированы

7. Frozen Heart: Создание доказательств нулевого знания

8. Утечка доверенной настройки

9. Назначено, но не ограничено

10. Использование небезопасных компонентов

11. Variable Precision

● Создание и проверка доказательств: Проанализируйте процесс создания и проверки доказательств, чтобы убедиться, что он эффективен и безопасен.

● Доказательство доступности данных: Гарантирует, что данные транзакций уровня 2 доступны на уровне 1, чтобы предотвратить потерю данных.

● Механизм синхронизации данных: Проверьте, является ли механизм синхронизации данных между Layer1 и Layer2 надежным и способным справиться с нештатными ситуациями, такими как разделение сети.

● Процесс депозита и вывода: Проверьте процесс депозита и вывода с уровня 1 на уровень 2 и с уровня 2 на уровень 1, чтобы убедиться, что процесс безопасен.

● Чеканка и сжигание ассета: проверьте логику приведения и уничтожения ассета на уровне 2, чтобы убедиться в правильном соответствии с ассетом уровня 1.

● Сканирование внешних зависимостей и известных уязвимостей: ZK Rollup часто полагается на криптографические и математические репозитории или инструменты третьих сторон и должен тщательно проверять их безопасность зависимостей для сканирования и проверки известных уязвимостей.

Приложение

Пункты общей проверки блокчейна и Layer2:

● Переполнение целого числа: Проверьте переполнение целых чисел и недостаток целых чисел

● Петля: Проверьте петлю программы, чтобы увидеть, является ли условие разумным

● Бесконечный рекурсивный вызов: Проверьте, является ли условие выхода из рекурсивного вызова программы разумным

● Race condition: Проверяет доступ к общим ресурсам в состоянии конкурентности

● Исключительный сбой: Проверьте код, вызывающий исключения, который заставляет программу активно завершаться

● Уязвимость при делении на 0: Проверьте, есть ли случай деления на 0

● Преобразование типов: Проверьте, является ли преобразование типов правильным и не теряется ли важная информация во время преобразования

● Выход за границы массива: проверяет доступ к элементам за пределами границ массива

● Уязвимость десериализации: Проверьте наличие проблем во время десериализации

● Безопасность реализации функций: Проверьте, имеются ли у реализации интерфейсов RPC безопасные риски и соответствуют ли они функциональному дизайну интерфейсов RPC

● Насколько разумные настройки разрешений чувствительного интерфейса RPC: Проверьте настройки доступа к чувствительному интерфейсу RPC

● Механизм шифрованной передачи: Проверьте, используется ли шифрованный протокол передачи, такой как TLS

● Разбор формата данных запроса: Проверяет процесс разбора формата для данных запроса

● Атака на разблокировку кошелька: когда узел разблокирует свой кошелек, RPC просит его украсть средства

● Традиционная безопасность веб-приложений: Проверьте наличие следующих уязвимостей: Межсайтовый скриптинг (XSS)/инъекция шаблонов/уязвимость сторонних компонентов/загрязнение параметров HTTP/SQL-инъекция/внедрение сущностей XXE/уязвимость десериализации/уязвимость SSRF/инъекция кода/включение локальных файлов/включение удаленных файлов/инъекция выполнения команд и другие традиционные уязвимости

● Механизм аутентификации и идентификации узла сети: проверка наличия механизма идентификации узла, механизм идентификации узла может быть обойден.

● Загрязнение таблицы маршрутизации: проверьте, может ли таблица маршрутизации быть вставлена или перезаписана произвольно

● Алгоритм обнаружения узла: Проверьте, является ли алгоритм обнаружения узла сбалансированным и непредсказуемым, например, алгоритм расстояния несбалансирован

● Аудит использования подключений: проверьте, разумно ли ограничивать и управлять количеством узлов, подключенных к сети p2p.

● Атаки на солнечные затмения: Оценка затрат и опасностей атак на солнечные затмения, при необходимости проведение количественного анализа

● Атака Сибиля: Оценка механизмов консенсуса при голосовании и анализ стратегий проверки права на голосование

● Атака прослушивания: Проверьте, разглашает ли коммуникационный протокол конфиденциальность

● Атака пришельцев: Оценивает, может ли узел распознать узел того же типа цепи

● Время перехвата: Проверьте механизм расчета сетевого времени узла

● Атака на истощение памяти: Проверьте большое потребление памяти

● Атака исчерпания жесткого диска: Проверьте, где хранятся большие файлы

● атака давлением сокета: проверьте политику ограничения на количество соединений

● Атака исчерпания обработчика ядра: Проверьте ограничения на создание обработчика ядра, такие как обработчики файлов

● Постоянные утечки памяти: Проверьте на утечки памяти

● Безопасность алгоритма хеширования: проверка устойчивости алгоритма хеширования к коллизиям

● Безопасность алгоритма цифровой подписи: проверка безопасности алгоритма подписи и реализации алгоритма

● Безопасность алгоритма шифрования: Проверьте безопасность алгоритма шифрования и реализацию алгоритма

● Безопасность генератора случайных чисел: Проверьте, является ли алгоритм генерации случайных чисел ключа разумным

● Безопасность реализации BFT: Оценка безопасности реализации алгоритмов BFT

● Правила выбора вилки: проверьте правила выбора вилки для обеспечения безопасности

● Тест на степень централизации: определите, есть ли чрезмерно централизованный дизайн в дизайне системы.

● Проверка поощрений: Оценка влияния поощрений на безопасность

● Атаки двойного расходования: проверьте, может ли консенсус защитить от атак двойного расходования

● Аудит MEV-атак: изучение влияния MEV узла блок-пакета на справедливость цепочки.

● Проверка процесса синхронизации блока: Проверка на наличие проблем безопасности во время синхронизации

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

● Проверка процесса генерации блоков: Проверка проблем безопасности в процессе генерации блоков, включая то, построен ли корень дерева Меркла в разумном формате

● Проверка процесса аудита блока: Проверьте, достаточны ли элементы подписи блока и логика проверки

● Аудит логики проверки блоков: проверьте, является ли алгоритм и реализация проверки блоков разумными.

● Столкновение хэша блока: Проверьте, как сконструировано столкновение хэша блока и обрабатывается ли столкновение разумно

● Лимиты ресурсов обработки блоков: Проверьте, разумно ли установлены лимиты ресурсов для пулов сиротских блоков, вычислений верификации, адресации жесткого диска и других ресурсов

● Аудит процесса синхронизации транзакций: проверяет наличие проблем безопасности в процессе синхронизации

● Столкновение хешей транзакций: Изучите, как конструируются столкновения хешей транзакций и как они обрабатываются

● Синтаксический анализ формата транзакции: проверка на наличие проблем безопасности во время синтаксического анализа формата, таких как ошибки синтаксического анализа, вызывающие сбои.

● Проверка допустимости транзакции: Проверьте, достаточны ли элементы подписи каждого типа транзакции и логика проверки

● Ограничения ресурсов обработки транзакций: Проверьте, что ограничения ресурсов, такие как пулы транзакций, вычисления проверки и адресация жесткого диска, являются разумными

● Атака на пластичность транзакций: может ли транзакция изменять внутренние поля (например, ScriptSig), чтобы изменить хэш транзакции, не влияя на действительность транзакции.

● Аудит атаки повторного воспроизведения транзакции: Проверяет систему обнаружения повторного воспроизведения транзакции

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

● Выполнение байт-кода контракта: проверка безопасности процесса выполнения байт-кода виртуальной машины, например целочисленного переполнения, мертвых циклов и т. д.

● Модель газа: Убедитесь, что платы за каждую атомную операцию обработки транзакции/выполнения контракта пропорциональны потреблению ресурсов.

● Целостность журнала: Проверьте, зарегистрирована ли ключевая информация

● Безопасность журналов: Проверьте, вызывает ли неправильная обработка журналов проблемы безопасности, такие как переполнение целого числа

● Журналы содержат информацию о конфиденциальности: проверьте, содержат ли журналы информацию о конфиденциальности, такую как ключи

● Хранение журналов: Проверьте, записывается ли в журналы избыточное количество информации, что приводит к израсходованию ресурсов узла

● Безопасность цепочки поставок узла: Проверьте все сторонние библиотеки, компоненты и версии фреймворков общедоступных цепочек на наличие известных проблем

Отказ от ответственности:

1. Эта статья взята из [ beosin]. Все авторские права принадлежат оригинальному автору [beosin]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они обработают это незамедлительно.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными рекомендациями.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.