Вибір між Polkadot та Web3: торгівля масштабованістю

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

безпека

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

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

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

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

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

Складність

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

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

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

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

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

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

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

взаємодія

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

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

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

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

Як відомо, підвищення продуктивності часто досягається ціною централізації та безпеки. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти 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: зменшити навантаження на окремий шард для досягнення масштабованості. Але Avalanche дозволяє валідаторам вільно вибирати участь у підмережі, і підмережі можуть встановлювати додаткові вимоги, такі як географічні, KYC тощо, жертвуючи децентралізацією та безпекою.

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

Ефіріум

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

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

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

ZK Rollup

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

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

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

Заключення

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

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

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