Баланс масштабованості Блокчейн: на прикладі Polkadot
Сьогодні, коли технологія Блокчейн постійно прагне до вищої ефективності, з'являється ключове питання: як підвищити продуктивність, не жертвуючи безпекою та гнучкістю системи? Це не лише виклик на технічному рівні, а й глибокий вибір в архітектурному проектуванні. Для екосистеми Web3 швидша система, якщо вона базується на жертві довіри та безпеки, часто не може підтримувати справжні стійкі інновації.
Ця стаття глибоко дослідить компроміси та вагомість дизайну розширюваності Polkadot, а також порівняє його рішення з іншими основними публічними блокчейнами, аналізуючи різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга (Relay Chain). Робота Rollup залежить від сортувальника (sequencer), який підключений до релейного ланцюга, його спілкування використовує механізм протоколу collator. Цей протокол абсолютно не потребує дозволу, не вимагає довіри, будь-хто з підключенням до мережі може його використовувати, підключити невелику кількість вузлів релейного ланцюга та подати запити на зміни стану rollup. Ці запити перевіряються якимось основним елементом релейного ланцюга, потрібно лише виконати одну умову: вони повинні бути дійсними змінами стану, інакше стан цього rollup не буде просунуто.
Торгівля вертикальним розширенням
Ролап може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість введена функцією "еластичного масштабування" (Elastic Scaling). Під час процесу проектування було виявлено, що оскільки верифікація блоків ролапу не фіксується на певному ядрі, це може вплинути на його еластичність.
Оскільки протокол подачі блоків до релейного ланцюга є бездозвільним і бездостовірним, будь-хто може подати блок для перевірки на будь-якому з core, призначених для rollup. Зловмисники можуть скористатися цим, повторно подаючи вже перевірені легітимні блоки на різні core, навмисно витрачаючи ресурси, що призводить до зниження загальної пропускної здатності та ефективності rollup.
Метою Polkadot є підтримка еластичності rollup та ефективного використання ресурсів релейного ланцюга без впливу на ключові характеристики системи.
Проблема довіри Sequencer
Простим рішенням є встановлення протоколу як "з дозволом": наприклад, впровадження механізму білого списку або за замовчуванням довіра до сортувальника, що не діє зловмисно, щоб забезпечити активність rollup. Однак у концепції дизайну Polkadot ми не можемо робити ніяких довірчих припущень щодо sequencer, оскільки потрібно підтримувати характеристики "без довіри" та "без дозволу" системи. Кожен повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю передати проблему функції перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому в результатах повинно бути чітко зазначено, на якому ядрі Polkadot потрібно виконати верифікацію.
Цей дизайн забезпечує подвійний захист гнучкості та безпеки. Polkadot повторно виконає перетворення стану rollup у процесі доступності та забезпечить правильність розподілу core за допомогою економічного протоколу ELVES.
Перед записом у будь-який rollup Блок в шарі доступності даних Polkadot (DA) група з приблизно 5 валідаторів спочатку перевіряє його легітимність. Вони отримують кандидата на квитанцію (candidate receipt) та доказ дійсності (PoV), в яких міститься rollup Блок та відповідні докази зберігання. Цю інформацію обробляє функція перевірки паралельного ланцюга, яка повторно виконується валідаторами в релейному ланцюзі.
У результатах верифікації міститься core selector, який використовується для вказівки, на якому core слід верифікувати блок. Верифікатор порівнює цей індекс з тим, за який він відповідає; якщо вони не співпадають, блок буде відкинуто.
Цей механізм забезпечує те, що система завжди зберігає властивості без довіри та без дозволу, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, та гарантує, що навіть при використанні кількох ядер у rollup система залишається стійкою.
безпека
У процесі прагнення до масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпеку rollup забезпечує релейний ланцюг, для підтримки життєздатності достатньо одного чесного сортировщика.
За допомогою протоколу ELVES, Polkadot розширює свою безпеку на всі rollup, перевіряючи всі обчислення на core, без жодних обмежень чи припущень щодо кількості використовуваних ядер.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання Turing-complete обчислень у середовищі WebAssembly, за умови, що одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню, загальний обсяг обчислень, що можуть бути виконані за 6-секундний цикл, зростає, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом у системному дизайні.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні виконувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть залежати від змінних на ланцюзі або поза ним. Наприклад:
Проста стратегія: завжди використовувати фіксовану кількість core, або вручну налаштовувати через офлайн.
Легка стратегія: моніторинг специфічного навантаження транзакцій у вузлі mempool;
Автоматизовані стратегії: через історичні дані та XCM інтерфейс заздалегідь викликати coretime сервіс для налаштування ресурсів.
Автоматизований спосіб, хоча і є більш ефективним, але витрати на реалізацію та тестування також суттєво зростають.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між rollup реалізується за рахунок базового рівня передачі, а простір комунікаційних блоків кожного rollup є фіксованим і не залежить від кількості призначених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза ланцюгом (off-chain messaging), де релейна ланцюг буде виступати як контрольна площина, а не як площина даних. Це оновлення підвищить можливості зв'язку між 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: зменшити навантаження на окремий Блок для досягнення масштабованості. Але Avalanche дозволяє валідаторам вільно обирати участь у підмережі, а також підмережі можуть встановлювати географічні, KYC та інші додаткові вимоги, жертвуючи децентралізацією та безпекою.
У Polkadot всі rollup ділять єдине забезпечення безпеки; тоді як підмережі Avalanche не мають стандартних гарантій безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ще потрібно буде піти на компроміс з продуктивністю, і важко надати визначеність в обіцянках безпеки.
Ефіріум
Розширювальна стратегія Ethereum полягає в ставці на масштабованість на рівні rollup, а не в безпосередньому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблему, а лише передає її на верхній рівень стека.
Оптимістичний Роллап
Наразі більшість Optimistic rollup є централізованими (деякі з них навіть мають лише одного секвенсера), що викликає проблеми з недостатньою безпекою, ізольованістю один від одного, високою затримкою (необхідно чекати на період доказу шахрайства, зазвичай кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені в одній транзакції. Вимоги до обчислень для генерації нульових знань дуже високі, і механізм "переможець забирає все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати затори в мережі, підвищення gas та вплинути на досвід користувачів.
У порівнянні, витрати на ZK rollup, що є тюрингом, приблизно в 2x10^6 разів перевищують витрати на основний протокол економічної безпеки Polkadot.
Крім того, проблема доступності даних ZK rollup також посилює його недоліки. Для забезпечення того, щоб будь-хто міг перевірити транзакції, все ще потрібно надати повні дані транзакцій. Це зазвичай залежить від додаткових рішень з доступності даних, що ще більше підвищує витрати та комісії користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
У порівнянні з іншими публічними блокчейнами, Polkadot не пішов шляхом централізації заради продуктивності чи заздалегідь визначеного довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю завдяки еластичному масштабуванню, бездозвільному дизайну протоколів, єдиному рівню безпеки та гнучкому механізму управління ресурсами.
У пошуках більш масштабних застосувань сьогодні, "нульова довіра до розширення", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
9 лайків
Нагородити
9
6
Поділіться
Прокоментувати
0/400
GateUser-a5fa8bd0
· 5год тому
dot слід добре вивчити! Старий бізнес більше не надійний.
Переглянути оригіналвідповісти на0
AirdropworkerZhang
· 08-01 00:33
Ця ефективність надзвичайно висока, витрати надзвичайно низькі, я, бос, пішов на майнінг.
Переглянути оригіналвідповісти на0
MEVHunter
· 07-31 10:51
мех... релейна ланцюг dot все ще має вузькі місця під важким тиском пулу пам'яті, якщо чесно. бачив токсичні сплески потоку минулого тижня
Переглянути оригіналвідповісти на0
Lonely_Validator
· 07-31 10:51
Старий гравець публічних ланцюгів, Dot завжди в моді.
Гнучке масштабування Polkadot: безкомпромісний баланс продуктивності та безпеки Web3
Баланс масштабованості Блокчейн: на прикладі Polkadot
Сьогодні, коли технологія Блокчейн постійно прагне до вищої ефективності, з'являється ключове питання: як підвищити продуктивність, не жертвуючи безпекою та гнучкістю системи? Це не лише виклик на технічному рівні, а й глибокий вибір в архітектурному проектуванні. Для екосистеми Web3 швидша система, якщо вона базується на жертві довіри та безпеки, часто не може підтримувати справжні стійкі інновації.
Ця стаття глибоко дослідить компроміси та вагомість дизайну розширюваності Polkadot, а також порівняє його рішення з іншими основними публічними блокчейнами, аналізуючи різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга (Relay Chain). Робота Rollup залежить від сортувальника (sequencer), який підключений до релейного ланцюга, його спілкування використовує механізм протоколу collator. Цей протокол абсолютно не потребує дозволу, не вимагає довіри, будь-хто з підключенням до мережі може його використовувати, підключити невелику кількість вузлів релейного ланцюга та подати запити на зміни стану rollup. Ці запити перевіряються якимось основним елементом релейного ланцюга, потрібно лише виконати одну умову: вони повинні бути дійсними змінами стану, інакше стан цього rollup не буде просунуто.
Торгівля вертикальним розширенням
Ролап може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість введена функцією "еластичного масштабування" (Elastic Scaling). Під час процесу проектування було виявлено, що оскільки верифікація блоків ролапу не фіксується на певному ядрі, це може вплинути на його еластичність.
Оскільки протокол подачі блоків до релейного ланцюга є бездозвільним і бездостовірним, будь-хто може подати блок для перевірки на будь-якому з core, призначених для rollup. Зловмисники можуть скористатися цим, повторно подаючи вже перевірені легітимні блоки на різні core, навмисно витрачаючи ресурси, що призводить до зниження загальної пропускної здатності та ефективності rollup.
Метою Polkadot є підтримка еластичності rollup та ефективного використання ресурсів релейного ланцюга без впливу на ключові характеристики системи.
Проблема довіри Sequencer
Простим рішенням є встановлення протоколу як "з дозволом": наприклад, впровадження механізму білого списку або за замовчуванням довіра до сортувальника, що не діє зловмисно, щоб забезпечити активність rollup. Однак у концепції дизайну Polkadot ми не можемо робити ніяких довірчих припущень щодо sequencer, оскільки потрібно підтримувати характеристики "без довіри" та "без дозволу" системи. Кожен повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю передати проблему функції перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому в результатах повинно бути чітко зазначено, на якому ядрі Polkadot потрібно виконати верифікацію.
Цей дизайн забезпечує подвійний захист гнучкості та безпеки. Polkadot повторно виконає перетворення стану rollup у процесі доступності та забезпечить правильність розподілу core за допомогою економічного протоколу ELVES.
Перед записом у будь-який rollup Блок в шарі доступності даних Polkadot (DA) група з приблизно 5 валідаторів спочатку перевіряє його легітимність. Вони отримують кандидата на квитанцію (candidate receipt) та доказ дійсності (PoV), в яких міститься rollup Блок та відповідні докази зберігання. Цю інформацію обробляє функція перевірки паралельного ланцюга, яка повторно виконується валідаторами в релейному ланцюзі.
У результатах верифікації міститься core selector, який використовується для вказівки, на якому core слід верифікувати блок. Верифікатор порівнює цей індекс з тим, за який він відповідає; якщо вони не співпадають, блок буде відкинуто.
Цей механізм забезпечує те, що система завжди зберігає властивості без довіри та без дозволу, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, та гарантує, що навіть при використанні кількох ядер у rollup система залишається стійкою.
безпека
У процесі прагнення до масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпеку rollup забезпечує релейний ланцюг, для підтримки життєздатності достатньо одного чесного сортировщика.
За допомогою протоколу ELVES, Polkadot розширює свою безпеку на всі rollup, перевіряючи всі обчислення на core, без жодних обмежень чи припущень щодо кількості використовуваних ядер.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання Turing-complete обчислень у середовищі WebAssembly, за умови, що одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню, загальний обсяг обчислень, що можуть бути виконані за 6-секундний цикл, зростає, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом у системному дизайні.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні виконувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть залежати від змінних на ланцюзі або поза ним. Наприклад:
Автоматизований спосіб, хоча і є більш ефективним, але витрати на реалізацію та тестування також суттєво зростають.
Інтероперабельність
Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Комунікація повідомлень між rollup реалізується за рахунок базового рівня передачі, а простір комунікаційних блоків кожного rollup є фіксованим і не залежить від кількості призначених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза ланцюгом (off-chain messaging), де релейна ланцюг буде виступати як контрольна площина, а не як площина даних. Це оновлення підвищить можливості зв'язку між rollup з еластичним масштабуванням, що ще більше посилить вертикальні можливості масштабування системи.
В权衡 інших протоколів
Як відомо, підвищення продуктивності часто досягається ціною централізації та безпеки. Але з точки зору коефіцієнта Накамото, навіть якщо деякі суперники Polkadot мають нижчий рівень децентралізації, їх продуктивність також не є задовільною.
Солана
Solana не використовує архітектуру шардінгу Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарової архітектури з високою пропускною спроможністю, спираючись на історичне доведення (PoH), паралельну обробку ЦП та механізм консенсусу на основі лідера, теоретичний TPS може досягати 65,000.
Одним з ключових дизайнів є його заздалегідь відкритий і перевіряємий механізм розкладу лідера:
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: зменшити навантаження на окремий Блок для досягнення масштабованості. Але Avalanche дозволяє валідаторам вільно обирати участь у підмережі, а також підмережі можуть встановлювати географічні, KYC та інші додаткові вимоги, жертвуючи децентралізацією та безпекою.
У Polkadot всі rollup ділять єдине забезпечення безпеки; тоді як підмережі Avalanche не мають стандартних гарантій безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ще потрібно буде піти на компроміс з продуктивністю, і важко надати визначеність в обіцянках безпеки.
Ефіріум
Розширювальна стратегія Ethereum полягає в ставці на масштабованість на рівні rollup, а не в безпосередньому вирішенні проблеми на базовому рівні. Цей підхід по суті не вирішує проблему, а лише передає її на верхній рівень стека.
Оптимістичний Роллап
Наразі більшість Optimistic rollup є централізованими (деякі з них навіть мають лише одного секвенсера), що викликає проблеми з недостатньою безпекою, ізольованістю один від одного, високою затримкою (необхідно чекати на період доказу шахрайства, зазвичай кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені в одній транзакції. Вимоги до обчислень для генерації нульових знань дуже високі, і механізм "переможець забирає все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати затори в мережі, підвищення gas та вплинути на досвід користувачів.
У порівнянні, витрати на ZK rollup, що є тюрингом, приблизно в 2x10^6 разів перевищують витрати на основний протокол економічної безпеки Polkadot.
Крім того, проблема доступності даних ZK rollup також посилює його недоліки. Для забезпечення того, щоб будь-хто міг перевірити транзакції, все ще потрібно надати повні дані транзакцій. Це зазвичай залежить від додаткових рішень з доступності даних, що ще більше підвищує витрати та комісії користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
У порівнянні з іншими публічними блокчейнами, Polkadot не пішов шляхом централізації заради продуктивності чи заздалегідь визначеного довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю завдяки еластичному масштабуванню, бездозвільному дизайну протоколів, єдиному рівню безпеки та гнучкому механізму управління ресурсами.
У пошуках більш масштабних застосувань сьогодні, "нульова довіра до розширення", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.