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

Fuente: Bitcoin Magazine; Compilación: Wuzhu, Golden Finance

Rollups recientemente se ha convertido en el foco de la escalabilidad de BTC, convirtiéndose en la primera cosa que realmente roba el protagonismo de la Lighting Network, en términos de una atención más amplia. Rollups tiene como objetivo ser una capa secundaria off-chain que no está limitada o restringida por la liquidez central de Lighting Network, es decir, los usuarios finales necesitan que alguien asigne (o ‘preste’) fondos con anticipación para recibir dinero, o los nodos intermedios necesitan tener saldos de canal para facilitar el flujo completo de los pagos desde el remitente hasta el destinatario.

Estos sistemas fueron originalmente desarrollados para funcionar en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a blockchains basados en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir el estado actual de implementación en BTC, sino más bien las características idealizadas de Rollup que se han perseguido durante mucho tiempo, las cuales dependen de la capacidad de verificar directamente las pruebas de conocimiento cero (ZKP) en BTC, lo cual no es compatible en la actualidad.

La arquitectura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) almacena los saldos 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 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 haciendo una transacción que demuestre que su cuenta es parte del árbol de Merkle, pueden salir unilateralmente de Rollup sin permiso del operador.

Los operadores de Rollup deben incluir una ZKP en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta on-chain durante el proceso de completar las transacciones off-chain. 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 off-chain están debidamente 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 de Merkle en la cadena, los usuarios pueden verlo y acceder a él, pero ¿cómo colocan sus ramas en el árbol para poder retirarse sin permiso cuando lo deseen?

Rollup adecuado

En el Rollup adecuado, cada vez que se confirma una nueva transacción fuera de la cadena y cambia el estado de la cuenta Rollup, la información se coloca directamente en la cadena de bloques. No es todo el árbol, eso sería demasiado absurdo, sino la información necesaria para reconstruir el árbol. En una implementación sencilla, el resumen de todas las cuentas existentes en Rollup contendrá el saldo y la cuenta solo se agregará en las transacciones de actualización de Rollup.

En implementaciones más avanzadas, utiliza diferencias de saldo. Básicamente, esto resume qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto hace que cada actualización de Rollup solo contenga 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.

Esto permitiría ahorrar costos significativos y espacio de Bloquear (ahorrando así dinero), al mismo tiempo que permite a los usuarios garantizar el acceso a la información necesaria para una salida unilateral. Las reglas de rollup requieren que estos datos estén incluidos en el rollup oficial proporcionado por la cadena de Bloquear al usuario, es decir, las transacciones que no incluyan un resumen de cuenta o una diferencia de cuenta se considerarán transacciones inválidas.

Período de validez

Otra forma de abordar el problema de la disponibilidad de datos de extracción de usuarios es almacenar los datos en algún lugar fuera de la cadena Bloquear. Esto plantea problemas sutiles, ya que rollup todavía debe 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 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 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 se puede hacer es verificar la prueba SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere la verificación de que los datos existen en pruebas on-chain de otros, lo 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 no ocurra en su propia cadena de bloques, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en el bloque realmente se transmitieron públicamente después de ser generados. No puede verificar si la información externa realmente se hace pública para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, crear compromisos para publicar datos y utilizarlos para avanzar en rollup, pero los datos en realidad no están disponibles. Esto impide que los usuarios retiren fondos. La única solución real es depender completamente del valor y la estructura de incentivos fuera de BTC.

Entre la espada y la pared

Esto ha puesto a rollup en un dilema. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una elección binaria entre publicar los 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, el uso de la cadena de bloques BTC como capa de disponibilidad de datos establecerá un límite duro para la escalabilidad de rollup. El espacio de bloques 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. 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 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 plantea nuevos problemas de seguridad y soberanía. En un 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 efectivamente el Bloquear.

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