Введение Дракона: Изучение Особенностей в Последнем Этапе Разработки Катапульты

Введение Дракона:

Изучение Особенностей

в Последнем Этапе
Разработки Катапульты

 

Обновлено: 04 Июня 2019

Dragon nem

Обновление Катапульты: Особенности Дракона

Катапульта — является следующим полнофункциональным ядром NEM, выпуск которого запланирован на четвертый квартал 2019 года. После выпуска обновления Cow (Корова), основные разработчики ядра выпустили четвертый этап обновлений для сервера Катапульты — которая называется Dragon (Дракон). Обновление Dragon (Дракон) включает в себя несколько ключевых реализаций и улучшений для обслуживания корпоративных функций. 

 

Харвестинг Бенефициарами

Харвестинг – это процесс, с помощью которого ноды (узлы) NEM генерируют блоки и получают вознаграждение. В обновлении Dragon (Дракон) каждая нода (узел) будет иметь возможность задать публичный ключ бенефициара, чтобы разделить процент вознаграждения за харвестинг. Коэффициент совместного использования, будет устанавливаться владельцем ноды (узла) и настраивается в сети. Когда нода (узел) не определяет бенефициара, все вознаграждения будут переданы подписавшему блок.

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

Таким образом, если нода (узел) Амира был выбран консенсусным протоколом для создания блоков, в котором транзакционные сборы составят 100 XEM, Амир получил бы 90 XEM, а Джейк получил бы 10 XEM, в том случае, что блок успешно создан.

Амир производит настройку харвестинга для бенефициара

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

 

Прочитайте больше: Харвестинг и Ноды (Узлы)

 

Инфляция

Ранее мозаику (как цифровой валютный актив в родной сети) можно было создать только с заданными конечными настройками. Однако с внедрением обновления Dragon (Дракон), движок Катапульты, будет поддерживать новые возможности увеличения функций мозаики. С помощью “инфляционной конфигурации”, количество родной мозаики, может быть увеличено на блок. По мере увеличения общего предложения, коэффициент увеличения, может варьироваться в зависимости от высоты блока, это связано из-за настроек сети.

Например, приватная сеть может позволить настроить инфляцию, увеличив количество мозаики (Валюты), которая называется nugget (самородок), таким образом:

starting-at-height-1 = 500

starting-at-height-1000 = 250

starting-at-height-2000 = 0

Согласно конфигурации, будет создано 500 nuggets (самородков) процесс создания будет проходить следующим образом от 1 блока до 999 блока, будет создано 250 nuggets (самородков), далее как только высота блока достигнет 1999 будет создано еще 250 nuggets (самородков). На 2000-м блоке больше не будут создаваться новые мозаики, под названием nuggets (самородки), тем самым положит конец инфляции. Если в первоначальном значении генезис блока (высота блока = 0) было 1 000 000, это означает,  конечный запас nuggets (самородков) будет 1 750 000.

С добавлением инфляции награды за блок для харвестеров будут включать мозаики, созданные из-за инфляции, аналогично майнингу в других криптовалютах. Харвестер будет собирать вновь созданные мозаики, разделяя их с бенефициарами, если ключ бенефициара был настроен.

Введение контролируемой инфляции даст для NEM прежде всего гибкость для поддержки новых экономических моделей токенов.

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

 

Прочитайте больше: Инфляция

Обновленные Модифицированные Мультиподписные транзакции

Модифицированные Мультиподписные Транзакции (MMT) используются по двум причинам:

  1. Трансформация аккаунта в мультиподписной аккаунт.
  2. Изменение настраиваемых свойств мультиподписного аккаунта.

После обновления до Dragon (Дракон) Модифицированные Мультиподписные транзакции (MMT) будут добавлены в Агрегированные Транзакции (Дополнительно прочитать про агрегированные транзакции можете здесь). Таким образом, Мультиподписные аккаунты будут подписывать транзакцию с помощью агрегированных транзакций для их завершения. Если участники не подписали, агрегированную транзакцию, то данная транзакция не будет включена в блок, следовательно, мультиподписная учетная запись не сможет добавить новые подписи.

Для этого изменения было несколько факторов, которые вызвали серьезные осложнения с Модифицированными Мультиподписными Транзакциями (MMT):

  1. Было максимальное количество учетных записей, для которых учетная запись может быть подписавшей стороной.
  2. Учетная запись не может избавиться от мультиподписного аккаунта до тех пор, пока не будет кворума между подписавшими его сторонами.


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

Например, если Джим и Пэм захотят создать мультиподписную учетную запись в Катапульте для фонда колледжа их дочери, они должны будут инициировать Агренированную Транзакциию со своими личными учетными акаунтами в качестве поручителей. В этом случае счет фонда колледжа их дочери будет преобразован в счет с несколькими подписями, если только Джим и Пэм оба согласятся, предоставив свои подписи для создания данного счета.

MMT
Фонд колледжа преобразован в мультиподписной аккаунт с использованием MMT

 

Межсетевая защита от атаки повторного воспроизведения

Обновление Dragon (Дракон) также укрепило безопасность Катапульты, добавив межсетевую защиту воспроизведения от атаки.

Сетевой идентификатор NEM составляет всего один байт (256 различных значений), поэтому при наличии более 256 сетей возможны совпадения. Ранее, если две учетные записи являются частью двух сетей, которые имеют общий сетевой идентификатор, транзакция между учетными записями в одной сети может быть «воспроизведена» в другой сети.

Предположим, что две учетные записи, Эми и Кевин (обе со 100 XEM), являются частью двух сетей (NET1 и NET2) с идентичным идентификатором сети. Эми хочет отправить 50 XEM Кевину, поэтому она создает транзакцию и отправляет ее в сеть NET1. После подтверждения Эми имеет баланс 50 XEM, а Кевин — 150 XEM, как и ожидалось.

Однако Кевин, жадный и хочет взять больше монет у Эми в сети NET2. Поэтому он копирует исходную транзакцию из сети NET1 и отправляет ее Эми в сеть NET2.

Транзакция принимается, поскольку она действительна и подписана. В результате Эми ошибочно подтверждает транзакцию, где списывается  50 XEM в сети NET2 и зачисляется на счет Кевина в сети NET1. У Эми остается нулевой баланс 0 XEM, в то время как Кевин теперь имеет баланс 200 XEM.

Чтобы такого не повторилось и решить данную проблему, с одинаковыми идентификаторами транзакций сети, данные транзакции должны быть различимы, чтобы их нельзя было применять к обеим сетям. Таким образом, в обновлении Dragon (Дракон) создали дополнительный уровень безопасности, добавив префикс хэша генерации сети (который является уникальным для каждой сети) к “полезной нагрузке” данных транзакций перед её проверкой.

(Полезная нагрузка / Request Payload — это любые данные, отправленные в теле запроса)

Signature = account.sign(generationHash +  SpecificTxPayload)

Если Кевин попытается воспроизвести данную транзакцию в сети NET2 в Катапульте (обновление Dragon), то транзакция будет отклонена сетью из-за неправильного генератора хэша сети и полезной нагрузки.

Прочитайте больше: Транзакции

Заметные Незначительные Обновления

Транзакции с Хэш-Блокировкой — Теперь будут принимать мозаики с псевдонимами блокировки. При создании транзакции с хэш-блокировкой можно будет указать псевдоним (идентификатор пространства имен) вместо идентификатора мозаики, что позволит получить более удобный и простой для пользователя опыт использования.

Транзакции с Секретной блокировкой — Позволяют повторно использовать секретный блок, если установленные получатели отличаются.

Брокерский Процесс Катапульты — Данный процесс автоматически перенесет изменения в MongoDB (документоориентированная система управления базами данных) и ZMQ (высокопроизводительная библиотека асинхронных сообщений, предназначенная для использования в распределенных или параллельных приложениях).

Процесс Восстановления в Катапульте — Если сервер Катапульты завершил работу из-за неконтролируемых ошибок, этот процесс восстановит локальное состояние сервера.

Дополнительные ссылки:

https://nemtech.github.io/concepts/harvesting.html

https://nemtech.github.io/concepts/inflation.html

https://nemtech.github.io/concepts/multisig-account.html#multisig-account

https://nemtech.github.io/concepts/aggregate-transaction.html

https://nemtech.github.io/concepts/aggregate-transaction.html#hash-lock-transaction

https://nemtech.github.io/concepts/cross-chain-swaps.html#secret-lock-transaction

 

 

Share