Воплощая Конфиденциальность
Настало время рассказать о средствах конфиденциальности и планах Decred. Наши средства конфиденциальности направлены на простоту, адаптируемость и креативность.
Вместо того чтобы идти по пути таких сосредоточенных на конфиденциальности разработок, как кольцевая подпись, zk-SNARKs или Mimblewimble, мы решили применить подход mixnet, проведя интеграцию mixnet с нашей системой управления Proof-of-Stake (“PoS”). На текущий момент уже больше 50% всего Decred в обращении участвует в PoS, который требует постоянного потока покупки тикетов. Существующий поток транзакций, уникальный для Decred, выступает в качестве естественной основы для mixnet. Подход с использованием системы управления PoS от Decred обеспечивает сценарий «двух зайцев одним выстрелом»: стейкхолдеры приобретают анонимность и одновременно создают существенный фоновый объем, с которым они и не стейкхолдеры могут «смешивать» обычные транзакции. Основные моменты по mixnet от Decred:
- Он основан на протоколе CoinShuffle++ из «P2P смешивание и несвязываемые транзакции в Биткоине» (“P2P Mixing and Unlinkable Bitcoin Transactions”) от Руффинга, Морено-Санчеза и Кейта.
- Процесс смешивания интегрирован в процесс покупки тикета, так что стейкхолдеры, владеющие кошельками для покупки тикетов, могут покупать их анонимно.
- В дополнение к номиналу (denomination), основанному на текущей стоимости тикета, меньшие фиксированные номиналы используются для размена от смешивания и обычных транзакций.
- Размен от процесса смешивания требует специальной обработки, предотвращающей установление связи с неизрасходованным выходом транзакции (“UTXO”).
- При использовании конфиденциальности хранилище ончейн транзакций увеличивается примерно в 12 раз.
- Первоначальная версия имеет интерфейс командной строки (“CLI”) и поддерживает только транзакции соло-стейкеров и нестейковые транзакции.
В оставшейся части этой статьи я расскажу о том, чем мотивированны наши решения, которые привели нас к этой системе, а также подробнее о том, как система работает, и какие шаги последуют после выпуска первоначальной версии.
Мотивация
Работа над приватностью велась тайно с середины 2017 года, что неплохо было бы разъяснить. На тот момент я заметил, что и Monero и Zcash, несмотря на существенную конфиденциальность, имели, на мой взгляд, серьезную проблему. Конкретнее — у них отсутствует возможность отбрасывания прошлых транзакций из заполненных нод (т.е. обрезки) ввиду невозможности понять израсходован выход транзакции (“TXO”) или нет. Хотя ясно, что оба проекта не считали это особой проблемой, я подумал, что это нанесет ущерб устойчивости в более долгосрочной перспективе. Блокчейну будет трудно оставаться долгосрочным средством накопления, если он будет слишком «раздут» для скачивания и быстрого копирования, что также снизит его безопасность. Оказалось, что большинство представителей блокчейн пространства точно так же не разделяли этого мнения, поэтому я счел, что лучше мне придержать свою критику, дабы не направить кого-нибудь другого в сторону разработки решения для этой проблемы.
Помимо обеспокоенности тем, что устранение обрезки было плохим долгосрочным инженерным решением, которое способно негативно отразиться на устойчивости, даже несмотря на всю пользу для краткосрочной приватности, я был озадачен сложностью двух других подходов. Кольцевая подпись несет в себе умеренную сложность, а zk-SNARKs — высокую, что и подвигло меня найти более простой подход, который бы не устранял обрезку. Вначале я планировал внедрить TumbleBit из статьи «TumbleBit: недоверенный анонимный платежный хаб — конкурент Биткоина» (“TumbleBit: An Untrusted Bitcoin-Compatible Anonymous Payment Hub”) авторства Хейльмана, Аль-Шенибра, Балдимтси, Скафуро и Голдберга. В период между зимой 2017 и весной 2018 Михаил Белопухов, разработчик с весомым опытом работы над криптографическими инженерными проектами, внедрил TumbleBit на Go. Как только начальное внедрение было завершено и настало время интегрировать код, я узнал о дырах в TumbleBit, а именно, что смешивающие сервера подвержены атакам Denial-of-Service (“DoS”), и что в качестве контрмеры против этого (анонимные ваучеры на комиссию) пришлось бы добавлять больше кода и большую сложность. Несмотря на то, что код TumbleBit не был интегрирован с Decred, мы выкладываем этот код в интересах общественности.
В тот момент я подумал, что лучше взглянуть на протокол CoinShuffle++ из «P2P смешивание и несвязываемые транзакции в Биткоине» (“P2P Mixing and Unlinkable Bitcoin Transactions”) от Руффинга, Морено-Санчеза и Кейта, который показался мне намного менее сложным, чем TumbleBit. CoinShuffle++ основывается на общих криптографических элементах, напр. обмене ключами, ключах сеанса связи, хеш функциях, подписях и арифметике конечной точности. После подробного изучения CoinShuffle++ стало ясно, что он значительно проще и более устойчив к DoS, чем TumbleBit, поэтому мы развернули свою деятельность в сторону CoinShuffle++. Простой код и простые элементы гарантируют меньшую вероятность того, что что-то может пойти не так. Ввиду ограничений инженерных ресурсов, эта работа началась только в декабре 2018 года, и сейчас, после нескольких месяцев работы, готова к публикации.
CoinShuffle++ работает только с таким компонентом конфиденциальности, как возможность отслеживания, не беря во внимание суммы транзакций. Поскольку CoinShuffle++ не требовалось никаких изменений консенсуса, эта работа могла быть выполнена конфиденциально. Того же нельзя было сказать о техниках обфускации сумм транзакций. Для того чтобы обфусцировать суммы транзакций необходимо провести изменение консенсуса, что в свою очередь должно произойти в качестве части публичного процесса Decred, согласно воле его стейкхолдеров.
Decred построен на постулатах безопасности блокчейна, встроенном управлении и самофинансируемой награде за блок, что делает его превосходным средством накопления. С учетом имеющихся основ, мы намерены встроить средства конфиденциальности для усиления защищенности наших пользователей. Несмотря на то, что от любой публичной процедуры требуется обфуцировать суммы транзакций, я считаю, что вопрос отслеживаемости намного важнее, когда разговор заходит о безопасности стейкхолдеров, которые в итоге заметят существенное улучшение конфиденциальности.
Как это работает
В кошелек Decred был внедрен вариант CoinShuffle++. Хотя существует возможность провести эту процедуру полностью в формате пир-ту-пир (“P2P”), этот формат не учитывает ограничения, вызываемые маршрутизацией через общий доступ в Интернет, поэтому мы создали и сервер, csppserver, и интегрированный в dcrwallet клиент. Для того чтобы лучше понять как работает CoinShuffle++ мы посмотрим на простой пример, иллюстрирующий концепцию всего процесса. В дополнение к тому, что было описано в статье, в кошелек встроена отлаженная обработка номинала и размена, а также кошелек настроен так, чтобы обрабатывать обычные транзакции и покупку тикетов. Существует несколько заметных ограничений описываемой первоначальной версии, поскольку она работает только в режиме CLI, требует конфигурации соло-стейкинга или нестейкинга, и смешивания могут быть отменены взломщиком, способным взломать задачу дискретного логарифма (“DLP”). Ожидается, что приблизительно 12,5% от всего decred в обращении сможет воспользоваться конфиденциальностью уже в течение нескольких месяцев. Конфигурирование dcrwallet для использования конфиденциальности требует небольшого редактирования конфигурации файлов.
CoinShuffle++
CoinShuffle++ — это некастодиальный процесс создания транзакций CoinJoin, при котором выходящие адреса анонимизируются через mixnet. Такая процедура, при которой анонимизируются выходящие адреса, называется DiceMix Light. Она является созданной Руффингом версией процедуры, первоначально предложенной в статье о CoinShuffle++. Обратите внимание, что возникающий CoinJoin передает информацию серверу о том, какие входные данные и адреса размена какому пиру принадлежат, но не о других пирах, участвующих в смешивании. Выходящие адреса полностью анонимизированы, так что ни один пир или сервер не может определить, какой выход какому пиру принадлежит. Смешивания эпизодически случаются в эпохах. Начальная эпоха основной сети (mainnet) установлена на 20 минутах (1200 секундах).
Архитектура
Выбранная нами архитектура клиент-сервера является распространенным подходом к инфраструктуре сети, по большей части, потому что трансляция сетевых адресов означает, что Вы можете не иметь возможности получить прямой доступ к другим пирам, с которыми Вы производите смешивание. Эта проблема очень распространена и сводится к вопросу о переадресации порта и о том, является ли UDP hole punching приемлемым подходом (на наш взгляд он добавляет сложности). К тому же, использование прямого P2P означало бы, что каждый пир мог бы видеть публичный IP каждого другого пира, что не слишком содействует конфиденциальности. Сервер, csppserver, требует доступа JSON-RPC к dcrd, процедуре консенсуса Decred, для подтверждения того, что TXO действительно не израсходованы.
Изначальный csppserver будет располагаться на cspp.decred.org, но также существует возможность запуска Вашего собственного сервера. Запуск Вашего собственного сервера будет иметь ограничения использования, и, поскольку целью является получение как можно большего количества пиров в каждом смешивании, мы не рекомендуем этого делать. У нас в планах воплотить высокодоступность сервера в будущем.
Упрощенный пример DiceMix
Для того чтобы понять как работает протокол DiceMix, наглядным будет рассмотреть упрощенный алгоритм под названием “Secure Sum”. Этот пример использует 3 пира, но несложно расширить этот процесс на случайное количество пиров.
Представьте Алису, Боба и Кэрол — у каждого из них есть какое-то число. Они хотят вычислить сумму всех этих чисел, но ни один из них не хочет, чтобы кто-то из оставшихся (пиров) знал какие числа у других. Алиса разбивает свое число на A1+A2+A3, Боб разбивает свое число на B1+B2+B3, а Кэрол свое на C1+C2+C3. Далее Алиса отправляет А2 Бобу, а А3 Кэрол; Боб отправляет В1 Алисе, а В3 Кэрол; Кэрол отправляет С1 Алисе, а С2 Бобу. Алиса вычисляет А1+В1+С1, Боб вычисляет A2+B2+C2, а Кэрол вычисляет A3+B3+C3, после чего они оповещают друг друга о получившихся частичных суммах. Каждый из них теперь может вычислить сумму всех чисел, сложив частичные суммы, но ни один из них не знает, какое число кому принадлежало (при допущении, что тайная договоренность отсутствует).
Трюк, используемый в вышеуказанном примере, состоит в том, что сумма горизонтальных сумм равняется сумме вертикальных сумм, что становится очевидным, при выписывании всех делений:
Упрощенный пример DiceMix
- Исходные данные каждого участника разделены на части
- Высчитаны вертикальные суммы на каждого участника
- Суммы горизонтальных сумм равны суммам вертикальных сумм
DiceMix добавляет сложности, но основная концепция остается той же. DiceMix подразумевает создание каждым пиром своего вектора порядка адресов выплат, добавление внутренних отступов к каждому компоненту вектора, основанных на парных ключах сеанса связи из процедуры обмена ключами, суммирование векторов каждого пира для создания системы уравнений и решение этой системы уравнений для адресов выплат. Этот прием состоит в том, что внутренние отступы выбираются таким образом, что они отменяются при сложении векторов всех пиров. Как только мы получаем анонимизированный список адресов выплат, с пирами проводится стандартная процедура CoinJoin.
Обработка номиналов и разменов
DiceMix анонимизирует выходящие адреса для транзакции CoinJoin, но он не делает эти выходы неразличимыми. Для того чтобы сделать их таковыми, они должны иметь фиксированный номинал для каждого смешивания. Необходимость фиксированного номинала выхода была отмечена в технической документации CryptoNote в 2012 году, поэтому необходимость идентичных сумм выхода для сохранения конфиденциальности хорошо известна. Номиналы, используемые для Decred — это текущая стоимость тикетов (плюс комиссия) и несколько фиксированных номиналов ниже стоимости тикетов. Стоимость тикета варьируется каждые 144 блока (примерно каждые 12 часов), поэтому этот номинал со временем изменяется. Если стоимость тикета меняется в течение эпохи, смешивание отменяется и пиры записываются на следующее смешивание.
Как часто бывает в мире криптовалют и конфиденциальности, «дьявол кроется в деталях», и размен от смешиваний CoinShuffle++ тому не исключение. CoinShuffle++ хорошо справляется с анонимизацией выходящих адресов, но если размен обрабатывается неаккуратно, могут связаться смешанные и несмешанные UTXO. Во многих случаях выходы размена могут быть связаны со своими входами при проведении анализа частичной суммы, например, сумма сегмента входов равняется 12,34, анонимный выход равняется 10, комиссия 0,001, а размен 2,339. Это означает, что если размен в размере 2,339 включен в качестве входа в анонимизированные выходы, он создает связь между входами, равняющимися 12,34 и анонимизированными выходами, сокращая, либо полностью разрушая конфиденциальность, над которой мы работали. Для устранения этой угрозы размен от смешиваний заливается на отдельный аккаунт кошелька, где он потом смешивается с меньшими номиналами, пока размен не становится меньше, чем самый маленький номинал миксера.
Фиксированные номиналы были выбраны для сбалансирования среднего размера хранилища ончейн транзакций, обеспечения качества смешивания и простоты выполнения умножений. Если мы представим, что номиналы используют основу N и существует M номиналов, в худшем случае получится N-1 выходов из некоторого номинала и M x (N — 1) всех выходов из одного входного размена. Для основы в 10 и размена в 99,999 потребуется до 5 x (10–1) = 45 смешанных выходов, поэтому Вы можете ожидать примерно 22-х кратного увеличения хранилища ончейн транзакций. Мы решили работать с основой в 4 и 8-ью номиналами ниже размера тикетов, поэтому в худшем случае размен потребует 8 x (4–1) = 24 выхода, что создаст 12-ти кратное увеличение ончейн хранилища. Были добавлены 2 дополнительных номинала выше стоимости тикета, но мы ожидаем их ограниченное использование. Самый маленький номинал равен 4⁹ атомов = 0.00262144, а тот, что ниже текущего размера тикета равен 4¹⁶ атомов = 42.94967296.
Ограничения
Указанный начальный код поддерживает только CLI кошелек, dcrwallet, и соло стейкеров, т.е. не работает с провайдерами сервисов голосования (“VSP”) и обычными транзакциями. Мы однозначно намерены поддерживать конфиденциальность GUI кошельков, например, Decrediton, и наладить его работу с VSP. Задача с GUI кошельками лежит в поле взаимодействия с пользователем (“UX”), поскольку процедура смешивания только что полученных платежей или размена требует, чтобы кошелек был разблокирован большее количество времени, например, десятки минут. VSP создают более существенную сложность, поскольку пользователи указывают личные данные при регистрации аккаунта в VSP, и каждый аккаунт имеет фиксированный скрипт мультиподписи 1-of-2. В случае, когда взломщик способен взломать DLP и пассивно записать весь обмен данными между клиентами смешивания и сервером, эти данные могут выдать связи между входами, выходами и разменом. Обратите внимание, что не существует риска вызова таким взломщиком «тихой инфляции» (silent inflation).
