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

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

Rollups se ha convertido recientemente en el centro de atención para la expansión de BTC, convirtiéndose en la primera cosa que realmente le ha quitado protagonismo a Lighting Network, en términos de una atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no esté sujeta a las restricciones o limitaciones de liquidez core de Lighting Network, es decir, los usuarios finales necesitan que alguien les asigne (o ‘preste’) fondos con antelación para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo completo de los pagos desde el remitente hasta el receptor.

Estos sistemas se desarrollaron originalmente 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 tiene la intención de discutir el estado actual de implementación en BTC, sino de discutir las capacidades ideales de Rollup que han sido perseguidas durante mucho tiempo, las cuales dependen de capacidades que actualmente no son compatibles con BTC, es decir, la capacidad de verificar Pruebas de Conocimiento Cero (ZKP) directamente en 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 árbol de Merkle, comprometiéndose así a 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 cierto contenido 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 transacción que demuestre que su cuenta es parte del árbol de Merkle, lo que les permite salir de Rollup de manera unilateral sin la necesidad de permiso del operador.

El operador de Rollup debe incluir una prueba de conocimiento-cero (ZKP) en la transacción para actualizar la raíz Merkle del saldo de la cuenta en la cadena de bloques al completar la transacción fuera de la cadena (off-chain). Sin esta 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 fuera de la cadena han sido autorizados adecuadamente por el titular de la cuenta y si el operador no ha actualizado maliciosamente el saldo para robar los 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 pueden colocar sus ramas en el árbol para poder salir cuando lo deseen sin permiso?

Rollup adecuado

En un Rollup adecuado, cada vez que se confirma una nueva transacción off-chain y el estado de la cuenta 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 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. Básicamente, 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 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í fondos), al tiempo que permite a los usuarios garantizar 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 mediante 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 otros lugares fuera de la cadena Bloquear. Esto introduce problemas sutiles, ya que rollup aún debe asegurarse de que los datos estén disponibles en otros lugares. 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 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 sistemas externos, lo mejor que pueden hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere verificar la existencia de datos en otras pruebas en cadena, lo que al final es un problema de Máquina de oráculo. La cadena Bloquear de BTC no puede verificar completamente nada que suceda 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 en la cadena Bloquear se publicaron realmente después de generarse. No puede verificar si la información externa realmente se hace pública para todos.

Esta ataque de retención de datos ha abierto la puerta, 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 retirar sus fondos. La única solución real es depender completamente del valor y la estructura de incentivos de sistemas fuera de BTC.

Entre la espada y la pared

Esto plantea un dilema para rollup. 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 de BTC o en otro lugar. Esta elección tiene un impacto significativo 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 duro para la escalabilidad de rollup. El espacio de bloquear es limitado, lo que establece un límite para la cantidad de rollup que puede existir a la vez y el número total de transacciones que pueden ser procesadas off-chain en todos los rollup. Cada actualización de rollup requiere bloquear espacio 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 superior rígido de la escalabilidad, pero también traerá nuevos problemas de seguridad y soberanía. En Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que el 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 defenderse del engaño 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 un Bloquear en lugar de difundirlo realmente, para hacer que los datos estén disponibles.

Entonces, si realmente logramos implementar una implementación ideal de Rollup en BTC, que permita a los usuarios retirar unilateralmente, ¿cómo sería eso?