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

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

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

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

Сеть молний

Первоначальная концепция Lightning Network была известна как «платежный канал». Философия дизайна заключалась в непрерывном обновлении статуса неподтвержденных транзакций путем замены транзакций до их окончательной передачи в сеть биткойнов. Когда Сатоши Накамото создал биткойн в 2009 году, он уже предложил идею платежных каналов, даже включив черновой код для платежных каналов в Bitcoin 1.0. Этот черновик позволил пользователям обновлять статус транзакции до ее подтверждения сетью. Однако это произошло только после выпуска белой бумаги с названием Сеть молний Биткойна: масштабируемые мгновенные внелинейные платежичто молния сети по-настоящему появилась и привлекла внимание общественности.

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

https://1ml.com/

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

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

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

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

2. Внебиржевые транзакции:

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

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

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

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

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

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

Из вызовов, с которыми сталкивается Lightning Network, можно выделить:

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

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

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

Боковые цепочки

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

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

1. Пользователь блокирует BTC на главной цепи. Затем доверенное лицо получает и использует упрощенное подтверждение платежей (SPV), чтобы подтвердить, была ли подтверждена транзакция блокировки пользователя.

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

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

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

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

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

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

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

Стаксы

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

Преимущества боковых цепочек

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

Проблемы боковых цепей

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

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

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

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

Rollup

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

Rollup поставляется в двух основных вариантах: zk-Rollup и op-Rollup. Однако, в отличие от Ethereum, отсутствие у Bitcoin полной вычислительной универсальности препятствует использованию смарт-контрактов для верификации доказательств нулевого знания (ZKP) непосредственно на своей сети. Это означает, что традиционные решения zk-Rollup не могут быть реализованы на Bitcoin. Так как же можно использовать zk-Rollup для достижения масштабирования Bitcoin на уровне 2? Давайте рассмотрим проект B² Network в качестве примера:

Для выполнения верификации ZKP на Bitcoin, B² Network разработала сценарий Taproot, интегрирующий верификацию нулевого доказательства zk-Rollup с механизмом инцентивного вызова op-Rollup. Вот как это работает:

1. B² Network сначала агрегирует все транзакции пользователей в Rollup.
2. Затем секвенсор упорядочивает эти транзакции Rollup, храня их в децентрализованном хранилище и обрабатывая через zkEVM.
3. После синхронизации состояния цепочки Биткойн zkEVM обрабатывает выполнение контрактов и другие транзакции, consolидируя результаты и отправляя их агрегатору.
4. Доказательство генерирует доказательство нулевого знания и отправляет его агрегатору, который объединяет транзакции и доказательство, а затем передает их узлам B².
5. Узлы B² проверяют доказательство нулевого разглашения и создают сценарий Taproot на основе данных Rollup, хранящихся в децентрализованном хранилище.
6. Taproot, который является UTXO со значением 1 сатоши, содержит B² Inscription в своей структуре данных, храня все данные Rollup, в то время как Tapleaf хранит данные проверки всех доказательств. Пройдя механизм стимулирования вызова, он представляется в Bitcoin в виде обязательства на основе zk-proof.

Преимущества Rollup:

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

Проблемы Rollup:

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

Учитывая, что используется Rollup, его ключевые пункты аудита безопасности согласуются с теми, которые есть у Layer 2 Ethereum.

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

Помимо традиционных решений уровня 2 BTC, появились новые протоколы сторонних разработчиков, связанные с экосистемой BTC, такие как Вавилон:

Babylon стремится преобразовать 21 миллион BTC в децентрализованные стейкинговые активы. В отличие от других решений BTC Layer 2, Babylon не сосредотачивается на масштабировании сети BTC. Вместо этого это уникальный блокчейн с специализированным протоколом стейкинга BTC, разработанным в первую очередь для взаимодействия с цепочками Proof of Stake (PoS). Цель состоит в стейкинге BTC для повышения безопасности цепочек PoS, решая проблемы, такие как атаки на длинные расстояния и риски централизации.

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

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

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

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

• Вавилон ускоряет процесс отвязки стейкинга PoS.
• Ставя BTC на стейкинг, Вавилон помогает смягчить инфляционные давления на соответствующей сети PoS.
• Babylon открывает новые возможности для владельцев BTC для получения дохода.

Проблемы Вавилона:

• Ставки вознаграждения и другие экономические факторы значительно влияют на стимул для ставки BTC.
• В наградных механизмах нет единства между различными цепями PoS.

Фокус на безопасности варьируется в зависимости от конкретной реализации протоколов сторонних производителей. Для Вавилона некоторые ключевые точки аудита безопасности включают:

1. Безопасность смарт-контрактов: Залоговые контракты на BTC реализованы через UTXO-скрипты, требующие тщательного внимания к их безопасности.2. Безопасность алгоритма подписи: Безопасность алгоритма подписи, используемого для управления залогами в контракте, критична, поскольку она влияет на генерацию и проверку подписей.3. Проектирование экономической модели: Экономическая модель протокола, особенно в части вознаграждений и штрафов, должна быть тщательно изучена, чтобы гарантировать, что она не приведет к потере активов пользователей.

Приложение:

Общие пункты аудита для общественных цепочек и уровня 2

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

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

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

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