Это машинный перевод. Оригинал на английском здесь: Update 12 January, 2023
Во-первых, большое спасибо всем, кто участвовал в нашей тестовой сети на прошлой неделе. Мы считаем это успешным, так как все наши последние изменения работали, как и ожидалось, и сеть оставалась стабильной, пока не была заполнена. Хорошая вещь. :тада:
Некоторые из вас заметили, что нам требовалось 7 старейшин, чтобы ответить клиенту, а не 5. Это потому, что мы намеренно жестко тестировали соединения и следили за тем, чтобы все работало правильно. Мы заняты внедрением дополнительных улучшений и бросим вам еще одну тестовую сеть, как только они будут введены. Но «все старейшины должны ответить» и аналогичные требования «строгого режима» останутся в силе еще некоторое время.
В фоновом режиме команда работала над более тонкими деталями распределения токенов. @JimCollinson ведет нас туда, куда мы должны.
Общий прогресс
@qi_ma и @roland продолжают упрощать процесс переезда. Это одна из самых сложных областей, в которой нужно разобраться. Сначала старейшины должны заметить, что узел исчез, и проголосовать за этот факт. Затем им нужно проголосовать за изменение членства, уведомить кандидата о замене отсутствующего узла, а затем обменяться сообщениями, чтобы у нового узла была вся необходимая информация, прежде чем данные будут переданы ему. Итак, много движущихся частей, и чем проще мы сможем это сделать, тем лучше.
Чтобы отслеживать эти сложные процессы, нам нужна надежная система наблюдения, которой занимается @chriso. В настоящее время он работает над тем, чтобы OpenSearch и OpenTelemetry работали с Amazon ECS.
@Roland также совершенствует графический интерфейс для использования с сейфом, чтобы устранить необходимость использовать ужасную командную строку. Должна быть демо-версия в ближайшее время.
@Joshuef продолжает сокращать количество сообщений, которые мы обрабатываем между узлами. Кажется, мы связываемся с узлами, которые находятся за пределами раздела, а затем ждем ответов, которые никогда не приходят, что приводит к ошибкам.
@bochaco завершил удаление потока отправки из Cmd::SendMsg, представив новую команду для разделения потоков, предназначенных исключительно для потоков.
И @anselme обращает внимание на некоторые рефакторинги DBC. Подробнее об этом позже.
Обновления планов безопасного распространения токенов сети
Привет народ. Небольшое обновление для RFC о распределении токенов, пока мы обходим некоторые решения.
Есть много движущихся частей; от технических возможностей, проектных предложений, эксплуатационных соображений до юридической обратной связи. Многое уходит на настройки, которые на первый взгляд могут показаться незначительными, поэтому мы благодарим вас за всю поддержку, терпение и ваши обширные комментарии и отзывы в последней ветке RFC 0061.
Эмиссия токенов и предложение Genesis
Самое большое изменение здесь — это ответ на вопрос о том, чеканим ли мы общий объем при запуске сети, и как и когда создаются и затем распределяются 70% оставшихся токенов.
Чеканка всего предложения при запуске требовала, чтобы либо Фонд, либо сама Сеть держали, а затем распределяли эти токены с течением времени, и у обоих из них есть серьезные проблемы, которых мы хотим избежать, главная из которых — безопасность, а также справедливое распределение значительной части токенов. экономическая мощь.
Напоминание о том, что целью было A. постепенное высвобождение оставшихся токенов, и в то же время B. хранение токенов в сети.
Решение здесь состоит не в том, чтобы чеканить их заранее, а в том, чтобы Сеть выпускала их с течением времени — создавая их по мере роста Сети — и выплачивая их операторам узлов в качестве вознаграждения за поставку ресурсов.
Несмотря на то, что это по-прежнему громоздкая работа, которую вряд ли можно завершить без задержки запуска сети, мы удовлетворены тем, что это разумное дизайнерское решение в пределах досягаемости, которое можно реализовать с помощью обновления сети после запуска.
Таким образом, предложение Genesis, циркулирующее при запуске, будет составлять 30% от максимального предложения, а оставшаяся часть начнет появляться только после того, как удовлетворительное, безопасное и надежное решение будет представлено и развернуто; а затем эти токены будут поступать участникам сети в течение длительного периода, вероятно, десятилетий.
Другие мелкие изменения
Вы также заметите некоторые другие незначительные изменения, такие как формулировка, описывающая право на получение сетевых роялти в качестве разработчика приложений; более точное распределение SNT для акционеров; и прямо заявляет, что eMaid будет обмениваться 1:1 на токены Safe Network, точно так же, как и оригинальный вариант MaidSafeCoin.
Максимальный запас
Вы заметите изменение термина с «Общее предложение» на «Максимальное предложение», которое сделано для того, чтобы лучше сформулировать изменения, связанные с эмиссией токенов и предлагаемым генезисным предложением.
Одна вещь, которую мы предлагаем, остается от RFC, это изменение первоначального предела Safecoin в 2 ^ 32 на максимальное предложение в 4 525 524 120. Это сделано для того, чтобы устранить причуду оригинальной краудсейла, в ходе которой была выпущена сверхчеканка M.ПОМОГАТЬ.
Но важно отметить, что:
- Ни инвесторы, ни участники краудфандинга, ни держатели MAID не остаются в проигрыше.
- Долго разрекламированный обмен 1:1 Maid на SNT сохраняется; который легко описать и понять, и его очень полезно поддерживать для удобства использования при переходе в сеть с помощью MAID.
- В связи с кардинальными техническими изменениями токены больше не привязаны к сетевым адресам. Это допускает такие вещи, как делимость, но также дает нам свободу указывать подходящий максимальный запас.
- Максимальное предложение MAID известно и рекламируется уже почти десятилетие, оно отображается на каждой бирже и в блокчейн-приложении вместе с условиями погашения 1:1, так что это неудивительно.
- Это более чистое решение, и мы считаем, что проще объяснить распределение 5/10/15%, выделенное первоначальным распределительным пулам, и их долю в общей экономике, чем повторно исследовать, почему MAID теперь составляет 10,37%.
Мы знаем, что некоторым из вас этот выбор не понравится, но это один из двух эстетических/эргономических вариантов, оба из которых приводят к одному и тому же результату, поэтому мы выбрали то, что, по нашему мнению, является путем наименьшего сопротивления.
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!