Дорожня карта Interop «прискорюється»: після оновлення Fusaka взаємодія Ethereum може зробити ключовий стрибок

Chainfeeds Вступ:

Без реального часу ZK дуже важко досягти справді зручного Interop UX.

Джерело статті:

Автор статті:

imToken Labs

Думка:

imToken Labs: 4 грудня оновлення Fusaka для Ethereum було офіційно активовано в основній мережі, хоча воно не було таким гучним, як колись оновлення Dencun, а увага ринку була зосереджена переважно на Blob масштабуванні та PeerDAS, із захопленням обговорюючи подальше зниження вартості даних для L2. Однак поза цим шумом існує ще одна непомітна пропозиція — EIP-7825, яка усунула найбільшу перешкоду для реалізації L1 zkEVM та доказів у реальному часі для Ethereum, і навіть можна сказати, що вона тихо прокладає шлях до фінальної мети Interop. У цьому оновленні Fusaka майже вся увага була прикута до масштабування: обсяг Blob збільшено у 8 разів, а разом із випадковою вибірковою перевіркою PeerDAS, наратив про вартість DA (доступність даних) остаточно став історією. Дійсно, дешевші L2 — це добре, але для довгострокової ZK-дорожньої карти Ethereum саме EIP-7825 є справжнім геймченджером, оскільки він встановлює ліміт Gas для однієї транзакції (близько 16,78 мільйонів Gas). Як відомо, цього року ліміт Gas блоку Ethereum вже підвищено до 60 мільйонів, але навіть із постійним підвищенням, теоретично, якщо хтось готовий платити надзвичайно високу ціну Gas, він все одно може відправити надскладну "мега-транзакцію", яка повністю заповнить обсяг блоку у 60 мільйонів Gas, що призведе до блокування всього блоку. То чому ж потрібно обмежувати розмір однієї транзакції? Насправді ця зміна не впливає на звичайних користувачів, але для ZK Prover (генератора доказів) це питання життя і смерті, і це тісно пов’язано зі способом генерації доказів у ZK-системах. Наприклад, до EIP-7825, якщо у блоці була "мега-транзакція", що споживає 60 мільйонів Gas, ZK Prover повинен був послідовно виконати цю надзвичайно складну транзакцію, не маючи можливості її розділити чи обробляти паралельно — це як односмугова автомагістраль, де попереду повільно їде величезна вантажівка, і всі інші машини (інші транзакції) змушені чекати, поки вона проїде. Це фактично означає "смертний вирок" для доказів у реальному часі — оскільки час генерації доказу стає неконтрольованим і може тривати десятки хвилин або навіть довше. Однак після EIP-7825, навіть якщо у майбутньому обсяг блоку збільшиться до 100 мільйонів Gas, оскільки кожна транзакція обмежена 16,78 мільйонами Gas, кожен блок розбивається на передбачувані, обмежені, паралельно оброблювані "маленькі завдання", що означає, що генерація доказів для Ethereum перетворюється з важкої "логічної задачі" на суто "проблему потужностей (Money Problem)": якщо можна залучити достатньо паралельних обчислювальних ресурсів, можна обробити ці розбиті маленькі завдання за дуже короткий час, тим самим згенерувавши ZK-доказ для великого блоку. Проте, хоча EIP-7825 шляхом обмеження розміру однієї транзакції проклав фізичний шлях для доказів у реальному часі (можливість паралелізації), це лише одна сторона медалі. Інша сторона — як сама основна мережа Ethereum зможе скористатися цією можливістю? Це стосується найскладнішого наративу у дорожній карті Ethereum — L1 zkEVM. Довгий час zkEVM вважався "Святим Граалем" масштабування Ethereum не лише тому, що він вирішує проблему продуктивності, а й тому, що він переосмислює механізм довіри блокчейну. Його основна ідея — надати основній мережі Ethereum можливість генерувати та верифікувати ZK-докази. Іншими словами, у майбутньому після виконання кожного блоку Ethereum можна буде отримати перевіряємий математичний доказ, завдяки якому інші вузли (особливо легкі вузли та L2) зможуть підтвердити правильність результату без повторного виконання обчислень — якщо можливість генерувати ZK-докази буде безпосередньо вписана у протокольний рівень Ethereum (L1), то кожного разу, коли пропозер (Proposer) пакує блок і генерує ZK-доказ, вузли-верифікатори більше не повинні повторно виконувати транзакції, а лише перевіряють цей невеликий математичний доказ.