Тестирование ARK Core v2: динамические сборы

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

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

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

Если у вас есть какие-либо вопросы, присоединяйтесь к нашему каналу Slack (#devnet), вы сможете задавать вопросы разработчикам ARK и при необходимости запрашивать дополнительные инструкции.

Техническая поломка

Более подробная техническая разбивка описана в Предложении AIP для динамических сборов.

Рассматривая сценарий включения из процесса узла, шаги следующие:

1. Отправка и обработка данных транзакции от клиента / отправителя

Рисунок 1. Отправка и обработка транзакций на узле

2. Форджер запрашивает транзакцию из пула

Когда Forger извлекает транзакции из пула, транзакции проверяются на соответствие. Методы вызываются в соответствии с диаграммой последовательности, приведенной ниже.

Рисунок 2: Подделка, запрашивающая транзакции от узла

Например, базовая транзакция передачи с полезной нагрузкой выглядит так:

В переводе на сериализованную версию этой полезной нагрузки:

Длина сериализованной транзакции составляет 160 байт. Эта длина учитывается в формуле расчета, приведенной в предложении AIP-16.

Размер транзакции варьируется и зависит от размера vendorField. Тип транзакции включается в динамический расчет комиссии, поскольку транзакция голосования или регистрации делегата требует большей вычислительной мощности. Здесь играет роль dynamicOffset. Смещения задаются в настройках сети (network.json). Значения по умолчанию выглядят так:

Динамическая комиссия рассчитывается в соответствии с реализацией формулы, как показано здесь:

И, наконец, процесс получения транзакции из пула показан в следующем фрагменте кода. Этот код выполняется в соответствии с каждой транзакцией перед возвратом к фальсификатору (Рисунок 2 - Фальсификатор, запрашивающий транзакции от узла), методу checkIfDynamicFeeMatch (транзакции).

Помогите нам протестировать

Новые функции и основные функции были протестированы нашей командой внутри компании. Тем не менее, публичное тестирование необходимо для того, чтобы взглянуть на все сценарии использования и исключения с новой точки зрения (разработчики не всегда лучшие тестировщики). Кошельки с динамическими комиссиями будут доступны до выпуска v2 MainNet, в настоящее время для тестирования в DevNet будут доступны только инструменты CLI.

Все приглашаются в нашу DevNet для проведения надлежащего тестирования (присоединяйтесь к нашему Slack, канал #devnet) - от динамических комиссий до транзакций с множеством транзакций и всего остального, о чем вы можете подумать. Чем больше мы будем тестировать, тем лучше будет основа для нашего нового Core v2.

Если вы обнаружите ошибку, предоставьте исчерпывающую и подробную информацию в нашем репозитории GitHub Core (нажмите), где все инструкции уже ждут вас.

Делегаты

Все делегаты, работающие с узлами, будут иметь возможность настраивать сборы в файле конфигурации в соответствии с сетью, для которой они запускают свой узел (например, Файл конфигурации DevNet Dynamic Fee).

Введение в интерфейс командной строки Core Tester

ARK Core v2 оснащен встроенным набором для тестирования. Предполагая, что для установки Core использовался ARK Commander, мы можем перейти в каталог Tester:

cd ~/ark-core/packages/core-tester-cli

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

Чтобы отправить одну или несколько транзакций, вы просто запускаете команды и настраиваете параметры. Как видите, первая команда запускает тестер и сообщает ему, какую транзакцию он будет запускать. «\» В конце означает конец строки, за которой последуют другие параметры (команды). Каждый параметр начинается с «-» и заканчивается «\», указывая на то, что идут другие параметры. Когда вы дойдете до последнего параметра, в конце не будет символа «\». Например, чтобы сгенерировать 2 транзакции, вы должны выполнить следующую команду:

./bin/tester transfer \
-n 2 \
--base-url http://167.114.29.34 \
--passphrase "your 12 word passphrase"

В приведенном выше примере n представляет количество транзакций, которые вы хотите отправить, base-url - это IP-адрес узла, на который транслируется (замените его IP-адресом вашего узла), а парольная фраза - это кошелек, с которого вы хотите отправлять транзакции.

Выполнив команду, вы получите в своем терминале следующий вывод:

Если мы проверим транзакции в dexplorer.ark.io, мы увидим, что две транзакции были подтверждены и подделаны:

Пакет core-tester-cli содержит следующие команды:

./bin/tester перевод - отправка нескольких транзакций
./bin/tester вторая подпись - создание кошельков со второй подписью
./bin/tester delegate-registration - Создание нескольких делегатов
./bin/tester голосование - создание нескольких голосов для делегата
./bin/tester multi-signature - создание нескольких кошельков с несколькими подписями.

Набор tester-CLI хранит адрес и парольную фразу каждого кошелька, созданного в файле ~ / ark-core / packages / core-tester-cli / test-wallets. Вы можете открыть файл, просто открыв его в своем редакторе. Например:

nano ~/ark-core/packages/core-tester-cli/test-wallets

Наш core-tester-cli содержит некоторую базовую справку и параметры. Если вы напишете:

./bin/tester -h

Вы получите базовую помощь, и если вы напишете:

./bin/tester COMMAND NAME -h

Вы получите более подробную информацию о параметрах и команде.

Вы также можете прочитать команды и их важные значения здесь:

Https://github.com/ArkEcosystem/core/tree/develop/packages/core-tester-cli/bin/tester#L23

Установка параметров динамической комиссии в сгенерированных транзакциях

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

Команда перевода содержит опцию `- transfer-fee`, где можно указать точную плату arktoshi.

./bin/tester transfer \
-n 2 \
--base-url http://127.0.0.1 \
--transfer-fee 5000 \
--passphrase "your 12 word passphrase"

Вы также можете указать случайные лимиты для параметров `--transfer-fee`. Например, вы можете указать диапазон комиссии за перевод следующим образом:

--transfer-fee 1000–5000

Это случайным образом выберет различные значения для сборов в указанном диапазоне от 1000 до 5000 арктоши.

Если вы просматриваете вывод своих журналов, вы увидите следующие сообщения:

Давайте выполним следующую команду, сгенерирующую 10 транзакций перевода со случайной комиссией от 29000 до 50000 арктоши.

./bin/tester transfer \
-n 10 \
--base-url http://127.0.0.1 \
--transfer-fee 29000–50000 \
--passphrase "your 12 word passphrase"

В приведенном выше примере комиссии будут генерироваться случайным образом для каждой из 10 транзакций в диапазоне от 29000 до 50000 арктоши. Это отлично подходит для тестирования лимитов и минимальных допустимых комиссий.

Если вы используете настраиваемые порты для API и P2P, у вас есть 2 доступных флага (по умолчанию они установлены на 4002 и 4003, поскольку мы запускаем это в devnet):

--api-port 4003 \
--p2p-port 4002 \

Как установить комиссию для других типов транзакций в Core Tester CLI?

Каждая транзакция имеет свой параметр в пакете core-tester-cli. Посмотрите командный файл тестера, где видны все параметры. В общем, у нас есть следующие варианты настройки динамической комиссии, относящиеся к различным типам транзакций.

./bin/tester перевод с параметром --transfer-fee
./bin/tester вторая-подпись с параметром --signature-fee
./bin/tester delegate-registration с параметром --delegate-fee
./bin/tester vote с параметром --vote-fee
./bin/tester мультиподпись с параметром --multisig-fee

Как мне настроить мой узел для приема динамических сборов?

И последнее, но не менее важное: вам необходимо разрешить вашей ноде (вашему делегату) принимать динамические сборы. Подробный подход изложен в Предложении AIP-16.

Есть два основных шага для настройки и включения динамических сборов.

1. Установка параметров оплаты в качестве делегата

Делегат может определить параметры своей формулы для feeMultiplier и ограничить входящие транзакции с помощью значения minAcceptableFee. Все настройки в АРКТОШИ за байт. Настройки делегата можно найти в delegates.json.

Предполагая, что для установки ядра использовался core-commander, файл конфигурации сети можно открыть с помощью следующей команды:

nano ~/.ark/config/delegates.json

И там у вас есть возможность изменить feeMultipler или minAcceptableFee.

“dynamicFees”: {
 “feeMultiplier”: 1000,
 “minAcceptableFee”: 30000
 }

Если вы его измените, не забудьте перезапустить процесс Core, чтобы загрузить обновленные настройки.

2. Включение динамических сборов

Включите динамические сборы в файле конфигурации сети. Предполагая, что для установки ядра использовался core-commander, файл конфигурации сети можно открыть с помощью следующей команды:

nano ~/.ark/config/network.json

Установив для параметра dynamic значение true и определив новую веху и высоту блока, с которой настройки должны вступать в силу, мы можем включить или отключить динамические сборы на уровне узла.

Например, приведенные ниже настройки позволят принимать динамические комиссии с высоты блока 10 и выше:

"height": 10,
"fees": {
  "dynamic": true

В приведенном ниже примере будет отключена динамическая обработка комиссий начиная с блока 20 и далее:

"height": 20,
"fees":{
  "dynamic": false

Все комиссии будут рассчитываться согласно статическим тарифам, определенным в network.json.