Вагомість масштабованості Блокчейн: Баланс Polkadot та Web3

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

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

Виклики, що виникають у дизайні розширення Polkadot

Баланс гнучкості та децентралізації

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

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

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

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

Оскільки протокол подачі блоків до релейного ланцюга є бездозвільним і бездостовірним, будь-хто може подати блок для перевірки на будь-якому ядрі, що призначене для 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 слід перевіряти Блок. Валідаор порівнює цей індекс з тим, за який він відповідає; якщо вони не збігаються, цей Блок буде відкинуто.

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

Безпека

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

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

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

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

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

Складність

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

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

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

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

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

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

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

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

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

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

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

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

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

Солана

Solana не використовує архітектуру шардінгу Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарової високопродуктивної архітектури, спираючись на історичне підтвердження (PoH), паралельну обробку CPU та механізм консенсусу на основі лідера, теоретична 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, а не в безпосередньому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблему, а просто передає її на верхній рівень стеку.

Оптимістичний Rollup

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

ZK Rollup

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

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

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

Висновок

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

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

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