Это машинный перевод. Оригинал на английском здесь: Update 30 March, 2023
Иногда, работая с передовыми технологиями, все, что вы можете сделать, — это дождаться развития событий в другом месте. Эти достижения могут быть удручающе долгими, но на этой неделе мы рады объявить о значительном прорыве на сетевом фронте. Мы также добились значительного прогресса в отношении DBC, сборов за транзакции и того, как они обрабатываются старейшинами. @oetyng объясняет больше.
Общий прогресс
Много положительных моментов, о которых стоит поговорить на этой неделе. Во-первых, некоторая мастерская детективная работа @qi_ma 
выявила основную причину давней проблемы, с которой мы столкнулись при работе с сетью. запуск, который вызывал сбои CI. Рад сообщить, что головной боли больше нет.
Теперь о том, что @dirvine описал как «изменивший правила игры», а также, немного загадочно, как «очень расслабляющий». Итак, что это? На этой неделе Protocol Labs, команда разработчиков IPFS и Filecoin, обновила свою библиотеку libp2p. Libp2p оказался довольно успешным в мультиплексировании и пробивке отверстий, но до сих пор он работал только через TCP. Теперь это изменилось, и библиотека работает с UDP и QUIC, которые Safe использует для управления соединениями между узлами. Libp2p используется Filecoin, Eth и Avalanche, и над ним работает множество отличных инженеров.
Более того, мы получаем бесплатную пробивку отверстий, обнаружение локальных узлов, защиту от DoS и многое другое. Похоже, что libp2p теперь является тем, чем она была задумана, и тем, что мы пытались создать с помощью qp2p: надежной библиотекой, ориентированной на p2p. С недавним включением QUIC мы видим, что команда libp2p осознала, что большая часть проделанной ими работы (потоковое мультиплексирование, шум для безопасности и т. д.) выполняется в QUIC.
В любом случае, отличные новости со всех сторон. Это должно означать, что мы, наконец, добились большой стабильности на сетевом уровне и чтобы сетевой уровень работал так, как мы этого хотим. Так что снимаю шляпу перед ребятами из libp2p 
С небольшой доработкой и несколькими PR мы наконец-то сможем заменить Quinn и qp2p в Safe. Ограничения этих библиотек не давали Дэвиду спать по ночам в течение многих месяцев. Наконец-то он может расслабиться. :пляжный зонт:
@bzee уже удалось получить прототип сети Kademlia с libp2p и немного дополнительной работой, которая должна работать в качестве теста. @Roland также изучает документацию, чтобы посмотреть, сможем ли мы использовать это.
@bochaco добавил несколько команд CLI в узел RPC, чтобы разрешить такие вещи, как проверки уровня хранилища, запросы вознаграждения и мутации кошелька.
А @oetyng был на дежурстве по платежам. Подробнее об этом ниже.
Обновление платежной сети
Мы сделали несколько шагов к платежной сети.
Во-первых, как уже было замечено ранее при работе в локальной сети, у нас были клиенты, запрашивающие старейшин за плату (жестко закодированное значение 1 нано) и расширяющие их передачу, чтобы также содержать по одному DBC для каждого старейшины. Это означало, что при отправке токенов каждый потраченный вами ввод DBC будет стоить 7 нано, выплачиваемых Старейшинам.
Но оплата по сути была ожогом. Потому что Старейшина не мог ни увидеть, что им платили, ни получить к ней доступ.
Проверка суммы комиссии
Итак, следующим шагом было введение «ослепления» суммы взноса, чтобы Старейшина мог убедиться, что А. за них была уплачена плата, и Б. что это была достаточная сумма. . Потому что помните, посторонний не может видеть, какая сумма содержится в DBC и для кого она предназначена. У нас должен быть способ рассказать об этом Старейшинам.
Итак, клиенты отправляют пару шифров — зашифрованную информацию — вместе со своим запросом на трату. Когда старейшина получает это, он может расшифровать его и получить следующее:
Индекс деривации
«Индекс деривации» используется для получения открытого ключа (по сути, уникального идентификатора) нового DBC, содержащего оплату комиссии. Клиент получает этот идентификатор из статического открытого ключа, который отправляет Старейшина, вместе с требуемой в настоящее время суммой комиссии за запрос Старейшины.
Старейшина использует тот же индекс деривации для получения соответствующего секретного ключа, с помощью которого они могут разблокировать значение в DBC, содержащее сумму комиссии для них.
Поскольку этот индекс деривации отправляется старейшине в зашифрованном виде, никто не может сказать, что этому старейшине была произведена оплата, и нет возможности узнать, на какую сумму она была выплачена.
коэффициент ослепления + сумма
Кроме того, Клиент отправляет зашифрованный «слепой фактор» и сумму.
С помощью «ослепляющего фактора» старейшина может ослепить сумму и сравнить ее с суммой в транзакции DBC. Это связано с тем, что при использовании одного и того же «ослепляющего фактора» и его количества получается точно такое же неразборчивое искажение. Вот почему «ослепляющий фактор» также зашифрован. Сумма будет известна только Клиенту и Старейшине.
Для получения более подробной информации о приведенном выше потоке вы можете прочитать раздел комментариев в верхней части этого файла: safe_network/mod.rs at main · maidsafe/safe_network · GitHub
Наконец густановление платы
Когда подавляющее большинство Старейшин подписывают расходы, каждый из них отправляет «SpentProofShare» держателям данных в сети. При запросе этих общих ресурсов SpentProof может быть агрегирован из этих подписей, и могут быть созданы DBC, соответствующие каждому из выходных данных транзакции. Таким образом, старейшина может запросить их в сети, а затем построить DBC, который содержит оплату комиссии.
От жестко запрограммированной платы к динамической
Одна нано на комиссию не сильно поможет, поэтому мы раскопали расчет необходимых токенов, чтобы сохранить некоторые данные, которые у нас уже были в наших архивах.
Реализация вычисляет требуемые токены для операций записи как количество токенов, подлежащих оплате за определенное количество байтов, с учетом префикса текущего раздела, количества узлов в разделе и процента заполнения. Это также можно использовать для расчета комиссии за перевод, поскольку мы просто передаем ему фиксированное количество байтов.
Учитывая входные параметры и дизайн кривой, есть влияние на цену, основанное на спросе и предложении, хотя и с некоторой инерцией. Вычисленное значение выше, когда в секции меньше узлов, когда меньше доступного места и раньше в сети. Ранее в сети? Вы можете спросить. Да, предполагается, что более крупная сеть означает, что токен имеет большую ценность, поскольку большее количество людей использует постоянное количество токенов. Следовательно, необходимое количество токенов на операцию также уменьшается по мере роста сети. Другими словами, цена отражает дефляционный характер СНТ.
Еще одним свойством кривой является то, что она очень плоская на низком уровне, пока не останется около 1/3 пространства, после чего она начинает быстро нарастать. Причина в том, чтобы комиссия оставалась как можно более низкой как можно дольше.
Но это не замена настоящему рынку. Несмотря на то, что у нас есть некоторый контроль над спросом/предложением, он довольно вялый, и размер комиссии, основанный на этом, довольно жесткий. Поэтому сети трудно отражать фактические изменения фиатной стоимости токена, и это может привести к большим дисбалансам, что никогда не бывает хорошо. Таким дисбалансом может быть слишком много запросов или слишком мало, потому что фактическое значение не синхронизировано со значением, рассчитанным на основе параметров сети.
Это подводит нас к возможности для Клиента расставить приоритеты в своих расходах и к тому, что это открывает для нас.
Очередь с приоритетом расходов
«Приоритет», связанный с затратами, — это большой скачок вперед к настоящему рынку, где характеристики спроса и предложения системы гибкие и реагирующие.
Это делается старейшинами, поддерживающими * приоритетную очередь *, упорядоченную по величине платы, уплаченной им за подписание расхода.
Преимущества реализации приоритетной очереди следующие:
- Клиенты могут получить более низкую цену за свое хранилище, если спрос низкий.
- Старейшины могут получить более высокую награду за свои услуги, если спрос высок.
- Поощрения операторов узлов за запуск дополнительных узлов увеличиваются по мере увеличения спроса.
- Сеть становится более отзывчивой и может расти быстрее (привлекать больше узлов для запуска) при увеличении спроса.
- Непрерывная работа узлов более защищена от перегрузки клиентских расходов.
- Нагрузка на сеть распределяется во времени, поскольку люди откладывают расходы в периоды высокой нагрузки и перемещают их в периоды меньшей нагрузки.
- У Старейшин есть потенциал для более быстрого доступа к своим наградам, поскольку они могут собирать их и перевыпускать в более крупный DBC, когда сборы низкие.
- …и более…
В первом примере используется несколько дискретных «приоритетных» шагов для клиента, которые можно использовать из пользовательского интерфейса кошелька при выполнении платежа. Это устраняет необходимость вручную устанавливать размер комиссии.
Приоритет преобразуется в комиссию на основе текущих комиссий в очереди. Высокий приоритет будет означать, что вы платите аналогичную сумму тем, кто выше в очереди, и наоборот, для низкого приоритета. Вы также можете установить его выше самого высокого значения или ниже самого низкого, и именно здесь может начаться давление на цену, основанное на спросе и предложении, а также на потребностях клиентов и операторов узлов в поиске равновесия.
Выбирая приоритет, Клиент, по сути, решает, как быстро он хочет, чтобы он был обработан. Они могут обработать его более или менее мгновенно или установить комиссию на более низком уровне, чтобы он обрабатывался в то время, когда спрос и сборы ниже.
Обратите внимание, что по-прежнему существует ограничение на то, насколько низкая комиссия может быть установлена Клиентом. Ниже этого он будет удален, и клиенту будет возвращена ошибка.
Клиент также должен иметь возможность обновлять незавершенные расходы, чтобы они не застряли там, если сборы и спрос останутся на более высоком уровне.
Краткое содержание
Итак, подытоживая, основная идея заключается в том, что расход DBC может привести к множеству выходных DBC. Когда мы отправляем запрос старейшинам на трату DBC, мы также прикрепляем эти выходные данные.
Затем старейшины проверяют сумму и приступают к обработке расходов.
Внимательный читатель заметил бы, что вознаграждение, уплачиваемое старейшине, находится в DBC, и когда старейшина захочет потратить этот DBC, то для его расходования потребуется плата, и еслидва одинаковых… значит у тебя… ничего?
Это именно так. Итак, если мы вспомним, что алгоритм цен возвращает более низкие значения, чем больше сеть, мы можем увидеть, что существует своего рода эффект блокировки + ранняя пташка. По мере снижения номинальной стоимости комиссии предыдущие уплаченные комиссии будут становиться все более и более «доступными».
Здесь также помогает приоритетная очередь. Сборы, которые были получены во время высоких нагрузок, могут быть собраны и перевыпущены, когда сборы ниже. Еще один фактор, который работает, чтобы выровнять нагрузку.
Надеюсь, это даст вам всем некоторое представление о том, что назревает.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!