Una Base de Datos en la Blockchain (1)

Teniendo una blockchain con contratos inteligentes, como en Ethereum&RSK, se nos abre un mundo de posibilidades, nuevos casos de usos, formas de agregar valor a las actividades. No estoy seguro de que sea necesaria, pero una posibilidad a explorar es tener asociada una simple base de datos relacional con una cuenta, usando el almacenamiento de la cuenta.

Una cuenta puede tener código (nativo, o precompilado a bytecodes de Ethereum Virtual Machine), balance, nonce y almacenamiento. El almacenamiento se compone de celdas de almacenamiento, cada una de ellas tiene una dirección pública de 32 bytes, y un contenido, un entero de 32 bytes. Si el contenido del almacenamiento cambia, hay un hash asociado a todo el contenido de la cuenta que también cambia..

En @RSKSmart, tenemos código experimental que puede almacenar en cualquier celde almacenamiento un arreglo de bytes arbitrario; no estamos limitados a guardar enteros de 32 bytes. El cálculo del hash es el mismo, y la persistencia de las celdas de almacenamiento es el mismo: internamente, usa los mismos key-value stores, como LevelDB.

Entonces, ahora puedo hacer más cosas que con Ethereum original. Puedo tener un contrato precompilado nativo, con:

– Método execute(sql) para ejecutar un comando SQL sencillo (create table, insert, ….)
– Método query(sql) para recuperar un arreglo de filas

Internamente, cada tabla tiene un ID (número corto), y cada fila de una tabla tiene un ID (p.ej. 20 bytes). La descripción de la base de datos (un base de datos relacional por cuenta) reside en tablas del sistema. La de almacenamiento para una fila de un tabla se localizaría en la dirección TableID + RowID, dentro del almacenamiento de la cuenta.

Almacenando de esta manera, cada estado del mundo, referenciado por un hash, tiene un snapshot de las bases de datos por cuenta, que son sus almacenamientos.

Pero insisto: habrá que ver que casos de usos necesitan esta funcionalidad. Puede que el mundo de los contratos inteligentes necesite más lógica y algunos datos expuestos en cada contrato, que implementar toda una base de datos relaciones.

Igual, espero ir escribiendo y comentado por acá código de implementación de estas ideas.

Otra aproximación es usar un contrato como una especie de envoltorio liviano alrededor de una base de datos industrial distribuida. Pero no me queda claro cómo mantener los snapshots por estado del mundo. Tampoco queda claro que casos de usos necesitan esos snapshots.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in Bitcoin, Blockchain, Ethereum, FinTech, Proyectos Open Source. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *