Постер запуску Polygon zkEVM викликав велику дискусію серед засновників паблік-чейну про масштабованість

26 лютого рекламний плакат, що анонсує запуск основної мережі Polygon zkEVM, викликав дискусію про використання еквівалентності терміна «Ethereum», а Є Чжан, засновник Scroll, урочисто зазначив, що Polygon zkEVM не має цієї функції. Озираючись назад, Райан Ваятт, керівник Polygon Labs, відповів, що це скоріше результат поганої комунікації між маркетологами та технічними фахівцями всередині команди.

Це нетривіальна справа, і ступінь ефективності навіть буде безпосередньо пов’язана з продуктивністю та масштабованістю L1/L2, лише два дні тому співавтор Solana Толі опублікував статтю про те, що ZK L2s не буде найкращим рішенням для вирішення проблеми масштабованості.

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

1 березня Solana також оголосила про «план поліпшення оновлення мережі», щоб знову нести прапор вбивці Ethereum, але її операційний механізм не був принципово впроваджений після численних збоїв, і це більше схоже на посткризову оптимізацію, яка також кидає тінь на заміну Ethereum на високопродуктивний L1.

У цій статті ми об’єднаємо твіти кількох засновників L1/L2, щоб розкрити тонкощі великої дискусії про ефективність публічних мереж.

Походження: Дебати про еквівалентність EVM

zkEVM від Polygon, строго кажучи, є механізмом zk VM, який узгоджується з основною мережею Ethereum на рівні L2 за допомогою картографування, і впровадження технології zk є причиною того, що він називається zk VM, і в нестрогому сенсі, якщо він може підтримувати синхронізацію, то називати його zk EVM нешкідливо.

Однак, за словами Є Чжана, засновника Scroll, еквівалентність EVM - це не зовсім те ж саме, що еквівалентність Ethereum, тому що останній повинен як мінімум відповідати основній мережі Ethereum з точки зору зберігання даних.

З більш широкої точки зору, жоден з поточних кросчейн-мостів L2s або Ethereum не може претендувати на звання еквівалента Ethereum, а більш модульні та складні стеки Ethereum забезпечать складнішу сумісність.

Простий приклад можна навести, щоб інтуїтивно зрозуміти різницю між ними, Optimism має справу з різницею між ними в плануванні продукту, на його думку:

Еквівалентність EVM: Головним чином з точки зору розробників dApp, їхній досвід роботи з OVM нічим не відрізняється від досвіду розробки dApps в основній мережі Ethereum, тому OVM має еквівалентність EVM;

Еквівалентність Ethereum: Головним чином з точки зору розробників протоколів, необхідно підтримувати високий ступінь узгодженості з Ethereum з точки зору клієнта, рівня зв’язку, рівня консенсусу та рівня виконання.

На додаток до дебатів про еквівалентність EVM, слід також зазначити, що суперечка про масштабованість в даний час знаходиться в центрі уваги битви між L2 на базі Ethereum і високопродуктивним L1.

Попередник: сумніви Solana щодо масштабованості ZK

24 лютого, за два дні до запуску трейлера Polygon zkEVM, співавтор Solana Толі опублікував пост у Twitter, в якому поставив під сумнів здатність ZK L2s вирішити проблему масштабування публічного ланцюга, щоб нівелювати сумніви громадськості щодо механізму роботи Solana.

Його основні тези полягають у наступному:

• Завантаження даних у ланцюжок у режимі реального часу вимагає стабільних можливостей послідовного виконання;
• Схема доказу ZK є дійсною за умови, що сума часу генерації доказів ZK + часу верифікації менша за час виконання в реальному часі;
• Рішення ZK не може обробляти великі обсяги даних у режимі реального часу та може виконувати лише переривчасту агрегацію, але не може підтримувати статус ончейн-стану в реальному часі;

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

На жаль, Solana зазнала серйозного збою 25 лютого, і спільнота, інженери та валідатори відновили основну мережу після двох перезавантажень, а витік будинку збігся з нічним дощем, і «добродії» скористалися можливістю, щоб поставити під сумнів механізм Solana, а користувач Twitter DBCryptoX стверджував, що «90-95% транзакцій на Solana містять повідомлення валідаторів і голосування в мережі».

Solana використовує механізм консенсусу PoS, який називає себе механізмом «Proof of History». PoH дозволяє мережі працювати швидше, оскільки вузлам не потрібно спілкуватися для перевірки блоку, а PoH дозволяє валідаторам точно визначати події в певний момент часу.

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

Подія відключення внесла негативний урок у масштабованість Solana. Співтворець Solana Толі вважає, що проверс на ZK L2 не може бути виконаний у режимі реального часу, тому остаточне ончейн-виконання ZK L2s не буде у встановленому порядку, тому або користувачі можуть запускати повні ноди, щоб збільшити навантаження на мережу, або покладатися на кілька чесних вузлів для підвищення ефективності та централізованого використання.

Однак виявляється, що високопродуктивний L1 Solana, схоже, не вирішує проблему виконання в реальному часі, адже згорнута мережа в кінцевому підсумку втратить встановлений порядок, а примусово відновлені дані стануть штучним «консенсусом», а не спонтанним станом самої мережі.

Наслідки: масштабованість Polygon критично важлива

Polygon zkEVM спочатку був допитаний Solana, а потім оголосив, що стався інцидент з улуном, який підозрювався в непрофесійності та введенні в оману. Тож розробник Джорді Бейліна (Jordi Baylina) вискочив і прийняв виклик професіоналізму, зосередившись на поясненні того, що виробник не є обмежуючим фактором для ZK L2s, а справжньою перешкодою є DA (доступність даних).

Перший - це процес роботи zkRollup, який можна умовно розділити на три етапи, як показано на малюнку нижче:

Синхронізація мережі, незалежно від архітектури зведення, поки задіяні дані на L2, вона повинна довести дійсність пакета повідомлень, щоб їх можна було підтвердити, коли вони нарешті повернуться до L1.

Генерація агрегатних доказів вимагає використання схеми zk proof scheme (ZKP), яка може бути прискорена паралельною обробкою, але сама генерація пакетних доказів займає деякий час. Можна навіть розробити динамічні механізми, де кількість мережевих доказів може бути збільшена або зменшена в залежності від потреб мережі.

Після запуску ZKP для даних генерується повна деревозахищена мережа, яка дозволяє різним серверам перевіряти дані та надсилати результати в ланцюжок L1.

По-друге, це питання вартості, найбільш критичним з яких є вартість доказу, програмне забезпечення, апаратне забезпечення та час виклику операції ZK будуть включені в розрахунковий коефіцієнт комісією TX (транзакції) і, нарешті, відображені в платі за газ мережі, а різні алгоритми, такі як STARK/SNARK/FLONK тощо, значно оптимізують витрати на використання мережі. Ключовим моментом є те, що завантаження даних не потрібно виконувати послідовно, щоб полегшити розпаралелювання.

Таким чином, Prover, який, на думку Solana, не може перешкоджати роботі доказів ZK, а справжньою перешкодою є доступність даних, яку потрібно вирішувати за допомогою ETH 2.0, DankSharding, EIP4844 та інших рішень.

Висновок: Куди рухається масштабованість

Дебати навколо Polygon zkEVM триватимуть, і ключем до того, наскільки добре zk EVM зможе вирішити поточну проблему масштабованості, що стане наступним випробуванням для L1/L2, з яким доведеться зіткнутися з великомасштабними dApps та користувачами.