Обновление Safe Network 🇷🇺 11 августа 2022 г

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

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

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

@yogesh оптимизировал настройку сервера ElasticSearch/Kibana, чтобы нам было проще отслеживать наши дроплеты, и завершает работу над документацией для traceroute.

@joshuef обнаружил процесс в sn_node, который использует около 1/3 процессорного времени и, вероятно, не нужен, поскольку мы реализовали эту функциональность в другом месте, поэтому он видит, что произойдет, если мы удалим его.

@oetyng и @davidrusu возглавили разработку концепции создания и выплат Genesis DBC, над которой команда работала на этой неделе (см. ниже), в то время как @anselme находится на завершающей стадии рефакторинга DKG с удалением многопоточности для простоты. , а также удаление таймаутов (см. ниже).

Разбивка активности

Членство, AE и консенсус — соединение точек

Членство и антиэнтропия (AE) связаны с тем, что система постоянно обновляется, в то время как консенсус используется для принятия решений, которые изменяют состав раздела и / или данные, которые он содержит.

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

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

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

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

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

Определение времени на тайм-аутах - повышение уверенности в раундах DGK

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

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

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

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

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

Изменения узла

Мы внесли некоторые изменения в наш двоичный файл sn_node. Теперь вам нужно передать путь к файлу контактов каждому узлу, который присоединяется к сети (--network-contacts-file). Вместо того, чтобы узел ожидал, что где-то будут найдены контакты, другие инструменты отвечают за обеспечение того, чтобы путь к узлу был предоставлен.

Мы обновили наш sn_launch_tool, чтобы сделать это, поэтому, если вы используете его (или CLI, который его использует), инструмент теперь предоставляет каждому присоединяющемуся узлу путь к --network-contacts-file.

--network-contacts-file — это просто файл, который предоставляет присоединяющемуся узлу или самозагружающемуся клиенту информацию, необходимую для присоединения к сети. Эта информация находится в SAP и в SAP-части «PrefixMap».

Для новых узлов мы используем файл PrefixMap узла Genesis для предоставления этой информации (он расположен в ~/.safe/node/local-test-network/sn-node-genesis/prefix_map), но инструмент также копирует это файл в место, где клиенты/CLI найдут его по умолчанию (~/.safe/prefix_maps/default).

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

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

Как описано в недавнем обновлении, PrefixMap недавно превратился из простого файла, который сопоставляет префиксы разделов с текущими SAP, в более сложная структура, включающая полный ключ секции DAG/tree, так что этот файл, скорее всего, скоро будет переименован.

Завершение сетевой выплаты 70% вознаграждения

70% SNT в конечном итоге будут созданы сетью в процессе загрузки данных клиентами.

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

Однако определенная доля (которая будет определена) платежей также приведет к чеканке новых SNT в форме DBC. Общая стоимость нового DBC будет равна сумме платежа. Новый DBC будет общим для всех узлов в разделе.

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

Старейшины проверяют каждый платеж, чтобы убедиться, что он проходит этот тест. Стимулом этой проверки (быстрой и требующей минимальных ресурсов) является шанс заработать SNT. Большинство платежей не пройдут тест и будут работать как обычно, но когда есть совпадение, старейшины используют этот платеж для создания «Genesis DBC». Этот Genesis DBC является совершенно новым и увеличивает общую сумму SNT, которую можно потратить. Его общая сумма такая же, как сумма платежа за загрузку, и его значение делится между всеми узлами в разделе, взвешенными по «возрасту узла».

Чтобы DBC был потрачен, он должен быть перевыпущен на открытые ключи нового владельца (владельцев). Для этого мы передаем «Genesis DBC» обратно клиенту и заставляем его повторно выдавать новые DBC узлам — плюс один DBC самому себе в качестве поощрения. Величина этого поощрения должна быть определена.

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

Создание нового SNT происходит только с новым хранилищем данных. Передачи SNT не приводят к созданию нового DBC.

Мы, вероятно, изменим название «Genesis DBC», так как таких DBC много, поэтому слово «Genesis» сбивает с толку.

Завершение фарма/оплаты хранилища

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

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

Эта квитанция затем станет частью процесса выплаты в сети, как описано выше.

Использование слухов для членства внутри секции имежсекционное обновление PrefixMap

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

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


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

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

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