Это машинный перевод. Оригинал на английском здесь: Update 27 July, 2023
Как вы заметили, среди нас новая тестовая сеть. Время прыгать на борт, если вы еще этого не сделали! Загрузите сейф и загрузите несколько файлов, и посмотрите, как плата за каждую загрузку автоматически вычитается из вашего кошелька. Конечно, на данный момент все деньги Монополии, но здорово увидеть ее в действии. Сообщите нам о любых ошибках, которые вы можете увидеть в теме.
Плата за данные — это большой шаг вперед, который стал возможным благодаря тому факту, что сеть теперь работает довольно хорошо и стабильно. Память на узел колеблется в диапазоне 50–60 МБ, тогда как раньше она исчислялась сотнями МБ. Но есть еще что сгладить. Спасибо за обратную связь. Продолжайте в том же духе. Следующим этапом будет тестирование основного потока платежей узлам и какого-то простого механизма ценообразования.
К сожалению, пока нет надежного обхода NAT, но те, у кого есть облачные узлы или кто доволен переадресацией портов, могут попробовать запустить узел или два. Дайте нам знать, как это происходит.
Теперь, когда мы находимся в стабильном месте, мы также начнем разбираться в работе сети. На этой неделе @roland объяснит, что происходит во время репликации данных.
Общий прогресс
@Chriso работает над централизованным ведением журналов, чтобы упростить совокупный анализ ошибок после тестовых сетей. В конечном счете, мы надеемся, что члены сообщества смогут делать это в режиме реального времени, но пока мы не усложняем задачу.
Томас Айзингер и Макс Инден из команды rust-libp2p объединили исправление от @bzee, из-за которого новые узлы продолжали набирать номер (сообщение ) другие узлы даже после их подключения к сети. @bzee находится в постоянном контакте с этой командой, которая говорит, что AutoNAT и пробивка отверстий должны заработать «скоро». У одного из сопровождающих есть предварительное решение, которое решит проблему повторного использования портов — AutoNAT не нужно повторно использовать порты на исходящих зондах. Скрестим пальцы за ранний прогресс в этом.
@aed900 занимается улучшением UX для неподключенных узлов обработка тайм-аутов.
@bochaco продвигает функцию одновременного получения всех расходов для подтверждения платежа, чтобы ускорить процесс проверки DBC, а также способ сделать регистры адресуемый по содержимому.
@qi_ma исправил небольшую ошибку с DBC. Когда клиент хочет потратить DBC для загрузки данных, узлы проверяют, существует ли существующее доказательство траты по соответствующему адресу (чтобы остановить двойную трату). Узел, содержащий этот адрес, также будет активно отвечать на запросы GET, что может задержать его ответ запрашивающим узлам, заставив их думать, что там нет потраченного доказательства. Это чрезвычайно редкое событие, но мы видели его в дикой природе, и это позволило бы удвоить расходы. Мы исправляем это, требуя, чтобы 5 узлов видели GET, прежде чем на него будут воздействовать.
А @joshuef следит за динамическими платежами и ценообразованием, включая то, что клиент спрашивает узлы рядом с местом оплаты какова их стоимость хранения, и при этом обновляет оплата за загрузки. А также базовый расчет стоимости хранилища на основе емкости хранилища записей.
Репликация данных
Репликация данных — это механизм, который позволяет узлам распределять данные между новыми одноранговыми узлами по мере их присоединения и передачи данных от «мертвого однорангового узла» другим узлам. Это гарантирует, что данные остаются доступными в сети, даже когда узлы присоединяются или удаляются. Однако подход, используемый Libp2p, основывался на том, что узел периодически заполняет сеть всеми своими данными. Это сопровождалось некоторыми недостатками, в том числе интенсивным сетевым трафиком и высоким использованием памяти между узлами. Кроме того, новые узлы не получали данные, за которые они отвечали, а данные, хранившиеся на мертвых узлах, не реплицировались вовремя. Чтобы решить эти проблемы, мы внедрили специальный процесс репликации, который запускается каждый раз, когда происходит изменение в закрытой группе узла.
Прежде чем углубляться в процесс репликации, давайте кратко обсудим, как данные хранятся в сети. Сеть работает как распределенная хеш-таблица (DHT), что позволяет извлекать данные с использованием уникальных ключей. Когда кто-то хочет сохранить файл в сети, он сначала использует свой DBC для оплаты файла, а затем загружает файл в сеть. Эти данные (DBC, фрагмент или регистр) преобразуются в серию нулей и единиц и помещаются внутрь чего-то, называемого «записью». Хотя записи могут быть бесконечно большими, узлы ограничены возможностью обработки записей размером 1 мб. Каждая «запись» имеет свой собственный «ключ», который является «XorName» данных, которые она хранит.
Чтобы сохранить «Запись», содержащую как данные, так и Ключ в сети, клиент вычисляет расстояние Xor между «Ключом записи» и его узлами в своем RT (Routi).
ng), сортируя одноранговые узлы по их близости к «ключу». Впоследствии клиент просит эти узлы «вычислить и поделиться узлами, которые, по их мнению, являются ближайшими к «ключу». Затем клиент сортирует ответы и идентифицирует узлы, которые еще ближе к «Ключу». Этот процесс продолжается до тех пор, пока не будут найдены восемь ответственных за запись узлов, и запись будет сохранена вместе с ними. Libp2p абстрагирует этот сложный процесс, позволяя нам построить нашу сеть поверх него.
После того, как «Запись» была сохранена среди ближайших одноранговых узлов в сети, мы хотим сохранить как минимум восемь копий записи, даже если узлы, удерживающие их, отключатся. Наш текущий процесс репликации работает следующим образом: каждый узел отслеживает близких к нему одноранговых узлов, то есть свою близкую группу. Всякий раз, когда пир добавляется или удаляется из RT, мы проверяем, не влияет ли это на нашу закрытую группу. Если есть изменения, мы отправляем «ключи записи» нашим коллегам из близкой группы, которые, по нашему мнению, должны хранить эту запись. При получении списка ключей, если одноранговый узел не имеет соответствующей записи, он запрашивает ее у узла, изначально отправившего «Ключ». Если он не может получить запись от узла, который изначально отправил ключ, он запрашивает данные у сети.
Хотя возможна дальнейшая оптимизация, текущий подход к репликации значительно менее ресурсоемкий, чем подход «Libp2p», и эффективно предотвращает потерю данных.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!