Масштабованість та компроміси: як Polkadot шукає баланс у екосистемі Web3
Сьогодні, коли блокчейн постійно прагне до більшої ефективності, з'являється ключове питання: як уникнути жертвування безпекою та гнучкістю системи під час розширення продуктивності? Це не лише технічний виклик, а й глибокий вибір архітектурного дизайну. Для екосистеми Web3, якщо швидша система будується на основі жертвування довірою та безпекою, вона часто не здатна підтримувати справжні стійкі інновації.
Polkadot як важливий рушій масштабованості Web3, чи зробив він певні жертви в досягненні цілей високої пропускної здатності та низької затримки? Чи робить його модель rollup поступки в децентралізації, безпеці або взаємодії мереж? У цій статті ми розглянемо ці питання, глибоко проаналізуємо компроміси та важливі аспекти дизайну масштабованості Polkadot і порівняємо їх з рішеннями інших основних публічних блокчейнів, досліджуючи їхні різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та централізованого релейного ланцюга, чи може це в певних аспектах ввести ризики централізації? Чи можливо утворення єдиної точки відмови або контролю, що вплине на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника, що підключений до релейного ланцюга, і його зв'язок використовує механізм, відомий як коллатор-протокол. Цей протокол повністю безкоштовний, без довіри, будь-хто, хто має підключення до мережі, може його використовувати, підключивши невелику кількість вузлів релейного ланцюга та подавши запит на зміни стану rollup. Ці запити перевіряються якимось ядром релейного ланцюга, за умови, що вони є дійсними змінами стану, інакше стан цього rollup не буде просунуто.
Торгівля вертикальним розширенням
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Цю нову можливість вводить функція «еластичного масштабування». У процесі проєктування ми виявили, що оскільки валідація блоків rollup не фіксується на певному ядрі, це може вплинути на його еластичність.
Оскільки протокол подання блоків до релейного ланцюга є бездозвільним і бездоверчим, будь-хто може подавати блоки на будь-який основний вузол, призначений для роллапу, для перевірки. Зловмисники можуть скористатися цим, повторно подаючи раніше перевірені легітимні блоки на різні основні вузли, зловмисно споживаючи ресурси, тим самим знижуючи загальну пропускну здатність та ефективність роллапу.
Мета Polkadot полягає в забезпеченні гнучкості rollup та ефективному використанні ресурсів релейної ланцюга без впливу на критичні характеристики системи.
Чи варто довіряти Sequencer?
Простим рішенням є налаштування протоколу на "з дозволом": наприклад, використання механізму білого списку або за замовчуванням довіра до сортировщика, який не буде здійснювати зловмисні дії, що забезпечує активність rollup.
Однак, у концепції дизайну Polkadot ми не можемо робити жодних довірчих припущень щодо sequencer, оскільки потрібно зберегти характеристики «без довіри» та «без дозволу» системи. Будь-хто має можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: безкомпромісне рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю покласти вирішення проблеми на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому вивід повинен чітко вказувати, на якому ядрі Polkadot має бути виконано перевірку.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot повторно виконає перехід стану rollup у процесі доступності та гарантує правильність розподілу core через економічний протокол ELVES.
Перед записом даних у шар доступності Polkadot з будь-якого rollup блоку, група з приблизно 5 валідаторів спочатку перевіряє їх легітимність. Вони отримують кандидатські квитанції та докази дійсності, подані сортувальником, які містять rollup блок та відповідні докази зберігання. Цю інформацію обробляє функція валідації паралельного ланцюга, яка повторно виконується валідаторами на релейному ланцюзі.
У результаті перевірки міститься core selector, що вказує, на якому core слід перевірити блок. Верифікатор перевіряє, чи відповідає цей індекс тому core, за який він відповідає; якщо ні, цей блок буде відхилено.
Цей механізм забезпечує постійне збереження системою атрибутів, які не потребують довіри та дозволу, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, щодо розташування підтвердження, що гарантує еластичність навіть при використанні кількох ядер у rollup.
безпека
У процесі досягнення масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпека rollup забезпечується релейним ланцюгом, і для підтримки живучості потрібен лише один чесний сортувальник.
Завдяки протоколу ELVES, Polkadot розширює свою безпеку на всі rollup, перевіряючи всі обчислення на ядрах без необхідності обмежувати або робити припущення щодо кількості використовуваних ядер.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання обчислень з повною Тюрінговою здатністю в середовищі WebAssembly, якщо одне виконання завершується за 2 секунди. Завдяки еластичному масштабуванню, загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.
складність
Вищий пропускний здатності та нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом у системному дизайні.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime для підтримки стабільного рівня безпеки. Вони також повинні виконувати частину вимог RFC103 для адаптації до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть покладатися на змінні на ланцюзі або поза ним. Наприклад:
Проста стратегія: завжди використовувати фіксовану кількість core або вручну налаштовувати поза ланцюгом;
Легка стратегія: моніторинг специфічного навантаження транзакцій у mempool вузла;
Автоматизовані стратегії: за допомогою історичних даних та XCM інтерфейсу заздалегідь викликати сервіс coretime для налаштування ресурсів.
Хоча автоматизовані методи є більш ефективними, витрати на реалізацію та тестування також суттєво зростають.
взаємодія
Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Передача повідомлень між роллапами реалізується на базі підлеглого транспортного рівня, а обсяг комунікаційних блоків кожного роллапа є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза ланцюгом, де релейна ланцюг буде виступати в ролі контрольного рівня, а не рівня даних. Це оновлення покращить можливості зв'язку між роллапами разом із гнучким масштабуванням, додатково підвищуючи вертикальні можливості масштабування системи.
Які компроміси зробили інші протоколи?
Як відомо, підвищення продуктивності часто досягається за рахунок жертвування децентралізацією та безпекою. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не вражає.
Солана
Solana не використовує архітектуру шардінгу Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарового високопродуктивного архітектурного рішення, що спирається на історичне доведення (PoH), паралельну обробку ЦП і механізм консенсусу на основі лідерства, теоретичний TPS може досягати 65,000.
Одним з ключових дизайнів є попередньо оприлюднений та перевіряємий механізм розкладу лідерів:
На початку кожного епохи (приблизно кожні два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейку.
Чим більше ви ставите, тим більше отримуєте. Наприклад, валідатор, який ставить 1%, отримає приблизно 1% шансів на блокування;
Всі майнери заздалегідь оголошують, що підвищує ризик цілеспрямованих DDoS-атак на мережу та частих збоїв.
PoH та паралельна обробка мають дуже високі вимоги до апаратного забезпечення, що призводить до централізації вузлів перевірки. Чим більше плата, тим більша ймовірність, що вузол створить блок, маленькі вузли майже не мають слоту, що ще більше посилює централізацію та підвищує ризик зупинки системи після атаки.
Solana, прагнучи до TPS, жертвує децентралізацією та стійкістю до атак, її коефіцієнт Накамото становить лише 20, що значно нижче за 172 у Polkadot.
ТОН
Один з блокчейн-проектів стверджує, що TPS може досягати 104,715, але це число було досягнуто у приватній тестовій мережі, з 256 вузлами, за ідеальних умов мережі та апаратного забезпечення. У той же час Polkadot досяг 128K TPS на децентралізованій публічній мережі.
У цього проекту є проблеми з механізмом консенсусу: ідентичність вузлів перевірки фрагментів може бути заздалегідь розкрита. Його білий документ також чітко зазначає, що хоча це може оптимізувати пропускну здатність, це також може бути зловмисно використано. Через відсутність механізму "банкрутства гравців" зловмисники можуть чекати, поки певний фрагмент повністю контролюється ними, або шляхом 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, а не безпосередньо вирішувати проблеми на базовому рівні. Такий підхід по суті не вирішує проблему, а лише передає її на верхній рівень стеку.
Оптимістичний Роллап
На сьогодні більшість Optimistic rollup є централізованими (деякі навіть мають лише одного секвенсера), що призводить до недостатньої безпеки, ізольованості один від одного, високої затримки (необхідно чекати період підтвердження шахрайства, зазвичай кілька днів) та інших проблем.
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть оброблятися за одну транзакцію. Вимоги до обчислень для генерації нульових доказів є дуже високими, а механізм "переможець забирає все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup часто обмежує обсяг транзакцій у кожній партії, що під час високого попиту може призвести до перевантаження мережі, зростання gas і погіршення користувацького досвіду.
У порівнянні, вартість ZK rollup з повною потужністю Тюрінга приблизно в 2x10^6 разів більша, ніж вартість основного протоколу безпеки криптоекономіки Polkadot.
Крім того, проблема доступності даних у ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, необхідно надати повні дані про транзакції. Це зазвичай залежить від додаткових рішень щодо доступності даних, що ще більше підвищує витрати та комісії для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності або попередньо визначеної довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через гнучке масштабування, бездозвільний дизайн протоколів, єдиний рівень безпеки та гнучкий механізм управління ресурсами.
У прагненні до більшого масштабу застосувань сьогодні, "нульова довіра до масштабування", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
13 лайків
Нагородити
13
8
Поділіться
Прокоментувати
0/400
MysteryBoxOpener
· 07-22 22:03
dot дійсно переважає інші публічні блокчейни
Переглянути оригіналвідповісти на0
NotFinancialAdviser
· 07-22 21:00
Не роздувайте, dot так собі.
Переглянути оригіналвідповісти на0
LuckyBearDrawer
· 07-22 00:01
Ця хвиля DOT має до місяця.
Переглянути оригіналвідповісти на0
P2ENotWorking
· 07-19 22:40
Яка користь від швидкості, спочатку вижити, а потім поговоримо.
Переглянути оригіналвідповісти на0
BrokenDAO
· 07-19 22:39
Знову малюючи ідеальний баланс... Ми ще пам'ятаємо ту екологічну кризу 2021 року?
Переглянути оригіналвідповісти на0
ser_we_are_early
· 07-19 22:39
Топ! У таких технічних статтях мене цікавить лише одне, зростання чи не зростання.
Переглянути оригіналвідповісти на0
DevChive
· 07-19 22:32
dot – це майбутнє, і хто ще може заперечувати?
Переглянути оригіналвідповісти на0
MagicBean
· 07-19 22:31
полка виборця чекає на результати, не можу не сказати, що все ж таки зможе До місяця
Проміжний шлях Polkadot: безкомпромісна масштабованість у екосистемі Web3
Масштабованість та компроміси: як Polkadot шукає баланс у екосистемі Web3
Сьогодні, коли блокчейн постійно прагне до більшої ефективності, з'являється ключове питання: як уникнути жертвування безпекою та гнучкістю системи під час розширення продуктивності? Це не лише технічний виклик, а й глибокий вибір архітектурного дизайну. Для екосистеми Web3, якщо швидша система будується на основі жертвування довірою та безпекою, вона часто не здатна підтримувати справжні стійкі інновації.
Polkadot як важливий рушій масштабованості Web3, чи зробив він певні жертви в досягненні цілей високої пропускної здатності та низької затримки? Чи робить його модель rollup поступки в децентралізації, безпеці або взаємодії мереж? У цій статті ми розглянемо ці питання, глибоко проаналізуємо компроміси та важливі аспекти дизайну масштабованості Polkadot і порівняємо їх з рішеннями інших основних публічних блокчейнів, досліджуючи їхні різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та централізованого релейного ланцюга, чи може це в певних аспектах ввести ризики централізації? Чи можливо утворення єдиної точки відмови або контролю, що вплине на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника, що підключений до релейного ланцюга, і його зв'язок використовує механізм, відомий як коллатор-протокол. Цей протокол повністю безкоштовний, без довіри, будь-хто, хто має підключення до мережі, може його використовувати, підключивши невелику кількість вузлів релейного ланцюга та подавши запит на зміни стану rollup. Ці запити перевіряються якимось ядром релейного ланцюга, за умови, що вони є дійсними змінами стану, інакше стан цього rollup не буде просунуто.
Торгівля вертикальним розширенням
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Цю нову можливість вводить функція «еластичного масштабування». У процесі проєктування ми виявили, що оскільки валідація блоків rollup не фіксується на певному ядрі, це може вплинути на його еластичність.
Оскільки протокол подання блоків до релейного ланцюга є бездозвільним і бездоверчим, будь-хто може подавати блоки на будь-який основний вузол, призначений для роллапу, для перевірки. Зловмисники можуть скористатися цим, повторно подаючи раніше перевірені легітимні блоки на різні основні вузли, зловмисно споживаючи ресурси, тим самим знижуючи загальну пропускну здатність та ефективність роллапу.
Мета Polkadot полягає в забезпеченні гнучкості rollup та ефективному використанні ресурсів релейної ланцюга без впливу на критичні характеристики системи.
Чи варто довіряти Sequencer?
Простим рішенням є налаштування протоколу на "з дозволом": наприклад, використання механізму білого списку або за замовчуванням довіра до сортировщика, який не буде здійснювати зловмисні дії, що забезпечує активність rollup.
Однак, у концепції дизайну Polkadot ми не можемо робити жодних довірчих припущень щодо sequencer, оскільки потрібно зберегти характеристики «без довіри» та «без дозволу» системи. Будь-хто має можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: безкомпромісне рішення
Остаточне рішення Polkadot полягає в тому, щоб повністю покласти вирішення проблеми на функцію перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому вивід повинен чітко вказувати, на якому ядрі Polkadot має бути виконано перевірку.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot повторно виконає перехід стану rollup у процесі доступності та гарантує правильність розподілу core через економічний протокол ELVES.
Перед записом даних у шар доступності Polkadot з будь-якого rollup блоку, група з приблизно 5 валідаторів спочатку перевіряє їх легітимність. Вони отримують кандидатські квитанції та докази дійсності, подані сортувальником, які містять rollup блок та відповідні докази зберігання. Цю інформацію обробляє функція валідації паралельного ланцюга, яка повторно виконується валідаторами на релейному ланцюзі.
У результаті перевірки міститься core selector, що вказує, на якому core слід перевірити блок. Верифікатор перевіряє, чи відповідає цей індекс тому core, за який він відповідає; якщо ні, цей блок буде відхилено.
Цей механізм забезпечує постійне збереження системою атрибутів, які не потребують довіри та дозволу, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, щодо розташування підтвердження, що гарантує еластичність навіть при використанні кількох ядер у rollup.
безпека
У процесі досягнення масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпека rollup забезпечується релейним ланцюгом, і для підтримки живучості потрібен лише один чесний сортувальник.
Завдяки протоколу ELVES, Polkadot розширює свою безпеку на всі rollup, перевіряючи всі обчислення на ядрах без необхідності обмежувати або робити припущення щодо кількості використовуваних ядер.
Отже, rollup Polkadot може досягти справжнього масштабування без жертвування безпекою.
Універсальність
Еластичне масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання обчислень з повною Тюрінговою здатністю в середовищі WebAssembly, якщо одне виконання завершується за 2 секунди. Завдяки еластичному масштабуванню, загальна кількість обчислень, що можуть бути виконані за 6-секундний цикл, збільшується, але типи обчислень не підлягають змінам.
складність
Вищий пропускний здатності та нижча затримка неминуче вводять складність, що є єдиним прийнятним компромісом у системному дизайні.
Rollup може динамічно налаштовувати ресурси через інтерфейс Agile Coretime для підтримки стабільного рівня безпеки. Вони також повинні виконувати частину вимог RFC103 для адаптації до різних сценаріїв використання.
Конкретна складність залежить від стратегії управління ресурсами rollup, які можуть покладатися на змінні на ланцюзі або поза ним. Наприклад:
Проста стратегія: завжди використовувати фіксовану кількість core або вручну налаштовувати поза ланцюгом;
Легка стратегія: моніторинг специфічного навантаження транзакцій у mempool вузла;
Автоматизовані стратегії: за допомогою історичних даних та XCM інтерфейсу заздалегідь викликати сервіс coretime для налаштування ресурсів.
Хоча автоматизовані методи є більш ефективними, витрати на реалізацію та тестування також суттєво зростають.
взаємодія
Polkadot підтримує взаємодію між різними rollup, а еластичне масштабування не вплине на пропускну здатність передачі повідомлень.
Передача повідомлень між роллапами реалізується на базі підлеглого транспортного рівня, а обсяг комунікаційних блоків кожного роллапа є фіксованим і не залежить від кількості виділених ядер.
У майбутньому Polkadot також підтримуватиме передачу повідомлень поза ланцюгом, де релейна ланцюг буде виступати в ролі контрольного рівня, а не рівня даних. Це оновлення покращить можливості зв'язку між роллапами разом із гнучким масштабуванням, додатково підвищуючи вертикальні можливості масштабування системи.
Які компроміси зробили інші протоколи?
Як відомо, підвищення продуктивності часто досягається за рахунок жертвування децентралізацією та безпекою. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не вражає.
Солана
Solana не використовує архітектуру шардінгу Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарового високопродуктивного архітектурного рішення, що спирається на історичне доведення (PoH), паралельну обробку ЦП і механізм консенсусу на основі лідерства, теоретичний TPS може досягати 65,000.
Одним з ключових дизайнів є попередньо оприлюднений та перевіряємий механізм розкладу лідерів:
На початку кожного епохи (приблизно кожні два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейку.
Чим більше ви ставите, тим більше отримуєте. Наприклад, валідатор, який ставить 1%, отримає приблизно 1% шансів на блокування;
Всі майнери заздалегідь оголошують, що підвищує ризик цілеспрямованих DDoS-атак на мережу та частих збоїв.
PoH та паралельна обробка мають дуже високі вимоги до апаратного забезпечення, що призводить до централізації вузлів перевірки. Чим більше плата, тим більша ймовірність, що вузол створить блок, маленькі вузли майже не мають слоту, що ще більше посилює централізацію та підвищує ризик зупинки системи після атаки.
Solana, прагнучи до TPS, жертвує децентралізацією та стійкістю до атак, її коефіцієнт Накамото становить лише 20, що значно нижче за 172 у Polkadot.
ТОН
Один з блокчейн-проектів стверджує, що TPS може досягати 104,715, але це число було досягнуто у приватній тестовій мережі, з 256 вузлами, за ідеальних умов мережі та апаратного забезпечення. У той же час Polkadot досяг 128K TPS на децентралізованій публічній мережі.
У цього проекту є проблеми з механізмом консенсусу: ідентичність вузлів перевірки фрагментів може бути заздалегідь розкрита. Його білий документ також чітко зазначає, що хоча це може оптимізувати пропускну здатність, це також може бути зловмисно використано. Через відсутність механізму "банкрутства гравців" зловмисники можуть чекати, поки певний фрагмент повністю контролюється ними, або шляхом 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, а не безпосередньо вирішувати проблеми на базовому рівні. Такий підхід по суті не вирішує проблему, а лише передає її на верхній рівень стеку.
Оптимістичний Роллап
На сьогодні більшість Optimistic rollup є централізованими (деякі навіть мають лише одного секвенсера), що призводить до недостатньої безпеки, ізольованості один від одного, високої затримки (необхідно чекати період підтвердження шахрайства, зазвичай кілька днів) та інших проблем.
ZK Rollup
Реалізація ZK rollup обмежена кількістю даних, які можуть оброблятися за одну транзакцію. Вимоги до обчислень для генерації нульових доказів є дуже високими, а механізм "переможець забирає все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup часто обмежує обсяг транзакцій у кожній партії, що під час високого попиту може призвести до перевантаження мережі, зростання gas і погіршення користувацького досвіду.
У порівнянні, вартість ZK rollup з повною потужністю Тюрінга приблизно в 2x10^6 разів більша, ніж вартість основного протоколу безпеки криптоекономіки Polkadot.
Крім того, проблема доступності даних у ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, необхідно надати повні дані про транзакції. Це зазвичай залежить від додаткових рішень щодо доступності даних, що ще більше підвищує витрати та комісії для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності або попередньо визначеної довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через гнучке масштабування, бездозвільний дизайн протоколів, єдиний рівень безпеки та гнучкий механізм управління ресурсами.
У прагненні до більшого масштабу застосувань сьогодні, "нульова довіра до масштабування", яку підтримує Polkadot, можливо, є справжнім рішенням, яке може підтримати довгостроковий розвиток Web3.