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 escalabilidad de BTC, convirtiéndose en la primera cosa que realmente ha robado 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 de liquidez del núcleo de Lighting Network, es decir, los usuarios finales necesitan que alguien asigne (o “preste”) fondos con anticipació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 destinatario.

Estos sistemas se desarrollaron inicialmente para ser ejecutados 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 que trata sobre las funcionalidades ideales de Rollup que la gente ha estado buscando a largo plazo, las cuales dependen de la capacidad actualmente no compatible con BTC de verificar 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. Este 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 off-chain, 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, solo presentando pruebas de transacciones que su cuenta es parte del árbol de Merkle, pueden salir unilateralmente de Rollup sin necesidad de permiso del operador.

Los operadores de Rollup deben incluir una prueba de conocimiento cero (ZKP) en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta en la cadena en el proceso de completar transacciones fuera de la cadena. 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 están debidamente autorizados por el titular de la cuenta y si el operador no actualiza 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 verlo y acceder a él, ¿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 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á el saldo, y las cuentas solo se agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utilizan desviaciones de saldo. Este es esencialmente un resumen de qué CUENTA han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup incluya solo los cambios de saldo de cuenta que se producen. A continuación, los usuarios pueden simplemente escanear la cadena y “calcular” desde el principio del Rollup para llegar al 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 mismo tiempo que permite a los usuarios garantizar el acceso a la información necesaria para la 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, es decir, las transacciones que no contienen 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 introduce problemas sutiles, 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 para servir como capa de disponibilidad de datos para sistemas como rollup.

Esto crea un dilema de seguridad igualmente poderoso. Cuando los datos se publican directamente en la cadena de bloques de Bitcoin, 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 que los datos existen en otras pruebas on-chain, que en última instancia 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 han publicado realmente después de generarse. No puede verificar si la información externa realmente se hace pública para todos.

Este ataque de retención de datos ha abierto la puerta, es decir, crear compromisos con los datos publicados y utilizarlos para impulsar el rollup, pero los datos no están realmente 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 que no dependan del 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 entre publicar 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 rollup. El espacio de bloqueo es limitado, lo que establece un límite para la cantidad de rollups que pueden existir y la cantidad total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere espacio de bloqueo 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, y en este sentido, no hay más potencial de escalabilidad.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite duro de ganancias de escalabilidad, pero también traerá 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 Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado para resistir el engaño 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 un Bloquear en lugar de difundir realmente ese Bloquear, para hacer que los datos estén disponibles.

Entonces, ¿cómo sería si realmente logramos una implementación ideal de Rollup en BTC y logramos el retiro unilateral de los usuarios?