Балансування та компроміси в розширюваності Блокчейн: на прикладі Polkadot
Сьогодні, коли технологія Блокчейн постійно прагне до вищої ефективності, виникає ключове питання: як уникнути жертвування безпекою та гнучкістю системи під час покращення масштабованості? Це не лише виклик на технічному рівні, але й глибокий вибір в архітектурному дизайні. Для екосистеми Web3 швидша система, якщо вона будується на жертві довіри та безпеки, часто не може підтримувати справжні стійкі інновації.
Як важливий двигун масштабованості Web3, чи зробив Polkadot певні жертви, прагнучи до високої пропускної здатності та низької затримки? Чи зробила його модель rollup поступки в децентралізації, безпеці або міжмережевій взаємодії? У цій статті буде розглянуто ці питання, детально проаналізувавши компроміси та вибори, які Polkadot зробив у проектуванні масштабованості, а також порівнюючи їх із рішеннями інших провідних публічних блокчейнів, досліджуючи їх різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс еластичності та децентралізації
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга, чи може це в деяких аспектах ввести ризики централізації? Чи можливо виникнення єдиної точки відмови або контролю, що може вплинути на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника, що підключений до релейного ланцюга, а його комунікація використовує механізм, що називається протоколом коллатора. Цей протокол абсолютно без ліцензії та без довіри, будь-хто з підключенням до мережі може ним користуватися, підключивши невелику кількість вузлів релейного ланцюга та подаючи запити на зміни стану rollup. Ці запити перевіряються певним core релейного ланцюга, і є тільки одна умова: вони повинні бути дійсними змінами стану, інакше стан цього rollup не буде просунуто.
Торгівельні компроміси вертикального розширення
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість була введена функцією «гнучкого масштабування». Під час проектування було виявлено, що оскільки валідація блоків rollup не виконується на певному ядрі, це може вплинути на його гнучкість.
Оскільки протокол подання блоків до релейної мережі є бездозволеним і без довіри, будь-хто може подати блок на будь-який основний вузол, призначений для rollup, для перевірки. Зловмисники можуть скористатися цим, повторно подаючи вже перевірені легітимні блоки на різні основні вузли, зловмисно споживаючи ресурси, що знижує загальну пропускну здатність і ефективність rollup.
Мета Polkadot полягає в тому, щоб підтримувати еластичність rollup і ефективне використання ресурсів релейного ланцюга без шкоди для ключових характеристик системи.
Чи варто довіряти Sequencer?
Простим рішенням є налаштування протоколу на "з ліцензією": наприклад, використання механізму білого списку або довіра до сортувальників за замовчуванням, які не будуть вчиняти злісні дії, щоб забезпечити активність rollup.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних довірчих припущень щодо sequencer, оскільки необхідно зберегти характеристики системи «без довіри» та «без дозволу». Будь-хто повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточний вибір рішення Polkadot: повністю покласти вирішення проблеми на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації консенсусу, тому виводі повинно бути чітко зазначено, на якому ядрі Polkadot має бути виконана перевірка.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати перехід стану rollup у процесі доступності та забезпечувати правильність розподілу core через економічний протокол ELVES.
Перед записом даних про доступність у мережі Polkadot в будь-який rollup Блок, група з приблизно 5 валідаторів спочатку перевіряє їхню легітимність. Вони отримують кандидатські квитанції та докази дійсності, подані сортувальником, які містять rollup Блок та відповідні докази зберігання. Цю інформацію обробляє функція перевірки паралельного ланцюга, яку повторно виконує валідатор на релейному ланцюзі.
Результати перевірки містять селектор core, який використовується для вказівки, на якому core слід перевіряти Блок. Валідаор порівнює цей індекс з тим, за який відповідає його core; якщо вони не збігаються, цей Блок буде відкинуто.
Цей механізм забезпечує безвідмовність системи та її безперешкодність, уникаючи маніпуляцій з боку зловмисних учасників, таких як сортувальники, у позиції верифікації, гарантуючи, що навіть при використанні кількох core, rollup може залишатися еластичним.
Безпека
У процесі досягнення масштабованості Polkadot не йшов на компроміс щодо безпеки. Безпека rollup забезпечується релейним ланцюгом, для підтримки життєздатності достатньо одного чесного сортувальника.
За допомогою протоколу ELVES Polkadot повністю розширить свою безпеку на всі rollup, перевіряючи всі обчислення на core, без необхідності обмежувати або припускати кількість використаних core.
Отже, rollup Polkadot може досягти справжньої масштабованості без шкоди для безпеки.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup Polkadot підтримує виконання обчислень, що є тьюринг-повними в середовищі WebAssembly, за умови, що одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню, загальна кількість обчислень, що можуть бути виконані за 6 секунд, збільшується, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче ведуть до складності, що є єдиним прийнятним компромісом у проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, яка може залежати від змінних на ланцюзі або поза ним. Наприклад:
Простий стратегія: завжди використовувати фіксовану кількість core, або вручну налаштовувати через офлайн.
Легка стратегія: моніторинг конкретного навантаження транзакцій у мемпулі вузла;
Автоматизовані стратегії: через історичні дані та інтерфейс XCM заздалегідь викликати службу coretime для налаштування ресурсів.
Автоматизований підхід, хоча й ефективніший, але вартість реалізації та тестування також значно зростає.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, і еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між різними rollup реалізується за допомогою підключеного транспортного рівня, при цьому простір комунікаційних блоків кожного rollup є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме міжланцюгове повідомлення, використовуючи релейний ланцюг як контрольну площину, а не як площину даних. Це оновлення підвищить можливості зв'язку між роллапами разом з еластичним масштабуванням, що ще більше посилить вертикальні можливості масштабування системи.
Які компроміси зробили інші протоколи?
Всім відомо, що підвищення продуктивності часто досягається за рахунок централізації та безпеки. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не вражає.
Солана
Solana не використовує архітектуру шардінгу Polkadot або Ethereum, а реалізує масштабованість за рахунок одношарової архітектури з високою пропускною здатністю, покладаючись на історичне підтвердження, паралельну обробку CPU та механізм консенсусу на основі лідера, теоретичний TPS може досягати 65,000.
Одним із ключових проектних рішень є попередньо опублікований та перевіряємий механізм призначення лідерів:
На початку кожного епохи (приблизно два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейкінгу;
Чим більше ви ставите, тим більше розподілу ви отримуєте. Наприклад, ставлячи 1% валідатора, ви отримаєте приблизно 1% шансів на блокування;
Усі майнери блоків заздалегідь оголошуються, що підвищує ризик цілеспрямованих DDoS-атак на мережу та частих збоїв.
Історія доводить, що паралельна обробка має дуже високі вимоги до апаратного забезпечення, що призводить до централізації вузлів перевірки. Чим більше вузлів стейка, тим більша ймовірність отримання блоку, маленькі вузли майже не мають слотів, що ще більше загострює централізацію та підвищує ризик зупинки системи після атаки.
Solana, прагнучи до TPS, пожертвувала децентралізацією та стійкістю до атак, її коефіцієнт Накамото становить лише 20, що значно нижче, ніж у Polkadot, який має 172.
ТОН
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 всі роллапи ділять єдине забезпечення безпеки; тоді як підмережі Avalanche не мають за замовчуванням забезпечення безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ще потрібно йти на компроміс у продуктивності, і важко забезпечити гарантовані зобов'язання безпеки.
Ефіріум
Розширена стратегія Ethereum полягає в ставці на масштабованість рівня rollup, а не в безпосередньому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблему, а передає її на верхній рівень стеку.
Оптимістичний Ролап
Наразі більшість Optimistic rollup є централізованими (деякі навіть мають лише одного секвенсера), що призводить до недостатньої безпеки, ізольованості один від одного, високої затримки (потрібно чекати періоду підтвердження шахрайства, зазвичай кілька днів) та інших проблем.
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових знань дуже високі, а механізм «переможець отримує все» може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup часто обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати завантаження мережі, підвищення газу та вплинути на досвід користувачів.
У порівнянні, вартість ZK rollup з Turing completeness приблизно в 2x10^6 разів перевищує вартість основного криптоекономічного безпекового протоколу Polkadot.
Крім того, проблема доступності даних ZK rollup також посилює її недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, все ще потрібно надавати повні дані про транзакції. Це зазвичай залежить від додаткових рішень з доступності даних, що ще більше підвищує витрати та комісії для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
У порівнянні з іншими публічними блокчейнами, Polkadot не пішов шляхом централізації заради продуктивності або попередньо заданої довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через гнучке масштабування, децентралізований дизайн протоколу, єдиний шар безпеки та гнучкі механізми управління ресурсами.
У прагненні до більшого масштабного впровадження сьогодні, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Polkadot еластичне масштабування: пошук балансу між продуктивністю та Децентралізацією
Балансування та компроміси в розширюваності Блокчейн: на прикладі Polkadot
Сьогодні, коли технологія Блокчейн постійно прагне до вищої ефективності, виникає ключове питання: як уникнути жертвування безпекою та гнучкістю системи під час покращення масштабованості? Це не лише виклик на технічному рівні, але й глибокий вибір в архітектурному дизайні. Для екосистеми Web3 швидша система, якщо вона будується на жертві довіри та безпеки, часто не може підтримувати справжні стійкі інновації.
Як важливий двигун масштабованості Web3, чи зробив Polkadot певні жертви, прагнучи до високої пропускної здатності та низької затримки? Чи зробила його модель rollup поступки в децентралізації, безпеці або міжмережевій взаємодії? У цій статті буде розглянуто ці питання, детально проаналізувавши компроміси та вибори, які Polkadot зробив у проектуванні масштабованості, а також порівнюючи їх із рішеннями інших провідних публічних блокчейнів, досліджуючи їх різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс еластичності та децентралізації
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга, чи може це в деяких аспектах ввести ризики централізації? Чи можливо виникнення єдиної точки відмови або контролю, що може вплинути на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника, що підключений до релейного ланцюга, а його комунікація використовує механізм, що називається протоколом коллатора. Цей протокол абсолютно без ліцензії та без довіри, будь-хто з підключенням до мережі може ним користуватися, підключивши невелику кількість вузлів релейного ланцюга та подаючи запити на зміни стану rollup. Ці запити перевіряються певним core релейного ланцюга, і є тільки одна умова: вони повинні бути дійсними змінами стану, інакше стан цього rollup не буде просунуто.
Торгівельні компроміси вертикального розширення
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість була введена функцією «гнучкого масштабування». Під час проектування було виявлено, що оскільки валідація блоків rollup не виконується на певному ядрі, це може вплинути на його гнучкість.
Оскільки протокол подання блоків до релейної мережі є бездозволеним і без довіри, будь-хто може подати блок на будь-який основний вузол, призначений для rollup, для перевірки. Зловмисники можуть скористатися цим, повторно подаючи вже перевірені легітимні блоки на різні основні вузли, зловмисно споживаючи ресурси, що знижує загальну пропускну здатність і ефективність rollup.
Мета Polkadot полягає в тому, щоб підтримувати еластичність rollup і ефективне використання ресурсів релейного ланцюга без шкоди для ключових характеристик системи.
Чи варто довіряти Sequencer?
Простим рішенням є налаштування протоколу на "з ліцензією": наприклад, використання механізму білого списку або довіра до сортувальників за замовчуванням, які не будуть вчиняти злісні дії, щоб забезпечити активність rollup.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних довірчих припущень щодо sequencer, оскільки необхідно зберегти характеристики системи «без довіри» та «без дозволу». Будь-хто повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточний вибір рішення Polkadot: повністю покласти вирішення проблеми на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації консенсусу, тому виводі повинно бути чітко зазначено, на якому ядрі Polkadot має бути виконана перевірка.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати перехід стану rollup у процесі доступності та забезпечувати правильність розподілу core через економічний протокол ELVES.
Перед записом даних про доступність у мережі Polkadot в будь-який rollup Блок, група з приблизно 5 валідаторів спочатку перевіряє їхню легітимність. Вони отримують кандидатські квитанції та докази дійсності, подані сортувальником, які містять rollup Блок та відповідні докази зберігання. Цю інформацію обробляє функція перевірки паралельного ланцюга, яку повторно виконує валідатор на релейному ланцюзі.
Результати перевірки містять селектор core, який використовується для вказівки, на якому core слід перевіряти Блок. Валідаор порівнює цей індекс з тим, за який відповідає його core; якщо вони не збігаються, цей Блок буде відкинуто.
Цей механізм забезпечує безвідмовність системи та її безперешкодність, уникаючи маніпуляцій з боку зловмисних учасників, таких як сортувальники, у позиції верифікації, гарантуючи, що навіть при використанні кількох core, rollup може залишатися еластичним.
Безпека
У процесі досягнення масштабованості Polkadot не йшов на компроміс щодо безпеки. Безпека rollup забезпечується релейним ланцюгом, для підтримки життєздатності достатньо одного чесного сортувальника.
За допомогою протоколу ELVES Polkadot повністю розширить свою безпеку на всі rollup, перевіряючи всі обчислення на core, без необхідності обмежувати або припускати кількість використаних core.
Отже, rollup Polkadot може досягти справжньої масштабованості без шкоди для безпеки.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup Polkadot підтримує виконання обчислень, що є тьюринг-повними в середовищі WebAssembly, за умови, що одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню, загальна кількість обчислень, що можуть бути виконані за 6 секунд, збільшується, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче ведуть до складності, що є єдиним прийнятним компромісом у проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, яка може залежати від змінних на ланцюзі або поза ним. Наприклад:
Простий стратегія: завжди використовувати фіксовану кількість core, або вручну налаштовувати через офлайн.
Легка стратегія: моніторинг конкретного навантаження транзакцій у мемпулі вузла;
Автоматизовані стратегії: через історичні дані та інтерфейс XCM заздалегідь викликати службу coretime для налаштування ресурсів.
Автоматизований підхід, хоча й ефективніший, але вартість реалізації та тестування також значно зростає.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, і еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між різними rollup реалізується за допомогою підключеного транспортного рівня, при цьому простір комунікаційних блоків кожного rollup є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме міжланцюгове повідомлення, використовуючи релейний ланцюг як контрольну площину, а не як площину даних. Це оновлення підвищить можливості зв'язку між роллапами разом з еластичним масштабуванням, що ще більше посилить вертикальні можливості масштабування системи.
Які компроміси зробили інші протоколи?
Всім відомо, що підвищення продуктивності часто досягається за рахунок централізації та безпеки. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не вражає.
Солана
Solana не використовує архітектуру шардінгу Polkadot або Ethereum, а реалізує масштабованість за рахунок одношарової архітектури з високою пропускною здатністю, покладаючись на історичне підтвердження, паралельну обробку CPU та механізм консенсусу на основі лідера, теоретичний TPS може досягати 65,000.
Одним із ключових проектних рішень є попередньо опублікований та перевіряємий механізм призначення лідерів:
На початку кожного епохи (приблизно два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейкінгу;
Чим більше ви ставите, тим більше розподілу ви отримуєте. Наприклад, ставлячи 1% валідатора, ви отримаєте приблизно 1% шансів на блокування;
Усі майнери блоків заздалегідь оголошуються, що підвищує ризик цілеспрямованих DDoS-атак на мережу та частих збоїв.
Історія доводить, що паралельна обробка має дуже високі вимоги до апаратного забезпечення, що призводить до централізації вузлів перевірки. Чим більше вузлів стейка, тим більша ймовірність отримання блоку, маленькі вузли майже не мають слотів, що ще більше загострює централізацію та підвищує ризик зупинки системи після атаки.
Solana, прагнучи до TPS, пожертвувала децентралізацією та стійкістю до атак, її коефіцієнт Накамото становить лише 20, що значно нижче, ніж у Polkadot, який має 172.
ТОН
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 всі роллапи ділять єдине забезпечення безпеки; тоді як підмережі Avalanche не мають за замовчуванням забезпечення безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ще потрібно йти на компроміс у продуктивності, і важко забезпечити гарантовані зобов'язання безпеки.
Ефіріум
Розширена стратегія Ethereum полягає в ставці на масштабованість рівня rollup, а не в безпосередньому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблему, а передає її на верхній рівень стеку.
Оптимістичний Ролап
Наразі більшість Optimistic rollup є централізованими (деякі навіть мають лише одного секвенсера), що призводить до недостатньої безпеки, ізольованості один від одного, високої затримки (потрібно чекати періоду підтвердження шахрайства, зазвичай кілька днів) та інших проблем.
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових знань дуже високі, а механізм «переможець отримує все» може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup часто обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати завантаження мережі, підвищення газу та вплинути на досвід користувачів.
У порівнянні, вартість ZK rollup з Turing completeness приблизно в 2x10^6 разів перевищує вартість основного криптоекономічного безпекового протоколу Polkadot.
Крім того, проблема доступності даних ZK rollup також посилює її недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, все ще потрібно надавати повні дані про транзакції. Це зазвичай залежить від додаткових рішень з доступності даних, що ще більше підвищує витрати та комісії для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
У порівнянні з іншими публічними блокчейнами, Polkadot не пішов шляхом централізації заради продуктивності або попередньо заданої довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через гнучке масштабування, децентралізований дизайн протоколу, єдиний шар безпеки та гнучкі механізми управління ресурсами.
У прагненні до більшого масштабного впровадження сьогодні, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.