Вибір розширюваності: компроміс між Polkadot та Web3

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

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

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

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

Баланс між гнучкістю та децентралізацією

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

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

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

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

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

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

Проблема довіри Sequencer

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

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

Polkadot: незламне рішення

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

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

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

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

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

безпека

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

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

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

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

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

складність

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

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

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

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

Хоча автоматизація є більш ефективною, витрати на реалізацію та тестування також суттєво зростають.

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

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

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

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

Зважування інших протоколів

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

Солана

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

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

• Кожен епоха( триває близько двох днів або 432 000 слотів) на початку, слоти розподіляються відповідно до обсягу стейку.
• Чим більше ви ставите, тим більше розподілу ви отримаєте. Наприклад, валідатор, який ставить 1%, отримає приблизно 1% шансів на створення блоку;
• Всі майнери заздалегідь оголошуються, що підвищує ризик цілеспрямованих DDoS-атак на мережу та частих збоїв.

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

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

ТОН

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, а не в прямому вирішенні проблем на базовому рівні. Такий підхід по суті не вирішує проблему, а передає її на верхній рівень стеку.

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

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

ZK Rollup

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

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

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

Висновок

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

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

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