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 la expansión de BTC, convirtiéndose en la primera cosa que realmente ha robado protagonismo a la Red Lightning, en términos de atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no está sujeta a las limitaciones de liquidez centrales de la Red Lightning, es decir, los usuarios finales necesitan que alguien asigna (o ‘presta’) fondos por adelantado para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo completo del monto de pago desde el remitente hasta el destinatario.

Estos sistemas fueron originalmente implementados en Ethereum y otros sistemas Turing completo, pero recientemente se ha puesto más énfasis en portarlos a cadenas de bloques basadas en UTXO, como BTC. Este artículo no pretende discutir la implementación actual en BTC, sino más bien las capacidades ideales de Rollup que se han buscado durante mucho tiempo, las cuales dependen de la capacidad de verificar directamente Prueba de conocimiento cero (ZKP) en BTC, una funcionalidad que BTC no admite actualmente.

La arquitectura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) almacena el saldo de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que representa todos los saldos actuales de las cuentas existentes en Rollup en forma de raíz de Merkle Tree. Todas estas cuentas están autorizadas con llave pública/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 pruebe que su cuenta es parte del árbol de Merkle, pueden salir de Rollup unilateralmente sin la necesidad de 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 en el proceso de completar la transacción fuera de la cadena. Si no hay ZKP, la transacción será inválida y no se puede incluir en la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en la cuenta fuera de la cadena están autorizados por el titular de la cuenta y si el operador no actualiza maliciosamente el saldo para robar 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 pueden colocar sus ramas en el árbol para poder salir cuando lo deseen sin permiso?

Rollup adecuado

En el Rollup adecuado, cada vez que se confirma una nueva transacción off-chain y cambia el estado de la cuenta Rollup, la información se coloca directamente en la cadena de bloques. No es el árbol completo, eso sería absurdo, sino la información necesaria para reconstruir el árbol. En una implementación simple, el resumen de todas las cuentas existentes en el Rollup contendrá saldos 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.

Esto puede ahorrar una gran cantidad de gastos y espacio de Bloquear (ahorrando así fondos), al mismo tiempo que permite a los usuarios asegurar el acceso a la información necesaria para salir unilateralmente. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado a los usuarios por la cadena de Bloquear, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Periodo de validez

Otra forma de abordar el problema de la disponibilidad de datos de retiro de usuarios es colocar los datos en otro lugar que no sea la cadena de Bloquear. Esto plantea el sutil problema de que rollup aún debe asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se utilizan para este propósito, diseñadas específicamente como capas 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 BTC Bloquear, las reglas de Consenso pueden garantizar que esté absolutamente correcto. Sin embargo, cuando se publica en un sistema externo, lo mejor que puede hacer es verificar la prueba SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere una prueba de que los datos existen en una prueba en cadena, que es en última instancia un problema de máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada más que 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 incluidos en el bloque se publican realmente después de generarse. No puede verificar si la información externa realmente se hace pública para todos.

Este ataque de retención de datos abrió la puerta, es decir, creando compromisos para publicar datos y utilizando esto para impulsar rollup, pero los datos no están disponibles en realidad. Esto hace que los usuarios no puedan retirar fondos. La única solución real es depender totalmente de un sistema de valor y estructura de incentivos que no sea BTC.

En un dilema

Esto ha puesto a rollup en un dilema. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una elección binaria entre publicar 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, el uso de Bitcoin Cadena de bloques como capa de disponibilidad de datos establecerá un límite máximo duro para la escalabilidad de rollup. El espacio de Bloquear es limitado, lo que establece un límite en la cantidad de rollup que puede existir en un momento dado, así como la cantidad total de transacciones que todos los rollups pueden procesar off-chain. Cada actualización de rollup requiere un espacio de Bloquear proporcional a la cantidad de cuentas cuyo saldo ha cambiado desde la última actualización. La teoría de la información solo permite que los datos se compriman hasta cierto punto, por lo que no hay más potencial de escalabilidad en este punto.

Por otro lado, el uso de capas diferentes para lograr la disponibilidad de datos eliminará el límite rígido de ganancias de escalabilidad, pero también traerá nuevos problemas de seguridad y soberanía. En Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que un usuario necesita extraer no se publican automáticamente en la cadena de bloques, el estado de Rollup no puede cambiar. Con Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado para resistir el fraude 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 al producir Bloquear en lugar de transmitirlos realmente, lo que permite que los datos estén disponibles.

Entonces, si realmente logramos implementar una implementación ideal de Rollup en BTC, logrando verdaderamente retiros unilaterales de los usuarios, ¿cómo sería eso?