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

Fuente: Bitcoin Magazine; Traducción: Wu Zhu, Golden 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.

Inicialmente, estos sistemas se ejecutaban en Ethereum y otros sistemas Turing completos, pero recientemente el enfoque se ha desplazado a portarlos a cadenas de bloques basadas en UTXO, como BTC. Este artículo no pretende discutir el estado actual de la implementación en BTC, sino más bien discutir la funcionalidad largamente buscada de los Rollups idealizados, que depende de una característica que BTC no admite actualmente, a saber, la capacidad de verificar la Prueba de conocimiento cero (ZKP) directamente en BTC.

La arquitectura básica de Roll es la siguiente: una única cuenta (en BTC, UTXO) almacena el saldo de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que existe en forma de raíz de Merkle de un árbol de Merkle, comprometiéndose con todos los saldos actuales de cuenta existentes 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, pueden salir unilateralmente de Rollup sin la necesidad de la autorización del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar el saldo de la cuenta on-chain durante el proceso de completar transacciones off-chain. Sin este ZKP, las transacciones serán inválidas y no se pueden incluir en el bloque. Esta prueba permite a las personas verificar si todos los cambios en el saldo off-chain cuentan con la autorización adecuada del titular de la cuenta, y si el operador no ha actualizado 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, entonces ¿cómo colocan sus ramas en el árbol para poder salir sin permiso cuando lo deseen?

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 utiliza la diferencia de saldo. Esto es esencialmente un resumen de qué cuentas aumentaron o disminuyeron los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup solo contenga cambios en el saldo de cuenta que ocurrieron. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el principio del Rollup para obtener el estado actual del saldo de 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í dinero), al tiempo que 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 utilizando la cadena de Bloquear, por lo que 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 colocar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea sutiles problemas, ya que rollup todavía necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se utilizan para este fin, diseñadas específicamente como capas de disponibilidad de datos para sistemas como rollup.

Esto ha creado 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 sea absolutamente correcto. Sin embargo, cuando se publica en sistemas externos, lo mejor que puede hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere validar que los datos existan en otras pruebas en cadena, que finalmente es un problema de Máquina de oráculo. La cadena de Bloquear de BTC no puede validar completamente nada que suceda fuera de su propia cadena de Bloquear, lo mejor que puede hacer es validar ZKP. Sin embargo, ZKP no puede validar si los datos de rollup en la cadena de Bloquear se han publicado realmente después de generarse. No puede validar si la información externa realmente se ha hecho pública para todos.

Esta apertura de la puerta para el ataque de retención de datos implica crear un compromiso con los datos publicados y utilizarlo para impulsar rollup, pero los datos no están realmente disponibles. Esto hace que los usuarios no puedan retirar fondos. La única solución real es depender completamente del valor y la estructura de incentivos de un sistema que no sea BTC.

En un 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 los datos en la cadena de bloques de BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad, la soberanía y la escalabilidad de rollup.

Por un lado, utilizar la cadena de bloques Bitcoin como capa de disponibilidad de datos establece un límite estricto a la escalabilidad de rollup. El espacio de bloque es limitado, lo que establece un límite en la cantidad de rollup que puede existir a la vez y la cantidad total de transacciones que pueden procesarse off-chain. 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 aspecto.

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 los usuarios desean extraer no se publican automáticamente en la cadena de bloques, el estado de Rollup no 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 mediante la producción de Bloquear en lugar de difundir el Bloquear real, para hacer que los datos estén disponibles.

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