Escalando Ethereum/RSK (1)

Published on Author lopezLeave a comment

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

Leave a Reply

Your email address will not be published. Required fields are marked *