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

Fuente: Bitcoin Magazine; Compilado por Wuzhu, Jinse Financial

Rollups has recently become the focus of BTC scalability, becoming the first thing to truly overshadow the Lighting Network and gaining wider attention. Rollups aims to be an off-chain second layer that is not constrained by the Lighting Network’s core liquidity limitations or restrictions. In other words, end-users need someone to allocate (or “lend”) funds in advance in order to receive money, or intermediate routing nodes need channel balances to facilitate the smooth flow of payment amounts from senders to receivers.

Estos sistemas se desarrollaron inicialmente para funcionar en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en trasladarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no pretende discutir el estado actual de implementación en BTC, sino las capacidades ideales de Rollup que la gente ha estado buscando durante mucho tiempo, las cuales dependen de la capacidad de verificar zk-SNARKs directamente en BTC, una función 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 raíz de Merkle de un árbol de Merkle, comprometiendo todos los saldos actuales de cuenta en Rollup. Todas estas cuentas están autorizadas con una Llave pública/Llave privada, por lo que los usuarios todavía deben firmar ciertos contenidos con una Llave secreta para realizar gastos fuera de la cadena. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente demostrando a través de una prueba de transacción que su cuenta es parte del árbol de Merkle, pueden salir de Rollup unilateralmente sin permiso del operador.

Los operadores de Rollup deben incluir una prueba de conocimiento nulo (ZKP) en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta en la cadena on-chain durante el proceso de completar 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 han autorizado adecuadamente todos los cambios en la cuenta fuera de la cadena y si el operador no ha actualizado maliciosamente el saldo para robar los fondos de los usuarios o redistribuirlos de manera deshonesta a otros usuarios.

El problema es que si solo se publica la raíz del árbol de Merkle en la cadena, los usuarios pueden ver y acceder a ella. ¿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 fuera de la cadena y cambia el estado de la cuenta de Rollup, la información se coloca directamente en la cadena. No es todo el árbol, eso sería demasiado absurdo, sino la información necesaria para reconstruir el árbol. En una implementación sencilla, se incluirá un resumen de todas las cuentas existentes en el Rollup que contendrá el saldo y las cuentas sólo se agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Esto es esencialmente un resumen de 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 las cuentas que han ocurrido. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el comienzo 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 salir unilateralmente. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado a los usuarios mediante la cadena Bloquear, 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 de extracción del usuario es colocar los datos en otro lugar fuera de la cadena de bloques. Esto plantea problemas sutiles, ya que rollup aún necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, se han utilizado otras cadenas de bloques para este propósito, diseñadas específicamente como capas 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 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 la prueba SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere que los datos se verifiquen en otras pruebas on-chain, lo que en última instancia es un problema de Máquina de oráculo. La cadena de bloques Bloquear de BTC no puede verificar completamente nada que no suceda dentro 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, incluidos en el Bloquear, se han difundido de manera pública después de su generación. No puede verificar si la información externa se ha hecho realmente pública para todos.

Esto abre las puertas a los ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para impulsar el rollup, pero los datos en realidad no están disponibles. Esto resulta en 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 plantea un dilema para rollup. 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, 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 máximo para la escalabilidad de rollup. El espacio de bloqueo es limitado, lo que establece un límite máximo tanto para la cantidad de rollups que pueden existir a la vez como para el número total de transacciones que pueden ser procesadas fuera de la cadena. Cada actualización de rollup requiere un espacio de bloqueo proporcional al número de cuentas cuyo saldo ha cambiado desde la última actualización. La teoría de la información sólo permite la compresión de datos hasta cierto punto, en este sentido, no hay más potencial de escalabilidad.

Por otro lado, utilizar diferentes capas para lograr la disponibilidad de datos eliminará el límite superior rígido de ganancia de escalabilidad, pero también traerá 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 un Bloquear en lugar de transmitirlo realmente, lo que hace que los datos estén disponibles.

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