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

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

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

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

Спалахова мережа

Початкова концепція за мерехтливою мережею була відома як "платіжний канал". Філософія дизайну полягала в постійному оновленні статусу непідтверджених транзакцій через заміну транзакцій до їх остаточного трансляції до мережі Bitcoin. Коли Сатоші Накамото створив Bitcoin у 2009 році, він вже запропонував ідею платіжних каналів, навіть включивши чернетковий код для платіжних каналів у Bitcoin 1.0. Цей чернетковий код дозволяв користувачам оновлювати статус транзакцій перед їх підтвердженням мережею. Однак це сталося лише після випуску білої книги під заголовком Мережа миттєвих платежів Bitcoin Lightning: масштабований платіж поза ланцюгомщо Мережа Lightning дійсно з'явилася і здобула увагу громадськості.

Сьогодні впровадження платіжних каналів та Мережі Блискавок стало досить зрілим. Наразі Мережа Блискавок складається з 13 325 вузлів та 49 417 каналів, загалом відкладено 4 975 BTC.

https://1ml.com/

У мережі Lightning важливо забезпечити безпеку активів користувачів під час переказів. Нижче ми пояснимо, як працює мережа Lightning та як вона захищає безпеку активів користувачів, виходячи з масштабу вузлів мережі.

Обидві сторони подають дві транзакції до основної мережі Bitcoin: одну - для відкриття каналу, іншу - для його закриття. Зазвичай процес включає три кроки:

1.Відкриття каналу:

Спочатку обидва користувачі ставлять Bitcoin на багато підписантний гаманець на мережі BTC через мережу Lightning. Як тільки Bitcoin успішно заставлений та заблокований, відкривається платіжний канал, що дозволяє обом сторонам проводити позачергові транзакції в межах цього каналу.

2.Операції поза ланцюгом:

Після відкриття каналу всі трансферні транзакції між користувачами обробляються в мережі Lightning, і кількість таких офлайн-транзакцій не обмежена. Ці транзакції не потрібно негайно подавати до основної мережі Bitcoin, а замість цього вони миттєво завершуються за допомогою офлайн-механізму Lightning мережі.

Цей метод обробки позачергово значно збільшує швидкість та ефективність транзакцій, уникаючи заторів на головній мережі Біткойн та високих комісій за транзакції.

3.Закриття каналу та здійснення розрахунків за рахунками:

Коли будь-який користувач вирішує вийти з каналу, відбувається остаточне залікове врегулювання. Цей процес забезпечує розподіл всіх коштів у каналі відповідно до найбільш останнього стану. Обидва користувача потім знімають свої відповідні врегульовані баланси з багатоадресного гаманця, відображаючи фактичний розподіл коштів на момент закриття каналу. Нарешті, транзакція, що представляє остаточний стан рахунку, надсилається на головну мережу Bitcoin.

Переваги мережі Lightning включають:

• Збільшена швидкість транзакцій:
  Мережа Lightning дозволяє користувачам здійснювати угоди поза ланцюжком, що означає, що угоди можуть бути завершені майже миттєво без очікування часу підтвердження блоку. Це дозволяє досягти швидкості угод другого рівня, що значно покращує враження від користування.
• Підвищена конфіденційність:
  Офлайн-транзакції в мережі Lightning не потребують публічного запису в основному ланцюжку Bitcoin, покращуючи конфіденційність транзакцій. Лише відкриття та закриття каналів потрібно записати на основному ланцюжку, тому активності користувачів не повністю розголошуються.
• Підтримка мікроплатежів:
  Мережа Lightning особливо підходить для обробки мікроплатежів, таких як оплата контенту та платежі між пристроями Інтернету речей. Традиційні транзакції Bitcoin через високі комісії не є ідеальними для частих мікроплатежів, але мережа Lightning вирішує цю проблему.

Завдання, з якими стикається мережа Lightning, включають:

• Ліквідність мережі:
  Мережа Lightning ҥіється від того, що Bitcoin передбачено заблокований в каналі. Це означає, що користувачі повинні завдати достатньо Bitcoin у свої платіжні канали наперед, щоб здійснювати транзакції. Недостатня ліквідність може призвести до невдалих платежів, особливо для великих платежів.
• Маршрутизація:
  Знаходження ефективного маршруту від відправника до одержувача може бути складною проблемою, особливо при збільшенні масштабу мережі. Зі зростанням кількості вузлів мережі та каналів забезпечення успішного завершення платежу стає складнішим.
• Довіреність кастодіального управління: Вузли можуть бути вразливими до зловмисних атак, і користувачам потрібно довіряти тому, що вузли, до яких вони підключені, не намагатимуться вкрасти кошти. Є також питання про те, чи можуть вузли запобігти витоку приватних ключів.
• Технічні стандарти та взаємодія: Необхідні постійні технічні стандарти та протоколи для забезпечення взаємодії між різними реалізаціями мережі Lightning. Наразі кілька розробницьких команд працюють над різними реалізаціями мережі Lightning, що може призвести до проблем сумісності.
• Проблеми конфіденційності: Хоча Мережа Lightning підвищує конфіденційність у операціях з Біткойном, інформацію про операції все ще можна відслідковувати або аналізувати. Крім того, оператори вузлів мережі можуть бачити операції, які проходять через їх вузли, що потенційно може підірвати деяку конфіденційність.

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

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

Бічні ланцюги

На відміну від мережі Lightning, вторинний ланцюжок є незалежним блокчейном, який працює паралельно з головним ланцюжком (наприклад, блокчейн BTC) та взаємодіє з ним через механізм, відомий як двосторонній прив'язка (2WP). Метою вторинних ланцюжків є надання додаткової функціональності та масштабованості без зміни протоколу головного ланцюжка.

Сайдчейн, як незалежний блокчейн, має свій власний механізм згоди, вузли та правила обробки транзакцій. Він може використовувати різні технології та протоколи в залежності від потреб конкретних сценаріїв застосування. За допомогою механізму двосторонньої прив'язки, сайдчейн спілкується з головним ланцюжком, забезпечуючи можливість вільного та безпечного переказу активів між ними. Робота механізму двосторонньої прив'язки, як правило, включає наступні кроки:

1. Користувач блокує BTC на головному ланцюжку. Довірена сторона потім отримує та використовує спрощену перевірку платежів (SPV), щоб підтвердити, чи була підтверджена транзакція блокування користувача.

2. Довірена сутність видає еквівалентну кількість токенів користувачу на бічному ланцюгу.

3. Після завершення їх транзакцій користувач блокує залишкові токени на бічному ланцюгу.

4. Після перевірки законності транзакцій довірена сторона розблоковує та випускає відповідну вартість BTC користувачеві на головному ланцюжку.

Примітка 1: Довірені суб'єкти відіграють критичну роль в механізмі двостороннього кріптовалютного обміну, управляючи блокуванням та звільненням активів. Ці суб'єкти повинні мати високий рівень довіryвідності та технічної здатності для забезпечення безпеки активів користувачів.

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

Представницькі проекти бічного ланцюжка

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

Стеки

Stacks з'єднує кожний блок Stacks з блоком Bitcoin через свій механізм Proof of Transfer (PoX). Для сприяння розробці смарт-контрактів Stacks спроектував мову програмування Clarity. У Clarity, отримати-інформацію-про-запис-блоку?функція дозволяє введення висоти блоку Bitcoin для отримання хеша заголовка блоку, тим часом висота-блоку-випалюванняКлючове слово отримує поточну висоту блоку ланцюга Bitcoin. Ці функції дозволяють розумним контрактам Clarity читати стан базового ланцюга Bitcoin, що дозволяє транзакціям Bitcoin спрацьовувати контракти. Автоматично виконуючи ці розумні контракти, Stacks розширює функціональність Bitcoin. Для докладного аналізу Stacks ви можете звернутися до попередньої дослідницької статті Beosin:Що таке Стакс? Які виклики можуть виникнути у мережі Стакс BTC другого рівня?

Переваги бічних ланцюгів

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

Виклики бічних ланцюжків

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

Рівень 2 - це повна система блокчейну, тому загальні аудиторські пункти для громадських блокчейнів також застосовуються до бічних ланцюжків. Докладніше дивіться додаток в кінці цієї статті.

Крім того, через свої унікальні характеристики, побічні ланцюжки потребують додаткових аудитів:

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

Rollup

Rollup - це рішення масштабування Layer 2, призначене для підвищення пропускної здатності та ефективності транзакцій блокчейну. Агрегуючи велику кількість транзакцій ("Розгортання") та оброблюючи їх поза ланцюжком, воно зменшує навантаження на головний ланцюжок, подаючи лише кінцеві результати назад до нього.

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

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

1. B² Network спочатку агрегує всі транзакції користувача в Rollup.
2. Потім секвенсор упорядковує ці транзакції Rollup, зберігаючи їх у децентралізованому сховищі і оброблюючи через zkEVM.
3. Після синхронізації стану ланцюга Біткойн zkEVM обробляє виконання контрактів та інші транзакції, узгоджуючи результати та надсилаючи їх агрегатору.
4. Доказувач генерує доказ нульового розголосу та надсилає його агрегатору, який комбінує транзакції та доказ та пересилає їх вузлам B².
5. B² Вузли перевіряють докази з нульовим відомостями та створюють сценарій Taproot на основі даних Rollup, збережених у децентралізованому сховищі.
6. Тапрут, який є UTXO зі значенням 1 сатоші, містить в собі B² впис у його структурі даних, зберігаючи всі дані Rollup, тоді як Тапліф зберігає дані верифікації всіх доказів. Після проходження механізму виклику стимулювання, він надсилається до Bitcoin як зобов'язання на основі zk-proof.

Переваги Rollup:

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

Виклики Rollup:

• Якщо дані поза ланцюжком стають недоступними, користувачі можуть бути не в змозі підтвердити транзакції та відновити свій стан.
• Зведені транзакції потрібно обробляти пакетами та зрештою надсилати до основного ланцюга, що може призвести до збільшення часу розрахунків. Це особливо актуально у випадку op-Rollup, де є період оскарження, що змушує користувачів довше чекати на остаточне підтвердження транзакції.
• Хоча ZK Rollup забезпечує вищу безпеку та миттєве підтвердження, він вимагає значних обчислювальних ресурсів для створення доказів із нульовим розголошенням.

Оскільки використовується Rollup, його ключові пункти аудиту безпеки відповідають тим, що на другому рівні Ethereum.

Інші (Вавилон)

Крім традиційних рішень другого рівня для BTC, з'явилися нові протоколи від сторонніх постачальників, пов'язані з екосистемою BTC, такі як Вавилон:

Вавилон має на меті перетворити 21 мільйон Біткойнів на децентралізовані активи стейкінгу. На відміну від інших рішень другого рівня BTC, Вавилон не фокусується на масштабуванні мережі BTC. Натомість, це унікальний блокчейн з спеціалізованим BTC протоколом стейкінгу, призначеним переважно для взаємодії з ланцюжками Proof of Stake (PoS). Мета полягає в стейкінгу BTC для підвищення безпеки ланцюжків PoS, вирішення проблем, таких як атаки на велику відстань та ризики централізації.

Архітектура поділена на три шари:

• Біткойн Шар: Це міцний фундамент Вавілону, використовуючи відому безпеку Біткойну, щоб забезпечити, що всі транзакції є вельми безпечними, так само, як на мережі Біткойн.
• Шар Вавилону:Ядро Вавилону, цей спеціалізований блокчейн з'єднує Bitcoin з різними ланцюжками PoS. Він обробляє транзакції, запускає смарт-контракти та забезпечує плавну роботу в екосистемі.
• Ланцюг PoS:Верхній шар складається з кількох ланцюгів PoS, кожен з яких обраний за його унікальними перевагами. Ця структура надає BabylonChain надзвичайну масштабованість і гнучкість, дозволяючи користувачам скористатися найкращими функціями різних PoS блокчейнів.

Babylon працює, підписуючи останні блоки на ланцюгу BTC, щоб забезпечити безпеку ланцюгів PoS. По суті це розширює базовий протокол додатковим раундом підписів. Ці підписи в останньому раунді +1 мають унікальну особливість: вони є витяжними одноразовими підписами (EOTS). Мета полягає в інтеграції контрольних точок PoS на ланцюгу BTC, вирішуючи проблеми тривалих періодів розблокування та атак на велику відстань в системах PoS.

Переваги Вавилона:

• Вавилон прискорює процес розблокування ставок PoS.
• Ставлячи BTC, Вавилон допомагає зменшити інфляційний тиск на відповідній мережі PoS.
• Вавилон відкриває нові можливості для власників BTC отримувати прибуток.

Виклики Вавилона:

• Ставки винагороди за участь та інші економічні фактори значно впливають на стимул для стейкінгу BTC.
• Немає єдності в механізмах винагороди на різних ланцюжках PoS.

Фокус на безпеці варіюється в залежності від конкретної реалізації протоколів сторонніх вендорів. Для Вавілона деякі ключові пункти аудиту безпеки включають:

1. Безпека Смарт-контрактів: Контракти з утриманням на BTC реалізовані через UTXO скрипти, які вимагають уважного ставлення до їх безпеки.2. Безпека Алгоритму Підпису: Безпека алгоритму підпису, який використовується для управління утриманням в контракті, є критичною, оскільки вона впливає на генерацію та перевірку підписів.3. Проектування Економічної Моделі: Економічна модель протоколу, особливо щодо винагород та покарань, потребує ретельного аналізу, щоб гарантувати, що вона не призведе до втрати активів користувачів.

Додаток:

Загальні аудиторські пункти для громадських ланцюгів & Рівень 2

• Переповнення цілого числа:Перевірте на переповнення та недостатність цілих чисел.
• Необмежена петля:Перевірте, чи умови циклу в програмі є обґрунтованими.
• Необмежена рекурсія:Переконайтеся, що умови виходу для рекурсивних викликів належним чином встановлені.
• Умова гонки:Дослідження операцій доступу до спільних ресурсів в умовах конкурентної взаємодії.
• Невідповідні винятки:Визначте код, що викидає винятки, що спричиняють неочікуване завершення програми.
• Ділення на Нуль:Перевірте випадки, де може виникнути ділення на нуль.
• Перетворення типів:Переконайтеся, що конвертація типів є точною і ніяка критична інформація не втрачається у процесі.
• Виходить за межі масиву:Переконайтесь, що елементи масиву доступні в межах дійсних меж.
• Вразливості десеріалізації:Перевірте проблеми під час процесу десеріалізації.
• Реалізація функціональності безпеки:Перевірте, чи реалізація інтерфейсів RPC є безпечною та відповідає їх функціональному дизайну.
• Чутливі налаштування дозволів інтерфейсу RPC:Переконайтеся, що доступ до дозволів для чутливих RPC інтерфейсів налаштований належним чином.
• Зашифрований механізм передачі:Перевірте використання зашифрованих протоколів передачі, таких як TLS.
• Розбір формату даних запиту:Перевірте процес розбору форматів даних запиту.
• Атака на розблокування гаманця:Переконайтеся, що кошти не вкрадені через запити RPC, коли вузол розблоковує свій гаманець.
• Традиційна веб-безпека:Перевірте наступні вразливості: Cross-Site Scripting (XSS), Впровадження шаблонів, Вразливості сторонніх компонентів, Забруднення параметрів HTTP, Впровадження SQL, Впровадження XXE, Вразливості десеріалізації, Вразливості SSRF, Впровадження коду, Локальне включення файлів, Віддалене включення файлів, Впровадження команд і т.д.
• Механізм аутентифікації та ідентифікації вузлів мережі:Переконайтеся, що існує механізм визначення ідентичності вузла, і його неможливо обійти.
• Отруєння таблиці маршрутизації:Перевірте, чи можна маніпулювати або перезаписувати таблицю маршрутизації довільним чином.
• Алгоритм виявлення вузлів:Переконайтеся, що алгоритм виявлення вузлів є збалансованим та непередбачуваним, вирішуючи проблеми, такі як дисбаланси в алгоритмах відстані.
• Аудит зайнятості підключення:Переконайтеся, що обмеження та керування вузлами, підключеними до мережі p2p, є обґрунтованими.
• Атака екліпса:Оцініть вартість та вплив атак екліпсу, надавши кількісний аналіз за необхідності.
• Атака Сібіл:Оцініть механізм консенсусу при голосуванні та проаналізуйте стратегії перевірки правомірності голосування.
• Атака прослуховування:Перевірте, що комунікаційний протокол не витікає особистої інформації.
• Атака інопланетян:Оцініть, чи можуть вузли визнавати інші вузли з однієї мережі блокчейн.
• Перехоплення часу:Перевірте механізм обчислення мережевого часу на вузлах.
• Атака на виснаження пам'яті:Перевірте області високого споживання пам'яті.
• Атака виснаження диска:Перевірте області, пов'язані з великим сховищем файлів.
• Атака на стрес-тестування сокетів:Перевірте стратегії, що обмежують кількість підключень.
• Атака на виснаження обробника вікон: Переконайтеся, що обмеження на створення вузлів ядра, таких як файлові вузли, є розумними.
• Постійні витоки пам'яті:Визначте області, схильні до витоку пам'яті.
• Алгоритм хешування безпеки:Переконайтеся, що хеш-алгоритм стійкий до колізій.
• Безпека алгоритму цифрового підпису:Перевірте безпеку алгоритму підпису та його реалізацію.
• Захист алгоритму шифрування: Переконайтеся, що алгоритм шифрування та його реалізація безпечні.
• Безпека генератора випадкових чисел:Перевірте, що критичні алгоритми генерації випадкових чисел є обґрунтованими.
• Безпека реалізації BFT:Оцініть безпеку реалізації алгоритму витривалості візантійської несправності (BFT).
• Правило вибору відгалуження:Перевірте правило вибору відгалуження, щоб забезпечити безпеку.
• Виявлення централізації:Виявіть будь-яку надмірну централізацію в дизайні системи.
• Перевірка механізму стимулювання:Оцініть вплив механізму стимулювання на безпеку.
• Атака подвійного витрачання:Перевірте, чи може консенсус відстояти атаки на подвійне витрачання.
• MEV Атака Аудит:Оцініть вплив максимально видобувної вартості (MEV) на справедливість ланцюга під час упакування блоку.
• Перевірка процесу синхронізації блоків:Перевіряти питання безпеки під час процесу синхронізації.
• Парсинг формату блокування аудиту:Оцінити проблеми безпеки під час розбору формату блоку, такі як помилки розбору, що призводять до аварій.
• Проведення аудиту процесу генерації блоків:Перегляньте безпеку процесу генерації блоків, включаючи побудову кореня дерева Меркла.
• Перевірка процесу блокування: аудитПеревірте вміст елементів підписів блоків та адекватність логіки перевірки.
• Перевірка логіки підтвердження блоку:Оцініть, чи алгоритм підтвердження блоку та його реалізація є розумними.
• Колізія хеш-функції блока:Перевірте, як конструюються колізії хеш-блоків та чи відповідно обробляється такі колізії.
• Обмеження ресурсів обробки блоків:Перевірте, чи обмеження ресурсів для пулу сирітських блоків, обчислення верифікації та адресування диска є обґрунтованими.
• Аудит процесу синхронізації транзакцій:Огляд проблем з безпекою під час процесу синхронізації транзакцій.
• Зіткнення хеш-значення транзакції:Перевірте, як конструюються та обробляються зіткнення хешів транзакцій.
• Розбір формату транзакції:Оцініть питання безпеки під час розбору формату транзакції, такі як помилки розбору, які можуть призвести до аварій.
• Перевірка законності транзакції:Перевірте зміст елементів різних підписів транзакцій та достатність логіки перевірки.
• Обмеження ресурсів обробки транзакцій:Перегляньте, чи обмеження ресурсів для пулу транзакцій, обчислення підтвердження та адресування на диску є розумними.
• Атака на зміну транзакції:Оцініть, чи можуть транзакції змінювати внутрішні поля (наприклад, ScriptSig), щоб змінити хеш транзакції без впливу на її валідність.
• Перевірка атаки повторення транзакцій:Перевірте виявлення системи атак повторного відтворення транзакцій.
• Перевірка байт-коду розумного контракту:Перегляньте безпеку процесу верифікації контракту віртуальної машини, такий як перевірка переповнень цілих чисел та безкінечні петлі.
• Виконання байткоду розумного контракту: Оцініть проблеми безпеки під час виконання байт-коду віртуальною машиною, такі як цілочисельні переповнення та нескінченні цикли.
• Модель газу: Переконайтеся, що плата за обробку транзакцій/виконання контрактів для кожної атомарної операції пропорційна споживанню ресурсів.
• Цілісність журналу:Переконайтеся, що критична інформація записана в журналах.
• Безпека журналу:Перевірте, чи обробка журналів не вводить проблем безпеки, таких як переповнення цілих чисел.
• Журнали, що містять чутливу інформацію:Переконайтеся, що журнали не містять ключі або іншу конфіденційну інформацію.
• Зберігання журналів:Перевірте, чи зайве ведення журналу призводить до використання ресурсів на вузлах.
• Безпека ланцюжка постачання вузлів коду:Перегляньте відомі проблеми з усіма бібліотеками сторонніх виробників, компонентами та версіями публічного ланцюжка framework.

Як одна з найстаріших глобальних компаній з блокчейн-безпеки, яка спеціалізується на формальній верифікації, Beosin фокусується на комплексній екосистемі «безпека + відповідність». Компанія встановила філії в понад 10 країнах та регіонах по всьому світу. Її послуги включають в себе продукти та послуги з блокчейн відповідності «все в одному», включаючи аудити безпеки коду перед запуском проектів, моніторинг ризиків безпеки в реальному часі та перехоплення під час операцій проекту, відновлення вкрадених активів, протидію відмиванню коштів (AML) для віртуальних активів та оцінки відповідності, які відповідають місцевим регулятивним вимогам. Ми вітаємо проекти з потребами в аудиті звертатися до команди безпеки Beosin.

Disclaimer：

1. Ця стаття передрукована з [ Beosin], Усі авторські права належать оригінальному автору [Beosin]. Якщо є заперечення проти цього видруку, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено, копіювання, поширення або плагіатування перекладених статей заборонене.