Eventos en blockchain

Una de las características de los contratos inteligentes que mas potencial ofrecen en muchos casos de uso son los eventos.  A continuación veremos: Qué son, Cómo funcionan, Cómo podemos sacarles partido.

Pero creo que es interesante que empecemos contextualizando.  Un contrato inteligente es un software, un programa, que se ejecuta en un blockchain. Es decir: es un programa que se ejecuta distribuidamente en la red. Múltiples sistemas suelen interactuar sobre un contrato, modificando su estado, y los eventos son el mecanismo por el cual estos cambios son notificados al resto de sistemas interesados.

eventos.png

Al igual que las transacciones, cada evento blockchain se lanza en todos los nodos del blockchain. Cualquiera puede recogerlo mediante subscripción. Es decir, los eventos funcionan como los topics; su entrega está asegurada, pero su recogida no (si un sistema recolector esta temporalmente fuera de servicio, pierde los eventos)

Como consecuencia tenemos tres advertencias de entrada

  1. Considerad que los eventos no tienen entrega asegurada. Debido a que el sistema subscriptor pueden estar ocasionalmente fuera de servicio (downtimes)  y si esto es un problema deberían de usarse estrategias H.A., como poner varios  escuchadores que escriban en un sistema de mensajería con entrega asegurada.
  2. El envío del evento si está asegurado, no necesitamos disponer de varios nodos de blockchain. Generalmente un nodo de blockchain que queda fuera de servicio “se queda rezagado“. Los eventos se disparan en ese nodo cuando al volver a funcionar “se pone al dia“, proceso que se denomina (catch up).
  3. No es, en general, buena idea utilizar los eventos para replicar el estado de un contrato. Principalmente porque el estado es un dato responsabilidad de blockchain y por la problemática de nuestra primera advertencia. Es mejor idea, en general, reaccionar a los eventos que nos interesan y, al procesarlos, empezar por capturar el estado actual del contrato, obteniéndolo de blockchain.

No obstante si optas por desoír mis consejos, aquí puedes ver como replicar el estado de un contrato en una base de datos local.

Entonces para qué son útiles los eventos

Pues pueden servir para recoger condiciones especiales que se registran en los contratos, como que quede poco gas, o que algún recurso escasea.  Pero su principal utilidad es mantenernos informados de lo que hacen otros participantes.

Esto es especialmente útil cuando lo que se comparte es un proceso, pero también cuando nos interesa que alguien pueda reaccionar a un cambio de estado en un activo.

Pensemos en un contrato para compraventa de casa, que requiere de la aprobación de la hipoteca, registro notarial, pago de impuestos, etc.  El sistema de registro notarial puede estar pendiente de procesos de compra notarial que lancen un evento que venga a significar “listo para registrarse“, para realizar su parte en el contrato.

A su vez , una vez registrado el inmueble, el contrato podría emitir un evento “registrado inmueble” que puede hacer que se desencadene el siguiente paso del proceso, por parte de otro sistema.

Sin eventos habría que ir consultando el estado de todas las instancias de un contrato periódicamente; un esfuerzo considerable e innecesario.

Como usamos los eventos

La máxima es mantenerlo simple (KISS lo llaman).

En la mayoría de los casos con un listener, un futuro o una promesa es suficiente. Si un evento por si mismo nos indica que es lo que tenemos que hacer, entonces podemos asociar a cada evento una acción. Si el evento que llega viene a significar: “listo para registrar” pues entonces registramos.

Pero si para realizar un registro dependemos de que nos hayan llegado los eventos :

  • “pagado”
  • “impuesto de la transmisión ok”
  • “ibi ok”
  • “tasado OK”

O cualquier condición de eventos, podemos utilizar mecanismos más complicados llamados CEP (complex event discovery). Para ello podemos utilizar CEPs externos complejos  como IBM ODM Insight o una simplemente una librería de programación reactiva como las reactiveX . En ambos casos podremos descubrir evento de tipo “listo para hacer algo” como una combinación de varios eventos que cumplen alguna condición… algo de tipo: “ha pagado todos lo que tiene que pagar en plazo y sin incidencias

La combinación de ambos sistemas es muy poderosa, pero el riesgo de sobre-arquitectura es grande, por eso es importante pensar KISS. Si en principio no necesitas un CEP, no lo pongas “por si acaso“, siempre se pueden poner más tarde. Normalmente si tras la recogida de un evento se comprueba el estado de un contrato, consultandolo en el propio blockchain, se suele evitar la necesidad de un CEP, a costa de un rendimiento ligeramente menor.

Anuncios