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 expansión de BTC, convirtiéndose en la primera cosa que realmente ha robado el protagonismo de la Red de Lighting Network, en términos de una atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no esté sujeta a las restricciones de liquidez centrales de Lighting Network, es decir, los usuarios finales necesitan que alguien asigne (o “preste”) fondos por adelantado para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo total del monto de 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 portarlos a cadenas de bloques basadas en UTXO (por ejemplo, Bitcoin). Este artículo no pretende discutir el estado actual de implementación en BTC, sino discutir las características del idealizado Rollup que se ha buscado durante mucho tiempo, lo que depende de la capacidad de BTC para verificar directamente la prueba de conocimiento cero (ZKP), que actualmente no es compatible con BTC.

La estructura 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 la raíz de Merkle del árbol de Merkle, comprometiendo todos los saldos actuales de las cuentas en Rollup. Todas estas cuentas están autorizadas con Llave pública/ Llave privada, por lo que para realizar gastos off-chain, 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 de Merkle, 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 la cadena de bloques al completar las transacciones fuera de la cadena. Sin 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 han sido autorizados adecuadamente 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 la raíz del árbol de Merkle se publica on-chain, los usuarios pueden ver y acceder a ella, entonces ¿como pueden colocar 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 el estado de la cuenta Rollup cambia, 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 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 saldo. Básicamente, esto es 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 solo contenga cambios en el saldo de cuentas que hayan ocurrido. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el principio del Rollup para obtener el estado actual del saldo de cuentas, lo que les permite reconstruir el árbol de Merkle del saldo actual.

De esta manera, se puede ahorrar una gran cantidad de gastos y espacio en Bloquear (lo que ahorra dinero), al mismo tiempo que permite a los usuarios asegurarse de acceder 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 por la cadena Bloquear, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Período de validez

Otra forma de abordar el problema de la disponibilidad de datos de extracción de usuarios es colocar los datos en otro lugar fuera de la cadena de bloques. Esto plantea un problema sutil, ya que rollup aún necesita asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de bloques se utilizan con este propósito, diseñadas específicamente como una capa 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 Bloquear Bitcoin, las reglas de Consenso pueden garantizar que son 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 on-chain, lo que es en última instancia un problema de Máquina de oráculo. La cadena de bloques de Bitcoin no puede verificar completamente cualquier cosa que ocurra fuera de su propio bloque on-chain, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup que contiene el bloque se transmitieron públicamente después de que se generó. No puede verificar si la información externa realmente se hizo pública para todos.

Este ataque de retención de datos ha abierto la puerta, es decir, crear compromisos para publicar datos y utilizarlos 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 los sistemas que no sean BTC.

Entre la espada y la pared

Esto presenta un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente hay una opción binaria de publicar los 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, usar la cadena de bloques de 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 todos los rollups pueden manejar fuera de la cadena. 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 eliminará el límite duro de ganancia de escalabilidad, pero también conllevará nuevos problemas de seguridad y soberanía. En el Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que el usuario necesita 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 ocultar 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 difundirlo realmente, permitiendo así 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?