- Solución trans-rollup basada en Ethereum permite enviar transacciones de A a B con un intermediario.
- Las transacciones requieren de un campo de Memo para especificar información adicional del emisor.
El inventor de Ethereum, Vitalik Buterin, ha presentado una propuesta que permitiría la comunicación entre dos protocolos que usen soluciones de escalado de segunda capa conocidas como Rollups. Titulada «Cross-rollup DEX with smart contracts only on the destination side», la propuesta permite que un usuario envíe fondos desde un Rollup a otro en caso de que solo uno de los dos usuarios tenga soporte completo de contratos inteligentes y el otro solo pueda usar «transacciones simples».
Según el concepto del mismo Vitalik, los Rollups son una serie de transacciones fuera de cadena que se agregan en un contrato inteligente compatible con Ethereum. Este contrato inteligente habilita a los usuarios para hacer transacciones de forma segura que luego son agregadas a la cadena principal. Sin embargo, la solución tiene complicaciones.
Los Rollup tienen diferentes tipos y pueden usar contratos inteligentes únicos. Por ejemplo, los «Optimistic Rollups» (ORs) operan con un agregador de transacciones que usa una cantidad pequeña de información, otros como los ZK-Rollups pueden operar bajo un esquema de «zero knowledge proof». Debido a sus características, es difícil que los Rollups interactúan entre sí.
¿Cómo funciona la solución del inventor de Ethereum?
En su propuesta, Buterin explica una de las muchas implementaciones que podría tener su solución, en un intercambio descentralizado en el que interactúan «Alice», usuaria que quiere cambiar monedas usando dos Rollups distintos, e Ivan, el intermediario. Aquí, es necesario que uno de los dos Rollups (A) tenga que un «campo de memo» o que permita el uso de órdenes de baja denominación del valor enviado en una transacción como un memo.
Este intermediario debe tener fondos en los contratos inteligentes de ambos Rollups (A y B), por lo tanto, el intermediario es llamado IVAN_A e IVAN_B. Alice enviará fondos desde la dirección (ALICE_A) a la dirección IVAN_A usando la primera de las dos soluciones de segunda capa. Además, el Rollup B debe poder ser la siguiente norma propuesta por Buterin:
Si alguien envía una transacción enviando monedas TRADE_VALUE a IVAN_A, conteniendo una dirección DESTINATION como memo, entonces después de los bloques MIN_REDEMPTION_DELAY puede enviar una transacción a IVAN_B conteniendo una prueba de la transferencia, que pone en cola una retirada de monedas TRADE_VALUE a la dirección DESTINATION.
Los memos permiten que Alice especifique que ella es la receptora de los fondos que llegarán desde IVAN_B a ALICE_B. Este destinatario recibirá los fondos después de un periodo de tiempo determinado. Así, las transacciones pueden puestas en lote e indexadas de tal manera que coincidan con las transacciones hechas por el Rollup A. Buterin resume el funcionamiento de su solución de la siguiente manera:
Alicia envía una transacción a IVAN_A con N monedas y una nota ALICE_B. Iván envía una transacción enviando monedas TRADE_VALUE * (1 – tasa) a través de IVAN_B a ALICE_B.
En el «peor de los casos», Buterin explica que el intermediario podría no enviar las monedas a la dirección de ALICE_B, pero considera que la usuario puede esperar a que Rollup A confirme la transacción para «encontrar una ruta alternativa» que envíe sus fondos a Rollup B y «reclamar los fondos ella misma». Buterin concluye:
La principal limitación del esquema es que IVAN_B necesita mantener una gran cantidad de capital para asegurar que todos los remitentes recibirán el pago.
