Останнім часом найчастіше запитують: як тлумачити поточний наратив Ethereum?
У 2017 році історія Ethereum була зосереджена на ICO та ідеї світового комп’ютера. До 2021 року акцент перейшов на DeFi і роль Ethereum як фінансового розрахункового шару. Але на підході до 2025 року новий наратив, співмірний із попередніми циклами, поки що не сформувався.
Дехто вважає, що ETF і Staking ETF — це часткові наративи, однак ці процеси не контролюються напряму спільнотою розробників Ethereum. Якщо говорити про іншого претендента — це ZK.
Ethereum — це публічний блокчейн, який найбільше інвестує у ZK-технології в криптоіндустрії.
Лише кілька днів тому Віталік із захопленням повідомив у Twitter, що ZKEVM перейшов у Alpha-фазу.
Чому Ethereum настільки зосереджений на ZK?
Поточний TPS Ethereum вже досить високий, а теоретичні піки перевищують 200 TPS — це стало можливим завдяки неодноразовому збільшенню ліміту gas.
Втім, підвищення ліміту gas має свою ціну і обмеження. Чим більший ліміт, тим дорожче сервери, потрібні для вузлів.
Разом з тим, Ethereum прагне зберігати свою децентралізацію, тому не може надмірно збільшувати вимоги до вузлів (для порівняння: сервер Solana приблизно у 5–10 разів дорожчий, ніж сервер Ethereum).
Тому повноцінна інтеграція ZK на рівні основної мережі є необхідною. Йдеться не лише про запуск окремих ZK Layer 2, а про комплексну інтеграцію ZK для Layer 1.
Що дає ZK?
Вузли Ethereum зможуть просто перевіряти ZK-докази, замість детальної перевірки кожної транзакції окремо.
Уявіть це як перевірку контрольних: вузли — це вчителі, а транзакції — роботи студентів.
Ручна перевірка — це повільно, а за наявності листів із відповідями (інтеграція ZK) машина миттєво підрахує результати кожного студента. Навантаження на вчителя суттєво знижується.
Тепер той, хто раніше міг перевірити 50 робіт, здатен обробити 1 000 — та сама людина, але з набагато більшою ефективністю.
Саме тому Ethereum потрібна ZK-інтеграція на основній мережі, щоб безпечно підвищувати ліміт gas ще більше.
Інтеграція ZK не є прямим чинником підвищення TPS — це передумова. Приріст продуктивності все ще залежить від збільшення ліміту gas, але з ZK вузли не потребують суттєвих додаткових витрат на сервери, і оновлення стає набагато дешевшим.
Після недавнього оновлення Fusaka — зокрема PeerDAS — продуктивність суттєво зросла, і Ethereum ще на крок ближче до інтеграції ZK на основній мережі. Саме це так надихає Віталіка.
Уявіть основну мережу з TPS понад 1 000 — це був би переконливий новий наратив для Ethereum.
Дехто питає: якщо Ethereum впровадить ZK-EVM на основній мережі, чи залишаються інші ZK-команди важливими?
Відповідь — так, безумовно.
Чому?
По-перше, ZK-інжиніринг — один із найскладніших проєктів у галузі, на рівні FHE. Це потребує глибокої криптографічної експертизи.
Ethereum Foundation має певні ресурси, але відкритий підхід базується на колективній роботі. Ethereum покладається на сторонні ZK-команди для експериментів і інновацій, і підтримує їх суттєво.
По-друге, існує чотири типи ZK-EVM — від першого до четвертого. Команди Polygon, Scroll, ZKsync і Taiko працюють із різними типами, розподіляючи роботу.
Є також ZK-VM, як-от Brevis.
Насправді позиція ZK-VM навіть стабільніша, ніж у ZK-EVM.
Чому? Серед чотирьох основних типів ZK-EVM, один, ймовірно, буде обраний як найефективніше рішення і стане частиною офіційної основної мережі Ethereum ZK-EVM, а решта три можуть бути відсунуті.
Але ZK-VM не сумісний з EVM, тому завжди буде частиною ширшої екосистеми Ethereum.
Оскільки VM не обмежені вимогами EVM, їхня продуктивність може бути значно вищою. ZK-EVM Ethereum не становить загрози — навпаки, спільнота Ethereum підтримує такі інновації.
Наприклад, Віталік публічно хвалив продуктивність ZK-VM Brevis і очікує його появи у сфері ZK-EVM.
А що з Layer 2? Вплив можливий, але він обмежений.
Віталік зазначав, що при обговоренні Polygon варто розділяти ZK і Layer 2.
З інтеграцією ZK на Layer 1 частина користувачів, ймовірно, повернеться з ZK Layer 2, адже дешевший Layer 1 зменшує мотивацію користуватися Layer 2.
Але варто пам’ятати: Layer 1 — це фундамент, Layer 2 — це хмарочос. Чим міцніший фундамент, тим краще. Тому інтеграція ZK на Layer 1 також знизить витрати і для Layer 2.
У тому ж дописі Віталік окремо згадав роботу Brevis із ZK-VM, підкресливши, що більшість їхніх досліджень ZK не обмежується Layer 2 — “дослідження ZK і Layer 2 мають залишатися окремими напрямками.”
Наприклад, вони запускають маркетплейс ZK-обчислень, допомагають Uniswap hooks впроваджувати розподіл винагород на основі ZK і просувають інновації для застосувань.
Отже, Ethereum працює вже 10 років, а заклики до інтеграції ZK тривають п’ять-шість років. Після багаторічних зусиль інтеграція ZK нарешті досягла Alpha-фази — це стало можливим завдяки постійній роботі Ethereum і багатьох сторонніх ZK-команд, зокрема Brevis і Polygon.
Відмова від відповідальності:
- Цю статтю повторно опубліковано з [Medium], авторське право належить оригінальному автору [Ebunker]. Якщо у вас є зауваження щодо цієї публікації, звертайтеся до команди Gate Learn для оперативного вирішення згідно зі стандартними процедурами.
- Відмова від відповідальності: думки та погляди, викладені в цій статті, належать автору і не є інвестиційною порадою.
- Інші мовні версії цієї статті перекладені командою Gate Learn. Якщо не згадано Gate, не копіюйте, не поширюйте і не плагіатуйте перекладений контент.
