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 llamado la atención lejos de la Red de Iluminación, en términos de una atención más amplia. Rollups tiene como objetivo ser una capa fuera de la cadena (off-chain) de segunda capa que no está sujeta a las restricciones de liquidez del núcleo de la Red de Iluminación, es decir, los usuarios finales necesitan que alguien asigne (o ‘preste’) los fondos de antemano para recibir dinero, o los nodos de enrutamiento necesitan tener un saldo de canal para facilitar el flujo completo de los pagos desde el remitente hasta el receptor.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir la implementación actual en BTC, sino más bien las características de un enfoque de Rollup ideal que ha sido buscado a largo plazo, lo cual depende de la capacidad de verificar directamente Prueba de conocimiento cero (ZKP) en BTC, una funcionalidad que no es compatible actualmente.

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

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta en la cadena de bloques, durante el proceso de completar las transacciones fuera de la cadena. Sin este ZKP, la transacción sería inválida y no podría ser incluida en la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en el saldo de la cuenta fuera de la cadena han sido autorizados adecuadamente por el titular de la cuenta y si el operador no está actualizando el saldo de manera malintencionada 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, ¿cómo colocan 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 utiliza la diferencia de saldo. Esto esencialmente resume 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 ocurrieron. Luego, los usuarios pueden escanear simplemente 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 bloqueo (y, por lo tanto, ahorrar dinero), al tiempo que permite a los usuarios asegurarse de tener acceso a la información necesaria para salir de forma unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado por la cadena de bloques, sin incluir el resumen de cuenta o las transacciones de cuenta diferencial se consideran transacciones inválidas.

Periodo de validez

Otra forma de abordar el problema de la disponibilidad de datos de extracción de usuarios es almacenar los datos en otro lugar fuera de la cadena de bloques. Esto plantea un problema sutil, ya que rollup aún necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de bloques se han utilizado con este propósito, diseñadas específicamente como capas de disponibilidad de datos para sistemas como rollup.

Esto crea un dilema de seguridad igualmente desafiante. 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 un sistema externo, lo mejor que se puede hacer es verificar la prueba SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere verificar que los datos existan en otras pruebas on-chain, lo que al final es un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada que suceda fuera de 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 la cadena de bloques generada realmente se divulgan públicamente. No puede verificar si la información externa realmente se hace pública para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para avanzar en rollup, pero en realidad los datos no están disponibles. Esto resulta en que los usuarios no pueden retirar fondos. La única solución real es depender completamente del valor y la estructura de incentivos de sistemas fuera de BTC.

Atrapado en una encrucijada

Esto plantea un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una dicotomía entre publicar los datos en la cadena de bloques de BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad, la soberanía y la escalabilidad del 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 en la cadena de bloques es limitado, lo que establece un límite para 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 en la cadena de bloques proporcional al número 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.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite duro de escalabilidad de las ganancias, 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 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 efectivamente ese Bloquear, lo que permite que los datos estén disponibles.

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