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

Fuente: Bitcoin Magazine; Compilación: 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 robado protagonismo a la Red Lightning, en términos de 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 les asigne (o “preste”) fondos con anticipación para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo completo de los pagos desde el remitente hasta el destinatario.

Estos sistemas fueron originalmente implementados en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a cadenas de bloques basadas en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir la situación actual de la implementación en BTC, sino más bien las funcionalidades del Rollup ideal perseguido durante mucho tiempo por la gente, lo cual depende de la capacidad de verificar directamente Prueba de conocimiento cero (ZKP) en BTC, una característica que actualmente no es compatible.

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 las cuentas en Rollup. Todas estas cuentas están autorizadas con una Llave pública/Llave privada, por lo que los usuarios aún deben firmar ciertos contenidos con una Llave secreta para hacer gastos fuera de la cadena. 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 abandonar Rollup unilateralmente sin el 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ía inválida y no se puede incluir en el bloque. Esta prueba permite a las personas verificar si se ha autorizado adecuadamente cualquier cambio en el saldo de la cuenta fuera de la cadena, así como 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 Merkle on-chain, los usuarios pueden verlo y acceder a él, 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 Rollup cambia, 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á 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 los saldos de las cuentas que han ocurrido. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el inicio 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 permite ahorrar una gran cantidad de gastos y espacio de Bloquear (ahorrando así fondos), al 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 se incluyan en el rollup formal proporcionado por la cadena de Bloquear a los usuarios, por lo que las transacciones que no incluyen un resumen de cuenta o diferencias de cuenta se consideran inválidas.

Período de validez

Otra forma de abordar el problema de la disponibilidad de datos para el retiro de usuarios es colocar los datos en otro lugar fuera de la cadena Bloquear. 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 Bloquear se utilizan para este propósito, diseñadas específicamente como capas de disponibilidad de datos para sistemas como rollup.

Esto crea 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 han publicado en otro sistema.

Esto requiere verificar que los datos existen en otras pruebas on-chain, que al final es un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente cualquier cosa que suceda fuera de 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 después de generarse realmente se han transmitido públicamente. No puede verificar si la información externa realmente se ha hecho pública para todos.

Esto abre la puerta a ataques de retención de datos, que consisten en crear compromisos sobre los datos publicados y utilizarlos para impulsar 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 de sistemas de valor y estructuras de incentivos que no sean BTC.

Estar en una posición difícil

Esto ha llevado a rollup a un dilema. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una elección binaria de si publicar los datos en la cadena de bloques de BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad, soberanía y 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 Bloquear es limitado, lo que establece un límite para la cantidad de rollup que puede existir a la vez y la cantidad total de transacciones que todos los rollups pueden procesar off-chain. Cada actualización de rollup requiere espacio de Bloquear 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 aspecto.

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 conlleva 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 extraer 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 mediante la producción de Bloquear en lugar de difundir realmente el Bloquear, 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, logrando verdaderamente retiros unilaterales de usuarios?