Blockchain en Arquitecturas Hexagonales

Las aplicaciones que solo utilizan blockchain tienen una utilidad muy limitada debido a la limitada cantidad de datos que se pueden almacenar, su dificultad de acceso, o la nula interoperabilidad de la cadena. Todo esto provoca,  que mas bien pronto que tarde, sea necesario agregar más componentes a nuestra arquitectura. Hace algún tiempo ya que vi un esquema que encajaba blockchain en una arquitectura MVC, pero me pareció un poco forzado.

Así mismo, el software de negocio parece buscar nuevas arquitecturas mas allá MVC, en parte impulsados por el DDD (Diseño Dirigido por el Dominio),  que nos llevan a arquitecturas como la Hexagonal, (sobre la cual me gustaría escribir un artículo pronto) en la cual encaja perfectamente blockchain.

Lo primero que podemos hacer en un desarrollo agil con DDD es modelar el dominio, la lógica de las entidades de negocio, sin contar con como lo persistiremos. Con esto postponemos la decisión de donde almacenar las entidades hasta que tenemos suficiente información para realizar mejor esta decisión. Tendremos mucho más claro que va en el blockchain y que va fuera.

Las entidades que caigan dentro de Blockchain serán asociadas a adaptadores blockchain. Estos adaptadores le indicarán a las entidades del dominio si blockchain (y por tanto el resto de entidades que comparten dicha entidad) aceptan un cambio de valor (transacción) o no.

hexa.001

Entidades de dominio persistidas en blockchain

Seguir leyendo

Extendiendo Blockchain

Uno de los problemas más restrictivos que afronta el programador en blockchain es la falta de espacio. La cantidad de información que podemos guardar en blockchain es tan poca que recuerda a la programación que se hacía hace muchos muchos años.

Esto es especialmente acuciante en las cadenas públicas (Bitcoin, Ethereum, etc.), porque se está obligando todos los participantes de la cadena a guardar tus datos, independientemente de que estén interesados en ellos o no y esto deriva en limitaciones muy estrictas (y a veces muy caras) Seguir leyendo

#ipfs

creando dinero electrónico.

El dinero es una de las cosas mas viejas del mundo. Pero su evolución en la última década ha sido sorprendente. Aunque muchos piensan que va a costar desbancar el viejo dinero, que lleva funcionando cerca de 1.500 años, lo cierto es que ya vemos como en ciertos países como Dinamarca apenas utilizan ya el dinero de monedas y billetes.

img_1882-jpg

A los tipos de dinero clásicos que estudié en el colegio ya se ha  añadido otro tipo más; el dinero electrónico. Pero me parece un saco muy grande para meter tipos de dinero tan dispares como los que hay hoy en día. Hay un tipo especialmente interesante de dinero electrónico: las criptodivisas. ¿De donde proviene el valor de el dinero electrónico? Seguir leyendo

#criptomoneda, #dinero

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)

Seguir leyendo

Tangle: de la cadena de bloques a la maraña.

Al igual que en la industria se abandonó la cadena en favor del cable por su mayor seguridad, comportamiento y resistencia.

E igual que antes del cable, la cadena era el elemento más resistente, El Blockchain lo es hoy en día, puesto que el Tangle (la maraña) no es todavía una realidad fuera de los laboratorios.

A continuación vamos a intentar describir como funciona, para que se creó y que iniciativas lo tienen en el punto de mira. Intentaremos demostrar que es una tecnología a la cual merece la pena seguirle la pista.

tangle

Tangle con baja carga (arriba) y con alta carga (abajo) de transacciones por unidad de tiempo

Seguir leyendo

#tangle

Criptocheque vs Criptomoneda

He estado oyendo estos ( feos ) términos recientemente. Corresponden a dos aproximaciones diferentes para realizar una de las tareas más veces encomendadas a blockchain: la transferencia de fondos.

Bitcoin, fue creado principalmente para resolver este problema, y lo realiza mediante transferencia directa de criptomoneda. Grosso modo, modela un criptomoneda dentro de un blockchain, esta criptomoneda puede ser troceada y transferida en transacciones consensuadas por la red. Únicamente el dueño de un Bitcoin (o fracción de Bitcoin) puede enviar dicho Bitcoin a otro usuario.

criptocheque

Que el emisor y el receptor acepten la misma criptomoneda (ie. Bitcoin) no es frecuente. Y aunque existen soluciones para trabajar con monedas reales dentro de blockchain, existen problemas adicionales a este tipo de transferencias, que en ciertos escenarios hacen recomendable el pago con criptocheques. Seguir leyendo

#criptocheque

BPM con referencias

Una de las premisas fundamentales para que un BPMS de buen resultado es que los procesos BPM deben de mandar hacer cosas, pero no hacer cosas ellos mismos. O dicho más formalmente: En automatización de un proceso BPM debe de centrarse el foco en secuenciar las tareas que se han de realizar, no en realizarlas. Entre las cosas que se debe de evitar, está la de mantener entidades de las que no se es responsable.

Así pues, y atendiendo al principio de responsabilidad del dato, la base de datos del BPMS deberá de mantener únicamente datos propios del proceso, e irá a buscar las entidades externas cuando las necesite.

Esto es especialmente importante en BPM, ya que entidades como cliente, cuenta, contrato, etc. que son subsceptibles de ser modificados por varios procesos o por eventos de forma concurrente, y un proceso BPM puede durar el tiempo suficiente como para que bloquear esos recursos no sea posible; debend e ser modificables de forma asíncrona.

Adicionalmente si los datos son responsabilidad de terceros deberemos de asumir que una vez adquiridos los datos, al poco, dichos datos dejan de ser validos.  Tras la primera tarea de usuario o automática que lleve más de unos segundos debemos descartarlos, y volver a pedirlos. No es necesario que alguien cambie los datos, la mera posibilidad de que alguien pueda haberlo hecho invalida los datos. Así pues no tiene sentido guardarlos.

¿Qué pasa con los datos que son responsabilidad del BPMS?

Seguir leyendo