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

Fuente: Bitcoin Magazine; Compilación: Wuzhu, 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 el protagonismo a la red Lightning Network en términos de atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no está limitada por las restricciones de liquidez del núcleo de la red Lighting Network, es decir, los usuarios finales necesitan que alguien asigne (o ‘preste’) fondos con anticipación para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo de pago de remitente a destinatario.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a cadenas de bloques basadas en UTXO (como BTC). Este artículo no tiene la intención de discutir el estado actual de la implementación en BTC, sino de discutir las características del Rollup ideal que se ha buscado durante mucho tiempo, que depende de la capacidad de BTC para verificar directamente Prueba de conocimiento cero (ZKP), una función que actualmente no es compatible con BTC.

La arquitectura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) almacena los saldos de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que existe como raíz de Merkle en un árbol de Merkle, comprometiendo todos los saldos actuales de las cuentas en Rollup. Todas estas cuentas están autorizadas con llave pública/privada, por lo que para realizar gastos fuera de la cadena, los usuarios todavía deben firmar algunos contenidos con la llave secreta. 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, pueden salir de Rollup unilateralmente sin 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 del merkle del saldo de la cuenta en la cadena de bloques on-chain durante el proceso de transacción 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 autorizados correctamente 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 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 sin permiso cuando lo deseen?

Rollup adecuado

En un Rollup adecuado, cada vez que se confirma una nueva transacción off-chain y cambia el estado de la cuenta de 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 agregan en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Básicamente, esto resume qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto hace que cada actualización de Rollup solo contenga cambios en el saldo de la cuenta que han ocurrido. Luego, los usuarios pueden simplemente escanear la cadena y “calcular” desde el principio del Rollup para obtener el 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 muchos gastos y espacio en Bloquear (lo que ahorra dinero), al tiempo que se 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 a los usuarios mediante la cadena Bloquear, y las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Fecha de caducidad

Otra forma de abordar el problema de la disponibilidad de datos de retiro de usuarios es poner los datos en algún lugar fuera de la cadena de bloques. Esto introduce problemas sutiles, ya que el rollup aún debe garantizar que los datos estén disponibles en otra parte. Tradicionalmente, se han utilizado otras cadenas de bloques 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 son absolutamente correctos. Sin embargo, cuando se publican en un sistema externo, lo mejor que pueden hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere la validación de que los datos existen en otras pruebas on-chain, lo que finalmente es un problema de Máquina de oráculo. La cadena Bloquear de BTC no puede verificar completamente nada más que lo que sucede en su propia cadena Bloquear, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos rollup en la cadena 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.

Esto abre la puerta a los ataques de retención de datos, es decir, crear compromisos en los datos publicados y utilizarlos para impulsar el rollup, pero los datos no están realmente disponibles. Esto hace que los usuarios no puedan extraer fondos. La única solución real es depender completamente del valor y la estructura de incentivos de los sistemas que no sean BTC.

Dilema

Esto plantea un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente hay una elección binaria entre publicar datos en la cadena de bloques 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 la cadena de bloques BTC como capa de disponibilidad de datos establece un límite máximo para la escalabilidad de rollup. El espacio en la cadena de bloques 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 pueden ser procesadas fuera de la cadena. Cada actualización de rollup requiere espacio en la cadena de bloques proporcional al número 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 máximo de escalabilidad, pero también plantea nuevos problemas de seguridad y soberanía. En Rollup, que utiliza BTC para lograr la disponibilidad de datos, si los datos que el usuario desea extraer no se publican automáticamente en la cadena de bloques, el estado de Rollup no podrá cambiar. Con Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado para resistir el fraude y la ocultación de 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 difundir el Bloquear real, lo que permite que los datos estén disponibles.

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