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

Fuente: Bitcoin Magazine; Compilado por Wu Zhu, Golden Finance

Rollups ha sido el foco de atención para la escalabilidad de BTC recientemente, convirtiéndose en la primera verdadera competencia para la Lighting Network y generando un mayor interés. Los Rollups tienen como objetivo ser una capa off-chain de segunda capa que no está limitada por las restricciones de liquidez del núcleo de la Lighting Network, lo que significa que los usuarios finales necesitan que alguien les asigne (o ‘preste’) fondos de antemano para poder recibir dinero, o que los nodos de enrutamiento necesitan tener 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 desplazado a su portabilidad a blockchains basados en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir el estado actual de implementación en BTC, sino más bien las características idealizadas de Rollup que la gente ha estado persiguiendo a largo plazo, las cuales dependen de la capacidad actualmente no admitida en BTC para verificar directamente pruebas de conocimiento cero (ZKP).

La arquitectura básica de Roll es la siguiente: una única cuenta (denominada 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 Merkle del árbol de Merkle, comprometiendo todos los saldos actuales de las cuentas en Rollup. Todas estas cuentas están autorizadas con una llave pública / llave privada, por lo que los usuarios aún deben firmar cierto contenido con una 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 forma 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 transacción off-chain. Sin este ZKP, la transacción será inválida y no se incluirá en la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en la cuenta off-chain han sido debidamente autorizados por el titular de la cuenta, y si el operador no ha actualizado el saldo de forma maliciosa 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 ver y acceder a ella, pero ¿cómo colocan sus ramas en el árbol para poder salir en cualquier momento sin permiso?

Rollup apropiado

En un Rollup adecuado, cada vez que se confirma una nueva transacción fuera de cadena y el estado de la cuenta Rollup cambia, la información se inserta 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, los resúmenes de todas las cuentas existentes en el Rollup contendrán 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. Esto esencialmente 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 los cambios de saldo de cuenta que han ocurrido. Luego, los usuarios pueden escanear simplemente la cadena y ‘calcular’ desde el principio de Rollup para obtener el estado actual del saldo de la cuenta, lo que les permite reconstruir el árbol de Merkle del saldo actual.

De esta manera, se puede ahorrar una gran cantidad de gastos y espacio de Bloquear (ahorrando así fondos), al mismo tiempo que se permite a los usuarios garantizar el acceso a la información necesaria para salir unilateralmente. Las reglas de rollup requieren que estos datos se incluyan en el rollup oficial proporcionado a los usuarios utilizando la cadena de Bloquear, y las transacciones que no incluyen un resumen de la 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 que no sea la cadena Bloquear. Esto introduce un problema sutil, ya que rollup todavía necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas Bloquear se utilizan con este fin, diseñadas específicamente para servir como capa 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 de SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere validar que los datos existan en otras pruebas on-chain, lo que finalmente es un problema de Máquina de oráculo. La cadena Bloquear de BTC no puede verificar completamente nada que no ocurra on-chain, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en el Bloquear se publican realmente después de generarse. No puede verificar si la información externa realmente se hace pública para todos.

Esta apertura de puerta de ataques de retención de datos implica crear compromisos para publicar datos y utilizarlos para avanzar en el rollup, pero en realidad los datos no están disponibles. Esto hace que los usuarios no puedan retirar los fondos. La única solución real es depender completamente del valor y la estructura de incentivos fuera de BTC.

Dilema

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 gran impacto en la seguridad, la soberanía y la escalabilidad de Rollup.

Por un lado, utilizar la cadena de bloques BTC como capa de disponibilidad de datos establece un límite duro para la escalabilidad de rollup. El espacio de bloque 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 todos los rollups 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 diferentes capas para lograr la disponibilidad de datos eliminará el límite máximo de 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 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 la ocultación 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 Bloquear en lugar de difundir físicamente ese Bloquear, para que los datos estén disponibles.

Entonces, ¿cómo sería si realmente logramos una implementación ideal de Rollup en BTC, permitiendo verdaderamente retiros unilaterales de usuarios?