Conectando Blockchains (7)

Published on Author lopez

Anterior Post

Es tiempo de presentar una propuesta para resolver el problema de la comunicación bidireccional entre blockchains heterogéneas, como lo son Bitcoun y Ethereum/RSK. Como hay más soporte de estado y lógica en Ethereum/RSK esta solución usará contratos inteligentes para cumplir con su misión. Aunque hay una implementación en RSK de esta comunicación bidireccional, mi intención es explorar una alternativa, más simple a mi parecer, para lograr entender el problema y cuáles son las partes difíciles del problema y de la solución. Así, que si bien hay puntos de contacto en común, también esta propuesta se aparte de la solución implementada actualmente, en varios puntos.

Un objetivo que quiero perseguir es la simplicidad. ¿Cuákes son las míniimas partes a tomar en consideración para resolver el problema? ¿y cuál es su forma más simple de implementación? Pienso que un problema como este merece la exploración de soluciones sencillas. Una consecuencia de este objetivo es que he evitado que la lógica de UTXOs (la selección de los unspent transaction outputs de Bitcoin) quede dentro de la lógica de consenso. Pienso que esta lógica se puede implementar en código auxiliar, y que las propuestas de transacciones Bitcoin que se necesitan armar en algún momento se pueden negociar en un contrato inteligente, pero su armado se puede delegar a código específico externo.

También quiero una solución que pueda implementarse en distintas plataformas, así que esto me lleva a evitar código de contratos precompilados, por ejemplo en Java, en cuanto sea posible. He adoptado a Solidity como lenguaje de implementación, con lo que la parte de lógica que reside en la sidechain es perfectamente ejecutable en nodos de distintas implementaciones (Java, Go, Rust, etc).

Si ambas blockchains fueran homogéneas, por ejemplo, si ambas fueran Ethereum/RSK, la solución sería aún más simple: se podría implementar sólo la transferencia desde blockchain A a blockchain B. Luego, la misma implementación (con otras instancias de código, contratos) se puede usar para transferencias de blockchain B a blockchain A.

Pero el problema entre manos involucra blockchains diferentes. La idea principal es esbozada en esta figura:

 

Hay transacciones (líneas sólidas) y consultas (tomar datos, desde la fuente al destino, en flechas no continuas). Las transacciones son movimientos que residen en alguna blockchain. Como he discutido en anteriores posts, hay una cuenta especial de Bitcoin (BTC) que se llama bridge (puente) que recibe fondos de un usuario BTC. Entonces, todo el sistema de arriba debe llegar en algún momento, a emitir una transacción Ethereum/RSK que transfiera fondos desde una cuenta especial Ethereum/RSK bridge, al usuario Ethereum/RSK correspondiente al usuario BTC original (hay una traducción de direcciones entre BTC y Ethereum/RSK).

Pero los contratos inteligentes no pueden obtener data del mundo exterior: un contrato inteligente no PUEDE LEER la blockchain de Bitcoin. Los hechos que ocurren en el mundo exterior DEBEN SER INFORMADOS por nodos especiales con código especial, ejecutado off chain, que LEE la blockchain Bitcoin, detectando nuevos bloques y transferencias de la cuenta especial BTC bridge.

Entonces, la solución requiere que nodos o cuentas especiales, llamados Federados u Oráculos, sean cuentas en las que el sistema confía. Es un patrón común en contratos inteligentes: teniendo oráculos, entidades externas en las que un contrato inteligente confía, ellos pueden enviar datos de hechos externos, por ejemplo, en resultado de un partido de fútbol a un contrato inteligente de apuestas de deportes.

La federación es un conjunto que se puede armar al comienzo del sistema, y que puede evolucionar: nuevos federados podrían entrar al sistema, y algunos federados pueden abandonarla. Por ahora, esta propuesta parte de una federación fija desde el comienzo. Luego más adelante, llegará el momento de tratar el caso de uso general.

Un federado está conectado a la red Bitcoin, y detecta:

  • Nuevos bloques en Bitcoin
  • Transacciones que involucran a la cuenta especial BTC bridge (ya sea como receptora o enviadora de fondos)

También, un federado puede emitir:

  • Una transacción BTC para transferir fondes desde la cuenta especial BTC bridge a un usuario normal

Estas son las interacciones de un federado con Bitcoin. Por temas de seguridad, las transferencias BTC descriptas arriba necesitan ser firmadas por VARIOS federados. La forma de conseguir eso está brevemente descripta más abajo, pero será descripta más detalladamente en el próximo post.

El federado también emite:

  • Transacciones de Ethereum/RSK iinformando la aparición de una nueva transacción BTC que transfiere fundos a y desde la cuenta BTC bridge

Estas son las transacciones que comunican los HECHOS externos que este conjunto de oráculos debe informar a la sidechain (Ethereum/RSK).

Un federado también consulta a Ethereum/RSK:

  • Para conocer si hay una nueva transacción Ethereum/RSK de usuario normal Ethereum/RSK a la cuenta especial Ethereum/RSK bridge.

Usando a la blockchain Ethereum/RSK como un dispositivo de negociación y comunicación, un federado también manda a esa blockchain:

  • Propuesta de transacción BTC a ser enviada a la red Bitcoin, para cumplir con la transferencia de devolución de fondos a un usuario BTC
  • Firmas adicionales de esa transacción propuesta

Para todas estas acciones, el esquema del sistema propuesto es:

 

Los rectángulos redondeados son CONTRATOS INTELIGENTES que residen y se ejecutan en Ethereum/RSK:

Un federado/oráculo debe poder manejar una cuenta Ethereum/RSK para enviar transacciones. Al comienzo del proceso, cada federado detecta bloques y transacciones BTC bridge de la red Bitcoin. Cuando tiene bastante información de confirmación de esa transacción (veremos en próximos posts modificaciones, como que alguno de los contratos inteligentes de arriba VERIFIQUE por su cuenta esas confirmaciones), envía ese HECHO al contrato inteligente Receiver. El HECHO cntiene hash de la transacción Bitcoin, hash del bloque donde reside, índice en ese bloque, cuenta enviadora (ya traducida a cuenta Ethereum/RSK) y monto a transferir.

El contrato Receiver es similar a un sistema de votos. Acepta esos hechos, pero SOLO si son transacciones enviadas por algún miembro de la federación activa (falta un contrato en el esquema de arriba, el Federation, que mantiene la lista de federados). Solamente cuando un HECHO consigue suficientes federados que lo voten (por ejemplo m federados, siendo m >= n / 2 + 1, siendo n el tamaño de la federación actual), solo entonces, EMITE una transacción al contrato Bridge. Este contrato, confía solamente en el Receiver,  y al recibir ese mensaje, transfiere fondos de su balance al usuario Ethereum/RSK correspondiente al usuario BTC original.

Veamos ahora el camino inverso.

Cuando el contrato Bridge recibe una transferencia desde un usuario Ethereum/RSK, emite un mensaje a la instancia de un contrato Sender. Esta instancia tiene estado conteniendo una lista de estas transacciones QUE TODAVIA no fueron respaldadas por una transacción BTC. Los federados consultan periódicamente a este estado.

Ningún federado puede cumplir en solitario con esta transferencia. Cada uno necesita de la ayuda de otros para construir una transacción BTC válida. Entonces, cuando una transferencia Ethereum/RSK de liberación de fondos aparece en el sistema, un federado puede construir la transacción BTC correspondiente. Eso es parte del código del federado, y no involucra nada de consenso. Cualquier federado puede enviar al contrato Sender una transacción BTC serializada a un arreglo de bytes y los otros federados pueden ir agregándole firmas. En próximo post discutiré más en detalle el proceso. Luego, cuando un federado detecte o arme una transacción con suficientes firmas, la puede enviar a la red Bitcoin. A discutir: cómo evitar el double spend, en próximo post.

Vean que así, gran parte del código del federado puede cambiarse, por ejemplo, para proponer mejores transacciones BTC, con mejor fee, etc, adaptarse con el tiempo a cambios en Bitcoin, sin afectar al consenso.

Luego, los federados también informan al contrato Sender las transacciones BTC que salen de la cuenta BTC bridge. El contrato Sender, al igual que el Receiver, va anotando los votos de los federados. Cuando tiene suficiente evidencia, elimina la transacción Ethereum/RSK original de la lista de pendientes, y la anota (a revisar si es necesario) como cumplida (la alternativa es simplemente emitir un evento y no ocupar memoria de almacenamiento).

También este proceso de votación de transacción BTC podría estar a cargo de Receiver, y cuando éste colecte suficientes votos, enviar un mensaje a Sender.

Hay varios detalles a discutir más en profundidad. Vean que agregué, en el esquema de arriba, una instancia de BTCRelay. Es un contrato ya existente (a revisar su actualización) que va registrando los bloques válidos de Bitcoin, y puede servir para validar si una transacción determinada existe y tiene confirmaciones. Tanto Sender como Receiver podrían consultarlo para confirmar las transacciones que están manejando.

Hay algo de código de estos contratos en mis proyectos públicos de Github, pero están en etapa inicial. Espero ir completándolos, para mostrarlos y comentarlos en esta serie de posts. Como dice Linus, talk is easy, show me the code!

Nos leemos!

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