Делегирование выполнения операций с нулевым разглашением в схеме DPC

В предыдущей статье мы уже рассмотрели DPC-схемы, используемые в Aleo. В этой же статье мы уже рассмотрим Делегирование выполнения операций с нулевым разглашением в этих схемах

Делегирование нулевого разглашения

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

Далее в статье мы рассмотрим, как решить эту проблему, позволяя пользователю делегировать выполнение вычислений для создания транзакции ненадежному исполнителю, например, удаленному серверу. Это позволяет слабым устройствам создавать транзакции, которые они не могли бы создать самостоятельно. Также я объясню, как идеи делегирования транзакций приводят к решениям для достижения пороговых транзакций и скрытых транзакций в схеме DPC, что также ценно в приложениях.

Подход

Суть заключается в том, что пользователь просит исполнителя произвести криптографическое доказательство от его имени, а затем включить это доказательство в транзакцию. Однако этот подход небезопасен, поскольку исполнитель, чтобы создать доказательство, должен узнать не только задачу, но и секретное свидетельство для доказываемого NP-высказывания. Поскольку секретное свидетельство включает секретный ключ адреса пользователя, если исполнитель узнает эту информацию, то он сможет выдать себя за пользователя. Необходимы другие идеи.

Исходя из конструкции схемы DPC, можно предположить, как позволить пользователю делегировать дорогостоящие вычисления доказательств исполнителю таким образом, чтобы исполнитель не мог создать действительные транзакции, которые не были авторизованы пользователем.

Основная идея заключается в том, чтобы изменить ключи адресов так, чтобы секретная информация, необходимая для создания криптографического доказательства, была отделена от секретной информации, необходимой для авторизации транзакции с этим доказательством. Таким образом, пользователь может передать исполнителю секреты, необходимые для создания криптографического доказательства, сохраняя оставшиеся секреты для авторизации этой (и будущих) транзакций. В частности, исполнитель не может создать действительные транзакции, которые не были авторизованы пользователем.

Дополнительный строительный блок: рандомизируемые подписи

Рандомизируемая схема подписи — это набор алгоритмов SIG = (Setup, Keygen, Sign, Verify, RandPk, RandSig), который позволяет стороне подписывать сообщения, а также позволяет рандомизировать публичные ключи и подписи для предотвращения связывания между множественными подписями. Описываются обычные алгоритмы и два алгоритма для рандомизации публичных ключей и подписей. Схема подписи SIG должна удовлетворять следующим требованиям безопасности: существенная неподдельность, невозможность связывания и инъективная рандомизация.

Делегируемая схема DPC

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

Пороговые транзакции и скрытые транзакции

Делегируемую схему DPC можно модифицировать для достижения дополнительных функций: пороговых транзакций или скрытых транзакций.

Пороговые транзакции полезны во многих ситуациях, например, для повышения операционной безопасности за счет реализации двухфакторной аутентификации.

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