Archive for the 'Blockchain' Category

Transacciones Offchain en Ethereum/RSK (1)

Wednesday, June 21st, 2017

En Ethereum/RSK, un contrato inteligente tiene un ciclo de vida como:

Un contrato es una cuenta, tiene dirección pública y un balance como cualquier otra cuenta. Pero, además, tiene código asociado y almacenamiento. Las transacciones que recibe pueden tener valor a transferir y datos para invocar código. Y cada transacción tiene un costo, y se graba y publica en la blockchain.

En esta serie de post, quiero describir una posible implementación para soporte de transacciones “offchain”, que no vayan directas a la blockchain, sino que puedan estar en un lugar alternativo, manteniendo estado, sin usar el costo de la blockchain. Solo en algunos momentos el resultado DE VARIAS transacciones se publica en la blockchain. La idea es que un contrato puede estar en otros estados, además del estado normal:

Cuando un contrato está en el estado “offchain”, se ejecuta en un UNICO nodo designado, su nodo de ejecución, y no en toda la red. Las transacciones que recibe son ejecutadas solamente por ESE NODO, y no son agregadas a la blockchain. De esta manera, se pueden ejecutar muchas transacciones contra ese contrato con un costo mucho menor. Solamente cuando el contrato decide pasar de nuevo a modo normal, se emite un “commit” que genera una transacción “onchain”, que cuando se mina y ejecuta, actualiza de en un solo paso el estado de almaceniemto público del contrato en la blockchain. La llamo la transacción delta.

El cambio de estado de normal a “offchain” es disparada por código de contrato, con una nueva instrucción (que se implementa como un nuevo opcode de la máquina virtual Ethereum), para cambiar al estado “offchain”. Las transacciones “onchain” que se reciban de ahí en mas, no se procesan por el contrato. Solo se procesan las transacciones “offline” (podría alternativamente procesar TODAS las que vengan, desde el estado “offchain”, pero me parece más claro al principio, que los usuarios que envíen transacciones ESPECIFICAMENTE las marquen como “onchain” o como “offchain”). Entonces, todas las transacciones “onchain” se rechazan, y ningún minero las agrega a un bloque, mientras el contrato público esté marcado como “offchain” en la blockchain. Las transacciones “offchain” se reconocen con algún dato adicional, por ejemplo, podrían implementarse con campo “nonce” en –1, pero eso es un detalle de implementación a discutir.

De nuevo, el código de contrato es el que decide CUANDO pasar de “offchain” a normal, haciendo un “commit” o un “rollback” al estado público previo. Si decide hacer “commit”, cambia a un estado temporario de congelamiento, hasta que una transacción delta emitida en ese momento, sea minada e incorporada a la blockchain pública. Esta transacción delta tiene como misión actualizar el estado público del contrato para reflejar el estado privado que en nodo ejecutor tiene en ese momento del contrato. De esta manera, en vez de ocupar cientos o miles de transacciones, un contrato usa la blockchain cada tanto, sólo para actualizar el estado público usando este tipo de transacciones delta.

En los próximos posts describiré la transacción delta con más detalle, y discutiré los casos de TRANSFERENCIA de valor (no solo cambio de estado interno) en las transacciones “offchain”. Ahora que el código principal de RSK es público, puede que escriba alguna implementación liviana de estas ideas, como referencia concreta. Como dice Linus, “talk is easy, show me the code” 😉

Nos leemos!

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

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

Resoluciones del Nuevo Mes: Marzo 2017

Wednesday, March 8th, 2017

Un nuevo mes comienza y es tiempo de escribir mis resoluciones. Primero, una revisión de las de febrero:

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

Además estuve trabajando en:

– Comenzar RskSharp [completo] ver repo
– Comenzar TensorSharp [completo] ver repo
– Mejorar AjDrawJs [completo] ver repo
– Mejorar SimpleForth [completo] ver repo
– Mejorar CrysSharp [completo] ver repo
– Nuevo ejemplo Bitcoin en SimpleGA [completo] ver repo
– Mejorar Husky, mi intérprete Haskell [completo] ver repo
– Mejorar SimpleLisp [completo] ver repo
– Mejorar CrysJS [completo] ver repo

Mis nuevas resoluciones:

– Continuar RskSharp
– Continuar SimpleBlockchain
– Continuar Solidity Compiler
– Continuar ChineseP
– Continuar TensorSharp

Nos leemos!

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

Resoluciones del Nuevo Mes: Febrero 2017

Monday, February 6th, 2017

El segundo mes del año comienza, es tiempo de escribir mis resoluciones, pero antes, un repaso de las de enero:

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

También estuve agregando una mejora menor en ErlSharp ver repo.

Mis resoluciones para febrero:

– Mejorar SharpGo 
– Mejorar BlockchainSharp
– Mejorar SimpleBlockchain
– Mejorar Solidity Compiler
– Mejorar ChineseP
– Mejorar ErlSharp

Nos leemos!

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

Resoluciones del Nuevo Mes: Diciembre 2016

Friday, December 9th, 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

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