Обновление Safe Network 🇷🇺 9 сентября 2021 г

Это машинный перевод. Оригинал на английском здесь: Update 09 September, 2021

На этой неделе мы более подробно рассмотрим несвязанность DBC, а также последствия и компромиссы для взаимодействия с пользователем и эффективности сети.

Общий прогресс

Старейшина - это особый тип узла с правом голоса и управленческими обязанностями, тогда как Взрослый хранит данные и доставляет их по запросу, но для клиента они выглядят точно так же. @chris.connelly работал над некоторыми ошибками, из-за которых клиент пытался выполнить загрузку для Adult, а затем игнорировал это, создавая неприятный цикл.

Крис также работал над улучшением инструмента sn_launch (как некоторые из вас заметили!) И отладкой обновления qp2p.

@JimCollinson изучает проблему учетных данных, используя мультиподпись, чтобы иметь возможность добавлять дополнительные параметры аутентификации к базовому паролю / мнемонике, включая аппаратные ключи, дополнительную мнемонику или начальные фразы и т. Д. Например, пользователь может оговорить, что любые три из пяти учетных данных необходимо предъявить, чтобы разблокировать Сейф. Multisig также открывает возможность использования n доверенных третьих лиц для восстановления учетной записи, если это необходимо. Пользователи Safe Network неизбежно теряют учетные данные, а мультиподпись предлагает путь к безопасному восстановлению учетной записи, позволяя пользователю контролировать баланс рисков по своему усмотрению.

@bochaco смотрит, как Клиент проверяет актуальность раздела, с которым он разговаривает, через AE.

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

Тем временем @chriso работает над модернизацией API, чтобы учесть новые изменения в обмене сообщениями, и эта задача почти завершена.

Работа @oetyng с интеграцией усиленного «самошифрования» и рефакторинга обработки фрагментов была объединена. Двойственность области видимости (общедоступная / частная) была перенесена с уровня фрагмента на уровень большого двоичного объекта, что значительно упростило код и обязанности узлов. Также была добавлена ​​правильная обработка фактического секретного ключа, который самошифрование выводит вместе с зашифрованными фрагментами. Теперь можно продолжить работу над пакетной обработкой фрагментов.

Мы также объединили нашу ветку незавершенной работы в master (или, скорее, переместили в нее HEAD из main, если вы хотите получить подробные сведения о git …). Это означает, что ветка была более стабильной, чем основная. Мы видим больше проходов CI и более чистый код в целом. В этой ветке много чего было добавлено, и мы все еще тестируем и отлаживаем различные потоки. Но с AE повсюду и более простым потоком кода в узле все становится проще. Так что пока нет тестовой сети, с которой можно было бы поиграть, мы идем в правильном направлении.

Подробнее о DBC

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

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

Несвязанность

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

Представьте себе два золотых слитка без опознавательных знаков равного веса. Один так же хорош, как и другой. Они неотличимы. Однако, если эти слитки помечены серийными номерами, и некоторая центральная организация хранит список всех обменов золотом, отслеживаемых по серийному номеру, то может возникнуть ситуация, когда один слиток станет меньше другого в сознании потенциальных получателей, потому что он был связаны с какой-то “плохой” деятельностью в прошлом. Или другой может быть даже более ценным, потому что он прошел через руки известного человека. С такой системой участники могут начать терять доверие к золотым слиткам. Возможно, им придется сверяться с централизованным «списком хороших / плохих» для каждой транзакции, чтобы предотвратить получение «плохой полосы», и система в целом станет менее эффективной. Из-за отслеживания мы потеряли взаимозаменяемость. Подробнее об этом см. В указанной выше статье.

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

Как мы можем определить, является ли монета связываемой или несвязанной? На самом деле это довольно просто, мы просто смотрим на входы и выходы пары транзакций.

Примечание. В случае с DBC мы часто используем слова транзакци и переиздание ввзаимозаменяемо

Вот упрощенный пример двух переизданий с использованием нашей текущей системы DBC. Можно сказать, что Боб заплатил 50 Алисе (1-е переиздание), а затем Алиса заплатил те же 50 Джиму (2-е переиздание). Таким образом, каждое переиздание имеет только один входной DBC и один выходной DBC. У каждого DBC есть связанная сумма, открытый ключ владельца pubkey и подпись монетного двора mintsig. В этом примере pubkey, mintsig и hash для краткости сокращены до трех цифр. На самом деле это очень большие уникальные числа.

переиздание 1 (r1):
→ input = a {amount = 50, pubkey = 567, mintsig = 233}, hash (a) = 223
→ output = b {amount = 50, pubkey = 725, mintsig = 112}, hash (b) = 787

переиздание 2 (r2):
→ input = b {amount = 50, pubkey = 725, mintsig = 112}, hash (b) = 787
→ output = c {amount = 50, pubkey = 212, mintsig = 455}, hash (c) = 993

Примечание: для этого примера метки a,b и c. Они не появляются в переиздании. Суммы теперь скрыты обязательствами, но не имеют отношения к этому анализу.

Мы легко можем видеть, что вход b для r2 совпадает с выходом b для r1. Мы можем связать их вместе с помощью любого из: pubkey == 725 или mintsig == 112, или hash == 787.

Это означает, что переиздания r1 и r2 связаны друг с другом, потому что они имеют общий DBC. После серии переизданий это создает цепочку, по которой можно следовать.

Это то, что подразумевается под возможностью связывания.

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

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

Вы можете спросить: а что, если мы будем использовать несколько входов и выходов и разные суммы для разделения и объединения токенов? Что ж, такие методы могут затруднить определение следа отдельного токена. Это основа CoinJoin, CoinShuffle и подобных алгоритмов микширования. Они делают больше возможных ссылок для отслеживания / оценки. Но на самом деле они не нарушают никаких ссылок … которые сохраняются на неопределенный срок, чтобы любой мог анализировать их на досуге с использованием статистического анализа, данных от третьих лиц (например, бирж) и т. Д. Такие методы обычно считаются шифровальщиками “слабым соусом”.

Вы также можете спросить: зачем вообще нужен уникальный идентификатор в DBC? Ответ заключается в том, что идентификатор необходим для предотвращения двойных расходов. Монетный двор должен иметь возможность записывать «монету» как потраченную, чтобы уловить любую будущую попытку потратить ее снова.

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

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

Слепые подписи

Самая старая известная техника была изобретена Дэвидом Чаумом и известна как слепые подписи. Его преимущество в том, что это самая простая в реализации схема и, по крайней мере, на данный момент, самая эффективная, что делает ее очень подходящей для операций с монетным двором.

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

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

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

Хорошо, давайте снова выполним наши два переиздания, на этот раз с использованием слепых подписей. Теперь это DBC Mint, который слепо подписывает конверт (ы). В этом примере мы предполагаем, что все DBC равны по стоимости.

переиздание 1 (r1):
→ input = a.slip {pubkey = 567, mintsig = 233}, hash (a.slip) = 223
→ output = b.envelope {слепой (b.slip)}, hash (b.envelope) = 565

переиздание 2 (r2):
→ input = b.slip {pubkey = 445, mintsig = 112}, hash (b.slip) = 787
→ output = c.envelope {слепой (c.slip)}, hash (c.envelope) = 993

Прописью:

  • Боб представляет ввод A (промах) на mint (wi с действительным знаком монетного двора над A) и получает подпись монетного двора над выходом B (конверт) с символом монетного двора, указывающим, что B стоит столько же, сколько A (промах).
  • Монетный двор также помечает A (промах) как потраченный.
  • Боб вынимает B (бланк) из B (конверт) и передает его Алисе, которая представляет B (бланк) монетному двору и получает знак монетного двора над C (конверт), который стоит столько же, сколько B (бланк).
  • Монетный двор также отмечает B (промах) как потраченный.

Теперь интересно то, что B (конверт) имеет другой хеш от B (промах) внутри него. 565! = 787

Следовательно, хэши не совпадают между tx1 и tx2, а также не совпадают никакие поля. Ничто не связывает эти две транзакции вместе, насколько это видно на монетном дворе. У нас несвязанность!

Цепи с нулевым разглашением

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

Используя доказательства ZK, мы пытаемся убедить Монетный двор в чем-то, не раскрывая конфиденциальной информации. Системы защиты цепей ZK, такие как PLONK, появились за последние несколько лет как общие системы для инженерных схем защиты ZK.

Например, скажем, мы реализуем схему ZK, которая имитирует sha3_256. Эта схема позволила бы нам доказать третьей стороне, что мы знаем данные, которые хешируются в некоторый хэш, не раскрывая сами данные. Мы даже можем доказать свойства этих данных!

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

let reissue = Reissue {
   входы: {Dbc {количество: 9, владелец: pk1, ..}, Dbc {количество: 1, владелец: pk2, ..},
   выводит: {Dbc {количество: 10, владелец: pk3, ..}
   Доказательства владения: {pk1_sig, pk2_sig}
};

Я мог бы запустить это переиздание через sha3_256, чтобы получить хэш:tx_hash = sha3_256 (reissue).
Чтобы убедить монетный двор в том, что это хэш действительной транзакции, мы можем сгенерировать доказательство ZK, используя нашу схему sha3_256.

Схема ZK имеет частные и общедоступные входы, в этом примере информация о перевыпуске будет частными входами, а tx_hash будет общедоступным входом.

закрытый: [9, pk1, 1, pk2, 10, pk3, pk1_sig, pk2_sig]
общедоступный: [tx_hash]

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

/// Ограничения повторной выдачи
private [0] + private [2] = private [4] // 9 + 1 = 10
private [1] .verify (private [0..6], public [6]) // pk1 подписал транзакцию
private [3] .verify (private [0..6], public [7]) // pk2 подписал транзакцию
public [0] = sha3_256 (private) // перевыпуск хэшей данных в tx_hash

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

Теперь, когда мы закодируем эти ограничения как схему ZK, мы можем вставить детали переиздания в частные входные слоты и tx_hash в публичный входной слот схемы. Затем мы поворачиваем ручку, чтобы получить доказательство того, что все ограничения выполнены.

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

Это очень круто, но исследования в этой области все еще молоды, а инструменты для этих схем ZK все еще недостаточно развиты. Доказательства, как правило, очень медленные для создания и проверки, особенно для сложных схем, таких как sha3_256.

Если хотите глубже эта серия неплохая.

Кольцевые подписи

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

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

Таким образом, кольцевые подписи представляют собой форму автоматического микширования. Ссылки все еще существуют, но их так много, что их может быть слишком сложно анализировать. В настоящее время в Monero есть 11 возможных подписантов: настоящий плюс 10 других. Это как прятаться в толпе из 11 человек … лучше, чем стоять в одиночестве, но не очень утешительно, если ищейка обнюхивает.

Сумма скрыта

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

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

Мы обсуждали Скрытие суммы через обязательства Педерсена в предыдущем обновлении.

Фиксированные номиналы

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

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

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


Полезные ссылки

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

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