Это машинный перевод. Оригинал на английском здесь: Update 08 June, 2023
По всему миру тысячи узлов все еще жужжат, бережно и беспрекословно храня и воспроизводя фотографии петушков сообщества и непостижимый музыкальный выбор во веки веков. Не волнуйтесь, со временем мы отключим эту тестовую сеть. Мы еще не достигли этого, но со временем сеть становится заметно более стабильной, предсказуемой и масштабируемой, что очень радует. Пожалуйста, продолжайте загрузку и обмен, и опубликуйте свои журналы, если вы видите что-то неблагоприятное.
Под капотом
Некоторые убедительные результаты тестов убедили нас изменить нашу модель репликации данных с push на pull. В модели push, которую мы использовали до сих пор, когда происходит отток (узел отключается), узлы с копиями данных, хранящихся на мертвом узле, выталкивают их на следующий ближайший узел. Некоторым из этих узлов удастся протолкнуть свои фрагменты, другим — нет, но в системе должна быть достаточная терпимость (контролируемая выбором k-value) во избежание потери данных.
Метод извлечения аналогичен, за исключением того, что новый узел, понимая, что он является наследником мертвого узла, запрашивает фрагменты из своей близкой группы. Опять же, некоторые запросы могут быть успешными, другие — нет, но в итоге все фрагменты должны быть получены.
Так какая разница? Это количество отправляемых сообщений и количество дополнительных копий, необходимых для работы модели push. @Qi_ma проводил тесты в экстремальных условиях оттока и обнаружил, что вытягивание лучше по всем показателям — сообщениям, процессору, памяти и коэффициенту успеха. Поэтому переключение было непростым делом. На данный момент мы используем модель вытягивания.
Это намного лучше, но мы все еще видим случайные пропущенные сообщения, поэтому успех еще не на 100%.
В других местах сейчас реплицируются DBC, закладывая основу для оплаты данных, что станет темой будущей тестовой сети. @bochaco создал иллюстрацию DAG Merkle и рассказал, как они строят дерево для куски, которые позволяют нам использовать корень дерева в качестве доказательства платежа за хранение, которое мы воспроизведем здесь.
Доказательства оплаты хранилища генерируются с использованием двоичного дерева Меркла:
Дерево Меркла, также известное как хеш-дерево, представляет собой структуру данных, используемую для проверки данных.
и синхронизация. Это древовидная структура данных, в которой каждый нелистовой узел представляет собой хэш
его дочерние узлы. Все листовые узлы находятся на одной глубине и максимально левые.
возможный. Он поддерживает целостность данных и использует для этой цели хеш-функции.
В Safe, чтобы платить сети за хранение данных, все файлы сначала самошифруются
получение всех фрагментов, за которые пользователь должен заплатить, прежде чем загружать их. Бинарный Меркл
дерево создается с использованием всех этих адресов/имен Xornames кусков, каждый лист в дереве Merkle
содержит значение, полученное в результате хеширования Xorname/адреса каждого фрагмента.
В следующем дереве показано, как будут использоваться два файла A и B, по два фрагмента в каждом.
для построения дерева Меркла:
[ Root ]
hash(Node0 + Node1)
^
|
*-------------------------------------------*
| |
[ Node0 ] [ Node1 ]
hash(Leaf0 + Leaf1) hash(Leaf2 + Leaf3)
^ ^
| |
*----------------------* *----------------------*
| | | |
[ Leaf0 ] [ Leaf1 ] [ Leaf2 ] [ Leaf3 ]
hash(ChunkA_0.addr) hash(ChunkA_1.addr) hash(ChunkB_0.addr) hash(ChunkB_1.addr)
^ ^ ^ ^
^ ^ ^ ^
| | | |
[ ChunkA_0 ] [ ChunkA_1 ] [ ChunkB_0 ] [ ChunkB_1 ]
^ ^ ^ ^
| | | |
*----------------------* *----------------------*
| |
self-encryption self-encryption
| |
[ FileA ] [ FileB ]
Пользователь связывает произведенный платеж с узлами хранения, устанавливая корневое значение дерева Меркла.
как значение 'Dbc::reason_hash'. Благодаря свойствам дерева Меркла пользователь может
затем предоставьте выходной DBC и контрольный журнал для каждого из чанков, оплачиваемых одним и тем же
DBC и дерево на узлы хранения при загрузке фрагментов для их хранения в сети.
@Anselme работал над некоторыми ошибками в сборщике и кошельке, которые в настоящее время не помечают DBC как потраченные в сети. Он также решил некоторые проблемы с регистрацией.
@Roland поднял PR для сбора показателей системы, сети и процессов. Это находится за функциональными воротами, что означает, что его можно включать и выключать в соответствии с нашими потребностями. Во время тестовых сетей полезно собирать метрики от сообщества. Позже мы включим метрики OpenSearch, но пока это простое решение.
У @ChrisO экспериментально работает автоматизированный процесс выпуска тестовой сети. Должны быть готовы к живому действию очень скоро. Он и @aed900 также работали над другими аспектами тестовых сетей, включая управление секретами в Digital Ocean. Ангус также рассматривал проблему, из-за которой частные узлы (за NAT) записываются в таблицу маршрутизации, а это не то, что нам нужно.
К счастью, @bzee, который копался в libp2p, считает, что следующая версия должна решить эту проблему для нас.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!