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

Fuente: Bitcoin Magazine; Compilación: Wuzhu, Golden Finance

Rollups se ha convertido recientemente en el foco de la expansión de BTC, convirtiéndose en la primera cosa que realmente roba el protagonismo de Lighting Network, en términos de una atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no esté restringida ni limitada por la liquidez central de Lighting Network, es decir, los usuarios finales necesitan que alguien les asigne (o “preste”) fondos por adelantado para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo completo del pago desde el remitente hasta el destinatario.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO, como BTC. Este artículo no pretende discutir la implementación actual en BTC, sino más bien las características del Rollup idealizado que se ha buscado durante mucho tiempo, que depende de la capacidad de verificar directamente la Prueba de conocimiento cero (ZKP) en BTC, que actualmente no es compatible.

La arquitectura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) alberga 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, comprometido con todos los saldos actuales de las cuentas existentes en Rollup. Todas estas cuentas están autorizadas con llave pública/llave privada, por lo que los usuarios aún deben firmar ciertos contenidos con una llave secreta para realizar gastos fuera de cadena. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente haciendo una transacción que pruebe que sus cuentas son parte del árbol de Merkle, y pueden salir de Rollup de manera unilateral sin la necesidad de 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 en la cadena de bloques en el proceso de completar la transacción fuera de la cadena (off-chain). Si no hay 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 las cuentas fuera de la cadena están debidamente autorizados por los titulares de las cuentas y si el operador no actualiza maliciosamente los saldos para robar 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, ¿cómo colocarán sus ramas en el árbol para poder salir en cualquier momento sin permiso?

Rollup adecuado

En el 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 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 la cuenta solo se agregará en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Esto es esencialmente un resumen de qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto hace que cada actualización de Rollup sólo contenga cambios en el saldo de las cuentas que han ocurrido. Luego, los usuarios pueden escanear simplemente la cadena y ‘calcular desde el principio’ del Rollup para obtener el estado actual del saldo de las cuentas, lo que les permite reconstruir el árbol de Merkle del saldo actual.

Esto permite ahorrar una gran cantidad de gastos y espacio de Bloquear (ahorrando así fondos), al tiempo que permite a los usuarios garantizar el acceso a la información necesaria para la salida unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado por la cadena de Bloquear a los usuarios, por lo que 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 del usuario es colocar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea un problema sutil, ya que rollup aún necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, se han utilizado otras cadenas de Bloquear con este propósito, diseñadas específicamente como una capa de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema en el que la seguridad es igualmente fuerte. Cuando los datos se publican directamente en la cadena de bloques de Bitcoin, las reglas de consenso pueden garantizar 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 verificación de los datos que existen en pruebas on-chain de otras cosas, lo que es en última instancia un problema de Máquina de oráculo. La cadena de bloques de Bitcoin no puede verificar completamente cualquier cosa que suceda fuera de su propia cadena de bloques, excepto la que ocurre en ella misma, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup contenidos en el bloque generado por la cadena de bloques están realmente difundidos públicamente. No puede verificar si la información externa realmente se hace pública para todos.

Este ataque de retención de datos ha abierto la puerta, es decir, la creación de compromisos para publicar datos 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 los sistemas fuera de BTC.

En un estado de indecisión

Esto ha llevado a rollup a un dilema. 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, soberanía y escalabilidad de rollup.

Por un lado, el uso de la cadena de bloques de Bitcoin (BTC) como capa de disponibilidad de datos establece un límite máximo para la escalabilidad de rollup. El espacio en bloques es limitado, lo que establece un límite para la cantidad de rollups que pueden existir al mismo tiempo y para el número total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere una cantidad proporcional de espacio en bloques para las cuentas que han experimentado cambios de saldo 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 estricto de escalabilidad, 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 datos que un usuario necesita extraer no se publican automáticamente en la cadena de bloques, el estado del Rollup no podrá cambiar. Con Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado para resistir el engaño 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, lo que permite que los datos estén disponibles.

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