Торгівля між масштабованістю та безпекою: архітектурний дизайн Web3 Polkadot
Сьогодні, коли технології блокчейну постійно прагнуть до більшої ефективності, поступово виникає ключове питання: як підвищити продуктивність, не жертвуючи безпекою та еластичністю системи? Це не лише технічний виклик, але й глибокі роздуми щодо архітектурного дизайну. Для екосистеми Web3 швидка система, якщо вона жертвує довірою і безпекою, часто не може підтримувати справжні стійкі інновації.
Як важливий рушій Web3 масштабованості, чи зробив Polkadot якісь компроміси в процесі досягнення високої пропускної здатності та низької затримки? Чи поступився його модель rollup у питаннях децентралізації, безпеки або міжмережевої взаємодії? У цій статті ми розглянемо ці питання, глибоко проаналізуємо компроміси та переваги, які Polkadot зробив у дизайні масштабованості, а також порівняємо їх з рішеннями інших основних публічних блокчейнів, досліджуючи їхні різні вибори в питаннях продуктивності, безпеки та децентралізації.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейної ланцюга. Чи може це в певних аспектах впровадити ризики централізації? Чи може виникнути єдина точка відмови або контролю, що вплине на його децентралізовані характеристики?
Робота зведення спирається на секвенсор, який з'єднує ланцюг реле, а його зв'язок використовує механізм протоколу коллятора. Протокол повністю інклюзивний і не потребує довіри, і будь-хто, хто має підключення до Інтернету, може використовувати його для підключення до невеликої кількості вузлів Relay Chain і надсилання запитів на перехід станів для зведень. Ці запити перевіряються одним із ядер Relay Chain лише з однією передумовою: вони мають бути допустимими переходами станів, інакше стан зведення не буде підвищено.
компроміс вертикального масштабування
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість була введена функцією «еластичного масштабування». У процесі проектування було виявлено, що оскільки перевірка блоків rollup не фіксується на певному ядрі, це може вплинути на його еластичність.
Оскільки протокол подання блоків до релейного ланцюга є бездозвільним і бездоверливим, будь-хто може подати блок для перевірки на будь-якому основному вузлі, призначеному для rollup. Зловмисники можуть скористатися цим, повторно подаючи раніше перевірені законні блоки на різні основні вузли, навмисно споживаючи ресурси і, таким чином, знижуючи загальну пропускну спроможність і ефективність rollup.
Мета Polkadot полягає в тому, щоб підтримувати еластичність rollup і ефективне використання ресурсів релейного ланцюга без шкоди для ключових характеристик системи.
Проблема довіри Sequencer
Простим рішенням є встановлення протоколу як "з ліцензією": наприклад, використання механізму білих списків або за замовчуванням довіряти сортировщику, який не буде вчиняти злочини, щоб забезпечити активність рулету.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки необхідно зберегти характеристики «без довіри» та «без дозволу» системи. Кожен повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Безкомпромісне рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю покласти проблему на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому в виході необхідно чітко вказати, на якому ядрі Polkadot має бути виконана перевірка.
Цей дизайн забезпечує подвійну гарантію еластичності та безпеки. Polkadot повторно виконає перехід стану rollup у процесі доступності та забезпечить правильність розподілу core через економічний протокол ELVES.
Перед записом даних у шар доступності Polkadot у будь-якому rollup-блоці група з приблизно 5 валідаторів спершу перевіряє їхню законність. Вони отримують кандидатські підтвердження та докази дійсності, подані сортувальником, які містять rollup-блок та відповідні докази зберігання. Цю інформацію обробляють функції валідації паралельних ланцюгів, які повторно виконуються валідаторами на релейному ланцюзі.
У результатах перевірки міститься основний селектор, який використовується для вказівки, на якому ядрі слід перевіряти блок. Верифікатор порівнює цей індекс з тим, за яке ядро він відповідає; якщо вони не збігаються, блок буде відкинуто.
Цей механізм забезпечує постійну відсутність потреби в довірі та дозволах у системі, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, щодо позицій верифікації, гарантуючи, що навіть при використанні кількох ядер у rollup система залишається стійкою.
безпека
У процесі прагнення до масштабованості Polkadot не пішов на компроміс в питаннях безпеки. Безпека rollup забезпечується релейним ланцюгом, для підтримки життєздатності потрібен лише один чесний сортувальник.
Завдяки протоколу ELVES, Polkadot повністю розширює свою безпеку на всі rollup, верифікуючи всі обчислення на core без будь-яких обмежень чи припущень щодо кількості використаних ядер.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежить програмованість rollup. Модель rollup в Polkadot підтримує виконання обчислень з повною Тюрінговою здатністю в середовищі WebAssembly, якщо одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню, загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом в проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть покладатися на змінні в мережі або поза нею. Наприклад:
Проста стратегія: завжди використовувати фіксовану кількість core або вручну налаштовувати поза ланцюгом;
Легка стратегія: моніторинг конкретного навантаження транзакцій у mempool вузла;
Автоматизовані стратегії: попереднє викликання служби coretime з конфігурацією ресурсів через історичні дані та XCM інтерфейс.
Хоча автоматизовані методи є більш ефективними, витрати на їх реалізацію та тестування також значно зростають.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, при цьому еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між крос-роллапами реалізується на основі нижнього рівня транспортного шару, при цьому простір комунікаційного блоку кожного роллапа є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза блокчейном, використовуючи релейний ланцюг як контрольний рівень, а не рівень даних. Це оновлення підвищить можливості зв'язку між роллапами разом з еластичним масштабуванням, що ще більше зміцнить вертикальні можливості масштабування системи.
В权衡 інших протоколів
Відомо, що підвищення продуктивності часто досягається за рахунок жертвування децентралізацією та безпекою. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не є вражаючою.
Солана
Solana не використовує шардінг-архітектуру Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарового архітектурного рішення з високою пропускною спроможністю, покладаючись на історичне підтвердження, паралельну обробку ЦП та механізм консенсусу на основі лідера, теоретична 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: зменшити навантаження на окремий shard для досягнення масштабованості. Але Avalanche дозволяє валідаторам вільно обирати участь у підмережах, і підмережі можуть встановлювати додаткові вимоги, такі як географічні, KYC тощо, жертвуючи децентралізацією та безпекою.
У Polkadot всі роллапи мають єдину гарантію безпеки; тоді як підмережі Avalanche не мають стандартної гарантії безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, доведеться поступитися продуктивністю, і складно надати визначені гарантії безпеки.
Ефіріум
Стратегія масштабування Ethereum полягає в ставці на масштабованість рівня rollup, а не в прямому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблеми, а передає її на верхній рівень стеку.
Оптимістичний ролап
Наразі більшість оптимістичних роллапів є централізованими, що призводить до недостатньої безпеки, ізоляції один від одного та високої затримки (потрібно чекати періоду підтвердження шахрайства, зазвичай кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових доказів є надзвичайно високими, а механізм "переможець отримує все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що може викликати затори в мережі та збільшення вартості gas під час високого попиту, що впливає на користувацький досвід.
У порівнянні, вартість ZK rollup, що є тюрінгом, приблизно в 2x10^6 разів більша, ніж безпековий протокол основної криптоекономіки Polkadot.
Крім того, проблема доступності даних у ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, необхідно надати повні дані транзакцій. Це зазвичай залежить від додаткових рішень щодо доступності даних, що додатково підвищує витрати та збори для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності або попереднього довіри заради ефективності, а досягнув багатовимірного балансу безпеки, децентралізації та високої продуктивності шляхом гнучкого масштабування, протоколів без дозволів, єдиного шару безпеки та гнучкого управління ресурсами.
У сучасному прагненні до більш масштабного впровадження, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
19 лайків
Нагородити
19
5
Репост
Поділіться
Прокоментувати
0/400
NFT_Therapy
· 07-16 00:58
Знову бачити мого старого друга dot!
Переглянути оригіналвідповісти на0
LayerZeroHero
· 07-14 19:38
Фактично, напевно, є trade-off, потрібно ще запустити бенчмарк для перевірки...
Web3-архітектура Polkadot: ідеальний баланс між масштабованістю та безпекою
Торгівля між масштабованістю та безпекою: архітектурний дизайн Web3 Polkadot
Сьогодні, коли технології блокчейну постійно прагнуть до більшої ефективності, поступово виникає ключове питання: як підвищити продуктивність, не жертвуючи безпекою та еластичністю системи? Це не лише технічний виклик, але й глибокі роздуми щодо архітектурного дизайну. Для екосистеми Web3 швидка система, якщо вона жертвує довірою і безпекою, часто не може підтримувати справжні стійкі інновації.
Як важливий рушій Web3 масштабованості, чи зробив Polkadot якісь компроміси в процесі досягнення високої пропускної здатності та низької затримки? Чи поступився його модель rollup у питаннях децентралізації, безпеки або міжмережевої взаємодії? У цій статті ми розглянемо ці питання, глибоко проаналізуємо компроміси та переваги, які Polkadot зробив у дизайні масштабованості, а також порівняємо їх з рішеннями інших основних публічних блокчейнів, досліджуючи їхні різні вибори в питаннях продуктивності, безпеки та децентралізації.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейної ланцюга. Чи може це в певних аспектах впровадити ризики централізації? Чи може виникнути єдина точка відмови або контролю, що вплине на його децентралізовані характеристики?
Робота зведення спирається на секвенсор, який з'єднує ланцюг реле, а його зв'язок використовує механізм протоколу коллятора. Протокол повністю інклюзивний і не потребує довіри, і будь-хто, хто має підключення до Інтернету, може використовувати його для підключення до невеликої кількості вузлів Relay Chain і надсилання запитів на перехід станів для зведень. Ці запити перевіряються одним із ядер Relay Chain лише з однією передумовою: вони мають бути допустимими переходами станів, інакше стан зведення не буде підвищено.
компроміс вертикального масштабування
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість була введена функцією «еластичного масштабування». У процесі проектування було виявлено, що оскільки перевірка блоків rollup не фіксується на певному ядрі, це може вплинути на його еластичність.
Оскільки протокол подання блоків до релейного ланцюга є бездозвільним і бездоверливим, будь-хто може подати блок для перевірки на будь-якому основному вузлі, призначеному для rollup. Зловмисники можуть скористатися цим, повторно подаючи раніше перевірені законні блоки на різні основні вузли, навмисно споживаючи ресурси і, таким чином, знижуючи загальну пропускну спроможність і ефективність rollup.
Мета Polkadot полягає в тому, щоб підтримувати еластичність rollup і ефективне використання ресурсів релейного ланцюга без шкоди для ключових характеристик системи.
Проблема довіри Sequencer
Простим рішенням є встановлення протоколу як "з ліцензією": наприклад, використання механізму білих списків або за замовчуванням довіряти сортировщику, який не буде вчиняти злочини, щоб забезпечити активність рулету.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки необхідно зберегти характеристики «без довіри» та «без дозволу» системи. Кожен повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Безкомпромісне рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю покласти проблему на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому в виході необхідно чітко вказати, на якому ядрі Polkadot має бути виконана перевірка.
Цей дизайн забезпечує подвійну гарантію еластичності та безпеки. Polkadot повторно виконає перехід стану rollup у процесі доступності та забезпечить правильність розподілу core через економічний протокол ELVES.
Перед записом даних у шар доступності Polkadot у будь-якому rollup-блоці група з приблизно 5 валідаторів спершу перевіряє їхню законність. Вони отримують кандидатські підтвердження та докази дійсності, подані сортувальником, які містять rollup-блок та відповідні докази зберігання. Цю інформацію обробляють функції валідації паралельних ланцюгів, які повторно виконуються валідаторами на релейному ланцюзі.
У результатах перевірки міститься основний селектор, який використовується для вказівки, на якому ядрі слід перевіряти блок. Верифікатор порівнює цей індекс з тим, за яке ядро він відповідає; якщо вони не збігаються, блок буде відкинуто.
Цей механізм забезпечує постійну відсутність потреби в довірі та дозволах у системі, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, щодо позицій верифікації, гарантуючи, що навіть при використанні кількох ядер у rollup система залишається стійкою.
безпека
У процесі прагнення до масштабованості Polkadot не пішов на компроміс в питаннях безпеки. Безпека rollup забезпечується релейним ланцюгом, для підтримки життєздатності потрібен лише один чесний сортувальник.
Завдяки протоколу ELVES, Polkadot повністю розширює свою безпеку на всі rollup, верифікуючи всі обчислення на core без будь-яких обмежень чи припущень щодо кількості використаних ядер.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежить програмованість rollup. Модель rollup в Polkadot підтримує виконання обчислень з повною Тюрінговою здатністю в середовищі WebAssembly, якщо одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню, загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом в проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть покладатися на змінні в мережі або поза нею. Наприклад:
Хоча автоматизовані методи є більш ефективними, витрати на їх реалізацію та тестування також значно зростають.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, при цьому еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між крос-роллапами реалізується на основі нижнього рівня транспортного шару, при цьому простір комунікаційного блоку кожного роллапа є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза блокчейном, використовуючи релейний ланцюг як контрольний рівень, а не рівень даних. Це оновлення підвищить можливості зв'язку між роллапами разом з еластичним масштабуванням, що ще більше зміцнить вертикальні можливості масштабування системи.
В权衡 інших протоколів
Відомо, що підвищення продуктивності часто досягається за рахунок жертвування децентралізацією та безпекою. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не є вражаючою.
Солана
Solana не використовує шардінг-архітектуру Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарового архітектурного рішення з високою пропускною спроможністю, покладаючись на історичне підтвердження, паралельну обробку ЦП та механізм консенсусу на основі лідера, теоретична TPS може досягати 65 000.
Одним з ключових дизайнів є його попередньо відкритий та перевіряємий механізм призначення лідера:
Історія показує, що паралельна обробка має дуже високі вимоги до апаратного забезпечення, що призводить до централізації валідаційних вузлів. Чим більше вузлів здійснює стейкінг, тим більша ймовірність, що вони зможуть створити блок, тоді як у малих вузлів майже немає слотів, що ще більше посилює централізацію і підвищує ризик знеструмлення системи після атаки.
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 всі роллапи мають єдину гарантію безпеки; тоді як підмережі Avalanche не мають стандартної гарантії безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, доведеться поступитися продуктивністю, і складно надати визначені гарантії безпеки.
Ефіріум
Стратегія масштабування Ethereum полягає в ставці на масштабованість рівня rollup, а не в прямому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблеми, а передає її на верхній рівень стеку.
Оптимістичний ролап
Наразі більшість оптимістичних роллапів є централізованими, що призводить до недостатньої безпеки, ізоляції один від одного та високої затримки (потрібно чекати періоду підтвердження шахрайства, зазвичай кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових доказів є надзвичайно високими, а механізм "переможець отримує все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що може викликати затори в мережі та збільшення вартості gas під час високого попиту, що впливає на користувацький досвід.
У порівнянні, вартість ZK rollup, що є тюрінгом, приблизно в 2x10^6 разів більша, ніж безпековий протокол основної криптоекономіки Polkadot.
Крім того, проблема доступності даних у ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, необхідно надати повні дані транзакцій. Це зазвичай залежить від додаткових рішень щодо доступності даних, що додатково підвищує витрати та збори для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності або попереднього довіри заради ефективності, а досягнув багатовимірного балансу безпеки, децентралізації та високої продуктивності шляхом гнучкого масштабування, протоколів без дозволів, єдиного шару безпеки та гнучкого управління ресурсами.
У сучасному прагненні до більш масштабного впровадження, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.