Archive for the 'Bitcoin' Category

Multi-Blockchains en Ethereum/RSK

Monday, June 19th, 2017

La implementación de una blockchain incluye la creación, distribución y manejo de bloques como éste:

Un bloque, en Bitcoin, Ethereum o RSK tiene:

  • Un hash único en el sistema
  • Un bloque padre, identificado por un hash
  • Un número de bloque (que es uno más que el número de bloque del padre)
  • Una lista de transacciones

En el caso de Ethereum y RSK, una transacción tiene:

  • Una cuenta enviadora
  • Una cuenta receptora
  • Un valor a transferir
  • Datos adicionales (usados si la cuenta receptora es un contrato inteligente)

Una lista de bloques válidos encadenados forma lo que se llama una blockchain:

En Ethereum/RSK, un bloque también tiene:

  • Bloques tíos (“uncles”)
  • Dificultad asociada al bloque (la dificulta de la prueba de trabajo (“proof of work”) más la suma de las dificultades de los tíos)

De esta forma, la presencia de bloques tíos contribuye a la dificultad del bloque. Y este número suma a la dificultad TOTAL de la blockchain a la que este bloque se agrega. Varios nodos en la red, llamados mineros, generan bloques en la blockchain. Si hay varias alternativas, el algoritmo de consenso distribuido elige la blockchain con mayor dificiltad total:

(en Bitcoin, la blockchain más larga siempre gana; en Ethereum/RSK una blockchain más corta puede ganar a otra más larga si tiene mayor dificultad acumulada total).

Un problema es mantener el estado de todas las cuentas y contratos en el sistema. Cada transacción tiene entonces algo adicional:

  • El hash del estado del mundo

Un  hash que referencia al estado del sistema DESPUES de la ejecución de la transacción. Ese hash es verificado en cada nodo de la red que procesa el bloque y la transacción; de esa manera todos los nodos de la red termina coincidiendo en el resultado del estado del mundo controlando el hash resultante en cada paso. Un estado del mundo se almacena en un trie, una estructura de árbol donde cada nodo tiene un hash asociado dependiendo del contenido de ese nodo. Ver mi trabajo anterior sobre tries en Building a Blockchain (5) Building a Blockchain (12)

El bloque mismo también tiene un hash de estado, representado el estado del mundo LUEGO de la ejecución del bloque. Puede ser DIFERENTE que el estado del mundo luego de la ULTIMA transacción del bloque, porque se admite que al final del bloque se realicen operaciones que alteren el estado, por ejemplo, la asignación de premios a los mineros. Este hash de estado de bloque también es controlado por todos los nodos de la red, para mantener el consenso y validar el bloque.

Un problema es el armado de un bloque, que puede ser un cuello de botella cuando se intenta procesar muchas transacciones (por ejemplo, cientos o miles de transacciones por segundo). Este es el principal caso de uso que inspira esta serie de posts. Sería interesante tener MUCHAS blockchains:

Entonces, una blockchain podría estar dedicada a las transacciones de un contrato/token muy popular, mientras que otra blockchain puede estar dedicada a las transacciones de una nación o región. Sólo de vez en cuando habrá transferencias entre blockchains. Este esquema de cosas no se limita a sólo dos blockchains, se podría manejar muchas más, y tener nodos dedicados a procesar sólo una o dos blockchains. Entonces, en cada nodo se requieren menos recursos para mantener el estado, y el estado global está distribuido en los nodos que atienden a DISTINTAS blockchains. Describo blockchains con esquemas iguales, no Bitcoin vs Ethereum, sino todas Ethereum o todas RSK.

En los próximos posts, describirér los cambios necesarios en Ethereum/RSK para manejar múltiples blockchains en la red.

Nos leemos!

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

Ejecutando un Nodo Ethereum/RSK

Monday, June 12th, 2017

La testnet pública de RSK fue lanzada, y el código principal fue abierto. Si no conoce a RSK, visitar:

http://rsk.co/

Técnicamente, es un fork de Ethereum, de la versión Java, con un 2-way peg contra Bitcoin, y con capacidades de merge-mining. Pueden correr su propio nodo, en solitario, o en su propia red, o pueden ejecutar nodos uniéndose a la testnet pública. Hay instrucciones de como hacerlo en el wiki del proyecto:

https://github.com/rsksmart/rskj/wiki

En este post, quiero describir mi flujo de trabajo para compilar, configurar y ejecutar un nodo, pudiendo así hacer experimentos, probar ideas de implementación distintas (nota: actualmente soy miembro del equipo de desarrollo de RSK, pero esta descripción en este posts, es una descripción personal de lo que uso). Primero, bajarse el código fuente de:

https://github.com/rsksmart/rskj

Actualmente, la versión que se usa en testnet, está en el branch Ginger:

https://github.com/rsksmart/rskj/tree/ginger

También pueden clonarse el repositorio y modificarlo en el suyo propio. Para compilar, se puede usar el IntelliJ Idea Community edition, o usar el comando de línea:

.\gradlew build shadow -x testnet

(usualmente trabajo con Windows; en Linux, Max, cambiar la barra invertida por la barra normal /). Más detalles en:

https://github.com/rsksmart/rskj/wiki/Compile-and-run-a-RSK-node-locally

La opción shadow es para armar un archivo jar que tenga todas las dependencias. La opción –x test permite saltear la ejecución de los tests durante la tarea de build. El comando genera un archivo jar en un subdirectorio. Ejecutar:


cd rskj-core\build\libs
java -Drsk.conf.file=<path> -cp rskj-core-0.2.0-GINGER-all.jar co.rsk.Start

Eso lanza al nodo. ¿Cuál es el archivo de configuración a usar? Más info en:

https://github.com/rsksmart/rskj/wiki/How-to-initialize-RSK-node-configuration-file-settings

Hay un archivo de configuración de ejemplo en:

https://github.com/rsksmart/rskj/blob/master/rskj-core/src/main/resources/config/rsk-sample.conf

Una de las cosas que hay que hacer, es que cada instancia de nodo que queremos lanzar tenga su id de nodo. Para generar el id de nodo y una clave privada asociada, ejecutar primero el comando de línea:


java -cp rskj-core-0.2.0-GINGER-all.jar co.rsk.GenNodeKeyId

Vuelva un JSON en consola. Hay que copiar de los datos que vuelta, la clave privada en el archivo de configuración, y opcionalmente, el id de nodo:


# Private key of the peer
nodeId = 66cf57...
privateKey = 46f850...

Sólo es mandatorio el privateKey para ejecutar el nodo, pero puede copiar el id de nodo para mantener una referencia. La otra línea a definir es el llamado secreto coinbase:


# this string is computed
# to be eventually the address
# that get the miner reward
coinbase.secret = mytreasure

Puede poner una palabra arbitraria.

Para permitir el CORS (Cross-Origin Resource Sharing) para exponer el estado del nodo por JSON RPC (Remote Procedure Call), hay que modificar la propiedad cors:


rpc {
enabled = true # you can disable rpc
port = 4444

cors = "*.rsk.co" # you can put "localhost here"

La capacidad de RPC es solamente usada para consultar al nodo, y enviar transferencias desde un cliente, pero desabilitarla no interfiere con el proceso normal del nodo. ¿Cómo hacemos que el nodo se conecte a la red testnet pública? Hay definidos nodos de bootstrap:


peer {
discovery = {
# if peer discovery is off
# the peer window will show
# only what retrieved by active
# peer [true/false]
enabled = true
# List of the peers to start
# the search of the online peers
# values: [ip:port]
ip.list = [
"bootstrap01.testnet.rsk.co:50505",
"bootstrap02.testnet.rsk.co:50505",
"bootstrap03.testnet.rsk.co:50505",
"bootstrap04.testnet.rsk.co:50505"
]

para usar como puntos de partida en lo que se llama el proceso de descubrimiento de pares, peer discovery. Se puede desabilitar, por ejemplo, si quiere usar el nodo para su propia red, o quiere poner en otro lugar de la configuración (ver más abajo) a qué nodos explícitos quiere conectarse al principio.

Si quiere ejecutar VARIOS nodos locales, debe tener entonces VARIOS archivos de configuración. En estos archivos, ajustar las propiedas siguientes, para que los nodos no se pisen entre sí:

# Peer for server to listen for incoming connections
# 50505 for testnet
listen.port = 50505 # ie to 50506

y también la ya mencionada:


rpc {
enabled = true
port = 4444 # ie to 4445

También, cambiar el directorio de database, donde cada nodo graba los bloques, el estado, etc, sus datos de funcionamiento en archivos. Adicionalmente, pueden poner su propio id de red, para que sus nodos sólo se entiendan entre ellos:


# Network id
networkId = 777 # ie to 42

También puede especificar directamente a qué nodos conectarse. Debe conocer entonces la IP o nombre de máquina, el port del otro nodo, y el id: el otro nodo no aceptará conexiones de quien no conozca su id de nodo:


# Boot node list
# Use to connect to specific nodes
active = [
#{
# ip = 11.22.33.44
# port = 50505
# nodeId = e437a483...
#}
]

En el ejemplo, la propiedad ip está puesta con números, pero puede ponerse el nombre de máquina directamente.

Si quieren que su nodo mine bloques, pueden cambiar estas propiedades a verdadero:


# miner options
miner {
server.enabled = false # change to true
client.enabled = false # change to true

Si sólo cambia la propiedad server.enabled a verdadero, dejando client.enabled en false, podrá minar apoyándose en merge mining con software y hardware de minería, pero esa característica está más allá del alcance de este post.

¿Alguna duda? Siempre pueden visitar, preguntar o comentar en el canal de gitter de RSK Java:

https://gitter.im/rsksmart/rskj

Interesados? RSK busca desarrolladores, ver los tweets:

https://twitter.com/RSKsmart/status/872169805515718657


Nos leemos!

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

Lanzando la TestNet RSK

Tuesday, May 23rd, 2017

El proyecto arrancó en 2015, y yo estoy participando en el equipo de desarrollo desde hace algo más de un año. Ayer se lanzó la TestNet pública, en medio de la conferencia Consensus 2017:

http://www.coindesk.com/events/consensus-2017/

Ver instrucciones para participar en la prueba:

https://github.com/rsksmart/rskj/wiki

El repositorio de código principal en:

https://github.com/rsksmart/rskj

Pueden observar el estado de la testnet en:

http://stats.rsk.co/

El gran tema del proyecto es correr una red Ethereum, pero separada, que permita la ejecución de “smart contracts”, usando bitcoins, transferidos a cuentas de la red RSK. Un usuario que tenga bitcoins puede transferir ese valor a la red RSK para que pueda aplicarlos en la ejecución de “smart contracts”.

Si el mundo de contratos inteligentes es nuevo para Uds., comenzar estudiando:

https://www.ethereum.org/

Si quieren saber cómo programar una blockchain (usando TDD por supuesto 🙂 estoy escribiendo en:

http://blogs.msmvps.com/lopez/category/blockchain/

Espero poder escribir más en detalle sobre las ideas de este proyecto.

Nos leemos!

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

Armando una Blockchain (15)

Saturday, December 3rd, 2016

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

MultiMoneda En Ethererum/RSK (1)

Tuesday, November 29th, 2016

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

Conectando Blockchains (6)

Sunday, November 27th, 2016

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

Conectando Blockchains (5)

Thursday, November 17th, 2016

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

Una Base de Datos en la Blockchain (1)

Tuesday, November 15th, 2016

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

Conectando Blockchains (4)

Sunday, November 13th, 2016

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

Conectando Blockchains (3)

Thursday, November 10th, 2016

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