Angel "Java" Lopez

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

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

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

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

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

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

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

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

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

Anterior Post

El año pasado puse a punto una librería de algoritmos genéticos, con ejemplos que usé en la JSConf 2014 de Argentina.

https://github.com/ajlopez/SimpleGA

Hace unas semanas volví a usarla para otro ejemplo, esta vez orientada a FinTech: generar estrategias de compra/venta de acciones. Era una de las ideas que tenía preparadas para el Hackathon internot de Poincenot. Pero luego el tema del hackathon no fue FinTech, sino orientado a CashMoon. Igual me gustó la idea inicial, y hoy seguí explorándola. Veamos los primeros resultados. Pueden verlo en:

https://github.com/ajlopez/SimpleGA/tree/master/samples/trading

Lo que me faltaba eran datos de acciones. Los conseguí de los datos que usa el juego de Bloomberg

http://www.bloomberg.com/features/2015-stock-chart-trading-game/

Cada compañía tiene valores en un archivo .csv, y los tomé como ejemplos de entrenamiento. Muchos de los valores son diarios, y otros son por día/hora, o por día pero espaciados. Debería conseguir mejores valores. Espero que el próximo experimento lo haga con valores diarios de acciones de compañías de mi pais, Argentina. Eso queda para próximo post.

El desarrollo del genotipo fue encarado, en lo que se pudo, siguiendo TDD (Test-Driven Development). Como hay un componente aleatorio en el desarrollo de una población, algunos tests quedaron siendo no determinísticos. Pero para lo que necesito ahora basta.

Como siempre, sigo dos guías en mis desarrollos: simplicity pays, y baby steps.

Esos dos principios me llevaron a primero probar con datos simples, de series ascendentes, o series de valores descendentes. Despues, a no preocuparme por los días: solo me interesa cómo varia el valor de una acción del tiempo T al tiempo T+1, donde el intervalo puede ser cualquiera. Luego de los primeros resultados se puede ir mejorando el experimento, el algoritmo y los datos.

Y con respecto al algoritmo del genotipo, su forma de representarse y evaluarse, quedará como tema de otro post. Pero baste adelantar que se basa en examinar valores consecutivos en el tiempo de una acción (por ejemplo, su comportanmiento en 3 “días”), y si baja o sube, comprar o vender tal monto (en unidades de moneda). Cada uno de los genes expresa una de esas estrategias.

El tema de la simplicidad me lleva a usar NodeJS y mi propia librería: no necesito frameworks mamutescos para realizar estos experimentos. Como suele decir @substack, NodeJS es ideal para estos experimentos de “mad science”.

Si en el directorio del ejemplo ejecutan:

node train ge lulu

Pueden obtener:

Lo que hace internamente es:

– Generar una población inicial de 1000 estrategias de trading aleatorias
– Ejecutar 100 generaciones (evaluaciones) de esas estrategias contra los datos de entrenamiento (en este caso dos compañías)
– En cada generación/pasada quedarse con los mejores y mutarlos, para alimentar a la próxima generación de traders (notablemente, no necesité cruzamiento, solo mutación, de nuevo, simplicidad, baby step, no usar algo si no se necesita todavía)

El resultado final muestra el mejor trader encontrado, su composición genética (a explicar en próximo post) y su evaluación. En este caso, partiendo de 2000 dólares iniciales (1000 por empresa), consiguió generar 2500 dólares. La longitud de estas series está en los 200 valores promedio. Si fueran días, hubiéramos obtenido un retorno de un 25% en menos de un año. No está mal para el primer experimento.

Una vez obtenido un resultado interesante (el de arriba fue mi primer primer experimento con datos no inventados), pasé a entregar traders con unas compañías y comparar sus resultados con los valores de otras.

Así, ejecutando:

node train tsla nflx — googl yhoo

se entrena con dos compañías (Tesla, Netflix) y se ejecuta el mejor trader obtenido con valores de otras dos compañías (Google, Yahoo):

En próximos posts: más detalle del cromosoma usado, algoritmo de mutación, y pruebas con más datos.

Nos leemos!

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