На саміті ETHShanghai 2023 засновник Axiom І Сун представив ZK-співпроцесор Ethereum Axiom і його важливість з точки зору доступу до даних і обчислювальної потужності. Axiom реалізує розширення доступу до даних і обчислення за допомогою концепції операції відображення, а також реалізує валідність запиту шляхом перевірки хеш-ланцюга та підтримки кешу. Програми для Axiom включають дорогі програми, більший доступ до даних, програми на основі протоколів керування історичними даними тощо. Завдяки Axiom смарт-контракти можуть отримувати більше даних і обчислювальної потужності, сприяючи подальшому розвитку додатків Ethereum.
Наступний текст є китайським перекладом виступу І Суня, а посилання є відео в прямому ефірі:
По-перше, давайте розберемося, як користувач фактично отримує доступ до інформації Ethereum. Коли ми вперше використовували Ethereum, фактично отримували інформацію про те, що відбувається в ланцюжку, через виклики JSON-RPC для архівування анотацій. Метою JSON-RPC API є надання користувачеві інформації про історію в мережі. По суті, уся інформація, яку ми бачимо про блокчейн, витягується з цих викликів API і представляється як запис на веб-сайті для читання користувачем.
Зараз, коли користувачі стають більш вправними у взаємодії з блокчейном, ми починаємо вимагати дедалі складніших представлень ланцюга. Тому для різних користувачів розробляються різні типи вузлів архівування. Отже, були Гет, Ерігон, Нетермінд і тепер Рет. Ми можемо вибрати найбільш підходящий архівний вузол відповідно до власних потреб.
Якщо користувачів не влаштовує окремий API JSON-RPC, можна вибрати індексатор для застосування постобробки під час відстеження транзакцій. Для різних програм користувачам можуть бути цікаві дані, отримані від The Graph або Covalent.
Нещодавно також з’явилися гаманці та інші продукти, які пропонують симуляцію транзакцій поверх вузлів архіву. Це означає, що ми можемо побачити фактичний результат віртуальної транзакції до її здійснення. Загалом, як кінцеві користувачі, спосіб взаємодії з Ethereum стає все більш витонченим, використовуючи більше обчислень на додаток до даних, які ми читаємо.
Тепер, якщо ми думаємо про це не з точки зору користувача, а з точки зору смарт-контракту на Ethereum. Звичайно, контракти також хочуть мати доступ до даних і виконувати з ними обчислення, але це складніше. Насправді, якщо ми зайдемо на OpenSea і подивимося на список CryptoPunk, то побачимо, що з усієї інформації на сторінці лише невелика частина доступна в смарт-контракті в ланцюжку.
Фактично, для списків CryptoPunk ця інформація стосується лише поточних власників. Звичайно, на сторінці є багато іншої інформації, але вся інформація, пов’язана з історичною інформацією про перекази, історичними цінами та історичними власниками, фактично недоступна для смарт-контракту, оскільки вона належить до минулої історії. Ці історії становлять інформацію в ланцюжку, але вони недоступні для смарт-контрактів, тому що нам потрібно уникати примусу кожного повного вузла Ethereum зберігати цю інформацію у своєму довільному доступі для перевірки транзакцій.
Крім того, як може сказати вам будь-який розробник блокчейну, виконання обчислень у ланцюжку є непомірно дорогим, хоча Ethereum має відносно ефективні операції віртуальної машини (VM), а попередня компіляція здешевлює певні типи операцій. Наприклад, Ethereum забезпечує відносно дешеву підтримку операцій з еліптичною кривою на кривій BN254. Однак для деяких конкретних програм віртуальна машина Ethereum все ще є дуже дорогим середовищем виконання. При розробці віртуальної машини блокчейну необхідно вибрати невід'ємний набір операцій, які необхідно ретельно вимірювати, щоб гарантувати, що кожен вузол може перевіряти транзакції в узгоджений час. Крім того, необхідно також враховувати безпеку в найгіршому випадку та стабільність консенсусу. Таким чином, проблема полягає в тому, як реалізувати масштабування конкретної програми для додатків у мережі. Axiom спрямована на розширення доступу до даних і обчислювальних можливостей для смарт-контрактів, щоб задовольнити потреби розширення різних програм.
Axiom створює те, що вона називає співпроцесором Ethereum (ZK Coprocessor), який дозволяє певним смарт-контрактам безнадійно делегувати в нашу оф-чейн систему, щоб вони могли делегувати читання даних і перевірені обчислення Axiom. Щоб надіслати запит до Axiom, смарт-контракт може надіслати транзакцію в нашу мережеву систему. Наш офлайн-вузол отримає транзакцію та згенерує результат на основі історичних запитів Ethereum, а також додасть підтвердження нульового знання, щоб підтвердити правильність результату. Нарешті, ми перевіряємо результати в ланцюжку та достовірно доставляємо результати до смарт-контрактів.
Це подібно до того, як центральний процесор комп’ютера делегує обчислення графічному процесору та повертає результати, коли вони відомі. На початку ця концепція називалася співпроцесором (Coprocesso). На слайді я показую зображення просунутого математичного копроцесора початку 1990-х років, аналогічного тому, що робить Axiom.
Ми можемо зрозуміти, які типи операцій може виконувати Axiom. Кожен запит до Axiom можна розбити на три частини.
Перша — це частина читання, яка полягає в тому, як вводяться запити Axiom — ми можемо надійно читати історичні дані в ланцюжку.
Друга частина полягає в тому, що ми можемо виконувати обчислення перевірки цих даних. Це може починатися від базового аналізу, як-от підсумовування деяких чисел, знаходження максимуму чи мінімуму, до більш складних обчислень. Наприклад, деяке агрегування підписів або перевірка за допомогою криптографії та навіть машинне навчання на основі нульових знань, як-от перевірка роботи певних алгоритмів репутації соціальних даних у ланцюжку або використання певних алгоритмів машинного навчання у фінансових програмах. Зрештою, ми надамо програмовані обчислювальні композиційні функції через віртуальні машини.
Остання частина, після кроків читання та обчислення, ми отримуємо результат і завжди поєднуємо цей результат із доказом нульового знання того, що обчислення результату було дійсним. Тому ми перевіряємо цей доказ у смарт-контракті Ethereum, а потім зберігаємо результат для використання в контракті.
Оскільки всі результати, які повертає Axiom, фактично перевіряються доказами з нульовим знанням, це означає, що безпека всього, що повертає Axiom, криптографічно еквівалентна безпеці самого Ethereum. Філософія Axiom полягає в тому, що ми не хочемо нав’язувати користувачам жодних додаткових припущень, крім криптографічних припущень, які вони вже мають, використовуючи Ethereum.
Далі я детально познайомлю принцип її реалізації, який включає поняття операції Reflection, згадане в назві виступу. Основний принцип, який робить усе це можливим, полягає в тому, що кожен блок у блокчейні містить повну історію. Ми можемо почати з поточного блоку Ethereum і повернутися до попередніх блоків, які нас цікавлять. Беручи всі заголовки блоків між минулим блоком і поточним блоком і перевіряючи хеш-ланцюжок цих заголовків блоків, ми можемо фактично повернути зобов’язання минулого блоку на поточний блок.
Отже, які переваги Reflection?
Ми можемо взяти блок поточного Ethereum і повернутися до попереднього блоку, який нас цікавить. Якщо ми отримуємо заголовки блоків між минулим блоком і поточним блоком, ми можемо повернути зобов’язання минулого блоку в поточний блок, перевіривши хеш-шлях між цими заголовками блоків. Потім, якщо нас цікавить якась інформація з минулого блоку, ми можемо надати доказ включення в зобов’язання цього блоку. Зокрема, це може бути доказ Merkle Patricia Trie того, що інформація існує в trie стану блоку, trie транзакції чи trie квитанції. У EVM, принаймні в принципі, будь-яка минула інформація в ланцюжку може бути доступна лише через знання останніх хешів блоків.
На жаль, робити це в EVM дорого. Як щойно згадувалося, вам потрібно перевірити хеш-ланцюжки та докази Merkle усіх заголовків блоків, що включає багато хеш-обчислень Keccak для великої кількості даних. Тож як тільки ви повертаєтеся в минуле, це стає дуже важко. Тому ми застосовуємо операцію Reflection, обернувши це доказ за допомогою ZK у EVM. Тож замість того, щоб поміщати всі минулі заголовки блоків і всі ці докази Merkle у ланцюжок, а потім перевіряти їх, ми перевіряємо з нульовим знанням, чи існує послідовність минулих заголовків блоків і деякі докази перевірки.
Це має дві переваги. По-перше, це позбавляє нас від необхідності вводити доказові дані в дані викликів. По-друге, це дозволяє агрегувати докази, що неможливо уявити без використання ЗК. Ідея полягає в тому, що під час перевірки будь-якої кількості обчислень на Ethereum вартість газу є фіксованою, тому ми можемо використовувати єдине доказ ZK для перевірки доступу до великої кількості історичних даних.
Дозвольте мені коротко торкнутися компромісів концепції роботи Reflection на основі ZK.
Є два способи доступу до даних. По-перше, ви знаєте про це раніше: ви можете отримати доступ до даних Ethereum безпосередньо зі смарт-контракту. Це має велику перевагу, оскільки доступ є синхронним. Тому ви можете безпосередньо викликати функцію читання в смарт-контракті, щоб отримати поточне значення. Наприклад, коли ви торгуєте на Uniswap, вам потрібна ця синхронність. Однак він також має багато обмежень. Ваша обчислювальна потужність обмежена вартістю палива, і ви не маєте доступу до жодних історичних даних.
По-друге, якщо ви хочете скористатися можливістю ZK відображати в Ethereum, оскільки вам потрібно створити докази того, що ваш доступ правильний, немає способу зробити це синхронно. Тож фактично немає прямого доступу до поточного стану в ланцюжку, тому що ви повинні підтвердити стан.
З іншого боку, якщо ви дозволите собі асинхронний доступ до історичних даних, ви можете застосовувати до них майже необмежену кількість обчислень і мати доступ до величезних обсягів даних. Тому, пом’якшивши концепцію синхронізації, доступ до оперативних даних Reflection на основі ZK можна значно розширити.
Потім ми розглянемо, як реалізувати операції Reflection через Axiom.
По-перше, ми фактично повинні підтримувати кеш усіх попередніх блоків у нашому смарт-контракті. У EVM останні 256 хешів блоків доступні нативно. Ми можемо довести, що в кожній партії з 1024 блоків хеш останнього блоку попередньої партії фіксується в наступному блоці. Подібним чином, хеш передостаннього блоку в попередньому пакеті фіксується в останньому блоці і так далі. Таким чином, ми можемо зворотно перевірити цей хеш-ланцюжок і довести дійсність цього хеш-ланцюжка через нульове знання.
Це дозволяє нам кешувати хеші блоків, починаючи з останнього блоку аж до блоку генезису. Насправді ми реалізували це в нашому розумному контракті основної мережі, який містить кешовані шляхи Merkle кожні 1024 хеші блоку з блоку genesis.
Ще одна особливість, яку ми додаємо, — гірський хребет Меркле. Він побудований на основі цього хеш-кешу блоків, структури даних, яка дозволяє посилатися на кожен хеш блоку в Ethereum в обмеженій ДНК.
Після створення кешу ми можемо запитувати Axiom, перевіряючи блоки в кеші. Щоб це спрацювало, ми маємо довести, що кожна частина даних в історії Ethereum, до якої ми намагаємося отримати доступ, насправді міститься в кеші певного блоку. По-друге, ми маємо довести, що всі обчислення, які ми виконуємо за цим запитом, правильні. Щоб перевірити це в ланцюжку, ми перевіряємо дійсність доказу нульового знання. Ми також перевіряємо, чи вона співвідноситься з інформацією, яку ми записали в мережі. Ми завжди довіряємо нашим кеш-пам’ятам або кеш-пам’ятам блоків і зіставляємо інформацію в цих кеш-пам’ятах блоків із загальнодоступною інформацією в доказах нульового знання.
Тепер давайте поговоримо про можливі застосування передбачуваної операції Reflection.
Горизонтальна вісь представляє складність даних, скільки даних насправді потрібно отримати для реалізації програми. Вертикальна вісь відображає обчислювальну складність, яка означає, скільки обчислювальних ресурсів насправді потрібно застосувати для виконання завдання.
Таким чином, перший тип програми – це програма, яку Axiom або будь-який тип механізму роботи Reflection можна реалізувати на Ethereum, але вартість дещо вища.
Деякі приклади цього включають зчитування нонсів консенсусного рівня із заголовків блоків на рівні консенсусу Ethereum, перевірку історичного віку облікового запису або зчитування різних типів даних оракула з історичної інформації про ціни. У EVM можна використовувати різні рішення для реалізації цих програм, але, помістивши ці рішення в нульові знання, ефективність можна підвищити.
Тепер існує ще один клас програм, які зазвичай потребують більшого доступу до даних і, отже, більше обчислень. На мій погляд, ці програми були б неможливі без використання співпроцесора ZK.
Як приклад, цікавим додатком є можливість зведення на Ethereum зчитувати стан базового рівня або іншого зведеного довіреним способом, використовуючи для взаємодії нульові знання. Однією з таких програм може бути дозвіл Roll-ups зчитувати знімки повного балансу токенів ERC20.
Якщо ми переведемо нашу увагу зі зберігання на історію транзакцій облікових записів, ви можете уявити собі створення довіреної репутації, ідентичності або кредитної системи рейтингу, записуючи повну історію адрес Ethereum. Це може бути використано для оцінки кредитоспроможності або для надання вам доступу до певного типу DAO у ланцюзі, або для надання вам доступу до випуску спеціальних NFT.
Існує також клас програм, які використовують історичні дані в ланцюжку для фактичного керування протоколом. Загальновідомий як облік угод.
Ідея полягає в тому, що протоколи існують для координації поведінки учасників, а основним принципом координації є можливість винагороджувати або карати учасників за їх поведінку. Якщо ви подивитеся на багато протоколів на Ethereum, запис дій учасників фактично повністю зберігається в ланцюжку. Отже, за допомогою Axiom ми можемо уявити, що на основі повного набору дій учасників протоколу протокол може визначати структуру платежів або навіть накладати певний тип штрафу на учасників, що, на нашу думку, може справді розширити простір протоколу. програми.
Нарешті, якщо ми дійсно підвищимо рівень обчислень, ми вважаємо, що було б дуже цікаво використовувати моделі машинного навчання для налаштування параметрів у мережі. Якщо ви подумаєте про традиційні фінансові програми, дуже поширеним є моделювання складних майбутніх параметрів на основі великих обсягів історичних даних, таких як дані про ціни, економічні дані тощо. І коли ми дивимося на поточний DeFi, він далекий від досягнення цього рівня. Я не думаю, що DeFi має працювати так само, як традиційні фінанси, але ми вважаємо, що впровадження деяких історичних баз даних і моделей і інформації на основі машинного навчання може допомогти створити більш динамічний протокол DeFi.
Це лише кілька ідей щодо того, що операції Reflection можуть привнести в блокчейн.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Демонтаж технічних переваг співпроцесора Ethereum ZK Axiom
По-перше, давайте розберемося, як користувач фактично отримує доступ до інформації Ethereum. Коли ми вперше використовували Ethereum, фактично отримували інформацію про те, що відбувається в ланцюжку, через виклики JSON-RPC для архівування анотацій. Метою JSON-RPC API є надання користувачеві інформації про історію в мережі. По суті, уся інформація, яку ми бачимо про блокчейн, витягується з цих викликів API і представляється як запис на веб-сайті для читання користувачем.
Зараз, коли користувачі стають більш вправними у взаємодії з блокчейном, ми починаємо вимагати дедалі складніших представлень ланцюга. Тому для різних користувачів розробляються різні типи вузлів архівування. Отже, були Гет, Ерігон, Нетермінд і тепер Рет. Ми можемо вибрати найбільш підходящий архівний вузол відповідно до власних потреб.
Якщо користувачів не влаштовує окремий API JSON-RPC, можна вибрати індексатор для застосування постобробки під час відстеження транзакцій. Для різних програм користувачам можуть бути цікаві дані, отримані від The Graph або Covalent.
Нещодавно також з’явилися гаманці та інші продукти, які пропонують симуляцію транзакцій поверх вузлів архіву. Це означає, що ми можемо побачити фактичний результат віртуальної транзакції до її здійснення. Загалом, як кінцеві користувачі, спосіб взаємодії з Ethereum стає все більш витонченим, використовуючи більше обчислень на додаток до даних, які ми читаємо.
Тепер, якщо ми думаємо про це не з точки зору користувача, а з точки зору смарт-контракту на Ethereum. Звичайно, контракти також хочуть мати доступ до даних і виконувати з ними обчислення, але це складніше. Насправді, якщо ми зайдемо на OpenSea і подивимося на список CryptoPunk, то побачимо, що з усієї інформації на сторінці лише невелика частина доступна в смарт-контракті в ланцюжку.
Фактично, для списків CryptoPunk ця інформація стосується лише поточних власників. Звичайно, на сторінці є багато іншої інформації, але вся інформація, пов’язана з історичною інформацією про перекази, історичними цінами та історичними власниками, фактично недоступна для смарт-контракту, оскільки вона належить до минулої історії. Ці історії становлять інформацію в ланцюжку, але вони недоступні для смарт-контрактів, тому що нам потрібно уникати примусу кожного повного вузла Ethereum зберігати цю інформацію у своєму довільному доступі для перевірки транзакцій.
Крім того, як може сказати вам будь-який розробник блокчейну, виконання обчислень у ланцюжку є непомірно дорогим, хоча Ethereum має відносно ефективні операції віртуальної машини (VM), а попередня компіляція здешевлює певні типи операцій. Наприклад, Ethereum забезпечує відносно дешеву підтримку операцій з еліптичною кривою на кривій BN254. Однак для деяких конкретних програм віртуальна машина Ethereum все ще є дуже дорогим середовищем виконання. При розробці віртуальної машини блокчейну необхідно вибрати невід'ємний набір операцій, які необхідно ретельно вимірювати, щоб гарантувати, що кожен вузол може перевіряти транзакції в узгоджений час. Крім того, необхідно також враховувати безпеку в найгіршому випадку та стабільність консенсусу. Таким чином, проблема полягає в тому, як реалізувати масштабування конкретної програми для додатків у мережі. Axiom спрямована на розширення доступу до даних і обчислювальних можливостей для смарт-контрактів, щоб задовольнити потреби розширення різних програм.
Axiom створює те, що вона називає співпроцесором Ethereum (ZK Coprocessor), який дозволяє певним смарт-контрактам безнадійно делегувати в нашу оф-чейн систему, щоб вони могли делегувати читання даних і перевірені обчислення Axiom. Щоб надіслати запит до Axiom, смарт-контракт може надіслати транзакцію в нашу мережеву систему. Наш офлайн-вузол отримає транзакцію та згенерує результат на основі історичних запитів Ethereum, а також додасть підтвердження нульового знання, щоб підтвердити правильність результату. Нарешті, ми перевіряємо результати в ланцюжку та достовірно доставляємо результати до смарт-контрактів.
Це подібно до того, як центральний процесор комп’ютера делегує обчислення графічному процесору та повертає результати, коли вони відомі. На початку ця концепція називалася співпроцесором (Coprocesso). На слайді я показую зображення просунутого математичного копроцесора початку 1990-х років, аналогічного тому, що робить Axiom.
Ми можемо зрозуміти, які типи операцій може виконувати Axiom. Кожен запит до Axiom можна розбити на три частини.
Перша — це частина читання, яка полягає в тому, як вводяться запити Axiom — ми можемо надійно читати історичні дані в ланцюжку.
Друга частина полягає в тому, що ми можемо виконувати обчислення перевірки цих даних. Це може починатися від базового аналізу, як-от підсумовування деяких чисел, знаходження максимуму чи мінімуму, до більш складних обчислень. Наприклад, деяке агрегування підписів або перевірка за допомогою криптографії та навіть машинне навчання на основі нульових знань, як-от перевірка роботи певних алгоритмів репутації соціальних даних у ланцюжку або використання певних алгоритмів машинного навчання у фінансових програмах. Зрештою, ми надамо програмовані обчислювальні композиційні функції через віртуальні машини.
Остання частина, після кроків читання та обчислення, ми отримуємо результат і завжди поєднуємо цей результат із доказом нульового знання того, що обчислення результату було дійсним. Тому ми перевіряємо цей доказ у смарт-контракті Ethereum, а потім зберігаємо результат для використання в контракті.
Оскільки всі результати, які повертає Axiom, фактично перевіряються доказами з нульовим знанням, це означає, що безпека всього, що повертає Axiom, криптографічно еквівалентна безпеці самого Ethereum. Філософія Axiom полягає в тому, що ми не хочемо нав’язувати користувачам жодних додаткових припущень, крім криптографічних припущень, які вони вже мають, використовуючи Ethereum.
Далі я детально познайомлю принцип її реалізації, який включає поняття операції Reflection, згадане в назві виступу. Основний принцип, який робить усе це можливим, полягає в тому, що кожен блок у блокчейні містить повну історію. Ми можемо почати з поточного блоку Ethereum і повернутися до попередніх блоків, які нас цікавлять. Беручи всі заголовки блоків між минулим блоком і поточним блоком і перевіряючи хеш-ланцюжок цих заголовків блоків, ми можемо фактично повернути зобов’язання минулого блоку на поточний блок.
Отже, які переваги Reflection?
Ми можемо взяти блок поточного Ethereum і повернутися до попереднього блоку, який нас цікавить. Якщо ми отримуємо заголовки блоків між минулим блоком і поточним блоком, ми можемо повернути зобов’язання минулого блоку в поточний блок, перевіривши хеш-шлях між цими заголовками блоків. Потім, якщо нас цікавить якась інформація з минулого блоку, ми можемо надати доказ включення в зобов’язання цього блоку. Зокрема, це може бути доказ Merkle Patricia Trie того, що інформація існує в trie стану блоку, trie транзакції чи trie квитанції. У EVM, принаймні в принципі, будь-яка минула інформація в ланцюжку може бути доступна лише через знання останніх хешів блоків.
На жаль, робити це в EVM дорого. Як щойно згадувалося, вам потрібно перевірити хеш-ланцюжки та докази Merkle усіх заголовків блоків, що включає багато хеш-обчислень Keccak для великої кількості даних. Тож як тільки ви повертаєтеся в минуле, це стає дуже важко. Тому ми застосовуємо операцію Reflection, обернувши це доказ за допомогою ZK у EVM. Тож замість того, щоб поміщати всі минулі заголовки блоків і всі ці докази Merkle у ланцюжок, а потім перевіряти їх, ми перевіряємо з нульовим знанням, чи існує послідовність минулих заголовків блоків і деякі докази перевірки.
Це має дві переваги. По-перше, це позбавляє нас від необхідності вводити доказові дані в дані викликів. По-друге, це дозволяє агрегувати докази, що неможливо уявити без використання ЗК. Ідея полягає в тому, що під час перевірки будь-якої кількості обчислень на Ethereum вартість газу є фіксованою, тому ми можемо використовувати єдине доказ ZK для перевірки доступу до великої кількості історичних даних.
Дозвольте мені коротко торкнутися компромісів концепції роботи Reflection на основі ZK.
Є два способи доступу до даних. По-перше, ви знаєте про це раніше: ви можете отримати доступ до даних Ethereum безпосередньо зі смарт-контракту. Це має велику перевагу, оскільки доступ є синхронним. Тому ви можете безпосередньо викликати функцію читання в смарт-контракті, щоб отримати поточне значення. Наприклад, коли ви торгуєте на Uniswap, вам потрібна ця синхронність. Однак він також має багато обмежень. Ваша обчислювальна потужність обмежена вартістю палива, і ви не маєте доступу до жодних історичних даних.
По-друге, якщо ви хочете скористатися можливістю ZK відображати в Ethereum, оскільки вам потрібно створити докази того, що ваш доступ правильний, немає способу зробити це синхронно. Тож фактично немає прямого доступу до поточного стану в ланцюжку, тому що ви повинні підтвердити стан.
З іншого боку, якщо ви дозволите собі асинхронний доступ до історичних даних, ви можете застосовувати до них майже необмежену кількість обчислень і мати доступ до величезних обсягів даних. Тому, пом’якшивши концепцію синхронізації, доступ до оперативних даних Reflection на основі ZK можна значно розширити.
Потім ми розглянемо, як реалізувати операції Reflection через Axiom.
По-перше, ми фактично повинні підтримувати кеш усіх попередніх блоків у нашому смарт-контракті. У EVM останні 256 хешів блоків доступні нативно. Ми можемо довести, що в кожній партії з 1024 блоків хеш останнього блоку попередньої партії фіксується в наступному блоці. Подібним чином, хеш передостаннього блоку в попередньому пакеті фіксується в останньому блоці і так далі. Таким чином, ми можемо зворотно перевірити цей хеш-ланцюжок і довести дійсність цього хеш-ланцюжка через нульове знання.
Це дозволяє нам кешувати хеші блоків, починаючи з останнього блоку аж до блоку генезису. Насправді ми реалізували це в нашому розумному контракті основної мережі, який містить кешовані шляхи Merkle кожні 1024 хеші блоку з блоку genesis.
Ще одна особливість, яку ми додаємо, — гірський хребет Меркле. Він побудований на основі цього хеш-кешу блоків, структури даних, яка дозволяє посилатися на кожен хеш блоку в Ethereum в обмеженій ДНК.
Після створення кешу ми можемо запитувати Axiom, перевіряючи блоки в кеші. Щоб це спрацювало, ми маємо довести, що кожна частина даних в історії Ethereum, до якої ми намагаємося отримати доступ, насправді міститься в кеші певного блоку. По-друге, ми маємо довести, що всі обчислення, які ми виконуємо за цим запитом, правильні. Щоб перевірити це в ланцюжку, ми перевіряємо дійсність доказу нульового знання. Ми також перевіряємо, чи вона співвідноситься з інформацією, яку ми записали в мережі. Ми завжди довіряємо нашим кеш-пам’ятам або кеш-пам’ятам блоків і зіставляємо інформацію в цих кеш-пам’ятах блоків із загальнодоступною інформацією в доказах нульового знання.
Тепер давайте поговоримо про можливі застосування передбачуваної операції Reflection.
Горизонтальна вісь представляє складність даних, скільки даних насправді потрібно отримати для реалізації програми. Вертикальна вісь відображає обчислювальну складність, яка означає, скільки обчислювальних ресурсів насправді потрібно застосувати для виконання завдання.
Таким чином, перший тип програми – це програма, яку Axiom або будь-який тип механізму роботи Reflection можна реалізувати на Ethereum, але вартість дещо вища.
Деякі приклади цього включають зчитування нонсів консенсусного рівня із заголовків блоків на рівні консенсусу Ethereum, перевірку історичного віку облікового запису або зчитування різних типів даних оракула з історичної інформації про ціни. У EVM можна використовувати різні рішення для реалізації цих програм, але, помістивши ці рішення в нульові знання, ефективність можна підвищити.
Тепер існує ще один клас програм, які зазвичай потребують більшого доступу до даних і, отже, більше обчислень. На мій погляд, ці програми були б неможливі без використання співпроцесора ZK.
Як приклад, цікавим додатком є можливість зведення на Ethereum зчитувати стан базового рівня або іншого зведеного довіреним способом, використовуючи для взаємодії нульові знання. Однією з таких програм може бути дозвіл Roll-ups зчитувати знімки повного балансу токенів ERC20.
Якщо ми переведемо нашу увагу зі зберігання на історію транзакцій облікових записів, ви можете уявити собі створення довіреної репутації, ідентичності або кредитної системи рейтингу, записуючи повну історію адрес Ethereum. Це може бути використано для оцінки кредитоспроможності або для надання вам доступу до певного типу DAO у ланцюзі, або для надання вам доступу до випуску спеціальних NFT.
Існує також клас програм, які використовують історичні дані в ланцюжку для фактичного керування протоколом. Загальновідомий як облік угод.
Ідея полягає в тому, що протоколи існують для координації поведінки учасників, а основним принципом координації є можливість винагороджувати або карати учасників за їх поведінку. Якщо ви подивитеся на багато протоколів на Ethereum, запис дій учасників фактично повністю зберігається в ланцюжку. Отже, за допомогою Axiom ми можемо уявити, що на основі повного набору дій учасників протоколу протокол може визначати структуру платежів або навіть накладати певний тип штрафу на учасників, що, на нашу думку, може справді розширити простір протоколу. програми.
Нарешті, якщо ми дійсно підвищимо рівень обчислень, ми вважаємо, що було б дуже цікаво використовувати моделі машинного навчання для налаштування параметрів у мережі. Якщо ви подумаєте про традиційні фінансові програми, дуже поширеним є моделювання складних майбутніх параметрів на основі великих обсягів історичних даних, таких як дані про ціни, економічні дані тощо. І коли ми дивимося на поточний DeFi, він далекий від досягнення цього рівня. Я не думаю, що DeFi має працювати так само, як традиційні фінанси, але ми вважаємо, що впровадження деяких історичних баз даних і моделей і інформації на основі машинного навчання може допомогти створити більш динамічний протокол DeFi.
Це лише кілька ідей щодо того, що операції Reflection можуть привнести в блокчейн.