Браян Пак є генеральним директором і співзасновником ChainLight, фірми з блокчейн-безпеки, яка спеціалізується на аудиті смарт-контрактів і моніторингу в мережі.

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

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

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

Але, незважаючи на ажіотаж, є велика проблема. Незнання ЖК – це бомба уповільненої дії.

Більшість крипторозробників все ще дуже мало знають про цю складну тему.

І оскільки все більше розробників починають експериментувати з технологією ZK, це створює серйозні ризики безпеці та навіть заважає технології реалізувати свій справжній потенціал.

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

Розробники ZK «нерозумні»

У 2022 році співзасновник Ethereum Віталік Бутерін вказав на ризики безпеки, пов’язані з зведенням ZK, як-от помилки в коді обмеження схеми.

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

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

Після попередження Бутеріна розробники виявили ще кілька вразливостей у проектах, що використовують технологію ZK.

У листопаді ChainLight виявив помилку в ZK-схемах ZK Sync Era, яка могла дозволити хакеру вкрасти 1,9 мільярда доларів.

Також у 2018 році криптограф Zcash виявив уразливість у доказах нульового знання, які лежать в основі протоколу. Якщо цю помилку не виправити, вона могла дозволити зловмиснику створити підроблені токени Zcash, не виявивши її.

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

Багато розробників, які пишуть код, і професіонали з безпеки, які повинні погоджуватися з його безпекою, просто недосяжні.

І це не дивно — будь-хто скаже вам, що для того, щоб розібратися в аспектах безпеки технології ZK, потрібен ступінь доктора філософії з математики.

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

І відсутність експертів для належного аудиту ZK-коду – не єдина проблема.

Зведені пакети ZK, такі як zkSync Era та StarkNet, розробляються власними силами, і, як наслідок, процеси експертної перевірки не такі ретельні, як стандарти, прийняті в академічних колах.

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

ЗК не реалізує свій потенціал

Відсутність розуміння технології ZK також заважає їй реалізувати свій потенціал.

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

Наприклад, однією з головних переваг, що рекламуються зведеннями ZK, є миттєва остаточність.

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

Optimistic rollups, головний конкурент ZK rollups, вимагає семиденного періоду очікування для виведення активів.

Зростає консенсус щодо того, що зведені ZK є найкращим рішенням для масштабування Ethereum у порівнянні з Optimistic.

Деякі заходять так далеко, що описують їх як «святий Грааль» рішень для масштабування.

Співзасновник Immutable X Роббі Фергюсон описав зведення ZK як «найпростіший спосіб масштабувати транзакції з високою пропускною здатністю».

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

Наприклад, жоден із існуючих зведених пакетів ZK насправді не має рекламованої миттєвої остаточності.

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

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

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

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

Безпека за проектом

У всьому web3 — не лише у сфері ZK — проекти не сприймають аудит достатньо серйозно.

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

Є кілька випадків, коли відомі помилки проникли в нові протоколи DeFi, коштуючи інвесторам мільйони.

Наприклад, кілька протоколів, які розгалужували код протоколу кредитування Compound v2, наприклад Hundred Finance та Onyx Protocol, робили це наосліп і не враховували відомі вектори атак у коді.

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

Розробка проекту починається з того, щоб бути в курсі загроз в екосистемі.

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

Хоча нездатність створити протоколи, які є безпечними за дизайном, буде проблемою для будь-якого проекту, це особливо згубно у випадку технології ZK.

Наприклад, давайте подивимося на існуючі ZKEVM — зведені ZK, які ідеально повторюють операційну систему Ethereum.

Багато ZKEVM покладаються на визначені вручну схеми, які потребують участі людини та використовують молоді, неперевірені бібліотеки.

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

З інвесторами, які збираються збирати ZK, заохочувані потенційними токенами, вони стають прибутковими цілями для наступного великого криптографічного пограбування.

Рішення

Впровадження безпеки на самому початку циклу розробки та на постійній основі — наприклад, через винагороди за помилки — може допомогти виправити це.

Немає сумніву, що технологія ZK змінить правила гри для Ethereum, і постійний розвиток є фундаментальним для масштабування блокчейна.

Однак рішення, які пропонуються ZK rollups, відповідають тому, що вони можуть спричинити проблеми з безпекою.

Стартапи повинні спочатку бути чесними щодо того, чи використовують вони технологію ZK тому, що це необхідно, чи тому, що вони стрибають на підножку.

Якщо вони впевнені, що вони перші, то вони повинні усвідомлювати ризики, а будівництво з безпечним дизайном є абсолютно фундаментальним.