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

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

У цій статті ми будемоМережа Lightning(Lightning Network), 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 Network і т.д. Beosin тепер запускає рішення для перевірки BTC Layer2, щоб надати комплексні та надійні послуги з перевірки безпеки для всього екосистеми BTC.

Мережа «Блискавка»

Найдавніша концепція Lightning Network називається «платіжний канал». Його ідея дизайну полягає в постійному оновленні статусу непідтвердженої транзакції шляхом заміни транзакцій, доки вона не буде остаточно трансльована в мережу Bitcoin. Сатоші Накамото вже запропонував ідею платіжних каналів, коли створив Bitcoin у 2009 році, і включив чернетку коду для платіжних каналів у Bitcoin 1.0, який дозволяв користувачам оновлювати статус транзакції до того, як транзакція була підтверджена мережею. Однак лише після випуску офіційного документа «Мережа Bitcoin Lightning Network: масштабований миттєвий платіж поза мережею» Lightning Network по-справжньому народилася та потрапила в поле зору громадськості.

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

https://1ml.com/

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

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

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

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

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

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

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

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

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

Перевага мережі Lightning полягає в тому, що:

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

Виклики, перед якими стоїть мережа Lightning:

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

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

• Перевірте всебічність конструкції системи мережі Lightning та можливість виникнення заторів у каналах через напади грифів.
• Перешкоди в каналі: Перевірте безпеку структури каналу мережі Lightning та можливість піддаватися атакам на перешкоди в каналі.
• Блокування та розблокування активів в каналі: Перегляньте процес блокування та розблокування активів в мережі Lightning, щоб забезпечити безпечність та надійність переказу коштів при відкритті або закритті платіжного каналу.
• Оновлення стану та закриття: Оцініть процес оновлення стану та механізм примусового закриття каналу, щоб забезпечити можливість правильно ідентифікувати та виконати найновіший стан при виникненні неприродних умов.
• Контракт Time Lock and Hash Lock (HTLC): Оцініть виконання HTLC, щоб переконатися, що умови часового блокування та хеш-блокування можуть бути виконані правильно, щоб уникнути втрат коштів, спричинених проблемами з часовим вікном.
• Залежність від часових позначок блокчейну: оцініть залежність мережі Lightning Network від часової позначки блокчейну Bitcoin, щоб переконатися, що час у мережі та поза мережею можна правильно координувати для запобігання атакам часу.
• Безпека алгоритму маршрутизації: перевірте ефективність і безпеку алгоритму маршрутизації, щоб запобігти ризикам розкриття конфіденційності користувачів і зловмисним маніпулюванням маршрутизацією.
• Зберігання каналу та відновлення даних: перевірте механізм зберігання каналу та стратегію відновлення даних, щоб переконатися, що статус каналу можна відновити у разі відмови вузла або несподіваного відключення, щоб уникнути втрати коштів.

бічний ланцюг

У відміну від мережі Lightning, побічний ланцюжок - це незалежний блокчейн, який працює паралельно з основним ланцюжком (таким як ланцюжок BTC) та взаємодіє з основним ланцюжком за допомогою двосторонньої прив'язки (Two-Way Peg). Метою побічного ланцюжка є досягнення більшої функціональності та покращення масштабованості, не змінюючи протокол основного ланцюжка.

Як незалежний блокчейн, бічний ланцюг має власний механізм згоди, вузли та правила обробки транзакцій. Він може використовувати технології та протоколи, відмінні від основного ланцюга відповідно до потреб конкретних сценаріїв застосування. За допомогою механізму двостороннього прив'язування (2WP) бічний ланцюг спілкується з основним ланцюгом, щоб забезпечити можливість вільного та безпечного переказу активів між ними. Операційний механізм механізму двостороннього прив'язування (2WP) приблизно такий:

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

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

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

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

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

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

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

CKB (Nervos Network)

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

Stacks

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?》

Перевага бічних ланцюгів полягає в тому, що:

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

Виклики, що стоять перед сайдчейнами:

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

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

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

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

Rollup

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

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

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

1. Б² Network спочатку згортає всі транзакції, ініційовані користувачами.

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

3. Після синхронізації zkEVM статусу ланцюга BTC він обробляє транзакції, такі як виконання контракту, об'єднання та упакування результатів та відправляє їх агрегатору.

4. Провер генерує доказ незнання і відправляє його агрегатору. Агрегатор агрегує транзакції та відправляє доказ B²-вузлам.

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

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

Перевага Rollup полягає в тому, що:

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

Виклики, з якими стикається Rollup:

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

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

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

Крім традиційного BTC Layer2, недавно в екосистемі BTC також з'явилися деякі нові концепції сторонніх протоколів, таких як Вавилон:

Метою Вавилона є перетворення 21 мільйона BTC на децентралізовані активи стейкінгу. На відміну від інших Layer 2 BTC, Вавилон не розширює ланцюжок BTC. Це унікальний ланцюжок сам по собі з особливим протоколом застави BTC. Головна мета - підключення до ланцюжка PoS. Застосовувана застава BTC для надання більшої безпеки ланцюжку PoS та вирішення проблеми ризику атак з віддаленого кінця ланцюжка та централізованого питання.

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

Шар Bitcoin: Це міцний фундамент Вавилона, який використовує відому безпеку Bitcoin, щоб забезпечити надійність усіх транзакцій, так само, як у мережі Bitcoin.

Вавилонський рівень: В основі Babylon лежить рівень Babylon, спеціальний блокчейн, який з'єднує Bitcoin з різними ланцюгами 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
• Перетворення типу: Перевірте, чи правильне перетворення типу та чи не втрачається важлива інформація під час процесу конвертування
• Помилка індексу масиву: перевірте, чи доступ до елемента за межами масиву
• Уразливість десеріалізації: перевірте, чи немає проблем під час процесу десеріалізації
• Безпека функціональної реалізації: перевірте, чи існують ризики безпеки в кожній реалізації інтерфейсу RPC і чи сумісна вона з функцією інтерфейсу RPC.
• Може бути розроблено для відповідності
• Чи мають розумні налаштування дозволів чутливого інтерфейсу RPC: Перевірте налаштування доступу до чутливого інтерфейсу RPC
• Механізм зашифрованої передачі: Перевірте, чи використовується зашифрований протокол передачі, такий як TLS, тощо.
• Перетворення формату даних запиту: Перевірте процес розбору формату даних запиту
• Атака розблокування гаманця: Коли вузол розблоковує свій гаманець, RPC просить його вкрасти кошти.
• Традиційна веб-безпека: перевірте наступні вразливості: міжсайтовий скриптинг (XSS) / внедрення шаблону
• Вразливості компонентів сторонніх постачальників / Забруднення параметрів HTTP / Внедрення SQL / Впровадження сутності XXE десеріалізації
• уразливості / SSRF уразливості / кодова ін'єкція / локальна включеність файлів / віддалена включеність файлів / ін'єкція командного виконання та інші традиційні уразливості
• Механізм аутентифікації та ідентифікації ідентифікації вузла мережі: Перевірте, чи є механізм ідентифікації вузла, та чи можна обійти механізм ідентифікації вузла.
• Забруднення таблиці маршрутизації: перевірте, чи можна випадково вставити або перезаписати дані таблиці маршрутизації
• Алгоритм виявлення вузлів: перевірте, чи є алгоритм виявлення вузлів збалансованим і непередбачуваним, наприклад, алгоритм незбалансованої відстані та інші проблеми
• Аудит зайнятості номеру з'єднання: Перевірте, чи є обмеження та управління кількістю вузлів п2п мережі розумними
• Атака затемнення: оцініть вартість і шкоду атаки затемнення та надайте кількісний аналіз, якщо це необхідно
• Атака Sybil: оцініть механізм консенсусу голосування та проаналізуйте стратегію перевірки кваліфікації голосування
• Атака прослуховування: Перевірка протоколів зв'язку на витоки конфіденційної інформації
• Атака інопланетян: оцініть, чи може вузол ідентифікувати схожі вузли ланцюга
• Захоплення часу: перевірка механізму обчислення мережевого часу вузла
• Атака на вичерпання пам'яті: перевірка місць з великим споживанням пам'яті
• Атака виснаження жорсткого диска: перевірте, де зберігаються великі файли
• Атака на тиск сокету: перевірте політику обмеження кількості з'єднань
• Атака на вичерпання ручок ядра: Перевірте обмеження на створення ручок ядра, таких як ручки файлів тощо.
• Постійні витоки пам'яті: перевірте на витоки пам'яті
• Безпека хеш-алгоритму: Перевірка стійкості до зіткнень хеш-алгоритму
• Безпека алгоритму цифрового підпису: перевірка безпеки алгоритму підпису та безпеки реалізації алгоритму
• Безпека алгоритму шифрування: Перевірка безпеки алгоритму шифрування, безпека реалізації алгоритму
• Безпека генератора випадкових чисел: перевірка надійності критичних алгоритмів генерації випадкових чисел
• Безпека реалізації BFT: Оцінка безпеки реалізації алгоритму BFT
• Правила вибору вілки: Перевірте правила вибору вілки, щоб забезпечити безпеку
• Виявлення централізації: визначте, чи існує надмірна централізація в дизайні системи
• Стимулюючий аудит: оцініть вплив стимулів на безпеку
• Атака подвійних витрат: перевірте, чи може консенсус захиститися від атаки подвійних витрат
• Аудит MEV-атаки: перевірте вплив MEV вузлів упаковки блоків на справедливість ланцюга
• Аудит процесу синхронізації блоків: перевірте проблеми з безпекою під час процесу синхронізації
• Аудит процесу аналізу блокового формату: перевірте проблеми безпеки в процесі аналізу формату, наприклад помилки аналізу, що призводять до аварійного завершення роботи
• Аудит процесу генерації блоків: Перевірка проблем безпеки під час процесу генерації блоків, включаючи розумність методу побудови кореня дерева Меркла
• Перевірка процесу перевірки блоку: Перевірте, чи достатні елементи вмісту підпису блоку та логіка перевірки
• Аудит логіки підтвердження блоку: Перевірити, чи є розумним алгоритм підтвердження блоку та його реалізація
• Зіткнення хешів блоків: перевірте метод побудови хеш-колізії блоків і чи обґрунтоване поводження з цим зіткненням.
• Обмеження ресурсів обробки блоків: Перевірте, чи є обмеження ресурсів, такі як пул сирітських блоків, обчислення підтвердження, адресація жорсткого диска та інші, розумними.
• Аудит процесу синхронізації транзакцій: перевірте проблеми з безпекою під час процесу синхронізації
• Колізія хешів транзакцій: перевірка методу побудови колізії хешів транзакцій та обробки колізії
• Розбір формату транзакції: Перевірка проблем безпеки під час процесу розбору формату, таких як помилки розбору, що призводять до збоїв
• Перевірка законності транзакції: Перевірка, чи є достатньо кожного типу елементів вмісту підпису транзакції та логіки перевірки
• Обмеження ресурсів обробки транзакцій: Перевірте, чи є ресурсні обмеження, такі як пули транзакцій, обчислення перевірки, адресація жорсткого диска тощо, розумними.
• Атака на модифікацію транзакцій: Чи може транзакція змінювати внутрішні поля (такі як ScriptSig) для зміни хешу транзакції без впливу на її дійсність?
• Аудит атаки повторного відтворення транзакцій: перевірка системного виявлення повторного відтворення транзакцій
• Перевірка байт-коду контракту: перевірте проблеми безпеки процесу перевірки контракту віртуальною машиною, такі як цілочисельне переповнення, нескінченний цикл тощо.
• Виконання байт-коду контракту: перевірте проблеми безпеки в процесі виконання байт-коду віртуальної машини, такі як цілочисельне переповнення, нескінченний цикл тощо.
• Газова модель: Перевірте, чи плата за обробку, що відповідає кожній атомарній операції обробки транзакцій/виконання контракту, пропорційна споживанню ресурсів
• Цілісність реєстрації: Перевірте, чи зареєстровано ключову інформацію
• Безпека записів журналу: перевірте, чи немає проблем із безпекою, спричинених неправильним поводженням під час обробки журналу, наприклад переповнення цілих чисел тощо.
• Журнал містить приватну інформацію: перевірте, чи містить журнал особисту інформацію, наприклад ключі
• Зберігання журналу: перевірте, чи не записує журнал занадто багато вмісту, що спричиняє споживання ресурсів вузла
• Безпека ланцюга постачання вузла коду: перевірте відомі проблеми всіх сторонніх бібліотек, компонентів та відповідних версій фреймворку громадського ланцюжку

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

Застереження:

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