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

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

Rollups recientemente se ha convertido 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 convertirse en una capa secundaria off-chain que no esté sujeta a las limitaciones de liquidez del núcleo de Lighting Network, es decir, los usuarios finales necesitan que se les asigne (o ‘presten’) fondos con anticipación para poder 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 fueron inicialmente implementados en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en portarlos a blockchains basadas en salidas no gastadas (UTXO), como BTC. Este artículo no pretende discutir la implementación actual en BTC, sino más bien explorar las características de un Rollup idealizado que ha sido buscado durante mucho tiempo, lo cual depende de la capacidad de BTC para verificar directamente conocimiento cero interactivo (ZKP) que actualmente no es compatible.

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. Esta UTXO incluye 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 una prueba de transacción que su cuenta es parte del árbol de Merkle, pueden salir de Rollup unilateralmente sin el 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 al completar las transacciones fuera de la cadena. Sin este ZKP, la transacción será inválida y no se puede incluir en la cadena de bloques. 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 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 cuando lo deseen sin permiso?

Rollup adecuado

En un Rollup adecuado, cada vez que se confirma una nueva transacción fuera de la cadena y cambia el estado de la cuenta Rollup, la información se coloca directamente en la cadena de bloques. No es todo el árbol, 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 agregan en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, utiliza diferencias de saldo. Básicamente, esto resume qué cuentas han aumentado o disminuido sus fondos durante el proceso de actualización. Esto hace 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.

De esta manera, se pueden ahorrar una gran cantidad de gastos y espacio de Bloquear (ahorrando dinero), 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 formal proporcionado por la cadena de Bloquear al usuario, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Fecha de caducidad

Otra forma de abordar el problema de la disponibilidad de datos para la extracción de usuarios es colocar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea problemas sutiles, ya que rollup todavía necesita asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se utilizan para este propósito, diseñadas específicamente como capas de disponibilidad de datos para sistemas como rollup.

Esto ha creado 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 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 la validación de que los datos existen en pruebas on-chain externas, lo que es en última instancia un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada que no haya ocurrido 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 que contiene la cadena de bloques han sido publicados públicamente después de su generación. No puede verificar si la información externa realmente se hizo pública para todos.

Este ataque de retención de datos abrió la puerta, es decir, crear compromisos con los datos publicados y utilizarlos para impulsar rollup, pero los datos no están realmente disponibles. Esto hace que los usuarios no puedan retirar sus fondos. La única solución real es depender completamente del valor y la estructura de incentivos de sistemas fuera de BTC.

En una situación difícil

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 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, el uso de la cadena de bloques BTC como capa de disponibilidad de datos establecerá un límite máximo en términos de escalabilidad para rollup. El espacio en la cadena de bloques es limitado, lo que establece un límite en la cantidad de rollups que pueden existir y en 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 a la cantidad de cuentas cuyos saldos han cambiado desde la última actualización. La teoría de la información solo permite comprimir los datos 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 duro de ganancias de escalabilidad, pero también conlleva nuevos problemas de seguridad y soberanía. En Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que el usuario desea extraer no se publican automáticamente en la cadena de bloques, el estado del Rollup no cambiará. Con Validiums, esta garantía depende totalmente 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 el Bloquear real, para que los datos estén disponibles.

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