Вагання масштабованості Блокчейн: дослідження Polkadot та екосистеми Web3
У сучасному світі Блокчейн, де постійно прагнуть до більшої ефективності, поступово виникає ключове питання: як досягти розширення продуктивності, не жертвуючи безпекою та еластичністю системи?
Це не лише виклик технічного рівня, а й глибокий вибір архітектурного дизайну. Особливо для екосистеми Web3, швидша система, якщо вона будується на основі жертви довіри та безпеки, часто не може підтримувати справжні стійкі інновації.
Як важливий рушій веб3-скалювання, чи зробив Polkadot певні жертви під час досягнення мети високої пропускної здатності та низької затримки? Чи робить його модель 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 core має бути виконана верифікація.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати перетворення стану rollup у процесі доступності та забезпечувати правильність розподілу core за допомогою економічного протоколу ELVES.
Перед записом даних rollup Блок в шарі доступності даних (DA) Polkadot група з приблизно 5 валідаторів спочатку перевіряє їх легітимність. Вони отримують кандидатські квитанції (candidate receipt) та докази дійсності (PoV), які містять rollup Блок та відповідні докази зберігання. Цю інформацію обробить функція верифікації паралельного ланцюга, яку повторно виконають валідатори на релейному ланцюзі.
Результат перевірки містить core selector, який вказує, на якому core слід перевірити Блок. Верифікатор порівнює цей індекс з тим, за який він відповідає; якщо вони не збігаються, цей блок буде відкинуто.
Цей механізм забезпечує безвідмовність системи, завжди зберігаючи властивості без довіри та без дозволу, уникаючи маніпуляцій з позицією верифікаторів з боку зловмисників, таких як сортувальник, та забезпечуючи стійкість навіть при використанні кількох core в rollup.
Безпека
У процесі прагнення до масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпека rollup забезпечується релейним ланцюгом, для підтримки життєздатності достатньо одного чесного сортувальника.
За допомогою протоколу ELVES, Polkadot розширює свою безпеку на всі rollup, перевіряючи всі обчислення на core, без необхідності накладати жодних обмежень чи припущень щодо кількості використаних core.
Отже, rollup Polkadot може досягти справжнього масштабу без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup у Polkadot підтримує виконання обчислень з Тюрінгом у середовищі WebAssembly, за умови, що одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню загальний обсяг обчислень, які можна виконати за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вносять складність, що є єдиним прийнятним компромісом у проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime для підтримки сталого рівня безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб пристосуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть покладатися на змінні на ланцюзі або поза ним. Наприклад:
Проста стратегія: завжди використовуйте фіксовану кількість core, або вручну коригуйте поза ланцюгом;
Легка стратегія: моніторинг конкретного навантаження транзакцій у mempool вузла;
Автоматизовані стратегії: попередньо викликавши службу coretime через історичні дані та інтерфейс XCM, налаштуйте ресурси.
Автоматизований спосіб, хоча й ефективніший, але вартість реалізації та тестування також значно зростає.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між rollup реалізується за допомогою нижчого рівня передачі, простір комунікаційного блоку кожного rollup є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза ланцюгом (off-chain messaging), де релейний ланцюг виступатиме в ролі контрольного рівня, а не рівня даних. Це оновлення підвищить можливості зв'язку між роллапами разом із еластичним масштабуванням, подальше підсилення вертикальної масштабованості системи.
Які компроміси зробили інші протоколи?
Як відомо, підвищення продуктивності часто досягається за рахунок жертвування децентралізацією та безпекою. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти 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, а не в прямому вирішенні проблем на базовому рівні. Цей підхід по суті не вирішує проблему, а передає її на верхній рівень стеку.
Оптимістичний ролап
Нині більшість Optimistic rollup є централізованими (деякі навіть мають лише один секвенсер), що призводить до недостатньої безпеки, ізольованості один від одного, високої затримки (потрібно чекати періоду підтвердження шахрайства, зазвичай кілька днів) тощо.
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть оброблятися за одну транзакцію. Генерація нульових знань потребує величезних обчислювальних ресурсів, а механізм "переможець забирає все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати затори в мережі, підвищення вартості газу та погіршення користувацького досвіду.
У порівнянні, вартість ZK rollup з повною потужністю Тюрінга приблизно в 2x10^6 разів більша, ніж вартість основного криптоекономічного безпекового протоколу Polkadot.
Крім того, проблема доступності даних у ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, потрібно надати повні дані транзакцій. Це зазвичай залежить від додаткових рішень з доступності даних, що додатково підвищує витрати та комісії для користувачів.
Заключення
Кінець масштабованості не повинен бути компромісом.
У порівнянні з іншими публічними блокчейнами, Polkadot не обрала шлях централізації за рахунок продуктивності та попередньо визначеної довіри за рахунок ефективності, а натомість досягла багатовимірного балансу безпеки, децентралізації та високої продуктивності завдяки еластичному масштабуванню, бездозвільному проєктуванню протоколів, єдиному рівню безпеки та гнучким механізмам управління ресурсами.
У прагненні до більшого масштабу застосування сьогодні, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
14 лайків
Нагородити
14
5
Поділіться
Прокоментувати
0/400
SignatureCollector
· 07-30 01:18
Давайте, ланцюг, швидко зростання, швидко зростання
Переглянути оригіналвідповісти на0
ForumMiningMaster
· 07-30 01:15
Заробляючи 100 тисяч на місяць, лише завдяки цим кільком ланцюгам.
Polkadot еластичне масштабування: шлях до високої продуктивності Web3 без компромісів
Вагання масштабованості Блокчейн: дослідження Polkadot та екосистеми Web3
У сучасному світі Блокчейн, де постійно прагнуть до більшої ефективності, поступово виникає ключове питання: як досягти розширення продуктивності, не жертвуючи безпекою та еластичністю системи?
Це не лише виклик технічного рівня, а й глибокий вибір архітектурного дизайну. Особливо для екосистеми Web3, швидша система, якщо вона будується на основі жертви довіри та безпеки, часто не може підтримувати справжні стійкі інновації.
Як важливий рушій веб3-скалювання, чи зробив Polkadot певні жертви під час досягнення мети високої пропускної здатності та низької затримки? Чи робить його модель 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 core має бути виконана верифікація.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати перетворення стану rollup у процесі доступності та забезпечувати правильність розподілу core за допомогою економічного протоколу ELVES.
Перед записом даних rollup Блок в шарі доступності даних (DA) Polkadot група з приблизно 5 валідаторів спочатку перевіряє їх легітимність. Вони отримують кандидатські квитанції (candidate receipt) та докази дійсності (PoV), які містять rollup Блок та відповідні докази зберігання. Цю інформацію обробить функція верифікації паралельного ланцюга, яку повторно виконають валідатори на релейному ланцюзі.
Результат перевірки містить core selector, який вказує, на якому core слід перевірити Блок. Верифікатор порівнює цей індекс з тим, за який він відповідає; якщо вони не збігаються, цей блок буде відкинуто.
Цей механізм забезпечує безвідмовність системи, завжди зберігаючи властивості без довіри та без дозволу, уникаючи маніпуляцій з позицією верифікаторів з боку зловмисників, таких як сортувальник, та забезпечуючи стійкість навіть при використанні кількох core в rollup.
Безпека
У процесі прагнення до масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпека rollup забезпечується релейним ланцюгом, для підтримки життєздатності достатньо одного чесного сортувальника.
За допомогою протоколу ELVES, Polkadot розширює свою безпеку на всі rollup, перевіряючи всі обчислення на core, без необхідності накладати жодних обмежень чи припущень щодо кількості використаних core.
Отже, rollup Polkadot може досягти справжнього масштабу без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup у Polkadot підтримує виконання обчислень з Тюрінгом у середовищі WebAssembly, за умови, що одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню загальний обсяг обчислень, які можна виконати за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вносять складність, що є єдиним прийнятним компромісом у проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime для підтримки сталого рівня безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб пристосуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть покладатися на змінні на ланцюзі або поза ним. Наприклад:
Проста стратегія: завжди використовуйте фіксовану кількість core, або вручну коригуйте поза ланцюгом;
Легка стратегія: моніторинг конкретного навантаження транзакцій у mempool вузла;
Автоматизовані стратегії: попередньо викликавши службу coretime через історичні дані та інтерфейс XCM, налаштуйте ресурси.
Автоматизований спосіб, хоча й ефективніший, але вартість реалізації та тестування також значно зростає.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між rollup реалізується за допомогою нижчого рівня передачі, простір комунікаційного блоку кожного rollup є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза ланцюгом (off-chain messaging), де релейний ланцюг виступатиме в ролі контрольного рівня, а не рівня даних. Це оновлення підвищить можливості зв'язку між роллапами разом із еластичним масштабуванням, подальше підсилення вертикальної масштабованості системи.
Які компроміси зробили інші протоколи?
Як відомо, підвищення продуктивності часто досягається за рахунок жертвування децентралізацією та безпекою. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти 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, а не в прямому вирішенні проблем на базовому рівні. Цей підхід по суті не вирішує проблему, а передає її на верхній рівень стеку.
Оптимістичний ролап
Нині більшість Optimistic rollup є централізованими (деякі навіть мають лише один секвенсер), що призводить до недостатньої безпеки, ізольованості один від одного, високої затримки (потрібно чекати періоду підтвердження шахрайства, зазвичай кілька днів) тощо.
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть оброблятися за одну транзакцію. Генерація нульових знань потребує величезних обчислювальних ресурсів, а механізм "переможець забирає все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати затори в мережі, підвищення вартості газу та погіршення користувацького досвіду.
У порівнянні, вартість ZK rollup з повною потужністю Тюрінга приблизно в 2x10^6 разів більша, ніж вартість основного криптоекономічного безпекового протоколу Polkadot.
Крім того, проблема доступності даних у ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, потрібно надати повні дані транзакцій. Це зазвичай залежить від додаткових рішень з доступності даних, що додатково підвищує витрати та комісії для користувачів.
Заключення
Кінець масштабованості не повинен бути компромісом.
У порівнянні з іншими публічними блокчейнами, Polkadot не обрала шлях централізації за рахунок продуктивності та попередньо визначеної довіри за рахунок ефективності, а натомість досягла багатовимірного балансу безпеки, децентралізації та високої продуктивності завдяки еластичному масштабуванню, бездозвільному проєктуванню протоколів, єдиному рівню безпеки та гнучким механізмам управління ресурсами.
У прагненні до більшого масштабу застосування сьогодні, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.