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

Fuente: Bitcoin Magazine; Compilado por: Wuzhu, 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.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completos, pero recientemente se ha puesto más énfasis 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 implementación en BTC, sino más bien las capacidades ideales de Rollup que se han perseguido durante mucho tiempo, las cuales dependen de la capacidad de verificar directamente pruebas de conocimiento cero (ZKP) en BTC, algo que no es compatible actualmente.

La arquitectura 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 Merkle, comprometiendo todos los saldos actuales de cuenta en Rollup. Todas estas cuentas están autorizadas con la Llave pública/Llave privada, por lo que para realizar gastos off-chain, los usuarios aún deben firmar cierto contenido con la Llave secreta. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente demostrando con una prueba de transacción que su cuenta es parte del árbol Merkle, pueden salir de Rollup unilateralmente sin la necesidad de permiso del operador.

Los operadores de Rollup deben incluir una prueba de conocimiento nulo (ZKP) en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta en la cadena en el proceso de completar transacciones fuera de la cadena. Sin esta ZKP, la transacción sería inválida y no se puede incluir en el bloque. Esta prueba permite a las personas verificar si todos los cambios en la cuenta fuera de la cadena están debidamente autorizados por el titular de la cuenta y si el operador no actualiza maliciosamente el saldo para robar fondos de los usuarios o redistribuirlos de manera deshonesta 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 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 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 demasiado 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 agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, utiliza diferencias de saldo. Básicamente, esto resume qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite 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.

Esto puede ahorrar una gran cantidad de gastos y espacio de Bloquear (y por lo tanto ahorrar dinero), al tiempo que permite a los usuarios asegurarse de que la información necesaria para una salida unilateral esté disponible. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado a los usuarios mediante la cadena 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 bloques. Esto introduce un problema sutil, rollup todavía necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de bloques se utilizan para este propósito, diseñadas específicamente como capas de disponibilidad de datos para sistemas como rollup.

Esto crea un dilema de seguridad igualmente difícil de resolver. 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 se puede hacer es verificar la prueba SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere la validación de los datos que existen en otras pruebas on-chain, lo que finalmente se convierte en un problema de Máquina de oráculo. La cadena de Bloquear de BTC no puede validar completamente nada más que lo que sucede 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 se han publicado abiertamente después de ser generados. No puede verificar si la información externa realmente está disponible para todos.

Esta apertura de la puerta para los ataques de retención de datos implica comprometerse con la publicación de datos y utilizarlo para impulsar el rollup, pero en realidad los datos no están disponibles. Esto hace que los usuarios no puedan retirar fondos. La única solución real es confiar completamente en el valor y la estructura de incentivos de un sistema fuera del BTC.

Entrar y salir de la encrucijada

Esto plantea un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una opción binaria para publicar 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, utilizar la cadena de bloques Bitcoin como capa de disponibilidad de datos establece un límite duro para la escalabilidad de rollup. El espacio en bloque es limitado, lo que establece un límite en la cantidad de rollups que pueden existir al mismo tiempo y en la cantidad total de transacciones que todos los rollups pueden procesar fuera de la cadena. Cada actualización de rollup requiere un espacio en 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 punto.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminaría el límite máximo de escalabilidad, pero también presenta nuevos problemas de seguridad y soberanía. En un Rollup que utiliza BTC para la disponibilidad de datos, si los datos que el usuario necesita extraer 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 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 produciendo Bloquear en lugar de transmitirlo realmente, lo que permite que los datos estén disponibles.

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