Примеры кода
Начинающим разработчикам всегда рекомендуется прочесть документации по той или иной библиотеке. Это помогает как понять работу библиотеки, так и запомнить возможности, которые можно использовать при разработке приложений. В данном разделе описаны наиболее популярные запросы в виде примеров.
Наиболее используемая библиотека для приложений Golos — golos-lib-js, поэтому примеры с её использованием. Подробная документация на английском с указанием всех методов и их атрибутов доступно по ссылке.
Подключение библиотеки
В зависимости от серверного (nodejs) или браузерного (js) использования библиотеку нужно подключать разными способами.
Для nodejs актуальной инструкцией будет установка библиотеки через
npm install golos-lib-js --save
и подключением её в js файле через
var golos = require('golos-lib-js');
Для js подключения можно либо самому собрать webpack библиотеки через консоль npm build
, либо воспользоваться уже собранной библиотекой от jsDelivr CND или Unpkg CDN. Просто добавьте к файлу script и укажите url библиотеки: <script type="text/javascript" src="https://unpkg.com/golos-lib-js@latest/dist/golos.min.js"></script>
, после чего у вас будет доступ через консоль к глобальной переменной golos
.
Использование публичной ноды
Пока у вашего приложения нет большого потока пользователей, для работы с блокчейном можно использовать и публичные API-ноды от делегатов, их список доступен здесь.
В нём указаны адреса для JSON-RPC запросов через WebSocket over SSL, для запросов через HTTPS просто замените wss
на https
и уберите ws
в конце.
Пример настройки для работы с нодой через HTTPS:
API-запросы
В разделе Плагины и их API были перечислены основные плагины и запросы к ним — все они доступны в библиотеке. Для того, чтобы выполнить тот или иной запрос, достаточно перевести его название в CamelCase.
Например, если вы решили выполнить запрос get_database_info к плагину database_api, то вам необходимо выполнить код:
В случае, если запрос требует входных данных, то вы добавляете их в начало вызова.
Транслирование транзакций (broadcast)
Для каждой операции из протокола Golos существует отдельный метод в библиотеке golos-lib-js, который принимает приватный ключ (для подписи транзакции) и параметры операции. Название операции, аналогично API методам, должно быть переведено в формат CamelCase. Пример кода для трансляции (broadcast) операции account_metadata
(запись в блокчейн мета-данных аккаунта):
Динамические глобальные свойства сети
Часть новичков хотят периодически опрашивать ноду и получать актуальные данные о DGP (Dynamic Global Properties), чтобы на основе этого показывать новые блоки, исполнять условия по необратимому блоку или подсвечивать в списке делегатов последнего, кто подписал блок. Для этого достаточно запрашивать данные по таймеру каждые 3 секунды (время между блоками):
Работа с ключами
Криптографические ключи представляют собой координаты X и Y которые записаны в общепринятом формате DER на эллептической кривой secp256k1 (в качестве хеш-функции служит SHA-256). В библиотеке golos-lib-js преобразования и работа с ключами относятся к модулю golos.auth
.
В Graphene экосистеме придумали механизм человекочитаемых паролей. По причинам перебора использовать их не рекомендуется, поэтому, чтобы усложнить множественный перебор приватных ключей к публичному пришли к определенным правилам формирования ключей в виде конкатенации строк: логин аккаунта, пароль (сложный), тип доступа.
Часть приложений условились использовать эти правила, таким образом упрощая доступ пользователем к разным возможностям аккаунта по общему паролю. Например, пользователь test зарегистрирован используя общий пароль PK3452JENDK332. При авторизации в приложении используя эти логин и пароль, приложение может самостоятельно сформировать ключи нужного типа доступа, просто используя конкатенацию строк. Пользователь хочет перевести токены? Приложение формирует налету приватный активный ключ по строке testPK3452JENDK332active. Пользователь награждает кого-то? Приложение формирует приватный постинг ключ по строке testPK3452JENDK332posting. Это упрощает доступ для пользователя по общему паролю, но лишает гибкости и подвергает опасности аккаунт. Типы доступа имеют разные полномочия и при компрометации доверенного окружения доверенного окружения пользователя или сайта доступ к аккаунту может быть перехвачен.
Регистрация аккаунта
Обычно, при регистрации пользователя, приложение генерирует пароль самостоятельно. Но бывает исключения, когда приложение позволяет использовать свой пароль для генерации ключей. Библиотека позволяет самостоятельно указать строки для генерации ключа в методе golos.auth.toWif(account_login,general_pass,auth_type);
. В примере ниже представлена функция для генерации случайного пароля заданной длины и генерации ключа по нему без привязки к пользователю и типу доступа:
Получить публичный ключ по заданному приватному можно методом golos.auth.wifToPublic(wif)
. Для тех приложений, которые хотят формировать ключи по кокатенации логина, пароля и типа доступа, существует метод golos.auth.getPrivateKeys(account_login,general_pass,auth_types);
. Метод возвращает массив по шаблону result.type для приватных ключей (которые нужно передать пользователю) и result._type_Pubkey для публичных ключей (которые нужно транслировать в блокчейн для сохранения за аккаунтом пользователя).
Конвертация токенов GOLOS в долю сети
Для автоматической конвертации всех доступных токенов GOLOS в долю сети VESTS необходимо запросить информацию об аккаунте и конвертировать их себе же в долю операцией transfer_to_vesting:
Перевод токенов
Пример перевода 1.000 GOLOS из баланса аккаунта в фонд воркеров:
Смена ключей аккаунта
Бывает, что есть необходимость сменить доступы у аккаунта. Это может быть по причине добавления нового ключа, делегирование управления или создание условий для мульти-подписного управления аккаунтом (когда для выполнения операций требуется подпись несколькими ключами).
Полномочия для выполнения операций имеют следующую структуру:
weight_threshold — необходимый вес для одобрения транзакции с операциями нужного типа;
account_auths — массив аккаунтов и их весов. Аккаунты могут добавить вес транзакции при добавлении к ней подписи ключом;
key_auths — массив публичных ключей и их весов.
Система проверяет транзакцию, операции в ней, проверяет наличие подписей задейственных аккаунтов и достаточным ли весом они обладают, для совершения действия положенного типа.
Пример полномочий с одним ключом:
Если у аккаунта будет записаны эти полномочия в тип доступа posting, то для совершения операции награждения блокчейн будет требовать подпись транзакции ключом 5KRLZitDd5c9uZzDgTMF4se4eVewENtZ29GbCuKwbT3msRbtLgi
(которому соответствует указанный в полномочиях публичный ключ GLS6LWhhUzKmYM5VcxtC2FpEjzr71imfb7DeGA9yodeqnvtP2SYjA
).
При делегировании управления другому аккаунту, например test
, необходимо изменить полномочия на:
После этого блокчейн будет требовать подпись либо указанным ключом, либо ключом аналогичного типа доступа аккаунта test
.
Мульти-подписное управление предполагает усложнение полномочий, например для управления 2 из 3 можно использовать полномочие:
Для того чтобы транзакция была принята блокчейном, необходимо добавить подписи как минимум 2 из 3 указанных ключей. В этом примере публичному ключу GLS4uiqeDPsoteSFVbTWPBUbmfzxYkJyXYmA6B1pAFWZ59n4iBuUK
соответствует приватный ключ 5KMBKopgd56MZvV8FYhp5AP7AWFyLKiybqRnZYgjXukw34VRE78
.
Передача права голосования прокси (proxy)
Если пользователь не принимает участие в выборе делегатов, он может делегировать право распоряжаться его долей другому аккаунту. Для этого существует операция account_witness_proxy
, ей может воспользоваться приложение регистратор, чтобы не загружать своего пользователя лишней информацией об устройстве блокчейн-системы.
Если пользователь решит самостоятельно участвовать в выборе делегатов, то первый же голос за делегата отменит прокси.
Custom операции
Когда разработчикам нужно ввести свою структуру в блокчейн, сделать децентрализированное приложение (dApp), которое будет мониторить блоки и учитывать операции в сети — они могут использовать custom операции. Custom операция имеет гибкую структуру:
Разработчики могут сами придумать структуры данных, протокол команд и их учет через custom операции.
Трехсторонние Escrow сделки
Трехсторонние сделки работают по принципу проверки выполнения условий гарантом (agent
). Получатель и гарант должны подтвердить начало сделки операцией escrow_approve
(гарант получает комиссию на этом этапе), иначе при достижении даты дедлайна ратификации (ratification_deadline
) происходит возврат всех токенов инициатору сделки.
Если наступает момент спора, то отправитель или получатель могут инициировать разбирательство операцией escrow_dispute
, после чего принятие решения по сделке передается гаранту (именно он решает кто и сколько токенов получит). Если сделка повисла и долгое время не разрешается — договор истекает (escrow_expiration
) и всеми токенами управляет либо агент (если был открыт диспут), либо любая из сторон сделки.
Создание escrow перевода:
Подтверждение участие в сделке по предложенным условиям (свое участие должны подтвердить гарант и получатель операцией escrow_approve
):
Требование диспута (открыть спор по сделке может отправитель или получатель операцией escrow_dispute
):
Отпустить средства (операция escrow_release
):
Чтобы получить информацию об escrow, необходимо вызвать API запрос get_escrow
плагина database_api
:
Система предложенных операций (proposal)
Для управления системой предложенных операций существует 3 операции: создания предложения, предоставление подписи (обновление), удаление предложения. После создания предложения блокчейн система будет ожидать все необходимые подписи для осуществления операций заложенных внутрь предложения, после чего выполнит их. Если подошел срок истечения, то предложение не будет выполнено. Системой предложенных операций пользуются для управления мультиподписными аккаунтами. Для создания предложения используйте операцию proposal_create
:
Чтобы получить информацию о предложениях сделанных пользователем, нужно выполнить API запрос get_proposed_transactions
к плагину database_api
(будет возвращен массив предложений):
Система предложений поддерживает все существующие операции в блокчейне, но не позволяет смешивать операции требующие разных полномочий (например, операции tranfer
, требующие active полномочия, и операции upvote
, требующие posting полномочия). Предоставить подпись нужного типа доступа можно операцией proposal_update
указав логин подписавшего транзакцию в массиве на добавление или удаления из списка подтвердивших предложение (для этого есть 4 типа массивов: active, owner, posting и key для использования одиночных ключей). Как только предоставлены все необходимые подписи — операции из предложения будут исполнены (при условии, что не указан период review_period_time
), в случае ошибки выполнения повторная попытка будет предпринята при экспирации. Пример:
Предложение может удалить заявитель или любой участник, чья подпись требуется. Для этого достаточно выполнить операцию proposal_delete
подписав её активным ключом:
js запросы к публичной ноде без библиотеки
Если вашему приложению не требуется криптография и подпись транзакций, то вы можете использовать нативные средства для json-rpc запросов через js.
Пример для WebSocket соединения:
Пример для HTTP соединения:
Last updated