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

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

Rollups se ha convertido recientemente en el foco de atención para la expansión de BTC, convirtiéndose en la primera cosa que realmente ha tomado el centro de atención de Lighting Network, en términos de una atención más amplia. Rollups tiene como objetivo convertirse en una segunda capa off-chain que no está limitada o restringida por la liquidez del núcleo de Lighting Network, es decir, que el usuario final necesita que alguien asigne (o ‘preste’) fondos con anticipación para poder recibir el dinero, o el Nodo de enrutamiento intermediario necesita un saldo de canal para facilitar el flujo completo del monto de pago desde el remitente hasta el receptor.

Estos sistemas fueron originalmente implementados en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO, como BTC. Este artículo no pretende discutir el estado actual de implementación en BTC, sino más bien las funcionalidades ideales que se persiguen a largo plazo en Rollups, que dependen de capacidades que BTC no admite actualmente, es decir, la capacidad de verificar directamente Prueba de conocimiento cero (ZKP) en BTC.

La estructura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) que almacena 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 para realizar gastos fuera de la cadena, los usuarios aún deben firmar ciertos contenidos con una 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 forma parte del árbol de Merkle, y pueden salir de Rollup de manera unilateral sin necesidad de 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 transacciones fuera de la cadena. Sin este ZKP, la transacción será inválida y no puede incluirse en la cadena de bloques. 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 maliciosamente el saldo para robar 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 en la cadena, los usuarios pueden verla y acceder a ella, entonces ¿cómo colocan sus ramas en el árbol para poder salir en el momento que deseen sin permiso?

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á 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. 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 solo incluya los cambios de saldo de cuenta que ocurrieron. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el inicio de 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í dinero), al tiempo que permite a los usuarios garantizar el acceso a la información necesaria para la 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 diferencias de cuenta se consideran inválidas.

Periodo de validez

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 de bloques. Esto plantea sutiles problemas, ya que rollup todavía necesita asegurar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de bloques se utilizan para este propósito, diseñadas específicamente para servir como capa 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 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 una prueba de SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere una prueba de que los datos existen en otra prueba on-chain, 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 se han 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 ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para impulsar 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 un dilema

Esto ha puesto a rollup en un dilema. Cuando se trata de problemas de disponibilidad de datos, básicamente hay 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, soberanía y escalabilidad de rollup.

Por un lado, el uso de la cadena de bloques Bitcoin 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 todos los rollups pueden manejar fuera de la cadena. Cada actualización de rollup requiere un 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 elimina el límite máximo de escalabilidad de los beneficios, pero también plantea nuevos problemas de seguridad y soberanía. En el Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que un 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 por completo de la capacidad de los sistemas externos utilizados para resistir el engaño 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 difundir el Bloquear real, lo que hace que los datos estén disponibles.

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