Баланс масштабованості, безпеки та Децентралізації: технічний вибір Polkadot

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

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

Polkadot як важливий каталізатор масштабованості Web3, чи зробив він деякі жертви в досягненні високої пропускної здатності та низької затримки? Чи зробила його модель rollup поступки в децентралізації, безпеці або мережевій інтероперабельності?

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

Виклики, з якими стикається дизайн розширення Polkadot

Баланс еластичності та Децентралізації

Архітектура Polkadot залежить від мережі валідаторів та централізованого релейного ланцюга. Чи може це в певних аспектах ввести ризики централізації? Чи може виникнути єдина точка відмови або контролю, що вплине на його децентралізовані характеристики?

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

Торгівля вертикальним масштабуванням

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

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

Метою Polkadot є підтримка гнучкості rollup та ефективного використання ресурсів релейного ланцюга без впливу на ключові характеристики системи.

Чи варто довіряти Sequencer?

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

Однак, у концепції дизайну Polkadot ми не можемо робити жодних довірчих припущень щодо секвенсора, оскільки потрібно підтримувати характеристики системи "без довіри" та "без дозволу". Будь-хто повинен мати можливість використовувати протокол колаторів для подачі запитів на зміни стану роллапу.

Polkadot: безкомпромісне рішення

Остаточне рішення Polkadot: повністю покласти вирішення проблеми на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому в результатах потрібно чітко вказати, на якому ядрі Polkadot має відбуватися верифікація.

Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати зміни стану rollup у процесі доступності та забезпечувати правильність розподілу core через економічний протокол ELVES.

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

Результат перевірки містить core selector, який вказує, на якому core слід перевіряти блок. Валідаор порівнює цей індекс з тим, за який він відповідає; якщо вони не збігаються, блок буде відкинуто.

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

Безпека

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

Завдяки протоколу ELVES, Polkadot повністю розширює свою безпеку на всі rollup, перевіряючи всі обчислення на core, не накладаючи жодних обмежень чи припущень щодо кількості використаних ядер.

Отже, rollup Polkadot може досягти справжньої масштабованості без жертви безпекою.

Універсальність

Гнучке масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання обчислень з Тюрінговою повнотою в середовищі WebAssembly, якщо одноразове виконання завершується протягом 2 секунд. Завдяки гнучкому масштабуванню, загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.

Складність

Вищий пропускна здатність і нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом у проектуванні систем.

Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати стабільний рівень безпеки. Вони також повинні відповідати частковим вимогам RFC103, щоб адаптуватися до різних сценаріїв використання.

Конкретна складність залежить від стратегії управління ресурсами rollup, яка може покладатися на змінні в мережі або поза мережею. Наприклад:

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

• Легка стратегія: моніторинг специфічного навантаження транзакцій у mempool вузла;

• Автоматизовані стратегії: попереднє викликування служби coretime через історичні дані та XCM інтерфейс для налаштування ресурсів.

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

Інтероперабельність

Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не вплине на пропускну здатність обміну повідомленнями.

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

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

Які компроміси зробили інші протоколи?

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

Солана

Solana не використовує архітектуру шардінгу Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарової архітектури з високою пропускною здатністю, спираючись на історичне підтвердження (PoH), паралельну обробку ЦП та механізм консенсусу на основі лідера, теоретичний TPS може досягати 65,000.

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

• На початку кожного епохи (приблизно кожні два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейкінгу;

• Чим більше стеґується, тим більше розподіляється. Наприклад, стеґування 1% валідатора призведе до отримання приблизно 1% шансів на створення блоку;

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

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

Solana, прагнучи до TPS, пожертвувала децентралізацією та стійкістю до атак, її коефіцієнт Накмото становить лише 20, що значно нижче за 172 Polkadot.

ТОН

TON стверджує, що TPS може досягати 104,715, але це число досягається в приватній тестовій мережі, з 256 вузлами, в ідеальних умовах мережі та апаратного забезпечення. А Polkadot вже досягла 128K TPS в децентралізованій публічній мережі.

У механізмі консенсусу TON існують проблеми з безпекою: особа вузлів перевірки шард може бути заздалегідь виявлена. У білому документі TON також чітко зазначено, що це може оптимізувати пропускну здатність, але також може бути використано зловмисниками. Через відсутність механізму "банкрутства азартних гравців" зловмисники можуть чекати, поки певний шард не буде повністю під їх контролем, або через DDoS-атаки блокувати чесних перевіряючих, що дозволяє їм змінювати стан.

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

Авала́нш

Avalanche використовує архітектуру основної мережі + підмережі для масштабування, основна мережа складається з X-Chain (перекази, ~4,500 TPS), C-Chain (смарт-контракти, ~100-200 TPS), P-Chain (управління валідаторами та підмережами).

Теоретичний TPS кожної підмережі може досягати ~5,000, подібно до концепції Polkadot: зменшити навантаження на окремий shard для досягнення масштабованості. Але Avalanche дозволяє валідаторам вільно вибирати участь у підмережах, і підмережі можуть встановлювати географічні, KYC та інші додаткові вимоги, жертвуючи децентралізацією та безпекою.

У Polkadot всі rollup ділять єдину систему безпеки; тоді як підмережі Avalanche не мають стандартних гарантій безпеки, частина з них може бути повністю централізованою. Якщо ви хочете підвищити безпеку, все ще потрібно йти на компроміси в продуктивності, і важко забезпечити визначені гарантії безпеки.

Ефіріум

Розширювальна стратегія Ethereum полягає в ставці на масштабованість рівня rollup, а не у вирішенні проблеми безпосередньо на базовому рівні. Цей підхід по суті не вирішує проблему, а просто передає її на верхній рівень стеку.

Оптимістичний роллап

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

ZK Rollup

Імплементація ZK rollup обмежена кількістю даних, які можуть оброблятися в одній транзакції. Обчислювальні вимоги для генерації нульових знань є надзвичайно високими, а механізм "вигравший все забирає" легко призводить до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує кількість транзакцій у кожній партії, що в умовах високого попиту може призвести до заторів у мережі, підвищення gas і вплинути на користувацький досвід.

В порівнянні, вартість ZK rollup з повною потужністю Тюрінга приблизно в 2x10^6 разів більша, ніж вартість основного криптоекономічного протоколу безпеки Polkadot.

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

Заключення

Кінець масштабованості не повинен бути компромісом.

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

У прагненні до впровадження більш масштабних застосувань сьогодні, "нульова довіра до розширюваності", яку дотримується Polkadot, можливо, є справжнім рішенням, яке зможе підтримати довгостроковий розвиток Web3.