Construccion del 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