Веб-семинар Lisk Bills уже открыт на нашем канале YouTube. Подпишитесь на дополнительные образовательные материалы для разработчиков.

Фаза Alpha SDK в Lisk официально началась в конце июля с выпуском SDK 2.1.0. Мы решили, что может быть лучше для демонстрации потенциала пользовательских транзакций, чем создание собственного приложения для проверки концепции (PoC) на блокчейне. Чтобы максимально изучить возможности пользовательских транзакций, мы решили создать приложение для выставления счетов и с его помощью зарегистрировать две новые пользовательские транзакции в нашей цепочке блоков.

Введение в пользовательские транзакции

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

Начало этапа Alpha SDK нашей дорожной карты позволяет вам создавать собственные проверочные блокчейн-приложения, соответствующие нашей архитектуре. Этот этап нашей дорожной карты также позволяет нам получать отзывы о том, как можно улучшить опыт разработки, путем обсуждения на каналах нашего сообщества.

Пользовательские транзакции для развития экосистемы Lisk

Пользовательские транзакции предлагают большую бизнес-ценность для экосистемы Lisk, поскольку они позволяют проявить много творчества. Мы считаем, что пользовательские транзакции являются творческой искрой для экосистемы Lisk, позволяющей увидеть создание целого ряда инновационных проектов. Мы уже видим, как члены сообщества предлагают свои собственные решения, начиная от системы отслеживания велосипедов на прокатном оборудовании Lisk.Bike до использования нашей модульной библиотеки JavaScript для инновационного подхода к классической стратегической игре Lisk. Крестики-нолики". Пришло время проявить творческий подход!

Преимущества пользовательских транзакций

Каждый объект транзакции может хранить данные в своем поле asset. Пользовательские транзакции умело используют это. Использование поля asset позволяет передавать в транзакцию любые данные JSON. Это обеспечивает большую гибкость и творческий подход при определении пользовательской логики.

Кроме того, каждая настраиваемая транзакция может получить доступ и изменить все данные, связанные с учетной записью, и только читать данные, связанные с транзакцией, из базы данных. Это позволяет более совершенное взаимодействие между данными и даже между различными пользовательскими транзакциями. Например, наш PoC использовал данные из транзакции Invoice для проверки действительности транзакции Payment.

Вы также можете создать токен в поле актива с некоторой базовой логикой передачи и проверки. В конце концов, это просто еще один способ логики смарт-контрактов.

Давайте продолжим изучение технических характеристик нашей PoC Lisk Bills.

Lisk Bills - выставление счетов на основе блокчейна

Поскольку нам нравится подход Keep it Simple and Stupid (KISS), мы создали минимальный интерфейс с React, который использует Lisk Alpha SDK для прямого взаимодействия с вашим блокчейн-приложением. PoC включает двух участников, клиента и фрилансера.

Представьте себе Алису (фрилансер) и Боба (клиента). Боб ищет новый логотип для своего веб-сайта и решает проконсультироваться с фрилансером. В поисках хорошего дизайнера он встречает Алису, которая предлагает несколько впечатляющих дизайнов в своем портфолио. Боб так взволнован, что решает немедленно применить набор навыков Алисы.

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

По указанной выше причине Боб просит Алису создать счет с помощью специальной транзакции Lisk.

Для этого Алиса сначала должна войти со своей парольной фразой в приложение Lisk Bills.

Специальная транзакция 1: счет-фактура

Теперь Алиса вошла в систему и может создавать счет. Чтобы создать заказную транзакцию счета-фактуры, Алиса должна ввести следующие данные:

  • Client содержит адрес Lisk или название компании Боба.
  • RequestedAmount содержит сумму, которую Боб причитается Алисе.
  • Description для описания предоставленных дизайнерских услуг.

Следующие данные хранятся в поле актива транзакции. Поскольку это обычная BaseTransaction, мы можем просто указать адрес Lisk Боба в качестве получателя транзакции.

Прежде чем мы углубимся в технические подробности, убедитесь, что открыт или клонирован репозиторий lisk-sdk-examples. Код для обеих пользовательских транзакций можно найти в invoice / transaction / invoice_transaction.js и invoice / transaction / payment_transaction.js.

Технические характеристики

Прежде всего, давайте взглянем на определение класса. InvoiceTransaction расширяет BaseTransaction, что означает, что он наследует его свойства. Как следует из названия, BaseTransaction - это самый простой интерфейс для создания новых типов транзакций. В системе существуют и другие типы транзакций, позже мы покажем пример расширения типа TransferTransaction.

При расширении BaseTransaction мы можем предоставить дополнительную бизнес-логику для следующих методов: Подготовка, Проверка актива, Применить актив и Отменить актив. Вы можете узнать больше об этих методах в нашей документации.

Также обратите внимание на функцию статического геттера для получения типа транзакции. В качестве примера мы выбрали 13 в качестве номера типа для этой транзакции. Кроме того, вы можете установить комиссию, которую пользователи должны платить за использование этого типа транзакции. На данный момент мы установили это значение на 1 LSK (от 10 до 8-го постельного белья).

Подготовить

Функция подготовки отвечает за загрузку необходимых данных, используемых внутри функций applyAsset() и undoAsset(). Здесь мы пытаемся загрузить данные учетной записи отправителя, поскольку мы хотим добавить данные в его поле asset в функции applyAsset(). Эти данные будут загружены из объекта StateStore, который обеспечивает доступ к данным в базе данных.

Мы можем кэшировать учетную запись отправителя таким образом, передав массив с фильтрами.

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

Подтвердить объект

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

Применить объект

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

Отменить объект

Не стоит недооценивать важность функции undoAsset(). Функция Отменить позволяет нам вернуться к предыдущему состоянию цепочки блоков. Следовательно, мы должны точно указать нашему блокчейн-приложению, как оно должно откатывать изменения.

Функция Undo наиболее важна для механизма восстановления вилки. В случае, если в цепочке с кончиком B возникает вилка, и мы хотим откатиться до общей высоты, чтобы повторно применить блоки до кончика цепочки A, нам понадобится функция Undo для выполнения собственно откат к этой общей высоте.

Для подтверждения концепции счета-фактуры код сокращает invoiceCount и удаляет идентификатор счета-фактуры из массива invoicesSent.

Хорошо, мы изучили функции для транзакции счета-фактуры. Перейдем к платежной операции.

Специальная транзакция 2: Платеж

Теперь, когда Боб получил транзакцию по счету в свой кошелек, он решает оплатить счет. Для выполнения транзакции мы обычно отправляем TransferTransaction, который изначально поддерживается Lisk SDK.

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

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

Вот как выглядит реализация пользовательского интерфейса для оплаты счета с помощью нашего приложения Lisk Bills.

Технические характеристики

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

Также обратите внимание, что мы не определяем статическую функцию получения для FEE. Мы не реализовали его здесь, так как не хотим перезаписывать FEE, определенный в TransferTransaction. Короче говоря, мы хотим использовать комиссию 0.1, определенную в TransferTransaction.

Подготовить

Функция подготовки отвечает за загрузку необходимых данных в store, которые будут использоваться внутри функций applyAsset() и undoAsset(). Для PaymentTransaction мы загружаем транзакцию, содержащую счет, используя идентификатор, отправленный с this.asset.data.

Подтвердить объект

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

Чтобы проверить это, нам нужен доступ к StateStore, так как нам нужно кэшировать транзакцию счета-фактуры. Поскольку мы можем выполнять только статические проверки в функции validateAsset(), которая не использует StateStore, эта проверка перемещена на шаг применения.

Применить объект

Функция applyAsset() сначала пытается найти соответствующую транзакцию счета-фактуры. Если эта транзакция существует, мы дополнительно проверяем, соответствует ли количество переданных токенов запрошенной сумме в счете-фактуре. Если эта проверка завершится успешно, транзакция будет применена.

Отменить объект

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

Однако не забудьте позвонить super.undoAsset(store), поскольку шаг Отменить гарантирует, что уплаченная Алиса плата будет возвращена на баланс ее аккаунта.

Как регистрировать пользовательские транзакции?

Хорошо, мы подготовили обе наши пользовательские транзакции. Боб и Алиса очень рады использовать обе транзакции для завершения своей сделки. Однако мы еще не знаем, как регистрировать эти новые транзакции в нашем приложении блокчейна.

Файл invoice / index.js содержит код запуска для запуска вашей собственной цепочки блоков, а также регистрирует обе транзакции. Это так просто!

Хорошо, все готово! Наконец, давайте кратко рассмотрим особенности использования пользовательских транзакций.

Рекомендации по использованию настраиваемых транзакций

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

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

Заключение

Lisk нацелен на творчество в отрасли блокчейнов, предоставляя возможность обрабатывать данные с помощью настраиваемой бизнес-логики. Эта концепция очень похожа на смарт-контракты, поскольку они также содержат настраиваемую бизнес-логику. Мы рады представить вам Lisk Bills как первый пример того, что возможно с нашим SDK.

Мы надеемся, что эта свобода вызовет появление целого ряда новых инновационных блокчейн-приложений, построенных на основе Lisk с использованием недавно выпущенного Lisk Alpha SDK. В настоящее время мы не планируем поддерживать пользовательские транзакции в основной сети Lisk, но они предназначены для использования в вашем собственном приложении блокчейна.

Что дальше? Прочтите о подробностях пользовательских транзакций, StateStore, фильтров и BaseTransaction против TransferTransaction.

Задача Lisk - позволить вам создавать децентрализованные, эффективные и прозрачные блокчейн-приложения. Присоединяйтесь к нам: