Resoluciones del Nuevo Mes: Diciembre 2016

Y llegamos al fin de año. Tiempo de revisar las resoluciones de noviembre:

– Mejorar CrysSharp [pendiente]
– Mejorar SharpGo [pendiente] ver repo
– Mejorar BlockchainSharp [pendiente]
– Mejorar SimpleBlockchain [pendiente]
– Mejorar Solidity Compiler [pendiente] see repo
– Continuar ChineseP [pendiente]
– Continuar PegSharp [pendiente] see repo

Mis resoluciones para el nuevo mes de diciembre:

– Mejorar CrysSharp
– Mejorar SharpGo
– Mejorar BlockchainSharp
– Mejorar SimpleBlockchain
– Mejorar Solidity Compiler
– Mejorar ChineseP
– Mejorar PegSharp

Nos leemos!

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

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

Armando una Blockchain (15)

Anterior Post

Siempre aparecen temas interesantes para encarar y resolver, en mis implementaciones de blockchain abiertas (C#, JavaScript/NodeJS); una es la comunicación ENTRE nodos. Los nodos tiene que intercambiar datos como nuevos bloques, nuevas transacciones, mensajes de estado y sincronización…. Y también, un nodo que comienza a ejecutar o que está ejecutando desde hace varios días, debe saber descubrir qué otros nodos como él están disponibles en ese momento. Ese proceso tiene un nombre: “peer discovery”, descubrimiento de pares.

Me gustaría escribir hoy algunas ideas:

– Cada nodo tiene un id de nodo, y un id de red en la que trabaja, de esa manera, los demás nodos lo identifican (id de node) y saben si trabaja en la misma red que ellos (id de red).

– Un nodo puede tener una lista preconfigurada (“hardcodeada”) de nodos con los cuales comunicarse, como pares iniciales

– Pero también puede tener otra lista: una lista de nodos especiales en la red, que CONOCEN a otros nodos de la red. Como que mantienen un registro (“registry”) de los nodos disponibles. Estos nodos especiales se van informando dinámicamente de los nodos que existen activos, y los van propagando a otros nodos registro. Un nodo normal se comunica periódicamente con nodos registro, y de esa forma va consiguiendo una lista de pares disponible. Los nodos registros no son nodoso de trabajo ni pares. Puede que en vez de estar identificados por un número de IP, estén referenciados por nombres de máquina, bajo control de servidores de nombre DNS que estén bajo control de la red. Eso permite cambiar su máquina física sin cambiar la configuración de los nodos originales.

Cuando un nuevo nodo comienza a ejecutar, comunica su existencia a su lista de nodos registro, y activamente les pide a éstos cuáles son los pares disponibles para trabajar. Cada nodo de trabajo tiene configurado un número de MAXIMA cantidad de pares activos a contactar.

Cuando uno de esos activos se cae, o se ve que no es alcanzable, el nodo original trata de conectarse con otros nodos activos que va descubriendo con el tiempo desde los nodos registro.

No es objetivo conseguir uan buena distribución de conexiones, pero se podría ir clasificiando los nodos conocidos en zonas arbitrarias (por ejemplo, la zona es el múdulo de id de nodo por 16). Cuando un nodo de la zona 2 pide nodos pares, se le podría entregar PREFERENTEMENTE nodos de la zona 1 y zona 3. Pero hay que demostrar que esto permite una mejor distribución de los mensajes. No es un caso de uso en el que haría énfasis por ahora. Podría ser más importante impedir que un nodo cualquiera, al interrogar a los nodos registro, consiguiera fácilmente la lista de TODOS los nodos de la red.

Como de costumbre, me gustaría pasar estas ideas a código, siguiendo simplicidad, casos de usos, y TDD.

Nos leemos!

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

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

MultiMoneda En Ethererum/RSK (1)

En mi serie de posts sobre conexión de blockchains, estoy escribiendo sobre el intercambio (de valor, uno a uno, sin cambio de valor) entre dos blockchains populares y heterogéneas (Bitcoin y Ethereum/RSK). Soy miembre del equipo de desarrollo de @RSKSmart, pero esos posts son opiniones personales: hay código adicional en el proyecto todavía no publicado.

Otro camino a explorar, es tener, en LA MISMA BLOCKCHAIN, varias cripto monedas. Pienso que puede hacerse de forma simple extendiendo Ethereum/RSK.

En Ethereum, hay cuentas con estado, y en el estado de la cuenta está el balance de esa cuenta. Hay una única moneda “asumida, el Ether. Pero pienso que este modelo puede ser extendido.

Cada cuenta puede tener una moneda. La cripomoneda asumida es el Ether, pero algunas cuentas podrían ser creadas con OTRA criptomoneda como moneda asumida. De este forma, tendrías una partición de cuentas. Una cuenta con moneda X puede transferir y recibir valor de otra cuenta de la MISMA MONEDA X. De esta manera, las nuevas cuentas podría reaprovecha, apalancar, toda la infraestructura de cuentas y transferencias original, pero para una moneda diferente, sin necesidad de armar una blockchain por separada.

En los próximos post, quiero escribir sobre:

– Cómo definir una nueva moneda
– Cómo crear una cuenta con una nueva moneda asociada
– Cómo transferir entre cuentas con la misma moneda
– Cómo transferir entre cuentas con diferentes monedas

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 (6)

Anterior Post

BitCoin es la blockchain más conocida. Ethereum es el “new kid on the block”, y tiene similitudes y diferencias con la BitCoin. En principio, Ethereum tiene nodos ejecutando, que intercambian transacciones, bloques, y van formando una blockchain por consenso distribuido:

El conseso se basa en un “proof of work” en cada bloque agregado a la blockchain, de manera parecida a como se hace en BitCoin. Pero ahí acaban las similitudes. La estructura interna de una transacción, el estado del mundo que se guarda al final de cada bloque, son diferentes. Por ejemplo, en Ethereum hay cuentas,  y se mantiene en su estado el saldo, mientras que en BitCoin se manejan “unspent outputs”, en vez de saldo.

Pero la principal diferencia es que en Ethereum, cada cuenta puede tener un contrato inteligente. Cada nodo de Ethereum corre una Virtual Machine que puede ejecutar esos contratos inteligentes. Cada transferencia puede (o no) ejecutar un método del contrato inteligente asociado a la cuenta destino de la transacción. Esto abre la posibilidad de todo un nuevo mundo de casos de uso.

El tener contratos inteligentes en Ethererum/RSK, es una de las motivaciones para intentar la comunicación bidireccional de estas dos blockchains. BitCoin es limitado en la ejecución de scripts, y los contratos inteligentes son un nuevo mundo a explorar.

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 (5)

Anterior Post
Siguiente Post

El caso de uso que tengo en mente es conectar blockchains heterogéneas: BitCoin y Ethereum/RSK:

El principal problema es que ambas blockchains son muy diferentes La solución del primer caso de uso (transferir de BitCoin a Ethereum/RSK) será muy diferente a la solución del segundo caso de uso (transferir desde Ethereum/RSK a BitCoin).

Y la diferencia clave es que Ethereum/RSK tiene contratos inteligentes (hasta admite contratos nativos precompilados, si se necesita mayores capacidades). La otra diferencia es el formato de las transacciones: BitCoin usa Unspent Outputs mientras Ethereum se basa en mantener balances por cuenta.

Pero elijo estos casos de usos porque son interesantes y no triviales, a discutir en los próximos posts.

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

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