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

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

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

Estos sistemas originalmente se ejecutaban en Ethereum y otros sistemas Turing completo, pero recientemente el enfoque se ha trasladado a portarlos 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 discutir las capacidades de Rollup idealizadas que la gente ha estado persiguiendo durante mucho tiempo, que dependen de capacidades que actualmente no son compatibles con BTC, es decir, la capacidad de verificar Prueba de conocimiento cero (ZKP) directamente en BTC.

La arquitectura básica de Roll es la siguiente: una sola cuenta (UTXO en BTC) guarda los saldos de todos los usuarios en Rollup. Esta UTXO contiene un compromiso en forma de raíz de Merkle del árbol de Merkle, comprometiendo todos los saldos actuales de cuenta existentes en Rollup. Todas estas cuentas están autorizadas mediante llaves públicas/privadas, por lo que para realizar gastos fuera de la cadena, los usuarios aún deben firmar algo con la llave secreta. Esta parte de la estructura permite que los usuarios salgan en cualquier momento sin permiso, simplemente haciendo una transacción que pruebe que su cuenta es parte del árbol de Merkle, y pueden salir de Rollup unilateralmente sin 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, durante el proceso de completar las transacciones fuera de la cadena. Sin este ZKP, la transacción será inválida y no podrá ser incluida en el bloque. Esta prueba permite a las personas verificar si todos los cambios en el saldo de la cuenta fuera de la cadena han sido autorizados adecuadamente por el titular de la cuenta, y si el operador no ha actualizado deshonestamente 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 podrían verlo y acceder a él, pero ¿cmo colocarían sus ramas en el árbol para poder salir cuando lo deseen sin necesidad de permiso?

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 el árbol completo, eso sería absurdo, sino la información necesaria para reconstruir el árbol. En una implementación sencilla, el resumen de todas las cuentas existentes en el Rollup contendrá los 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 saldos. 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 contenga solo los 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.

De esta manera se pueden ahorrar costos significativos y espacio de bloquear (lo que ahorra dinero), 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 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 transacciones 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 Bloquear. Esto introduce un problema sutil, rollup aún necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas Bloquear se utilizan para este propósito, diseñadas específicamente como capas de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema de seguridad igualmente fuerte. 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 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 verificación de que los datos existen en otras pruebas en cadena, que es en última instancia un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada que suceda fuera de su propia cadena de bloques, excepto a través de verificación de conocimiento cero (ZKP). Sin embargo, ZKP no puede verificar si los datos de rollup en un bloque realmente se han difundido públicamente después de su generación. No puede verificar si la información externa realmente está disponible para todos.

Esto abrió la puerta a los ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para avanzar en el rollup, pero los datos no están realmente disponibles. Esto hace que los usuarios no puedan extraer fondos. La única solución real es depender completamente del valor y la estructura de incentivos de sistemas que no sean BTC.

En la encrucijada

Esto plantea 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, soberanía y escalabilidad de rollup.

Por un lado, utilizar la cadena de bloques BTC como capa de disponibilidad de datos establecerá un límite máximo en la escalabilidad de rollup. El espacio de bloqueo 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 pueden ser procesadas fuera de la cadena. Cada actualización de rollup requiere espacio de bloqueo 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, y en este punto ya no hay más potencial de expansión.

Por otro lado, el uso de capas diferentes para lograr la disponibilidad de datos eliminará el límite máximo de escalabilidad de las ganancias, 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 Bloques en el sistema de disponibilidad de datos externos puede secuestrar los fondos de los usuarios de BTCRollup al producir un Bloqueo 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 realmente retiros unilaterales de los usuarios?