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

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

Rollups has recently become the focus of BTC scalability and the first thing to truly steal the spotlight from the Lighting Network, in terms of wider attention. Rollups aims to be an off-chain second layer that is not limited or restricted by the core liquidity of the Lighting Network, meaning that end users need someone to allocate (or ‘lend’) funds in advance in order to receive money, or intermediate nodes need channel balances to facilitate the flow of payment amounts from sender to receiver.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a cadenas de bloques basadas en UTXO (como BTC). Este artículo no tiene la intención de discutir el estado actual de implementación en BTC, sino más bien hablar sobre las características de Rollup idealizadas que se han perseguido durante mucho tiempo, las cuales dependen de la capacidad de verificar directamente Pruebas de Conocimiento Cero (ZKP) en BTC, una funcionalidad que actualmente no es compatible.

La estructura básica de Roll es la siguiente: una sola 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 cuenta en Rollup. Todas estas cuentas están autorizadas con la Llave pública/Llave privada, por lo que para realizar gastos fuera de la cadena, los usuarios todavía deben firmar cierto contenido con la Llave secreta. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente haciendo una prueba de transacción de que su cuenta es parte del árbol de Merkle, pueden salir de Rollup unilateralmente sin el permiso del operador.

Los operadores de Rollup deben incluir un ZKP en la transacción para actualizar la raíz de Merkle del saldo de la cuenta on-chain al completar la transacción off-chain. Si no hay este ZKP, la transacción será inválida y no se puede incluir en la cadena de bloques. Esta prueba permite a la gente verificar si todos los cambios en la cuenta off-chain 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 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 off-chain 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 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. Esencialmente, esto es un resumen de qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup contenga solo cambios en el saldo de las cuentas 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 costos significativos y espacio de bloqueo (lo que ahorra fondos), al tiempo que se 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 por la cadena de bloques a los usuarios, es decir, las transacciones que no contienen un resumen de cuenta o diferencias de cuenta se consideran inválidas.

Fecha de caducidad

Otra forma de abordar el problema de la disponibilidad de los datos de extracción del usuario es almacenar los datos en otro lugar fuera de la cadena de bloques. Esto plantea un problema sutil, ya que el rollup aún debe garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, se han utilizado otras cadenas de bloques con este propósito, diseñadas específicamente como capas de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema en el que la seguridad es igual de fuerte. Cuando los datos se publican directamente en la cadena de bloques de Bitcoin, 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 una prueba on-chain. Esto termina siendo un problema de Máquina de oráculo. La cadena Bloquear de BTC no puede verificar completamente nada más que ocurre fuera de su propia cadena Bloquear, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup de la cadena Bloquear se han transmitido públicamente después de su generación. No puede verificar si la información externa realmente se ha hecho pública para todos.

Esto abrió la puerta a los ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para avanzar en rollup, pero los datos no están realmente disponibles. Esto impide que los usuarios retiren sus 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 llevado a 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 BTC como capa de disponibilidad de datos establece un límite máximo para la escalabilidad de la rollup. El espacio de bloques 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 se pueden procesar fuera de la cadena. Cada actualización de la rollup requiere espacio de bloque proporcional al número 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 sentido.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite superior de escalabilidad de los beneficios, pero también conlleva nuevos problemas de seguridad y soberanía. En Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que el usuario desea 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 la ocultación de datos.

Ahora, cualquier productor de bloques en el sistema de disponibilidad de datos externos puede secuestrar los fondos de los usuarios de BTCRollup produciendo un bloque en lugar de difundirlo realmente, 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 y logramos la retirada unilateral de los usuarios?