Демистифицируем ZEXE

ZEXE — это система на основе реестра, которая позволяет запускать несколько приложений в одном реестре таким образом, что транзакции не раскрывают никакой информации о конкретных выполняемых вычислениях.

Введение

ZEXE — это система на основе реестра, которая позволяет пользователям выполнять произвольные вычисления в автономном режиме и создавать транзакции, которые подтверждают правильность этих вычислений посредством использования доказательств с нулевым разглашением. Подход ZEXE направлен на достижение не только конфиденциальности данных (сокрытие всех пользовательских данных), но и конфиденциальности функций, что означает невозможность (наблюдателя), чтобы отличать функции, выполняемые в автономном режиме, друг от друга. Частные офлайн-вычисления могут представлять собой переходы состояний различных приложений (например, токенов, рынков, выборов и т. д.), все из которых выполняются поверх одного и того же реестра.

От Zerocoin до Zerocash и далее

Zerocoin

Одним из способов улучшить свойства анонимности криптовалюты является использование микшера, который запутывает историю транзакций пользователя. . Для смешивания пользователи отправляют свои монеты посреднику и получают разные монеты, внесенные другими пользователями. Zerocoin был разработан как децентрализованный миксер для биткойнов. С помощью серии бирж, таких как биткойн → Zerocoin → биткойн, пользователь заменяет старые монеты таким же количеством новых, которые нельзя привязать к монетам, отправленным в микс. Свойство несвязываемости достигается за счет использования доказательств с нулевым разглашением и схем обязательств.

Биткойн → Zerocoin

Чтобы чеканить зерокоин из биткойна, вы генерируете серийный номер. $s n$ (который однозначно идентифицирует монету), создайте обязательство $COM M_{р} (s n)$ с использованием некоторой случайности $р$ и отправьте коммитирующую транзакцию в реестр.

Zerocoin → биткойн

Чтобы выкупить монету, вам нужно доказать с нулевым разглашением, что вы знаете ее стоимость. $р$ такой, что $COM M_{р} (s n)$ существует в реестре. Вы помещаете доказательство в транзакцию вместе с серийным номером. $s n$ и отправить его в реестр. С $р$ скрыто под доказательством с нулевым разглашением, невозможно узнать, какая из зафиксированных монет была погашена, и, как следствие, невозможно найти ссылку на исходный биткойн. Издательский $s n$ гарантирует, что ни одна монета не будет потрачена дважды.

Zerocash

Zerocash — это схема цифровой валюты, которая позволяет осуществлять прямые платежи на любую сумму и основана на Zerocoin. Чтобы создать полноценную платежную систему на основе протокола Zerocoin, Zerocash вводит некоторые функциональные возможности, такие как возможность отправлять монеты от одного пользователя другому или отправлять произвольное количество определенной монеты всего за одну транзакцию. Zerocash обеспечивает надежные гарантии конфиденциальности данных, скрывая стоимость монет и личности пользователей. ZEXE можно рассматривать как обобщение Zerocash, обеспечивающее конфиденциальность данных и функций.

Что такое конфиденциальность функций?

В Zerocash каждая транзакция содержит доказательство с нулевым разглашением, которое доказывает сохранение стоимости в этой транзакции, а именно, что сумма всех потраченных значений монет равна сумме всех созданных значений монет: $\sum_{я} в_{я o l d} "=" \sum_{дж} в_{дж n e w}$ . Если Алиса хочет дать $Икс$ монеты Бобу и Чарли, Боб получает $й$ монеты от Алисы, а Чарли получает $я$ монеты от Алисы, должно быть так $Икс "=" й + я$ . Предикат сохранения значения представляет собой своего рода вычисление стоимости монет. Представьте теперь, что у нас есть два определяемых пользователем актива: $А_{1}$ и $А_{2}$ , которые используют один и тот же реестр для хранения транзакций (например, платформа Ethereum, которая поддерживает множество контрактов, каждый из которых представляет собой отдельную валюту). Даже если бы каждый из них принял протокол, подобный Zerocash, для обеспечения конфиденциальности данных, транзакция все равно показала бы, какой именно токен был обменян. $А_{1}$ или $А_{2}$ или, другими словами, какое вычисление было выполнено. Приватность функции означает невозможность отличить один тип вычислений от другого. В этом случае конфиденциальность функции не сохранится. В Zerocash конфиденциальность функций достигается по тривиальным причинам: наличие только одного типа вычислений, выполняемых в каждой транзакции, означает, что транзакции невозможно различить, глядя на выполненные в них вычисления.

Достижение конфиденциальности функций

Мы хотим, чтобы в одном реестре выполнялось несколько типов вычислений. Но если мы просто начнем выполнять различные вычисления без дополнительных изменений, конфиденциальность функций не сохранится. Чтобы обеспечить конфиденциальность функций для реестра с несколькими функциями транзакций, введен новый криптографический примитив, называемый децентрализованными частными вычислениями (DPC). DPC можно рассматривать как обобщение подхода Zerocash, который делает возможным анонимное выполнение произвольных вычислений над произвольными блоками данных.

От монет к пластинкам

запись — это единица данных с произвольной полезной нагрузкой. Записи — это обобщенное понятие монеты, но вместо хранения целого значения монеты $в$ , запись содержит произвольную полезную нагрузку $п$ <а я=0>. Как и у монет, у записей есть владелец, их можно создавать и потреблять, и каждая транзакция имеет записи в качестве входных и выходных значений (как в модели UTXO). Как и в Zerocash, чтобы создать запись, вы должны отправить обязательство в реестр, и серийный номер записи раскрывается, когда запись используется, в то время как соответствующая случайность скрыта доказательством с нулевым разглашением. Записи могут использоваться для различных видов вычислений. Чтобы добиться конфиденциальности функций при наличии нескольких функций, нам нужен способ сделать эти вычисления неотличимыми друг от друга. Хитрость здесь заключается в том, чтобы использовать универсальную функцию и хранить «реальные» значения. функционирует как полезная нагрузка записи. Тогда все транзакции в системе будут реализовывать только одну функцию, универсальную, а все детали, связанные с реальными функциями, будут скрыты в полезной нагрузке. наноядро записи (РНК) определяет набор правил для вычислений над записями.

Рекордное наноядро (RNK)

Каждая запись имеет полезную нагрузку, предикат рождения $Φ_{б}$ и предикат смерти $Φ_{д}$ . Предикат рождения должен выполняться при создании записи, а предикат смерти должен выполняться при использовании записи. RNK гарантирует соблюдение обоих условий, так что в течение всего срока существования записи соблюдаются определенные ограничения. Предикаты могут видеть содержимое всей транзакции, включая:

- содержимое каждой записи (ее полезная нагрузка, предикаты рождения и смерти и т. д.)

- меморандум о транзакции: общая память, публикуемая в реестре (например, обязательства, серийные номера использованных записей)

- вспомогательный ввод: общая память, которая не публикуется в реестре

На основе входных данных предикаты могут решить, какие виды взаимодействия с записью разрешены, а какие запрещены, что позволяет записям безопасно взаимодействовать друг с другом. Например, запись может решить не взаимодействовать с записями, полезные данные которых не удовлетворяют определенным свойствам, или разрешить взаимодействие только с записями, имеющими определенные типы предикатов рождения или смерти. Транзакция считается действительной только в том случае, если одновременно выполняются предикаты смерти всех использованных записей и предикаты рождения всех созданных записей. Чтобы доказать свою достоверность, каждая транзакция содержит доказательство с нулевым разглашением, которое подтверждает выполнение этих предикатов. Для достижения эффективности используется один уровень рекурсивной композиции доказательства. Это означает, что на самом деле имеется два доказательства: внутреннее доказывает, что предикаты выполняются в соответствии с запросом, а внешнее доказывает, что внутреннее доказательство действительно. Внутреннее доказательство можно вычислить в автономном режиме, а внешнее доказательство гарантирует, что оно вычислено правильно. И внутренние, и внешние доказательства кратки, а это значит, что их проверка обходится дешево. Внешнее доказательство должно быть с нулевым разглашением, и поэтому внутреннее доказательство не обязательно.

Записи в деталях

Каждая запись имеет свой собственный открытый ключ адреса. $a p k$ который указывает владельца записи. Как и в Zerocash, для создания записи необходимо создать обязательство. $c m$ к данным, содержащимся в записи, и для использования записи необходимо указать ее серийный номер $s n$ , который невозможно вычислить без секретного ключа адреса $a s k$ что соответствует $a p k$ . Это означает, что только тот человек, который имеет $a s k$ может использовать запись. Секретный ключ адреса $a s k "=" (s k_{ПРФ}, р_{p k})$ состоит из секретного ключа PRF $s k_{ПРФ}$ и случайность обязательств $р_{p k}$ . Открытый ключ адреса $a p k "=" COM M_{р p k} (s k_{ПРФ})$ это прекрасно скрываемая приверженность $s k_{ПРФ}$ со случайностью $р_{p k}$ . Ключ $s k_{ПРФ}$ используется для вычисления серийного номера записи: $s n "=" PR F_{s k ПРФ} (ρ)$ , где $ρ$ — это серийный номер nonce, который также хранится в записи. Подводя итог, запись содержит:

- адрес открытого ключа $a p k "=" COM M_{р p k} (s k_{ПРФ})$

- предикат рождения $Φ_{б}$

- предикат смерти $Φ_{д}$

- полезная нагрузка данных

- серийный номер nonce $ρ$

- обязательство $c m$ ко всему вышеперечисленному

Фиктивные записи

Фиктивные записи — это функция, пришедшая из старых протоколов, где количество входов и выходов было постоянным для каждой транзакции. В ZEXE можно свободно создавать фиктивные записи, но их использование требует удовлетворения их предиката смерти. Данные, хранящиеся в фиктивных записях, не проверяются и нигде не используются. Приятной особенностью фиктивных записей является то, что они скрывают реальное количество входов и выходов транзакции, поскольку не существует механизма, позволяющего отличить фиктивные записи от нефиктивных записей. Пользователь может знать только верхнюю границу количества нефиктивных записей, созданных/потребленных в транзакции. Фиктивные записи также могут быть полезны для реализации некоторой логики в предикатах.

Делегируемый DPC

Чтобы гарантировать выполнение предикатов рождения и смерти, пользователь должен предоставить соответствующее доказательство с нулевым разглашением, что является проблемой для пользователей слабых устройств (например, мобильных телефонов). Схема делегируемого ЦОД призвана решить эту проблему. Схема делегируемого DPC позволяет пользователю делегировать создание доказательства работнику, а затем включать его в транзакцию. Основная идея состоит в том, чтобы разделить секретный ключ $a s k$ , чтобы часть, необходимая для создания криптографического доказательства, была отделена от части, необходимой для авторизации транзакции, затем передайте работнику первую часть и оставьте вторую часть скрытой. Таким образом, исполнитель может только предоставить доказательство, но не может использовать его для создания транзакции, поскольку у него нет доступа к оставшейся части секретного ключа. Для этого используются случайные подписи. Рандомизируемые подписи позволяют рандомизировать открытые ключи и подписи, чтобы предотвратить связывание нескольких подписей. Каждому пользователю предоставляется пара ключей подписи $p k_{S I G}, s k_{S I G}$ , где $p k_{S I G}$ встроен в $a p k$ , и $s k_{S I G}$ используется только для авторизации транзакции. Теперь пользователь отправляет данные, необходимые для доказательства (включая секретный ключ). $s k_{ПРФ}$ ) работнику подписывает предъявленное доказательство секретным ключом $s k_{S I G}$ , рандомизирует полученную подпись и включает ее в итоговую транзакцию. Поскольку работник не знает ключ подписи $s k_{S I G}$ , невозможно произвести действительную транзакцию.

Случайные подписи

Идея схем рандомизируемой подписи заключается в том, что каждый раз, когда мы вычисляем подпись сообщения, мы обновляем как открытый ключ, так и подпись, чтобы рандомизированный открытый ключ можно было использовать для проверки рандомизированной подписи, но значение обоих отличается от значения предыдущие. Например, рассмотрим схему подписи Шнорра. Предположим, у нас есть пара ключей для подписи. $(p k "=" г^{Икс}, s k "=" x)$ и подпись вычисляется как $σ "=" (s "=" к - x e, е "=" H (g^{к} ∣∣ m))$ , где $к$ это некоторый случайный скаляр. Мы можем рандомизировать открытый ключ и подпись, используя случайное значение. $р_{S I G}$ (в случае ZEXE, $р_{S I G} "=" PR F_{s k ПРФ} (ρ)$ ) как таковой: $пк^"="пк∗грСяг$ $�^"="(с−е∗рСяг,е)$ Неофициально, имея подпись $(s, e)$ и открытый ключ $p k_{S I G}$ , алгоритм проверки подписи выглядит так:

- вычислить $р_{в} "=" г^{с} p k_{S I G е}$

- вычислить $е_{в} "=" H (r_{в} ∣∣ m)$

- проверить, если $е == е_{в}$

Если у нас есть рандомизированная подпись $�^"="(с^,е)$ и соответствующий рандомизированный открытый ключ $пк^Сяг$ случайность открытого ключа отменяет случайность подписи: $р^в"="гс^∗пк^Сяге"="гс−е∗рСяг∗гИксе+е∗рСяг"="гс+Иксе"="гс∗пкСяге"="рв$ Обратите внимание, что подпись и открытый ключ должны быть рандомизированы с одинаковым значением. $р_{S I G}$ чтобы соответствовать.

Схема делегируемого DPC позволяет создавать пороговые и слепые транзакции. Транзакция называется пороговой, если существуют $н > 1$ стороны, владеющие долей ключа авторизации $s k_{S I G}$ и любой $т$ из них достаточно для подписания транзакции. Поскольку рандомизация происходит после создания ключа и подписи, достаточно использовать существующие протоколы пороговой или слепой подписи, а затем рандомизировать ее. Чтобы создать пороговую транзакцию с использованием делегируемой схемы DPC, необходимо использовать схему подписи, которая позволяет генерировать пороговый ключ и алгоритмы пороговой подписи. Для создания слепой транзакции необходимо использовать схему подписи, имеющую алгоритм слепой подписи.

Вариант использования 1: определяемые пользователем активы

В заключение давайте рассмотрим некоторые варианты использования ZEXE. Чтобы создать собственную систему поверх DPC, нам необходимо определить правила для этой системы. Для этого мы определяем предикаты рождения и смерти и описываем ожидаемое содержимое полезных данных записи. Итак, система определяется содержанием записей. Сначала мы рассматриваем формат транзакции, в котором имеется ровно две входные и две выходные записи. Для записи, представляющей монету пользовательского актива, мы создаем предикат рождения, который называется Mint-or-Conserve. Он называется так потому, что может работать в двух режимах: режиме монетного двора и режиме сохранения. В режиме монетного двора предикат рождения создает первоначальный запас $в$ актива и уникальный идентификатор актива $i d$ . Полезная нагрузка выходной записи происхождения: $(i d, v, в "=" v)$ где $в$ это значение записи. Уникальный идентификатор актива $i d$ получается из серийных номеров использованных входных записей: $i d "=" COM M_{р} (s n_{1} ∣∣ s n_{2})$ . Поскольку серийные номера являются уникальными значениями, свойство привязки гарантирует, что значение $i d$ также уникален. В режиме сохранения MoC проверяет, что для всех записей в этой транзакции с одним и тем же MoC и одним и тем же идентификатором актива значение сохраняется (как и в Zerocash, сумма значений входных записей равна сумме значений выходных записей). Итак, если Алиса хочет отправить некоторые токены Бобу, Алиса создает транзакцию с входной записью для использования, фиктивной входной записью и двумя выходными записями: первая принадлежит Бобу, а вторая принадлежит Алисе. и представляет собой оставшиеся токены.

Вариант использования 2: частные DEX

Теперь, когда мы можем создавать пользовательские активы, как нам их обменивать? Мы будем использовать децентрализованную биржу (DEX), приложение на основе реестра, которое позволяет торговать цифровыми активами. Чтобы реализовать частный DEX, в дополнение к предикату рождения MoC мы определяем предикат смерти «обмен или отмена» (EoC). Вызванный в режиме обмена, EoC позволяет использовать запись путем обмена ее на некоторые единицы другого актива. $А_{2}$ . В режиме отмены EoC позволяет отменить обмен, отправив токены на указанный адрес. $a p k$ (обратно к владельцу).

DEX на основе намерений

В основанных на намерениях DEX имеется индексная таблица, в которой производители публикуют свои намерения торговать (например, 5 единиц актива $А_{1}$ за 10 единиц актива $А_{2}$ ). Заинтересованный получатель T может связаться с производителем M, согласовать условия и совершить транзакцию. 1. М публикует намерение продать 5 единиц $А_{1}$ за 10 единиц $А_{2}$ 2. T связывается с M для согласования условий торговли, создает запись с 10 единицами $А_{2}$ и предикат смерти EoC, который указывает, что запись может быть потрачена только в случае обмена на 5 единиц $А_{1}$ и отправляет ее M со всей информацией, необходимой для выкупа записи 3. Теперь M может создать транзакцию обмена с предикатом EoC в режиме обмена или отменить обмен с предикатом EoC в режиме отмены. Поскольку предикаты и полезная нагрузка записей скрыты под доказательством с нулевым разглашением, никакая частная информация не раскрывается. Обратите внимание, что M не обязательно сразу создавать транзакцию, и до момента фактического обмена цены токенов могут измениться (например, 5 единиц $А_{1}$ были эквивалентны 10 единицам $А_{2}$ когда Т создал запись, но позже 5 единиц $А_{1}$ были эквивалентны всего 5 единицам $А_{2}$ ), поэтому обмен становится более выгодным для одной из сторон и, наоборот, менее выгодным для другой.

DEX на основе заказов

В на основе заказов DEX производители публикуют записи вместе с информацией, необходимой для их авансового погашения, в книге заказов. На DEX с открытой книгой тейкер выбирает ордер из книги заказов, а на с закрытой книгойс открытой книгой. a> DEX берущий сопоставляется с дающим вне цепочки с помощью оператора книги ордеров.

DEX с открытой книгой

1. Если М желает обменять 5 единиц $А_{1}$ за 10 единиц $А_{2}$ , она создает запись с 5 единицами $А_{1}$ , предикат смерти EoC, который указывает, что запись может быть потрачена только в случае обмена на 10 единиц $А_{2}$ и публикует его в книге заказов вместе с информацией, необходимой для погашения записи.

2. T может создать транзакцию обмена с предикатом смерти EoC в режиме обмена или отменить обмен с предикатом EoC в режиме отмены. Поскольку предикаты и полезная нагрузка записей скрыты под доказательством с нулевым разглашением, никакая частная информация не раскрывается, но поскольку транзакция раскрывает серийный номер записи, ее можно связать с заказом (серийный номер является частью данных, необходимых для выкупа записи), которая раскрывает обмениваемые активы и суммы.

DEX с закрытой книгой

1. Если М желает обменять 5 единиц $А_{1}$ за 10 единиц $А_{2}$ , она создает запись с 5 единицами $А_{1}$ , предикат смерти EoC, который указывает, что запись может быть потрачена только в случае обмена на 10 единиц $А_{2}$ и отправляет его в книгу заказов вместе с информацией, необходимой для погашения записи.

2. Теперь T публикует запись с 10 единицами $А_{2}$ и предикат смерти EoC, который указывает, что запись может быть потрачена только в случае обмена на 5 единиц $А_{1}$ и отправляет его в книгу заказов вместе с информацией, необходимой для погашения записи.

3. Оператор книги заказов создает транзакцию, которая использует соответствующие записи. Поскольку заказы не публикуются, суммы и активы раскрываются только оператору книги заказов.

Последние мысли

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

Написано Юлией Халниязовой, исследователем криптографии с нулевым разглашением и amp; разработчик протокола в Heliax, команде Anoma.

Если вы заинтересованы в криптографии с нулевым разглашением, передовых криптографических протоколах или инженерных позициях в Rust, ознакомьтесь открытыми вакансиями в Heliax .

Tags: Anoma