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 a la Red de Rayos, en términos de una atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no esté restringida o limitada por la liquidez central de la Red de Rayos, es decir, los usuarios finales necesitan que alguien les asigne (o “preste”) fondos con anticipación para poder recibir dinero, o los nodos intermedios necesitan saldo en los canales para facilitar el flujo completo de los pagos desde el remitente hasta el destinatario.

Estos sistemas se desarrollaron inicialmente para funcionar en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir el estado actual de la implementación en BTC, sino que se centra en las capacidades ideales de Rollup que la gente ha estado persiguiendo durante mucho tiempo, lo que depende de la capacidad actualmente no admitida en BTC para verificar directamente conocimiento cero (ZKP) en BTC.

La estructura básica de Roll es la siguiente: una sola 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 de Merkle, comprometiendo todos los saldos actuales de cuenta en Rollup. Todas estas cuentas están autorizadas con la llave pública/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 transacción que su cuenta es parte del árbol de Merkle, pueden salir unilateralmente de Rollup sin permiso del operador.

Los operadores de Rollup deben incluir un ZKP en la transacción para actualizar la raíz de Merkle del saldo en la cuenta en la cadena de bloques durante el proceso de transacción fuera de la cadena. Si no hay un ZKP, la transacción será inválida y no se puede incluir en un 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 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 pueden verlo y acceder a él, ¿cómo pueden colocar 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 cambia el estado de la cuenta 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á el saldo, 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 contenga solo los cambios en el saldo de la cuenta que han ocurrido. Luego, los usuarios pueden escanear simplemente 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 grandes gastos y espacio de Bloquear (y por lo tanto ahorrar dinero), al tiempo que se permite a los usuarios asegurar el acceso a la información necesaria para una salida 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 para la extracción de usuarios es colocar los datos en otro lugar fuera de la cadena Bloquear. Esto plantea un problema sutil, ya que rollup todavía necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas Bloquear se utilizan con este propósito, diseñadas específicamente para servir como capa 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 BTC, las reglas de consenso pueden garantizar que sea absolutamente correcto. Sin embargo, cuando se publica en un sistema externo, lo mejor que puede 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 pruebas en cadena externas, lo que es en última instancia un problema de Máquina de oráculo. La cadena de bloques de BTC no puede validar completamente nada que no ocurra en su propia cadena de bloques, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si un bloque que contiene datos de rollup realmente se ha difundido públicamente después de la generación. No puede verificar si la información externa realmente está disponible para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, la creación de compromisos para publicar datos y utilizarlos para avanzar en 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 distintos a BTC.

En una situación difícil

Esto plantea un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente hay una elección binaria entre publicar datos en la cadena de bloques de BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad y soberanía de rollup, así como en su escalabilidad.

Por un lado, el uso de la cadena de bloques BTC como capa de disponibilidad de datos establecerá un límite máximo para la escalabilidad de rollup. El espacio en la cadena de bloques es limitado, lo que establece un límite para la cantidad de rollups que pueden existir al mismo tiempo y la cantidad total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere espacio en la cadena de bloques 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 expansión en este sentido.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite máximo de escalabilidad de los beneficios, 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 han publicado 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 al producir Bloquear en lugar de transmitir el Bloquear real, lo que hace que los datos estén disponibles.

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