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

Posted in Bitcoin, Blockchain, Ethereum, FinTech, Proyectos Open Source | Leave a comment

Conectando Blockchains (4)

Anterior Post
Siguiente Post

Veamos de agregar un nuevo caso de uso. Para realmente expandir la conexión de las dos blockchain, podemos agregar un caso de uso “reverso”: transferir valor desde la segunda blockchain hacia la primera:

El aspecto externo es el mismo: una transacción hacia una cuenta especial en la segunda blockchain, deberá reflejarse automáticamente en una transacción similar en la primera blockchain. De esta forma, el dueño del valor en Acc2’, puede transferirlo a su cuenta en la primera blockchain, a su cuenta Acc2.

Dado que este segundo caso de uso se parece al primero, podríamos esperara que tenga una implementación similar. Podría ser el caso si ambas blockchain tienen las mismas capacidades. Pero, podrían ser diferentes.

En el próximo post, pasaremos estos casos de uso a algo más conctreto, con dos blockchains: Bitcoin y Ethereum/RSK.

Nos leemos!

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

Posted in Bitcoin, Blockchain, Ethereum, FinTech, Proyectos Open Source, RSK | Leave a comment

Conectando Blockchains (3)

Anterior Post
Siguiente Post

Comencemos por el caso de uso más simple. Las blockchains manejan bloques, pero pueden contener distintos datos. Uno de los usos más frecuentes en una blockchain es que el contenido de un bloque sea una lista de transacciones, que representen transferencias de una criptomoneda, la transferencia de un valor entre cuentas.

Dado eso ¿cuál es el caso de uso más simpe que podemos encarar, para conectar dos blockchains basadas en transacciones? Que la aparición de una transacción en una blockchain provoque, se vea reflejada en la aparición de otra transacción en la otra blockchain:

¿Por qué esta transferencia es especial y provoca esta conducta? Porque la primera transferencia tiene una cuenta de destino especial: cualquier valor transferido a esa cuenta, indica que tiene que aparecer una transferencia en la segunda blockchain. Es una cuenta especial de transpaso (y de lockeo: los fondos de la primera blockchain quedan ahí “atrapados”). El valor de transferencia es el mismo: si uno transfiere 1000 unidades en la primera transacción, entonces se transferirán 1000 unidades usando la segunda (automáticamente generada) transacción.

El usuario controla la primera cuenta (Acc1) en la primera blockchain. Y conociendo esa cuenta, el sistema sabe que tiene que transferir a la segunda cuenta (Acc1’) de la segunda blockchain. El usuario también controla esa cuenta (por ejemplo, conociendo la clave privada de ambas). Entonces, para el usuario, el valor que “desaparece” en la primer blockchain, ahora lo tiene disponible enl segunda, de forma automática y transparente.

El monto transferido queda “lockeado” en Acc1, desde el punto de vista de la primera blockchain. Luego veremos caso de uso donde el usuario recupera control de ese monto en esa blockchain.

Las cuentas especiales que aparecen en este caso de uso, son manejadas por el sistema automático, no por usuarios humanos.

Se vienen más casos de uso, nos leemos!

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

Posted in Bitcoin, Blockchain, Ethereum, FinTech, Proyectos Open Source, RSK | Leave a comment

Conectando Blockchains (2)

Anterior Post
Siguiente Post

Debe haber más de una forma de conectar dos blockchains. Lo que quiero en esta serie de post, es explorar la implementación de una forma y pocas variantes, siguiendo algunas líneas de base:

Simplicidad: Para mí, es la clave del desarrollo de software: implementar algo simple, en vez de producir una máquina de Rube Goldberg. Haciendo que la implementación sea simple, uno puede ir entendiendo el problema original y la solución simple encontrada hasata ese momento. Y va construyendo algo que puede evolucionar, cambiar, adaptarse en el futuro, en lugar de tener una arquitectura grande, complicada, de astronauta.

Guiado por casos de uso: No todo es tecnología, están los casos de uso en concreto. Ver claramente el problema, implementar una solución simple. No preocuparse por agregar algo para lo que hasta ese momento, no hay caso de uso que lo pida agregar.

Make it work, make it right, make it fast: Una frase de Kent Beck, que promueve una implementación evolutiva, un software que va creciende en el tiempo, como un organismo. No tenemos que tener todo desde el principio. Comenzar por un caso de uso simple, ir agregando funcionalidad, no preocuparse al principio por la optimización.

Test-Driven Development: Ya saben que soy un gran promotor de TDD. Para mí, escribir código de producción con TDD promueve la simplicidad en la implementación y el desarrollo evolutivo, concentrándose en los casos de uso que van apareciendo, más que en la tecnología o los detalles que no importan en ese momento.

Resiliencia: En el caso de conectar dos blockchains, con intercambio de valor, ocurre que la implementación debe ser robusta. Cuando manejamos valor, no queremos que una falla nos haga perder algo.

Nos leemos!

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

Posted in Bitcoin, Blockchain, Ethereum, FinTech, RSK | Leave a comment

Resoluciones del Nuevo Mes: Noviembre 2016

Se acerca el fin de año. Tiempo de escribir mis resoluciones del nuevo mes, pero antes un repaso a las del mes pasado.

– Mejorar CrysSharp [completo] ver repo
– Mejorar SharpGo [completo] ver repo
– Mejorar BlockchainSharp [completo] ver repo
– Mejorar SimpleBlockchain [completo] ver repo
– Continuar Solidity Compiler [completo] ver repo
– Continuar ChineseP [completo]
– Escribir sobre implementar una block chain [pendiente]
– Escribir sobre simplicidada e implementar un two way peg [completo] ver post

Además, estuve trabajando en:

– Dar una charla sobre Connecting Blockchains [completo] ver slides
– Código de ejemplo en PegSharp [completo] ver repo

Mis resoluciones para el nuevo mes:

– Mejorar CrysSharp
– Mejorar GoSharp 
– Mejorar BlockchainSharp
– Mejorar SimpleBlockchain
– Continuar Solidity Compiler
– Continuar ChineseP
– Continuar PegSharp

Nos leemos!

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

Posted in Bitcoin, Blockchain, C#, Ethereum, JavaScript, Proyectos Open Source | Leave a comment

Conectando Blockchains (1)

Siguiente Post

Con el éxito de Bitcoin, la criptomoneda está en todos lados: es la más popular de las soportadas por una blockchain distribuida, está cambiando el mundo fintech. Pero el éxito no viene solo: pone de manifiesto las limitaciones de la implementación actual, como el bajo número de transacciones procesadas por tiempo, el tamaño del bloque, la orientación sólo a transferencias, la inercia ante los cambios, la falta de contratos inteligentes.

Un camino para superar esas limitaciones es la evolución de la implementación. Pero históricamente, los cambios en Bitcoin (mediante propuestas de mejora, hard y soft forkts…) han tenido un proceso que no facilita la innovación. Y tiene sus razones: la seguridad ganada por Bitcoin no es fácilmente cambiable o negociable en los cambios propuestos. Hay muchos intereses que luchan contra los cambios que puede afectar la base del sistema.

El “new kid on the block”, Ethereum, es un ejemplo de innovación controlada paralela: su plataforma soporta la ejecución de contratos inteligentes, que pueden abrir un nuevo mundo de aplicaciones con monedas virtuales, su manejo y el manejo de otros activos.

Soy miembro del equipo de desarrollo de @RSKSmart, donde estamos trabajando dura para conectar la red Bitcoin, con su moneda virtual y su seguridad, con una red RSK basada en Ethereum, con contratos inteligentes. En esta serie personal de posts, quisiera discutir alguna d elas maneras que podríamos usar para conectar blockchains diferentes, en general, y Bitcoin con Ethererum/RSK en particular.

Nos leemos!

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

Posted in Bitcoin, Blockchain, Ethereum, FinTech, RSK | Leave a comment

Escalando Ethereum/RSK (1)

Soy parte del equipo de desarrollo de @RSKSmart. Estamos trabajando implementando una blockchain basada en Ethereum (la versión de Java) que se conecta con Bitcoin usando un “two way peg”.

Hay varias ideas (sin publicar) en el equipo para mejorar la escalabilidad de Ethereum/RSK. En esta nueva serie de post, quiero compartir una idea personal para alcanzar escalabilidad, ejecutando transacciones de un bloque en paralelo, para aprovechar los modernos procesadores.

Ethereum/RSK, como otras blockchains, tiene bloques con transacciones. La diferencia clave con Bitcoin es que soportan la ejecución de “smart contracts”. Cada transacción puede, entonces, ser una simple transferencia de valor, o puede ser una llamada a un método de un contrato. Cada contrato creado tiene una dirección pública (es igual a una cuenta, con saldo) y un almacenamiento asociado. Las transacciones en un bloque se ejecutan en un orden, para obtener un resultado determinista (el estado del mundo), al final de la ejecución, que debe ser el mismo en cualquier nodo de la red. El bloque completo se asocia con el estado del mundo al final de la ejecución de las transacciones, partiendo del estado del mundo del bloque previo.

Pero en muchas situaciones, dos transacciones consecutivas son indepedientes. El estado del mundo al final de su ejecución es el mismo, independientemente de su orden de ejecución. Aun cuando quizás ejecuten el mismo contrato, dos transacciones pueden ser ejecutados, en algunos casos, en paralelo. Por ejemplo, un contrato puede manejar un activo/valor por usuario, y la transacción T1 modifica el valor del activo del usuario U1, y la transacción T2 modifica el valor del activo del usuario U2. Ambas transacciones se pueden ejecutar en cualquier orden. De esta manera, un contrato no se transforma en el cuello de botella de ejecución. La semántica de las transacciones indica si son independientes o no.

Estuve experimentando con implementaciones livianas de “tries”, la estructura de datos usada para mantener el estado del mundo y calcular su “hash” (ver Building a blockchain (5)). Mi idea es paralelizar la ejecución de las transacciones usando un “trie” que soporta multithreading, y detectec cualquier conflicto de lectura/escritura entre transacciones. Si N transacciones se pueden ejecutar sin clonflitos (por ejemplo, un conflicto aparece si dos transacciones modifican la misma celda de “storage”), entonces se pueden ejecutar en paralelo. La idea básica: usar ideas de “software transactional memory” (ver Memory Transactions In AjSharp Using References).

Nos leemos!

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

Posted in Blockchain, Escalabilidad, Ethereum, RSK | Leave a comment

Resoluciones del Nuevo Mes: Octubre 2016

Otro mes intensivo en mi trabajo diario, preparando un “milestone” de @RSKSmart. Tiempo de revisar mis resoluciones del mes pasado:

– Mejorar CrysSharp [completo] ver repo
– Mejorar BlockchainSharp [pendiente]
– Mejorar SimpleBlockchain [pendiente]
– Continuar Solidity Compiler [completo] ver repo
– Continuar ChineseP [pendiente]

También estuve trabajando en:

– Mejorar SharpGo [completo] ver repo

Mis resuluciones para el nuevo mes:

– Mejorar CrysSharp
– Mejorar GoSharp 
– Mejorar BlockchainSharp
– Mejorar SimpleBlockchain
– Continuar Solidity Compiler
– Continuar ChineseP
– Escribir sobre implementar una blockchain
– Escribir sobre simplicidad e implementar una two way peg

Nos leemos!

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

Posted in Blockchain, C#, JavaScript, NodeJs, Proyectos Open Source | Leave a comment

Resoluciones del Nuevo Mes: Septiembre 2016

Otro mes de trabajo intensivo en @RSKsmart, es tiempo de escribir las resoluciones personales para el nuevo mes. Primero, reviso las del mes pasado:

– Mejorar CrysSharp [completo] ver repo
– Mejorar CrysJS [pendiente]
– Mejorar BlockchainSharp [pendiente]
– Mejorar SimpleBlockchain [pendiente]
– Comenzar Solidity Compiler [completo] ver repo

También estuve trabajando en:

– Mejorar SimpleDSL [completo] ver repo
– Comenzar ChineseP, sitio de práctica de chino, en in NodeJS [completo] ver repo

Las resoluciones para el nuevo mes:

– Mejorar CrysSharp
– Mejorar BlockchainSharp
– Mejorar SimpleBlockchain
– Continuar Solidity Compiler
– Continuar ChineseP

Nos leemos!

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

Posted in C#, JavaScript, NodeJs, Proyectos Open Source | Leave a comment

Resoluciones del Nuevo Mes: Agosto 2016

Julio ha sido un mes de bastante ocupación en mi trabajo diario de desarrollo de software. Pero igual me hice algo de tiempo para trabajar en proyectos personales. Revisión de mis resoluciones del mes pasado:

– Mejorar WangTiles [pendiente]
– Mejorar WangTilesJS [pendiente]
– Mejorar CrysSharp [completo] ver repo
– Mejorar CrysJS [completo] ver repo
– Mejorar SimpleForth [pendiente]
– Mejorar BlockchainSharp [completo] ver repo
– Mejorar SimpleBlockchain [completo] ver repo

Tambien estuve trabajando en:

– Comenzar ChineseP, un sitio de práctica de idioma chino [completo] ver repo
– Actualizar SimpleLists [completo] ver repo

Mis resoluciones para el nuevo mes de agosto:

– Mejorar CrysSharp
– Mejorar CrysJS
– Mejorar BlockchainSharp
– Mejorar SimpleBlockchain
– Comenzar Solidity Compiler

Nos leemos!

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

Posted in Blockchain, C#, JavaScript, NodeJs, Proyectos Open Source | Leave a comment