Обновление Safe Network 🇷🇺 26 мая 2022 г

Это машинный перевод. Оригинал на английском здесь: Update 26 May 2022

Наша основная цель с Safe Network — постоянство данных. Мы храним копии данных на устройствах, которые по статистике вряд ли будут находиться в том же регионе, если, например, произойдет массовое отключение электроэнергии или отключение Интернета по инициативе правительства. Для этой цели чем больше копий, тем лучше, но это налагает требования к хранилищу и, в частности, пропускной способности сети. На этой неделе мы рассмотрим один из подходов к решению этой проблемы, который должен обеспечивать большую избыточность при меньшем потоке данных.

Общий прогресс

@Anselme исправил ошибку консенсуса, реализовав антиэнтропию как для передачи, так и для поколений. Более подробные повторные попытки присоединения (где мы гарантируем, что находимся в текущем состоянии раздела) также были объединены :muscle: .

@Chriso копается в реализации DBC и уже выполнил все изменения CLI для передачи DBC новому владельцу. Теперь он обращает свое внимание на сторону sn_api для назначения владельца изменения DBC.

Мы также можем сообщить о прогрессе на фронте наблюдаемости, когда @yogesh добился хороших успехов с сообщениями traceroute, убедившись, что все потоки сообщений (файл и регистр) имеют ответ traceroute обратно клиенту от взрослых и зарегистрированы в тестах.

И @davidrusu распространил информацию, посетив еще одну встречу Toronto CompSci, чтобы поговорить о Tree CRDT. «Отличное обсуждение вокруг», — сообщает он, и отличное место для привлечения заинтересованных сторон в Safe Labs.

В более широком безопасном мире текущий проект сообщества по поддержке MaidSafeCoin в протоколе ERC20 не ослабевает, и мы рады сообщить, что эти усилия продолжают приносить плоды! Таким образом, в дополнение к Uniswap eMAID теперь также открыт для торговли на P2PB2B!

Вы можете поблагодарить преданных членов сообщества, таких как @Sotros25 и @Mightyfool, которые взяли на себя ответственность за постоянное продвижение этой темы :clap:

Оптимизация передачи данных

Когда кто-то делает запрос GET, этот удар запускает ряд процессов. Сначала запрос передается старейшинам, в каком разделе хранится чанк. Затем старейшины вычисляют, какие четыре взрослых хранят фрагмент — четыре XOR-ближайших к адресу фрагмента — и каждый из этих взрослых передает свою копию фрагмента старейшинам, которые затем возвращают их запрашивающему клиенту.

Это обеспечивает избыточность, всегда есть четверо взрослых с копией чанка, а также дает нам возможность отслеживать производительность. Если один взрослый значительно медленнее или менее надежен, его можно понизить в должности. Но это связано с ценой.

Если клиент свяжется со всеми семью старейшинами секции и попросит фрагмент «А» размером 1 МБ, а каждый старейшина, в свою очередь, запросит фрагмент А у четырех взрослых, удерживающих его, и вернет их клиенту, то потенциально это 28 МБ (4x7), передаваемых по сети для один запрос GET размером 1 МБ.

В настоящее время мы используем систему на полпути, в которой клиент связывается с тремя случайными старейшинами, а эти старейшины связываются с четырьмя взрослыми, у которых есть чанк A, поэтому у нас потенциально есть 12 МБ (3x4) данных, протекающих по сети для запроса 1 МБ — лучше, но все равно не супер. А сокращение контактов до трех старейшин дорого обходится: если у нас есть только три старейшины, взаимодействующие со взрослыми, у нас больше нет квалифицированного большинства, чтобы решить, является ли один из взрослых недееспособным, что усложняет отслеживание дисфункции.

Решение, которое мы рассматриваем сейчас, — это алгоритмы рассеивания информации (IDA, также известные как кодирование стирания). Это могло бы помочь нам значительно сократить объем передаваемых данных на GET, заставив взрослых передавать долю данных старейшинам, а не все целиком. Затем старейшины передают эти общие данные обратно клиенту, который собирает их заново, и, вуаля, фрагмент А воссоздается. Потенциально это может уменьшить потоки в GET до 1,4 МБ для фрагмента размером 1 МБ.

Итак, как это работает? Во-первых, мы не предлагаем замену репликации IDA. Некоторые проекты делают это (например, Solana), но для нас слишком много компромиссов. Так что, как и сейчас, если взрослый отключается от сети, его данные полностью реплицируются другому взрослому. Изменение заключается в том, что взрослые смогут разделить фрагмент А на семь частей с помощью IDA и передать старшим по запросу только один фрагмент, а не весь фрагмент, а это означает, что обменивается гораздо меньше данных.

Собрав пять из семи частей, клиент может снова собрать кусок А.

Эта цифра «пять из семи», несомненно, зажгла несколько умственных лампочек :bulb:, потому что это тот же порог, который мы используем для консенсуса BLS, но IDA — это зверь, отличный от пороговой криптографии, предназначенный скорее для оптимизации хранения и передачи данных. чем обмен секретами. Если вам интересно, откуда берутся дополнительные 0,4 (для передачи фрагмента размером 1 МБ с использованием IDA требуется 1,4 МБ потоков данных), это неизбежные накладные расходы из-за того, как работает алгоритм.

Таким образом, меньше нагрузки на сеть и клиента, и, конечно же, все семь старейшин теперь находятся в контакте со взрослыми, что значительно упрощает достижение консенсуса по поводу дисфункции.

Дальнейшие оптимизации также должны быть возможны с этой архитектурой. Из-за недавних изменений в членстве мы теперь знаем, кто из трех взрослых, владеющих куском А, на самом деле ближе всего. Таким образом, вместо того, чтобы спрашивать кусок A, клиент может напрямую попросить у него первый кусок A[0], и старшие пойдут прямо к ближайшему взрослому; второй кусок A[1], старшие будут спрашивать у следующего ближайшего взрослого и так далее. Любые неудачи просто повторяются на другом взрослом. Это более эффективно и означает, что мы потенциально можем увеличить количество реплик — взрослых, содержащих чанк A — без существенной дополнительной нагрузки на сеть, с очевидным выигрышем за счет избыточности данных.


Полезные ссылки

Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.

Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!