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

Існує кілька різних типів рішень для масштабування Ethereum, кожен зі своїми власними компромісами та моделями безпеки, включаючи шарування рівня 1, канали стану рівня 2, Plasma, бічні ланцюги, Rollups та Validium. Оскільки технологія шарування повільно розвивається та складна в реалізації, а бічні ланцюги та Validium не можуть успадковувати безпеку та доступність даних від Ethereum. У підсумку, в екосистемі Ethereum зараз головним чином використовується рішення для масштабування Rollups.

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

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

На даний момент Rollups можуть бути реалізовані двома основними способами:

Оптимістичні ролапи: Використовуйте економічні стимули та теорію ігор для перевірки транзакцій, таких як Arbitrum, Base, OP, Blast, тощо.

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

рішення для масштабування Optimistic Rollups

Вступ

Optimistic Rollups - це спосіб масштабування Ethereum шляхом виведення обчислень та зберігання стану в офшор. Він виконує транзакції офшорно, але публікує дані транзакції на головну мережу у вигляді виклику даних або блобу.

Optimistic Rollups розгортають смарт-контракт на Ethereum під назвою Rollup contract, який керує статусом Rollup, відстежує баланси користувачів і обробляє депозити, зняття коштів і вирішення суперечок. Транзакції збираються та підсумовуються поза мережею секвенсором, а кілька транзакцій об'єднуються в блок Rollup, який містить зведений та криптографічний доказ нового стану рахунку (корінь Меркла). Потім секвенсер фіксує блок Rollup в основному ланцюжку, надаючи кореневі системи Меркла і calldata.

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

Як показано на наведеному нижче малюнку, період виклику більшості оптимістичних Rollups на сьогодні становить 7 днів, а найкоротший - 1 день.

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

Якщо пакет Rollup залишається непротестованим після періоду виклику (тобто всі транзакції виконані правильно), він вважається дійсним і прийнятим на Ethereum. Інші можуть продовжувати розширювати непідтверджені блоки Rollup, але слід зауважити, що результати транзакцій будуть скасовані, якщо транзакція виконана на підставі раніше опублікованої помилки.

На завершення користувач повинен подати запит на виведення коштів до контракту Rollup для виведення коштів з рівня 2 до рівня 1. Контракт перевірить, що у користувача є достатньо коштів на Rollup і відповідно оновить їх баланс на головному ланцюжку.

Ведучі мережі Layer2

1. Arbitrum

З екологічною будівництвом та роздачами, Arbitrum швидко став найактивнішою мережею в ETH Layer2, з TVL понад $2,7 мільярда. Після великої роздачі, команда Arbitrum запустила програму Arbitrum Orbit: що спонукає розробників будувати Layer3, використовуючи пов'язані з Arbitrum технології. Beosin завершив аудит безпеки ArbSwap, Arbipad для допомоги в розвитку безпеки екосистеми Arbitrum.

1. Оптимізм

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

1. База

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

1. Вибух

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

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

OP Stack, зрілий фреймворк для Оптимістичних Ролапів, в основному розбиває складний процес побудови ланцюгів оптимістичних ролапів на спрощений процес, надаючи повний набір програмних компонентів, інструментів та фреймворків. Тут ми беремо фреймворк Op stack як приклад для аналізу типової архітектури оптимізму ролапів.

● Виконавчий вузол: Op-geth - це розширений виконавчий клієнт для Ethereum, який обробляє специфічні для Layer2 функції, такі як отримання депозитів токенів від Layer1. Цей рівень визначає всі функції, відповідальні за виконання змін стану. Тут переходи стану спрацьовують на підставі введених даних від вузлів зведення (послідовностей та перевіряючих) через API двигуна.

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

● Доказ шахрайства: Cannon є оновленою версією Geth і відповідає за запуск EVM на етапі виявлення та доказу шахрайства. По суті, це механізм суперечок у ланцюжку, який координує свої дії з секвенторами та валідаторами через API для підтвердження хибних транзакцій.

● Пакетний коміт: Послідовники пакетно обробляють всі оброблені транзакції одночасно, перевіряються верифікаторами, і Послідовники надсилають пакетно оброблені транзакції на Layer1.

● Мостові контракти: Розгорнуті на Ethereum та Layer2, що дозволяє користувачам передавати повідомлення та переказувати активи між Layer1 та Layer2.

Згідно з технічною архітектурою Оптимістичного Rollup, важливо забезпечити безпеку активів користувачів під час переміщення між L1 та L2. Нижче наведено, як користувачі можуть отримати доступ до активів між цими двома рівнями та як система зберігає цілісність та безпеку таких транзакцій.

● Перенесення активів до Rollup: Користувачі вносять кошти на контракт мосту ланцюга Rollup на Layer1. Контракт мосту ланцюга передає транзакцію на Layer2, де виготовляється рівна кількість активів і відправляється на адресу, вибрану користувачем в оптимістичному Rollup.

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

● Зняття активів з Rollup: через механізм доказу шахрайства зняття коштів з Optimistic Rollup на Ethereum є більш складним. Якщо користувач ініціює транзакцію з рівня 2 на рівень 1 для зняття коштів, управління якими здійснюється на рівні 1, вони повинні зачекати до завершення періоду виклику, який, як правило, триває приблизно 7 днів.

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

Щоб не чекати тиждень, перш ніж виводити гроші з Ethereum, користувачі Optimistic Rollup можуть запросити аванс у постачальника ліквідності (LP), який бере на себе право власності на незавершені зняття коштів і виплачує користувачеві кошти на рівні 1 в обмін на комісію. Постачальники ліквідності можуть перевірити обґрунтованість запитів користувачів на виведення коштів, самостійно перевіривши ончейн-дані, перш ніж переказувати кошти. Таким чином, вони можуть гарантувати, що транзакція в кінцевому підсумку буде підтверджена, досягнувши впевненості в довірі.

Перевірка елементів

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

Крім того, через його особливу природу, Optimistic Rollup потребує ряду додаткових аудитів:

● Доказ перевірки доступності даних: Забезпечити доступність даних транзакції Layer2 на Layer1, щоб запобігти втраті даних.

● Механізм синхронізації даних: Перевірте, чи є механізм синхронізації даних між Layer1 та Layer2 надійним та може впоратися з надзвичайними ситуаціями, такими як розділення мережі.

● Договір профилактики шахрайства: Перевірте, що договір профилактики шахрайства виконаний правильно.

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

● Процес надання доказів шахрайства: Перевірте, що процес надання доказів шахрайства є безпечним.

● Процес депозиту та виведення: Перевірте процес депозиту та виведення з Layer1 на Layer2 та з Layer2 на Layer1, щоб забезпечити безпеку процесу.

● Виготовлення та знищення активів: Перевірте логіку виготовлення та знищення активу на Layer2, щоб забезпечити правильну відповідність з активом Layer1.

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

Zero-Knowledge Rollups

Вступ

Zero-Knowledge (ZK) Rollup - це Layer2 на основі доказу без відома. Він головним чином виконує складні обчислення та генерацію доказу поза ланцюжком, перевіряє докази на ланцюжку та зберігає частину даних, щоб забезпечити доступність даних.

ZK Rollup — це «гібридне рішення для масштабування», яке є офчейн-протоколом, який працює незалежно, але отримує безпеку від Ethereum. Зокрема, мережа Ethereum забезпечує дійсність оновлень статусу ZK Rollups і гарантує доступність фонових даних щоразу, коли оновлюється статус зведення. Стан Rollup підтримується смарт-контрактами, розгорнутими в мережі Ethereum. Щоб оновити цей статус, вузол ZK Rollups має надати підтвердження валідності для перевірки. Доказ дійсності - це криптографічна гарантія того, що запропонована зміна стану дійсно є результатом виконання даної партії транзакцій. Це означає, що ZK Rollups потрібно лише надати підтвердження дійсності, щоб завершити транзакції в Ethereum, без необхідності публікувати всі дані про транзакції.

Немає затримок у переказі коштів з ZK Rollups на Ethereum, оскільки транзакція виходу виконується після того, як контракт ZK Rollups перевірив докази валідності. Натомість зняття коштів з Optimistic Rollups спричиняє затримки, оскільки будь-хто може використовувати докази шахрайства для оскарження транзакції виходу.

Провідні мережі Layer2

1. zkSync

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

1. StarkNet

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

1. Прокрутка

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

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

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

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

Контракт Rollup відповідає за забезпечення доступності даних для транзакцій Rollup, перевірку доказів валідності zkEVM та дозволяє користувачам переміщувати активи між Ethereum та Rollup. Він отримує кореневий стан другого рівня та блок від колектора, кореневий стан зберігається в Ethereum, а дані блоку другого рівня зберігаються як calldata Ethereum.

Місткові контракти розгорнуті на Ethereum та Layer2, що дозволяє користувачам передавати повідомлення та переміщати активи між Layer1 та Layer2.

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

● Координатор: Координатор повідомляється, коли коллатор генерує новий блок і отримує слід виконання цього блоку від коллатора. Слід виконання потім направляється до випадково вибраного Роллера в мережі Роллер, який генерує доказ валідності.

● Relayer: Повторювач слідкує за контрактами Rollup та контрактами мосту, розгорнутими на Ethereum та Layer2. Основні обов'язки: 1) Відслідковування доступності даних та перевірка блоків Layer2 шляхом моніторингу контрактів Rollup; 2) Слідкування за подіями депозиту та зняття коштів Ethereum та залученням мосту Layer2 та передача повідомлень на інший кінець.

● Roller Network: Roller у мережі Roller діє як виконавець і відповідає за створення доказів дійсності ZK Rollup. Трасування виконання блоку спочатку отримується від координатора, перетворюється на свідка схеми, потім для кожного zkevm генерується доказ за допомогою апаратного прискорення, і, нарешті, агрегація доказів використовується для aggreGate кількох доказів в один доказ.

В рамках технічної архітектури ZK Rollups важливо забезпечити безпеку активів користувача під час переказу між L1 та L2. Нижче наведено деталі того, як користувачі можуть отримати доступ до активів між цими двома рівнями та як система забезпечує цілісність та безпеку цих транзакцій.

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

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

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

● Виведення активів із Rollup: користувач ініціює транзакцію виходу, відправляючи активи у своєму Rollup на вказаний акаунт для знищення. Якщо оператор додає транзакцію до наступної партії, користувач може подати запит на виведення коштів до ончейн-контракту. Запити на виведення коштів включають:

1. Доказ Меркла, який підтверджує, що транзакція користувача додається до знищеного рахунку в пакеті транзакцій

2. Дані про транзакції

3. Пакетний корінь

4. Мережева адреса рівня 1 для отримання внесених коштів

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

Елементи аудиту

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

Крім того, через свою особливу природу, ZK Rollup вимагає проведення додаткових перевірок:

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

● Безпека схеми: Перевірте можливі вразливості у дизайні та реалізації схеми, головним чином, включаючи наступне:

1. Необмежені схеми

2. Перевантажені схеми

3. Недетерміновані схеми

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

5. Невідповідність довжин бітів

6. Невикористані громадські вхідні дані оптимізовані

7. Замерзле серце: Ковальня нуль-знанієвих доказів

8. Витік довіреної налаштування

9. Призначено, але не обмежено

10. Ненадійне використання компонентів

11. Змінна точність

● Генерація та перевірка доказів: Перегляньте процес генерації та перевірки доказів, щоб переконатися, що він ефективний та безпечний.

● Доказ відомостей про доступність: Забезпечити доступність даних транзакцій Layer2 на Layer1 для запобігання втраті даних.

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

● Процес депозиту та виведення: Перевірте процес депозиту та виведення з Layer1 на Layer2 та з Layer2 на Layer1, щоб переконатися, що процес є безпечним.

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

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

Додаток

Аудит пунктів блокчейну та Layer2:

● Переповнення цілого числа: Перевіряйте переповнення та недостачу цілих чисел

● Перевірка циклу: Перевірте цикл програми, щоб переконатися, що умова є розумною

● Нескінченний рекурсивний виклик: перевірте, чи обґрунтована умова виходу рекурсивного виклику програми

● Умова змагання: перевіряє доступ до спільних ресурсів у одночасному стані

● Виключення аварійного завершення: перевірте код, який викликає виключення та призводить до активного виходу програми

● Уразливість ділення на 0: Перевірте, чи є випадки ділення на 0

● Перетворення типів: перевірте, чи правильне перетворення типів і чи не втрачено важливу інформацію під час перетворення

● Вихід за межі масиву: Перевіряє доступ до елементів, які знаходяться поза межами масиву

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

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

● Чи розумні налаштування дозволів для чутливого RPC-інтерфейсу: Перевірте налаштування доступу до чутливого RPC-інтерфейсу

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

● Аналіз форматування даних запиту: перевіряє процес форматування даних запиту

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

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

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

● Забруднення таблиці маршрутизації: перевірте, чи можна довільно вставити або перезаписати таблицю маршрутизації

● Алгоритм виявлення вузлів: перевірте, чи є алгоритм виявлення вузлів збалансованим і непередбачуваним, наприклад, алгоритм відстані незбалансований

● Аудит використання підключення: перевірка на розумність обмеження та управління кількістю вузлів, підключених до p2p-мережі.

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

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

● Атака перехоплення: перевірка того, чи розкривається приватність комунікаційного протоколу

● Інопланетна атака: оцінює, чи може вузол розпізнавати однотипний вузол ланцюга

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

● Атака виснаження пам'яті: Перевірка великого споживання пам'яті

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

● Атака тиску на розетку: перевірте політику обмеження кількості посилань

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

● Постійні витоки пам'яті: Перевірте на витоки пам'яті

● Безпека хеш-алгоритму: перевірте стійкість до колізій хеш-алгоритму

● Безпека алгоритму цифрового підпису: Перевірка безпеки алгоритму підпису та його реалізації

● Безпека алгоритму шифрування: Перевірте безпеку алгоритму шифрування та його реалізацію

● Безпека генератора випадкових чисел: Перевірте, чи є алгоритм генерації випадкових чисел ключа розумним

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

● Правила вибору вілки: Перевірте правила вибору вілки, щоб забезпечити безпеку

● Тест на ступінь централізації: визначте, чи є надмірно централізований дизайн у дизайні системи

● Аудит стимулів: Оцінка впливу стимулів на безпеку

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

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

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

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

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

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

● Перевірка логіки перевірки блоку: Перевірте, чи розумний алгоритм перевірки блоку та його реалізація

● Колізія хеш-блоку: Перевірте, як будується колізія хеш-блоку та чи обробляється колізія належним чином

● Обмеження ресурсів обробки блоків: перевірте, чи обґрунтовані пули блоків-сиріт, перевірочні обчислення, адресація жорсткого диска та інші обмеження ресурсів

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

● Зіткнення хешів транзакцій: Дослідіть, як будуються зіткнення хешів транзакцій і як вони обробляються

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

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

● Ліміти ресурсів обробки транзакцій: перевірте, чи обґрунтовані обмеження ресурсів, такі як пули транзакцій, обчислення перевірки та адресація жорсткого диска

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

● Аудит атаки повторного відтворення транзакції: Перевіряє систему виявлення повторного відтворення транзакції

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

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

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

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

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

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

● Зберігання журналів: перевірте, чи не записано в журнали надмірний вміст, який споживає ресурси вузла

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

Відмова від відповідальності:

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