Caso de uso : Lisk Bills una aplicación de facturación Blockchain
Como nos gusta el enfoque Keep it Simple and Stupid (KISS) , hemos creado una interfaz mínima con React que utiliza Lisk Alpha SDK para interactuar directamente con su aplicación blockchain. El PoC incluye dos actores, el cliente y el autónomo.
Imagina a Alice (autónoma) y Bob (cliente). Bob está buscando un nuevo logotipo para su sitio web y decide consultar a un profesional independiente. Mientras busca un buen diseñador, se encuentra con Alice que ofrece algunos diseños espectaculares en su portafolio. Bob está tan emocionado que decide emplear de inmediato las habilidades de Alice.
Pasan unos días y Alice devuelve el logo prometido junto con una factura. Sin embargo, Bob es un gran admirador de la tecnología blockchain, ya que ayuda a facilitar el proceso de liquidación. A menudo sucede que las partes no están de acuerdo con el precio, el producto o incluso los términos de envío acordados. Bob, por lo tanto, cree que blockchain puede ayudar a registrar toda esta información desde el principio, por lo que no pueden ocurrir disputas y se pueden eliminar los errores humanos. La cadena de bloques debe actuar como prueba de la factura.
Por la razón anterior, Bob le pide a Alice que cree la factura a través de una transacción personalizada de Lisk.
Para hacerlo, Alice primero debe iniciar sesión con su contraseña en la aplicación Lisk Bills.
Transacción personalizada 1: factura
Ahora que Alice ha iniciado sesión, puede crear una factura. Para crear la transacción de factura personalizada, Alice debe ingresar los siguientes detalles:
Clienttiene la dirección o el nombre comercial de Bob's Lisk.RequestedAmountsostiene la cantidad que Bob le debe a Alice.Descriptionpara describir el servicio de diseño entregado.
Los siguientes datos se almacenan en el campo de activos de la transacción. Como esta es una BaseTransaction normal , simplemente podemos especificar la dirección Lisk de Bob como el destinatario de la transacción.
Antes de sumergirnos en los aspectos técnicos, asegúrese de abrir o clonar el repositorio lisk-sdk-examples . El código para ambas transacciones personalizadas se puede encontrar en factura / transacciones / factura_transacción.js y factura / transacciones / pago_transacción.js .
Técnicas
En primer lugar, echemos un vistazo a la definición de la clase. El InvoiceTransactionextiende los BaseTransaction que significa que es heredan sus propiedades. Como sugiere el nombre, BaseTransaction es la interfaz más básica para crear nuevos tipos de transacciones. También existen otros tipos de transacciones en el sistema, más adelante mostraremos un ejemplo de extensión del TransferTransaction tipo.
Al extender el BaseTransaction , podemos proporcionar una lógica comercial adicional para los siguientes métodos: preparar, validar activos, aplicar activos y deshacer activos . Puede obtener más información sobre estos métodos en nuestra documentación .
Además, preste atención a la función de captador estático para recuperar el tipo de transacción. Como ejemplo, hemos elegido 13 ser el número de tipo para esta transacción. Además de eso, puede establecer la tarifa que desea que los usuarios paguen por usar este tipo de transacción. Por ahora, lo hemos establecido en 1 LSK (10 hasta la octava sombra).
Aclaración: Para ver completos los codigos se recomienda verlos desde una PC
Preparar
La función de preparación es responsable de cargar los datos requeridos utilizados dentro de la función applyAsset() y undoAsset(). Aquí, intentamos cargar los datos de la cuenta para el remitente ya que queremos agregar datos a su asset campo en la applyAsset() función. Estos datos se cargarán desde el objeto StateStore que proporciona acceso a los datos en la base de datos.
Podemos almacenar en caché la cuenta del remitente de esta manera pasando una matriz con filtros.
Sin embargo, en realidad no tenemos que almacenar en caché los datos manualmente. Simplemente podemos llamar al método principal para la prepare función en la BaseTransaction clase abstracta que, por defecto, almacenará en caché la cuenta del remitente para deducir la tarifa en el paso de aplicación .
Validar activo
Antes de que una transacción llegue al paso de solicitud, se valida. Verifique la corrección de los activos de la transacción desde la perspectiva del esquema (sin acceso StateStore aquí). Puede invalidar la transacción insertando un error en la matriz de resultados.
Aplicar activo
Como puede ver, finalmente usamos la cuenta cargada que colocamos en la tienda durante el prepare paso. A continuación, actualizamos el recuento de facturas y registramos el ID de la factura en una matriz con las facturas enviadas. Usaremos estos datos en nuestra interfaz para mostrar todas las facturas.
Deshacer activo
No subestime la importancia de la undoAsset() función. La función Deshacer nos permite retroceder a un estado anterior de blockchain. Por lo tanto, debemos decirle exactamente a nuestra aplicación blockchain cómo debe revertir los cambios.
La función Deshacer es de suma importancia para el mecanismo de recuperación de la horquilla. En caso de que ocurra una bifurcación en una cadena con punta B y queremos retroceder a una altura común para volver a aplicar bloques hasta la punta de la cadena A, necesitamos la función Deshacer para hacer el retroceso real a esta altura común .
Para la prueba de concepto de factura, el código reduce invoiceCount y elimina el ID de factura de la invoicesSent matriz.
Bien, hemos explorado las funciones para la transacción de la factura. Pasemos a la transacción de pago.
Transacción personalizada 2: Pago
Ahora que Bob ha recibido la transacción de la factura en su billetera, decide pagar la factura. Para completar la transacción, normalmente enviamos un TransferTransaction que es compatible de forma nativa con Lisk SDK.
Sin embargo, hacerlo haría de este un tutorial muy aburrido. Por lo tanto, Bob decide utilizar otra transacción personalizada para mostrar las posibilidades de Lisk. Esta Transacción de pago personalizada tiene lógica para verificar que el monto transferido sea al menos igual al RequestedAmount. Además, la transacción requiere que Bob especifique el ID de la factura que desea cumplir.
Si el monto transferido es demasiado bajo o el ID de la factura simplemente no existe, la transacción falla. Bob mantiene su parte del acuerdo y envía la cantidad solicitada al ID de factura de Alice. Bob incluso agrega un consejo por el gran trabajo de Alice.
Así es como se ve la implementación de la interfaz de usuario para pagar una factura con nuestra aplicación Lisk Bills.
Técnicas
Nuevamente, echemos un vistazo a la definición de clase. El PaymentTransactionextiende el TransferTransaction que significa que está heredar sus propiedades como una tarifa diferente y comprobaciones de verificación de transferencia relacionada. Además, preste atención a la función de captador estático para recuperar el tipo de transacción. Como no podemos tener tipos de transacciones idénticos, el PaymentTransaction tipo ha recibido 14.
Además, tenga en cuenta que no definimos una función getter estática para FEE. No lo implementamos aquí porque no queremos sobrescribir lo FEE definido en TransferTransaction. En resumen, queremos utilizar la 0.1 tarifa definida en TransferTransaction.
Preparar
La función de preparación es responsable de cargar los datos requeridos en el store que se utilizará dentro de la función applyAsset() y undoAsset(). Para el PaymentTransaction, estamos cargando la transacción que contiene la factura usando el ID enviado con this.asset.data.
Validar activo
Como habrás notado, no implementamos la validateAsset()función para la transacción de pago. La única comprobación que tenemos que realizar es validar si el número de tokens enviados es al menos igual al número solicitado de tokens.
Para validar esto, necesitamos acceder al StateStore ya que necesitamos almacenar en caché la transacción de la factura. Debido a que solo podemos realizar comprobaciones estáticas en la validateAsset() función que no utiliza StateStore, esta comprobación se traslada al paso de aplicación .
Aplicar activo
La applyAsset() función primero intenta encontrar la transacción de factura correspondiente. Si esta transacción existe, verificamos además que la cantidad de tokens transferidos sea al menos igual a la cantidad solicitada en la factura. Si esta verificación tiene éxito, se aplica la transacción.
Deshacer activo
No se requiere lógica de reversión para el paso de deshacer de la transacción de pago. No modificamos ningún dato en la tienda con el set método, por lo que no es necesario definir pasos de deshacer para revertir este cambio de datos.
Sin embargo, no olvide llamar, super.undoAsset(store) ya que el paso Deshacer garantizará que la tarifa que pagó Alice se devuelva al saldo de su cuenta.
Lisk tiene como objetivo permitir la creatividad dentro de la industria blockchain al proporcionar la capacidad de procesar datos con lógica empresarial personalizada. Este concepto es muy similar a los contratos inteligentes, ya que también tienen una lógica comercial personalizada. Nos complace presentarle Lisk Bills como el primer ejemplo de lo que es posible con nuestro SDK.
Esperamos que esta libertad provoque un montón de nuevas e innovadoras aplicaciones de blockchain construidas sobre Lisk utilizando el recién lanzado Lisk Alpha SDK. Actualmente, no planeamos admitir transacciones personalizadas en la red principal de Lisk, pero están diseñadas para usarse dentro de su propia aplicación blockchain.
Recursos:
Fuente: blog de Lisk
