Аудит криптовалютного кошелька — это возможность для третьей стороны («аудитора») видеть транзакции этого кошелька и рассчитывать его корректный актуальный баланс без права на трату средств.

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

Материал рассчитан на читателей, знакомых с темой блокчейна и «классических» криптовалют, а также с основами криптографии на эллиптических кривых.

Содержание

1. Введение
2. Базовые сведения о криптографии на эллиптических кривых
3. Учет средств и расчет баланса в CryptoNote
4. Вариант 1/3. Bytecoin Auditable Coins
4.1. tx.version < amethyst, legacy address
4.2. tx.version ≥ amethyst
4.3. tx.version ≥ amethyst, legacy address
4.4. tx.version ≥ amethyst, amethyst address
4.5. Сравнение подписей транзакций CryptoNote и Bytecoin Amethyst
5. Вариант 2/3. Исследования аудита в CryptoNote от Anton Sokolov
6. Вариант 3/3. Аудит через ограничение на подмешивание выходов
7. Заключение
Литература

1. Введение

Что такое CryptoNote?

Как это ни странно, но большинство интересующихся блокчейн-технологиями ничего не слышали о CryptoNote, и это несмотря на то, что эта технология явилась основой для более чем 300 форков, самым известным из которых стал Monero.

В 2014 году в криптовалютной среде появились упоминания [2] о проекте, который назывался Bytecoin. Проект не являлся форком Bitcoin или другого открытого проекта и имел совершенно новую кодовую базу, что было крайне необычно для того времени. Его основная концепция сводилась к реализации privacy-технологии, которую называли CryptoNote. Приватность обеспечивалась двумя механизмами: стелс-адресами и подмешиванием входов с использованием кольцевой подписи (ее еще называли в то время «микшер на блокчейне»). Поскольку в то время Zcash существовал только в теории, технология оказалась весьма конкурентоспособной и вызвала большой резонанс в криптовалютном сообществе.

Вскоре группа энтузиастов, проявившая интерес к одному из первых форков этой технологии, а затем и перехватившая инициативу в этом форке, своими энергичными действиями сумела привлечь наибольшее внимание к технологии как среди сообщества так и среди инвесторов. Этот форк назывался BitMonero [3, 4], однако довольно скоро он был переименован в Monero.

В дальнейшем оба проекта — Bytecoin и Monero — развивались технологически разными путями: если Bytecoin оставался закрытым анонимным проектом, то Monero превратился в крупный community-driven проект с очень большим количеством участников и разработчиков. Тем не менее, они оба являются развитием CryptoNote технологии.

Понятие аудита и его приложения

В отличие от классического «псевдонимного» блокчейна типа Bitcoin, в котором любой желающий, сканируя блокчейн, может тривиально подсчитать балансы любого адреса, в приватном блокчейне, в частности, в CryptoNote, эта задача едва ли осуществима без дополнительных знаний. Во-первых, благодаря технологии стелс-адресов, в блокчейне вообще отсутствуют упоминания каких-либо адресов (это свойство обычно обозначается как anonymity). Во-вторых, в силу того, что благодаря кольцевой подписи вход транзакции не указывает на один конкретный выход родительской транзакции, а указывает, в общем случае, на множество вероятных выходов, отследить движение средств также не представляется возможным (это свойство называется untraceability).

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

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

Об авторе и цели публикации

Автор данного материала является одним из основных разработчиков проекта Zano — проекта, основанного на CryptoNote, который развивался несколько лет теми же руками, которыми был написан оригинальный код технологии.

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

2. Базовые сведения о криптографии на эллиптических кривых

Протокол CryptoNote использует эллиптическую кривую из схемы цифровой подписи с открытым ключом ed25519 [5].

Напомним основные параметры этой кривой и дадим дополнительные определения.

Зафиксировано большое простое число $q = 2^{255}-19$ .
Все операции происходят в целых числах в конечном поле $inline$ вычетов по модулю $inline$ .
Задана эллиптическая кривая над полем $inline$ , обозначаемая $inline$ :
$inline$
где $inline$ (отношение вычисляется в $inline$ и является целым числом).
Важным является факт ее симметрии относительно $inline$ и $inline$ .
Над множеством точек кривой геометрически определена операция, для любых двух точек дающая третью: $inline$ , условно называемая «сложением», и задан нейтральный элемент, как точка, лежащая в бесконечности (это подробно рассмотрено в [6]). Эта операция не выводит за пределы множества, обладает ассоциативностью, коммутативностью и наличием обратного элемента, благодаря чему все точки кривой вкупе с ней образуют абелеву группу, обозначаемую $inline$ .
Порядок этой группы (число всех точек): $\# E(F_q)=2^cl$ , где $inline$ (кофактор) и $l=2^{252}+27742317777372353535851937790883648493$ .
Каждая точка кривой задается своими координатами $inline$ . Поскольку координаты связаны уравнением кривой, это представление избыточно, и поэтому при реализации криптографических функций для экономии используется только координата $inline$ , кодируемая как 256-битное число.
$inline$ -координата, в соответствии с симметричностью кривой (см. уравнение), может быть только одним из двух вариантов, выбор которого кодируется как старший бит числа, представляющего $inline$ -координату.
Зафиксирована специальная точка кривой $inline$ . Точка задается $inline$ -координатой, из двух возможных вариантов x выбирается положительный.
Сложение (см. п. 3) точки $inline$ с самой собой $inline$ раз определяет операцию умножения ( $inline$ , опускается в формулах) на целое число, образующую замкнутую мультипликативную группу $\mathbf{G}$ , порядок которой меньше, чем $inline$ :
$\#\mathbf{G} < \#E(F_q)$ ,
при этом
$\#\mathbf{G}=l=2^{252}+27742317777372353535851937790883648493$ .
Открытый ключ $inline$ — это точка эллиптической кривой, принадлежащая группе $\mathbf{G}$ :
$X \in \mathbf{G}$
Секретный ключ $inline$ , или скаляр, соответствующий открытому ключу $inline$ — это такое целое число, что:
$X = x*G, x \in [1; l-1]$
Секретный ключ, также как и открытый (см. выше), кодируется как 256-битное число.
Определена основная хеш-функция $inline$ (в коде и других источниках обозначается как cn_fast_hash). Она вычисляет 32-байтный хеш по произвольному набору данных: $H:\{0, 1\}^* \to [0,2^{256}-1]$
Хеш-функция $inline$ ( $inline$ означает scalar) по произвольным данным выдает число, являющееся скаляром, т.е. валидным секретным ключом:
$H_s:\{0,1\}^* \to [1; l-1]$
$inline$ может быть реализована тривиально через $inline$ :
$H_s(x)= H(x) \mod (l-1) + 1$
Хеш-функция $inline$ ( $inline$ означает point — точка кривой) по произвольным данным выдает элемент группы $\mathbf{G}$ , то есть, валидный открытый ключ:
$H_p:\{0,1\}^* \to \mathbf{G}$
Реализация этой хеш-функции представляет определенную сложность по той причине, что во-первых, не любой набор 256 бит можно декодировать в точку эллиптической кривой (см. п. 4), а во-вторых, не любая точка кривой принадлежит группе $\mathbf{G}$ (см. п. 6).
Одним из тривиальных способов реализации $inline$ является последовательное хеширование данных $inline$ до тех пор, пока результат не станет возможным декодировать в точку $X \in \mathbf{G}$ .
В CryptoNote используется более сложный и эффективный подход, реализованный в виде функции ge_fromfe_frombytes_vartime, который подробно рассмотрен в работе [7].
Определим функцию, детерминированно преобразующую произвольные 256 бит в элемент группы $\mathbf{G}$ как:
$to\_point : [0,2^{256}-1] \to \mathbf{G}$
В CryptoNote хеш-функция $inline$ реализована так:
$H_p(x) = to\_point( H(x) )$

3. Учет средств и расчет баланса в CryptoNote

Вспомним, как происходит отправка средств и расчет баланса в оригинальной версии протокола.

Алиса, отправляя деньги Бобу, формирует выходы своей транзакции следующим образом (рис. 3.1).

_{Рис. 3.1. Алиса формирует выходы транзакции, отправляя деньги Бобу}

У Боба есть пара закрытых ключей $inline$ . Он вычисляет свой адрес как пару соответствующих открытых ключей $inline$ и опубликовывает его или отправляет Алисе.
Алиса выбирает случайный секретный ключ транзакции $inline$ и вычисляет открытый ключ $inline$ , который записывает в специальное поле extra транзакции.
Для каждого выхода Алиса вычисляет стелс-адрес (one-time destination key):
$inline$ , где $inline$ — порядковый номер выхода.
Алиса подписывает и отправляет транзакцию.

Сторонний наблюдатель, анализируя стелс-адреса $inline$ , не может сказать, предназначен ли конкретный выход Бобу, и даже не может определить, предназначены ли разные выходы с ключами $inline$ и $inline$ одному получателю.

Чтобы принять деньги, Боб анализирует все транзакции в блокчейне следующим образом (рис. 3.2).

_{Рис. 3.2. Боб проверяет выходы транзакции, чтобы определить входящие переводы}

5. Используя свой секретный ключ $inline$ , Боб вычисляет для каждого выхода $inline$ (где $inline$ — порядковый номер выхода, $inline$ — открытый spend-ключ Боба).
Если $inline$ , то это означает, что он является получателем данного выхода и может его потратить, вычислив соответствующий секретный ключ.Поэтому Боб увеличивает баланс своего кошелька на номинал данного выхода.

Чтобы потратить выход, получателем которого Боб является, и отправить монеты Кэрол, он действует следующим образом.

_{Рис. 3.3. Боб формирует вход для новой транзакции, используя принадлежащий ему выход}

6. Боб, используя свои секретные ключи $inline$ , вычисляет закрытый ключ $inline$ к стелс-адресу $inline$ , то есть такой, что $inline$ .

7. Боб рассчитывает key image: $inline$ и записывает его, номинал и ссылку на соответствующий выход во вход своей транзакции для Кэрол.
Следует обратить внимание на то, что, во-первых, вычислить key image может только владелец секретного spend-ключа $inline$ (корректность этого будет удостоверена кольцевой подписью), и во-вторых, третья сторона не сможет связать key image $inline$ и соответствующий стелс-адрес $inline$ .

8. Боб уменьшает баланс своего кошелька на номинал используемого выхода в п. 6.

9. Боб формирует выходы в транзакции для Кэрол в соответствии с п.п. 2-3. После чего подписывает транзакцию и отправляет.

Если предположить, что Боб утратил всю историю своих операций, но по-прежнему владеет своими секретными ключами $inline$ , то он сможет восстановить историю транзакций и рассчитать свой текущий баланс следующим образом (рис. 3.4).

_{Рис. 3.4. Боб определяет свои входящие и исходящие платежи и рассчитывает баланс}

10. Боб сканирует весь блокчейн и анализирует все транзакции на предмет наличия выходов, адресованных ему (см. п. 5).

11. При нахождении такого выхода $inline$ , Боб увеличивает баланс своего кошелька на величину номинала.
Затем, используя свой секретный spend-ключ $inline$ вычисляет соответствующий секретный ключ выхода $inline$ (п. 6) и key image $inline$ (п. 7). После чего записывает key image, $inline$ и другие данные платежа в таблицу.

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

Действуя таким образом, Боб восстановит актуальный баланс своего кошелька.

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

Таким образом, для расчета баланса кошелька Боба необходимо знать оба секретных ключа $inline$ .

Если Боб передаст аудитору Дену оба своих секретных ключа $inline$ , это будет равносильно передаче самих средств, так как Ден, обладая $inline$ , сможет их потратить. Поэтому полноценный аудит кошельков в рамках оригинального протокола CryptoNote невозможен.

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

Отметим, что секретный ключ транзакции $inline$ Алисе имеет смысл сохранять (что и происходит в некоторых реализациях протокола). Любой, кто знает $inline$ для некоторой транзакции, может проверить, относится ли выход $inline$ этой транзакции к заданному адресу $inline$ , просто повторяя вычисления из п.3:

$inline$

и сравнивая результат с $inline$ .

Этот факт Алиса может, например, использовать, чтобы доказать, что она перевела деньги именно Бобу.

Вычислить целевой адрес $inline$ по выходу, даже зная $inline$ , нельзя.

4. Вариант 1/3. Bytecoin Auditable Coins

В момент своего появления Bytecoin был первой и единственной реализацией протокола CryptoNote, поэтому ему были свойственны все особенности и ограничения, рассмотренные в предыдущем разделе.

7 февраля 2019 года разработчики выпустили ([20]) версию 3.4.0 Amethyst, содержащую ряд улучшений и изменений CryptoNote, которые мы сейчас рассмотрим. Большая часть информации этого раздела была получена путем анализа исходного кода Bytecoin, так как официальной документации не предоставлено.

В рамках тематики этой статьи, наиболее интересным изменением стала возможность для обычных кошельков создавать специальные копии — auditable wallet (AW), обладающие двумя свойствами:

AW не может потратить средства из основного кошелька;
баланс AW всегда совпадает с балансом основного кошелька. Невозможно изменить баланс основного кошелька так, чтобы это не отразилось на балансе AW.

Однако, такой функциональностью обладают только адреса кошельков новых версий, так называемые, amethyst-адреса. С существующими адресами и аккаунтами обеспечивается обратная совместимость, они теперь называются legacy-адреса. Реализация новой функциональности стала возможна только в транзакциях новой версии, поскольку разработчики поменяли формат выходов, поэтому в сети Bytecoin в данный момент циркулируют как транзакции старого формата, так и новые. Транзакции нового формата также поддерживают два типа адресов: amethyst и legacy, поэтому в конечном счете мы имеем три варианта криптографических схем:

tx.version < amethyst, legacy address;
tx.version ≥ amethyst, legacy address;
tx.version ≥ amethyst, amethyst address.

Рассмотрим их более подробно.

4.1. tx.version < amethyst, legacy address

Это оригинальная схема CryptoNote, но с детерминированной генерацией $inline$ .

Аккаунт кошелька представлен секретным ключом $inline$ и хешем $inline$ . Секретный view-ключ $inline$ детерминированно генерируется как функция от $inline$ .

Секретный ключ $inline$ транзакции теперь выбирается не случайно, а вычисляется при помощи $inline$ :

$inline$ , где $inline$

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

Баланс кошелька вычисляется аналогично оригинальному CryptoNote (см. раздел 3), то есть, для учета исходящих платежей необходим секретный spend-ключ $inline$ .

В случае, если в локальном хранилище кошелька будут сохранены все адреса, на которые когда-либо осуществлялся перевод средств, то существует возможность рассчитать верный баланс без привлечения секретного spend-ключа $inline$ следующим образом:

Алиса сканирует транзакции в блокчейне и ведет учет входящих платежей при помощи секретного view-ключа $inline$ , как было описано в разделе 3, и увеличивает баланс.
Также для каждого выхода каждой транзакции Алиса перебирает все адреса $inline$ на которые когда-либо осуществлялись переводы и вычисляет:
$inline$
Если $inline$ , то данный выход является исходящим платежом Алисы на адрес $inline$ и она уменьшает баланс.

Так Алиса рассчитает баланс используя только $inline$ и $inline$ .

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

4.2. tx.version ≥ amethyst

Как уже было отмечено выше, начиная с версии 3.4.0 Amethyst в Bytecoin изменился формат транзакций. Если tx.version ≥ amethyst, то выходы транзакции имеют другой формат.

Теперь каждый выход, помимо номинала amount и открытого ключа P_i, содержит также дополнительный открытый ключ Q_i (обозначаемый в коде как encrypted_secret) и дополнительный байт, содержащий зашифрованный тип адреса, amethyst или legacy (именуемый в коде encrypted_address_type). Эти структуры схематично показаны на рис. 4.2.

_{Рис. 4.2. Сравнение структуры данных для выходов транзакций CryptoNote и Bytecoin Amethyst}

Таким образом, размер каждого выхода увеличился на 33 байта.

Для каждого выхода i тип адреса кодируется и декодируется следующим образом:

encrypted_address_type(i) = (H(o_i) & 255) xor address_tag

где:

$inline$ (обозначается в коде как output_seed),

address_tag равен 0 для legacy-адресов и 1 для ametyst-адресов.

4.3. tx.version ≥ amethyst, legacy address

Аккаунт кошелька также представлен секретным ключом $inline$ и хешем $inline$ , на основе которого детерминированно генерируется секретный view-ключ $inline$ .

Алиса, отправляя деньги Бобу на его адрес $inline$ формирует выходы своей транзакции следующим образом:

1. Вычисляет $inline$ , затем для каждого выхода $inline$ :
2. $inline$ (в коде обозначается как output_shared_secret)
3. $inline$
4. $inline$ (при этом $inline$ , однако view-ключ $inline$ получателя неизвестен)
5. Пара $inline$ — открытые ключи выхода $inline$ .

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

6. Для каждой транзакции вычисляет $inline$ , затем для каждого выхода $inline$ :
7. $D_i = v^{-1} Q_i$
8. $inline$
9. Если $inline$ совпадает с открытым ключом $inline$ Боба, то этот выход предназначен ему и он увеличивает баланс своего кошелька на соответствующий номинал.

Чтобы потратить выход, получателем которого Боб является, и отправить монеты Кэрол, он действует следующим образом.

10. Используя свои секретные ключи $inline$ и $inline$ , вычисляет секретную часть $inline$ :
$D_i = v^{-1} Q_i$
$inline$ , при этом легко видеть, что $inline$ (см. п. 3).
11. Боб рассчитывает key image: $inline$ и записывает его, номинал и ссылку на соответствующий выход во вход своей транзакции для Кэрол.
12. Боб уменьшает баланс своего кошелька на номинал используемого выхода.
13. Боб формирует выходы в транзакции для Кэрол в соответствии с п.п. 1-5. После чего подписывает транзакцию и отправляет.

Особенностью данной схемы, в отличии от CryptoNote, является то, что любой, кому Алиса передаст свой секретный хеш $inline$ , сможет вычислить адрес получателя $inline$ для любой транзакции Алисы:

14. $inline$
15. $inline$
16. $V = H_s(h_t, v_s, i)^{-1} Q_i$

Однако проблемой в данном случае является задача определения, какие транзакции сформировала и отправила Алиса. Без этой информации в п.п. 14-16 для произвольных транзакций будут получатся произвольные бесполезные данные, неотличимые от настоящих адресов $inline$ . Некоторую помощь в этом может оказать алгоритм кодирования encrypted_address_type, так как для транзакций Алисы это поле после декодирования будет иметь только допустимые значения $\{0, 1\}$ . Но, к сожалению, допустимые значения также могут получится и произвольно, и такой случай нельзя будет отличить.

Поскольку в данной схеме вычисление key image также требует знания секретного spend-ключа $inline$ , то проблема аудита, то есть, вычисления точного баланса кошелька без передачи прав на трату средств, остается не решенной.

4.4. tx.version ≥ amethyst, amethyst address

Константа H

Для работы этой криптографической схемы требуется введение новой константы — точки $inline$ , элемента группы $\mathbf{G}$ , причем порядок точки $inline$ неизвестен. Иными словами, это некоторый зафиксированный открытый ключ, секретная часть которого гарантировано неизвестна и вероятность ее нахождения пренебрежимо мала:

$inline$ , где $inline$ — неизвестное число.

Например, можно задать $inline$ так, как предлагается в [8]:

$H = H_p(G) = to\_point( cn\_fast\_hash(G) )$

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

bytecoin/src/crypto/crypto_helpers.hpp, line 67

constexpr P3 H{ge_p3{{7329926, -15101362, 31411471, 7614783, 27996851, -3197071, -11157635, -6878293, 466949, -7986503},    {5858699, 5096796, 21321203, -7536921, -5553480, -11439507, -5627669, 15045946, 19977121, 5275251},    {1, 0, 0, 0, 0, 0, 0, 0, 0, 0},    {23443568, -5110398, -8776029, -4345135, 6889568, -14710814, 7474843, 3279062, 14550766, -7453428}}};

Однако поиск этой числовой последовательности показал ([9]), что ими используется та же константа, что и в Monero для RingCT, способ вычисления которой и его обоснование рассмотрены в [8].

Поскольку $inline$ принадлежит группе $\mathbf{G}$ , то можно сказать, что $inline$ так же порождает группу $\mathbf{G}$ , как и базовая точка $inline$ .

Это означает, что $\forall x \in [1,p-1], xH \in \mathbf{G}$

Множественные несвязываемые адреса (unlinkable addresses)

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

Рассматриваемая же схема позволяет на одном и том же наборе секретных ключей генерировать неограниченное количество публичных адресов. При этом:

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

Аккаунт кошелька представлен секретным ключом $inline$ и хешем $inline$ , также, как и в предыдущей схеме. Однако на основе хеша $inline$ теперь детерминированно генерируется не только секретный view-ключ $inline$ , но и дополнительный секретный audit-ключ $inline$ .

Процесс генерации i-го адреса происходит следующим образом (рис. 4.4.2).

_{Рис. 4.4.2. Генерация amethyst-адресов для аккаунта Bytecoin (желтым цветом обведены предрассчитанные величины, раскрытие которых не угрожает раскрытию секретных ключей , и )}

1. Вычисляется $\delta = H_s(A + sH, i)$ и $\Delta = \delta G$
2. $inline$
3. $inline$
4. пара $inline$ является $inline$ -ым публичным адресом данного аккаунта.

Заметим, что для расчета достаточно знать следующие величины:
• $inline$
• $inline$
• $inline$
• $inline$

Величины $inline$ и $inline$ предрассчитываются при создании аккаунта и рассматриваются как безопасные в том смысле, что зная их, нельзя вычислить $inline$ или $inline$ .

Сгенерированные адреса хранятся локально в контейнере, оптимизированном для поиска по полю $inline$ .

Формирование выходов при отправке средств

Алиса, отправляя деньги Бобу на его адрес $inline$ формирует выходы своей транзакции следующим образом (рис. 4.4.3).

_{Рис. 4.4.3. Формирование выходов транзакции при отправке средств на Amethyst-адрес}

1. Вычисляет $inline$ , затем для каждого выхода $inline$ :
2. $P_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} S$
3. $Q_i = H_s( H_p(h_t, v_s, i), h_t, i )^{-1} V + H_p(h_t, v_s, i)$
4. Пара $inline$ — открытые ключи выхода $inline$ .

Учет входящих платежей

Чтобы принять деньги, Боб анализирует все транзакции следующим образом (рис. 4.4.4.).

_{Рис. 4.4.4. Анализ выходов транзакции на предмет входящих переводов}

Для каждого выхода $inline$ , используя секретный view-ключ $inline$ , Боб вычисляет: $inline$ (output_shared_secret в коде)
$inline$
После чего пытается найти $inline$ в списке своих адресов. Если находит, то это означает, что данный выход переводит деньги Бобу. Он увеличивает баланс для соответствующего адреса.

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

Формирование исходящих платежей

Чтобы потратить выход $inline$ , получателем которого Боб является, и отправить монеты Кэрол, он действует следующим образом.

$inline$ (output_shared_secret в коде)
$x_i = H_s(K, h_t, i)^{-1} (a + \delta)$
$X_i = x_i G + H_s(K, h_t, i)^{-1} s H$
Вычисляет key image $inline$
Боб уменьшает баланс, относящийся к его адресу $inline$ на величину номинала соответствующего выхода.
Боб формирует выходы транзакций, подписывает ее и отправляет.

Видно, что для вычисления key image требуется знание не только секретного view-ключа $inline$ , но и $inline$ .

Важной особенностью данной схемы является возможность вычисления key image (а значит, и учета своих исходящих платежей, следовательно — расчет баланса) без использования секретного spend-ключа $inline$ .

Раскрытие адресов получателей для аудита

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

Происходит это следующим образом (рис. 4.4.5).

_{Рис. 4.4.5. Аудитор, обладая , восстанавливает информацию о входящих/исходящих платежах, балансе и адресах получателей}

Предположим, что Алиса передала $inline$ и $inline$ Кэрол. Тогда Кэрол:

Восстановит секретные ключи $inline$ и $inline$ , восстановит список адресов Алисы.
Будет сканировать блокчейн и для каждого выхода $inline$ каждой транзакции будет определять, является ли он входящим платежом, пытаясь найти
$inline$
среди адресов Алисы.
Если найдет, то Кэрол увеличит баланс соответствующего адреса и, при помощи $inline$ и $inline$ , вычислит key image (см. выше) и сохранит его локально.
Если среди входов транзакций встретится key image Алисы, то это будет означать, что данная транзакция — исходящий платеж Алисы. Кэрол восстановит адреса получателей для всех выходов этой транзакции:
$inline$
$inline$
и уменьшит баланс соответствующего адреса Алисы на величину номинала входа.

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

Чтобы сгенерировать список своих адресов:
• $inline$
• $inline$
• $inline$
• $inline$

Чтобы распознать только входящие платежи:
• $inline$
• $inline$
• $inline$

Чтобы произвести аудит, т.е. рассчитать баланс по своим адресам, без раскрытия адресов получателей:
• $inline$
• $inline$
• $inline$

Чтобы произвести аудит, т.е. рассчитать баланс по своим адресам, и раскрыть при этом адреса получателей:
• $inline$
• $inline$

4.5. Сравнение подписей транзакций CryptoNote и Bytecoin Amethyst

Структуры данных и размеры подписей

Как было отмечено выше, реализация возможности проводить аудит кошельков, не раскрывая секретный spend-ключ, потребовала от разработчиков Bytecoin Amethyst увеличения размера данных, передаваемых в каждом выходе транзакции: по сравнению с оригинальным протоколом передается один открытый ключ и 1 байт для идентификации типа адреса. Итого, 33 байта на выход.

В CryptoNote у транзакции подписывается отдельно каждый ее вход. Для каждого открытого ключа $inline$ некоторого выхода, на который ссылается данный вход, в подпись записывается пара скаляров $inline$ общим размером 64 байта. (Вход может ссылаться на несколько выходов, лишь один из которых — настоящий, а остальные служат для анонимизации перевода.)

Таким образом, если в транзакции $N_{inputs}$ входов, каждый из которых ссылается на $N_{mixins}$ выходов, то общий размер подписи в байтах можно выразить как:

$S = 32 * 2 * N_{mixins} * N_{inputs}$

Минимальный размер подписи для транзакции составляет 64 байта (один вход, который тратит один выход напрямую).

В Bytecoin Amethyst подписывается вся транзакция целиком, и соответствующая структура данных усложнена (рис. 4.5.1).

_{Рис. 4.5.1. Сравнение структуры подписи транзакции в CryptoNote и Bytecoin}

Для каждого входа транзакции в подпись записывается точка, два скаляра и еще $N_{mixins}$ скаляров. Ко всей подписи также добавляется еще один скаляр. Итого, общий размер подписи в байтах можно выразить как:

$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$

Минимальный размер подписи для транзакции составляет 160 байт (один вход, который тратит один выход напрямую).

Видно, что обе функции растут пропорционально произведению $N_{mixins} * N_{inputs}$

Чтобы сравнить различие размеров подписи транзакции более наглядно, рассчитаем их для наиболее характерных величин $N_{mixins}$ и $N_{inputs}$ и составим таблицу (рис. 4.5.2).

_{Рис. 4.5.2. Различие в размере подписи транзакции Bytecoin по сравнению с CryptoNote (в процентах относительно размера подписи CryptoNote; зеленым отмечен выигрыш в размере подписи Bytecoin)}

Как легко можно видеть, в ситуации, когда подмешивание выходов отсутствует и происходит прямая трата средств ( $N_{mixins} = 1$ ), либо когда подмешивается один выход ( $N_{mixins} = 2$ ), размер подписи Bytecoin больше, чем CryptoNote до 150%.

При подмешивание двух выходов ( $N_{mixins} = 3$ ) размеры подписей в той и другой схемах практически совпадают.

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

Стоит отметить, что разработчики Bytecoin с выходом версии 3.4.0 Amethyst в целях увеличения анонимности установили минимальное число подмешиваемых выходов равным 3 [10]. В таких условиях подпись Bytecoin будет обладать меньшим размером.

Трудоемкость проверки подписи

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

Трудоемкость проверки подписи для CryptoNote и Bytecoin можно было бы легко сравнить практически, просто написав тест, генерирующий, а затем проверяющий большое число подписей с заданными $N_{mixins}$ и $N_{inputs}$ , однако, поскольку далее в статье будут рассмотрены еще не реализованные на практике, а лишь предлагаемые в теории схемы, будет логично трудоемкость и этих схем оценивать эмпирически, по числу используемых криптографических операций.

В CryptoNote и Bytecoin используется несколько основных примитивов (см. раздел 2). В таблице на рис. 4.5.3. приведено характерное время выполнения самых часто используемых примитивов на современном middle-end компьютере с процессором Core i5-6500 (для сравнения использовался оригинальный исходный код, скомпилированный в Microsoft Visual Studio 2017 со всеми возможными оптимизациями по скорости).

_{Рис. 4.5.3. Характерное время основных криптографических операций}

Результаты, полученные из тестов в Bytecoin и CryptoNote хорошо согласуются между собой. Легко видеть, что наибольший вклад будет давать операция умножения скаляра на точку, и, в меньшей степени, процедура вычисления хеш-функции $inline$ , при этом операции сложения двух точек и вычисления хеш-функции $inline$ не будут существенно влиять на сложность.

Рассмотрим процедуру проверки кольцевой подписи CryptoNote (рис. 4.5.4, процедура генерации подписи подробно рассмотрена в [1] и здесь рассматриваться не будет).

_{Рис. 4.5.4. Схема проверки кольцевой подписи CryptoNote}

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

Для каждой пары значений $inline$ и $inline$ при помощи key-image входа $inline$ и открытого ключа $inline$ очередного выхода, на который ссылается данный вход, вычисляются величины: $inline$
$inline$
(при этом индекс j пробегает значение от 0 до $N_{mixins}$ )
Вычисляется сумма $inline$ всех $inline$ .
Вычисляется хеш $c`=H_s(tx\_prefix\_hash, L_0 ... L_n, R_0 ... R_n$ )
где tx_prefix_hash — хеш префиксной части транзакции (без подписи).
Проверяется равенство $inline$ . Если оно выполняется, то кольцевая подпись считается действительной.

Оценим число операций умножения скаляра на точку и вычисления хеша $inline$ .

Каждое вычисление $inline$ и $inline$ требует по два скалярных умножения. Число пар $inline$ соответствует числу подмешиваемых выходов $N_{mixins}$ для каждого входа. Поэтому имеем:

$O(*) = N_{inputs} * 4 * N_{mixins}$

При этом хеш-функция $inline$ используется однократно при каждом вычислении $inline$ , следовательно:

$O(H_p) = N_{inputs} * N_{mixins}$

Теперь рассмотрим алгоритм проверки кольцевой подписи в Bytecoin Amethyst (рис. 4.5.5).

_{Рис. 4.5.5. Схема проверка кольцевой подписи в Bytecoin Amethyst}

Проверяется целиком вся подпись, для всех входов сразу. Происходит это так:

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

Оценим число операций умножения скаляра на точку и вычисления хеша $inline$ .

Каждое вычисление $inline$ и $inline$ требует по два скалярных умножения, плюс вычисление $inline$ требует трех скалярных умножений. Число пар $inline$ соответствует числу подмешиваемых выходов $N_{mixins}$ для каждого входа. Поэтому имеем:

$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$

При этом хеш-функция $inline$ используется однократно при каждом вычислении $inline$ и однократно для вычисления $inline$ для каждого из входов, следовательно:

$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

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

$inline$

Затем сравним относительные результаты для CryptoNote и Byteсoin в процентах (рис. 4.5.6).

_{Рис. 4.5.6. Вычислительная сложность проверки кольцевой подписи Bytecoin Amethyst по сравнению с CryptoNote (зависимость от отсутствует)}

Как видно, проверка подписи Bytecoin является значительно более трудоемкой операцией.

Однако, как уже было отмечено выше, в Bytecoin с версии 3.4.0 Amethyst в целях увеличения анонимности установлено минимальное число подмешиваемых выходов равным 3 [10], поэтому худшее практическое значение не превысит 25% (в теории).

Подытожим:

Размер каждого выхода увеличивается на открытый ключ $inline$ — 32 байта.
Размер кольцевой подписи варьирует в сравнении с размером подписи CryptoNote в зависимости от числа подмешиваемых выходов (при большом их числе оказывается меньше):
$S = 32 * ((3 + N_{mixins}) * N_{inputs} + 1)$
Вычислительная сложность выше, чем в CryptoNote и значительно зависит от числа подмешиваемых выходов:
$O(*) = N_{inputs} * (3 + 4 * N_{mixins})$
$O(H_p) = N_{inputs} * (N_{mixins} + 1)$

5. Вариант 2/3. Исследования аудита в CryptoNote от Anton Sokolov

Осенью 2019 года на площадке Medium.com была опубликована серия эссе [11, 12, 13, 14, 15, 18] о проблеме аудита в CryptoNote и возможных способах ее решения под авторством Anton Sokolov. В ней с теоретических позиций рассматриваются несколько вариантов модификации оригинального протокола таким образом, чтобы решить задачу аудита для третьей стороны.

Рассмотрим последнюю из них [15] как наиболее оптимизированную. Будем сокращенно обозначать ее как «AS».

Примечание: для единообразия изложения spend-ключи и далее будут обозначаться буквами $inline$ и $inline$ , view-ключи — буквами $inline$ и $inline$ , несмотря на то, что в оригинальных работах используются $inline$ , $inline$ и $inline$ , $inline$ соответственно.

Формирование выходов

Аккаунт кошелька представлен набором не двух, как в CryptoNote, а трех секретных ключей $\{v, s, d\}$ : view-, spend- и audit-ключи соответственно.

Совокупность трех открытых ключей $\{V, S, D\}$ представляет публичный адрес этого аккаунта.

Алиса, отправляя деньги бобу, действует следующим образом (рис. 5.1).

_{Рис. 5.1. Формирование выходов транзакций в схеме AS}

Боб опубликовывает свой адрес, поэтому Алиса знает его открытые ключи $inline$ , $inline$ и $inline$ .
Так же, как и в CryptoNote, Алиса выбирает случайный секретный ключ транзакции $inline$ и вычисляет открытый ключ $inline$ , который записывает в специальное поле extra транзакции.
Для каждого выхода Алиса вычисляет не один, а два стелс-адреса $inline$ и $inline$ . Первый рассчитывается аналогично CryptoNote:
$inline$
Второй иначе:
$inline$
Порядковый номер выхода в оригинальной работе здесь не используется, однако, разумно предположить, что это сделано для упрощения и на практике он будет одним из аргументов функции $inline$ по аналогии с CryptoNote (см. раздел 3).
Алиса подписывает и отправляет транзакцию.

Сторонний наблюдатель не сможет связать $inline$ и $inline$ с адресом Боба.

Распознавание входящих платежей и формирование входов

Чтобы принять и потратить деньги, Боб действует следующим образом (рис. 5.2).

_{Рис. 5.2. Определение входящих переводов и формирование входов для тратящей их транзакции}

Используя свой секретный view-ключ $inline$ , Боб стелс-адрес $inline$ каждого выхода сравнивает с точкой:
$inline$
(этот шаг аналогичен CryptoNote)
В случае, если равенство выполняется, это означает, что данный выход адресован Бобу. Он увеличивает свой баланс на величину номинала выхода.
При необходимости перевести полученные средства Кэрол, Боб, используя свои секретные spend- и audit-ключи $inline$ и $inline$ , вычисляет два key image: $inline$ и $\ddot I$ . Первый — аналогично CryptoNote:
$inline$
и дополнительный:
$inline$
$\ddot I = t H_p(P)$
Затем записывает их, номинал и ссылку на соответствующий выход во вход своей транзакции для Кэрол.
Затем Боб формирует выходы транзакции для Кэрол, уменьшает свой баланс пропорционально потраченным выходам, подписывает транзакцию и отправляет.

Как видно, здесь так же, как и в CryptoNote третья сторона — Аудитор — обладая только секретным view-ключом $inline$ , сможет распознать только входящие переводы.

Аудит

Если же Аудитор располагает также секретным audit-ключом $inline$ , то он сможет распознать исходящие платежи Боба и рассчитать его баланс следующим образом:

Для каждого входящего платежа Аудитор будет рассчитывать и запоминать дополнительный key image $\ddot I$ в локальном хранилище:
$inline$
$\ddot I = t H_p(P)$
Если во входах какой-либо из транзакций блокчейна дополнительный key image $inline$ совпадёт с одним из сохраненных, то это будет означать, что данная транзакция является исходящим платежом Боба. Аудитор уменьшит баланс на номинал соответствующего входа.

Таким образом, Аудитор, обладая набором ключей $\{v, S, d\}$ сможет распознать в блокчейне входящие и исходящие переводы Боба и восстановить его корректный баланс. При этом потратить средства Аудитор не сможет, т.к. без секретного spend-ключа $inline$ он не сможет вычислить основной key image $inline$ .

Задача решена.

Кольцевая подпись

Применив идеи из работы [16], автору удалось уменьшить размер подписи по сравнению с CryptoNote: теперь, для каждого входа в подписи хранится только $N_{mixins} + 1$ скаляр (рис. 5.3).

_{Рис. 5.3. Сравнение размеров кольцевой подписи в схеме AS и CryptoNote}

Таким образом, размер подписи уменьшается почти вдвое.

Рассмотрим вычислительную сложность ее проверки. Схема проверки подписи представлена на рис. 5.4.

_{Рис. 5.4. Схема проверки кольцевой подписи в AS}

Этот алгоритм очень похож по структуре на используемый в CryptoNote (см. рис. 4.5.4). Проверка осуществляется раздельно для каждого входа и состоит в последовательном вычислении значений $inline$ , $inline$ , $inline$ , $inline$ для всех выходов, использованных для подмешивания в данном входе. В результате, цикл из $inline$ должен замкнуться и величина $c_{n+1}$ должна совпасть с $inline$ , в этом случае подпись считается действительной.

Вычислительная сложность алгоритма определяется шестью операциями скалярного умножения и одним вычислением хеш-фукнции $inline$ на итерацию, число который есть произведение $N_{inputs} * N_{mixins}$ .

Сравнение с CryptoNote по данным и вычислительной нагрузке

Размер адреса увеличивается на 50%, т.к. адрес теперь представляет совокупность трех открытых ключей: , а не двух .
Кодированное представление адреса увеличится примерно на столько же: например, стандартный Zano-адрес, содержащий два открытых ключа, занимает 97 символов:
```
ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwj2q99bmz7t
```
Аналогичный Zano-адрес, содержащий три открытых ключа будет иметь длину порядка 141 символа:
```
ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2nP4HxSPDpuLHvizpwjcenhnGbhpJFLk8vkhJywHCcht4d9EKA7CHHav1H6QPpB1cLsTvPfj
```
Размер каждого выхода увеличивается на дополнительный стелс-адрес $inline$ — 32 байта.
Размер каждого входа увеличивается на дополнительный key image $\ddot I$ — 32 байта.
Размер кольцевой подписи меньше, чем в CryptoNote:
$S = 32 * (N_{mixins} + 1) N_{inputs}$
Вычислительная сложность выше, чем в CryptoNote:
$O(*) = N_{inputs} * 6 * N_{mixins}$
$O(H_p) = N_{inputs} * N_{mixins}$

6. Вариант 3/3. Аудит через ограничение на подмешивание выходов

Рассмотрим еще один способ реализации аудита в CryptoNote.

Атрибут выхода mix_attr

В проекте Zano, являющимся наследником CryptoNote, у выхода транзакции появился дополнительный атрибут mix_attr размером 8 бит, и правило ядра, ограничивающее использование выходов в подмешивании, в зависимости от его значения.

Структуру выходов CryptoNote и Bytecoin (рис. 4.2) мы можем теперь дополнить таким образом (рис. 6.1.).

_{Рис. 6.1. Сравнение структуры данных для выходов транзакций CryptoNote, Zano и Bytecoin Amethyst}

Правило ядра, ограничивающее подмешивание в зависимости от mix_attr, таково:

Если mix_attr = 0, то ограничений нет. Данный выход может использоваться для подмешивания с другими выходами в любых комбинациях. Это — значение по-умолчанию.
Если mix_attr = 1, то данный выход может быть потрачен только непосредственно, без подмешивания, и не может быть использован для подмешивания к другим выходам.
Если mix_attr ≥ 2, то данный выход может быть потрачен только при подмешивании других, при этом общее число использованных выходов не должно быть меньше величины mix_attr.

Главной особенностью этого нововведения является п. 3, что позволяет увеличить untraceability (неотслеживаемость связей) за счет исключения ситуаций, когда выход, уже использованный в подмешивании, тратится его владельцем непосредственно (это подробно рассмотрено в [19]).

Однако, в контексте данной статьи, нас будет интересовать п. 2, то есть ситуация, когда mix_attr = 1 и выход, помеченный таким образом, может быть потрачен только непосредственно. Это ограничение проиллюстрировано на рис. 6.2.

_{Рис. 6.2. Иллюстрация ограничения. Сверху: input #0 ссылается только на output #0 с mix_attr = 1 (непосредственная трата) — допустимая ситуация.Снизу: input #1 ссылается на три выхода: output #2 с mix_attr = 1 и еще на output #1 и output #3 — недопустимая ситуация}

Так как output #2 имеет mix_attr = 1, то он не может быть смешан с другими выходами, вне зависимости от их значений атрибута mix_attr. Он может быть только потрачен непосредственно, как output #0.

Эту особенность можно использовать для организации аудита.

Аудит при помощи mix_attr = 1

Как было отмечено в разделе 3, если в рамках оригинального протокола CryptoNote аудитор Ден получит от Боба секретный ключ $inline$ , он сможет распознать входящие транзакции, но не сможет распознать исходящие, поэтому точный расчет баланса невозможен.

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

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

Схема работы будет выглядеть следующим образом (рис. 6.3).

_{Рис. 6.3. Аудитор с помощью секретного view-ключа Боба определяет входящие и исходящие транзакции}

Боб сообщает Алисе свой публичный адрес $inline$ , а также просит ее во всех выходах, адресованных ему, поставить атрибут mix_attr в значение 1 (ниже рассмотрим, как это можно реализовать технически).
Боб передает аудитору Дену свой секретный view-ключ $inline$ .
Алиса отправляет Бобу транзакцию по обычной схеме CryptoNote. В выходах, адресованных Бобу она ставит mix_attr = 1.
Ден сканирует все транзакции в блокчейне и с помощью секретного view-ключа Боба проверяет для каждого выхода $P_i \stackrel{?}{=} P’_i = H_s(v R, i) G + S$ (где $inline$ — порядковый номер выхода, $inline$ — открытый spend-ключ Боба). Если равенство выполняется, то данный выход адресован Бобу.
Ден убеждается, что mix_attr == 1, добавляет данный выход в список и увеличивает баланс на величину номинала выхода.
Ден также проверяет все входы всех транзакций, и если один из входов ссылается на UTXO Боба из списка, то это означает, что данная транзакция — исходящий платеж Боба. Благодаря ограничению mix_attr = 1, данных вход не может подмешивать другие выходы, а значит он тратит выход Боба непосредственно, и Ден может быть уверен, что это исходящий платеж Боба.Ден уменьшает баланс на величину номинала входа.

Таким образом, Ден сможет рассчитать корректный баланс кошелька Боба, не получая доступа к его секретному spend-ключу $inline$ .

Особенности схемы

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

Один из вариантов решения — введение адресов особого типа, содержащих те же два открытых ключа $inline$ , но упакованных отличным от стандартного образом. Алиса, отправляя средства на адрес такого типа, будет знать о необходимости установить mix_attr = 1 для соответствующих выходов.

Особенность 2. Использование адресов особого типа не обязывает Алису устанавливать нужное значение атрибута для выходов. Она может отправить средства не сделав этого, однако, это будет сразу же выявлено как Бобом, так и аудитором Деном.

Особенность 3. В данной схеме возможность аудита достигается ценой предельного уменьшения untraceability (неотслеживаемости связей). Это не представляет особой проблемы в случае, если возможность аудита предоставлена неограниченному кругу лиц. Например, благотворительный фонд может опубликовать адрес для пожертвований вместе с секретным view-ключом, благодаря чему любой желающий сможет выступить в качестве аудитора и рассчитать актуальный баланс его кошелька. Важно, что при этом анонимность входящих переводов остается стандартной для CryptoNote (можно использовать большое число $N_{mixins}$ ). Однако, анонимность исходящих платежей будет ограничена невозможностью подмешивать произвольные выходы.

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

Большими достоинствами этого варианта являются простота реализации и отсутствие дополнительной нагрузки по вычислениям и данным.

7. Заключение

Мы рассмотрели три варианта добавления возможности проведения аудита в протокол CryptoNote: Bytecoin Amethyst, теоретическая схема AS от Anton Sokolov и использование mix_attr (обозначим как MA).

Относительное изменение размера кольцевой подписи для всех вариантов, кроме Bytecoin (BCN), не зависит от $N_{inputs}$ , поэтому рассмотрим $N_{inputs} = 1$ (минимальный) и $N_{inputs} = 3$ (рис. 7.1).

_{Рис. 7.1. Сравнение размеров кольцевой подписи при и для всех рассмотренных вариантов}

Примечание. $N_{inputs}$ — число входов в транзакции, $N_{mixins}$ — число выходов, ассоциированных с каждым входом транзакции. Если $N_{mixins} > 1$ то это означает, что для увеличения untraceability каждый вход ссылается более чем на один выход какой-то другой транзакции и при этом нельзя установить, какой из них реальный.

Лучший результат показывает схема AS, давая уменьшение размера кольцевой подписи в широком диапазоне числа подмешиваемых выходов ( $N_{mixins}$ ). Bytecoin также дает хороший результат при $N_{mixins} \ge 3$ (как уже было отмечено, в Bytecoin Amethyst для повышения untraceability было введено ограничение на минимальное число $N_{mixins}$ равное 3).

Схема MA никаких улучшений в части размера кольцевой подписи не предлагает.

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

$inline$

Имеем следующую картину (рис. 7.2).

_{Рис. 7.2. Сравнение увеличения вычислительной сложности проверки кольцевой подписи ()}

При прямой трате средств ( $N_{mixins} = 1$ ) схемы AS и Bytecoin требуют существенно большего объема вычислений для проверки подписи.

При подмешивании выходов ( $N_{mixins} > 1$ ) схема Bytecoin Amethyst выглядит предпочтительнее AS, однако последний рассмотренный вариант MA остается непревзойденным.

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

_{Рис. 7.3. Сравнение всех рассмотренных схем}

Bytecoin сохраняет удобную для конечного пользователя длину адреса, в то время как схема Anton Sokolov увеличивает его на 50%. Это не влияет непосредственно на размер блокчейна (хотя адрес отправителя в зашифрованном виде может передаваться в extra транзакции при желании последнего, например) и вычислительную сложность, однако незначительно влияет на удобство использования. В схеме MA размер адреса остается равным 64 байтам, однако требуется способ отличать адреса, предназначенные для аудита, от обычных.

Варианты реализации аудита Bytecoin и AS подразумевают добавление одной точки (32 байт) к каждому выходу транзакции, однако, размер входа остается неизменным только для Bytecoin.

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

Схема AS, напротив, описана строго и предложена к обсуждению в криптосообществе [17].

Схема MA не имеет строго описанного формального доказательства, однако, в силу ее крайней простоты, оно представляется излишним.

Аудит кошельков в CryptoNote