Вибір розширюваності Блокчейн: інноваційний шлях Polkadot

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

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

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

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

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

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

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

Роллап може досягти вертикального масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість була введена функцією "еластичного масштабування" (Elastic Scaling). У процесі проектування було виявлено, що оскільки валідація блоків роллапу не фіксується на певному ядрі, це може вплинути на його еластичність.

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

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

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

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

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

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

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

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

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

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

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

Безпека

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

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

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

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

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

Складність

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

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

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

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

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

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

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

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

В майбутньому Polkadot також підтримуватиме (off-chain messaging), де релейний ланцюг виступатиме у ролі контрольного рівня, а не рівня даних. Це оновлення дозволить підвищити можливості комунікації між 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, а не в безпосередньому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблему, а просто передає її на верхній рівень стеку.

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

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

ZK Rollup

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

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

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

Висновок

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

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

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