Вагомість і виклики розширювальної здатності Блокчейн: рішення Polkadot

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

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

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

Баланс гнучкості та децентралізації

Архітектура Polkadot залежить від мережі валідаторів та релейного ланцюга (Relay Chain), що може в певних аспектах впроваджувати ризики централізації. Робота Rollup залежить від сікуенсерів (sequencer), що з'єднують релейний ланцюг, а їхня комунікація використовує механізм протоколу колаторів (collator). Цей протокол повністю бездозвільний, без довіри, будь-хто з підключенням до мережі може його використовувати, підключаючи невелику кількість вузлів релейного ланцюга та подаючи запити на зміни стану rollup.

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

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

Проблема довіри Sequencer

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

Рішення Polkadot

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

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

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

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

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

Безпека

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

Універсальність

Еластичне масштабування не обмежує програмованість rollup. Модель rollup в Polkadot підтримує виконання тієї ж обчислювальної потужності в середовищі WebAssembly, якщо одноразове виконання завершується протягом 2 секунд. Завдяки еластичному масштабуванню загальний обсяг обчислень, що можуть бути виконані за 6-секундний цикл, збільшується, але типи обчислень залишаються незмінними.

Складність

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

Конкретна складність залежить від стратегії управління ресурсами rollup, яка може покладатися на змінні на ланцюзі або поза ним. Наприклад:

• Проста стратегія: завжди використовувати фіксовану кількість core, або вручну налаштовувати через поза ланцюгом;
• Легка стратегія: моніторинг специфічного навантаження транзакцій у mempool вузла;
• Автоматизовані стратегії: за допомогою історичних даних та XCM інтерфейсу заздалегідь викликати coretime сервіс для налаштування ресурсів.

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

Інтероперабельність

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

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

Торгівля іншими протоколами

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

Солана

Solana використовує одношарову архітектуру з високою пропускною здатністю для досягнення масштабованості, покладаючись на історичне підтвердження (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 обмежена кількістю даних, які можуть бути оброблені в одній транзакції. Обчислювальні вимоги для генерації нульових доказів дуже високі, а механізм "переможець забирає все" може призвести до централізації системи. Щоб забезпечити TPS, ZK rollup часто обмежує обсяг транзакцій у кожній партії, що в умовах високого попиту може призвести до заторів у мережі, зростання вартості gas та погіршення досвіду користувачів.

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

Висновок

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

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