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

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

Rollups se ha convertido recientemente en el foco de la expansión de BTC, convirtiéndose en la primera cosa que realmente ha robado el protagonismo de Lighting Network, en términos de una mayor atención. Rollups tiene como objetivo ser una capa secundaria off-chain no restringida por las limitaciones de Liquidez del núcleo de Lighting Network, es decir, los usuarios finales necesitan que se les asigne (o ‘presten’) fondos con anticipación para recibir dinero, o los nodos de enrutamiento 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 completos, pero últimamente se ha centrado en portarlos a blockchains basadas en UTXO, como BTC. Este artículo no pretende discutir la implementación actual en BTC, sino más bien las capacidades ideales de un rollup, que dependen de la capacidad de verificar directamente Pruebas de Conocimiento Cero (ZKP), una función que BTC no admite actualmente.

La arquitectura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) almacena los saldos de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que representa todos los saldos actuales de las cuentas existentes en Rollup en forma de raíz de Merkle de un árbol de Merkle. Todas estas cuentas están autorizadas con llaves públicas/privadas, por lo que para gastar 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, solo presentando una prueba de transacción de que su cuenta forma parte del árbol de Merkle, y pueden salir unilateralmente de Rollup sin el permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar la raíz merkle del saldo de la cuenta on-chain durante el proceso de completar transacciones off-chain. Sin este ZKP, la transacción será inválida y no se puede incluir en la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en la cuenta off-chain han sido debidamente autorizados por el titular de la cuenta, y si el operador no actualiza los saldos de forma 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 verlo y acceder a él, 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, utiliza la diferencia 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 contenga solo cambios en el saldo de la cuenta que han ocurrido. Luego, los usuarios pueden 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 puede 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 a los usuarios mediante la cadena de Bloquear, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Período 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 Bloquear. Esto plantea sutiles problemas, ya que rollup todavía debe 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 ha creado un dilema en el que la seguridad es igualmente fuerte. Cuando los datos se publican directamente en la cadena BTC Bloquear, 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 han publicado en otro sistema.

Esto requiere validar la existencia de datos en otras pruebas on-chain, lo que al final es un problema de Máquina de oráculo. La cadena Bloquear de BTC no puede verificar completamente nada más que lo que sucede on-chain, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en la cadena Bloquear se han publicado abiertamente después de su generación. No puede verificar si la información externa se ha publicado realmente 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 distintos a BTC.

En un dilema

Esto ha llevado a un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente hay una elección binaria entre publicar 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, utilizar la cadena de bloques BTC como capa de disponibilidad de datos establecerá un límite máximo duro para la escalabilidad de rollup. El espacio de bloque 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 pueden ser procesadas off-chain por todos los rollup. Cada actualización de rollup necesita 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 eliminará el límite rígido de ganancias de escalabilidad, pero también traerá nuevos problemas de seguridad y soberanía. En el 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 de los sistemas externos utilizados para resistir el fraude y el ocultamiento 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 difundir realmente ese Bloquear, lo que hace que los datos estén disponibles.

Entonces, si realmente logramos implementar Rollup ideal en BTC, logrando la retirada unilateral real de los usuarios, ¿cómo sería eso?