Що таке фреймворк ZKThreads і як він працює?

ZKThreads — фреймворк, що використовує технологію доказів з нульовим розголошенням для підвищення продуктивності та масштабованості блокчейн-застосунків. Його представила команда StarkWare (розробник мережі Starknet) у співпраці з проєктом Cartridge у 2024 році в межах концепції «фрактального масштабування». 

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

Що таке ZKThreads?

ZKThreads — це zero-knowledge-фреймворк, який використовує можливості мережі Starknet для створення стандартизованого середовища розробки та виконання сумісних між собою DApp на блокчейні.

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

StarkWare та Cartridge розробили ZKThreads як частину бачення «повноцінної ZK-операційної системи» для блокчейнів. Фреймворк описують як стандарт для побудови «доказових» (provable) застосунків — подібно до того, як свого часу стандарт ERC-20 уніфікував випуск токенів на Ethereum. 

Мета ZKThreads — надати розробникам загальний інтерфейс, де різні програми, що використовують ZKP, можуть безшовно взаємодіяти одна з одною без необхідності запускати окремі блокчейни. Це своєрідне шардинг-рішення на рівні застосунків: кожен DApp отримує свою «нитку» (thread) з транзакціями, але всі вони працюють на спільній інфраструктурі Starknet. 

Як працює ZKThreads?

Процес обробки транзакцій у ZKThreads проходить у кілька етапів:

1. Розгортання логіки застосунку. Спочатку бізнес-логіка DApp (смарт-контракти, що визначають правила його роботи) розгортається в спеціальних контрактах ZKThread. Це середовище, де виконуються транзакції цього застосунку, ізольоване в межах «нитки».
2. Групування транзакцій. Замість індивідуальної обробки транзакцій, ZKThread накопичує їх у пакет (суб-блок) для спільної обробки. Наприклад, дії користувачів протягом певного періоду можуть бути згруповані. Це підвищує ефективність, дозволяючи обробляти одразу велику кількість операцій.
3. Створення криптографічного доказу. Після формування пакету спеціальний модуль — prover (доказувач) — генерує STARK-доказ (STARK proof) для цього суб-блоку. Доказ математично підтверджує, що всі транзакції в пакеті виконані коректно згідно з правилами смарт-контракту DApp.
4. Верифікація і оновлення стану. Згенерований доказ передається до секвенсера на L2 (Starknet), де працює спеціальний контракт ZKThread Verifier. Веріфікатор перевіряє доказ щодо актуального канонічного запису стану застосунку — тобто вже підтвердженого стану, який мережа вважає дійсним. Під час перевірки гарантується відсутність подвійного витрачання, валідність підписів і дотримання всіх правил протоколу. Якщо доказ коректний, канонічний запис стану DApp оновлюється на нове значення; якщо ні — усі зміни відхиляються. Таким чином забезпечується цілісність системи: жодна недійсна транзакція не потрапить у остаточний реєстр станів.

Особливістю ZKThreads є те, що за будь-яких проблем можна повернутися на базовий рівень Starknet. Якщо, приміром, доказ довго не генерується або виникає збій, транзакції DApp можуть бути підтверджені напряму в L2, минаючи ZKThread. Це гарантує liveness — «живучість» застосунку, тобто здатність продовжувати роботу за будь-яких умов.

Чим ZKThreads відрізняються від інших рішень?

ZKThreads належать до покоління другого рівня масштабування (як і zk-ролапи), проте мають кілька важливих відмінностей від традиційних рішень:

• Дані зберігаються поза блокчейном. У типовому zk-rollup обчислення виконуються поза L1, але стиснені дані транзакцій все ж періодично публікуються на основному ланцюгу для забезпечення доступності інформації. Натомість ZKThreads виносять і обчислення, і всі дані (стан і транзакції) за межі базового блокчейну, використовуючи ZKP для гарантії їх коректності. Це зменшує навантаження на основну мережу та дозволяє суттєво знизити витрати на зберігання і комісії.
• Спільний канонічний стан та інтероперабельність. ZKThreads від самого початку спроєктовані як «нитки» в межах єдиної системи, подібно до потоків в операційній системі. Всі застосунки на ZKThreads оперують на спільних ресурсах L2 Starknet і розділяють єдиний простір стану, хоч і мають власні підконтрольні «нитки». Це означає, що DApp в ZKThreads можуть безшовно взаємодіяти між собою у межах одного середовища (наприклад, викликати функції один одного, обмінюватися даними) без складних мостів чи окремих валідаторів. Натомість рішення на кшталт окремих L3-ланцюжків або незалежних ролапів працюють ізольовано, що призводить до фрагментації ліквідності та складнощів із сумісністю.
• Механізм перевірки і ланцюг довіри. ZKThreads використовують докази типу STARK, які перевіряються на рівні Starknet (L2) спеціальним контрактом. У традиційних zk-ролапах зазвичай застосовуються або zk-SNARK, або zk-STARK-докази, що публікуються у L1 і перевіряються смарт-контрактом основної мережі. Тобто класичний ролап покладається на L1 для остаточної перевірки, тоді як ZKThreads — на L2. З одного боку, це зменшує залежність від пропускної здатності L1 та пришвидшує фіналізацію змін (оскільки все відбувається на швидкому L2-рівні Starknet). З іншого — повна достовірність залежить від безпеки Starknet. Втім, Starknet сам є валідним ролапом Ethereum, тому ланцюг довіри все одно веде до Ethereum як до остаточного арбітра правильності. Таким чином, ZKThreads можна розглядати як рівень L3, інтегрований всередині L2: вони дають додатковий шар масштабування, але не відокремлений від базового середовища, як це було б у випадку окремих L3-ланцюжків.
• Гнучкість і гарантія продовження роботи. ZKThreads мають механізм fallback — за потреби DApp може тимчасово повернутися до виконання транзакцій напряму на Starknet. Це забезпечує гарантію liveness (живучості), якої бракує багатьом ізольованим ZK-рішенням. Наприклад, zk-coprocessor (окремий модуль для ZK-обчислень) не гарантує, що докази будуть завжди згенеровані — отже, його робота може зупинитися. Натомість у ZKThreads будь-яка «нитка» у разі збою може бути безпечно продовжена на базовому рівні Starknet, хоч і з втратою тимчасових переваг у масштабованості.

Варто зауважити, що технологія ZKThreads все ще нова і перебуває на ранніх стадіях впровадження. Генерація zero-knowledge доказів залишається ресурсномістким процесом, що потребує значних обчислювальних потужностей і часу.

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

Нині ZKThreads реалізовані переважно на Starknet, тому їх ширше застосування залежатиме від розвитку цієї екосистеми. Проте активна участь спільноти і поява перших успішних кейсів можуть прискорити дорослішання цієї технології.

Приклади застосування ZKThreads

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

• Децентралізовані біржі другого рівня (L2 DEX). Ринок DEX на Starknet до появи ZKThreads був обмежений, адже користувачам доводилося б сплачувати комісію за кожну трейдову операцію. Використання ZKThreads дозволяє змінити модель оплати: комісії складаються і стягуються лише один раз — при виведенні коштів з біржі на основний рівень. Це робить торгівлю дешевшою та практичнішою. Фактично, платформа на кшталт dYdX, що раніше працювала на окремому ролапі, теоретично може бути реалізована прямо на Starknet як ZKThread-біржа.
• Ончейн-ігри (session-based games). Ігри на блокчейні, де потрібна висока інтерактивність (покер, шахи тощо), страждають від проблем з комісіями — плата за кожен хід робить такі проєкти непрактичними. ZKThreads дозволяють змінити підхід: партія гри може виконуватися в межах окремої «нитки», а гравці оплатять лише фінальний запис результату в мережу Starknet.
• ZK-захищене проміжне програмне забезпечення (middleware) та спільна ліквідність. Багато інфраструктурних елементів DeFi та Web3 — таких як оракули (служби даних), мости між блокчейнами чи модулі ліквідності — можна реалізувати без створення окремих мереж. За рахунок цього оракул, наприклад, працюватиме під захистом загальної безпеки Starknet, а не на окремому наборі вузлів. Генеруючи докази своїх оновлень, він гарантуватиме актуальність і чесність даних для всіх підключених застосунків. Аналогічно, спільні пули ліквідності можна реалізувати як нитки: декілька DApp зможуть користуватися одним пулом, не турбуючись про сумісність — адже всі вони живуть на одному рівні Starknet. Це знижує фрагментацію ліквідності та ризики централізації, які виникають при використанні сторонніх мостів чи multi-chain рішень.
• Ончейн-ШІ та соціальні мережі. ZKThreads надають достатню обчислювальну потужність, щоб розгортати моделі штучного інтелекту прямо на блокчейні. Приміром, можна створити ШІ-модель як застосунок у ZKThread, яка навчається або виконує інтелектуальні завдання, а потім різні ігри чи соцмережі викликають цю модель через її канонічний стан. У такий спосіб можна мати єдиний ончейн-«мозок», яким спільно користуються багато платформ. Завдяки ZKThreads всі виклики AI фіксуватимуться з доказами коректності (наприклад, що модель працювала чесно згідно алгоритму). Подібно можна реалізувати спільні соціальні графи — бази даних взаємодії користувачів, доступні різним соцмережам або додаткам, без потреби дублювати їх у кожному проєкті окремо.