Это машинный перевод. Оригинал на английском здесь: Update 26 May 2022
Наша основная цель с Safe Network — постоянство данных. Мы храним копии данных на устройствах, которые по статистике вряд ли будут находиться в том же регионе, если, например, произойдет массовое отключение электроэнергии или отключение Интернета по инициативе правительства. Для этой цели чем больше копий, тем лучше, но это налагает требования к хранилищу и, в частности, пропускной способности сети. На этой неделе мы рассмотрим один из подходов к решению этой проблемы, который должен обеспечивать большую избыточность при меньшем потоке данных.
Общий прогресс
@Anselme исправил ошибку консенсуса, реализовав антиэнтропию как для передачи, так и для поколений. Более подробные повторные попытки присоединения (где мы гарантируем, что находимся в текущем состоянии раздела) также были объединены 
.
@Chriso копается в реализации DBC и уже выполнил все изменения CLI для передачи DBC новому владельцу. Теперь он обращает свое внимание на сторону sn_api для назначения владельца изменения DBC.
Мы также можем сообщить о прогрессе на фронте наблюдаемости, когда @yogesh добился хороших успехов с сообщениями traceroute, убедившись, что все потоки сообщений (файл и регистр) имеют ответ traceroute обратно клиенту от взрослых и зарегистрированы в тестах.
И @davidrusu распространил информацию, посетив еще одну встречу Toronto CompSci, чтобы поговорить о Tree CRDT. «Отличное обсуждение вокруг», — сообщает он, и отличное место для привлечения заинтересованных сторон в Safe Labs.
В более широком безопасном мире текущий проект сообщества по поддержке MaidSafeCoin в протоколе ERC20 не ослабевает, и мы рады сообщить, что эти усилия продолжают приносить плоды! Таким образом, в дополнение к Uniswap eMAID теперь также открыт для торговли на P2PB2B!
Вы можете поблагодарить преданных членов сообщества, таких как @Sotros25 и @Mightyfool, которые взяли на себя ответственность за постоянное продвижение этой темы 
Оптимизация передачи данных
Когда кто-то делает запрос GET, этот удар запускает ряд процессов. Сначала запрос передается старейшинам, в каком разделе хранится чанк. Затем старейшины вычисляют, какие четыре взрослых хранят фрагмент — четыре XOR-ближайших к адресу фрагмента — и каждый из этих взрослых передает свою копию фрагмента старейшинам, которые затем возвращают их запрашивающему клиенту.
Это обеспечивает избыточность, всегда есть четверо взрослых с копией чанка, а также дает нам возможность отслеживать производительность. Если один взрослый значительно медленнее или менее надежен, его можно понизить в должности. Но это связано с ценой.
Если клиент свяжется со всеми семью старейшинами секции и попросит фрагмент «А» размером 1 МБ, а каждый старейшина, в свою очередь, запросит фрагмент А у четырех взрослых, удерживающих его, и вернет их клиенту, то потенциально это 28 МБ (4x7), передаваемых по сети для один запрос GET размером 1 МБ.
В настоящее время мы используем систему на полпути, в которой клиент связывается с тремя случайными старейшинами, а эти старейшины связываются с четырьмя взрослыми, у которых есть чанк A, поэтому у нас потенциально есть 12 МБ (3x4) данных, протекающих по сети для запроса 1 МБ — лучше, но все равно не супер. А сокращение контактов до трех старейшин дорого обходится: если у нас есть только три старейшины, взаимодействующие со взрослыми, у нас больше нет квалифицированного большинства, чтобы решить, является ли один из взрослых недееспособным, что усложняет отслеживание дисфункции.
Решение, которое мы рассматриваем сейчас, — это алгоритмы рассеивания информации (IDA, также известные как кодирование стирания). Это могло бы помочь нам значительно сократить объем передаваемых данных на GET, заставив взрослых передавать долю данных старейшинам, а не все целиком. Затем старейшины передают эти общие данные обратно клиенту, который собирает их заново, и, вуаля, фрагмент А воссоздается. Потенциально это может уменьшить потоки в GET до 1,4 МБ для фрагмента размером 1 МБ.
Итак, как это работает? Во-первых, мы не предлагаем замену репликации IDA. Некоторые проекты делают это (например, Solana), но для нас слишком много компромиссов. Так что, как и сейчас, если взрослый отключается от сети, его данные полностью реплицируются другому взрослому. Изменение заключается в том, что взрослые смогут разделить фрагмент А на семь частей с помощью IDA и передать старшим по запросу только один фрагмент, а не весь фрагмент, а это означает, что обменивается гораздо меньше данных.
Собрав пять из семи частей, клиент может снова собрать кусок А.
Эта цифра «пять из семи», несомненно, зажгла несколько умственных лампочек 
, потому что это тот же порог, который мы используем для консенсуса BLS, но IDA — это зверь, отличный от пороговой криптографии, предназначенный скорее для оптимизации хранения и передачи данных. чем обмен секретами. Если вам интересно, откуда берутся дополнительные 0,4 (для передачи фрагмента размером 1 МБ с использованием IDA требуется 1,4 МБ потоков данных), это неизбежные накладные расходы из-за того, как работает алгоритм.
Таким образом, меньше нагрузки на сеть и клиента, и, конечно же, все семь старейшин теперь находятся в контакте со взрослыми, что значительно упрощает достижение консенсуса по поводу дисфункции.
Дальнейшие оптимизации также должны быть возможны с этой архитектурой. Из-за недавних изменений в членстве мы теперь знаем, кто из трех взрослых, владеющих куском А, на самом деле ближе всего. Таким образом, вместо того, чтобы спрашивать кусок A, клиент может напрямую попросить у него первый кусок A[0], и старшие пойдут прямо к ближайшему взрослому; второй кусок A[1], старшие будут спрашивать у следующего ближайшего взрослого и так далее. Любые неудачи просто повторяются на другом взрослом. Это более эффективно и означает, что мы потенциально можем увеличить количество реплик — взрослых, содержащих чанк A — без существенной дополнительной нагрузки на сеть, с очевидным выигрышем за счет избыточности данных.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!