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

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

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

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

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

На этой неделе исправлено много ошибок. Мы боролись с еще одной проблемой памяти узла, связанной с помещением файлов. Эти всплески памяти были вызваны проблемой усиления сообщений, вызванной потоками AE на клиенте, а также от взрослых _ назад_ к клиентам. Исправления для них были объединены, и использование памяти значительно уменьшилось.

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

В связи с этим @chris.connelly копался в qp2p, удаляя некоторые функции пула соединений, которые больше не нужны.

@oetyng реализует обработку противодавления (сопротивление или сила, препятствующие желаемому потоку данных через программное обеспечение). Идея состоит в том, чтобы узел проверял загрузку процессора при получении запросов. Если он выше определенного уровня, он вернет сообщение, содержащее загрузку процессора. Затем принимающий узел может регулировать свою связь на основе этой информации. Через некоторое время они возвращаются к настройкам по умолчанию.

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

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

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

Тем временем @Lionel.faber улучшил способ работы GitHub Actions для автоматизации развертывания тестовых сетей в Digital Ocean, что очень понравилось команде, а @Qi_Ma обнаружила некоторые аномальные поведения с AE. С каждой устраненной ошибкой мы становимся ближе.

О, и мы были очень рады получить пиар от @davidpbrown. Замечательно, что в этом участвуют члены сообщества. Если кто-то хочет внести свой вклад, вам нужно сначала разветвить репо - подробнее здесь.

DBC Mints

DBC Mints существуют с 90-х годов, но так и не стали очень популярными.

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

Децентрализация с помощью секций (шардинг) - центральная особенность проектирования безопасной сети. Дизайн SN DBC использует и основывается на этом для создания децентрализованного и масштабируемого монетного двора. На сегодняшний день ни одна из развернутых криптовалют [1] не включает децентрализованные монетные дворы DBC, о которых мы знаем, так что это новая разработка. Наша цель - масштабирование для использования во всем мире за счет мгновенных (и частных) расчетов по транзакциям.

Функциональность децентрализации можно разбить на несколько основных областей:

  1. MintNode сверстники внутри раздела.
  2. Шардинг: каждый раздел отвечает за подмножество DBC.
  3. Агрегация клиентов
  4. Распределенная электронная книга, написанная клиентом.

Давайте посмотрим на каждый из них.

Одноранговые узлы MintNode в разделе.

Внутри раздела каждый старейшина также обозначен как MintNode. Таким образом, имеется 7 узлов, остальные готовы и ждут замены любого отказавшего узла. При формировании раздела или изменении членства узлы выполняют цикл генерации распределенного ключа (DKG) для создания общего ключа BLS. Это ключ с несколькими подписями, так что 5 из 7 (подавляющее большинство) узлов должны подписать часть данных, чтобы она считалась действительной. В случае DBC подписанные данные называются ReissueShare. Эти ReissueShares должны собираться с подавляющего большинства узлов в разделе, чтобы завершить повторную выдачу DBC, управляемых этим разделом.

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

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

Шардинг: каждый раздел отвечает за подмножество DBC.

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

Наш подход к сегментированию на самом деле довольно прост. Ключ расходов DBC (универсально уникальный одноразовый ключ) определяет, какой раздел отвечает за его обработку. Клиентское программное обеспечение отвечает за отправку идентичного ReissueRequest всем узлам mint во всех разделах, соответствующих входам DBC в ReissueRequest.

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

По мере того как MintNode просматривает входные DBC, для каждого из них он проверяет, несет ли он ответственность или нет. Если MintNode отвечает за DBC, Spentbook проверяет, израсходован ли уже этот DBC. Таким образом, MintNode ReissueShare предоставляет SignatureShare только для DBC, для которых конкретный раздел имеет полномочия.

Агрегация клиентов

Когда пользователь хочет повторно выпустить DBC, клиентское программное обеспечение пользователя связывается с каждым из 7 MintNodes для раздела (ов), ответственного за входные DBC, и отправляет ReissueRequest. Каждый узел проверяет запрос и, если все в порядке, отвечает ReissueShare, который содержит BLS SignatureShare.

Клиентское программное обеспечение собирает ответы ReissueShare со всех узлов MintNodes, с которыми оно контактировало, и проверяет их. Если по крайней мере 5 узлов в данном разделе ответили правильно, то клиент может объединить свои SignatureShare, чтобы сформировать окончательный Mint Signature для каждого выходного DBC. Имея в руках подпись, клиент затем создает фактические DBC, которые позже могут быть отправлены в качестве входных данных для другого переиздания.

Распределенная электронная книга, написанная клиентом

Это функция в разработке. Основная идея состоит в том, что Клиент выполняет заданную ReissueTransaction и публикует это обязательство, идентифицированное ключом расходов DBC (или хешем ключа), в безопасной сети, прежде чем он сделает ReissueRequest. Затем каждый MintNode должен только прочитать запись Spentbook для каждого DBC и подтвердить, что запись правильно подписана владельцем DBC. Это упрощает операции для MintNode, которому больше не нужно записывать какие-либо данные, и сохраняет идемпотентность API повторной выдачи MintNode. Другими словами, Клиент может многократно вызывать повторную отправку с одним и тем же ReissueRequest и всегда получать один и тот же ответ.

Мы планируем более подробно рассказать о Spentbook в одном из следующих обновлений.

[1] В 2019 году был опубликован технический документ с описанием децентрализованной системы DBC Mint под названием Scrit. Дизайн Scrit существенно отличается от нашего, и, похоже, он не был публично развернут на момент написания этой статьи.


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

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

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