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

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

Rollups recientemente se ha convertido en el foco de la expansión de BTC, siendo la primera cosa que realmente ha eclipsado 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á sujeta a las restricciones de liquidez centrales de la Red Lightning, es decir, los usuarios finales necesitan asignar (o ‘prestar’) fondos con anticipación para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo de pago desde el remitente hasta el destinatario.

Estos sistemas originalmente se ejecutaban en Ethereum y otros sistemas Turing completo, pero recientemente el enfoque se ha trasladado a portarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no pretende discutir el estado actual de implementación en BTC, sino más bien discutir las funcionalidades de Rollup idealizadas perseguidas a largo plazo por las personas, que dependen de la capacidad actualmente no admitida en BTC de verificar Prueba de conocimiento cero (ZKP) directamente en BTC.

La arquitectura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) que guarda los saldos de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que existe en forma de raíz Merkle del árbol Merkle, comprometiendo todos los saldos actuales de las cuentas en Rollup. Todas estas cuentas están autorizadas con Llave pública/ Llave privada, por lo que los usuarios aún deben firmar ciertos contenidos con 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 haciendo una prueba de transacción de que su cuenta es parte del árbol Merkle, pueden salir de Rollup unilateralmente sin permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar el saldo de la cuenta on-chain en el proceso de completar transacciones off-chain. Sin este ZKP, la transacción sería inválida y no se incluiría en el bloque. Esta prueba permite a las personas 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 el saldo de manera maliciosa 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 ver y acceder a ella, 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 cambia el estado de Rollupcuenta, 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, use diferencias de saldo. En esencia, 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 simplemente escanear 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 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 salir unilateralmente. 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.

Fecha de caducidad

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 Bloquear. Esto plantea sutiles problemas, ya que rollup aún debe garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se han utilizado 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 importante. Cuando los datos se publican directamente en la cadena de bloques de Bitcoin, las reglas de consenso garantizan que son absolutamente correctos. Sin embargo, cuando se publican en sistemas externos, lo mejor que se puede hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere la validación de que los datos existen en una prueba de existencia en cadena, lo que finalmente es un problema de Máquina de oráculo. La cadena de Bitcoin no puede verificar completamente cualquier cosa que no ocurra en su propia cadena, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en la cadena de bloques realmente se han difundido 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 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 del valor y la estructura de incentivos de sistemas fuera de BTC.

En un dilema

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 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 estricto a la escalabilidad de rollup. El espacio de bloques es limitado, lo que establece un límite en la cantidad de rollups que pueden existir al mismo tiempo y en la cantidad total de transacciones que pueden ser procesadas fuera de la cadena. 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.

Por otro lado, utilizar 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 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 Validium, esta garantía depende completamente de la capacidad de los sistemas externos utilizados para resistir el engaño y la ocultación de 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 el Bloquear real, lo que hace que los datos estén disponibles.

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