Вагомість розширювальної здатності Web3: рішення Polkadot

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Polkadot: Непоступливе рішення

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

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

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

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

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

безпека

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

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

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

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

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

складність

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

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

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

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

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

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

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

взаємодія

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

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

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

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

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

деяка публічна блокчейн A

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

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

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

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

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

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

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

певна публічна блокчейн B

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

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

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

Деяка публічна мережа C

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

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

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

Ефір

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

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

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

ZK Rollup

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

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

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

Висновок

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

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

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