Компроміси розширюваності: Виклики Polkadot і Web3
Сьогодні, коли блокчейн прагне до більшої ефективності, поступово виникає ключове питання: як досягти масштабування продуктивності, не жертвуючи безпекою та еластичністю системи? Це не лише виклик на технологічному рівні, а й глибокий вибір у проектуванні архітектури. Для екосистеми Web3 швидша система, якщо вона будується на основі жертви довіри та безпеки, зазвичай не може підтримувати справжні стійкі інновації.
Як важливий рушій Web3 масштабованості, чи зробив Polkadot певні жертви в гонитві за високою пропускною здатністю та низькою затримкою? Чи пожертвував його модель rollup децентралізацією, безпекою чи міжмережевою взаємодією?
Ця стаття буде зосереджена на цих питаннях, глибоко аналізуючи компроміси та вибори Polkadot у дизайні масштабованості, а також порівнюючи їх з рішеннями інших основних публічних ланцюгів, щоб дослідити різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга, чи може це в певних аспектах впровадити ризики централізації? Чи може виникнути єдина точка відмови або контролю, що вплине на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника, який підключений до релейного ланцюга, а його комунікація використовує механізм протоколу collator. Цей протокол абсолютно не потребує дозволів і не довіряє, будь-хто з підключенням до мережі може його використовувати, підключаючи невелику кількість вузлів релейного ланцюга і надсилаючи запити на зміни стану rollup. Ці запити будуть перевірятися якимось core релейного ланцюга, і є лише одна умова: зміна стану повинна бути дійсною, інакше стан rollup не буде просунуто.
Торгівля вертикальним масштабуванням
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Цю нову можливість вводить функція "еластичного масштабування". У процесі проєктування виявлено, що оскільки валідація блоків rollup не фіксується на конкретному ядрі, це може вплинути на його еластичність.
Оскільки протокол подачі блоків до релейної мережі є бездозвільним і бездостовірним, будь-хто може подавати блоки на будь-який core, призначений для rollup, для верифікації. Зловмисники можуть скористатися цим, повторно подаючи раніше верифіковані легітимні блоки на різні core, навмисно витрачаючи ресурси, що знижує загальну пропускну здатність та ефективність rollup.
Мета Polkadot полягає в тому, щоб підтримувати гнучкість rollup і ефективне використання ресурсів релейної цепі без впливу на ключові характеристики системи.
Чи варто довіряти Sequencer?
Одним із простих рішень є налаштування протоколу на "з ліцензією": наприклад, використання механізму білого списку або за замовчуванням довіряти сортувальникам, що не здійснюють злочинних дій, щоб забезпечити активність rollup.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки потрібно зберегти характеристики "без довіри" та "без дозволу" системи. Будь-хто повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточне рішення Polkadot полягає в тому, що питання повністю передається функції перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому в результатах необхідно чітко вказати, на якому ядрі Polkadot потрібно виконати перевірку.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot повторно виконає перехід стану rollup у процесі доступності та забезпечить правильність розподілу core через економічний протокол ELVES.
Перед тим, як будь-які rollup-блоки записуються в шар доступності даних Polkadot, група з приблизно 5 валідаторів спочатку перевіряє їх законність. Вони отримують кандидати на квитанції та докази дійсності, подані сортувальником, які містять rollup-блоки та відповідні докази зберігання. Цю інформацію обробляє функція верифікації паралельного ланцюга, яку повторно виконує валідатор на релейному ланцюзі.
У результатах перевірки міститься core selector, що використовується для вказівки, на якому core слід перевірити блок. Верифікатор порівнює цей індекс з тим, за який він відповідає; якщо вони не збігаються, цей блок буде відкинуто.
Цей механізм забезпечує постійне збереження системою властивостей без довіри та без дозволу, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, щодо позицій верифікації, гарантуючи, що навіть при використанні кількох ядер rollup залишається еластичним.
Безпека
У процесі прагнення до масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпека ролапу забезпечується релейною ланцюгом, для підтримки життєздатності достатньо одного чесного сортувальника.
Завдяки протоколу 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), паралельну обробку CPU та механізм консенсусу на основі лідера, теоретичний TPS може досягати 65 000.
Ключовим дизайном є його заздалегідь відкритий та перевіряємий механізм розподілу лідерів:
На початку кожного епохи (приблизно через два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейку.
Чим більше ви стейкаєте, тим більше отримуєте. Наприклад, стейкаючи 1% валідаторів, ви отримаєте приблизно 1% шансів на видобуток блока;
Усі майнери заздалегідь оголошуються, що підвищує ризик цілеспрямованих DDoS-атак на мережу та частих відмов у роботі.
PoH та паралельна обробка вимагають надзвичайно високих вимог до апаратного забезпечення, що призводить до централізації валідаційних вузлів. Чим більше узгоджено вузлів, тим більша ймовірність їхнього видобутку блоків, маленькі вузли практично не мають слотів, що ще більше посилює централізацію і збільшує ризик зупинки системи після атаки.
Solana, прагнучи до TPS, пожертвувала децентралізацією та стійкістю до атак, її коефіцієнт Накамото становить лише 20, що значно нижче за 172 у Polkadot.
ТОН
TON стверджує, що TPS може досягати 104,715, але ця цифра була досягнута на приватній тестовій мережі з 256 вузлами за ідеальних умов мережі та апаратного забезпечення. А Polkadot на децентралізованій публічній мережі вже досяг 128K TPS.
Механізм консенсусу TON має проблеми з безпекою: ідентичність вузлів перевірки шард може бути розкрита заздалегідь. У білому документі TON також чітко зазначено, що хоча це може оптимізувати пропускну здатність, це також може бути використано зловмисно. Через відсутність механізму "банкрутства гравця" зловмисники можуть чекати, коли певний шард буде повністю під їх контролем, або за допомогою DDoS-атаки блокувати чесних перевіряючих, в результаті чого стан може бути змінено.
На відміну від цього, валідатори Polkadot випадковим чином призначаються та їх ідентичність розкривається з затримкою, тому зловмисники не можуть заздалегідь дізнатися про ідентичність валідаторів, а атака потребує ставити під загрозу успіх контролю. Якщо хоча б один чесний валідатор розпочне спір, атака зазнає невдачі і призведе до втрати застави зловмисником.
Авала́нч
Avalanche використовує архітектуру основної мережі + підмережі для масштабування, основна мережа складається з X-Chain (трансакції, ~4,500 TPS), C-Chain (смарт-контракти, ~100-200 TPS), P-Chain (управління валідаторами та підмережами).
Теоретична TPS кожної підмережі може досягати ~5,000, подібно до ідеї Polkadot: зменшити навантаження на окремий shard для досягнення масштабування. Але Avalanche дозволяє валідаторам вільно обирати участь у підмережах, і підмережі можуть встановлювати географічні, KYC та інші додаткові вимоги, жертвуючи децентралізацією та безпекою.
У Polkadot всі rollup ділять єдину безпеку; тоді як підмережі Avalanche не мають стандартної гарантії безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ж доведеться йти на компроміси в продуктивності, і важко забезпечити детермінаційні гарантії безпеки.
Ефіріум
Стратегія розширення Ethereum полягає в ставці на масштабованість шару rollup, а не в безпосередньому вирішенні проблем на базовому шарі. Цей підхід по суті не вирішує проблему, а лише передає її на наступний рівень стеку.
Оптимістичний Ролап
Наразі більшість оптимістичних роллапів є централізованими (деякі навіть мають лише один секвенсер), що викликає проблеми з безпекою, ізольованістю та високою затримкою (потрібно чекати період підтвердження шахрайства, зазвичай кілька днів).
ZK Rollup
Імплементація ZK rollup обмежена обсягом даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових доказів є надзвичайно високими, і механізм "виграє той, хто перший" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати затори в мережі, підвищення gas та впливати на користувацький досвід.
У порівнянні, вартість Turing-complete ZK rollup приблизно в 2x10^6 разів більша, ніж у основному протоколі економічної безпеки Polkadot.
Крім того, проблема доступності даних ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, необхідно надати повні дані про транзакції. Це зазвичай залежить від додаткових рішень для забезпечення доступності даних, що додатково підвищує витрати та комісії для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності чи попередньо заданої довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через гнучке масштабування, бездозвільний протокол проектування, єдиний рівень безпеки та гнучкий механізм управління ресурсами.
У сьогоднішньому світі, де прагнуть до більшого масштабу застосувань, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, що підтримує довгостроковий розвиток Web3.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
12 лайків
Нагородити
12
8
Поділіться
Прокоментувати
0/400
LiquidityWhisperer
· 07-22 15:35
Швидкість і безпека не можуть бути одночасно?
Переглянути оригіналвідповісти на0
DiamondHands
· 07-22 13:17
Швидкість і безпека, як правило, є взаємовиключними.
Переглянути оригіналвідповісти на0
GasGuru
· 07-21 22:12
Знову chain займається балансуванням.
Переглянути оригіналвідповісти на0
TokenVelocity
· 07-21 22:10
Чи дійсно Полка стабільна? Чи це обман для дурнів?
Переглянути оригіналвідповісти на0
BearMarketSage
· 07-21 21:53
Не можна мати рибу і ведмежу лапу одночасно.
Переглянути оригіналвідповісти на0
MidnightSeller
· 07-21 21:52
Жертвуючи безпекою заради швидкості, майже чекайте на дах.
Переглянути оригіналвідповісти на0
PermabullPete
· 07-21 21:48
Зрозумів, але де точки?
Переглянути оригіналвідповісти на0
MEVSandwichMaker
· 07-21 21:48
Ціну жертви завжди потрібно платити, тільки подивіться, хто перший вибухне.
Як Polkadot реалізує нульову довіру для розширення, ведучи в майбутнє Web3
Компроміси розширюваності: Виклики Polkadot і Web3
Сьогодні, коли блокчейн прагне до більшої ефективності, поступово виникає ключове питання: як досягти масштабування продуктивності, не жертвуючи безпекою та еластичністю системи? Це не лише виклик на технологічному рівні, а й глибокий вибір у проектуванні архітектури. Для екосистеми Web3 швидша система, якщо вона будується на основі жертви довіри та безпеки, зазвичай не може підтримувати справжні стійкі інновації.
Як важливий рушій Web3 масштабованості, чи зробив Polkadot певні жертви в гонитві за високою пропускною здатністю та низькою затримкою? Чи пожертвував його модель rollup децентралізацією, безпекою чи міжмережевою взаємодією?
Ця стаття буде зосереджена на цих питаннях, глибоко аналізуючи компроміси та вибори Polkadot у дизайні масштабованості, а також порівнюючи їх з рішеннями інших основних публічних ланцюгів, щоб дослідити різні шляхи вибору між продуктивністю, безпекою та децентралізацією.
Виклики, з якими стикається дизайн розширення Polkadot
Баланс між еластичністю та децентралізацією
Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга, чи може це в певних аспектах впровадити ризики централізації? Чи може виникнути єдина точка відмови або контролю, що вплине на його децентралізовані характеристики?
Робота Rollup залежить від сортувальника, який підключений до релейного ланцюга, а його комунікація використовує механізм протоколу collator. Цей протокол абсолютно не потребує дозволів і не довіряє, будь-хто з підключенням до мережі може його використовувати, підключаючи невелику кількість вузлів релейного ланцюга і надсилаючи запити на зміни стану rollup. Ці запити будуть перевірятися якимось core релейного ланцюга, і є лише одна умова: зміна стану повинна бути дійсною, інакше стан rollup не буде просунуто.
Торгівля вертикальним масштабуванням
Rollup може реалізувати вертикальне масштабування, використовуючи багатоядерну архітектуру Polkadot. Цю нову можливість вводить функція "еластичного масштабування". У процесі проєктування виявлено, що оскільки валідація блоків rollup не фіксується на конкретному ядрі, це може вплинути на його еластичність.
Оскільки протокол подачі блоків до релейної мережі є бездозвільним і бездостовірним, будь-хто може подавати блоки на будь-який core, призначений для rollup, для верифікації. Зловмисники можуть скористатися цим, повторно подаючи раніше верифіковані легітимні блоки на різні core, навмисно витрачаючи ресурси, що знижує загальну пропускну здатність та ефективність rollup.
Мета Polkadot полягає в тому, щоб підтримувати гнучкість rollup і ефективне використання ресурсів релейної цепі без впливу на ключові характеристики системи.
Чи варто довіряти Sequencer?
Одним із простих рішень є налаштування протоколу на "з ліцензією": наприклад, використання механізму білого списку або за замовчуванням довіряти сортувальникам, що не здійснюють злочинних дій, щоб забезпечити активність rollup.
Проте, у концепції дизайну Polkadot ми не можемо робити жодних припущень щодо sequencer, оскільки потрібно зберегти характеристики "без довіри" та "без дозволу" системи. Будь-хто повинен мати можливість використовувати протокол collator для подання запитів на зміни стану rollup.
Polkadot: Непоступливе рішення
Остаточне рішення Polkadot полягає в тому, що питання повністю передається функції перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом усієї інформації про консенсус, тому в результатах необхідно чітко вказати, на якому ядрі Polkadot потрібно виконати перевірку.
Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot повторно виконає перехід стану rollup у процесі доступності та забезпечить правильність розподілу core через економічний протокол ELVES.
Перед тим, як будь-які rollup-блоки записуються в шар доступності даних Polkadot, група з приблизно 5 валідаторів спочатку перевіряє їх законність. Вони отримують кандидати на квитанції та докази дійсності, подані сортувальником, які містять rollup-блоки та відповідні докази зберігання. Цю інформацію обробляє функція верифікації паралельного ланцюга, яку повторно виконує валідатор на релейному ланцюзі.
У результатах перевірки міститься core selector, що використовується для вказівки, на якому core слід перевірити блок. Верифікатор порівнює цей індекс з тим, за який він відповідає; якщо вони не збігаються, цей блок буде відкинуто.
Цей механізм забезпечує постійне збереження системою властивостей без довіри та без дозволу, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, щодо позицій верифікації, гарантуючи, що навіть при використанні кількох ядер rollup залишається еластичним.
Безпека
У процесі прагнення до масштабованості Polkadot не йшов на компроміс у питаннях безпеки. Безпека ролапу забезпечується релейною ланцюгом, для підтримки життєздатності достатньо одного чесного сортувальника.
Завдяки протоколу 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), паралельну обробку CPU та механізм консенсусу на основі лідера, теоретичний TPS може досягати 65 000.
Ключовим дизайном є його заздалегідь відкритий та перевіряємий механізм розподілу лідерів:
На початку кожного епохи (приблизно через два дні або 432 000 слотів) слоти розподіляються відповідно до обсягу стейку.
Чим більше ви стейкаєте, тим більше отримуєте. Наприклад, стейкаючи 1% валідаторів, ви отримаєте приблизно 1% шансів на видобуток блока;
Усі майнери заздалегідь оголошуються, що підвищує ризик цілеспрямованих DDoS-атак на мережу та частих відмов у роботі.
PoH та паралельна обробка вимагають надзвичайно високих вимог до апаратного забезпечення, що призводить до централізації валідаційних вузлів. Чим більше узгоджено вузлів, тим більша ймовірність їхнього видобутку блоків, маленькі вузли практично не мають слотів, що ще більше посилює централізацію і збільшує ризик зупинки системи після атаки.
Solana, прагнучи до TPS, пожертвувала децентралізацією та стійкістю до атак, її коефіцієнт Накамото становить лише 20, що значно нижче за 172 у Polkadot.
ТОН
TON стверджує, що TPS може досягати 104,715, але ця цифра була досягнута на приватній тестовій мережі з 256 вузлами за ідеальних умов мережі та апаратного забезпечення. А Polkadot на децентралізованій публічній мережі вже досяг 128K TPS.
Механізм консенсусу TON має проблеми з безпекою: ідентичність вузлів перевірки шард може бути розкрита заздалегідь. У білому документі TON також чітко зазначено, що хоча це може оптимізувати пропускну здатність, це також може бути використано зловмисно. Через відсутність механізму "банкрутства гравця" зловмисники можуть чекати, коли певний шард буде повністю під їх контролем, або за допомогою DDoS-атаки блокувати чесних перевіряючих, в результаті чого стан може бути змінено.
На відміну від цього, валідатори Polkadot випадковим чином призначаються та їх ідентичність розкривається з затримкою, тому зловмисники не можуть заздалегідь дізнатися про ідентичність валідаторів, а атака потребує ставити під загрозу успіх контролю. Якщо хоча б один чесний валідатор розпочне спір, атака зазнає невдачі і призведе до втрати застави зловмисником.
Авала́нч
Avalanche використовує архітектуру основної мережі + підмережі для масштабування, основна мережа складається з X-Chain (трансакції, ~4,500 TPS), C-Chain (смарт-контракти, ~100-200 TPS), P-Chain (управління валідаторами та підмережами).
Теоретична TPS кожної підмережі може досягати ~5,000, подібно до ідеї Polkadot: зменшити навантаження на окремий shard для досягнення масштабування. Але Avalanche дозволяє валідаторам вільно обирати участь у підмережах, і підмережі можуть встановлювати географічні, KYC та інші додаткові вимоги, жертвуючи децентралізацією та безпекою.
У Polkadot всі rollup ділять єдину безпеку; тоді як підмережі Avalanche не мають стандартної гарантії безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, вам все ж доведеться йти на компроміси в продуктивності, і важко забезпечити детермінаційні гарантії безпеки.
Ефіріум
Стратегія розширення Ethereum полягає в ставці на масштабованість шару rollup, а не в безпосередньому вирішенні проблем на базовому шарі. Цей підхід по суті не вирішує проблему, а лише передає її на наступний рівень стеку.
Оптимістичний Ролап
Наразі більшість оптимістичних роллапів є централізованими (деякі навіть мають лише один секвенсер), що викликає проблеми з безпекою, ізольованістю та високою затримкою (потрібно чекати період підтвердження шахрайства, зазвичай кілька днів).
ZK Rollup
Імплементація ZK rollup обмежена обсягом даних, які можуть бути оброблені за одну транзакцію. Обчислювальні вимоги для генерації нульових доказів є надзвичайно високими, і механізм "виграє той, хто перший" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує обсяг транзакцій у кожній партії, що під час високого попиту може викликати затори в мережі, підвищення gas та впливати на користувацький досвід.
У порівнянні, вартість Turing-complete ZK rollup приблизно в 2x10^6 разів більша, ніж у основному протоколі економічної безпеки Polkadot.
Крім того, проблема доступності даних ZK rollup також посилить його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, необхідно надати повні дані про транзакції. Це зазвичай залежить від додаткових рішень для забезпечення доступності даних, що додатково підвищує витрати та комісії для користувачів.
Висновок
Кінець масштабованості не повинен бути компромісом.
На відміну від інших публічних блокчейнів, Polkadot не пішов шляхом централізації заради продуктивності чи попередньо заданої довіри заради ефективності, а досягнув багатовимірного балансу між безпекою, децентралізацією та високою продуктивністю через гнучке масштабування, бездозвільний протокол проектування, єдиний рівень безпеки та гнучкий механізм управління ресурсами.
У сьогоднішньому світі, де прагнуть до більшого масштабу застосувань, "нульова довіра до масштабованості", яку підтримує Polkadot, можливо, є справжнім рішенням, що підтримує довгостроковий розвиток Web3.