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

Armando una Blockchain (14)

Anterior Post
Siguiente Post

Despues de un tiempo de descanso, estoy de vuelta, trabajando en mis proyectos personales de blockchain:

https://github.com/ajlopez/SimpleBlockchain
https://github.com/ajlopez/BlockchainSharp

Hoy quiero presentar mis primeros tests para modelar un minero. Un minero debe minar bloques, agregando transacciones, armando un bloque hijo del mejor bloque de la blockchain. Hay varios casos a resolver: las transacciones deben ser válidas, deben ser minadas una sola vez, etc…. Pero siguiendo el flujo de trabajo de TDD (Test-Driven Development), puedo ir agregando funcionalidad guiado por esos tests. El primero:

exports['mine empty block'] = function (test) {
    var txs = transactions.txs();
    var miner = miners.miner(txs);
    
    var states = tries.states();
    var genesis = blocks.block();
    
    var result = miner.mine(genesis, states);
    
    test.ok(result);
    test.ok(result.hash);
    test.ok(result.transactions);
    test.ok(Array.isArray(result.transactions));
    test.equal(result.transactions.length, 0);
    test.ok(result.parentHash);
    test.equal(result.parentHash, genesis.hash);
};

Despues de implementar el código que hace pasar a este test, escribí un segundo test algo más completo:

exports['mine block with transaction'] = function (test) {
    var from = utils.hash();
    var to = utils.hash();
    var value = 1000;

    var states = tries.states().put(from, { balance: 3000 });
    var tx = transactions.transfer(from, to, value);
    
    var txs = transactions.txs();
    txs.add(tx);

    var miner = miners.miner(txs);
    
    var genesis = blocks.block();
    
    var result = miner.mine(genesis, states);
    
    test.ok(result);
    test.ok(result.hash);
    test.ok(result.transactions);
    test.ok(Array.isArray(result.transactions));
    test.equal(result.transactions.length, 1);
    
    test.equal(result.transactions[0].from, from);
    test.equal(result.transactions[0].to, to);
    test.equal(result.transactions[0].value, 1000);
    
    test.ok(result.parentHash);
    test.equal(result.parentHash, genesis.hash);
};

Todavía es un test algo débil. Por ejemplo, no obliga a la validación de las transacciones en el proceso de minado, y no está claro todavía que pasa con la transacción que fue incluida en el nuevo bloque. Pero todo esto puede irse agregando en tests, describiendo la conducta esperada, y luego implementando.

La parte interesante de este flujo de trabajo es que la implementación va creciendo, siguiendo el camino más simple, siguiendo lo esperado por los tests.

Nos leemos!

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

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

Resoluciones del Nuevo Mes: Julio 2016

Llegó el dia de escribir mis nuevas resoluciones y repasar las del mes pasado:

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

Además, estuve trabajando en:

– Mejorar CrysJS [completo] ver repo

Mis nuevas resoluciones:

– Mejorar WangTiles
– Mejorar WangTilesJS
– Mejorar CrysSharp
– Mejorar CrysJS
– Mejorar SimpleForth
– Mejorar BlockchainSharp
– Mejorar SimpleBlockchain

Nos leemos!

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

Posted in Blockchain, C#, JavaScript, NodeJs, Proyectos Open Source, Test-Driven Development | Leave a comment

Armando una Blockchain (13)

Anterior Post
Siguiente Post

Una parte importande de una blockchain a la Ethereum, es la ejecución de transacciones de transferencias. Cada cuenta tiene una dirección pública y un estado de cuenta conteniendo su balanca. Los estados de cuenta se almacenan en tries inmutables. Esta semana estuve trabajando en mi proyecto personal de blockchain, escrito en JavaScript/NodeJS:

https://github.com/ajlopez/SimpleBlockchain

para ejecutar una transferencia entre cuentas. Como es habitual, lo codifiqué siguiendo el flujo de trabajo de TDD (Test-Driven Development). Mi primer test:

exports['execute transfer'] = function (test) {
    var from = utils.hash();
    var to = utils.hash();
    var value = 1000;

    var states = tries.states().put(from, { balance: 3000 });

    var tx = transactions.transfer(from, to, value);
    
    test.ok(tx);
    test.equal(tx.from, from);
    test.equal(tx.to, to);
    test.equal(tx.value, value);
    
    var newstates = transactions.execute(tx, states);

    test.ok(newstates);
    
    var oldfromstate = states.get(tx.from);
    
    test.ok(oldfromstate);
    test.equal(oldfromstate.balance, 3000);
    
    var oldtostate = states.get(tx.to);
    
    test.ok(oldtostate);
    test.equal(oldtostate.balance, 0);
    
    var newtostate = newstates.get(tx.to);
    
    test.ok(newtostate);
    test.equal(newtostate.balance, 1000);
    
    var newfromstate = newstates.get(tx.from);
    
    test.ok(newfromstate);
    test.equal(newfromstate.balance, 2000);
}

Luego de la ejecución de una transacción, un nuevo trie de estados de cuenta se arma y se devuelve. Pero también hay que rechazar las transferencias que no tienen fondos:

exports['execute transfer without funds'] = function (test) {
    var from = utils.hash();
    var to = utils.hash();
    var value = 1000;

    var states = tries.states();

    var tx = transactions.transfer(from, to, value);
    
    test.ok(tx);
    test.equal(tx.from, from);
    test.equal(tx.to, to);
    test.equal(tx.value, value);
    
    var newstates = transactions.execute(tx, states);

    test.equal(newstates, null);
    
    var oldfromstate = states.get(tx.from);
    
    test.ok(oldfromstate);
    test.equal(oldfromstate.balance, 0);
    
    var oldtostate = states.get(tx.to);
    
    test.ok(oldtostate);
    test.equal(oldtostate.balance, 0);
}

Para cumplir con esos tests, mi implementación actual, simple, es:

function execute(tx, states) {
    var fromstate = states.get(tx.from);
    var tostate = states.get(tx.to);

    fromstate.balance -= tx.value;
    
    if (fromstate.balance < 0)
        return null;
        
    tostate.balance += tx.value;
    
    return states.put(tx.from, fromstate).put(tx.to, tostate);
}

Próximos posts: ejecutando bloques con transacciones, almacenando permanentemente los tries de estados, smart contracts, etc…

Nos leemos!

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

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

Armando una Blockchain (12)

Anterior Post
Siguiente Post

En un anterior post describí la implementación en C# de un árbol inmutable. Necesito un estructura llamada trie para mantener el estado de las cuentas en la blockchain: sus balances pueden ser recuperados usando la dirección pública de la cuenta. La estructura debería ser inmutable para poder recuperar fácilmente los estados de las cuentas en distintos instantes del tiempo. Cada trie tiene los estados de todas las cuentas en un determinado instante. Al ser inmutable, cuando se agrega un valor, un nuevo trie es creado y el original todavía sigue estando disponible.

En estos dias he agregado una implementación de trie a mi proyecto personal de blockchain escrito en JavaScript/NodeJS:

https://github.com/ajlopez/SimpleBlockchain

La implementación fue escrita usando el flujo de trabajo de TDD (Test-Development Driven). Tengo tests simples como:

exports['put data and get data'] = function (test) {
    var trie = tries.trie();
    
    var result = trie.put('0123', 42).get('0123');
    
    test.ok(result);
    test.equal(result, 42);
};

exports['put two new data and retrieve them'] = function (test) {
    var trie = tries.trie();
    
    var result = trie.put('0123', 42)
        .put('3210', 1);
    
    test.ok(result);
    test.equal(result.get('0123'), 42);
    test.equal(result.get('3210'), 1);
    test.equal(trie.get('0123'), null);
    test.equal(trie.get('3210'), null);
};

Usando un lenguaje dinámico como JavaScript, sin declaración de tipos para las variables y argumentos, pude escribir una implementación muy simple, como una función:

function Trie(values) {
    if (values == null)
        values = [];
        
    this.get = function (key, offset) {
        if (offset == null)
            offset = 0;
            
        var ky = key[offset];
        
        if (offset === key.length - 1)
            return values[ky];
        else if (values[ky])
            return values[ky].get(key, offset + 1);
        else
            return null;
    };
    
    this.put = function (key, data, offset) {
        if (offset == null)
            offset = 0;
        
        var newvalues = values.slice();
        var ky = key[offset];
        
        if (offset === key.length - 1)
            newvalues[ky] = data;
        else {
            if (!newvalues[ky])
                newvalues[ky] = new Trie();
                
            newvalues[ky] = newvalues[ky].put(key, data, offset + 1);
        }
            
        return new Trie(newvalues); 
    };
}

Cada valor tiene una clave (key). Creo un árbol de tries. Para agregar un valor usando una clave, agrego el valor al árbol, usando cada letra en la clave para recorrer el árbol interno del trie. En un lenguaje tipado, debería declarar el tipo de las claves y valores. Pero usando JavaScript, solamente el algoritmo es importante: la declaración de los tipos no es importante para escribir el código.

El argumento offset es usado para seleccionar el caracter de la clave. Así, si la clave tiene cuatro caracteres, el valor es guardado en un trie compuesto de cuatro niveles.

Esta es una implementación simple, que puedo mejorar, escribiendo nuevos tests con la conducta esperada. Algo para agregar: persistencia a disco/archivo/base de datos, y calcular hash por trie. Cada bloque procesado y cada transición tendría un hash con los estados resultados, así puedo recuperar el árbol usando el hash. Y cada bloque tendría el hash del estado esperado al terminar su proceso. Si ese hash del bloque no coincide con el hash del árbol calculado por aplicar las transacciones del bloque, entones no es válido lo que estamos calculando. Todos los nodos de la red está revisando cada bloque que agregan a la blockchain, controlando que los estados resultantes sean los esperados por el que calculó por primera vez un bloque.

Cuando un nuevo bloque es construido, se usa como estado inicial el estado final del bloque padre, se aplica cada transacción a ese estado, y el hash del estado final se guarda con el bloque. De esta forma, todos pueden controlar que cada bloque queda en el mismo estado para todos los nodos de la red, manteniendo la coherencia de los estados de las cuentas, o sea, sus balances.

Próximos posts: proceso de transacciones y bloques, almacenamiento y validación.

Nos leemos!

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

Posted in Bitcoin, Blockchain, Ethereum, JavaScript, NodeJs | Leave a comment