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

Fuente: Bitcoin Magazine; Traducción: Wu Zhu, Golden Finance

Rollups has recently become the focus of BTC scaling, becoming the first thing that truly steals the spotlight from the Lighting Network, in terms of broader attention. Rollups aim to become an off-chain second layer that is not constrained or limited by the core Liquidity of the Lighting Network, meaning that end users need someone to pre-allocate (or ‘lend’) funds in order to receive money, or intermediate routing nodes need channel balances to facilitate the flow of payment amounts from senders to receivers.

Estos sistemas originalmente se ejecutaban en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en trasladarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no pretende discutir el estado actual de la implementación en BTC, sino más bien discutir las capacidades de Rollup idealizadas que las personas han estado persiguiendo durante mucho tiempo, las cuales dependen de la capacidad no admitida actualmente en BTC, es decir, la capacidad de verificar Prueba de conocimiento cero (ZKP) directamente en BTC.

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 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. Todas estas cuentas están autorizadas con una llave pública/llave 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 demostrando con una prueba de transacción que su cuenta es parte del árbol de Merkle, lo que les permite salir unilateralmente de Rollup sin necesidad de permiso del operador.

Los operadores de Rollup deben incluir una prueba de conocimiento cero (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 esta 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 el saldo de 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 los 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 colocan sus ramas en el árbol para poder salir sin permiso en el momento que deseen?

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 de Rollup, 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, los resúmenes de todas las cuentas existentes en el Rollup contendrán el saldo y las cuentas solo se agregan en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo de la cuenta. 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 contenga solo cambios en el saldo de la 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 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 Bloquear (ahorrando así fondos), mientras permite a los usuarios asegurar el acceso a la información necesaria para salir unilateralemente. 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 Bloquear, es decir, las transacciones que no incluyen un resumen de 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 extracción de usuarios es almacenar los datos en otro lugar fuera de la cadena de bloques. Esto plantea un problema sutil, ya que se debe garantizar que los datos sigan estando disponibles en ese otro lugar. Tradicionalmente, otras cadenas de bloques se utilizan con este propósito, diseñadas específicamente como una capa 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 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 SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere una prueba de que los datos están en la cadena. Este 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 suceda en su propia cadena de bloques, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si el bloque que contiene los datos de rollup se ha transmitido públicamente después de su generación. No puede verificar si la información externa realmente está disponible 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 avanzar en 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 sistemas distintos al BTC.

En una encrucijada

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 de 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 establecerá 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 rollup que puede 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 que los datos se compriman hasta cierto punto, por lo que no hay más potencial de escalabilidad en este punto.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite máximo de escalabilidad de las ganancias, pero también plantea nuevos problemas de seguridad y soberanía. En el 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, no se producirán cambios en el estado de Rollup. 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 realmente ese Bloquear, permitiendo que los datos estén disponibles.

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