En un esfuerzo continuo por combatir el aumento de las tarifas de transacción mientras se crea un ecosistema unificado, el cofundador de Ethereum, Vitalik Buterin, ha propuesto una solución para un tipo particular de escalado de resumen cruzado.

La propuesta describe cómo dos protocolos que utilizan conjuntos pueden comunicarse entre sí mientras mantienen la interconectividad y la capacidad de composición.

Los rollups son soluciones de capa dos que son esencialmente redes de contratos inteligentes que procesan y almacenan datos de transacciones fuera de la cadena principal. Sin embargo, hay varios tipos de acumulación diferentes, cada uno de los cuales utiliza contratos inteligentes únicos, como optimista y conocimiento cero.

Si bien varios proyectos de DeFi han implementado paquetes acumulativos de capa dos, como Loopring y Synthetix, los detalles de los diversos paquetes acumulativos significan que los proyectos no pueden comunicarse entre sí directamente en la capa dos.

La propuesta de Buterin asume que un paquete acumulativo puede procesar transacciones simples mientras que el otro tiene soporte completo para contratos inteligentes. Ya existen propuestas para transferencias entre dos protocolos habilitados para contratos inteligentes que utilizan acumulaciones.

Para explicar cómo funciona la propuesta, Buterin proporciona el ejemplo de un intermediario de intercambio hipotético al que llamó ‘Ivan’, donde Ivan tiene una cuenta ‘IVAN_A’ en el paquete A que controla por completo, y también tiene algunos fondos depositados en un contrato inteligente ‘IVAN_B ‘en el paquete acumulativo B.

El contrato inteligente estaría programado para aceptar «memorandos» que incluyan datos adicionales de cualquier persona que le envíe para asegurar cualquier transacción futura. Las transacciones crean una capa de conexión que mantiene los depósitos en todos estos contratos aislados, lo que permite que el paquete A se envíe al paquete B a través de esta capa.

Buterin sugirió que el comportamiento funcionaría de la siguiente manera;

“Alice envía una transacción a IVAN_A con N monedas y un memo ALICE_B. Iván envía una transacción enviando monedas TRADE_VALUE * (1 – tarifa) a través de IVAN_B a ALICE_B «

Agregó que el peor comportamiento sería si Iván no envía monedas a ALICE_B como se espera que lo haga.

Al abordar el escenario del «peor de los casos» que podría surgir como resultado del uso de la situación propuesta, Buterin enfatizó que Alice aún podría esperar hasta que la transacción en el paquete acumulativo A se confirme, encuentre una ruta alternativa para obtener monedas en el paquete acumulativo B para pagar tarifas, y luego simplemente reclamar los fondos ella misma.

En respuesta a la propuesta, Alon Muroch señaló que funcionaba de manera similar a cómo los bancos liquidan las transacciones:

“Eso es muy interesante, similar a cómo los bancos liquidan las transacciones entre ellos. Agrupar activos en «cuentas» separadas podría tener limitaciones, una solución podría ser solo grandes grupos en ambos extremos y las tarifas se dividirían proporcionalmente «.