Компанія Anagram Build проводить більшість часу на дослідженнях нових криптографічних примітивів та їх застосуванні в конкретних продуктах. Один з наших останніх дослідницьких проєктів привів нас до області Перевірки обчислень (VC); наша команда використала ці дослідження для створення нової системи з відкритим вихідним кодом під назвою Bonsol. Ми вибрали цю галузь досліджень, враховуючи появу ефективних використань VC та узгоджених зусиль різних L1s для оптимізації ефективності витрат та масштабованості VC.

У цьому блозі у нас є дві мети.

• Спочатку ми хочемо переконатися, що ви розумієте VC як концепцію та можливі продукти, які вона дозволяє в екосистемі Solana.
• По-друге, ми хочемо представити вам наш останній твір, Bonsol.

Що взагалі таке перевірне обчислення?

Термін «Перевірка обчислень» може не з'являтися в інвестиційних презентаціях стартапів бичого ринку, але термін «Нульовий Знання» так. Отже, що означають ці терміни?

Перевірна обчислення (VC) виконує конкретну робоче навантаження таким чином, що воно надає підтвердження своєї роботи, яке може бути публічно перевірене без повторного виконання обчислень. Нульове знання (ZK) може довести висловлення про дані або обчислення без розкриття всіх даних або вхідних даних для обчислення. Терміни дещо змішані в реальному світі, ZK є дещо неправильним. Це більше стосується вибору інформації, яку потрібно зробити публічною для доведення висловлення про неї. VC є більш точним терміном і є загальною метою в багатьох існуючих архітектурах розподілених систем.

Як венчурний капітал допомагає нам будувати кращі криптопродукти?

Отже, чому ми хочемо додати системи венчурного капіталу або ZK на додаток до таких платформ, як Solana та Ethereum? Схоже, відповідь більше стосується безпеки для розробника. Розробник системи виступає посередником між довірою кінцевих користувачів до чорної скриньки та технічними функціями, які роблять цю довіру об'єктивно обґрунтованою. Використовуючи методи ZK/VC, розробник може зменшити площу поверхні для атаки в продуктах, які він створює. Системи венчурного капіталу зміщують локус довіри на систему доведення та обчислювальне навантаження, що доводиться. Це схожа інверсія довіри, яка виникає при переході від типового клієнто-серверного підходу web2 до підходу блокчейну web3. Довіра переходить від покладання на обіцянки компанії до довіри до відкритого вихідного коду та криптографічних систем мережі. З точки зору користувача, не існує справжніх систем нульової довіри, і я стверджую, що для кінцевих користувачів все це здається чорною скринькою.

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

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

У рамках нашої роботи в Anagram ми маємо можливість спілкуватися з безліччю засновників / розробників криптовалют, щоб зрозуміти, де поточний стан криптовалютного програмного стеку уповільнює інновації продукту. Історично наші розмови допомогли нам виявити цікавий тренд. Зокрема, когорта проектів активно переносить логіку продукту on-chain off-chain, оскільки це стає занадто дорогим, або їм потрібно додати більше екзотичної бізнес-логіки. Таким чином, на кінець ці розробники опиняються в пошуку систем і інструментів для балансу між on- та off-chain частинами продуктів, які вони розробляють, які стають все більш потужними. Це те місце, де VC стає критичною частиною шляху вперед у допомозі з'єднати світи on- та off-chain за допомогою довірених і перевірених методів.

Поїхали! Так як сьогодні працюють системи VC/ZK?

Функції VC та ZK зараз в основному виконуються на альтернативних обчислювальних шарах (так званих rollups, sidechains, relays, oracles або coprocessors), доступних через виклик до часу виконання смарт-контракту. Для забезпечення цього робочого процесу багато з L1-ланцюгів мають в процесі зусиль надання скорочень поза часом виконання смарт-контракту (наприклад, syscalls або precompiles), що дозволяє їм робити речі, які інакше були б надто дорогими on-chain.

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

Повна перевірка на ланцюжку

Для систем доведення VC і ZK, які можуть створювати невеликі докази, такі як Groth16 або деякі різновиди Plonk, доказ потім надсилається в ланцюжку та перевіряється в ланцюжку за допомогою раніше розгорнутого коду. Такі системи зараз дуже поширені, і найкращий спосіб випробувати це – використовувати Circom і верифікатор Groth16 на Solana або EVM. Недоліком є те, що ці системи доказів працюють досить повільно. Вони також зазвичай вимагають вивчення нової мови. Щоб перевірити 256-бітний хеш в Circom, вам потрібно вручну розібратися з кожним з цих 256 біт. Існує багато бібліотек, які дозволяють просто викликати хеш-функції, але за лаштунками вам потрібно заново реалізувати ці функції у вашому коді Circom. Ці системи чудово підходять, коли елемент ZK і VC у вашому випадку використання менший, і вам потрібно, щоб доказ був дійсним, перш ніж буде вжито якихось інших детермінованих дій. В даний час Bonsol відноситься до цієї першої категорії.

Підтвердження поза ланцюжкем

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

Мережі перевірки

Доказ подається до мережі перевірки, і ця мережа перевірки виступає як оракул для виклику смарт-контракту. Ви отримуєте детермінізм, але вам також потрібно довіряти мережі перевірки.

Синхронна перевірка на ланцюжку

Четвертий і останній режим досить відрізняється; в цьому випадку доведення та перевірка відбуваються одночасно і повністю on-chain. Саме тут L1 або смарт-контракт на L1 фактично може запустити ZK схему над вхідними даними користувача, яка дозволяє довести виконання за допомогою приватних даних. У дикій природі не так багато широко поширених прикладів цього, і, як правило, типи речей, які ви можете зробити з цим, обмежені більш базовими математичними операціями.

Огляд

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

Представляємо Bonsol!

Увійдіть Bonsol, нова система VC, розроблена та відкрита нами в Anagram. Bonsol дозволяє розробнику створювати перевірне виконавче середовище для приватних та публічних даних та інтегрувати результати в розумні контракти Solana. Зверніть увагу, що цей проект залежить від популярного інструментарію RISC0.

Цей проект був натхненний питанням, яке задавали багато проектів, з якими ми працюємо щотижня: «Як я можу зробити цю річ з приватними даними і довести це на ланцюжку?» Хоча «річ» відрізнялася у кожному випадку, базове бажання було однаковим: мінімізувати свої централізовані залежності.

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

Сценарій один

Додаток, який дозволяє користувачам купувати квитки на розіграш у басейнах різних токенів. Басейни щодня «вилливаються» зі світового басейну таким чином, що сума грошей у басейні (суми кожного токену) прихована. Користувачі можуть купувати доступ до все більш конкретних діапазонів токенів у басейні. Але є підвох: як тільки користувач купує діапазон, він одразу стає публічним для всіх користувачів. Користувач повинен вирішити купувати квиток. Він може вирішити, що це не варте покупки, або він може захистити свою частку в басейні, купивши квиток.

Bonsol вступає в гру, коли створюється пул і коли користувач платить за те, щоб діапазон став відомим. Коли пул створюється/відливається, програма ZK приймає приватні вхідні дані кількості кожного токена для відливання. Типи токенів є відомими вхідними даними, а адреса пулу є відомим входом. Цей доказ є доказом випадкового вибору зі загального пулу в поточний пул. Доказ містить зобов'язання щодо балансів. Смарт-контракт на ланцюжку отримає цей доказ, перевірить його і збереже зобов'язання таким чином, що коли пул урешті закриється, а баланси будуть відправлені власникам квитків на лотерею зі загального пулу, вони можуть перевірити, що суми токенів не змінювалися з моменту випадкового вибору на початку пулу.

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

Хоча існує багато способів здійснення цієї системи сортування лотерейних квитків, властивості Bonsol дозволяють досить легко не довіряти сутності, яка проводить лотерею. Це також підкреслює міжопераційність Solana та системи VC. Програма Solana (смарт-контракт) відіграє важливу роль у посередництві цього довіри, оскільки вона перевіряє докази, а потім дозволяє програмі перейти до наступної дії.

Сценарій два

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

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

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

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

Архітектура Bonsol

Ці сценарії використання допомагають описати, для чого корисний Bonsol, але давайте поглянемо на його поточну архітектуру, поточну модель стимулювання та потік виконання.

Наведене вище зображення описує потік від користувача, якому потрібно виконати певні обчислення, які можна перевірити, зазвичай це відбувається через децентралізовану програму, якій це потрібно, щоб дозволити користувачеві виконати певну дію. Це буде мати форму запиту на виконання, який містить інформацію про виконувану програму ZK, входи або набори входів, час, протягом якого обчислення повинні бути доведені, і підказку (саме так реле отримують оплату). Запит приймається естафетами, і вони повинні наввипередки вирішити, чи хочуть вони вимагати цього виконання, і почати доводити. Виходячи з конкретних можливостей операторів реле, вони можуть вирішити передати це, тому що чайові не варті того, або zkprogram або входи занадто великі. Якщо вони вирішать, що хочуть виконати це обчислення, вони повинні виконати вимогу щодо нього. Якщо вони першими отримають претензію, то їх докази будуть прийматися до певного часу. Якщо вони не нададуть доказ вчасно, інші вузли можуть вимагати виконання. Для того, щоб претендувати на перемогу, Реле повинен зробити ставку, яка в даний час жорстко закодована для tip / 2, яка буде скорочена, якщо вони не зможуть надати правильний доказ.

Bonsol був побудований на тезі, що більше обчислень буде перенесено на шар, де вони підтверджуються та перевіряються у ланцюжку, і що Solana стане «першорядним» ланцюжком для VC і ZK незабаром. Швидкі транзакції Solana, дешеві обчислення і ростуча користувацька база роблять його відмінним місцем для перевірки цих ідей.

Чи було легко це побудувати? Ані трохи!

Це не означає, що під час побудови Bonsol не було жодних викликів. Щоб взяти доказ Risco0 та перевірити його на Solana, нам потрібно зробити його меншим. Але ми не можемо просто це зробити без жертвування властивостями безпеки доказу. Тому ми використовуємо Circom та обгортаємо Risc0 Stark, який може бути приблизно в ~200кб, і обгортаємо його у доказ Groth16, який завжди виявляється 256 байтів. На щастя, Risc0 надав деякі початкові інструменти для цього, але це додає багато накладних витрат та залежностей до системи.

Коли ми почали створювати Bonsol і використовувати існуючі інструменти для обгортання Stark зі Snark, ми шукали способи зменшити залежності та збільшити швидкість. Circom дозволяє компілювати код Circom в C++ або wasm. Спочатку ми спробували скомпілювати схему Circom у файл wasmu, створений LLVM. Це найшвидший і найефективніший спосіб зробити інструмент Groth16 портативним і при цьому швидким. Ми вибрали wasm через його портативність, оскільки код C++ залежав від архітектури процесора x86, а це означає, що нові сервери на базі Macbook або Arm не зможуть його використовувати. Але це стало для нас глухим кутом на часовій шкалі, з якою нам довелося працювати. Оскільки більшість наших експериментів з дослідження продукту обмежені в часі, поки вони не доведуть свою цінність, у нас було 2-4 тижні часу, щоб перевірити цю ідею. Компілятор llvm wasm просто не зміг впоратися зі згенерованим кодом wasm. Доклавши більше зусиль, ми могли б обійти це, але ми спробували багато прапорців оптимізації та способів змусити компілятор llvm працювати як плагін wasmer для попередньої компіляції цього коду в llvm, але нам це не вдалося. Оскільки схема Circom складається з близько 1,5 мільйона рядків коду, ви можете собі уявити, що кількість Wasm стала величезною. Потім ми звернули увагу на спробу просто створити міст між C++ і нашою кодовою базою ретрансляторів Rust. Це також зазнало швидкої поразки, оскільки C++ містив специфічний для x86 код асемблера, з яким ми не хотіли возитися. Для того, щоб зробити систему загальнодоступною, ми просто завантажили систему таким чином, щоб використовувати код C++, але видалити деякі залежності. У майбутньому ми хотіли б розширити ще один напрямок оптимізації, над яким ми працювали. Це полягало в тому, щоб взяти код C++ і фактично скомпілювати його в граф виконання. Ці артефакти C++ з компіляції Circom здебільшого є просто модульною арифметикою над скінченні поляз дуже великим простим числом як генератором. Це показало деякі перспективні результати для менших і простіших артефактів на C++, але потрібно більше роботи, щоб зробити його працюючим з системою Risc0. Це через те, що згенерований код C++ складається з приблизно 7 мільйонів рядків коду, і генератор графів, схоже, досягає обмежень розміру стеку, а підвищення цих обмежень, схоже, призводить до інших недоліків, які ми не мали часу визначити. Навіть якщо деякі з цих шляхів не дали результатів, ми змогли зробити внесок у проекти OSS і сподіваємося, що в якійсь момент ці внески будуть включені в основний потік.

Наступний набір викликів більше пов'язаний з дизайном. Невід'ємною частиною цієї системи є можливість мати приватні входи. Ці входи повинні звідкись надходити, і через обмеження в часі ми не змогли додати якусь химерну систему шифрування MPC, щоб дозволити приватним входам бути в системі в замкнутому циклі. Тому, щоб задовольнити цю потребу та розблокувати розробників, ми додали поняття приватного сервера введення, який має перевіряти цього запитувача, який перевіряється підписом корисного навантаження, є поточним претендентом на доказ і вручати його йому. У міру розширення Bonsol ми плануємо впровадити систему порогового дешифрування MPC, за допомогою якої вузли Relay зможуть дозволити заявнику розшифровувати приватні входи. Всі ці дискусії про приватні вхідні дані підводять нас до еволюції дизайну, яку ми плануємо зробити доступною в репозиторії Bonsol. Це Bonsolace, яка є простішою системою, яка дозволяє вам, як розробнику, легко доводити ці zk-програми на власній інфраструктурі. Замість того, щоб звертатися до мережі prover, ви можете просто довести це самостійно та перевірити це за тим самим контрактом, який використовує мережа prover. Цей варіант використання призначений для дуже цінних випадків використання приватних даних, коли доступ до приватних даних повинен бути зведений до мінімуму за будь-яку ціну.

Останнє зауваження про Bonsol, яке ми ще не бачили в інших місцях, що використовують Risc0, полягає в тому, що ми змушуємо зобов'язуватися (хеш) над вхідними даними в програму zk. І ми фактично перевіряємо в контракті, що вхідні дані, які повинен був зробити виконавець, відповідають тому, що очікував користувач і відправив у систему. Це пов'язано з певною ціною, але без цього це означає, що організатор може обдурити і запустити програму zkprogram на входах, які користувач не вказав. Решта розробок Bonsol перейшла у звичайну розробку Solana, але слід зазначити, що ми навмисно випробували там деякі нові ідеї. У смарт-контракті ми використовуємо flatbuffers як єдину систему серіалізації. Це дещо нова техніка, яку ми хотіли б бачити розробленою та перетвореною на фреймворк, оскільки вона чудово підходить для автоматичної генерації SDK, які є кросплатформними. Останнє зауваження щодо Bonsol полягає в тому, що наразі йому потрібна попередня компіляція для найефективнішої роботи, ця прекомпіляція має з'явитися в Solana 1.18, але до того часу ми працюємо над тим, щоб побачити, чи зацікавлені команди в цьому дослідженні та заглядають за межі Bonsol в інші технології.

Завершення

Поза Bonsol команда Anagram глибоко досліджує багато місць у сфері ВК. Проекти, такі як Jolt, zkllvm, spartan 2, Binius, - це проекти, які ми відстежуємо, разом із компаніями, які працюють у просторі Повністю Гомоморфного Шифрування (FHE), якщо ви не знаєте, що це таке, слідкуйте, оскільки ми обов'язково розглянемо це в певний момент.

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

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

Увага:

1. Ця стаття публікується з [ Анаграма], Усі авторські права належать оригінальному авторові [austbot]. Якщо є заперечення до цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.

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

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