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 atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no está restringida o limitada por la liquidez central de Lighting Network, es decir, los usuarios finales necesitan que alguien les asigne (o ‘preste’) fondos con anticipación para recibir dinero, o los nodos intermedios necesitan equilibrio de canal para facilitar el flujo completo de los pagos desde el remitente hasta el destinatario.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en la portabilidad a cadenas de bloques basadas en UTXO, como BTC. Este artículo no pretende discutir el estado actual de implementación en BTC, sino las características de los Rollups idealizados a largo plazo, que dependen de la capacidad de verificar directamente Prueba de conocimiento cero (ZKP) en BTC, una característica que BTC no admite actualmente.

La estructura básica de Roll es la siguiente: una única cuenta (llamada UTXO en BTC) que almacena el saldo de todos los usuarios en Rollup. Este UTXO contiene un compromiso que existe en forma de raíz de Merkle del árbol Merkle, comprometiendo todos los saldos actuales de cuenta en Rollup. Todos estos cuentas se autorizan con la llave pública/llave privada, por lo que para realizar gastos fuera de la cadena, los usuarios aún deben firmar cierto contenido con la llave secreta. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente demostrando con una transacción que su cuenta es parte del árbol Merkle, pueden salir unilateralmente de Rollup sin necesidad de permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar el saldo de la cuenta on-chain durante el proceso de transacción off-chain. Sin este ZKP, la transacción será inválida y no se puede incluir 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 maliciosamente los saldos para robar fondos de los usuarios o redistribuirlos de manera deshonesta a otros usuarios.

La pregunta es, si solo se publica la raíz del árbol de Merkle en la cadena, y los usuarios pueden ver y acceder a ella, ¿cómo colocarán sus ramas en el árbol para poder salir sin permiso cuando lo deseen?

Rollup adecuado

En un Rollup adecuado, cada vez que se confirma una nueva transacción fuera de la cadena y el estado de la cuenta del Rollup cambia, la información se coloca directamente en la cadena de bloques. No es todo el árbol, eso sería absurdo, sino la información necesaria para reconstruir el árbol. En una implementación sencilla, el resumen de todas las cuentas existentes en el Rollup contendrá el saldo y las cuentas solo se agregan en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, utiliza 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 asegurar el acceso a la información necesaria para una salida unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado a los usuarios a través de la cadena de Bloquear, por lo que las transacciones que no incluyan 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. Esto plantea un problema sutil, dado que rollup aún debe garantizar la disponibilidad de datos en otro lugar. Tradicionalmente, otras cadenas se utilizan con este propósito, específicamente diseñadas como capas de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema de seguridad igualmente poderoso. Cuando los datos se publican directamente en la cadena de bloques de BTC, 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 validen en pruebas en cadena que existen en otras pruebas en cadena. Esto es en última instancia un problema de Máquina de oráculo. La cadena Bloquear de BTC no puede validar completamente nada que ocurra fuera de su propio Bloquear en cadena, lo mejor que puede hacer es validar ZKP. Sin embargo, ZKP no puede validar si los datos de rollup en el Bloquear se difunden realmente al público después de la generación. No puede validar si la información externa se hace realmente pública para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, crear compromisos para los datos publicados y utilizarlos para avanzar en 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.

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 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, el uso de la cadena de bloques BTC como capa de disponibilidad de datos establecerá un límite estricto en la escalabilidad de rollup. El espacio de bloque es limitado, lo que establece un límite en la cantidad de rollups que pueden existir a la vez y la cantidad total de transacciones que se pueden procesar 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 que los datos se compriman hasta cierto punto, por lo que no hay más potencial de escalabilidad en este sentido.

Por otro lado, el uso de capas diferentes para lograr la disponibilidad de datos elimina el límite superior fijo de escalabilidad, pero también plantea nuevos problemas de seguridad y soberanía. En 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 de 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 Bloquear en lugar de difundir el Bloquear real, lo que permite que los datos estén disponibles.

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