Биткойн (BTC), как первая криптовалюта в мире, постепенно стала угловым камнем цифровых активов и децентрализованной финансовой системы с момента ее создания в 2009 году. Однако, по мере увеличения числа пользователей и объема транзакций, проблемы сети BTC становятся все более очевидными и заключаются, главным образом, в следующем:：

• Высокие комиссии за транзакции: Когда сеть Bitcoin перегружена, пользователям приходится платить более высокие комиссии, чтобы обеспечить максимально быстрое подтверждение транзакций.
• Время подтверждения транзакции: Блокчейн Bitcoin генерирует новый блок в среднем каждые 10 минут, что означает, что ончейн-транзакции часто должны ждать нескольких подтверждений блоков, прежде чем они считаются окончательными.
• Ограничения смарт-контрактов: скриптовый язык Bitcoin имеет ограниченные функции и сложно реализовать сложные смарт-контракты.

В этой статье мы будемСеть Lightning(Сеть Lightning), Sidechains, Rollup и другие технологии вместе называются решениями для расширения BTC Layer2. Они поддерживают децентрализацию и безопасность сети BTC, обеспечивая быстрые и недорогие транзакции. Внедрение технологии Layer2 может улучшить скорость транзакций и снизить их стоимость, оптимизировать опыт пользователей и расширить сетевые возможности, предоставив важную техническую поддержку и направление инноваций для будущего развития BTC.

На данный момент Beosin стал официальным партнером по безопасности для BTC Layer2, таких как Merlin Chain., прошел аудит нескольких BTC экологических протоколов, таких как Bitmap.Games、Surf Protocol、Savmswap、Mineral. В прошлых аудитах многие известные общедоступные цепочки успешно прошли аудиты безопасности от Beosin, включая Ronin Network、Clover、Self Chain、Crust Networkwait. Beosin теперь запускает аудиторское решение для BTC Layer2, чтобы предоставить всеобъемлющие и надежные услуги аудита безопасности для всей экосистемы BTC.

Молниеносная Сеть

Самая ранняя концепция Lightning Network называется "платежный канал". Его идея заключается в непрерывном обновлении статуса неподтвержденной транзакции путем замены транзакции до тех пор, пока она наконец не будет транслирована в сеть Bitcoin. Сатоши Накамото уже предложил идею платежных каналов, когда создал Bitcoin в 2009 году, и включил черновой код для платежных каналов в Bitcoin 1.0, что позволило пользователям обновлять статус транзакции до ее подтверждения сетью. Однако только после выпуска белой книги "Bitcoin Lightning Network: масштабируемая моментальная внеланцевая оплата" Lightning Network появилась и вошла в общественное внимание.

На сегодняшний день реализация платежных каналов и Lightning Network очень зрелая. На сегодняшний день в сети Lightning насчитывается 13 325 узлов, 49 417 каналов, а общее количество заложенных BTC достигло 4 975.

https://1ml.com/

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

Пользователи обеих сторон отправляют две транзакции в основную сеть Биткойн: одну для открытия канала и одну для закрытия канала. Процесс грубо делится на следующие три шага:

1.Открытие канала:

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

2.Off-chain транзакции:

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

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

3. Закрытие канала и расчет реестра:

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

Преимущество сети Lightning заключается в том, что:

• Увеличенная скорость транзакций. Сеть Lightning позволяет пользователям проводить транзакции вне цепи, что означает, что транзакции могут быть завершены практически мгновенно без ожидания времени подтверждения блока. Это может обеспечить скорость транзакций второго уровня, значительно улучшая пользовательский опыт.
• Улучшенная конфиденциальность. Внеланцетные транзакции Lightning Network не требуют публичной записи в основной цепи Биткойна, что улучшает конфиденциальность транзакций. Только открытие и закрытие канала должны быть записаны в основной цепи, поэтому поведение пользователя при совершении транзакций не будет полностью раскрыто.
• Поддержка микроплатежей. Сеть Lightning очень подходит для обработки малых платежей (микроплатежей), таких как платежи за контент, платежи устройств интернета вещей и т. д. Традиционные транзакции Биткойна не подходят для частых малых платежей из-за высоких комиссий, в то время как сеть Lightning решает эту проблему.

Проблемы, с которыми сталкивается Lightning Network:

• проблемы с ликвидностью сети: Lightning Network полагается на то, что биткоины заранее блокируются в каналах. Это означает, что пользователи должны предварительно внести достаточное количество биткоинов на свой платежный канал, чтобы совершить транзакцию. Недостаточная ликвидность может привести к сбоям платежей, особенно при больших суммах.
• проблема маршрутизации: Найти эффективный путь от отправителя платежа к получателю может быть сложной задачей, особенно при увеличении размеров сети. С увеличением количества узлов сети и каналов возрастает сложность обеспечения плавного завершения платежей.
• Проблемы доверительного хранения фондов: узлы могут подвергаться злонамеренным атакам, и пользователям необходимо доверять тем узлам, с которыми они связаны, чтобы они не пытались украсть средства. Могут ли узлы предотвратить утечки частных ключей?
• Технические стандарты и совместимость: Для обеспечения совместимости необходимы согласованные технические стандарты и протоколы между различными реализациями молнии. В настоящее время несколько команд разработчиков работают над различными реализациями сети Lightning, что может привести к проблемам совместимости.
• Проблемы конфиденциальности: Хотя Сеть Lightning улучшает конфиденциальность транзакций Bitcoin, информацию о транзакциях все еще можно отслеживать или анализировать. Кроме того, операторы узлов сети могут видеть транзакции, проходящие через их узлы, что может раскрыть определенную личную информацию.

Безопасность молнии напрямую влияет на масштабируемость биткойна вне цепи и безопасность пользовательских средств. Поэтому помимо общих проверочных пунктов открытой цепи (см. приложение в конце этой статьи для получения подробной информации), сеть Lightning также должна обращать внимание на следующие важные риски безопасности:

• Перегрузка канала: Проверьте всесторонность проектирования системы Lightning Network и будет ли она вызывать перегрузку канала из-за атак горя.
• Вмешательство в канал: Проверьте безопасность структуры канала сети Lightning и будет ли она подвержена атакам на вмешательство в канал.
• Блокировка и разблокировка активов канала: Проанализируйте процесс блокировки и разблокировки активов в сети Lightning, чтобы обеспечить безопасность и надежность передачи средств от и на цепочку при открытии или закрытии платежного канала.
• Обновление статуса и закрытие: Оцените процесс обновления статуса и механизм принудительного закрытия канала, чтобы обеспечить правильную идентификацию и выполнение последнего статуса при возникновении аварийных ситуаций.
• Контракт с временной блокировкой и контракт с хэш-блокировкой (HTLC): Оцените реализацию HTLC, чтобы убедиться, что условия временной блокировки и хэш-блокировки могут быть выполнены правильно, чтобы предотвратить потерю средств, вызванную проблемами с временным окном.
• Зависимость метки времени блокчейна: Оцените зависимость молнии от метки времени биткойн-блокчейна, чтобы гарантировать правильную координацию времени в сети и вне ее для предотвращения атак со стороны времени.
• Безопасность алгоритма маршрутизации: Проверьте эффективность и безопасность алгоритма маршрутизации, чтобы предотвратить риск разглашения конфиденциальной информации пользователей и злонамеренного вмешательства в маршрутизацию.
• Хранение канала и восстановление данных: Проверьте механизм хранения канала и стратегию восстановления данных, чтобы обеспечить возможность восстановления состояния канала в случае сбоя узла или неожиданного разрыва, чтобы избежать потери средств.

боковая цепь

В отличие от Lightning Network, боковая цепь - это независимая блокчейн, которая работает параллельно с основной цепью (например, цепью BTC) и взаимодействует с основной цепью через двусторонние якорные (Two-Way Peg). Цель боковой цепи - достичь большего количества функций и улучшить масштабируемость без изменения протокола основной цепи.

Как независимая блокчейн, побочная цепочка имеет собственный механизм консенсуса, узлы и правила обработки транзакций. Она может использовать технологии и протоколы, отличные от основной цепочки, в зависимости от потребностей конкретных сценариев применения. Через двусторонний механизм якорения (2WP) побочная цепочка обменивается информацией с основной цепочкой, чтобы обеспечить свободный и безопасный перевод активов между ними. Рабочий механизм двустороннего механизма якорения (2WP) примерно следующий:

1. Пользователь блокирует BTC на главной цепи, и доверенное учреждение 1 получает и использует верификацию SPV 2, чтобы убедиться, подтверждена ли заблокированная транзакция пользователя.

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

3. После бесплатных транзакций пользователи блокируют оставшиеся токены на боковой цепи.

4. После проверки законности транзакции доверенное учреждение разблокирует BTC в основной цепочке и выдает пользователю соответствующее значение BTC.

Примечание 1: Доверенный орган играет важную роль в двустороннем механизме якорения и отвечает за управление блокировкой и освобождением активов. Этим учреждениям необходимо иметь высокую степень доверия и технические возможности для обеспечения безопасности активов пользователей.

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

Представительные проекты боковых цепей:

CKB (Сеть Nervos)

Nervos Network - это экосистема открытого исходного кода общедоступного блокчейна, которая стремится использовать преимущества безопасности и децентрализации механизма консенсуса POW BTC, в то время как вводит более масштабируемую и гибкую модель UTXO для обработки транзакций. Его ядро - это Common Knowledge Base (CKB), которая является блокчейном уровня 1, построенным на RISC-V и использующим PoW (Proof of Work) в качестве механизма консенсуса. Она расширяет модель UTXO до модели Cell, позволяя хранить любые данные и поддерживать написание скриптов на любом языке для выполнения на цепи в качестве смарт-контракта.

Стэкс

Stacks соединяет каждый блок Stacks с блоком Bitcoin через свой механизм PoX (Proof of Transfer). Для разработки смарт-контрактов Stacks разработали специализированный язык программирования Clarity. В Clarity функция get-burn-block-info? позволяет передавать высоту блока Bitcoin и получать хэш заголовка блока. В то же время ключевое слово burn-block-height может получить текущую высоту блока цепочки Bitcoin. Эти две функции позволяют смарт-контрактам Clarity читать состояние базовой цепочки Bitcoin, позволяя транзакциям Bitcoin служить триггерами контракта. Автоматизируя выполнение этих смарт-контрактов, Stacks расширяет возможности Bitcoin.

Для подробного анализа Stacks вы можете прочитать предыдущую исследовательскую статью Beosin: «Что такое стеки? С какими проблемами может столкнуться стеки сети BTC уровня 2?》

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

• Боковые цепи могут использовать разные технологии и протоколы для проведения различных экспериментов и инноваций, не влияя на стабильность и безопасность основной цепи.
• Сайдчейны могут вводить функции, которых нет у основной цепи, такие как смарт-контракты, защита конфиденциальности, выпуск токенов и т. д., чтобы обогатить сценарии применения экосистемы блокчейна.

Проблемы, стоящие перед боковыми цепочками:

• Сторонняя цепь имеет независимый механизм консенсуса, который может быть не таким надежным, как основная цепь BTC. Если механизм консенсуса боковой цепи слаб или имеет уязвимости, это может привести к атакам на 51% или другим формам атак, влияющим на безопасность пользовательских активов. Безопасность основной цепи BTC зависит от ее огромной вычислительной мощности и широкого распространения узлов, в то время как боковые цепи могут не соответствовать тем же стандартам безопасности.
• Реализация двустороннего механизма якорения требует сложных алгоритмов шифрования и протоколов. Если в них есть уязвимые места, это может вызвать проблемы с передачей активов между основной цепью и боковой цепью, а также привести к потере или краже активов.
• Чтобы найти баланс между скоростью и безопасностью, большинство боковых цепей. Степень централизации выше, чем в основной цепи.

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

Также, из-за своей особой природы, побочные цепочки также требуют дополнительной проверки:

• Безопасность протокола консенсуса: Проверьте, полностью ли проверен и протестирован протокол консенсуса побочной цепочки (например, PoW, PoS, DPoS) и есть ли потенциальные уязвимости или векторы атаки, такие как атаки на 51%, атаки на дальний диапазон и т. д.
• Безопасность узлов консенсуса: Оценить безопасность узлов консенсуса, включая управление ключами, защиту узлов и резервное копирование, чтобы предотвратить взлом или злоупотребление узлами.
• Блокировка и освобождение активов: Просмотрите двусторонний механизм привязки активов между боковой цепью и основной цепью, чтобы обеспечить безопасность и надежность умных контрактов для блокировки и освобождения активов, предотвращая двойные траты, потерю активов или сбои блокировки.
• Проверка межцепочечной верификации: Проверьте точность и безопасность межцепочечной верификации, обеспечьте децентрализованный и защищенный процесс верификации, предотвратите сбои верификации или злонамеренную верификацию.
• Проверка кода контракта: Глубокая проверка всех смарт-контрактов, работающих на боковой цепи, для выявления возможных лазеек или задней двери, особенно логики контракта при обработке операций межцепочных.
• Механизм обновления: Проверьте, безопасен ли механизм обновления смарт-контрактов, есть ли соответствующие процессы аудита и консенсуса сообщества, чтобы предотвратить злонамеренные обновления или вмешательство в контракты.
• Межузловая коммуникация: Проверьте, является ли коммуникационный протокол между узлами боковой цепи безопасным и используются ли зашифрованные каналы для предотвращения атак типа man-in-the-middle или утечек данных.
• Кросс-цепное взаимодействие: Проверьте коммуникационный канал между боковой цепью и основной цепью, чтобы гарантировать целостность и подлинность данных, и предотвратить возможность их перехвата или подмены.
• Отметка времени и время блока: Проверьте механизм синхронизации времени боковой цепи, чтобы обеспечить согласованность и точность времени генерации блока и предотвратить атаки или откаты блоков, вызванные различиями во времени.
• Безопасность управления on-chain: Проверьте механизм управления боковой цепью, чтобы обеспечить прозрачность и безопасность процессов голосования, предложений и принятия решений, а также предотвратить злонамеренный контроль или атаки.
• Аудит токеномики: Проверка модели токеномики побочной цепи, включая распределение токенов, механизм стимулирования и модель инфляции, для обеспечения того, чтобы экономические стимулы не приводили к злонамеренной деятельности или нестабильности системы.
• Механизм комиссий: Проверьте механизм комиссий для транзакций в боковой цепочке, чтобы убедиться, что он соответствует потребностям пользователей основной и боковой цепочек, чтобы предотвратить манипуляции с комиссиями или перегрузку сети.
• Безопасность активов: Проверка механизма управления активами на цепи, чтобы гарантировать, что процесс хранения, передачи и уничтожения активов является безопасным и надежным, и нет риска несанкционированного доступа или кражи.
• Управление ключами: Проверьте политику управления ключами боковой цепи, чтобы обеспечить безопасность и контроль доступа к закрытому ключу и предотвратить утечку или кражу ключа.

Rollup

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

Rollup в основном делится на zk-Rollup и op-Rollup. Но в отличие от ETH, из-за тьюринг-неполноценности BTC невозможно использовать контракты на BTC для проверки нулевого доказательства. Традиционные решения zk-Rollup не могут быть реализованы на BTC. Так как реализовать BTC Layer2 с использованием zk-Rollup? Далее рассмотрим проект B² Network в качестве примера:

Для проведения верификации доказательства нулевого разглашения на BTC, сеть B² создала сценарий Taproot, который объединяет верификацию доказательства нулевого разглашения zk-Rollup и выдачу стимулов op-Rollup. Его механизм работы примерно следующий:

1. Сеть B² сначала суммирует все транзакции, инициированные пользователями.

2. После сортировки транзакций Rollup сохраните транзакции Rollup, используя децентрализованное хранилище, и передайте их на обработку в zkEVM одновременно.

3. После синхронизации zkEVM со статусом цепочки BTC он обрабатывает транзакции, такие как выполнение контрактов, объединяет и упаковывает результаты и отправляет их агрегатору.

4. Prover генерирует доказательство нулевого разглашения и отправляет его агрегатору. Агрегатор агрегирует транзакции и отправляет доказательство узлам B².

5. Узлы B² выполняют проверку доказательства нулевого знания и создают сценарии Taproot на основе данных Rollup в децентрализованном хранилище.

6. Taproot - это UTXO со значением 1 сатоши. В его структуре данных B² Inscription хранит все данные Rollup, а Tapleaf хранит все данные проверки. После прохождения механизма стимулирования вызовов, он будет отправлен в BTC в качестве подтверждения, проверенного на основе zk proof.

Преимущество Rollup заключается в том, что:

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

Проблемы, с которыми сталкивается Rollup:

• Если данные вне цепи недоступны, пользователи могут быть не в состоянии проверить транзакции и восстановить статус.
• Транзакции Rollup должны быть обработаны пакетами и, наконец, отправлены на главную цепь, что может привести к более длительным временам расчетов. Особенно в op-Rollup есть период споров, и пользователям может потребоваться долгое время ожидания, прежде чем транзакция будет окончательно подтверждена.
• Хотя ZK Rollup обеспечивает более высокий уровень безопасности и мгновенное подтверждение, требования к вычислениям и хранению высоки, и для генерации доказательств с нулевым разглашением требуется большое количество вычислительных ресурсов.

Поскольку выбранное решение - Rollup, его основные пункты аудита безопасности в основном такие же, как у ETH Layer2.

Другие (Вавилон)

Помимо традиционного слоя BTC Layer2, недавно появились также некоторые новые концепции сторонних протоколов, связанных с экосистемой BTC, такие как Вавилон:

Цель Вавилона - преобразовать 21 миллион BTC в децентрализованные стейкинговые активы. В отличие от других уровней 2 BTC, Вавилон не расширяет цепочку BTC. Это уникальная цепочка сама по себе, с особым протоколом ипотеки BTC. Основная цель - соединиться с цепочкой PoS. Ипотека BTC для обеспечения более надежной безопасности для цепочки PoS и решения риска атак с удаленного конца цепочки и централизованного вопроса.

Архитектура разделена на три уровня:

Уровень Биткойна: Это прочная основа Babylon, использующая хорошо известную безопасность Биткойна, чтобы гарантировать, что все транзакции очень безопасны, как и в сети Биткойн.

Слой Вавилона: В сердце Вавилона находится слой Вавилона, настраиваемый блокчейн, который соединяет Биткойн с различными цепями Proof-of-Stake (PoS). Он обрабатывает транзакции, запускает умные контракты и обеспечивает бесперебойную работу всей экосистемы.

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

Принцип работы состоит в обеспечении безопасности цепочки PoS с помощью окончательных блоков, подписанных в цепочке BTC. По сути, это расширяет базовый протокол с помощью дополнительных раундов подписи. Эти подписи в окончательном раунде +1 имеют уникальную особенность: они являются Одноразовыми Извлекаемыми Подписями (EOTS). Цель состоит в интеграции контрольных точек PoS в BTC для решения проблем длительного периода разъединения и удаленных атак PoS.

Преимущество Вавилона в том, что:

• Сделать период отвязки PoS быстрее
• Поскольку BTC заложен, цена связана с BTC, что может снизить инфляционное давление на соответствующую сеть PoS.
• Открывает новые возможности для заработка на BTC

Проблемы, с которыми сталкивается Вавилон:

• Экономические дизайны, такие как процент доходности стейкинга, оказывают большее влияние на энтузиазм стейкинга BTC
• Отсутствие положений о согласованности вознаграждений между цепями PoS

У сторонних протоколов есть различные точки безопасности в зависимости от их реализации. На примере Вавилона, некоторые элементы проверки безопасности, на которые следует обратить внимание, перечислены ниже:：

1. Безопасность смарт-контрактов: Залоговый контракт на BTC реализуется через UTXO-скрипт, и его безопасность требует особого внимания.

2. Безопасность алгоритма подписи: Подписи используются в контракте для управления залогами пользователей, а безопасность его алгоритма связана с генерацией и проверкой подписей.

3. Дизайн экономической модели протокола: Насколько разумно установлена экономическая модель протокола с точки зрения наград и штрафов, и будет ли это приводить к потере активов пользователей.

приложение:

Общие аудиторские элементы публичной цепи и Layer2

• Переполнение целого числа: Проверьте наличие переполнения целого числа и недостатка целого числа
• Бесконечный цикл: проверьте, являются ли условия оценки цикла программы разумными
• Бесконечный рекурсивный вызов: Проверьте, является ли условие выхода из рекурсивного вызова программы разумным
• Гонки: Проверьте операции доступа к общим ресурсам в параллельных условиях
• Аномальный сбой: Проверьте код выбрасывания исключения, который позволяет программе активно завершиться
• Уязвимость деления на 0: Проверьте, есть ли деление на 0
• Преобразование типов: Проверьте, правильно ли происходит преобразование типов и не теряется ли важная информация в процессе преобразования
• Array out of bounds: Убедитесь, что обращение к элементу за пределами массива
• Десериализация через уязвимость: проверьте, есть ли какие-либо проблемы в процессе десериализации
• Функциональная реализация безопасности: проверьте, есть ли в каждой реализации интерфейса RPC безопасные уязвимости и соответствует ли она функции интерфейса RPC.
• Может быть разработано для соответствия
• Являются ли разумными настройки разрешений для чувствительного интерфейса RPC: Проверьте настройки доступа для чувствительного интерфейса RPC
• Механизм шифрованной передачи: Проверьте, используется ли зашифрованный протокол передачи, такой как TLS, и т. д.
• Синтаксический анализ формата данных запроса: проверка процесса синтаксического анализа формата данных запроса
• Атака на разблокировку кошелька: когда узел разблокирует свой кошелек, RPC запрашивает у него кражу средств.
• Традиционная веб-безопасность: Проверьте наличие следующих уязвимостей: Межсайтовый скриптинг (XSS) / Внедрение шаблонов
• Уязвимости компонентов сторонних поставщиков / загрязнение параметров HTTP / SQL-инъекция / внедрение сущностей XXE десериализации
• уязвимости/уязвимости SSRF/внедрение кода/локальный включение файла/удаленное включение файла/внедрение выполнения команд и другие традиционные уязвимости
• Механизм аутентификации и идентификации узла сети: Проверьте наличие механизма идентификации узла и возможность обхода этого механизма идентификации узла.
• Загрязнение таблицы маршрутизации: Проверьте, можно ли случайным образом вставлять или перезаписывать данные в таблице маршрутизации
• Алгоритм обнаружения узла: Проверьте, сбалансирован ли и непредсказуем ли алгоритм обнаружения узла, например, проблемы с несбалансированным алгоритмом расстояния и другие.
• Аудит занятости номера соединения: Проверьте, является ли ограничение и управление количеством узлов соединения сети p2p разумным
• Атака затмением: Оцените затраты и вред от атаки затмением и предоставьте количественный анализ при необходимости
• Сибил атака: оцените механизм консенсуса голосования и проанализируйте стратегию проверки квалификации голосования
• Атака прослушивания: Проверка протоколов связи на утечку конфиденциальной информации
• Атака пришельцев: Оцените, может ли узел идентифицировать подобные узлы цепи
• Временное вмешательство: проверка механизма расчета сетевого времени узла
• Атака нехватки памяти: проверка мест с большим потреблением памяти
• Атака истощения жесткого диска: проверьте, где хранятся большие файлы
• Атака на давление сокета: проверьте политику ограничения количества подключений
• Атака исчерпания обработчика ядра: Проверьте пределы создания обработчика ядра, такие как файловые обработчики и т. д.
• Устойчивые утечки памяти: проверьте наличие утечек памяти
• Безопасность алгоритма хэширования: проверка устойчивости к коллизиям алгоритма хэширования
• Безопасность алгоритма цифровой подписи: проверка безопасности алгоритма подписи и безопасности реализации алгоритма
• Безопасность алгоритма шифрования: проверка безопасности алгоритма шифрования, безопасность реализации алгоритма
• Безопасность генератора случайных чисел: Проверка того, насколько надежны критические алгоритмы генерации случайных чисел
• Безопасность реализации BFT: оценка безопасности реализации алгоритма BFT
• Правила выбора вилки: Проверьте правила выбора вилки, чтобы обеспечить безопасность
• Выявление централизации: определение наличия избыточной централизации в дизайне системы
• Аудит поощрений: оценка влияния поощрений на безопасность
• Атака двойных трат: Проверьте, может ли согласование защитить от атаки двойных трат
• Аудит атаки MEV: Проверьте влияние MEV узлов упаковки блоков на справедливость цепи
• Аудит процесса синхронизации блоков: Проверка проблем безопасности во время процесса синхронизации
• Аудит процесса разбора блочного формата: Проверка проблем безопасности в процессе разбора формата, таких как ошибки разбора, приводящие к аварийному завершению
• Аудит процесса генерации блоков: Проверка вопросов безопасности во время процесса генерации блоков, включая разумность метода построения корня дерева Меркла
• Аудит процесса проверки блока: проверка достаточности элементов содержимого подписи блока и логики проверки
• Аудит логики подтверждения блоков: проверка обоснованности алгоритма и реализации подтверждения блока
• Коллизия хэша блока: Проверьте метод построения конфликта хэша блока и является ли обработка конфликта разумной.
• Ограничения ресурсов обработки блока: Проверьте, являются ли ограничения ресурсов, таких как пул потерянных блоков, расчет проверки, адресация жесткого диска и т. д., разумными.
• Аудит процесса синхронизации транзакций: Проверьте проблемы безопасности во время процесса синхронизации
• Коллизия хэша транзакции: Проверьте метод построения коллизии хэша транзакции и обработки коллизии
• Разбор формата транзакции: проверка проблем безопасности в процессе разбора формата, таких как ошибки разбора, приводящие к сбоям
• Проверка законности транзакции: проверьте, достаточны ли каждый тип элементов контента подписи транзакции и логика проверки.
• Ограничения ресурсов обработки транзакций: Проверьте, являются ли ограничения ресурсов, такие как пулы транзакций, вычисления проверки, адресация жесткого диска и т. д., разумными.
• Атака на пластичность транзакций: может ли транзакция изменить внутренние поля (например, ScriptSig), чтобы изменить хэш транзакции, не влияя на действительность транзакции?
• Проверка атаки повтора транзакции: Проверьте обнаружение системы повтора транзакции
• Проверка байт-кода контракта: проверьте проблемы безопасности процесса проверки контракта виртуальной машины, такие как целочисленное переполнение, бесконечный цикл и т. д.
• Исполнение байткода контракта: Проверка проблем безопасности в процессе выполнения байткода виртуальной машины, таких как переполнение целого числа, бесконечный цикл и т.д.
• Модель газа: Проверьте, соответствуют ли комиссии за обработку каждой атомной операции обработки транзакций/выполнения контракта ресурсному потреблению
• Целостность ведения журнала: Проверьте, зарегистрированы ли ключевые сведения
• Безопасность записей журнала: Проверьте, нет ли проблем с безопасностью, вызванных неправильной обработкой во время обработки журнала, таких как целочисленное переполнение и т. д.
• Журнал содержит конфиденциальную информацию: Проверьте, содержит ли журнал конфиденциальную информацию, такую как ключи
• Хранилище журналов: проверьте, не записывается ли в журнал слишком много контента, что приводит к потреблению ресурсов узла
• Безопасность цепочки поставок узла кода: Проверьте известные проблемы всех сторонних библиотек, компонентов и соответствующих версий общественной цепочки фреймворка

Beosin — одна из первых в мире компаний, занимающихся безопасностью блокчейна, которая начала проводить формальную проверку. Сосредоточившись на полном экологическом бизнесе «безопасность + соответствие», она открыла филиалы в более чем 10 странах и регионах по всему миру. Его бизнес включает в себя аудит безопасности кода до того, как проект выйдет в онлайн, мониторинг и блокировку рисков безопасности во время работы проекта, восстановление после кражи, «универсальные» продукты для обеспечения соответствия блокчейну + услуги безопасности, такие как борьба с отмыванием денег (AML) виртуальных активов и оценка соответствия, которая соответствует местным нормативным требованиям. Участники проекта, нуждающиеся в аудите, могут связаться с отделом безопасности Beosin.

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

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