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

Fuente: Bitcoin Magazine; Compilación: Wuzhu, Golden Finance

Los rollups se han convertido recientemente en el foco de la escalabilidad de BTC, convirtiéndose en la primera cosa que realmente roba el protagonismo de la Lightning Network, en términos de una atención más amplia. Los rollups tienen como objetivo ser una capa secundaria off-chain que no está sujeta a las restricciones o limitaciones de liquidez centrales de la Lightning Network, es decir, los usuarios finales necesitan que alguien les asigne (o “preste”) fondos con anticipación para poder recibir dinero, o los nodos intermediarios necesitan saldos de canal para facilitar el flujo completo de los pagos 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 su implementación en blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no pretende discutir el estado actual de la implementación en BTC, sino discutir las capacidades idealizadas de Rollup que la gente ha estado persiguiendo a largo plazo, las cuales dependen de capacidades no admitidas actualmente por BTC, es decir, la capacidad de verificar Prueba de conocimiento cero (ZKP) directamente en BTC.

La arquitectura básica de Roll es la siguiente: una sola cuenta (UTXO en BTC) guarda el saldo de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que existe en forma de raíz de Merkle de un árbol de Merkle, comprometiendo todos los saldos actuales de la cuenta existentes en Rollup. Todas estas cuentas están autorizadas con una Llave pública/Llave privada, por lo que para hacer gastos 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 y salir de Rollup simplemente haciendo una transacción que pruebe que su cuenta es parte del árbol de Merkle, lo que les permite salir de Rollup unilateralmente sin el 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 completar las transacciones 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 el saldo para robar fondos de los usuarios o redistribuirlos deshonestamente a otros usuarios.

El problema es que si solo la raíz del árbol de Merkle se publica en la cadena, los usuarios pueden verlo y acceder a él, entonces ¿cómo colocarán sus ramas en el árbol para poder salir cuando lo deseen sin permiso?

Rollup adecuado

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

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Básicamente, esto es un resumen de qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite 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 puede ahorrar una gran cantidad de gastos y espacio de bloqueo (ahorrando así fondos), al 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 a través de la cadena de bloqueo, por lo que las transacciones que no incluyen un resumen de cuenta o diferencias 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 el sutil problema de que rollup aún 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 crea un dilema de seguridad igualmente fuerte. Cuando los datos se publican directamente en la cadena de bloques de Bitcoin, las reglas de consenso pueden garantizar que sea absolutamente correcto. Sin embargo, cuando se publica en sistemas externos, lo mejor que puede hacer es verificar la prueba de SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere una prueba de que los datos existen en otras pruebas de on-chain, lo que finalmente es un problema de Máquina de oráculo. La cadena de Bitcoin no puede verificar completamente nada más que lo que sucede en su propia cadena de bloques, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en el bloque después de ser generados realmente se han transmitido abiertamente. 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 el rollup, pero en realidad los datos 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 plantea un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una elección binaria entre publicar los datos en la cadena de bloques BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad, la soberanía y la escalabilidad de rollup.

Por un lado, utilizar la Cadena de bloques de Bitcoin como capa de disponibilidad de datos establece un límite máximo para la escalabilidad de rollup. El espacio de Bloquear es limitado, lo que establece un límite en la cantidad de rollups que pueden existir a la vez y en la cantidad total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere un espacio de Bloquear proporcional al número de cuentas cuyo saldo ha cambiado desde la última actualización. La teoría de la información sólo permite comprimir los datos hasta cierto punto, en este punto no hay más potencial de escalabilidad.

Por otro lado, el uso de capas diferentes para lograr la disponibilidad de datos eliminará 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 datos que el usuario necesita extraer no se publican 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 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 difundirlo realmente, lo que permite que los datos estén disponibles.

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