Обновление Safe Network 🇷🇺 18 августа 2022 г

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

На этой неделе мы более подробно рассмотрим выбросы SNT. Таким образом, после первоначального распределения токенов при создании сети оставшиеся 70% общее количество ресурсов будет создано и безопасно распределено в результате того, что люди будут загружать данные в долгосрочной перспективе. Мы немного глубже подумали о том, как это должно работать, чтобы оно было максимально простым и безопасным, и вырезали пару шагов из нашего первоначального дизайна.

Спасибо @southside за тестирование последних сборок и предоставление журналов :pray:. Изучаем эти всплески и сбои узлов сейчас.

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

@Davidrusu рационализировал журналы, чтобы каждый из них представлял собой одну строку, чтобы их было легче анализировать и удалять постороннюю информацию. К сожалению, в процессе мы сломаем Vdash @happybeing, но, надеюсь, не так, чтобы его было слишком сложно снова разлочить.

Большая часть остальной работы — тестирование тестирования тестирования. Следуя предложению @Chriso, мы вносим некоторые изменения в то, как тесты влияют на ночную сборку, вводим промежуточную ветку и расставляем приоритеты по исправлению сбоев тестов, которые препятствуют выпуску там, чтобы код всегда был готов к выпуску или близок к нему.

А @anselme исправил проблему на этапе трансляции эфемерного ключа BLS в DKG. И ключевая трансляция BLS, и голоса DKG теперь работают правильно, и все участники получают все голоса, что является важным шагом.

Выбросы СНТ

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

Платеж, который приводит к созданию нового («Genesis») DBC, называется (на данный момент) «событием Genesis». Для события «Genesis» требуется «GenesisProof», который представляет собой файл, в котором кодируется информация о значении DBC и его получателях.

Ценность Genesis DBC достаточно проста – это фиксированная часть стоимости транзакции хранения (например, может быть вознаграждено 90% первоначального платежа).

В части получателей все немного сложнее. «Событие Genesis» из транзакции происходит только в одном разделе, и все старейшины и узлы хранения получают оплату пропорционально их возрасту узла. Но членство в секции постоянно меняется, так как же нам узнать, какие узлы платить?

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

Таким образом, лучшим способом было бы использовать получателей платежа «Genesis event». В запросе магазина (котировке) клиенту сообщается, кто должен платить, включая SAP (старейшины) и узлы хранения. Возраст узлов на момент котировки можно рассчитать по их ID. Таким образом, любой из получателей может перевыпустить DBC себе и другим получателям в любое время, и платеж гарантированно дойдет до них, даже если они больше не находятся в разделе, процесс является детерминированным.

Однако нашим первым портом захода для перевыпуска всегда будет клиент (плательщик), так как это снижает нагрузку на сеть. Мы обсуждаем, может ли одним из получателей вознаграждения DBC быть сам клиент, создавая стимул для клиента выполнить повторную выдачу, но если это не удастся, то вместо этого это может сделать любой из сетевых узлов, упомянутых в «GenesisProof».

Плата только за хранение взрослых, а не всех взрослых в разделе (еще один возможный сценарий) работает хорошо, поскольку это означает меньшее количество DBC и меньшее количество сообщений. Со временем платежи осуществляются случайным образом по разделу/сети, поскольку узлы хранения определяются по адресу XOR фрагментов данных.

Вот над чем мы сейчас работаем. Нам все еще нужно выяснить, как установить стоимость хранилища, как сделать майнинг СНТ нерентабельным для мошеннических разделов и где хранить «GenesisProofs».

Мы также стремимся отказаться от прозвища «Genesis» для новых DBC, поскольку оно сбивает с толку. Одно из предложений: «RootDBC» — что вы думаете, о сообщество?


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

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

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