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

Fuente: Bitcoin Magazine; Compilado por: Wu Zhu, Golden Finance

Rollups se ha convertido recientemente en el foco de la escalabilidad de BTC, convirtiéndose en la primera cosa que realmente ha eclipsado a Lightning Network y ha ganado una atención más amplia. Rollups tiene como objetivo convertirse en una segunda capa off-chain que no esté restringida por las limitaciones de liquidez del núcleo de Lightning Network, lo que significa que los usuarios finales necesitan que alguien asigne (o “preste”) fondos de antemano para recibir dinero, o que los nodos intermedios necesitan tener saldos de canal para facilitar el flujo completo del pago desde el remitente hasta el destinatario.

Estos sistemas originalmente se ejecutaban en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en trasladarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir la implementación actual en BTC, sino más bien las capacidades idealizadas de Rollup que las personas han estado persiguiendo durante mucho tiempo, lo que depende de la capacidad no admitida actualmente en BTC para verificar zk-SNARKs directamente en BTC.

La estructura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) que guarda los saldos 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 llave pública/llave privada, por lo que para realizar gastos fuera de la cadena, los usuarios aún deben firmar cierto contenido con llave secreta. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente demostrando que sus cuentas son parte del árbol Merkle a través de una transacción, pueden salir unilateralmente de Rollup 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 de Merkle del saldo de la cuenta en cadena al completar la transacción fuera de la cadena. Si no se proporciona esta ZKP, la transacción será 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 autorizados por el titular de la cuenta y si el operador no actualiza 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 Merkle en la cadena, los usuarios pueden ver y acceder a ella, pero ¿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 el estado de la cuenta Rollupcambia, 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 incluirá el saldo y las cuentas solo se agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, use diferencias de saldo. 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 el saldo de la cuenta que ocurrieron. Luego, los usuarios pueden simplemente escanear la cadena y realizar un ‘cálculo’ 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 grandes gastos y espacio de Bloquear (lo que ahorra dinero), al tiempo que se permite a los usuarios garantizar el acceso a la información necesaria para salir de manera unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado por la cadena de Bloquear a los usuarios, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia 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 de Bloquear. Esto introduce un problema sutil, rollup todavía necesita asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se utilizan para este propósito, diseñadas específicamente como una capa de disponibilidad de datos para sistemas como rollup.

Esto crea un dilema de seguridad igualmente fuerte. Cuando los datos se publican directamente en la cadena Bitcoin, las reglas de consenso pueden garantizar que sean 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 en la cadena, lo que finalmente es un problema de Máquina de oráculo. La cadena de Bitcoin no puede validar completamente nada que ocurra fuera de su propia cadena, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en la cadena, una vez generados, realmente se han transmitido públicamente. No puede verificar si la información externa realmente se ha hecho pública para todos.

Esto abrió la puerta a los ataques de retención de datos, es decir, crear compromisos sobre la publicación de datos y utilizarlos para avanzar en rollup, pero los datos en realidad no están 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 distintos a BTC.

En un estado de indecisión

Esto presenta un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente existe 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 y la soberanía de rollup, así como en su escalabilidad.

Por un lado, el uso de la cadena de bloques Bitcoin como capa de disponibilidad de datos establecerá un límite duro para la escalabilidad de rollup. El espacio de bloque 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 en todos los rollups. Cada actualización de rollup requiere 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 que los datos se compriman 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 elimina el límite máximo de escalabilidad de los beneficios, 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 necesitan extraer no se publican automáticamente en la cadena de bloques, el estado de Rollup no puede 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 al producir un Bloquear en lugar de transmitirlo realmente, 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 usuarios?