Это машинный перевод. Оригинал на английском здесь: Update 26 October, 2023
За последние несколько лет мы часто сочувствовали Сизифу из греческой легенды. Сизифу пришлось вечно толкать валун на гору только для того, чтобы он снова покатился вниз, как только он приблизился к вершине.
Не желая искушать печально известных мстительных греческих богов, мы все больше уверены, что на этот раз нам наконец удалось его разгадать и мы прекрасно сидим на плато. Откуда эта уверенность, о вы, кто остался с нами несмотря ни на что, о вы, кто, возможно, испытывает слабое чувство дежавю?
Ну, потому что ошибок становится меньше, и мы исправляем их быстрее. Потому что вся команда исправляет ошибки вместе, а не каждый имеет специализацию. Потому что тестовые сети живут дольше и дают результаты, которые мы можем понять и с которыми можно справиться. Потому что мы можем выполнять итерации на лету, добиваясь ощутимых улучшений. Потому что мы сотрудничаем с единомышленниками. И потому что сообщество занимается своими собственными исправлениями. Мы перешли от теории к практике, и это приятно.
На этой неделе пошла целая куча пиаров, от коллектива, на команду и еще на какие-то проекты. В итоге:
- Исправлена ошибка, из-за которой возвращалось большинство узлов, а не все из них.
- PR, чтобы просто оплатить один узел, а не все из них, при этом продолжая репликацию в закрытую группу.
- Еще один на replication, на этот раз используется
tokio::Interval
для принудительной репликации вместо Instant, чтобы справиться с всплесками трафика, вызывающими блокировки. . - Изменение клиента: проверять только те фрагменты, которые достигают большинства для репликации.
- Исправлена проблема с одноранговым узлом проблема дублирования при запуске репликации.
- И еще один, который экспериментирует с расширением диапазона репликации.
- Еще есть вариант, который удаляет медленное ведение журнала content_hash для больших записей — возможная утечка памяти.
- Опять же, что касается ведения журнала, есть один, который добавляет ведение журнала SwarmCmd для профилирования производительности, другой, который добавляет ведение журнала KBucketKey узла и еще один, который исправляет журналы синхронизации.
- Кроме того, есть пиар @bzee для
libp2p
для решения проблемы постоянно растущего вектора адресов хранилища - еще один кандидат на утечку памяти. - Кроме того, есть исправление для ошибок тестирования вознаграждения путем создания NetworkEvent при публикации GossipSub.
- Плюс еще несколько игроков, ожидающих приземления из отдельных ветвей команды.
Спасибо @southside за полезный пиар за простое улучшение вывода и shuoer86
за некоторые исправления опечаток. Все остальные, не стесняйтесь. Если вы заметили что-то, что можно изменить или улучшить, оставьте комментарий или сообщите нам об этом на форуме.
Общий прогресс
@joshuef изучал колебания затрат в магазинах и то, как клиенты без необходимости зацикливаются на повышении цен и платят за уже сохраненные данные. (PR 887/888). Мы ужесточаем платежную систему, проверяя, у кого есть эта часть, и при необходимости выплачиваем им долг, а не выплачиваем всем. В свою очередь, это снижает нагрузку на процесс проверки, а значит, меньше бессмысленной деятельности и повышается производительность.
Сопутствующие улучшения включают устранение избыточного хеширования контента и проверку только фрагментов в большинстве закрытых групп, а не всех из них, чтобы избежать ненужной работы.
@bochaco работает над изменениями документации для новых команд cli/rpc-client и тестирует testnet-deploy, чтобы убедиться, что CashNotes можно загрузить и разместить в локальном кошельке. Он также завершил процесс оплаты узлов Foundation и подготовил новейшую тестовую сеть, чтобы протестировать ее.
@bzee рассматривает возможность оплаты одного узла за хранение данных. Как обсуждалось на прошлой неделе, это может быть хорошим дешевым и грязным вариантом хранения данных без избыточности, если он окажется достаточно надежным. Он также надеется устранить еще одну утечку данных вокруг постоянно растущего хранилища в libp2p
, в котором хранятся идентификаторы известных узлов. Команда libp2p
сейчас этим занимается.
Тем временем @anselme обновил хранимые платежи с помощью CashNotes и Transfers.
@roland сосредоточил свое внимание на репликации, откладывая ее с мгновенной до проверки каждые 10 секунд, чтобы избежать нежелательных блокировок в противном случае.здесь. Кроме того, Роланд оптимизировал способ записи и хранения узлов своих близких одноранговых узлов, чтобы избежать дублирования.
Репликация регистров была еще одной нерешенной проблемой. Если регистр изменяется во время процесса репликации, разные узлы могут в конечном итоге содержать разные версии, при этом возникают проблемы из-за того, что конвергенция CRDT не происходит вовремя. @Qi_ma уже исправил это, так что это еще одна галочка.
А @chriso продолжает совершенствовать процесс автоматизации тестовой сети, включая команду установки для менеджера узлов.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!