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)

captura-de-pantalla-2016-12-07-a-las-11-16-40

Propuesta arquitectónica para aplicaciones decentralizadas *

Pero incluso en las cadenas privadas (Eris, Hiperledger, etc.) presentan limitaciones al espacio disponible, principalmente por dos motivos:

  • En blockchain no existe el borrado, no se puede liberar espacio. Incluso las modificaciones incrementan el espacio utilizado.
  • Blockchain escala mal. Incrementar el numero de participantes no incrementa el espacio disponible, porque todos los nodos tienen toda la información.

La solución más inmediata sacar los datos menos transcendentes o mas voluminosos, y referenciarlos desde la cadena.

Los sistemas más utilizados para almacenar estos datos son GIT (un sistema de control de versiones distribuido), IPFS (un sistema de ficheros descentralizado) o BigChainDB (una base de datos de activos digitales, descentralizada)

Que características deberían de tener estos depósitos externos.

  • Inmutabilidad en el acceso. Si cambiamos los datos sin que la cadena lo perciba, perdemos las ventajas que aporta blockchain. En este sentido IPFS es muy elegante dado que el hash del contenido es su propia dirección.
  • Replicación parcial de los datos, y acceso global. Si los datos se guardan en todos los nodos no solucionamos el problema del deficiente escalado de blockchain. En este sentido BigchainDB establece un factor de replicación 3 (todo dato está en tres nodos)  . Ipfs determina que se replicará en función del interés de cada nodo en cada archivo. En ambos casos cualquier dato puede ser leído desde cualquier servidor.
  • Accesibilidad desde la cadena; que los datos puedan participar en el programa desplegado en la cadena y aquí es donde encontramos mayores diferencias. Pensemos en estos tres grados de participación:
    1. Los datos son referenciados: En blockchain se guarda una referencia a un dato inmutable. Se puede guardar la documentación adjunta, o un activo digital. La pega es que el software en la cadena no tiene acceso a dicha información para poder, por ejemplo, verificar un dato en una condición. (ej: Si el contrato es por mas de 1000€ entonces….). Este tipo de participación puede ser implementado con IPFS, Git o BigchainDB.
    2. Los datos referenciados tienen su propia lógica, su parte del contrato. Este es el enfoque de BigchainDB. No parece una solución muy elegante, puesto que al final, blockchain no conoce nada de la lógica que reside en la base de datos, no obstante, es cierto que se puede extender la lógica de negocio manteniéndola descentralizada.
    3. Integración de los datos. En este caso la solución consiste en integrar el almacenamiento externo (no completamente replicado) con la cadena. Permitiendo a la cadena el acceso a los datos en su lógica sin poner en riesgo la integridad de la cadena. Lamentablemente, no he encontrado implementaciones de este esquema, solo el tiempo dirá si llegaremos a verlas.

Mientras no llegemos a ver la integración total de los datos en la cadena, deberemos seguir delegando esta tarea a los oraculos, tal y como ya comentamos en Blockchain vs. Mundo exterior.

Anuncios

#ipfs