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

Fuente: Bitcoin Magazine; Compilación: Wuzhu, Jinse Finance

Los rollups se han convertido recientemente en el foco del escalado de BTC, convirtiéndose en lo primero que realmente “roba el espectáculo” de Lighting Network, en términos de una atención más amplia. Los rollups están diseñados para ser una capa 2 fuera de la cadena que no está restringida ni restringida por las restricciones centrales de Liquidez de Lighting Network, es decir, el usuario final necesita que alguien asigne (o “preste”) los fondos por adelantado para recibir el dinero, o el enrutamiento intermedio Nodo necesita el saldo del canal para facilitar el flujo del monto del pago desde el remitente hasta el receptor.

Estos sistemas originalmente se ejecutaban en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en trasladarlos a cadenas de bloques basadas en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir el estado actual de implementación en BTC, sino más bien discutir las capacidades de idealización de Rollup que las personas han estado persiguiendo durante mucho tiempo, lo que depende de las capacidades que actualmente no son compatibles con BTC, es decir, la capacidad de verificar Prueba de conocimiento cero (ZKP) directamente en BTC.

La estructura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) que guarda 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, comprometiéndose a todos los saldos actuales de las cuentas en Rollup. Todas estas cuentas están autorizadas con llave pública/llave privada, por lo que los usuarios aún deben firmar cierto contenido 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, pueden salir de Rollup unilateralmente sin el permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar la raíz de merkle del saldo de la cuenta en la cadena de bloques al completar las transacciones fuera de la cadena. Sin este ZKP, la transacción será inválida y no se podrá incluir en la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en el saldo de la cuenta fuera de la cadena han sido autorizados correctamente por el titular de la cuenta, y si el operador no ha actualizado los saldos de manera maliciosa 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 chain, los usuarios pueden verlo y acceder a él, ¿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 fuera de la cadena (off-chain) 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 simple, el resumen de todas las cuentas existentes en el Rollup contendrá el saldo y las cuentas solo se agregan en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldos. Esto es esencialmente un resumen de qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup contenga solo cambios en los saldos de cuenta que han ocurrido. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el principio del Rollup para obtener el estado actual de los saldos de cuenta, lo que les permite reconstruir el árbol de Merkle de los saldos actuales.

Esto puede ahorrar una gran cantidad de gastos y espacio de bloque (ahorrando así dinero), al tiempo que permite a los usuarios verificar la información necesaria para la salida unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado a los usuarios mediante la cadena de bloques, es decir, las transacciones que no incluyen un resumen de la cuenta o una diferencia de cuenta se consideran inválidas.

Período de validez

Otra forma de abordar el problema de la disponibilidad de datos de retiro de usuario es colocar los datos en otro lugar que no sea en la cadena de Bloquear. Esto plantea un problema sutil en el que rollup todavía necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se utilizan con este fin, diseñadas específicamente para servir como capa de disponibilidad de datos para sistemas como rollup.

Esto crea un dilema de seguridad igualmente poderoso. Cuando los datos se publican directamente en la cadena de bloques de 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 necesita validar la existencia de datos en otras pruebas en cadena, lo que finalmente es un problema de Máquina de oráculo. La cadena de Bloquear de BTC no puede verificar completamente nada más que ocurra en su propia cadena de Bloquear, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en la cadena de Bloquear realmente se han difundido 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, a la creación de compromisos para publicar datos y utilizarlos para impulsar rollup, pero 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 sistemas de valor y estructuras de incentivos que no dependan de BTC.

En un estado de indecisión

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

Por un lado, el uso de la cadena de bloques Bitcoin como capa de disponibilidad de datos establecerá un límite máximo para la escalabilidad de rollup. El espacio 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 off-chain por todos los rollups. Cada actualización de rollup requiere un 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 plantea nuevos problemas de seguridad y soberanía. En el Rollup que utiliza BTC para lograr la disponibilidad de datos, si los usuarios necesitan extraer datos que no se hayan publicado 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 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 transmitirlos realmente, lo que hace que los datos estén disponibles.

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