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

Fuente: Bitcoin Magazine; Compilado por: Wuzhu, Golden Finance

Rollups se ha convertido recientemente en el foco de atención para la escalabilidad de BTC, convirtiéndose en la primera cosa que realmente eclipsa a Lightning Network y recibe una atención más amplia. El objetivo de Rollups es convertirse en una capa off-chain de segunda capa que no esté limitada o restringida por la liquidez central de Lightning Network, lo que significa que los usuarios finales necesitan que alguien les asigne (o ‘preste’) fondos de antemano para recibir pagos, o que los nodos de enrutamiento necesitan tener saldos de canal para facilitar el flujo completo del monto de pago desde el remitente hasta el receptor.

Estos sistemas originalmente se ejecutaban en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO, como BTC. Este artículo no tiene la intención de discutir la implementación actual en BTC, sino más bien las características del Rollup idealizado que se ha buscado durante mucho tiempo, que dependen de la capacidad de verificar directamente la Prueba de conocimiento cero (ZKP) en BTC, una función que BTC no admite actualmente.

La arquitectura básica de Roll es la siguiente: una sola cuenta (llamada UTXO en BTC) mantiene el saldo de todos los usuarios en el Rollup. Esta UTXO contiene un compromiso que representa todas las saldos actuales de las cuentas en el Rollup en forma de raíz de Merkle tree. Todas estas cuentas están autorizadas con una 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 proporcionando una prueba de transacción que demuestre que su cuenta es parte del árbol de Merkle, pueden salir del Rollup unilateralmente sin el permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar el saldo de la cuenta on-chain en el proceso de completar transacciones off-chain; sin este ZKP, las transacciones serán inválidas y no se pueden incluir en la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en la cuenta off-chain han sido debidamente autorizados 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 de Merkle on-chain, los usuarios pueden verlo y acceder a él, ¿cómo pueden colocar sus ramas en el árbol para poder salir cuando lo deseen sin permiso?

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 agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Esto esencialmente 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 permite ahorrar una gran cantidad de gastos y espacio de Bloquear (ahorrando así fondos), al mismo tiempo que permite a los usuarios garantizar 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 mediante la cadena de Bloquear, es decir, las transacciones que no incluyen un resumen de cuenta o diferencias 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 fuera de la cadena Bloquear. Esto introduce un problema sutil, rollup aún debe garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas Bloquear se utilizan con este propósito, diseñadas específicamente 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 SPV, es decir, que los datos se hayan publicado en otro sistema.

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

Esto abrió la puerta a ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para impulsar el 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 sistemas fuera de BTC.

En un dilema

Esto plantea un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente hay una opción binaria de publicar 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 de BTC como capa de disponibilidad de datos establecerá un límite máximo de escalabilidad para rollup. El espacio de bloqueo es limitado, lo que establece un límite superior en la cantidad de rollups que pueden existir y en la cantidad total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere una cantidad proporcional de espacio de bloqueo para las 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á el límite duro de ganancias de escalabilidad, pero también traerá 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 publicaron 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 defenderse del engaño 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 un Bloquear en lugar de transmitir el Bloquear real, lo que permite que los datos estén disponibles.

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