Aplicaciones construidas en Lisk : Proyecto de pagos recurrentes
En el equipo de Moosty, aprendemos haciendo. Al construir pruebas de conceptos, aprendemos sobre la tecnología blockchain y la creación de dinámicas de red. Trabajamos junto con comunidades (en línea y fuera de línea), institutos de conocimiento y organizaciones y tenemos un fuerte vínculo con la comunidad Lisk, la comunidad LCU y las empresas locales en Utrecht. ¿Le gustaría unirse a este viaje de innovación con nosotros? Construyamos juntos una prueba de concepto.
Introducción al proyecto
Pagos recurrentes es una prueba de concepto realizada con Lisk SDK . Muestra una solución técnica relativamente simple que utiliza transacciones personalizadas para construir un contrato determinista entre dos partes (peer to peer). Le permite establecer un contrato con cualquiera que cree una cuenta (billetera) en el sistema. Las cuentas, el contrato, todos sus cambios y todas las actividades se almacenan en la cadena de bloques, que fue creada específicamente para esta PoC.
El proyecto ha obtenido una subvención Lisk Builders . De ahora en adelante elaboramos la prueba de concepto.
Situación actual
Una organización (A) solicita un subsidio del gobierno (B). Actualmente, se paga en una sola cantidad por un período de 1 año. La parte receptora debe cumplir con ciertas condiciones durante este período. Si el beneficiario no ha cumplido las condiciones al final del año, la subvención deberá reembolsarse total o parcialmente.
¿Por qué debería funcionar de manera diferente?
En la situación en la que la parte A no ha cumplido con las condiciones y el subsidio tiene que ser reembolsado total o parcialmente, se encuentra con el problema de que en la mayoría de los casos ya se ha gastado la totalidad del monto. Esto asegura que el proveedor de la subvención (parte B) no tenga la garantía de la cantidad a recuperar y que la parte A pueda tener problemas financieros.
¿Cómo funciona el pago recurrente?
La parte A redacta el contrato con las condiciones de pago, incluida la frecuencia, el momento y el monto. Party B llena la caja fuerte con tokens para cumplir con las condiciones del contrato. En cualquier período en el que la parte A tenga derecho a los tokens del contrato, la parte A puede ejecutar una transacción para recibir los tokens durante ese período. Si la parte B quiere rescindir el contrato prematuramente, la tarifa preestablecida debe pagarse a la parte A, y la parte B recibirá las fichas restantes de la caja fuerte. Esto se puede comparar con la rescisión prematura de un contrato.
Futuro
“En el futuro, puede crear un contrato entre usted y su vecino, que es profesor de guitarra. Establece un contrato por 1 año, mediante el cual le paga una cantidad acordada cada mes. Luego deposita el pago de un mes por adelantado, y si cualquiera de las partes rescinde el contrato, el último mes se le proporcionará al maestro. Una vez establecido, el contrato es inmutable y crea un acuerdo legible y transparente entre las dos partes "
Una infraestructura de servicios flexible
Hoy en día, la herramienta utiliza solo un puñado de transacciones personalizadas . Con estas seis transacciones personalizadas, tenemos el potencial de construir una poderosa aplicación blockchain que crea una solución de contratación flexible entre dos partes. Te da la posibilidad de crear lo siguiente:
🔴 Un mecanismo de pago mensual.
🔴 Proporcione un subsidio mediante el cual el dinero se desbloquee automáticamente después de 3 (o más) meses, a menos que alguien rescinda el contrato.
🔴 Una suscripción en la que paga el importe total por adelantado (para recibir un descuento).
🔴 Un contrato de servicio en el que pagas 2 periodos por adelantado.
🔴 Reserve dinero de bolsillo para sus hijos.
🔴 Programe donaciones mensuales hasta un monto máximo.
Habrá una multitud de posibilidades cuando ampliemos la funcionalidad de estas transacciones, o cuando se agreguen nuevas transacciones personalizadas e incorporemos 10 o quizás 20 transacciones diferentes.
Por ejemplo: cree un crowdfund con un pago mensual (máximo) para el crowdfunding.
¡Háganos saber si tiene ideas aún mejores!
Detalles técnicos
Esta sección contiene una introducción a los detalles técnicos y proporciona una descripción general de los diferentes marcos utilizados, las transacciones personalizadas creadas y, finalmente, nuestra experiencia al trabajar con Lisk SDK.
Componentes del PoC
🔴 Back-end: transacciones personalizadas en funcionamiento que se pueden ejecutar en una cadena de bloques.
🔴 Una API HTTP extendida que conecta el back-end y el front-end.
🔴 Front-end: una billetera de front-end de ReactJS para administrar contratos (interactuar con las transacciones).
Transacciones personalizadas
“Las transacciones son una parte esencial de las aplicaciones blockchain que se crean utilizando Lisk SDK, ya que definen el conjunto de acciones que pueden realizar los usuarios en la red. Cada transacción pertenece a un tipo de transacción específico que se registra en la red ". Documentación Lisk SDK .
Esta prueba de concepto utiliza seis transacciones personalizadas diferentes. Diferentes transacciones pueden interactuar con carteras de contrato como se enumeran a continuación:
· 🔴 Crear: hacer el contrato.
· 🔴 Revisar / aceptar: revisar y validar el contrato.
· 🔴 Contrato de fondo: depositar tokens en el contrato.
· 🔴 Retirar: obtenga tokens del contrato.
· 🔴 Terminar - Terminación prematura del contrato.
· 🔴 Transacción de faucet: proporciona a la billetera tokens y registro de nombre de usuario.
Nota: las transacciones funcionarán con unidades de minutos en esta prueba de concepto para simular contratos más rápido.
Consulte el repositorio de registro de tipo de transacción de Open Lisk para obtener una lista con todos los tipos de transacciones de Lisk registrados. Todos pueden realizar una solicitud de extracción para agregar registros nuevos o actualizar los existentes, y también reutilizar las transacciones personalizadas registradas para configurar rápidamente su propia aplicación blockchain.
Contrato
Un contrato se hace con diferentes reglas que deben cumplirse como se muestra a continuación:
🔴 Unidad: unidad de tiempo [diaria, semanal, mensual, anual].
🔴 Precio unitario: cuántas fichas puede recuperar cada unidad de la caja fuerte.
🔴 Unidades prepagas: cuántas unidades * precio deben estar en la caja fuerte.
🔴 Inicio: cuando comienza el contrato.
🔴 Unidades totales: cuántas unidades contiene el contrato.
🔴 Tasa de rescisión: cuánto de la tasa se paga con la cancelación prematura del contrato.
🔴 Destinatario: en qué dirección puede sacar cada unidad las fichas de tiempo de la caja fuerte (lote A).
🔴 Contratista: qué dirección puede llenar la caja fuerte (lote B).
🔴 Descripción: descripción del contrato.
🔴 Nombre: nombre del contrato.
¿Como funciona?
El futuro remitente o el destinatario de un contrato pueden realizar un contrato. Este contrato puede ser aprobado o modificado por la otra parte a través de la transacción de validación. Si se modifica el contrato, la primera parte debe aprobar o rechazar esta modificación. Este proceso se puede repetir hasta que ambas partes estén de acuerdo. El remitente (parte B) puede llenar una bóveda con una transacción de fondo personalizada que utiliza montos de pago completos y activa el contrato.
SDK 4.0
Este PoC utiliza Lisk SDK 4.0. Esto proporciona tarifas dinámicas y estado de la cadena. La tienda de estado de la cadena se utiliza para determinar el momento de la transacción y puede determinar a partir del estado del contrato cuántos tokens se pueden desbloquear. En esta versión del SDK, la marca de tiempo se elimina de la transacción base y se introduce un nonce. Debido a la naturaleza incremental del nonce, el front-end recupera el nonce de la cuenta de la cadena de bloques cada vez, justo antes de que se firme una transacción.
Solución de tarifas dinámicas
Las tarifas dinámicas funcionan a la perfección. Debido a la falta de documentación (ya que comenzamos a usar la versión 4 demasiado pronto), tomó un tiempo averiguar cómo calcularlos. Lo solucionamos de la siguiente manera que se describe a continuación:
Empezando
Para el front-end, tuvimos un problema con BigInt ( problema ), porque BigInt usa una biblioteca Buffer para js en el navegador que aún no ha completado la integración de `buffer.readBigUint64BE ()`. Esta función se utiliza en Lisk SDK y es necesaria para firmar transacciones. La solicitud de extracción para esta función está en proceso, pero aún no se ha aceptado en el momento de escribir este artículo. Lo arreglamos bifurcando el repositorio de búfer y fusionándolo con la solicitud de extracción para que funcione por ahora.
API HTTP
La API HTTP de Lisk predeterminada se ha ampliado con un módulo API adicional para hacer posible la búsqueda de nombres de usuario parciales , campos de activos específicos de contratos y campos de activos específicos de transacciones . Por ejemplo, cada contrato tiene transacciones que le pertenecen a sí mismo, pero la cuenta nunca es el remitente de ninguna transacción. Para recopilar todas las transacciones que pertenecen a un contrato, la API recibirá las transacciones de la entidad de la transacción agregando un filtro `asset_contains` a la entidad de la transacción. Esto hace posible buscar en `.asset.contractPublicKey` ===` contract.publicKey`.
Interfaz
La creación de transacciones personalizadas en el back-end es relativamente fácil cuando comienza a dominarlo. El elemento que consume más tiempo es el front-end, según los requisitos de la interfaz de usuario, y la conexión de los dos. La recopilación de datos de la cadena de bloques se puede optimizar aún más, sin embargo, está fuera del alcance de esta prueba de concepto.
El método undoAsset ()
Además, el método UndoAsset () en una transacción personalizada puede ser difícil de crear con datos nominales estáticos. Esperamos la nueva solución para crear transacciones personalizadas sin el método UndoAsset (), que ya se ha planeado en una versión posterior del SDK. Resolver esto garantizará que la transacción de revisión envíe muchos menos datos y, por lo tanto, use menos recursos de red, lo que a su vez da como resultado tarifas dinámicas más bajas.
Recursos
- Demostración: Demostración de pagos recurrentes
- Cliente: https://github.com/Moosty/lisk-recurring-payment-client
- Transacciones: https://github.com/Moosty/lisk-recurring-payment
Fuente; Blog de Lisk
