Обновленные методы API-Minter от Monster’s Club + размышления на тему

Сегодня у нас абсолютно не интересная для обычных пользователей Minter статья , однако многие разработчики продуктов на MInter ждут ее с нетерпением уже больше недели (так что подумайте нужно ли вам это читать если вы не планируете создавать своих продуктов, ботов, сайтов в блокчейне Minter)

Я полностью переработал представленный мной ранее пакет методов API-Minter. За последние 3 недели ко мне часто обращались с просьбами добавить те или иные методы, в результате получился данный пак. Все методы максимально стандартизированы и упрощены, что облегчает их использование и значительно высвобождает мощности оборудования.

Практически все методы поддерживают параметр height, что позволяет получать информацию на конкретный блок, однако не стоит забывать, что большая часть данных в детализации хранится только на указанное количество блоков, к примеру на моих API-нодах хранится 120000 блоков истории(примерно неделя реального времени). Если же вам достаточно истории на "прям сейчас", то height можно вообще не указывать, что я и буду делать ниже.

Не забывайте что в API все суммы монет указаны в pip (наименьшая неделимая часть любой монеты), а значит 1 bip = 1000000000000000000 pip.

Все примеры для удобства убрал в ссылки:

1) /get_stakes - позволяет получить все стейки по любым из трех параметров или их комбинациям

pub_key - выведет все стейки в конкретной мастерноде

coin - покажет все стейки в определенной монете

address - найдет все стейки определенного кошелька

pub_key=_&coin=_&address=_ - параметры можно комбинировать любым удобным способом, к примеру получить список стейков MonsterNode в монете TAXFREE или вообще не указать ни одного параметра и получить список всех стейков во всех нодах, но учитывайте что крайний вариант весьма ресурсоемкий и зачастую приемлем только при локальном использовании.

2) /total_slashed - выдаст bip_value всех монет сожженных в сети. Просили - сделал.

3) /height_by_time - один из моих любимых методов позволяющий определить номер блока какой блок был сутки или неделю назад, или 30 апреля в 5 часов 44 минуты 22 секунды. Метод высвобождает весьма приличный объем ресурсов необходимых для хранения такого бесполезного параметра как время создания блока в своей базе данных и позволяет настроить индекс по номеру блока. Очень полезен для рейтингов и прочих сервисов, которым необходимо сравнение данных к примеру текущих и сутки назад.

4) /frozzed - еще один метод о котором меня просили многие разработчики. Без дополнительных параметров выдает все "замороженные" средства - unbounds,проверяет есть ли анбоунды по конкретному кошельку или монете.

5) /calc_tx_commission - альтернативный метод позволяющий определить размер комиссии по еще не сформированной транзакции.

Метод весьма сложный, поэтому опишу его параметры чуть подробнее:

gascoin - указывает в какой монете считать комиссию за транзакцию

payload - так же влияет на стоимость, потому нужно указать в {...}

txtype - типа транзакции(SendTx, ConvertTx, DeclareCandidacyTx, DelegateTx, UnbondTx, ToggleCandidateStatus, EditCandidate, RedeemCheckTx, CreateMultisig, MultiSend)

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

6) /calc_tx_free_coin - аналогично предыдущему методу, но дополнительно выдает информацию о том сколько монет остается свободных для перевода. Думаю приятно сделать перевод монет MNST оплатив комиссию ей же и ни оставить ни одного pip-MNSTна кошельке.

7) /address_balance - подробный баланс кошелька с учетом количества и стоимости всех имеющихся и делегированных монет во все ноды (может использоваться как с параметром height=, так и без)

Идеальный метод для сервисов кошельков. Выдает информацию быстро и сразу рассчитывает стоимость каждой кастомной монеты в bip и общую стоимость всех монет на кошельке с учетом делегированных.

Просто идеально. Один запрос и сразу вся нужная информация.

8) /candidate_info - метод позволяющий получить подробную информацию о конкретном кандидате, к примеру MonsterNode.

От предыдущей версии отличается тем что был оптимизирован код и произведено деление кандидатов на 3 типа:

a) ноды не отправившие команду set candidat on, отключеные через set candidat off или выпавшие из валидирования по причине падения (status = 1) в моей терминологии это Кандидат

б) ноды готовые валидировать, но не проходящие в валидаторы по стейку (status=2), я называю их Претендент

в) Активные валидаторы (status = 3), ну валидатор и есть Валидатор.

Напомню что в базовой версии candidate в параметре status только 2 значения.

9) /candidates_info - метод аналогичный предыдущему, но выводит ни одного, а сразу всех кандидатов, валидаторов и претендентов. А можно вывести к примеру только тех кто является валидатором или тех кто готов валидировать, но ему не хватает стейка, для этого можно указать status.

10) /nosign - удобен для сбора данных о том кто не подписал конкретный блок. Способ легче и быстрее чем запрашивать всю информацию о блоке и обрабатывать ее. Дополнительно выдает информацию о том кто являлся пропоузером блока когда кто то пропустил.

11) /txs_from_block - аналогично предыдущему методу выдает только нужное, что облегчает запрос относительно /block и ускоряет получение данных. Незначительно, но все же на 100к запросов экономия времени составит порядка 35%. Мелочи заметны в тираже.

12) /find_events - поиск eventов по кошельку или PublicKey валидатора, или по тому и другому в конкретном блоке

Мультизапрос удобен тем что можно выводить и парсить не все events сети на конкретный блок, а только те которые необходимы, например по конкретному кошельку или нескольким кошелькам или валидатору, а можно и в комбинированном варианте.

Фишка запроса что при разумном использовании он быстрее родителя /events раз в 50-100, т.к. обрабатывает и выводит только НЕОБХОДИМЫЕ данные.

13) /grouped_events - Информация по распределению наград с валидирования по конкретному блоку в разрезе валидатора и типов ревардов

Один из самый странных запросов, но может быть применим для ряда сервисов для более быстрого и удобного парсинга сгруппированных данных по ревардам. Шустрее родителя раз в 200 за счет того что не выводит слайсы по каждому реварду

Все описанные выше методы выложены на GitHub в нашем репозитории https://github.com/MNSTteam

Но это не все... Теперь ряд моих мыслей. Сейчас работаю над вариантом платного API и есть за ним будущее однозначно. Пока что только формирую только наброски и специальные платные методы. вот некоторые из них:

1) /accounts - самый тяжелый из всех существующих методов. По сути он обрабатывается порядка 15 секунд и в это время забирает практически все ресурсы машины, но оно того стоит. Выдачей являются ВСЕ балансы всех кошельков в блокчейне в разрезе монет. После максимальной минимизации выдачи это более 12 мегабайт данных если запрашивать без дополнительных фильтров. Или можно запросить информацию по конкретной монете. В качестве примера вот выдача по монете DOBRO

А вот кусок общей выдачи по всем монетам:

Метод конечно плохо читаемый визуально, но как альтернатива держанию данных в базе просто идеален. 15 секунд и у тебя все балансы всех пользователей блокчейна. Сейчас он на ноде закрыт специальным API-Key. И его я пока на GitHub выкладывать не планирую... Очень уж много нервов, усилий и затрат ушло на его создание.

2) /addresses_balances - мультизапрос балансов кошельков очень удобен и быстр. в запросе тестировали 200 кошельков, и такая обработка заняла около секунды. удобно:

3) /nosigns за пару секунд может обработать до 10000 блоков и вывести все пропуски валидаторов:

4) /txs_from_blocks тоже классный запрос для парсинга транзакций. 1 запросов выдает все транзакции в указанном количестве блоков. Максимально прописанное значение 1000 блоков.

Вот эти 4 метода сейчас у меня не будут выкладываться в GitHub, но будут доступны в специальных сборках с вшитыми уникальными ApiKey. Условия обговариваются индивидуально. Я думаю такая математика разумна и будет интересна многим.

Как и всегда все идеи и предложения можно озвучить мне лично в телеграм @alexeyxl или в чат @mnstRU