Торгівля масштабованістю: Вибір між Polkadot та Web3

У світі блокчейн-технологій, де постійно прагнуть до більшої ефективності, поступово виникає ключове питання: як забезпечити безпеку та еластичність системи, одночасно підвищуючи продуктивність? Це не лише технічний виклик, але й глибокий вибір архітектурного дизайну. Для екосистеми Web3, якщо швидша система створена на основі жертви довіри та безпеки, вона часто не може підтримувати справжні інновації, що є стійкими.

Як важливий двигун масштабованості Web3, чи зробив Polkadot певні компроміси у прагненні до високої пропускної здатності та низької затримки? Чи його модель rollup поступається в децентралізації, безпеці або міжмережевій взаємодії? У цій статті буде глибоко проаналізовано компроміси та баланс, які Polkadot робить у дизайні масштабованості, а також порівняно з іншими основними рішеннями публічних блокчейнів, досліджуючи різні шляхи в досягненні продуктивності, безпеки та децентралізації.

Виклики, з якими стикається дизайн розширення Polkadot

Баланс між еластичністю та децентралізацією

Архітектура Polkadot залежить від мережі валідаторів та централізованого релейного ланцюга. Чи може це в певних аспектах ввести ризик централізації? Чи можливо утворення єдиної точки відмови або контролю, що вплине на її децентралізовані характеристики?

Запуск Rollup залежить від сортувальника, підключеного до релейної мережі, а його зв'язок використовує механізм, відомий як протокол коллатора. Цей протокол повністю бездозвільний, без довіри, будь-хто з підключенням до мережі може його використовувати, підключаючи невелику кількість вузлів релейної мережі та подаючи запити на зміни стану Rollup. Ці запити перевіряються якимось ядром релейної мережі, потрібно лише дотримуватися однієї умови: зміна стану повинна бути дійсною, інакше стан Rollup не буде просунутим.

Торгівля вертикальним розширенням

Rollup може реалізувати вертикальне масштабування за рахунок використання багатоядерної архітектури Polkadot. Ця нова можливість була введена завдяки функції "еластичного масштабування". Під час проектування ми виявили, що оскільки валідація блоків rollup не є фіксованою на певному ядрі, це може вплинути на його еластичність.

Оскільки протокол подання блоків до релейного ланцюга є бездозвільним і без довіри, будь-хто може подати блок на будь-який основний вузол, призначений для роллапу, для перевірки. Зловмисники можуть скористатися цим, повторно подаючи раніше перевірені легітимні блоки до різних основних вузлів, ненавмисно витрачаючи ресурси, що знижує загальну пропускну спроможність і ефективність роллапу.

Мета Polkadot полягає в тому, щоб підтримувати еластичність rollup та ефективне використання ресурсів релейної мережі без впливу на ключові характеристики системи.

Чи можна довіряти Sequencer?

Одним із простих рішень є встановлення протоколу як "з дозволом": наприклад, використання механізму білого списку або за замовчуванням довіряти сортировщику, щоб уникнути зловмисних дій, що забезпечує активність rollup.

Однак у концепції дизайну Polkadot ми не можемо робити жодних довірчих припущень щодо секвенсера, оскільки необхідно зберегти характеристики "без довіри" та "без дозволу" системи. Будь-хто повинен мати можливість використовувати протокол коллатора для подання запитів на зміни стану роллапу.

Polkadot: безкомпромісне рішення

Остаточне рішення Polkadot полягає в тому, щоб повністю передати проблему функції перетворення стану rollup (Runtime). Runtime є єдиним надійним джерелом всієї інформації про консенсус, тому в результатах повинно бути чітко вказано, на якому ядрі Polkadot має виконуватися перевірка.

Цей дизайн забезпечує подвійний захист еластичності та безпеки. Polkadot буде повторно виконувати перехід стану rollup у процесі доступності та забезпечить правильність розподілу core через економічний протокол ELVES.

Перед записом даних в шар доступності Polkadot у будь-якому блокові rollup (DA) група з близько 5 валідаторів спочатку перевірить їхню законність. Вони отримують кандидатські квитанції та докази дійсності, подані сортувальником, які містять блоки rollup та відповідні докази зберігання. Цю інформацію обробляє функція перевірки паралельного ланцюга, яка повторно виконується валідаторами на релейному ланцюгу.

Результат перевірки містить core selector, який використовується для вказівки, на якому core слід перевіряти блок. Верифікатор порівнює цей індекс з тим, за який він відповідає; якщо вони не співпадають, цей блок буде скинутий.

Такий механізм забезпечує постійне збереження системою властивостей, які не потребують довіри та дозволів, уникаючи маніпуляцій з боку зловмисників, таких як сортувальники, щодо позицій верифікації, що гарантує гнучкість навіть при використанні кількох ядер у роллапі.

безпека

У процесі досягнення масштабованості 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 також підтримуватиме передачу повідомлень поза мережею, при цьому релейна ланцюгова мережа буде виконувати роль контрольного рівня, а не рівня даних. Це оновлення підвищить можливості зв'язку між rollup з одночасним гнучким масштабуванням, додатково зміцнивши вертикальні можливості розширення системи.

Які компроміси зробили інші протоколи?

Як всім відомо, підвищення продуктивності часто обходиться в жертву децентралізації та безпеці. Але з точки зору коефіцієнта Накамото, навіть якщо деякі конкуренти Polkadot мають нижчий рівень децентралізації, їх продуктивність також не вражає.

Солана

Solana не використовує шардінг-архітектуру Polkadot або Ethereum, а реалізує масштабованість за допомогою одношарової архітектури з високою пропускною здатністю, покладаючись на історичне підтвердження (PoH), паралельну обробку ЦП і консенсусний механізм на основі лідера, теоретичний 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: зменшити навантаження на окремий шард для досягнення масштабованості. Але Avalanche дозволяє валідаторам вільно вибирати участь у підмережах, і підмережі можуть встановлювати географічні, KYC та інші додаткові вимоги, жертвуючи децентралізацією та безпекою.

У Polkadot всі роллапи ділять єдині заходи безпеки; тоді як підмережі Avalanche не мають стандартних гарантій безпеки, деякі з них можуть бути повністю централізованими. Якщо ви хочете підвищити безпеку, все ще потрібно йти на компроміс у продуктивності, і важко надати визначені зобов'язання щодо безпеки.

Ефіріум

Стратегія розширення Ethereum полягає в ставці на масштабованість шару rollup, а не в безпосередньому вирішенні проблеми на базовому шарі. Цей підхід по суті не вирішує проблему, а лише передає її на верхній рівень стеку.

Оптимістичний Роллап

Наразі більшість Optimistic rollup є централізованими, що призводить до недостатньої безпеки, ізольованості один від одного, високої затримки ( необхідно чекати період доказу шахрайства, зазвичай кілька днів ) та інших проблем.

ZK Rollup

Реалізація ZK rollup обмежена кількістю даних, які можуть бути оброблені за одну транзакцію. Вимоги до обчислень для генерації нульових доказів є надзвичайно високими, і механізм «переможець отримує все» може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup зазвичай обмежує кількість транзакцій в кожній партії, що в умовах високого попиту може викликати затори в мережі, підвищення газу та вплинути на досвід користувачів.

У порівнянні, вартість ZK rollup з повною потужністю Тюринга приблизно в 2x10^6 разів більша, ніж вартість основного протоколу безпеки криптоекономіки Polkadot.

Крім того, проблема доступності даних ZK rollup також посилює його недоліки. Щоб забезпечити можливість перевірки транзакцій будь-ким, необхідно надати повні дані транзакцій. Це зазвичай залежить від додаткових рішень щодо доступності даних, що додатково підвищує витрати та плату для користувачів.

Висновок

Кінець масштабованості не повинен бути компромісом.

На відміну від інших публічних блокчейнів, Polkadot не обрала шлях централізації заради продуктивності або попередньої довіри заради ефективності, а реалізувала багатовимірний баланс безпеки, децентралізації та високої продуктивності через еластичне масштабування, бездозвільний протокол, єдиний рівень безпеки та гнучкий механізм управління ресурсами.

У світі, що прагне до більш масштабного впровадження, «нульова довіра до масштабованості», яку відстоює Polkadot, можливо, є справжнім рішенням, яке підтримує довгостроковий розвиток Web3.