## Резюме

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

Первые предложенные расширения для программируемой приватности в Zcash включали в себя оплату за верификацию-ключ (P2VK) [1], экранированные активы Zcash (ZSA) [2] и прозрачные расширения Zcash (TZE) [3]. С тех пор в этом проблемном пространстве наблюдается быстрый прогресс: новые разработки позволяют добиться большего параллелизма и выразительности. Поскольку DeFi продолжает стремительно внедряться в программируемые цепочки, такие как Ethereum, а цепочка Zcash итеративно продвигается к программируемости, разговор о программируемой конфиденциальности становится как никогда актуальным.

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

## Мотивация

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

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

Учитывая дифференциацию Zcash по уровню конфиденциальности, мы являемся сторонниками включения конфиденциальности с самого начала. Этот SoK поможет сообществу Zcash решить, какое направление лучше всего подходит для экосистемы.

## Команда и предыстория

Мы - команда из двух старших криптографов (исследователей и разработчиков), имеющих конкретный опыт проектирования и реализации протоколов конфиденциальности (в Zcash и других экосистемах). В состав команды входят Йинг Тонг (Geometry) и Даниэль Бенаррох (Inversed Tech).

## Область применения и технические детали

В настоящее время усилия по внедрению программируемости в Zcash включают расширение Zcash Shielded Assets (ZSAs) [2], которое обобщает функциональность передачи для работы с определенными пользователем типами активов; и Transparent Zcash Extensions (TZEs) [3], которое позволяет пользователям указывать произвольные предварительные условия на *публичных* данных. Более раннее предложение, pay-to-verification-key (P2VK) [1], позволяло использовать эту возможность для экранированных транзакций путем кодирования предварительного условия в предоставленном пользователем проверочном ключе.

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

1. формально определить соответствующие *параметры*, такие как параллельность, конфиденциальность данных и конфиденциальность функций;
2. проанализировать существующие *классы решений* на основе этих параметров;
3. провести обзор *приложений и случаев использования*, требующих программируемой конфиденциальности; и
4. изучить *совместимость существующих решений* с протоколом Zcash.

Как мы уже говорили, существует несколько способов достижения программируемой конфиденциальности. В данном проекте мы сосредоточимся в основном на протоколах, основанных на модели UTXO, которая является актуальной для цепочки блоков Zcash. Мы подчеркнем различия с моделью баланса счета и ограничения каждой из них, но не будем подробно анализировать протоколы для последней.

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

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

Чтобы проиллюстрировать это, рассмотрим простой пример увеличения счетчика (взято из [этого комментария на GitHub](https://github.com/o1-labs/snarkyjs/issues/265#issuecomment-1177512908)):

транзакция                           zkapp счет после транзакции
{ state: 0, newState:1 } ----------> { state: 1 }
{ state:0, newState: 1 } -----X----> { state:1 }  // транзакция завершается
                                // неудачей, неверное предусловие состояния

Примерами решений для раннего связывания являются:
- **сукцессивные роллапы (или "zkRollups")** фиксируют некоторое состояние приложения и функцию перехода состояний на цепи.Секвенсор вне цепи выполняет серию переходов состояния, а затем представляет доказательство правильности выполнения для обновления состояния на цепи. Поскольку пользователи должны предоставлять свои состояния для упорядочивания и последовательного выполнения **центральной стороной**, эти системы не являются частными по отношению к секвенсору. Сукцинальные свертки также можно рассматривать как оракулы, которые проверяют состояние вне цепи.
- **[Zcash](https://zips.z.cash/protocol/protocol.pdf)** можно рассматривать как частный случай роллапа, где каждый пользователь является собственным секвенсором, а единственной разрешенной функцией перехода состояния является трансфер.
- **[ZEXE](https://eprint.iacr.org/2018/962.pdf)** [4] расширяет Zcash, позволяя осуществлять произвольные переходы между состояниями.Переходы состояний могут быть настолько общими, как виртуальные машины или процессоры.
- Если пользователям вне цепи необходимо произвести совместные вычисления над приватными данными, они могут использовать протокол ************************************************************secure multi-party computation************************************************************ (SMPC) и аналогичным образом опубликовать доказательство корректного выполнения SMPC на цепи.**Позднее связывание (исполнение на цепи)**.

В модели *позднего связывания* каждое доказательство фиксирует только **намерение** транзакции, но не публичное состояние до или после ее выполнения. Другими словами, доказательство фиксирует только **действие** пользователя, но не его **последствия**. Это аналогично тому, как в Zcash сегодня реализуются приватные переводы. Предполагаемые действия в каждом доказательстве могут быть применены в любом порядке, даже если публичное состояние одновременно обновляется другими транзакциями.

Чтобы обеспечить публичное исполнение, каждая транзакция должна представить свое намерение в виде публичного входа в соответствующее доказательство.В зависимости от дизайна приложения это может привести к утечке информации о частном состоянии пользователя.- В [**Penumbra**](http://penumbra.zone) [5] и [**Polygon Miden**](https://github.com/0xPolygonMiden/miden-vm/discussions/192) [6] это достигается с помощью асинхронной передачи сообщений в *акторной модели*, хорошо зарекомендовавшей себя модели для параллельных вычислений.
- [**Mina**](https://docs.minaprotocol.com/zkapps/advanced-snarkyjs/actions-and-reducer) поддерживает обязательства по *списку действий*, которые представляют собой "ожидающие обновления" и могут обновляться параллельно. Затем эти действия могут быть "сокращены" путем пакетной обработки.
- Аналогичным образом в [**Kachina**](https://eprint.iacr.org/2020/543.pdf) [7] используется "транскрипт оракула состояния" для записи запросов, выполняемых транзакцией к состоянию контракта. Транскрипт фиксируется в момент создания транзакции и применяется во время ее выполнения.

**Шифрование потока**.

Для определенных случаев использования, когда дельты состояний гарантированно гомоморфно аддитивны, в [Penumbra](http://penumbra.zone) введен примитив "шифрование потока". Он заключается в шифровании обновлений состояния для порогового числа валидаторов, их гомоморфном сложении и последующей расшифровке суммарного результата. Это обеспечивает конфиденциальность транзакций на уровне блока и, следовательно, устойчивость к MEV.

Для более общих переходов состояния возможны следующие альтернативы: полностью гомоморфное шифрование (FHE) и анклавы доверенного исполнения (TEE).

## Дополнительная функциональность
В качестве интереса мы также включим небольшое обсуждение следующих вопросов:

### Приватные программы (функциональная приватность)

В некоторых случаях, например, при использовании собственных моделей машинного обучения, пользователь может пожелать скрыть выполняемую программу. В ZEXE [4] функциональная конфиденциальность достигается с помощью одного уровня рекурсии:


Рисунок взят из статьи [VERI-ZEXE](https://eprint.iacr.org/2022/802.pdf).

1. На первом этапе пользователи производят SNARK-доказательства, удостоверяющие выполнение всех соответствующих предикатов над некоторыми локальными данными данной транзакции.
2. Для достижения конфиденциальности функций доказательства SNARK для предикатов-SAT не публикуются непосредственно в бухгалтерской книге.Вместо этого на втором этапе генерируется внешнее доказательство, подтверждающее корректность этих доказательств предикатов, для чего в качестве **секретных свидетелей** берутся доказательства предикатов и их ключи проверки, а внутри внешней схемы запускается верификатор SNARK.

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

### Сетевая конфиденциальность

Сетевой и коммуникационный стек p2p не определяется основным протоколом, но может взаимодействовать с ним, что приводит к непреднамеренной утечке приватной информации. Например, текущий протокол легкого кошелька Zcash позволяет серверу легкого кошелька сопоставлять транзакции с кошельками, подтверждать принадлежность адресов и т.д. При оценке гарантий конфиденциальности предлагаемых решений мы намерены определить список инвариантов, которые должны дополнительно сохраняться базовым сетевым протоколом.## Влияние и снижение рисков

Протокол Zcash [8] обеспечивает надежные гарантии безопасности и конфиденциальности.При внесении модификаций и расширений в протокол мы можем допустить непреднамеренные нарушения некоторых инвариантов, вводя дополнительные предположения о доверии в пользу масштабируемости и выразительности.Чтобы снизить этот риск, мы предоставим **формальные определения конфиденциальности** и доказательства их выполнения, если это применимо. По возможности мы также будем приводить неформальный анализ эффективности рассматриваемого протокола.

Кроме того, многие программируемые свойства конфиденциальности достигаются за счет **удобства использования**, часто требуя от авторов приложений рассуждений о сложных моделях состояний и шаблонах.Мы намерены учесть в нашем анализе удобство использования и предложить меры по устранению типичных "подводных камней" и ошибок, выявляемых этими протоколами.

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

### Этап 1 - Исследование протоколов и параметров

- ******************************************Достигаемый результат:****************************************** Обновление сообщения на форуме сообщества Zcash с основными выводами по результатам исследования и окончательным набором параметров
- ************Охват:************
- исследование и изучение различных существующих протоколов
- первоначальный общий анализ для определения ключевых параметров
- выбор окончательного набора протоколов для использования в анализе - выбор окончательного набора параметров и моделей конфиденциальности для использования в анализе

### Этап 2 - анализ и сравнение протоколов

- ********************************Достигаемый результат:******************************** Обновление сообщения на форуме сообщества Zcash с первоначальным письменным анализом различных выбранных протоколов на основе выбранных параметров
- ************Охват:************
- углубленный анализ каждого из протоколов
- сравнительный анализ для групп схем на основе параметров
- описание потенциальных путей интеграции в zcash
- первоначальный проект основных разделов статьи

### Milestone 3 - Write SoK Paper

- ************************Поставляемый результат:************************ PDF-файл с полным текстом исследования и презентация результатов на Zcon4
- ************Охват:************
- подготовить презентацию для Zcon4
- подготовить статью для отправки в IACR eprint
- представить доклад на конференцию "Финансовая криптография" (и/или другие конференции)

[Milestone Timeline](https://www.notion.so/22fbe66fa2234215bc2c8764395dd63f?pvs=21)

## Бюджет и план оплаты

Для данного проекта мы запрашиваем **общий бюджет в размере 140 000 долларов США*.

Этот бюджет подразумевает 70-90 рабочих дней всей команды (2-3 человека).

| | Платеж 1 | Платеж 2 | Платеж 3 |
| --- | --- | --- | --- |
| Процент | 40% | 30% | 30% |
| Сумма | 56 000 долл.| 42 000 долл.| 42 000 долл.|
| Срок исполнения | После утверждения предложения | После выполнения 2-го этапа | После выполнения 3-го этапа |

## Ссылки
[1] "Платежи за верификацию-ключ". (2017). https://github.com/zcash/zcash/issues/2425

[2] "Предложение по экранированным активам (ZSA/UDA) для DeFi на Zcash". (2021). https://forum.zcashcommunity.com/t/a-proposal-for-shielded-assets-zsa-uda-for-defi-on-zcash/40520

[3] "ZIP 222: Прозрачные расширения Zcash". (2019). https://zips.z.cash/zip-0222

[4] Bowe, S., Chiesa, A., Green, M., Miers, I., Mishra, P., & Wu, H. (2020, May).

Zexe: Обеспечение децентрализованных частных вычислений.In *2020 IEEE Symposium on Security and Privacy (SP)* (pp. 947-964). IEEE.[5] Penumbra: документация по ZSwap. (2021). https://protocol.penumbra.zone/main/zswap.html

[6] Bobbin Threadbare (2022).*Polygon Miden*. https://www.polygon.technology/polygon-miden[7] Kerber, T., Kiayias, A., & Kohlweiss, M. (2021, June). Kachina-foundations of private smart contracts.In *2021 IEEE 34th Computer Security Foundations Symposium (CSF)* (pp. 1-16).IEEE.

[8] D. Hopwood, S. Bowe, T. Hornby, and N. Wilcox, "Zcash Protocol Specification". (2023).[https://github.com/zcash/zips/blob/master/protocol/protocol.pdf](https://github.com/zcash/zips/blob/main/protocol/protocol.pdf)

### Оригинальная статья
[Proposal for SoK on Programmable Privacy](https://inversed.notion.site/Proposal-for-SoK-on-Programmable-Privacy-c72edf7e92114a9abb10381a999c82b5)