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

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

Rollups ha sido el foco de atención para la escalabilidad de BTC recientemente y se ha convertido en la primera cosa que realmente ha robado protagonismo a Lighting Network, en términos de atención más amplia. Los Rollups están diseñados para ser una segunda capa fuera de la cadena (off-chain) que no está limitada o restringida por la liquidez central de Lighting Network, lo que significa que los usuarios finales necesitan que se les asigne anticipadamente (o se les ‘preste’) fondos para poder recibir dinero, o los nodos de enrutamiento necesitan tener saldo en los canales 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 se ha centrado en trasladarlos a cadenas de bloques 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 más bien discutir la funcionalidad ideal de Rollup que las personas han estado persiguiendo durante mucho tiempo, la cual depende de la capacidad actualmente no admitida en BTC, es decir, la capacidad de verificar zk-SNARKs directamente en BTC.

La estructura básica de Roll es la siguiente: una sola 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. Todos estos cuentas están autorizados con la llave pública/llave privada, por lo tanto, 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, simplemente demostrando con una transacción que su cuenta es parte del árbol de Merkle, pueden salir unilateralmente de Rollup sin necesidad del permiso del operador.

El operador de Rollup debe incluir una Prueba de Conocimiento Cero (ZKP) en la transacción para actualizar la raíz de Merkle del saldo de la cuenta on-chain durante el proceso de transacción off-chain. Sin esta ZKP, la transacción sería inválida y no se podría incluir en la cadena de bloques. 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 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 podrían ver y acceder a ella, pero ¿cómo pueden colocar sus ramas en el árbol para poder salir cuando lo deseen sin necesidad de permiso?

Rollup adecuado

En 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 Rollup contendrá el saldo y las cuentas solo se agregan en las transacciones de actualización de 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 cambios en el saldo de cuenta que han ocurrido. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el comienzo del Rollup para obtener el estado actual del saldo de cuenta, lo que les permite reconstruir el árbol de Merkle del saldo actual.

De esta manera, se pueden ahorrar una gran cantidad de gastos y espacio de Bloquear (lo que ahorra dinero), al tiempo que permite a los usuarios garantizar el acceso a la información necesaria para la salida unilateral. Según las reglas de rollup, estos datos deben incluirse en el rollup oficial proporcionado por la cadena de Bloquear al usuario, es decir, 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 extracción del usuario es colocar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea problemas sutiles, ya que el rollup aún debe asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear han sido utilizadas con este propósito, diseñadas específicamente como una 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 Bitcoin, las reglas de consenso pueden asegurar que sea absolutamente correcto. Sin embargo, cuando se publica en un sistema externo, lo mejor que puede hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere la validación de que los datos existen en pruebas en-cadena de otros, esto es en última instancia un problema de Máquina de oráculo. La cadena de bloques de Bloquear de BTC no puede verificar completamente nada más que lo que sucede en su propia cadena de bloques en-cadena, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en un bloque después de su generación realmente se difunden públicamente. No puede verificar si la información externa realmente se hace pública para todos.

Esta apertura de puertas para los ataques de retención de datos implica la creación de compromisos para publicar datos y su uso en el avance de 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 los sistemas que no sean 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 datos en la cadena de bloques 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 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 pueden procesarse 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 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 plantea nuevos problemas de seguridad y soberanía. En Rollup, que utiliza BTC para lograr la disponibilidad de datos, si los datos que un usuario desea 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 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 transmitir el Bloquear real, lo que permite que los datos estén disponibles.

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