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