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

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

Сегодня мы подробнее рассмотрим DBC и собственность. Базовая сеть и DBC / Mints развивались параллельно, но мы приближаемся к тому, чтобы собрать их вместе :crossed_fingers: . В настоящий момент происходит так много всего - большую часть этого, к сожалению, невозможно описать в таком обзоре, - но в целом это была хорошая неделя для работы над некоторыми давними и запутанными проблемами со стабильностью, подключениями и тестированием.

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

@oetyng изучает лучший способ работы с небольшими файлами, которые не могут быть самошифруемыми из-за их размера, названными пятнами, чтобы отличить их от больших двоичных объектов (> 3072 байта), которые проходят через SE. Споты будут включать в себя множество файлов данных в виде простого текста, в том числе DataMaps, поэтому их все равно необходимо зашифровать, если только они не будут общедоступными опубликованными данными.

@yogesh и @joshuef исправили ошибку, которая отправляла сообщение всем старейшинам в разделе, а не только выбор, который требуется после сообщения об обновлении AE. Это резко увеличило количество сообщений в сети, что привело к увеличению количества сообщений (больше сообщений для пожилых людей значило больше для взрослых, а затем снова и снова). С исправлением, объединенным в PR # 473, эффективность и пропускная способность сети увеличились, что означает, что наши тесты E2E проходят гораздо более стабильно.

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

@Yogesh также исправил проблему с тестами AE, когда зацикливание вызывало усиление обмена сообщениями.

@ChrisO работает над CLI и API, обновляя их для совместимости с последними версиями сети, и некоторые команды теперь работают с использованием ключа генезиса, хотя эта работа еще не превратилась в main, она должна появиться скоро.

@Chris.Connelly и @lionel.faber экспериментируют с удалением пула соединений из qp2p. Пул соединений сохраняет соединения открытыми после первого контакта, но это тупой инструмент и что-то вроде черного ящика. Нам нужен больший контроль, чтобы мы могли оптимизировать использование ресурсов, и поэтому мы ищем что-то лучшее в кодовой базе safe_network.

Предыдущие проблемы с памятью теперь в основном исправлены (у нас почти все узлы работают на холостом ходу ~ 80 МБ и увеличиваются примерно до 250 МБ под нагрузкой), но есть один крайний случай, обнаруженный @qi_ma, где файл журнала недавно перемещенного узла увеличивается в размере, предположительно из-за того, что сообщения не принимаются.

Владение DBC

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

Поскольку любой, у кого есть копия DBC, может ее потратить, обычной практикой является немедленно перевыпустить DBC, как только вы ее получите, чтобы убедиться, что кто-то другой не потратит ее первым.

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

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

Имея собственные DBC, мы можем хранить DBC публично, не опасаясь кражи, поскольку только у нас есть секретные ключи, на которые можно потратить наши DBC.

ПРИМЕЧАНИЕ. Фактически мы можем моделировать DBC без владельца с собственными DBC, упаковывая секретный ключ в DBC при совершении платежа.

Конфиденциальность и собственные DBC

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

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

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

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

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

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

owner_index = random_256bits () owner_pk = sams_donation_pk.derive_child (owner_index)

Затем Джанет перевыпускала DBC за 10 долларов с владельцем, установленным на «owner_pk». Этот DBC за 10 долларов затем отправляется Сэму вместе с owner_index. Когда Сэм идет потратить это пожертвование, он использует owner_index, чтобы получить секретный ключ владельца из секретного ключа пожертвования:

owner_sk = sams_donation_sk.derive_child (owner_index)

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

Spentbook и ключи расходов

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

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

Чтобы проиллюстрировать изменение, давайте продолжим с примера выше. Сэм получил пожертвование DBC в размере 10 долларов США и теперь хочет его потратить.

Сначала Сэм создает транзакцию, которую он хотел бы выполнить, здесь он делит свои 10 долларов на DBC за 8 долларов и DBC за 2 доллара.

let tx = ReissueTransaction { входные данные: {$ 10DBC} выходы: {$ 8DBC, $ 2DBC} }

Теперь, когда Сэм указал транзакцию, Сэму нужно выделить DBC на сумму 10 долларов для этой транзакции, зарегистрировав ее в Spentbook.

Для записи в Spentbook требуется доказательство того, что вы действительно являетесь владельцем DBC. Мы делаем это, чтобы заставить клиентов получить DBC Spend Key и подтвердить право собственности, подписав транзакцию.

Ключ расходования

Ключ к расходам - ​​это то, как DBC упоминаются в Spentbook. Он получен от владельца DBC с использованием хэша DBC.

пусть dbc = $ 10DBC; пусть потратят_key = dbc.owner.derive_child (sha3_256 (dbc))

Вам может быть интересно, почему мы не используем напрямую владельца DBC? Зачем выводить другой ключ, если предполагается, что владельцем является одноразовый ключ? Монетный двор не видит случайный индекс, используемый для определения владельца, поэтому у нас нет гарантии, что это действительно уникальный ключ.

Spentbook требует, чтобы у нас был уникальный ключ для каждого DBC, поэтому мы используем хэш DBC для получения ключа Spend Key, который гарантированно будет непредсказуемым. Итак, у нас здесь работают три ключа, производных по цепочке:

well_known_key <- широко опубликовано и связано с реальной организацией owner_key <- получено из well_known_key с использованием случайного индекса trust_key <- полученный из owner_key с использованием хэша DBC

Подтверждение транзакции

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

``
пусть input_dbc = $ 10DBC;
let tx = ReissueTransaction {
входы: {input_dbc}
выходы: {$ 8DBC, $ 2DBC}
}

пусть потратят_ключ = input_dbc.owner.derive_child (sha3_256 (input_dbc))
``

Сэм подписывает транзакцию с помощью этого ключа «trust_key» и отправляет «tx», «trust_key» и подпись в сеть для записи в Spentbook.

После того, как Spentbook будет написан, все, что осталось сделать, это получить подпись Mint, подтверждающую, что транзакция действительна. Для этого Сэм просто отправляет транзакцию tx в Mint, каждый узел Mint запрашивает Spentbook и гарантирует, что каждый ввод транзакции привязан к этой же транзакции. Если это пройдет, мы проверяем стандартные ограничения повторной выдачи, а именно: сумма входов должна соответствовать сумме выходных данных, и что каждый входной DBC действителен.

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

Этот новый поток переиздания приводит к тому, что узлы Mint просто действуют как валидаторы с доступом только для чтения в Spentbook, это должно снизить требования к ресурсам на узлах Elder и дать нам более быструю сеть.


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

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

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