TL;DR: У рамках наших зусиль із вивчення приватних рішень смарт-контрактів ми розробили систему децентралізованих приватних обчислень (DPC) VERI-ZEXE, яка підтримує універсальне налаштування. VERI-ZEXE покращує сучасний рівень [1] приблизно в 9,0 разів при генерації транзакцій і в ~ 2,6 рази при використанні пам’яті, і використовуватиметься в майбутніх версіях CAPE, щоб увімкнути довільну політику ресурсів, визначену користувачем, зберігаючи можливість налаштування конфіденційність активів.

Перегляньте документ ePrint тут і GitHub тут.

Системи розумних контрактів, такі як Ethereum і Solana, є чудовим середовищем для інновацій web3. Однак вони страждають від відсутності конфіденційності або масштабованості, а іноді і того, і іншого. Щоб забезпечити публічну перевірку, усі стани програм та зміни станів є публічними та прозорими, жертвуючи конфіденційністю, а всі транзакції чи обчислення повторно виконуються всіма (повними) вузлами, що впливає на масштабованість.

У 2019 році Боу та ін. запропонував схему під назвою децентралізоване приватне обчислення (DPC), яка дозволяє користувачам виконувати довільні обчислення поза ланцюгом і надсилати транзакцію, що засвідчує правильність цих обчислень, використовуючи докази з нульовим знанням [2]. Вони впровадили систему під назвою ZEXE (zk-виконання), яка створює екземпляр схеми DPC для вирішення обох проблемних моментів, наведених вище. Приблизно, ZEXE — це «програмований Zcash», узагальнений від системи з одним додатком до системи смарт-контрактів із збереженням гарантій конфіденційності.

Деякі варті уваги особливості ZEXE:

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

• Програмованість: за допомогою ZEXE користувачі можуть приєднувати довільні правила/предикати до запису (подібно до ідеї Bitcoin Script), який визначає правила переходу для відповідних станів програми. Bowe та ін. показали, як програмувати визначені користувачем активи, DEX і стейблкоїни, що відповідають нормам, у моделі ZEXE.

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

Існуючі реалізації (SnarkVM testnet 1 і SnarkVM testnet 2) забезпечують описані вище функції, але мають недоліки, які обмежують їх практичність і залишають багато можливостей для вдосконалення: [3]:

• Спеціальне налаштування схеми: ZEXE (SnarkVM testnet1) використовує неуніверсальні SNARK, як-от GM17 і Groth16, для сертифікації правильності виконання смарт-контрактів, що забезпечує надійне налаштування для кожної програми, що є дуже непрактичним.

• Продуктивність: ZEXE з універсальним SNARK (SnarkVM testnet2) зазнає значного погіршення продуктивності через вищу складність універсальної логіки перевірки SNARK і того факту, що ZEXE вимагає створення доказу SNARK для заяви, яка кодує логіку перевірки SNARK.

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

По-перше, ми порівнюємо себе з найсучаснішими реалізаціями ZEXE, серед яких найважливіші показники включають час генерації транзакції (тобто алгоритм Execute), використання пам’яті та розмір підтвердження дійсності транзакції. Як показано нижче, наша продуктивність відповідає оригінальному неуніверсальному ZEXE. Порівняно з найкращою універсальною реалізацією ZEXE ми досягли ~9,0-кратного покращення генерації транзакцій і ~2,6-кратного покращення використання пам’яті.

По-друге, ми надаємо детальніше порівняння з SnarkVM testnet2. Як показано нижче, розмір нашої зовнішньої схеми (яка використовується під час композиції перевірки глибини 2) набагато менший, і, отже, час перевірки на порядок швидший, що призводить до набагато швидшого створення перевірки для всіх параметрів транзакції:

Нарешті, щоб проілюструвати наші інновації в системі обмежень TurboPlonk і UltraPlonk, а також наші методи оптимізації, ми надаємо розбивку вартості обмежень для криптографічних будівельних блоків, які використовуються у VERI-ZEXE. Ми поділилися цими основними моментами щодо складності гаджетів, коли представили нашу бібліотеку Jellyfish на початку цього року.

Кількість PLONK обмежено для основних криптографічних будівельних блоків і алгебраїчних операцій. Ці цифри є специфічними для конструкції TurboPlonk.

Незважаючи на те, що ZEXE не є ідеальним рішенням для приватних смарт-контрактів (через інші проблеми, згадані в [3]), це чудове рішення для додатків із мінімальними спільними станами серед користувачів, які насолоджуватимуться високим паралелізмом і низькою залежністю від транзакцій за умов Модель UTXO. Продукт CAPE є чудовим прикладом того, як це може виглядати для користувачів.

Наразі наш протокол CAPE підтримує лише попередньо визначений набір політик активів (наприклад, увімкнення карбування, анонімних передач, заморожування ключів, призначені політики перегляду тощо), але не підтримує динамічні, визначені користувачем політики активів. Уявіть, що ви хочете створити новий «концертний токен», який має загальну кількість 1000 одиниць і може бути викарбуваний, лише якщо певний актив буде сплачено на вказану адресу. Ця нова політика карбування, пов’язана з нашим новим токеном концерту, виходить за рамки того, що може застосовувати поточний продукт CAPE. Це загальна вимога та бажана функція для емітентів активів, щоб мати можливість розробляти індивідуальні, більш складні політики для своїх майбутніх активів. VERI-ZEXE зробить таку можливість програмування можливою.

«VERI-ZEXE може служити основою для приватних смарт-контрактів. Порівняно з попередньою роботою, він підтримує універсальне налаштування та ~9x прискорення генерації транзакцій, а також ~2,6x економію використання пам’яті, підштовхуючи такі програми, як приватні стейблкоїни, з довільна, настроювана політика активів у сфері практичності», – каже Алекс Сюн, перший автор.

Біньї Чен, головний криптограф Espresso Systems, додав: «Методики, що лежать в основі VERI-ZEXE, не обмежуються забезпеченням конфіденційності, але також допомагають у масштабованості. Наприклад, ті самі методи можна використовувати для оптимізації продуктивності так званих zk-zk -rollup, де зведення застосовується до форматів транзакцій із нульовим знанням (приватних), таких як CAP або Zcash."

Ми опублікуємо більше про наші розробки для вдосконалення CAPE у наступних публікаціях і дуже раді, що ці новаторські інновації принесуть Espresso. Залишайтеся на зв'язку!

[1]: SnarkVM від Aleo має багато ітерацій: їх версія testnet1 є досить точною реалізацією ZEXE, описаною в документі S&P19, яка вимагає довірених налаштувань для конкретної програми; рання версія testnet2 замінює систему доказів, яка використовувалася для створення доказів для предикатів народження/смерті, з GM17 на Marlin, роблячи систему «універсальною»; пізніша версія testnet2 і майбутні версії testnet відходять від оригінальної моделі DPC, спрощуючи модель, але обмежуючи її програмованість (наприклад, забороняючи міжпрограмний виклик). Нова, спрощена, але обмежена модель DPC, оскільки testnet3 виходить за межі цього блогу, а наш код порівнюється з testnet1 і попередньою версією testnet2. Ми внесли додаткові модифікації в їхній код, щоб зробити справедливе порівняння під час бенчмарку, див. докладніше в розділі 4.2 статті.

[2]: Загальний потік обчислень поза ланцюгом і перевірки підтвердження цілісності обчислень у ланцюзі може звучати схоже на zk-rollup. Користувачі в ZEXE генерують підтвердження дійсності транзакції та надсилають транзакції безпосередньо в ланцюжок, тоді як користувачі в zk-Rollup надсилають транзакцію валідаторам зведення, які потім створять підтвердження zk для надсилання в ланцюг. Технічно ZEXE не хвилює, як виконується обчислення поза ланцюгом: одним користувачем, чи багатокористувацьким протоколом MPC, чи зведеним сервером, тому ми вважаємо ці два підходи взаємодоповнюючими.

[3]: Є багато інших проблем із ZEXE, зокрема проблема паралельності (коли кілька користувачів намагаються одночасно перевести спільний стан у новий стан), можливість атомарної композиції (досягнення програми, подібної до Flashloan, у ZEXE потребуватиме техніки, яку ми називаємо «в -нагромадження пакетів», які трохи змінюють нано-ядро запису (RNK) ZEXE), складність програмування предикатів у моделі UTXO (існуюче рішення, таке як Chialisp). Ми спробуємо представити наші підходи до деяких із цих проблем у наступних публікаціях блогу.

TL;DR: У рамках наших зусиль із вивчення приватних рішень смарт-контрактів ми розробили систему децентралізованих приватних обчислень (DPC) VERI-ZEXE, яка підтримує універсальне налаштування. VERI-ZEXE покращує сучасний рівень [1] приблизно в 9,0 разів при генерації транзакцій і в ~ 2,6 рази при використанні пам’яті, і використовуватиметься в майбутніх версіях CAPE, щоб увімкнути довільну політику ресурсів, визначену користувачем, зберігаючи можливість налаштування конфіденційність активів.

Перегляньте документ ePrint тут і GitHub тут.

Системи розумних контрактів, такі як Ethereum і Solana, є чудовим середовищем для інновацій web3. Однак вони страждають від відсутності конфіденційності або масштабованості, а іноді і того, і іншого. Щоб забезпечити публічну перевірку, усі стани програм та зміни станів є публічними та прозорими, жертвуючи конфіденційністю, а всі транзакції чи обчислення повторно виконуються всіма (повними) вузлами, що впливає на масштабованість.

У 2019 році Боу та ін. запропонував схему під назвою децентралізоване приватне обчислення (DPC), яка дозволяє користувачам виконувати довільні обчислення поза ланцюгом і надсилати транзакцію, що засвідчує правильність цих обчислень, використовуючи докази з нульовим знанням [2]. Вони впровадили систему під назвою ZEXE (zk-виконання), яка створює екземпляр схеми DPC для вирішення обох проблемних моментів, наведених вище. Приблизно, ZEXE — це «програмований Zcash», узагальнений від системи з одним додатком до системи смарт-контрактів із збереженням гарантій конфіденційності.

Деякі варті уваги особливості ZEXE:

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

• Програмованість: за допомогою ZEXE користувачі можуть приєднувати довільні правила/предикати до запису (подібно до ідеї Bitcoin Script), який визначає правила переходу для відповідних станів програми. Bowe та ін. показали, як програмувати визначені користувачем активи, DEX і стейблкоїни, що відповідають нормам, у моделі ZEXE.

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

Існуючі реалізації (SnarkVM testnet 1 і SnarkVM testnet 2) забезпечують описані вище функції, але мають недоліки, які обмежують їх практичність і залишають багато можливостей для вдосконалення: [3]:

• Спеціальне налаштування схеми: ZEXE (SnarkVM testnet1) використовує неуніверсальні SNARK, як-от GM17 і Groth16, для сертифікації правильності виконання смарт-контрактів, що забезпечує надійне налаштування для кожної програми, що є дуже непрактичним.

• Продуктивність: ZEXE з універсальним SNARK (SnarkVM testnet2) зазнає значного погіршення продуктивності через вищу складність універсальної логіки перевірки SNARK і того факту, що ZEXE вимагає створення доказу SNARK для заяви, яка кодує логіку перевірки SNARK.

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

По-перше, ми порівнюємо себе з найсучаснішими реалізаціями ZEXE, серед яких найважливіші показники включають час генерації транзакції (тобто алгоритм Execute), використання пам’яті та розмір підтвердження дійсності транзакції. Як показано нижче, наша продуктивність відповідає оригінальному неуніверсальному ZEXE. Порівняно з найкращою універсальною реалізацією ZEXE ми досягли ~9,0-кратного покращення генерації транзакцій і ~2,6-кратного покращення використання пам’яті.

По-друге, ми надаємо детальніше порівняння з SnarkVM testnet2. Як показано нижче, розмір нашої зовнішньої схеми (яка використовується під час композиції перевірки глибини 2) набагато менший, і, отже, час перевірки на порядок швидший, що призводить до набагато швидшого створення перевірки для всіх параметрів транзакції:

Нарешті, щоб проілюструвати наші інновації в системі обмежень TurboPlonk і UltraPlonk, а також наші методи оптимізації, ми надаємо розбивку вартості обмежень для криптографічних будівельних блоків, які використовуються у VERI-ZEXE. Ми поділилися цими основними моментами щодо складності гаджетів, коли представили нашу бібліотеку Jellyfish на початку цього року.

Кількість PLONK обмежено для основних криптографічних будівельних блоків і алгебраїчних операцій. Ці цифри є специфічними для конструкції TurboPlonk.

Незважаючи на те, що ZEXE не є ідеальним рішенням для приватних смарт-контрактів (через інші проблеми, згадані в [3]), це чудове рішення для додатків із мінімальними спільними станами серед користувачів, які насолоджуватимуться високим паралелізмом і низькою залежністю від транзакцій за умов Модель UTXO. Продукт CAPE є чудовим прикладом того, як це може виглядати для користувачів.

Наразі наш протокол CAPE підтримує лише попередньо визначений набір політик активів (наприклад, увімкнення карбування, анонімних передач, заморожування ключів, призначені політики перегляду тощо), але не підтримує динамічні, визначені користувачем політики активів. Уявіть, що ви хочете створити новий «концертний токен», який має загальну кількість 1000 одиниць і може бути викарбуваний, лише якщо певний актив буде сплачено на вказану адресу. Ця нова політика карбування, пов’язана з нашим новим токеном концерту, виходить за рамки того, що може застосовувати поточний продукт CAPE. Це загальна вимога та бажана функція для емітентів активів, щоб мати можливість розробляти індивідуальні, більш складні політики для своїх майбутніх активів. VERI-ZEXE зробить таку можливість програмування можливою.

«VERI-ZEXE може служити основою для приватних смарт-контрактів. Порівняно з попередньою роботою, він підтримує універсальне налаштування та ~9x прискорення генерації транзакцій, а також ~2,6x економію використання пам’яті, підштовхуючи такі програми, як приватні стейблкоїни, з довільна, настроювана політика активів у сфері практичності», – каже Алекс Сюн, перший автор.

Біньї Чен, головний криптограф Espresso Systems, додав: «Методики, що лежать в основі VERI-ZEXE, не обмежуються забезпеченням конфіденційності, але також допомагають у масштабованості. Наприклад, ті самі методи можна використовувати для оптимізації продуктивності так званих zk-zk -rollup, де зведення застосовується до форматів транзакцій із нульовим знанням (приватних), таких як CAP або Zcash."

Ми опублікуємо більше про наші розробки для вдосконалення CAPE у наступних публікаціях і дуже раді, що ці новаторські інновації принесуть Espresso. Залишайтеся на зв'язку!

[1]: SnarkVM від Aleo має багато ітерацій: їх версія testnet1 є досить точною реалізацією ZEXE, описаною в документі S&P19, яка вимагає довірених налаштувань для конкретної програми; рання версія testnet2 замінює систему доказів, яка використовувалася для створення доказів для предикатів народження/смерті, з GM17 на Marlin, роблячи систему «універсальною»; пізніша версія testnet2 і майбутні версії testnet відходять від оригінальної моделі DPC, спрощуючи модель, але обмежуючи її програмованість (наприклад, забороняючи міжпрограмний виклик). Нова, спрощена, але обмежена модель DPC, оскільки testnet3 виходить за межі цього блогу, а наш код порівнюється з testnet1 і попередньою версією testnet2. Ми внесли додаткові модифікації в їхній код, щоб зробити справедливе порівняння під час бенчмарку, див. докладніше в розділі 4.2 статті.

[2]: Загальний потік обчислень поза ланцюгом і перевірки підтвердження цілісності обчислень у ланцюзі може звучати схоже на zk-rollup. Користувачі в ZEXE генерують підтвердження дійсності транзакції та надсилають транзакції безпосередньо в ланцюжок, тоді як користувачі в zk-Rollup надсилають транзакцію валідаторам зведення, які потім створять підтвердження zk для надсилання в ланцюг. Технічно ZEXE не хвилює, як виконується обчислення поза ланцюгом: одним користувачем, чи багатокористувацьким протоколом MPC, чи зведеним сервером, тому ми вважаємо ці два підходи взаємодоповнюючими.

[3]: Є багато інших проблем із ZEXE, зокрема проблема паралельності (коли кілька користувачів намагаються одночасно перевести спільний стан у новий стан), можливість атомарної композиції (досягнення програми, подібної до Flashloan, у ZEXE потребуватиме техніки, яку ми називаємо «в -нагромадження пакетів», які трохи змінюють нано-ядро запису (RNK) ZEXE), складність програмування предикатів у моделі UTXO (існуюче рішення, таке як Chialisp). Ми спробуємо представити наші підходи до деяких із цих проблем у наступних публікаціях блогу.