В权衡 розширюваності Блокчейн: вибір Polkadot та Web3
В умовах постійного прагнення до підвищення ефективності в Блокчейн, поступово виникає ключове питання: як уникнути жертвування безпекою та еластичністю системи під час розширення продуктивності?
Це не лише виклик на технічному рівні, а й глибокий вибір у проектуванні архітектури. Для екосистеми Web3 просто прагнути до швидших систем, ігноруючи довіру та безпеку, важко підтримувати справжні стійкі інновації.
Як важливий рушій масштабованості Web3, чи зробив Polkadot певні компроміси в прагненні до високої пропускної здатності та низької затримки? Чи став його модель rollup компромісом в питаннях децентралізації, безпеки чи міжмережевої взаємодії?
У цій статті буде обговорено ці питання, глибоко проаналізовано компроміси Polkadot у дизайні масштабованості та проведено порівняння з рішеннями інших основних публічних блокчейнів, щоб дослідити їхні різні вибори між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається розробка розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів і релейного ланцюга, чи може це в певних аспектах впровадити ризики централізації? Чи можливо виникнення єдиної точки відмови або контролю, що вплине на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника з'єднувальної ланцюга, а його комунікація використовує механізм протоколу collator. Цей протокол повністю безкоштовний, без довіри, будь-хто з підключенням до мережі може його використовувати, підключаючи невелику кількість вузлів з'єднувальної ланцюга та подаючи запити на зміни стану rollup. Ці запити перевіряються певним core з'єднувальної ланцюга, і єдина умова - зміна стану повинна бути дійсною, в іншому випадку стан rollup не буде просунуто.
Торгівля вертикальним розширенням
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість введена функцією «гнучкого масштабування». Під час проектування було виявлено, що оскільки валідація блоків rollup не фіксується на певному ядрі, це може вплинути на його гнучкість.
Оскільки протокол подачі блоків до проміжного ланцюга є бездозвільним та бездокументним, будь-хто може подати блок для перевірки на будь-якому основному вузлі, призначеному для rollup. Зловмисники можуть використати це, повторно подаючи вже перевірені законні блоки на різні основні вузли, зловмисно витрачаючи ресурси та знижуючи загальну пропускну здатність і ефективність rollup.
Мета Polkadot полягає в підтримці гнучкості rollup та ефективному використанні ресурсів релейної ланцюга без шкоди для ключових характеристик системи.
Чи варто довіряти Sequencer?
Одним із простих рішень є налаштування протоколу на «з ліцензією»: наприклад, використання механізму білого списку або за замовчуванням довіряти сортувальнику, який не буде вдаватися до зловмисних дій, тим самим забезпечуючи активність rollup.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки необхідно зберегти характеристики «без довіри» та «без дозволу» системи. Будь-хто має мати можливість використовувати протокол колаторів для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточне рішення Polkadot: передати вирішення проблеми повністю функції перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом всієї інформації про консенсус, тому в виході потрібно чітко вказати, на якому ядрі Polkadot має виконуватись верифікація.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати перетворення стану rollup у процесі доступності та забезпечить правильність розподілу core через економічний протокол ELVES.
Перед тим, як будь-який блок rollup буде записано в шар даних доступності Polkadot, група з близько 5 валідаторів спочатку перевірить його законність. Вони отримують кандидати на квитанції та докази дійсності, подані сортувальником, які містять блоки rollup і відповідні докази зберігання. Цю інформацію обробить функція перевірки паралельного ланцюга і буде повторно виконана валідаторами на релейному ланцюзі.
У результатах перевірки є core selector, який вказує, на якому core слід перевіряти блок. Валідаор порівнює цей індекс з власним core; якщо вони не збігаються, цей блок буде відкинуто.
Цей механізм забезпечує те, що система завжди зберігає властивості, які не потребують довіри та дозволу, запобігаючи маніпуляціям з боку зловмисників, таких як сортувальники, щодо місця верифікації, гарантуючи, що навіть якщо rollup використовує кілька core, він зберігає еластичність.
Безпека
У процесі прагнення до розширювальності Polkadot не йшов на компроміс у безпеці. Безпека rollup забезпечується релейною мережею, і для підтримки життєздатності потрібен лише один чесний сортувальник.
Завдяки протоколу ELVES, Polkadot повністю розширює свою безпеку на всі rollup, перевіряючи всі обчислення на core, без жодних обмежень чи припущень щодо кількості використовуваних core.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання Тюрінг-повних обчислень у середовищі WebAssembly, за умови, що одноразове виконання завершується за 2 секунди. Завдяки еластичному масштабуванню загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, зростає, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом у проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, яка може покладатися на змінні на ланцюгу або поза ним. Наприклад:
Проста стратегія: завжди використовувати фіксовану кількість core або вручну налаштовувати поза ланцюгом;
Легка стратегія: моніторинг специфічного навантаження транзакцій у мемпулі вузла;
Автоматизовані стратегії: за допомогою історичних даних та інтерфейсу XCM заздалегідь викликати службу coretime для налаштування ресурсів.
Автоматизований спосіб, хоча й є більш ефективним, але витрати на його реалізацію та тестування також суттєво зростають.
Інтероперабельність
Polkadot підтримує взаємодію між різними роллапами, при цьому еластичне масштабування не впливає на пропускну здатність передачі повідомлень.
Комунікація повідомлень між крос-роллапами реалізується на основі підлеглого транспортного рівня, а простір комунікаційного блоку кожного роллапу є фіксованим і не залежить від кількості виділених ядер.
У майбутньому 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: зменшення навантаження на окремий Блок для досягнення масштабованості. Але Avalanche дозволяє валідаторам вільно обирати участь у підмережах, а підмережі можуть встановлювати географічні, KYC та інші додаткові вимоги, жертвуючи децентралізацією та безпекою.
У Polkadot всі rollup ділять єдине забезпечення безпеки; натомість підмережі Avalanche не мають за замовчуванням забезпечення безпеки, а деякі можуть бути повністю централізованими. Щоб підвищити безпеку, все ще потрібно йти на компроміс у продуктивності, і важко надати гарантовані зобов'язання безпеки.
Ефіріум
Розширювальна стратегія Ethereum полягає в ставці на масштабованість шару rollup, а не в прямому вирішенні проблем на базовому рівні. Цей підхід в основному не вирішує проблему, а лише передає її на верхній рівень стеку.
Оптимістичний Ролап
На сьогодні більшість оптимістичних роллапів є централізованими (деякі навіть мають лише один послідовник), що створює проблеми з недостатньою безпекою, ізольованістю та високою затримкою (необхідно чекати період підтвердження шахрайства, який зазвичай триває кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових доказів є надзвичайно високими, а механізм «переможець забирає все» може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній пакетній обробці, що під час високого попиту може викликати затори в мережі, підвищення газу та вплинути на досвід користувачів.
Порівняно з цим, вартість Turing-complete ZK rollup приблизно в 2x10^6 разів перевищує вартість основного криптоекономічного безпекового протоколу Polkadot.
Крім того, проблема доступності даних ZK rollup також посилить його недоліки. Щоб будь-хто міг перевірити транзакцію, все ще потрібно надати повні дані транзакції. Це зазвичай залежить від додаткових рішень щодо доступності даних, що додатково підвищує витрати та комісії користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності чи попередньої довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через еластичне масштабування, бездозвільний дизайн протоколів, єдиний рівень безпеки та гнучкі механізми управління ресурсами.
У прагненні до більшого масштабу застосування сьогодні, "нульова довіра до масштабованості", якої дотримується Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
6
Репост
Поділіться
Прокоментувати
0/400
Fren_Not_Food
· 07-23 13:22
Проект звучить досить добре, але давайте подивимося на фактичні результати.
Переглянути оригіналвідповісти на0
BlockchainDecoder
· 07-23 11:10
Згідно з нещодавніми даними дослідницької групи Cho, одноланковий TPS зазвичай нижчий за 3k, питання компромісу потребує термінового вирішення.
Polkadot безкомпромісна масштабованість: новий вибір для екосистеми Web3
В权衡 розширюваності Блокчейн: вибір Polkadot та Web3
В умовах постійного прагнення до підвищення ефективності в Блокчейн, поступово виникає ключове питання: як уникнути жертвування безпекою та еластичністю системи під час розширення продуктивності?
Це не лише виклик на технічному рівні, а й глибокий вибір у проектуванні архітектури. Для екосистеми Web3 просто прагнути до швидших систем, ігноруючи довіру та безпеку, важко підтримувати справжні стійкі інновації.
Як важливий рушій масштабованості Web3, чи зробив Polkadot певні компроміси в прагненні до високої пропускної здатності та низької затримки? Чи став його модель rollup компромісом в питаннях децентралізації, безпеки чи міжмережевої взаємодії?
У цій статті буде обговорено ці питання, глибоко проаналізовано компроміси Polkadot у дизайні масштабованості та проведено порівняння з рішеннями інших основних публічних блокчейнів, щоб дослідити їхні різні вибори між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається розробка розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів і релейного ланцюга, чи може це в певних аспектах впровадити ризики централізації? Чи можливо виникнення єдиної точки відмови або контролю, що вплине на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника з'єднувальної ланцюга, а його комунікація використовує механізм протоколу collator. Цей протокол повністю безкоштовний, без довіри, будь-хто з підключенням до мережі може його використовувати, підключаючи невелику кількість вузлів з'єднувальної ланцюга та подаючи запити на зміни стану rollup. Ці запити перевіряються певним core з'єднувальної ланцюга, і єдина умова - зміна стану повинна бути дійсною, в іншому випадку стан rollup не буде просунуто.
Торгівля вертикальним розширенням
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Ця нова можливість введена функцією «гнучкого масштабування». Під час проектування було виявлено, що оскільки валідація блоків rollup не фіксується на певному ядрі, це може вплинути на його гнучкість.
Оскільки протокол подачі блоків до проміжного ланцюга є бездозвільним та бездокументним, будь-хто може подати блок для перевірки на будь-якому основному вузлі, призначеному для rollup. Зловмисники можуть використати це, повторно подаючи вже перевірені законні блоки на різні основні вузли, зловмисно витрачаючи ресурси та знижуючи загальну пропускну здатність і ефективність rollup.
Мета Polkadot полягає в підтримці гнучкості rollup та ефективному використанні ресурсів релейної ланцюга без шкоди для ключових характеристик системи.
Чи варто довіряти Sequencer?
Одним із простих рішень є налаштування протоколу на «з ліцензією»: наприклад, використання механізму білого списку або за замовчуванням довіряти сортувальнику, який не буде вдаватися до зловмисних дій, тим самим забезпечуючи активність rollup.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки необхідно зберегти характеристики «без довіри» та «без дозволу» системи. Будь-хто має мати можливість використовувати протокол колаторів для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточне рішення Polkadot: передати вирішення проблеми повністю функції перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом всієї інформації про консенсус, тому в виході потрібно чітко вказати, на якому ядрі Polkadot має виконуватись верифікація.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати перетворення стану rollup у процесі доступності та забезпечить правильність розподілу core через економічний протокол ELVES.
Перед тим, як будь-який блок rollup буде записано в шар даних доступності Polkadot, група з близько 5 валідаторів спочатку перевірить його законність. Вони отримують кандидати на квитанції та докази дійсності, подані сортувальником, які містять блоки rollup і відповідні докази зберігання. Цю інформацію обробить функція перевірки паралельного ланцюга і буде повторно виконана валідаторами на релейному ланцюзі.
У результатах перевірки є core selector, який вказує, на якому core слід перевіряти блок. Валідаор порівнює цей індекс з власним core; якщо вони не збігаються, цей блок буде відкинуто.
Цей механізм забезпечує те, що система завжди зберігає властивості, які не потребують довіри та дозволу, запобігаючи маніпуляціям з боку зловмисників, таких як сортувальники, щодо місця верифікації, гарантуючи, що навіть якщо rollup використовує кілька core, він зберігає еластичність.
Безпека
У процесі прагнення до розширювальності Polkadot не йшов на компроміс у безпеці. Безпека rollup забезпечується релейною мережею, і для підтримки життєздатності потрібен лише один чесний сортувальник.
Завдяки протоколу ELVES, Polkadot повністю розширює свою безпеку на всі rollup, перевіряючи всі обчислення на core, без жодних обмежень чи припущень щодо кількості використовуваних core.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання Тюрінг-повних обчислень у середовищі WebAssembly, за умови, що одноразове виконання завершується за 2 секунди. Завдяки еластичному масштабуванню загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, зростає, але типи обчислень не підлягають змінам.
Складність
Вищий пропускний здатність і нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом у проектуванні систем.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime, щоб підтримувати постійний рівень безпеки. Вони також повинні реалізувати частину вимог RFC103, щоб адаптуватися до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, яка може покладатися на змінні на ланцюгу або поза ним. Наприклад:
Автоматизований спосіб, хоча й є більш ефективним, але витрати на його реалізацію та тестування також суттєво зростають.
Інтероперабельність
Polkadot підтримує взаємодію між різними роллапами, при цьому еластичне масштабування не впливає на пропускну здатність передачі повідомлень.
Комунікація повідомлень між крос-роллапами реалізується на основі підлеглого транспортного рівня, а простір комунікаційного блоку кожного роллапу є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також буде підтримувати позамережеву передачу повідомлень, використовуючи релейну мережу як контрольний рівень, а не рівень даних. Це оновлення дозволить підвищити можливості комунікації між 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, а не в прямому вирішенні проблем на базовому рівні. Цей підхід в основному не вирішує проблему, а лише передає її на верхній рівень стеку.
Оптимістичний Ролап
На сьогодні більшість оптимістичних роллапів є централізованими (деякі навіть мають лише один послідовник), що створює проблеми з недостатньою безпекою, ізольованістю та високою затримкою (необхідно чекати період підтвердження шахрайства, який зазвичай триває кілька днів).
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових доказів є надзвичайно високими, а механізм «переможець забирає все» може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній пакетній обробці, що під час високого попиту може викликати затори в мережі, підвищення газу та вплинути на досвід користувачів.
Порівняно з цим, вартість Turing-complete ZK rollup приблизно в 2x10^6 разів перевищує вартість основного криптоекономічного безпекового протоколу Polkadot.
Крім того, проблема доступності даних ZK rollup також посилить його недоліки. Щоб будь-хто міг перевірити транзакцію, все ще потрібно надати повні дані транзакції. Це зазвичай залежить від додаткових рішень щодо доступності даних, що додатково підвищує витрати та комісії користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності чи попередньої довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через еластичне масштабування, бездозвільний дизайн протоколів, єдиний рівень безпеки та гнучкі механізми управління ресурсами.
У прагненні до більшого масштабу застосування сьогодні, "нульова довіра до масштабованості", якої дотримується Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.