*Переслати оригінальний заголовок „Як ZKP та ZK-Rollups допомагають вирішити проблему масштабованості: огляд блокчейну zkSync“

У цій статті ми пояснимо, що таке технологія доказу відсутності знань та поговоримо про популярний блокчейн — zkSync: як працюють транзакції в zkSync та основні відмінності від Ethereum Virtual Machine (EVM). Також обговоримо переваги та недоліки цього блокчейну, який, на нашу думку, може мати перспективне майбутнє.

ZkSync - це блокчейн другого рівня (Шар 2 — L2) для Ethereum, призначений для вирішення проблем високих комісій та обмеженої пропускної здатності (транзакції на секунду — TPS) на мережі Ethereum. Ця платформа використовує технологію ZK-Rollup, яка використовує докази з нульовим відомостями (ZKP), щоб пакувати кілька транзакцій поза основною мережею (L1). До L1 надсилаються лише криптографічні докази правильності транзакцій та їх стиснуті дані, що значно підвищує ефективність та зменшує витрати.

Розроблено Matter Labs, zkSync оголошено як повністю відкритий продукт (100% відкритий код), керований спільнотою. Згідно з Крипторанк, проект вже привернув увагу, привернув інвестиції у розмірі $458 мільйонів. У довгостроковій перспективі Matter Labs має на меті створити комплексну екосистему. Наразі працюють два блокчейни: zkSync Lite, який обробляє платежі в ETH та токенах ERC20, та zkSync Era, що підтримує повноцінні смарт-контракти. У майбутньому планується запуск гіперчейн системи (L3), забезпечуючи високий рівень безпеки. Мета Matter Labs - масштабувати технологію до рівня, який приверне наступний мільярд користувачів блокчейну.

Фон

ZkSync представляє собою новий підхід до вирішення проблеми масштабованості, відому як трилема блокчейнуЦей проект, як і інші рішення другого рівня (L2), прагне знайти баланс між безпекою, масштабованістю та децентралізацією в блокчейн мережах.

1. Масштабованість: Здатність системи ефективно обробляти зростаючий обсяг транзакцій або даних без втрати продуктивності та безпеки.
2. Блокчейн Безпека: Забезпечення надійності та захисту даних від несанкціонованого доступу, втручання або модифікацій.
3. Децентралізація: Відсутність централізованої контролюючої структури. У децентралізованій системі управління та прийняття рішень демократично розподілені серед усіх учасників мережі.

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

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

Шар 2

Основним завданням для збільшення TPS мережі Ethereum без збільшення навантаження на вузли було введення Шардингв поєднанні з переходом до консенсусу PoS (Proof of Stake). Це передбачало розділення валідаторів на підгрупи для обробки окремих сегментів мережі, тим самим зменшуючи загальне навантаження та збільшуючи пропускну здатність. Однак спільнота зосереджується на рішеннях 2-го рівня, враховуючи їх швидкий розвиток.

Крім ідеї впровадження Sharding в Ethereum, з'явилися інші рішення щодо масштабованості, такі як:

• Оплата і канали стану
• Бічні ланцюги
• Плазма
• Оптимістичний Rollup

А також технології, що базуються на доказах з нульовим знанням (ZKP), включаючи:

• Validium
• zkRollup
• Воля

Більш детальну інформацію можна знайти тут.

Хоча шардінг все ще знаходиться в стадії розробки, заплановано проведення хардфорку Dencun на початку 2024 року, який реалізує Прото-DankshardingЦей проміжний крок спрямований на поліпшення рішень 2-го рівня, зроблення зберігання даних на L1 більш економічним. Отже, Proto-Danksharding обіцяє зменшити витрати на транзакції на L2, як крок до повноцінного рішення Sharding.

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

У ця стаття, запропоновані ключові критерії для оцінки протоколів, використовуваних у рішеннях 2-го рівня. Вони включають в себе:

• безпека,
• продуктивність та економічна ефективність,
• простота у використанні,
• додаткові аспекти, такі як підтримка смарт-контрактів, сумісність байт-коду EVM та опції конфіденційності.

Важливо! Стаття написана Matter Labs і, на мою думку, деякі речі "розтягнуті" на користь zkRollup (оскільки існує чіткий конфлікт інтересів), але це не так важливо, головне - побачити, які різниці існують між протоколами другого рівня.

Нижче я надам таблицю, а тут коротко опишу її зміст.

Безпека

• Припущення про живість або «життєздатність» Layer-2. Припускається, що для забезпечення функціональності Layer-2 деякі учасники завжди будуть на ланцюгу на рівні Layer-1, щоб реагувати на потенційні випадки шахрайства. Це або валідатори, які відкладають певну суму коштів (позначену як «Забезпечено» в таблиці) на L1, або треті сторони, які забезпечують безпеку протоколу за винагороду. Як видно з таблиці, рішення, що використовують ZKP (Validium та zkRollup), не мають цієї необхідності.
• Проблема масового виходу. Проблема, яка виникає, якщо з погляду безпеки необхідно ініціювати виведення коштів всіма користувачами з рівня L2 на рівень L1. Як видно з таблиці, ця проблема існує лише з протоколом Plasma, про який можна прочитати тут.
• Опіка. Питання про те, чи можуть валідатори L2 тимчасово блокувати або конфісковувати кошти користувачів.
• Економічні вразливості. Включає різноманітні атаки на L2 валідаторів, включаючи хабарництво L1 майнерів, створення «тіньових» DAOs та інші економічно мотивовані атаки.
• Криптографія. Відмінність між стандартними та новими криптографічними примітивами. Стандартні були більш досліджені та потенційно вразливі, тоді як нові (такі як SNARK та STARK) забезпечують більшу надійність, але вимагають додаткових знань та перевірок від розробників.

Професійна діяльність та економіка

Щодо продуктивності, все просто. TPS (транзакції на секунду) вказує на пропускну здатність мережі, і в контексті масштабування це найважливіший параметр.

Економічні аспекти:

• Ефективність капіталу: Цей аспект особливо важливий для Платіжних каналів. Вони потребують заморожування коштів у розмірі середньої обсягу операцій у каналі, що робить їх менш ефективними з точки зору капіталовкладень.
• L1 Транзакція для створення облікового запису L2. Також недолік для платіжних каналів, оскільки у всіх інших рішеннях обліковий запис, створений у L1, працює за замовчуванням у L2.
• Вартість транзакції: Разом з TPS це один із найважливіших чинників масштабованості, що визначає економічну привабливість рішення.

Зручність використання

• Час виведення з L2 на L1: Цей період може варіюватися від кількох хвилин до кількох тижнів. Оптимістичні ролапи та Плазма особливо незручні у цьому відношенні, оскільки вони потребують більше часу для виведення коштів.
• Час до суб'єктивної остаточності транзакції: Визначає, наскільки швидко транзакція стає незворотньою на рівні L1 з погляду зовнішніх спостерігачів. Наприклад, у оптимістичних роллапах досягнення остаточності на рівні L1 потребує лише одного підтвердження на Ethereum, але повна остаточність транзакції займає приблизно тиждень.
• Перевірка суб'єктивної остаточності з клієнтським кодом: Визначає, чи можна перевірити час суб'єктивної остаточності за допомогою легких клієнтів (браузерів / мобільних гаманців). Продовжуючи за прикладом Оптимістичних Роллапів, для підтвердження остаточності транзакції користувач повинен завантажити та перевірити весь стан роллапу за останній тиждень.
• Миттєві підтвердження транзакцій. Чи може протокол забезпечувати миттєві підтвердження транзакцій із повною гарантією? Або це гарантується лише на рівні консенсусу L2.
• Миттєва видима завершеність: Може бути реалізована на вершині більшості L2 протоколів, що означає, що транзакції миттєво підтверджуються в інтерфейсі користувача. Тільки платіжні канали (станові канали) пропонують повну гарантію безпеки для цих підтверджень, тоді як у інших протоколах ці транзакції все ще можуть бути скасовані протягом певного часу, поки вони не будуть підтверджені в L1.

Інші аспекти

• Смарт-контракти: Розгляд питання про те, чи підтримує рішення L2 повністю програмовані смарт-контракти, чи лише обмежений підмножина функцій через предикати.
• Сумісність з байт-кодом EVM: Оцінює можливість перенесення існуючих розумних контрактів байт-коду Ethereum EVM на L2 без значних змін.
• Вбудована підтримка конфіденційності: Розгляд ефективності захисту конфіденційності в рішеннях L2, особливо в контексті доступності та вартості конфіденційних транзакцій.

Нижче подано порівняльну таблицю основних рішень на основі ZKP:

Для більш детального розуміння доказів нульового знання (ZKP) рекомендую звертатися до ця статтяв нашомублокчейн-вікі, створений розробниками для розробників з любов'ю до доказів та глибоких занурень у деталі.

Цикл транзакції в zkSync

Операцію ZK-Rollups можна представити на високому рівні наступним чином:

1. Утворення Rollup: Транзакції упаковуються в Rollup.
2. Створення ZKP: Доказ нульового знання формується.
3. Підтвердження в Ethereum: Доказ надсилається для перевірки на розумний контракт Ethereum.

У контексті архітектури zkSync процес виглядає наступним чином:

1. Колекція внутрішніх блоків: валідатори zkSync збирають внутрішні блоки з транзакцій кожні декілька секунд.
2. Формування блок-пакету: кожні 30-90 секунд створюється пакет блоків з внутрішніх блоків.
3. Зобов'язання стану блокчейну: Валідатори записують поточний стан блокчейну та передають змінені дані L1 як вхідні дані для можливого відновлення.
4. Обчислення та відправлення SNARK: Валідатори обчислюють SNARK (ZKP) для пакета та надсилають його на перевірку до смарт-контракту Ethereum. Після перевірки новий стан мережі стає остаточним.

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

Примітка: В епоху zkSync роль валідаторів виконується операторами.

Розробники zkSync відзначають наступні гарантії своєї архітектури:

1. Безпека фонду: Оператори ніколи не можуть пошкодити стан мережі або вкрасти кошти, що є перевагою порівняно з бічними ланцюжками.
2. Можливість відновлення коштів: Користувачі завжди можуть вилучити свої кошти навіть у випадку припинення діяльності операторів. Це можливо завдяки доступності даних, на відміну від системи Plasma.
3. Незалежність від моніторингу: завдяки ZKP користувачам або довіреним третім сторонам не потрібно постійно контролювати блоки Rollup, щоб запобігти шахрайству, що є перевагою порівняно з системами, що базуються на доказах шахрайства, такими як Платіжні канали або Оптимістичні Rollups.

Транзакції в епоху zkSync проходять кілька ключових станів, відмінних від звичайних підтверджень Rollup на рівні L1:

• Очікуйте: Операцію отримано оператором, але вона ще не оброблена.
• Оброблено: Транзакцію обробляє оператор і готова до включення у наступний блок.
• Зафіксовано: Дані операції публікуються в Ethereum, забезпечуючи доступність даних, але не підтверджують її правильне виконання.
• Виконано: Останній етап, коли доказ валідності (SNARK) для транзакції перевіряється смарт-контрактом Ethereum, зроблючи транзакцію остаточною.

Крім номера блоку, у транзакціях zkSync також відображається номер пакету. Спочатку параметри, такі як block.number, block.timestamp та blockhash, бралися з L1. Однак після оновлення, ці значення тепер будуть отримуватися з L2. Незважаючи на це, розробники планують забезпечити методи доступу до даних з L1.

Відмінності між zkEVM та EVM

Сумісність рішень L2, що базуються на ZKP з Ethereum, є складним завданням. Це пов'язано з тим, що Ethereum спочатку не був розроблений для оптимальної взаємодії з ZKP. У результаті при розробці таких систем необхідно знайти компроміс між продуктивністю та потенціалом масштабованості з одного боку, та сумісністю з Ethereum та EVM з іншого. Стаття Vitalik Buterin«Різні типи ZK-EVMs»обговорює ці аспекти детально і висвітлює різні рівні сумісності.

zkSync обрав один з найважчих шляхів, спрямованих на високу продуктивність, але з обмеженою сумісністю як з Ethereum, так і з EVM. Щоб отримати байткод, сумісний з zkEVM, LLVMпроект використовується з набором власних компіляторів та оптимізаторів. У випадку Solidity та Yul після стандартного компілятора solc код проходить кілька етапів, перш ніж стає байткодом zkEVM. Наведена нижче діаграма ілюструє всі етапи цього процесу (детальніше описанотут):

Важливо! Оптимізації в zksolc підтримуються.

Байткод, спеціально скомпільований для EVM, несумісний з zkEVM. Це означає, що адреси ідентичних смарт-контрактів в Ethereum та zkSync будуть відрізнятися. Проте розробники планують вирішити цю проблему у майбутньому.

Однією з важливих переваг цього підходу є незалежність від конкретних мов програмування. У майбутньому розробники zkSync обіцяють додати підтримку мов, таких як Rust і C++. Важливо, щоб затримка в оновленнях та інтеграція новацій між високорівневими компіляторами (наприклад, solc) та платформовими компіляторами (наприклад, zksolc) була мінімальною. Спочатку була ідея створити власну мову програмування, Zinc, але на даний момент команда фокусується на підтримці більш популярних мов програмування.

Питання сумісності zk-компіляторів з існуючими засобами розробки та налагодження для розумних контрактів Solidity та Vyper є значущим. Поточні платформи розробки, такі як Remix, Hardhat та Foundry, не підтримують zk-компілятори з коробки, що ускладнює роботу з ними. Однак рішеннярозробляються проекти, які обіцяють спростити процес міграції проєктів та адаптацію до нових технологій.

У статті Віталіка Бутеріна зазначається, що Ethereum ймовірно буде прагнути покращити сумісність з ZKP на рівні протоколу з часом. Так само, L2-рішення з ZKP адаптуються для кращої сумісності з Ethereum. У результаті у майбутньому різниці між цими системами можуть стати майже непомітними, забезпечуючи більш плавну інтеграцію та перехід для розробників.

Особливості zkEVM

Важливо! Протокол активно розробляється; завжди звертайтеся до останньої версії документації!

zkEVM відрізняється від EVM і, незважаючи на зусилля розробників приховати ці відмінності «під капотом», є важливі особливості, які слід враховувати при написанні смарт-контрактів:

1. Відмінності від EVM: Поведінка коду, написаного в Solidity для zkEVM, може відрізнятися, особливо в аспектах, таких як block.timestamp та block.number. Важливо регулярно перевіряти документаціяпро зміни.
2. Системні контракти: У zkSync існують системні розумні контракти для різних функцій, такі як ContractDeployer для розгортання розумних контрактів та MsgValueSimulator для роботи з ETH. Більше про системні розумні контракти можна знайти в документація.
3. Шаблон Проксі для Розгортання: Рекомендується використовувати шаблон проксі під час перших кількох місяців після розгортання для запобігання можливих помилок компілятора.
4. Розрахунок газу: Модель розрахунку газу в zkEVM відрізняється від Ethereum, включаючи інший набір опкодів та залежність ціни газу від L1. Деталі можна знайти тут.
5. Локальне тестування: Стандартні інструменти, такі як Hardhat Node або Anvil, не підходять для локального тестування zkEVM. Замість цього, спеціальні опціївикористовуються, включаючи тестування у режимі вілки.
6. Перевірка підпису: Рекомендується використовувати вбудовану підтримку абстракції облікового запису замість ecrecover.
7. Відстеження Помилок, Пов'язаних з Газом: У zkSync неможливо відстежити помилки, пов'язані з нестачею газу через специфіку виконання в межах системи розумного контракту DefaultAccount.

Для глибокого розуміння роботи з zkEVM рекомендується вивчити документацію, включаючи розділ "Безпека та найкращі практики".

Абстракція рахунку

Абстракція облікового запису в zkSync має кілька ключових переваг порівняно з ERC-4337:

1. Рівень впровадження: У zkSync абстрагування облікового запису вбудоване на рівні протоколу, що робить всі облікові записи, включаючи зовнішні власні облікові записи (EOA), функціонально схожими на розумні контракти.
2. Обробка транзакцій: Під час використання ERC-4337 використовується окремий пул пам'яті для пакувальників, створюючи два різних потоки транзакцій, zkSync Era має єдиний пул пам'яті. Це означає, що транзакції, що виникають з EOAs та розумних контрактів, обробляються в одному потоці, забезпечуючи більш гладку інтеграцію та обробку.
3. Підтримка для платіжних агентів: zkSync підтримує платіжних агентів для всіх типів рахунків, що дозволяє налаштовувати комісію за газ у токенах ERC20 для будь-якого рахунку.

Інфраструктура zkSync

Інфраструктура ери zkSync швидко набирає оберти і вже включає десятки протоколів: Мости, DeFi, інфраструктурні протоколи та інше. (Поточний список можна переглянутитут).

Ще однією перевагою є сумісність з гаманцями Ethereum, такими як MetaMask або TrustWallet.

Гіперланцюги

Протокол zkSync розпочав свій розвиток з запуску zkSync Lite, призначеного лише для переказів етеру та токенів ERC-20, без можливості розгортання повноцінних протоколів. Ця стадія була важливим кроком у розвитку, але передувала лише прихід ери zkSync — повноцінного рішення L2 для Ethereum, яке теоретично може бути адаптоване для інших блокчейнів L1. Однак амбіції zkSync тут не закінчуються, оскільки плани розвитку включають запуск так званих гіперланцюгів.

Гіперланцюги, або «фрактальне масштабування», складаються з мереж ZKP, кожна з яких формує свої власні блоки та докази. Ці докази потім збираються разом і публікуються в основній мережі L1. Кожна з цих мереж є повністюю копією всієї системи та може розглядатися як її «фрактал».

Унікальність гіперланцюгів полягає в тому, що їх можна створювати та розгортати незалежно. Для забезпечення послідовності та сумісності кожен гіперланцюг повинен використовувати спільний рушій zkEVM, який є частиною ZK стеку (при цьому zkSync Era виступає першим гіперланцюгом). Це дозволяє гіперланцюгам успадковувати свою безпеку від L1, забезпечуючи їх надійність та усуваючи потребу в додаткових заходах довіри та безпеки.

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

• Підтвердження передачі між гіперланцюгами: Гіперланцюги передаватимуть блокові підтвердження одне одному, збільшуючи відстань, яку повинна пройти транзакція, перш ніж дійде до основної мережі L1. Це допомагає розподілити навантаження й уникнути проблем заторів.

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

Більше про все це можна знайти тут.

Переваги та недоліки zkSync

про

1. Безпека: Безпека, близька до рівня L1 та потенціал для децентралізації у майбутньому.
2. Сумісність EVM: Підтримка смарт-контрактів, сумісних з EVM.
3. Web3 API та Гаманці: Стандартний Web3 API та підтримка гаманців Ethereum, таких як MetaMask.
4. Абстракція облікового запису: Підтримка абстракції облікового запису на рівні мови.
5. Швидкість транзакції: Швидка обробка транзакцій на L2 з подальшим підтвердженням на L1.
6. Низькі комісії: Зменшення газових витрат порівняно з L1.
7. ERC20 Оплата газу: Можливість оплати комісій за газ у токенах ERC20.
8. Розвиваюча інфраструктура: Дуже активний розвиток інфраструктури.
9. Потенціал масштабованості: можливості для значних покращень у масштабованості.

Про

1. Обмежена сумісність EVM: Порівняно з конкурентами (наприклад, Polygon zkEVM, Scroll), вона має меншу сумісність EVM.
2. Ризик помилок в смарт-контрактах: збільшений ризик помилок, що вимагає ретельного тестування та аудиту.
3. Потреба в конкретному стеку розробки: Необхідність адаптації стеку розробки до конкретики протоколу.
4. Відстаючи від основних технологій: Затримка у впровадженні інновацій в компіляторах та оновленнях бібліотек.
5. Централізація мережі: В даний час мережею керує обмежена кількість операторів.
6. Потреба в оновлюваних розумних контрактах: З усього вищевказаного випливає, що завжди необхідно створювати оновлювані контракти на початку проєкту, щоб мати змогу швидко виправляти недоліки та вразливості.

Висновок

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

Попередження:

1. Ця стаття перепечатана з [ MetaLamp]. Переслати оригінальний заголовок «Як ZKP та ZK-Rollups допомагають вирішити проблему масштабованості: огляд блокчейну zkSync». Усі авторські права належать оригінальному автору [MetaLamp]. Якщо є зауваження до цього видруку, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно з цим впораються.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору, і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.