Это машинный перевод. Оригинал на английском здесь: Update 01 June, 2023
Мы объявляем NatNet определенным успехом! Насколько мы можем судить, все домашние узлы, работающие за NAT, были успешно обнаружены и отключены, что смягчило проблемы, с которыми мы сталкивались ранее, когда сеть пыталась установить связь с недоступными узлами. Теперь мы уверены в обнаружении узлов за NAT, следующим шагом на этом фронте будет разрешение им присоединиться через пробивку отверстий и UDP/Quic. NatNet был только TCP.
Наряду с этим, хотя (обход NAT все еще требует некоторой работы, как мы упоминали ранее, он довольно прост в libp2p, так что это может занять некоторое время), есть много работы.
Сначала мы рассматриваем узлы провайдеров, которые могут выполнять такие задачи, как архивирование. Если вы помните, с помощью libp2p мы можем рассматривать определенные узлы как поставщиков услуг для выполнения специальных функций, таких как архивирование.
Другая область, к которой мы вернулись, — это размер узла (и попытка сравнить потоки репликации). Насколько мала мала? 1000 маленьких узлов лучше, чем один большой такой же мощности? Какая разница, когда у нас массовый отток? Каковы компромиссы? Сейчас мы проводим предварительные тесты.
Общий прогресс
@anselme адаптировал книгу расходов, чтобы она содержала обе записи о двойных расходах вместо одной. Тогда с ними будет легче справиться. Это вдобавок к недавнему слиянию работы по переносу DBC в «RecordStore», что означает, что они будут автоматически реплицироваться вместе с фрагментами (там остаются только регистры для сортировки).
@bochaco работает над сериализацией и отправкой подтверждений платежей узлам, пробуя различные методы, чтобы облегчить ситуацию.
@joshuef рассматривал преимущества и ограничения наличия нескольких узлов на машине и возможных вариантов. Пока без оптимизации 10 узлов на каплю Digital Ocean работают достаточно хорошо (хотя и без оттока), хотя удвоение этого числа замедляет все сразу. Это должно позволить нам иметь гораздо больше узлов в будущих тестовых сетях!
Благодаря информации из DiskNet и более позднему внутреннему тестированию, @roland реализует RecordHeader и проверяет записи перед их сохранением. Это также аккуратно позволяет нам разделить адресное пространство между нашими базовыми типами данных (chunk/DBC/register) и выполнять там некоторую пользовательскую обработку (например, операции слияния регистров CRDT).
@qi_ma изучает проблему с закрытием соединения во время передачи данных. Это может быть связано с RPC-адресом, используемым для передачи данных, хотя этого быть не должно. Если это так, это вполне может быть основной причиной некоторых ошибок подключения, которые мы наблюдаем, а также связанных с этим проблем, когда соединения также могут быть закрыты, поскольку при наборе однорангового узла он набирает более одного из его адресов. @bzee копался там.
Тем временем @Chriso и @aed900 продолжают работать над инструментами запуска для тестовых сетей.
Вдали от кода @jimcollinson снова активно участвует в исследованиях рынка и планировании запуска. Он и @andrew.james внимательно изучают методы обеспечения плавного экономического перехода на начальных этапах Сети, уделяя особое внимание ликвидности. Теперь, когда Фонд успешно работает в Швейцарии, этот процесс значительно упростился. Эндрю также поддерживает связь со швейцарскими аудиторами для обсуждения подходящих структур бухгалтерского учета.
Так что новой тестовой сети пока нет. Но тем не менее напряженное время!
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!