Інженери Pipe Network хочуть поділитися своїми дослідженнями та інсайтами щодо блокчейну другого рівня (Layer 2).
У децентралізованих системах балансування масштабованості, безпеки та продуктивності є складним викликом, особливо коли мова йде про обробку змінюваних даних у режимі реального часу. Одним із найбільш перспективних рішень для досягнення цього балансу є використання Merkle-ізованих операційних CRDT (конфліктно-вільних реплікованих типів даних), зокрема в середовищах другого рівня (L2), які не залежать від традиційних механізмів консенсусу або нативних токенів.
Але як можна вирішувати критичні проблеми, такі як атаки на відмову в обслуговуванні (DDoS) та спам транзакцій, якщо немає консенсусу та нативних токенів? Ці загрози зазвичай знижуються за допомогою таких механізмів, як стейкінг, комісії за транзакції або інші економічні стримування. У цій публікації ми глибше розглянемо, як Merkle-ізовані CRDT у поєднанні з архітектурою Solana Layer 1 можуть допомогти пом'якшити ці ризики, зберігаючи систему легкою та ефективною.
CRDT для масштабованості та змінюваності без консенсусу Як зазначалося раніше, CRDT дозволяють децентралізованим реплікам оновлювати дані незалежно та паралельно. Вони гарантують, що навіть у розподіленому середовищі всі репліки врешті-решт досягнуть єдиного стану, що усуває потребу в важких механізмах консенсусу.
Операційні CRDT: Ці CRDT передають операції (такі як оновлення даних) між репліками. Операції зливаються детерміновано, тому потреби в глобальному упорядкуванні немає, що знижує навантаження та підвищує продуктивність. Це гарантує швидке оновлення без вузьких місць.
Без консенсусу: Оскільки CRDT природно вирішують конфлікти через детерміноване злиття операцій, немає потреби в протоколах консенсусу, таких як ті, що використовуються на блокчейнах першого рівня (наприклад, Proof of Stake). Це суттєво знижує обчислювальні та економічні витрати на підтримку L2, що дозволяє створювати швидші, масштабованіші системи.
Однак, хоча CRDT вирішують проблему децентралізованої змінюваності, вони не надають захисту від зловмисних дій, таких як DDoS або спам-атаки. Для цього ми звертаємось до Merkle-дерев та Solana Layer 1.
Merkle-дерева: криптографічна верифікація та докази Merkle-дерева забезпечують криптографічні гарантії, які можуть забезпечити цілісність даних і захистити верифікацію стану навіть у децентралізованому середовищі.
Merkle-ізовані операції: Кожна операція, яка змінює стан CRDT, хешується та включається в Merkle-дерево. Це означає, що можна створити компактний криптографічний доказ для будь-якої даної операції, що дозволяє всій мережі перевіряти, чи є певна операція дійсною і чи є частиною загального набору даних.
Анкоринг на Solana: Без механізму консенсусу на L2 періодичний анкоринг коренів Merkle на ланцюзі Solana першого рівня може служити безпечним журналом аудиту. Це забезпечує, що операції, виконані на L2, є дійсними та криптографічно перевіреними без необхідності консенсусу для кожної окремої операції.
Хоча Merkle-дерева гарантують, що включені лише дійсні операції, вони не адресують безпосередньо такі проблеми, як атаки DDoS або спам-транзакції. Однак, завдяки періодичному анкорингу на Solana L1, L2 може використовувати безпеку та високу пропускну здатність Solana для додаткового захисту.
Захист від DDoS та спам-транзакцій у безтокеновому L2 Одним із головних викликів при відмові від консенсусу та нативних токенів є потенційна вразливість до DDoS-атак та спаму транзакцій. Ці загрози можуть перевантажити систему великою кількістю операцій, що може спричинити зниження продуктивності або навіть зупинку.
Ось як ці ризики можна зменшити:
Обмеження швидкості на рівні вузлів Кожен вузол, який бере участь у L2, може впроваджувати обмеження швидкості для запобігання спаму або DDoS-атакам. Обмежуючи кількість операцій, які можна обробити за певний період часу, вузли можуть забезпечити, що жоден користувач чи група користувачів не зможе переповнити систему надмірною кількістю операцій. Це може бути зроблено через кілька підходів:
Обмеження на основі IP: Вузли можуть відстежувати кількість операцій, поданих з кожної IP-адреси, і обмежувати відправку після досягнення певного порогу.
Обмеження на основі геолокації: Крім обмежень на основі IP, вузли можуть застосовувати обмеження на основі географічних регіонів для запобігання регіональним атакам чи концентрації операцій.
Merkle-докази для дійсних операцій У поєднанні з обмеженням швидкості, Merkle-докази можна використовувати для відсікання недійсних або спам-операцій ще до їх надходження в мережу. Кожна операція криптографічно хешується та включається в Merkle-дерево, і лише операції з дійсними доказами розповсюджуються серед вузлів.
Періодичне створення контрольних точок та фінальність на Solana Layer 1 Для додаткового захисту L2 від зловмисних дій періодичне створення контрольних точок на Solana Layer 1 може слугувати “шаром фінальності” для операцій. Анкоринг коренів Merkle на високопродуктивному L1 Solana створює систему, у якій L2 потрібно взаємодіяти з L1 лише зрідка, але ці взаємодії гарантують цілісність операцій у разі спаму чи DDoS-атак.
Відсутність нативного токена: легкі операції без комісій Однією з головних переваг цього дизайну є відсутність нативного токена на L2. Більшість L2 використовують нативні токени для оплати комісій та стимулювання операторів вузлів. Проте, комбінуючи Merkle-ізовані CRDT з періодичним анкорингом на Solana, можна повністю уникнути системи комісій на основі токенів.
Відсутність комісій за транзакції на L2: Оскільки операції обробляються репліками CRDT і верифікація забезпечується через Merkle-докази, немає потреби стягувати комісію з користувачів за кожну операцію.