Bitcoin Magazine: ¿Qué desafíos enfrenta Rollup?

Fuente: Bitcoin Magazine; Traducción: Wu Zhu, Golden Finance

Rollups se ha convertido recientemente en el foco de atención para la escalabilidad de BTC, convirtiéndose en la primera cosa que realmente le ha robado protagonismo a la Red Lightning en términos de atención más amplia. Los Rollups tienen como objetivo convertirse en una capa fuera de la cadena (off-chain) de segunda capa que no esté limitada o restringida por la liquidez central de la Red Lightning, es decir, los usuarios finales deben tener fondos asignados (o ‘prestados’) de antemano para recibir dinero, o los nodos de enrutamiento necesitan tener saldo de canal para facilitar el flujo completo de los montos de pago desde el remitente hasta el receptor.

Estos sistemas fueron originalmente implementados en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en trasladarlos a cadenas de bloques basadas en UTXO, como BTC. Este artículo no tiene la intención de discutir la implementación actual en BTC, sino más bien discutir las capacidades de idealización de Rollup que las personas han estado persiguiendo durante mucho tiempo, las cuales dependen de la capacidad de verificar directamente la prueba de conocimiento cero (ZKP) en BTC, que actualmente no es compatible.

La estructura básica de Roll es la siguiente: una sola cuenta (UTXO en BTC) que almacena el saldo de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que existe en forma de raíz de Merkle del árbol de Merkle, comprometiendo todos los saldos actuales de las cuentas en Rollup. Todas estas cuentas están autorizadas con una llave pública/llave privada, por lo que los usuarios aún deben firmar ciertos contenidos con una llave secreta para realizar gastos fuera de la cadena. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente haciendo una transacción que demuestre que su cuenta es parte del árbol de Merkle, y así pueden salir de Rollup unilateralmente sin el permiso del operador.

Los operadores de Rollup deben incluir una prueba de conocimiento cero (ZKP) en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta en la cadena de bloques durante el proceso de finalización de las transacciones fuera de la cadena (off-chain). Sin esta ZKP, la transacción sería inválida y no se podría incluir en el bloque. Esta prueba permite a las personas verificar si todos los cambios en la cuenta fuera de la cadena han sido debidamente autorizados por el titular de la cuenta y si el operador no ha actualizado maliciosamente el saldo para robar los fondos de los usuarios o redistribuirlos deshonestamente a otros usuarios.

El problema es que si solo se publica la raíz del árbol de Merkle en la cadena, los usuarios pueden verlo y acceder a él, pero ¿cómo colocan sus ramas en el árbol para que puedan salir sin permiso cuando lo deseen?

Rollup adecuado

En un Rollup adecuado, cada vez que se confirma una nueva transacción fuera de la cadena y cambia el estado de la cuenta Rollup, la información se coloca directamente en la cadena de bloques. No es todo el árbol, eso sería absurdo, sino la información necesaria para reconstruir el árbol. En una implementación sencilla, el resumen de todas las cuentas existentes en el Rollup contendrá el saldo y las cuentas solo se agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utilizan desviaciones de saldo. Este es esencialmente un resumen de qué CUENTA han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup incluya solo los cambios de saldo de cuenta que se producen. A continuación, los usuarios pueden simplemente escanear la cadena y “calcular” desde el principio del Rollup para llegar al estado actual del saldo de la cuenta, lo que les permite reconstruir el árbol de Merkle del saldo actual.

De esta manera, se pueden ahorrar gastos significativos y espacio de bloqueo (lo que ahorra fondos), al tiempo que aún permite a los usuarios garantizar el acceso a la información necesaria para una salida unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado por la cadena de bloques, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran transacciones inválidas.

Período de validez

Otra forma de abordar el problema de la disponibilidad de los datos de extracción de los usuarios es almacenar los datos en otro lugar fuera de la cadena de bloques. Esto plantea un problema sutil, ya que rollup aún debe garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, se han utilizado otras cadenas de bloques con este propósito, diseñadas específicamente como capa de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema de seguridad igualmente fuerte. Cuando los datos se publican directamente en la cadena de bloques Bitcoin, las reglas de consenso pueden garantizar que sean absolutamente correctos. Sin embargo, cuando se publican en sistemas externos, lo mejor que pueden hacer es verificar la prueba de SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere la validación de que los datos existen en pruebas on-chain de otras cadenas de bloques, lo que finalmente es un problema de Máquina de oráculo. La cadena de bloques de Bloquear de BTC no puede verificar completamente cualquier cosa que suceda fuera de su propia cadena de bloques, aparte de lo que sucede en su propia cadena de bloques. Lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en la cadena de bloques de Bloquear se han transmitido públicamente después de su generación. No puede verificar si la información externa realmente se ha hecho pública para todos.

Esta apertura de la puerta para los ataques de retención de datos implica la creación de compromisos con respecto a la publicación de datos y su uso para impulsar el rollup, aunque en realidad los datos no están disponibles. Esto hace que los usuarios no puedan retirar sus fondos. La única solución real es depender completamente de un sistema de valor y estructura de incentivos que no sea BTC.

Entre la espada y la pared

Esto presenta un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una elección binaria entre publicar los datos en la cadena de bloques de BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad, soberanía y escalabilidad de rollup.

Por un lado, usar la cadena de bloques Bitcoin como capa de disponibilidad de datos establecerá un límite duro para la escalabilidad de rollup. El espacio de bloque es limitado, lo que establece un límite para la cantidad de rollups que pueden existir a la vez y la cantidad total de transacciones que todos los rollups pueden procesar off-chain. Cada actualización de rollup necesita espacio de bloque proporcional a la cantidad de cuentas cuyo saldo ha cambiado desde la última actualización. La teoría de la información solo permite comprimir los datos hasta cierto punto, por lo que no hay más potencial de escalabilidad en este sentido.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite duro de ganancias de escalabilidad, pero también traerá nuevos problemas de seguridad y soberanía. En un Rollup que utiliza BTC para lograr la disponibilidad de datos, si los usuarios necesitan extraer datos que no se publican automáticamente en la cadena de bloques, el estado del Rollup no puede cambiar. Con Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado para resistir el engaño y ocultar datos.

Ahora, cualquier productor de Bloquear en el sistema de disponibilidad de datos externos puede secuestrar los fondos de los usuarios de BTCRollup mediante la producción de Bloquear en lugar de difundir el Bloquear real, para que los datos estén disponibles.

Entonces, ¿cómo sería si realmente logramos una implementación ideal de Rollup en BTC y logramos la retirada unilateral de los usuarios?