Это машинный перевод. Оригинал на английском здесь: Update 15 June, 2023
Первое, что нужно сказать, это то, что мы чрезвычайно довольны тем, как работает ReplicationNet. Было немного рискованно бросить так много узлов — наша самая большая тестовая сеть с некоторым отрывом — и мы ожидали серьезных колебаний, но она взяла все, что мы могли бросить на своем шагу и без жалоб, пока полные узлы не перестали играть. . Больше всего обнадеживает эта стабильность, несмотря на некоторые ошибки обмена сообщениями при репликации данных, которые, как можно было ожидать, могли привести к ее падению. Вместо этого он отшвырнул их, как мух. Еще раз сердечно благодарим всех, кто принял участие 
, и отдельное упоминание @shu за его фантастическую работу с приборной панелью 
.
ReplicationNet — выводы и действия
Итак, просмотрев логи, как любезно предоставленные сообществом, так и собственные, можем сообщить следующее.
-
Медленно растущая проблема с памятью почти наверняка связана с тем, что узлы достигают емкости. Мы не видим такого поведения до тех пор, пока несколько узлов не заполнятся (в данном случае 1024 фрагмента). Как только сеть заработает, мы не должны этого видеть, поскольку новые узлы будут заинтересованы в присоединении.
-
Проблемы с нехваткой памяти, по-видимому, вызваны тем, что в кэше хранится слишком много данных, когда узел приближается к емкости. (И в этом случае у нас слишком много узлов на слишком маленькой машине). Это не ошибка сама по себе, libp2p должен рассредоточить этот кеш, и данные будут храниться по мере присоединения большего количества узлов.
-
Мы обнаружили и устранили ошибку, из-за которой репликация данных приводила к закрытию соединения и, как следствие, большому количеству потерянных сообщений во время репликации. Это то, что может означать гибель, и это свидетельство базовой стабильности сети, что оно оказало такое незначительное влияние.
-
Еще одно исправление ошибки было связано с ошибками Outbound Failure.
-
Распределение данных по узлам довольно равномерное. Опять же, отличные новости, потому что мы можем использовать процентное пространство, используемое в качестве триггера для вознаграждения, как и планировалось. Проблема с тем, что некоторые узлы не заполняются, является ошибкой, вероятно, связанной с тем, что новые узлы не продвигаются достаточно сильно в чужие таблицы маршрутизации.
-
В журналах есть несколько аномалий, из-за которых запросы на размещение и сохраненные метрики кусков не совпадают. Нам нужно работать над их уточнением.
-
Чтобы предоставить пользователям с более низкой пропускной способностью больше контроля, мы добавили возможность клиента устанавливать время ожидания для запросов и ответов из сети. . Мы также увеличили время ожидания по умолчанию с 10 до 30 секунд.
-
Теперь мы думаем о потоках платежей и вознаграждениях для различных сценариев: новые данные, репликация данных и повторная публикация данных (когда действительные данные были потеряны по какой-либо причине)
Следующая тестовая сеть поможет нам протестировать эти предположения и исправления, а также проверить работу пользователей.
Общий прогресс
Все внимание теперь приковано к DBC, а @bochaco и @Anselme работают над обеспечением безопасности проверки процесса оплаты для хранения фрагментов, включая проверку родителей платежные DBC тратятся, а их хеш-причины совпадают с информацией о подтверждении платежа, предоставленной для каждого фрагмента. Anselme исправил ошибку, из-за которой сборщик и кошелек не помечали DBC как потраченные. Оказалось, что это связано с синхронной активностью проверяющих узлов, вызывающей блокировку чтения-записи, тогда как нам нужно, чтобы она была асинхронной.
Точно так же @roland устраняет тупиковые ситуации в операциях PUT и GET, чтобы гарантировать, что они могут выполняться и оплачиваться одновременно. Параллелизм — это название игры. Он также следит за тем, чтобы наши проверки данных происходили независимо от того, когда данные поступают на узел, предотвращая некоторую «загрузку» данных через протоколы libp2p/kad (которые, по сути, разрешали бы бесплатные данные).
@bzee все еще возится с внутренностями libp2p, в настоящее время настраивая начальный набор одноранговых узлов начальной загрузки.
@Joshuef и @qi_ma в основном работают над выводами последней тестовой сети и исправляют их по ходу дела.
@chriso усердно работал над обновлением safeup, подробнее об этом скоро.
А @aed900 конкурировал с инструментом запуска тестовой сети для автоматизации создания тестовых сетей на AWS и Digital Ocean.
Вперед!
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!