Перевод Проблемы с временем разблокировки Monero

Тема в разделе "Статьи", создана пользователем Mr. Pickles, 8 мар 2021.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    981
    Симпатии:
    246
    TL;DR: В этой последней статье из серии, состоящей из трёх постов, посвящённых времени разблокировки (unlock_time) в Monero, я пытаюсь вникнуть в проблемы, связанные с анонимностью при использовании текущего времени разблокировки, и в то, как можно улучшить ситуацию, зашифровав поле, ограничив его содержимое, настроив возможность выбора участников кольца или полностью удалив всё разом.

    В последних двух постах (пожалуйста, прочтите сначала их) подробно описаны как уязвимости в реализации [1], так и в протоколе [2] поля unlock_time транзакций Monero как для приложений, которые должны верифицировать это поле, так и для основного программного обеспечения Monero. Исследования, проведённые в январе 2020 года специалистом в области обработки данных, Isthmus (в Twitter известным как @ Mitchellpkt0), из Исследовательской лаборатории Monero (#monero-research-lab - IRC-канал на Freenode, который делает обсуждение исследований проще), показали, что параметр unlock_time также не до конца понятен и для многих пользователей Monero. Его использование оставляет информационные следы, которые могут нанести ущерб анонимности пользователей. После публикации соответствующей информации в последних двух статьях в конце апреля этого года мною было написано предложение по внедрению шифрования времени разблокировки, которое позволило бы решить эту проблему, связанную с нарушением анонимности. Тогда это предложение не особо поддержали по причинам, которые я раскрою ниже, и я не стал добиваться его реализации. Части того предложения, соавтором которых стал Isthmus, переработаны в рамках данной статьи. Также я выражаю благодарность коллеге Isthmus, N3ptune, предоставившему необработанные данные.

    Шаблоны использования unlock_time
    Анонимность Monero во многом зависит от неразличимости транзакций, которая не позволяет связывать транзакций друг с другом. Любая характеристика транзакции, раскрывающая что-либо о пользователе или программном обеспечении, которое её создало, снижает уровень анонимности. Одним из примеров может служить статистический анализ времени разблокировки, при котором происходит разделение анонимного пула Monero в зависимости от программного обеспечения и пользователя, создавших транзакцию. Данные, представленные в настоящей статье, были взяты из блоков с 1 000 000 по 2 197 574.

    Было выявлено примерно пять разных шаблонов использования параметра unlock_time:

    1. unlock_time = 0

    - Поведение основного кошелька (и любого другого кошелька, удачно имитирующего его) по умолчанию.

    - Выход, который можно потратить в генезис-блоке, никогда не блокируется.

    - Было зарегистрировано только 12 493 транзакции, где значение параметра было задано выше

    - Пример: e4098567e981e9596f8b2a449c7df24cc77268ff08280b5901b624c2de234202

    ---

    2. unlock_time = {1 … 6, 10, 12, 13, 15}

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

    - В общей сложности в 12 297 транзакциях, примерно 98% случаев использования параметра unlock_time

    - Пример: bf800d30889423fafdf7cde841f1a61d3372667a0efc7c6e8784f220c0dcc3a8

    ---

    3. unlock_time ~ 1 000 000+

    - Значение unlock_time менее 500 000 000 интерпретируется как высота блока

    - 195 транзакций, примерно 2% от всех случаев использования параметра unlock_time на данный момент

    - Пример: 93df46c18742ff6fd0ba86076bd360b0a32cda4f670b9944c9f176d5c9783959

    ---

    4. unlock_time ~ 1 400 000 000

    - Большое значение unlock_time означает время Unix

    - Никаких транзакций в этом диапазоне не зафиксировано!

    - Пример: 012932593e59f21d10b7badc5f0556c1aaaefd60d0ebf05f1637361a66b17273

    ---

    5. unlock_time > 1 400 000 000 000

    - Теоретически эти выходы будут разблокированы в далёком будущем

    - Единственная транзакция со значением 1844674073709551616 была создана Isthmus, и она заблокирована до 292 277 026 596 года.

    - Пример: 2c2762d8817ea4d1cb667752698f2ff7597a051d433043776945669043d908b5

    Isthmus также подготовил следующий график использования unlock_time (ещё два приводятся ниже):

    1.png

    Распределение использования низких значений представляется странным (в верхнем ряду указаны значения unlock_time, в нижнем ряду - количество случаев использования):

    2.JPG

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

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

    Следующая гистограмма наглядно показывает, насколько использование параметра unlock_time соответствует этим нелогичным шаблонам и насколько мала в них доля разумных значений (обведены синим кружком):

    3.png

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

    На следующем графике продемонстрирована разница между значимой высотой блока unlock_time и высотой его вычисления (майнинга), что отражает фактическое количество блоков, на которое заблокирована каждая транзакция:

    4.png

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

    Параметр unlock_time и выбор участников кольца
    Помимо этих кластеров, ещё одну проблему для анонимности пользователей представляют транзакции со значимым параметром unlock_time. В случае с Monero в качестве ложных участников кольцевых подписей выбираются выходы прошлых транзакций, которые хранятся в блокчейне Monero. Процесс выборки должен имитировать поведение при трате выходов. Пользователи, как правило, тратят более «молодые» выходы чаще, чем старые, поэтому при выборке предпочтение отдаётся транзакциям, созданным на большей высоте блока, а не на низкой. Однако при выборке значения параметр unlock_time не вычисляется сверх фактической высоты блока. Предположим, что текущая высота блока составляет 400 000. В соответствии с действующими на данный момент правилами выход со значением unlock_time 350 000, созданный на высоте блока 200 000, обрабатывается так же, как и другой выход, созданный на высоте 200 000, даже если выход со значением unlock_time будет доступен для траты только через 50 000 блоков, в то время как другой выход можно будет потратить через 200 000 блоков. Данное слабое место в алгоритме выбора приводит к утечке информации, позволяя наблюдателю за блокчейном Monero угадать, какой из участников кольцевой подписи является ложным, а кто реальным.

    Решение заключается в том, чтобы учитывать статистическое поведение при выборе по возрасту, связанное с unlock_time, подбирая ложных участников кольца. Возраст траты позволят измерить количество времени, которое проходит между "созреванием" выхода транзакции и его последующим использованием в качестве входа транзакции. Статистические данные о возрасте траты могут быть взяты из прозрачного блокчейна, использующего блокировку по времени, например, из блокчейна Bitcoin, а затем их можно задействовать для эвристического анализа Monero. Данное упущение в алгоритме выбора в настоящее время не представляет собой проблемы, поскольку параметр unlock_time почти не используется.

    Шифрование блокировки по времени
    Грубым решением могло бы стать полное удаления поля. Используется оно редко, но при этом может стать причиной утечки информации. Как вариант, добавление временной блокировки для каждого выхода и ограничение размера поля до более компактного типа данных, например, время шифрования 2-байтового числа с шагом в час и 1-битным флагом для выбора, в зависимости от блока или времени, может значительно уменьшить вероятность вредоносного использования. Кроме того, транзакции с ненулевой блокировкой по времени, которые были созданы в прошлом, могут быть заблокированы в соответствии с правилами консенсуса.

    Более изощрённый подход — это реализация зашифрованных параметров блокировки по времени, которые бы не допускали утечки информации, следов пользователя / программного обеспечения, поскольку шифротекст распределяется равномерно. Значения временной блокировки могут быть зашифрованы аналогично тому, как на этот момент происходит шифрование суммы Monero. Обязательство по нулевой сумме, доказывающее то, что время блокировки истекло, просто добавляется к существующей конструкции кольцевой подписи. Также необходимо представить доказательство Bulletproof для значения временной блокировки в целочисленном диапазоне. Суть этих дополнительных этапов шифрования описана в публикации №65 Исследовательской лаборатории Monero и работе по DLSAG.

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

    Помимо этого игрушечного варианта реализации шифрования временной блокировки с помощью CLSAG, криптограф из #monero-research-lab Саранг Нёзер написал другой вариант реализации на C ++ для CLSAG, текущего алгоритма подписи Monero, и Triptych, алгоритма подписи, который, возможно, будет использоваться в будущем, а на их основе им были созданы следующие тесты, позволяющие сравнить время верификации подписей (3-CLSAG и 3-Triptych являются вариантами по времени разблокировки):

    5.png

    Зашифрованные параметры временной блокировки имеют серьезные недостатки с точки зрения производительности. Помимо значительно увеличивающегося (примерно в 2 раза) времени верификации как в случае с используемым в настоящее время, так и возможным будущим алгоритмом, шифрование также требует дополнительных 64 байта на подпись в транзакции и 32 байта на каждый дополнительный выход, связанный с блокировкой по времени, если она реализуется поверх алгоритма подписи CLSAG. Также возможно значительное увеличение как размера, так и времени верификации доказательства диапазона. Оптимальная схема доказательства диапазона пока ещё не найдена, поэтому нет и конкретных цифр, связанных с воздействием на производительность доказательств диапазона.

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

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

    Я считаю маловероятным наличие каких-либо других недостатков, помимо удвоения размера и времени верификации, при шифровании временной блокировки. До сих пор принцип разработки Monero состоял в отсутствии каких-либо компромиссов в отношении обеспечения самых высоких параметров анонимности и безопасности пользователей по умолчанию. Я считаю, что, если Monero стремится сохранить свой статус доминирующей криптовалюты, ориентированной на обеспечение анонимности, издержки, связанные с производительностью, не должны сказываться на возможности повышения уровня анонимности и безопасности. Однако такой масштаб технической работы кажется слишком большим в сравнении с небольшим объёмом использования параметра unlock_time. На мой взгляд, лучше всего просто полностью удалить его.

    Написано 10 октября 2020 г.

    ---

    Источник: Monero timelock woes

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.