Три способа аудита кошельков в CryptoNote

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

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

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

Что такое CryptoNote?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зафиксировано большое простое число q = 2²⁵⁵ - 19.

1. Все операции происходят в целых числах в конечном поле F_q вычетов по модулю q.
   
2. Задана эллиптическая кривая над полем F_q, обозначаемая E/F_q:

   −x²+y²= 1 +dx² y², где d = −121665/121666 (отношение вычисляется в F_q и является целым числом).

   Важным является факт ее симметрии относительно x и y.
   
3. Над множеством точек кривой геометрически определена операция, для любых двух точек дающая третью: F(A, B) = C, условно называемая “сложением”, и задан нейтральный элемент, как точка, лежащая в бесконечности (это подробно рассмотрено здесь). Эта операция не выводит за пределы множества, обладает ассоциативностью, коммутативностью и наличием обратного элемента, благодаря чему все точки кривой вкупе с ней образуют абелеву группу, обозначаемую E(F_q).
   Порядок этой группы (число всех точек): #E(F_q)=2^cl, где с = 3 (кофактор) и l=2²⁵²+27742317777372353535851937790883648493.
   
4. Каждая точка кривой задается своими координатами (x, y). Поскольку координаты связаны уравнением кривой, это представление избыточно, и поэтому при реализации криптографических функций для экономии используется только координата y, кодируемая как 256-битное число.
   x-координата, в соответствии с симметричностью кривой (см. уравнение), может быть только одним из двух вариантов, выбор которого кодируется как старший бит числа, представляющего y-координату.
   
5. Зафиксирована специальная точка кривой G = (x, −4/5). Точка задается y-координатой, из двух возможных вариантов x выбирается положительный.
   
6. Сложение (см. п. 3) точки G с самой собой n раз определяет операцию умножения на целое число, образующую замкнутую мультипликативную группу G, порядок которой меньше, чем E(F_q):

   #G< #E(F_q), при этом #G=l=2²⁵²+27742317777372353535851937790883648493.

7. Открытый ключ X — это точка эллиптической кривой, принадлежащая группе G: X ∈ G
8. Секретный ключ x, или скаляр, соответствующий открытому ключу X — это такое целое число, что:

   X = x * G, x ∈ [1; l-1]

   Секретный ключ, также как и открытый (см. выше), кодируется как 256-битное число.
   
9. Определена основная хеш-функция H (в коде и других источниках обозначается как cn_fast_hash). Она вычисляет 32-байтный хеш по произвольному набору данных:

   H : {0, 1} * → [0,2²⁵⁶-1]

10. Хеш-функция H_s (s означает scalar) по произвольным данным выдает число, являющееся скаляром, т.е. валидным секретным ключом:

    H_s : {0,1} * → [1; l-1]

    H_s может быть реализована тривиально через H:

    H_s(x)= H(x) + 1 mod l

11. Хеш-функция H_p (p означает point — точка кривой) по произвольным данным выдает элемент группы G, то есть, валидный открытый ключ:

    H_p : {0,1} * → G

    Реализация этой хеш-функции представляет определенную сложность по той причине, что во-первых, не любой набор 256 бит можно декодировать в точку эллиптической кривой (см. п. 4), а во-вторых, не любая точка кривой принадлежит группе G (см. п. 6).
    Одним из тривиальных способов реализации H_p является последовательное хеширование данных H(H(...H(x)...)) до тех пор, пока результат не станет возможным декодировать в точку XG.
    В CryptoNote используется более сложный и эффективный подход, реализованный в виде функции ge_fromfe_frombytes_vartime, который подробно рассмотрен в этой работе.
    Определим функцию, детерминированно преобразующую произвольные 256 бит в элемент группы G как:

    to_point :[0,2²⁵⁶-1] → G

    В CryptoNote хеш-функция H_p реализована так:

    H_p(x) = to_point( H(x) )

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

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

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

1. У Боба есть пара закрытых ключей (v, s). Он вычисляет свой адрес как пару соответствующих открытых ключей (V, S) и опубликовывает его или отправляет Алисе.
2. Алиса выбирает случайный секретный ключ транзакции r и вычисляет открытый ключ R = r * G, который записывает в специальное поле extra транзакции.
3. Для каждого выхода Алиса вычисляет стелс-адрес (one-time destination key):
   
   P_i = H_s(r * V, i) * G + S, где i — порядковый номер выхода.
   
   
4. Алиса подписывает и отправляет транзакцию.

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

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

5. Используя свой секретный ключ v, Боб вычисляет для каждого выхода P’_i = Hs(v * R, i) * G + S (где i — порядковый номер выхода, S — открытый spend-ключ Боба).

Если P’_i == P_i, то это означает, что он является получателем данного выхода и может его потратить, вычислив соответствующий секретный ключ.
Поэтому Боб увеличивает баланса своего кошелька на номинал данного выхода.

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

6. Боб, используя свои секретные ключи (v, s), вычисляет закрытый ключ x_i = H_s(v * R, i) + s к стелс-адресу P_i, то есть P_i = x_i * G.
   
   

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

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

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

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

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

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

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

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

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

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

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

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

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

P’_i = H_s(r * V, i) * G + S

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

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

Вычислить целевой адрес (V, S) по выходу, даже зная r, нельзя.

4. Вариант A: Bytecoin Auditable Coins

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

7 февраля 2018 года разработчики выпустили версию 3.4.0 Amethyst, содержащую ряд улучшений и изменений CryptoNote, которые мы сейчас рассмотрим.

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

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

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

1. tx.version < amethyst, legacy address;
2. tx.version >= amethyst, legacy address;
3. tx.version >= amethyst, amethyst address.

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

4.1. tx.version < amethyst, legacy address

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

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

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

r = H_s(h_t, v_s), где h_t = H(tx.inputs, tx.version)

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

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

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

1. Алиса сканирует транзакции в блокчейне и ведет учет входящих платежей при помощи секретного view-ключа v, как было описано в разделе 3, и увеличивает баланс.
2. Также для каждого выхода каждой транзакции Алиса перебирает все адреса (V, S) на которые когда-либо осуществлялись переводы и вычисляет:

   P’_i = H_s(r * V, i) * G + S

3. Если P’_i = P_i, то данный выход является исходящим платежом Алисы на адрес (V, S) и она уменьшает баланс.

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

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

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.

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

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

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

где:

o_i = H(h_t, v_s, i) (обозначается в коде как output_seed),

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

4.3. tx.version >= amethyst, legacy address

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

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

1. Вычисляет h_t = H(tx.inputs, tx.version), затем для каждого выхода i:
2. D_i = H_s(h_t, v_s, i) * G (в коде обозначается как output_shared_secret)
3. P_i = S + H_s(D_i, h_t, i) * G
4. Q_i = H_s(h_t, v_s, i) * V (при этом Q_i = v * D_i, однако view-ключ v получателя неизвестен)
5. Пара (P_i, Q_i) — открытые ключи выхода i.

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

6. Для каждой транзакции вычисляет h_t = H(tx.inputs, tx.version), затем для каждого выхода i:

7. D_i = v^-1 * Q_i

8. S’ = P_i - H_s(D_i, h_t, i) * G

9. Если S’ совпадает с открытым ключом S Боба, то этот выход предназначен ему и он увеличивает баланс своего кошелька на соответствующий номинал.

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

10. Используя свои секретные ключи v и s, вычисляет секретную часть Pi:
D_i = v^-1 * Q_i
x_i = s + H_s(D_i, h_t, i), при этом легко видеть, что P_i = x_i * G (см. п. 3)

11. Боб рассчитывает key image: I = x_i * H_p(P_i) и записывает его, номинал и ссылку на соответствующий выход во вход своей транзакции для Кэрол.

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

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

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

14. D_i = H_s(h_t, v_s, i) * G

15. S = P_i - H_s(D_i, h_t, i) * G

16. V = H_s(h_t, v_s, i)^-1 * Q_i

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

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

4.4. tx.version >= amethyst, amethyst address

Константа H

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

H = y * G, где y — неизвестное число.

Например, можно задать H так, как предлагается тут:

H = H_p(G) = to_point( cn_fast_hash(G) )

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

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}}};

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

Поскольку H принадлежит группе G, то можно сказать, что H так же порождает группу G, как и базовая точка G.

Это означает, что ∀ x ∈ [1,p - 1], x *H ∈ G 

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

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

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

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

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

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

1. Вычисляется δ = H_s(A + s * H, i), Δ = δ * G
2. S = A + s * H + Δ
3. V = v * S = v * (A + s * H + Δ) = v * (A + s * H) + δ * V
4. пара (V, S) = (v * S, S) является i-ым публичным адресом данного аккаунта.

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

• A
• V
• s * H
• v * (A + s * H)

Величины s * H и v * (A + s * H) предрассчитываются при создании аккаунта и рассматриваются как безопасные в том смысле, что зная их, нельзя вычислить s или v.

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

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

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

Вычисляет h_t = H(tx.inputs, tx.version), затем для каждого выхода i:

1. P_i = H_s( H_p(h_t, v_s, i), h_t, i )^-1 * S
2. Q_i = H_s( H_p(h_t, v_s, i), h_t, i )^-1 * V + H_p(h_t, v_s, i)
3. Пара (P_i, Q_i) — открытые ключи выхода i.

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

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

1. Для каждого выхода i, используя секретный view-ключ v, Боб вычисляет:

   K = H_p(h_t, v_s, i) = Q_i - v * P_i (output_shared_secret в коде)

2. S’ = H_s(K, h_t, i) * P_i
3. После чего пытается найти S’ в списке своих адресов. Если находит, то это означает, что данный выход переводит деньги Бобу. Он увеличивает баланс для соответствующего адреса.

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

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

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

1. K = H_p(h_t, v_s, i) = Q_i - v * P_i (output_shared_secret в коде)
2. x_i = H_s(K, h_t, i)^-1 * (a + δ)
3. X_i = x_i * G + H_s(K, h_t, i)^-1 * s * H
4. Вычисляет key image I = x_i * H_p(X_i)
5. Боб уменьшает баланс, относящийся к его адресу S = H_s(K, h_t, i) * P_i на величину номинала соответствующего выхода.
6. Боб формирует выходы транзакций, подписывает ее и отправляет.

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

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

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

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

Происходит это следующим образом:

Предположим, что Алиса передала vs и s * H Кэрол. Тогда Кэрол:

1. Восстановит секретные ключи v и a, восстановит список адресов Алисы.
2. Будет сканировать блокчейн и для каждого выхода i каждой транзакции будет определять, является ли он входящим платежом, пытаясь найти

   S’ = H_s(Q_i - v * P_i, h_t, i) * P_i

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

   S = P_i * H_s(H_p(h_t, v_s, i), h_t, i)
   V = (Q_i - H_p(h_t, v_s, i)) * H_s(H_p(h_t, v_s, i), h_t, i)

   и уменьшит баланс соответствующего адреса Алисы на величину номинала входа.

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

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

• A
• V
• s * H
• v * (A + s * H)

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

• A
• v
• s * H

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

• a
• v
• s * H

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

• v_s
• s * H

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

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

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

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

Таким образом, если в транзакции N_inputs входов, каждый из которых ссылается на N_mixins выходов, то общий размер подписи в байтах можно выразить как:

S = 32 * 2 * N_mixins * N_inputs

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

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

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

S = 32 * ((3 + N_mixins) * N_inputs + 1)

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

Видно, что обе функции растут пропорционально произведению N_mixins * N_inputs

Чтобы сравнить различие размеров подписи транзакции более наглядно, рассчитаем их для наиболее характерных величин N_mixins и N_inputs и составим таблицу (рис. 4.5.2).

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

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

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

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

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

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

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

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

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

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

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

1. Для каждой пары значений r_j и c_j при помощи key-image входа I и открытого ключа P_j очередного выхода, на который ссылается данный вход, вычисляются величины:

   L_j = r_j * G + c_j * P_j
   R_j = r_j * H_p(P_j) + c_j * I

   (при этом индекс j пробегает значение от 0 до N_mixins)
   
2. Вычисляется сумма c всех c_j.
   
3. Вычисляется хеш c`=Hs(tx_prefix_hash, L₀ .. L_n, R₀ .. R_n)
   где tx_prefix_hash — хеш префиксной части транзакции (без подписи).
   
4. Проверяется равенство c` = c. Если оно выполняется, то кольцевая подпись считается действительной.

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

Каждое вычисление L_j и R_j требует по два скалярных умножения. Число пар L_j, R_j соответствует числу подмешиваемых выходов N_mixins для каждого входа. Поэтому имеем:

O(*) = N_inputs * 4 * N_mixins

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

O(H_p) = N_inputs * N_mixins

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

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

1. В хеш-буфер записывается префиксный хеш транзакции (без подписи).
2. Для каждого входа i (строка подписи на рисунке):
1. Вычисляется X.
2. Последовательно вычисляются значения пар (Y₀, Z₀) ... (Y_n, Z_n), где n = N_mixins
3. Набор (pp, X, Y_n, Z_n, P₀ ... P_n), где P_j — открытые ключи выходов, на которые ссылается данный вход, добавляется в хеш-буфер.
3. Вычисляется H_s по всем данным хеш-буфера и результат сравнивается с величиной c₀.
   Подпись считается действительной, если равенство соблюдается.

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

Каждое вычисление Y_j и Z_j требует по два скалярных умножения, плюс вычисление X требует трех скалярных умножений. Число пар Y_j, Z_j соответствует числу подмешиваемых выходов N_mixins для каждого входа. Поэтому имеем:

O(*) = N_inputs * (3 + 4 * N_mixins)

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

O(H_p) = N_inputs * (N_mixins + 1)

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

O(total) = 130 * O(*) + 15 * O(H_p)

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

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

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

Подытожим:

1. Размер каждого выхода увеличивается на открытый ключ Q — 32 байта.
   
2. Размер кольцевой подписи варьирует в сравнении с размером подписи CryptoNote в зависимости от числа подмешиваемых выходов (при большом их числе оказывается меньше):

   S = 32 * ((3 + N_mixins) * N_inputs + 1)

3. Вычислительная сложность выше, чем в CryptoNote и значительно зависит от числа подмешиваемых выходов:

   O(*) = N_inputs * (3 + 4 * N_mixins)
   O(H_p) = N_inputs * (N_mixins + 1)

5. Исследования аудита в CryptoNote от Anton Sokolov

Осенью 2019 года на Medium.com была опубликована серия эссе (1, 2, 3, 4, 5, 6) о проблеме аудита в CryptoNote и возможных способах ее решения под авторством Anton Sokolov. В ней с теоретических позиций рассматриваются несколько вариантов модификации оригинального протокола таким образом, чтобы решить задачу аудита для третьей стороны.

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

Примечание: для единообразия изложения spend-ключи и далее будут обозначаться буквами s и S, view-ключи — буквами v и V, несмотря на то, что в оригинальных работах используются b, B и a, A соответственно.

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

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

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

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

1. Боб опубликовывает свой адрес, поэтому Алиса знает его открытые ключи V, S и D.
   
   
2. Так же, как и в CryptoNote, Алиса выбирает случайный секретный ключ транзакции r и вычисляет открытый ключ R = r * G, который записывает в специальное поле extra транзакции.
   
   
3. Для каждого выхода Алиса вычисляет не один, а два стелс-адреса P и T. Первый рассчитывается аналогично CryptoNote:

   P = H_s(r * V) * G + S

   Второй иначе:

   T = H_s(r * D) * D

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

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

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

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

5. Используя свой секретный view-ключ v, Боб стелс-адрес P каждого выхода сравнивает с точкой:
P’ = H_s(v*R)*G+S
(этот шаг аналогичен CryptoNote)

6. В случае, если равенство выполняется, это означает, что данный выход адресован Бобу. Он увеличивает свой баланс на величину номинала выхода.

7. При необходимости перевести полученные средства Кэрол, Боб, используя свои секретные spend- и audit-ключи s и d, вычисляет два key image: I и Ï. Первый — аналогично CryptoNote:
I = x * H_p(P)
и дополнительный:
t = H_s(d*R)*d
Ï = t * H_p(P)
Затем записывает их, номинал и ссылку на соответствующий выход во вход своей транзакции для Кэрол.

8. Затем Боб формирует выходы транзакции для Кэрол, уменьшает свой баланс пропорционально потраченным выходам, подписывает транзакцию и отправляет.

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

Аудит

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

9. Для каждого входящего платежа Аудитор будет рассчитывать и запоминать дополнительный key image Ï в локальном хранилище:
t = H_s(d*R)*d
Ï = t * H_p(P)

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

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

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

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

Применив идеи из этой работы, автору удалось уменьшить размер подписи по сравнению с CryptoNote: теперь, для каждого входа в подписи хранится только N_mixins + 1 скаляр (рис. 5.3).

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

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

Этот алгоритм очень похож по структуре на используемый в CryptoNote (см. рис. 4.5.4). Проверка осуществляется раздельно для каждого входа и состоит в последовательном вычислении значений u_j, L_j, R_j, c_j для всех выходов, использованных для подмешивания в данном входе. В результате, цикл из c_j должен замкнуться и величина c_n+1 должна совпасть с c₀, в этом случае подпись считается действительной.

Вычислительная сложность алгоритма определяется шестью операциями скалярного умножения и одним вычислением хеш-фукнции Hp на итерацию, число который есть произведение N_inputs * N_mixins.

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

1. Размер адреса увеличивается на 50%, т.к. адрес теперь представляет совокупность трех открытых ключей: {V, S, D}, а не двух {V, S}.
   Кодированное представление адреса увеличится примерно на столько же: например, стандартный Zano-адрес, содержащий два открытых ключа, занимает 97 символов:
   ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2
nP4HxSPDpuLHvizpwj2q99bmz7t
   Аналогичный Zano-адрес, содержащий три открытых ключа будет иметь длину порядка 141 символа:
   ZxD5UBX5PM3RTsEtTRd9ATUFxXyocoQzDRk3baVBahuWQJRK8QHTUT9GQM7jk7GoedK5B2
nP4HxSPDpuLHvizpwjcenhnGbhpJFLk8vkhJywHCcht4d9EKA7CHHav1H6QPpB1cLsTvPfj
   
2. Размер каждого выхода увеличивается на дополнительный стелс-адрес T — 32 байта.
   
3. Размер каждого входа увеличивается на дополнительный key image Ï — 32 байта.
   
4. Размер кольцевой подписи меньше, чем в CryptoNote:

   S = 32 * (N_mixins + 1) * N_inputs

5. Вычислительная сложность выше, чем в CryptoNote:

   O(*) = N_inputs * 6 * N_mixins
   
   O(H_p) = N_inputs * N_mixins

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Боб сообщает Алисе свой публичный адрес (V, S), а также просит ее во всех выходах, адресованных ему, поставить атрибут mix_attr в значение 1 (ниже рассмотрим, как это можно реализовать технически).
   
2. Боб передает аудитору Дену свой секретный view-ключ v.
   
3. Алиса отправляет Бобу транзакцию по обычной схеме CryptoNote. В выходах, адресованных Бобу она ставит mix_attr = 1.
   
4. Ден сканирует все транзакции в блокчейне и с помощью секретного view-ключа Боба проверяет для каждого выхода P_i == P’_i = Hs(v * R, i) * G + S (где i — порядковый номер выхода, S — открытый spend-ключ Боба). Если равенство выполняется, то данный выход адресован Бобу.
   Ден убеждается, что mix_attr == 1, добавляет данный выход в список и увеличивает баланс на величину номинала выхода.
   
5. Ден также проверяет все входы всех транзакций, и если один из входов ссылается на UTXO Боба из списка, то это означает, что данная транзакция — исходящий платеж Боба. Благодаря ограничению mix_attr = 1, данных вход не может подмешивать другие выходы, а значит он тратит выход Боба непосредственно, и Ден может быть уверен, что это исходящий платеж Боба. Ден уменьшает баланс на величину номинала входа.

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

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

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

Один из вариантов решения — введение адресов особого типа, содержащих те же два открытых ключа (V, S), но упакованных отличным от стандартного образом. Алиса, отправляя средства на адрес такого типа, будет знать о необходимости установить 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).

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

Лучший результат показывает схема AS, давая уменьшение размера кольцевой подписи в широком диапазоне числа подмешиваемых выходов (N_mixins). Bytecoin также дает хороший результат при N_mixins >= 3 (как уже было отмечено, в Bytecoin Amethyst для повышения untraceability было введено ограничение на минимальное число N_mixins равное 3).

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

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

O(total) = 130 * O(*) + 15 * O(H_p)

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

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

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

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

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

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

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

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

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