Масштабованість та компроміси: технічний вибір Polkadot і екосистеми Web3
Сьогодні, коли технології блокчейн постійно прагнуть до вищої ефективності, поступово виникає ключове питання: як забезпечити масштабування продуктивності, одночасно враховуючи безпеку та еластичність системи? Це не лише виклик на технологічному рівні, але й глибокий вибір в архітектурному проектуванні. Для екосистеми Web3 просто прагнути до швидших систем, жертвуючи довірою та безпекою, важко підтримувати справжні сталий інновації.
Як важливий рушій Web3 масштабованості, чи зробив Polkadot певні жертви у своїй меті досягнення високої пропускної здатності та низької затримки? Чи є його модель rollup компромісом у децентралізації, безпеці чи взаємодії мереж? У цій статті ми розглянемо ці питання, детально проаналізуємо компроміси та рівновагу, які Polkadot робить у дизайні масштабованості, та порівняємо це з рішеннями інших основних публічних блокчейнів, досліджуючи їх різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга. Чи може це в деяких аспектах впровадити ризики централізації? Чи можливо виникнення єдиної точки збоїв або контролю, що може вплинути на його децентралізовані характеристики?
Запуск Rollup залежить від сортувальника, що підключений до релейного ланцюга, його комунікація використовує механізм протоколу collator. Цей протокол абсолютно не вимагає дозволу і не потребує довіри, будь-хто з підключенням до мережі може ним користуватися, підключаючи невелику кількість вузлів релейного ланцюга та надсилаючи запити на зміни стану rollup. Ці запити будуть перевірені якимось core релейного ланцюга, необхідно лише виконати одну умову: вони повинні бути дійсними змінами стану, інакше стан цього rollup не буде просунуто.
компроміс вертикального масштабування
Rollup може досягти вертикального масштабування, використовуючи багатоядерну архітектуру Polkadot. Цю нову можливість вводить функція "гнучкого масштабування". Під час проектування було виявлено, що оскільки валідація блоків rollup не фіксується на певному ядрі, це може вплинути на його гнучкість.
Оскільки протокол подачі блоків до релейного ланцюга є бездозвільним і бездостовірним, будь-хто може подати блок на будь-який з core, призначених для rollup, для перевірки. Зловмисник може скористатися цим, повторно подаючи раніше перевірені легітимні блоки на різні core, зловмисно споживаючи ресурси, що призводить до зниження загальної пропускної здатності та ефективності rollup.
Мета Polkadot полягає в підтримці гнучкості rollup та ефективному використанні ресурсів релейної мережі без шкоди для ключових характеристик системи.
Проблема довіри до Sequencer
Простим рішенням є налаштування протоколу як "з ліцензією": наприклад, використання механізму білого списку або за замовчуванням довіра до сортувальника, який не буде здійснювати зловмисні дії, що забезпечить активність rollup.
Однак у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки необхідно зберегти характеристики "без довіри" та "без дозволу" системи. Будь-хто повинен мати можливість використовувати протокол коллаторів для подання запитів на зміни стану rollup.
Polkadot: незламне рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю покласти вирішення проблеми на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом всієї інформації про консенсус, тому в результаті потрібно чітко вказати, на якому ядрі Polkadot має бути виконана валідація.
Цей дизайн забезпечує подвійний захист гнучкості та безпеки. Polkadot повторно виконає перетворення стану rollup у процесі доступності та забезпечить правильність розподілу core за допомогою економічного протоколу ELVES.
Перед записом даних у шар доступності Polkadot (DA) у будь-якому rollup блоці, група з близько 5 валідаторів спочатку перевіряє їх легітимність. Вони отримують кандидатів на квитанцію та докази дійсності, подані сортувальником, які містять rollup блок та відповідні докази зберігання. Цю інформацію обробляє функція валідації паралельного ланцюга, яку повторно виконує валідатор на релейному ланцюзі.
У результатах перевірки міститься core selector, який вказує, на якому core слід перевіряти блок. Верифікатор порівнює цей індекс з тим 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, а еластичне масштабування не впливає на пропускну здатність передачі повідомлень.
Зв'язок повідомлень між крос-роллапами реалізується за допомогою базового рівня передачі, а простір комунікаційних блоків кожного роллапу є фіксованим і не залежить від кількості виділених йому ядер.
У майбутньому Polkadot також підтримуватиме обмін повідомленнями поза ланцюгом, використовуючи релейний ланцюг як контрольний рівень, а не як рівень даних. Це оновлення підвищить можливості зв'язку між роллапами разом з еластичним масштабуванням, що ще більше зміцнить вертикальні можливості масштабування системи.
Узгодження з іншими протоколами
Відомо, що підвищення продуктивності часто обходиться в ціну жертви децентралізації та безпеки. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не є задовільною.
Деякий блокчейн A
Деяка публічна блокчейн A не використовує шардінг-архітектуру Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарової архітектури з високою пропускною здатністю, покладаючись на історичне доведення, паралельну обробку ЦП та механізм консенсусу, оснований на лідерах, теоретична TPS може досягати 65 000.
Ключовим дизайном є його попередньо оприлюднений та перевіряємий механізм розподілу лідерства:
На початку кожного епохи (приблизно через два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейкінгу;
Чим більше заставлено, тим більше розподілу. Наприклад, заставляючи 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 кожної підмережі може досягати ~5000, подібно до концепції Polkadot: зменшити навантаження на окремий шард для досягнення масштабування. Але певний блокчейн C дозволяє валідаторам вільно обирати участь у підмережах, і підмережі можуть встановлювати додаткові вимоги щодо географії, KYC тощо, жертвуючи децентралізацією та безпекою.
У Polkadot всі rollup ділять єдину систему безпеки; тоді як підмережа певного блокчейну C не має за замовчуванням гарантії безпеки, деякі навіть можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ще потрібно буде йти на компроміс з продуктивністю, і важко буде надати визначені гарантії безпеки.
певна публічна блокчейн D
Розширювальна стратегія певного публічного блокчейну D полягає в тому, щоб зробити ставку на масштабованість рівня rollup, а не безпосередньо вирішувати проблеми на базовому рівні. Цей підхід, по суті, не вирішує проблему, а лише передає її на верхній рівень стеку.
Оптимістичний ролап
Наразі більшість оптимістичних роллапів є централізованими (деякі навіть мають лише одного секвенсера), що викликає проблеми з недостатньою безпекою, ізольованістю один від одного, високими затримками (необхідно чекати на період фальсифікації, зазвичай кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена обсягом даних, які можна обробити в одній транзакції. Обчислювальні вимоги для генерації нульових доказів дуже високі, а механізм "переможець забирає все" легко призводить до централізації системи. Щоб забезпечити TPS, ZK rollup часто обмежує обсяг транзакцій у кожній партії, що в умовах високого попиту може викликати затори в мережі та підвищення вартості газу, впливаючи на користувацький досвід.
У порівнянні, вартість ZK rollup з повною потужністю Тюрінга приблизно в 2x10^6 разів перевищує вартість основного безпекового протоколу криптоекономіки Polkadot.
Крім того, проблема доступності даних ZK rollup також посилює його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, все ще потрібно надавати повні дані транзакцій. Це зазвичай залежить від додаткових рішень з доступності даних, що додатково підвищує витрати та збори для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не обрала шлях централізації заради продуктивності чи попередньої довіри заради ефективності, а досягла багатовимірного балансу безпеки, децентралізації та високої продуктивності через еластичне масштабування, бездозвільний дизайн протоколів, єдиний рівень безпеки та гнучкий механізм управління ресурсами.
У прагненні до більш масштабного впровадження сьогодні, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
13 лайків
Нагородити
13
6
Поділіться
Прокоментувати
0/400
FlashLoanKing
· 7год тому
Можна виграти за рахунок швидкості? Звалити провину на користувачів?
Еластичне масштабування Polkadot: компроміс між масштабованістю та безпекою в екосистемі Web3
Масштабованість та компроміси: технічний вибір Polkadot і екосистеми Web3
Сьогодні, коли технології блокчейн постійно прагнуть до вищої ефективності, поступово виникає ключове питання: як забезпечити масштабування продуктивності, одночасно враховуючи безпеку та еластичність системи? Це не лише виклик на технологічному рівні, але й глибокий вибір в архітектурному проектуванні. Для екосистеми Web3 просто прагнути до швидших систем, жертвуючи довірою та безпекою, важко підтримувати справжні сталий інновації.
Як важливий рушій Web3 масштабованості, чи зробив Polkadot певні жертви у своїй меті досягнення високої пропускної здатності та низької затримки? Чи є його модель rollup компромісом у децентралізації, безпеці чи взаємодії мереж? У цій статті ми розглянемо ці питання, детально проаналізуємо компроміси та рівновагу, які Polkadot робить у дизайні масштабованості, та порівняємо це з рішеннями інших основних публічних блокчейнів, досліджуючи їх різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга. Чи може це в деяких аспектах впровадити ризики централізації? Чи можливо виникнення єдиної точки збоїв або контролю, що може вплинути на його децентралізовані характеристики?
Запуск Rollup залежить від сортувальника, що підключений до релейного ланцюга, його комунікація використовує механізм протоколу collator. Цей протокол абсолютно не вимагає дозволу і не потребує довіри, будь-хто з підключенням до мережі може ним користуватися, підключаючи невелику кількість вузлів релейного ланцюга та надсилаючи запити на зміни стану rollup. Ці запити будуть перевірені якимось core релейного ланцюга, необхідно лише виконати одну умову: вони повинні бути дійсними змінами стану, інакше стан цього rollup не буде просунуто.
компроміс вертикального масштабування
Rollup може досягти вертикального масштабування, використовуючи багатоядерну архітектуру Polkadot. Цю нову можливість вводить функція "гнучкого масштабування". Під час проектування було виявлено, що оскільки валідація блоків rollup не фіксується на певному ядрі, це може вплинути на його гнучкість.
Оскільки протокол подачі блоків до релейного ланцюга є бездозвільним і бездостовірним, будь-хто може подати блок на будь-який з core, призначених для rollup, для перевірки. Зловмисник може скористатися цим, повторно подаючи раніше перевірені легітимні блоки на різні core, зловмисно споживаючи ресурси, що призводить до зниження загальної пропускної здатності та ефективності rollup.
Мета Polkadot полягає в підтримці гнучкості rollup та ефективному використанні ресурсів релейної мережі без шкоди для ключових характеристик системи.
Проблема довіри до Sequencer
Простим рішенням є налаштування протоколу як "з ліцензією": наприклад, використання механізму білого списку або за замовчуванням довіра до сортувальника, який не буде здійснювати зловмисні дії, що забезпечить активність rollup.
Однак у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки необхідно зберегти характеристики "без довіри" та "без дозволу" системи. Будь-хто повинен мати можливість використовувати протокол коллаторів для подання запитів на зміни стану rollup.
Polkadot: незламне рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю покласти вирішення проблеми на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом всієї інформації про консенсус, тому в результаті потрібно чітко вказати, на якому ядрі Polkadot має бути виконана валідація.
Цей дизайн забезпечує подвійний захист гнучкості та безпеки. Polkadot повторно виконає перетворення стану rollup у процесі доступності та забезпечить правильність розподілу core за допомогою економічного протоколу ELVES.
Перед записом даних у шар доступності Polkadot (DA) у будь-якому rollup блоці, група з близько 5 валідаторів спочатку перевіряє їх легітимність. Вони отримують кандидатів на квитанцію та докази дійсності, подані сортувальником, які містять rollup блок та відповідні докази зберігання. Цю інформацію обробляє функція валідації паралельного ланцюга, яку повторно виконує валідатор на релейному ланцюзі.
У результатах перевірки міститься core selector, який вказує, на якому core слід перевіряти блок. Верифікатор порівнює цей індекс з тим core, за який він відповідає; якщо вони не збігаються, цей блок буде відкинуто.
Цей механізм гарантує, що система завжди зберігає властивості без довіри та без дозволу, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, забезпечуючи еластичність навіть при використанні кількох core у rollup.
безпека
У процесі досягнення масштабованості Polkadot не йшло на компроміс у питанні безпеки. Безпека rollup забезпечується релейним ланцюгом, і для підтримання життєздатності потрібен лише один чесний сортувальник.
Завдяки протоколу ELVES, Polkadot повністю розширює свою безпеку на всі rollup, перевіряючи всі обчислення на ядрах, без необхідності обмежувати або робити припущення щодо кількості використовуваних ядер.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне розширення не обмежує програмованість rollup. Модель rollup Polkadot підтримує виконання обчислень з повною Тюрінговою завершеністю в середовищі WebAssembly, за умови, що одноразове виконання завершується протягом 2 секунд. Завдяки еластичному розширенню, загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.
складність
Вищий пропускний здатність і нижча затримка неминуче впроваджують складність, що є єдиним прийнятним компромісом у проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime для підтримки стабільного рівня безпеки. Вони також повинні виконувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, яка може покладатися на змінні на ланцюгу або поза ним. Наприклад:
Автоматизовані методи, хоча і є більш ефективними, але також значно збільшують витрати на реалізацію та тестування.
інтерактивність
Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не впливає на пропускну здатність передачі повідомлень.
Зв'язок повідомлень між крос-роллапами реалізується за допомогою базового рівня передачі, а простір комунікаційних блоків кожного роллапу є фіксованим і не залежить від кількості виділених йому ядер.
У майбутньому Polkadot також підтримуватиме обмін повідомленнями поза ланцюгом, використовуючи релейний ланцюг як контрольний рівень, а не як рівень даних. Це оновлення підвищить можливості зв'язку між роллапами разом з еластичним масштабуванням, що ще більше зміцнить вертикальні можливості масштабування системи.
Узгодження з іншими протоколами
Відомо, що підвищення продуктивності часто обходиться в ціну жертви децентралізації та безпеки. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не є задовільною.
Деякий блокчейн A
Деяка публічна блокчейн A не використовує шардінг-архітектуру Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарової архітектури з високою пропускною здатністю, покладаючись на історичне доведення, паралельну обробку ЦП та механізм консенсусу, оснований на лідерах, теоретична TPS може досягати 65 000.
Ключовим дизайном є його попередньо оприлюднений та перевіряємий механізм розподілу лідерства:
Історія доводить, що паралельна обробка вимагає дуже високих вимог до апаратного забезпечення, що призводить до централізації валідаторів. Чим більше часток має вузол, тим більша ймовірність його участі у створенні блоку, тоді як маленькі вузли практично не мають слотів, що ще більше загострює централізацію і збільшує ризик паралічу системи після атаки.
Деяка публічна блокчейн-система 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 кожної підмережі може досягати ~5000, подібно до концепції Polkadot: зменшити навантаження на окремий шард для досягнення масштабування. Але певний блокчейн C дозволяє валідаторам вільно обирати участь у підмережах, і підмережі можуть встановлювати додаткові вимоги щодо географії, KYC тощо, жертвуючи децентралізацією та безпекою.
У Polkadot всі rollup ділять єдину систему безпеки; тоді як підмережа певного блокчейну C не має за замовчуванням гарантії безпеки, деякі навіть можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ще потрібно буде йти на компроміс з продуктивністю, і важко буде надати визначені гарантії безпеки.
певна публічна блокчейн D
Розширювальна стратегія певного публічного блокчейну D полягає в тому, щоб зробити ставку на масштабованість рівня rollup, а не безпосередньо вирішувати проблеми на базовому рівні. Цей підхід, по суті, не вирішує проблему, а лише передає її на верхній рівень стеку.
Оптимістичний ролап
Наразі більшість оптимістичних роллапів є централізованими (деякі навіть мають лише одного секвенсера), що викликає проблеми з недостатньою безпекою, ізольованістю один від одного, високими затримками (необхідно чекати на період фальсифікації, зазвичай кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена обсягом даних, які можна обробити в одній транзакції. Обчислювальні вимоги для генерації нульових доказів дуже високі, а механізм "переможець забирає все" легко призводить до централізації системи. Щоб забезпечити TPS, ZK rollup часто обмежує обсяг транзакцій у кожній партії, що в умовах високого попиту може викликати затори в мережі та підвищення вартості газу, впливаючи на користувацький досвід.
У порівнянні, вартість ZK rollup з повною потужністю Тюрінга приблизно в 2x10^6 разів перевищує вартість основного безпекового протоколу криптоекономіки Polkadot.
Крім того, проблема доступності даних ZK rollup також посилює його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, все ще потрібно надавати повні дані транзакцій. Це зазвичай залежить від додаткових рішень з доступності даних, що додатково підвищує витрати та збори для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не обрала шлях централізації заради продуктивності чи попередньої довіри заради ефективності, а досягла багатовимірного балансу безпеки, децентралізації та високої продуктивності через еластичне масштабування, бездозвільний дизайн протоколів, єдиний рівень безпеки та гнучкий механізм управління ресурсами.
У прагненні до більш масштабного впровадження сьогодні, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.