Программируемая приватность: Aztec и Garbled Circuits

Эволюция архитектуры приватности: от миксеров к программируемым протоколам

Классические миксеры вроде Tornado Cash или Sinbad уходят в прошлое под давлением регуляторов, санкций управления по контролю за иностранными активами (OFAC) и анализа графов транзакций методом эвристического кластеризованного слежения. Нативная анонимизация на уровне пулов ликвидности блокируется на уровне смарт-контрактов через списки адресов повышенного риска (Chainalysis, Elliptic), интегрированные в RPC-ноды ведущих провайдеров (Infura, Alchemy).

Индустрия переходит к концепции программируемой приватности (Programmable Privacy). Вместо сокрытия самого факта транзакции через размытие депозитов в пуле, новые протокол-уровневые решения позволяют выполнять произвольную бизнес-логику и смарт-контракты поверх зашифрованных данных. Лидерами этого перехода становятся сети на базе zk-rollup архитектур с поддержкой Programmable Privacy, такие как Aztec (Noir), и специализированные конфиденциальные L1-сети вроде COTI 2.0, используя аппаратные и криптографические примитивы нового поколения.

Запутанные схемы (Garbled Circuits) в блокчейне

В основе платформ вроде COTI 2.0 лежит классический криптографический примитив протокол Яо (Yao's Garbled Circuits), адаптированный под децентрализованную среду блокчейна. В отличие от zk-SNARK, доказывающих валидность утверждения без раскрытия данных, Garbled Circuits позволяют двум или более недоверяющим сторонам вычислять произвольную булеву функцию от конфиденциальных входов так, что ни одна из сторон не видит чужих данных.

Механика запутанной схемы

• 1. Представление логики в виде булевой схемы: Любое вычисление (перевод токенов, проверка баланса, кредитный скоринг) компилируется в направленный ациклический граф, состоящий из логических гейтов (AND, XOR, NOT).
• 2. Гарблирование (Запутывание): Создатель схемы (Гарблер) генерирует случайные 128-битные ключи для каждого входа и выхода каждого гейта. Таблицы истинности гейтов шифруются этими ключами в случайном порядке.
• 3. Обливиозный перевод (Oblivious Transfer, OT): Оценщик схемы (Оценщик) получает свои ключи для входа от Гарблера через криптографический протокол OT. Оценщик узнает ключи только для своего реального инпута, не раскрывая его Гарблеру, и не получает доступа к остальным ключам.
• 4. Поэлементное вычисление: Оценщик расшифровывает зашифрованные таблицы истинности снизу вверх по схеме, вычисляя результат без возможности узнать промежуточные значения переменных.

Инженерные оптимизации для блокчейна

Сырые Garbled Circuits требуют огромного объема сетевых коммуникаций. Для интеграции в блокчейн-среду разработчики применяют две ключевые оптимизации:

• Free-XOR техника: Позволяет выполнять гейты XOR без шифрования и передачи данных, сокращая нагрузку на память и пропускную способность шины в несколько раз.
• Point-and-permute: Метод маскирования битов, позволяющий Оценщику сразу находить правильную строку в зашифрованной таблице истинности без перебора всех вариантов дешифрования.

Сравнение криптографических стеков конфиденциальности

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

Практика: Избирательное раскрытие (Selective Disclosure) и стейблкоины

Современный комплаенс требует перехода от концепции «абсолютной тени» к принципу избирательного раскрытия (Selective Disclosure). Пользователь сохраняет полный контроль над историей своего капитала, но при необходимости может доказать контрагенту, регулятору или налоговой легальность средств без раскрытия полного баланса кошелька и всей матрицы связей с другими адресами.

В архитектуре Aztec это реализуется через систему раздельных ключей и клиентское исполнение в Private Execution Environment (PXE).

Архитектура ключей в Aztec

Каждый пользователь управляет детерминированным набором ключей, привязанных к смарт-контракту аккаунта:

• Nullifier Keys ($nhk$): Используются для генерации доказательств траты средств (nullifier) без утечки информации о том, какой именно баланс или нота (note) списываются.
• Incoming Viewing Keys ($ivsk$): Позволяют предоставить аудиторский доступ к конкретным входящим транзакциям. Вы можете передать зашифрованный просмотровый ключ контрагенту или регулятору, открыв им видимость только целевой транзакции стейблкоина (например, USDT/USDC в обертке L2), оставляя остальные активы скрытыми.

Пример реализации: Частный перевод стейблкоинов на Noir

Ниже приведен фрагмент production-ready кода на языке Noir (базовый DSL для написания схем в Aztec), реализующий приватную проверку баланса и генерацию обязательства перевода токенов без публикации сумм в публичном реестре.

Фрагмент кода

// Зависимость в Nargo.toml: poseidon = { tag = "...", git = "https://github.com/noir-lang/poseidon" }
use poseidon::poseidon::bn254::{hash_2, hash_3};
global TREE_DEPTH: u32 = 32;
struct Note {
    owner: Field,
    amount: u64,
    randomness: Field,
}
fn commit(note: Note) -> Field {
    hash_3([note.owner, note.amount as Field, note.randomness])
}
fn merkle_root(leaf: Field, index: u32, path: [Field; TREE_DEPTH]) -> Field {
    let bits: [u1; TREE_DEPTH] = (index as Field).to_le_bits();
    let mut node = leaf;
    for i in 0..TREE_DEPTH {
        node = if bits[i] == 0 {
            hash_2([node, path[i]])
        } else {
            hash_2([path[i], node])
        };
    }
    node
}
fn main(
    // Публичные входы: ничего о суммах и адресах
    merkle_root_pub: pub Field,
    nullifier: pub Field,
    recipient_commitment: pub Field,
    change_commitment: pub Field,
    // Приватные входы
    sender_sk: Field,
    sender_note: Note,
    path: [Field; TREE_DEPTH],
    leaf_index: u32,
    transfer_amount: u64,
    recipient_owner: Field,
    recipient_randomness: Field,
    change_randomness: Field,
) {
    // 1. Владение нотой (с доменным тегом)
    assert(hash_2([sender_sk, 1]) == sender_note.owner);
    // 2. Членство в дереве относительно публичного корня
    let sender_commitment = commit(sender_note);
    assert(merkle_root(sender_commitment, leaf_index, path) == merkle_root_pub);
    // 3. Достаточность средств (при нехватке вычитание u64 тоже упадёт)
    assert(sender_note.amount >= transfer_amount);
    let change_amount = sender_note.amount - transfer_amount;
    // 4. Nullifier
    assert(hash_3([sender_commitment, sender_sk, 2]) == nullifier);
    // 5. Обе новые ноты привязаны к публичным commitments
    assert(commit(Note {
        owner: recipient_owner,
        amount: transfer_amount,
        randomness: recipient_randomness,
    }) == recipient_commitment);
    assert(commit(Note {
        owner: sender_note.owner,
        amount: change_amount,
        randomness: change_randomness,
    }) == change_commitment);
}

Вне схемы остаются: шифрование нот для получателя, хранение и обновление дерева на контракте, проверка уникальности nullifier и сверка merkle_root_pub с известным корнем.

Рекомендации по интеграции для разработчиков

• 1. Отказ от серверной генерации доказательств: Никогда не доверяйте генерацию ZK-пруфов удаленным API-серверам третьих сторон. Весь цикл вычислений (PXE в Aztec или клиентские скрипты) должен выполняться локально на пользовательском устройстве или изолированной ноте.
• 2. Управление апп-силированными ключами (App-Siloed Keys): Используйте изолированные производные ключи для каждого децентрализованного приложения. Это гарантирует, что компрометация ключа в одном протоколе не приведет к деанонимизации истории транзакций пользователя в других смарт-контрактах.
• 3. Аудит каналов View Keys: При проектировании корпоративных шлюзов или платежных шлюзов на базе программируемой приватности закладывайте логику генерации временных просмотровых ключей с ограничением по времени жизни. Это позволяет проходить банковский и регуляторный комплаенс (AML/KYT) без публикации перманентных мастер-ключей кошелька.