Постійне забезпечення цілісності блокчейн-протоколу через відкриті примітиви та баг-банті @immunefi, @commonwarexyz, @arbitrum Цілісність блокчейн-протоколу не є властивістю, яка може бути повністю забезпечена одноразовим перевірним або оцінкою в певний момент часу, а має бути зрозумілою як характеристика, яка повинна підтримуватися та перевірятися постійно з плином часу. Сучасні блокчейн-системи мають структуру, в якій багато компонентів взаємодіють між собою, особливо в рішеннях масштабування, таких як ролапи, де середовище виконання, мости, сіквенсори, механізми перевірки тісно пов'язані між собою. У такому середовищі навіть найбільш досконало написаний код може мати нові вразливості через оновлення, зміни конфігурації або зміни економічних стимулів. Тому одноразові аудити мають сенс для перевірки стану коду в певний момент, але мають чіткі обмеження в забезпеченні довгострокової цілісності протоколу. Реальний випадок з Arbitrum добре ілюструє цю особливість. Продуктовий стек Arbitrum включає середовище виконання Nitro, контракти однокрокового доведення, інфраструктуру мостів, які відповідальні за перенесення активів між шарами, логіку сіквенсора, яка визначає порядок транзакцій, та механізм доказів обману. Ці компоненти не існують окремо, а взаємодіють, формуючи єдину систему. Оновлення ArbOS 31 Bianca, виконане в березні 2024 року, вплинуло одночасно на Arbitrum One та Nova, що демонструє, як одне оновлення може викликати ланцюгові зміни в різних компонентах мережі. Крім того, Arbitrum виконував шість основних оновлень ArbOS між 2024 і 2026 роками, підтримуючи швидкий цикл розробки, коли код, розгорнутий в тестовій мережі, вводиться в основну мережу за відносно короткий час. Така швидкість створює середовище, яке важко підтримувати традиційними процедурами аудиту, що може призводити до використання коду, який ще не пройшов аудиту, в реальному середовищі. Крім того, вже багаторазово підтверджено, що тільки перевірка коду недостатньо для передбачення атак, які виникають в реальній мережі. Хак моста Wormhole, який відбувся в лютому 2022 року, і вразливість моста Polygon Plasma в грудні 2021 року виникли в коді, який пройшов аудит, а атакувальники знайшли динамічні шляхи атаки, використовуючи економічні стимули, а не самі вади коду. Це чітко демонструє, що цілісність протоколу не обмежується лише синтаксичною правильністю коду, а є багатовимірним поняттям, яке включає економічну структуру, спосіб ведення операцій та процедури гіпернанції. У цьому контексті повторне використання відкритих блокчейн-примітивів набуває місця як одного з елементів стратегії безпеки. Підхід так званого "анти-фреймворку", запропонований Commonware, передбачає розподіл основних функцій мережі, консенсусу, криптографії, зберігання, тестування на модульних примітивах, замість створення єдиного великого стеку. Ці примітиви реалізовані як бібліотеки на Rust і включають підтверджену P2P-комунікацію, алгоритми консенсусу, що допускають помилки типу Бізантія, підписи та генерацію випадкових чисел, абстрактні інтерфейси зберігання, а також компоненти середовища виконання для детермінованих симуляцій. Кожен примітив класифікується за рівнем стабільності на альфа, бета, гамма, дельта, епсилон, і ці класи визначаються на основі обсягу тестування та досвіду використання в реальних умовах. Найбільшою перевагою повторного використання примітивів є зменшення ризиків реалізації. Наприклад, використання вже перевіреного математично примітива консенсусу замість його власної реалізації дозволяє зменшити кількість помилок, які часто повторюються. Крім того, примітиви високого рівня стабільності мають чітко визначені цілі для аудиту та баг-банті, що дозволяє зосередити ресурси безпеки на ключових логіках. Детерміноване середовище симуляції, яке надає Commonware Runtime, дозволяє відтворювати умови мережі та виконувати регресійні тести між версіями, що є важливим для підтримки цілісності під час оновлень. Однак такий підхід несе з собою інші ризики. Якщо кілька протоколів використовують однакові примітиви, це може призвести до структурної концентрації, коли одна вразливість вплине на всю екосистему. Для зменшення цього ризику Commonware ввів систему класифікації стабільності, чітко визначив інтерфейси та стимулює конкуруючі реалізації для однакових інтерфейсів.Незважаючи на це, неможливо заперечити, що ризики можуть зосереджуватися на рівні проектування, що зробило постійне виявлення вразливостей обов'язковим елементом. У роллап-середовищі поверхня, де вимагається цілісність протоколу, дуже велика. У випадку Arbitrum контракти Nitro Prover можуть містити математичні помилки або проблеми з розрахунком газу, а контракти-мости, що з'єднують L1 і L2, несуть критичні ризики, такі як відбір коштів або блокування виведення. Логіка сіквенсера передбачає можливість отримання необґрунтованих вигод через цензуру або перестановку транзакцій, а механізм губернанса також може бути вразливим до атак, таких як маніпуляції з пропозиціями або обхід таймлока. Крім того, з операційної точки зору фактори, такі як зупинка сіквенсера, невдача в управлінні ключами або відсутність моніторингу, безпосередньо впливають на цілісність. Для постійного виявлення таких різноманітних ризиків програма баг-бонусів відіграє важливу роль. Програма баг-бонусів, яку проводить Immunefi, класифікує серйозність за рівнем впливу, а для критичних вразливостей, таких як відбір коштів або зупинка мережі, надає певний відсоток від ризикованих активів як винагороду. Цей підхід вбудовано так, щоб винагорода зростала разом із масштабом мережі, довгостроково вирівнюючи мотивацію дослідників і протоколу. Крім того, через процедуру відповідальної публікації, яка регулює момент публікації, вразливості оголошуються після виправлення, щоб мінімізувати збитки для користувачів. Незважаючи на це, баг-бонус не охоплює всі ризики. Економічні атаки, такі як вилучення MEV або помилки в проектуванні стимулів, сценарії, що використовують губернанс-процедури, а також операційні помилки часто залишаються поза межами. Насправді, інцидент Wormhole демонструє, що навіть при видачі великих винагород, сама подія не була повністю запобіжена. Це вказує на те, що, хоча баг-бонус є важливим примітивом безпеки, він не є самодостатньою відповіддю. Об'єднання відкритих джерел і баг-бонусів формує один життєвий цикл системи забезпечення цілісності. Примітиви зменшують можливість помилок на етапі реалізації, і з підвищенням стабільності вони стають предметом зовнішньої перевірки та оцінки з винагородою. Обсяг баг-бонусів Arbitrum зараз обмежений поточною робочою версією, що стимулює дослідників зосередитися на коді, де дійсно існують ризики. Якщо вразливість виявлено, відповідний випадок відображається в симуляційних тестах, щоб уникнути повторення проблеми в наступних версіях. У цьому процесі також необхідно чітко визначити межі відповідальності. Втримувач примітивів має забезпечити точність і сумісність в межах інтерфейсу, а інтегратор несе відповідальність за безпечне поєднання та експлуатацію в реальному середовищі. Відкриті ліцензії обмежують юридичну відповідальність, але реальне забезпечення цілісності залежить від цієї розподіленої відповідальності і співпраці. У процесі регулювання моменту публікації вразливостей і видачі патчів також вимагається співпраця між кількома проектами. Процес губернансу і оновлень також є ключовим елементом збереження цілісності. Arbitrum керує ризиками оновлень через таймлока конституційних пропозиць, період виклику L1-повідомлень, надзвичайну владу безпекового комітету та поетапну процедуру розгортання через тестову мережу. Ці процедури можна розглядати як спробу зберегти баланс між швидким відповіддю і децентралізацією. У кінцевому підсумку, відкриті джерела блокчейн-примітиви і постійні баг-бонуси дозволяють підходити до цілісності протоколу не як до одноразової сертифікації, а як до постійного процесу. Примітиви зменшують повторні помилки реалізації, а баг-бонуси стимулюють постійну зовнішню перевірку через економічні стимули. Операційний досвід Arbitrum демонструє, як така комбінація працює на реальній великомасштабній мережі, чітко показуючи, що цілісність — це не фіксований стан, а властивість, яку потрібно постійно перевіряти і підтримувати. $ARB $ETH $XRP $POL