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 ha robado el protagonismo de Lighting Network en términos de atención más amplia. Rollups tiene como objetivo ser una capa secundaria off-chain sin las limitaciones de liquidez centrales de Lighting Network, es decir, los usuarios finales necesitan que alguien asigne (o “preste”) fondos por adelantado para recibir dinero, o los nodos intermedios necesitan equilibrios de canal para facilitar el flujo total de los pagos desde el remitente hasta el destinatario.

Estos sistemas se desarrollaron originalmente para ejecutarse en Ethereum y otros sistemas Turing completo, pero recientemente el enfoque se ha desplazado hacia su portabilidad a blockchains 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 las capacidades ideales de Rollup que las personas han estado persiguiendo durante mucho tiempo, lo cual depende de la capacidad actualmente no compatible 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 sola cuenta (llamada 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. 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, simplemente demostrando que su cuenta es parte del árbol de Merkle, pueden salir de Rollup unilateralmente sin necesidad de permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar el saldo de la cuenta en la cadena de bloques on-chain durante el proceso de completar transacciones off-chain. Sin este 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 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 pueden ver y acceder a ella, pero ¿cómo colocan sus ramas en el árbol para poder salir sin permiso cuando lo deseen?

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 absurdo, sino la información necesaria para reconstruir el árbol. En una implementación sencilla, el resumen de todas las cuentas existentes en el Rollup contendrá los 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. Esencialmente, esto resume qué cuentas han aumentado o disminuido sus fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup solo contenga cambios de saldo de cuenta que hayan ocurrido. Luego, los usuarios pueden simplemente escanear 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 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. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado a los usuarios utilizando la cadena de Bloquear, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran transacciones inválidas.

Período de validez

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 sutiles problemas, ya que rollup aún debe garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de 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 en el que la seguridad es igualmente fuerte. Cuando los datos se publican directamente en la cadena BTC Bloquear, las reglas de Consenso pueden garantizar que sean absolutamente correctos. Sin embargo, cuando se publican en un sistema externo, lo mejor que pueden hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere pruebas de que los datos existen en pruebas de que los datos existen en otros bloques de la cadena, lo que en última instancia es un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada que suceda fuera de sus propios bloques de la cadena, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en el bloque se han difundido públicamente después de su generación. No puede verificar si la información externa realmente está disponible para todos.

Esta es una puerta abierta para ataques de retención de datos, es decir, la creación de compromisos con respecto a la publicación de datos y su uso para impulsar el 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 de sistemas de valores y estructuras de incentivos fuera de BTC.

En un dilema

Esto plantea un dilema para Rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente hay una elección binaria de si publicar datos en la cadena de bloques BTC o en otro lugar. Esta elección tiene un impacto significativo en la seguridad y soberanía de Rollup, así como en su escalabilidad.

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 bloques es limitado, lo que establece un límite en la cantidad de rollups que pueden existir a la vez y en la cantidad total de transacciones que todos los rollups pueden manejar 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, por lo que no hay más potencial de escalabilidad en este aspecto.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite rígido de ganancias de escalabilidad, 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 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 ocultar datos.

Ahora, cualquier productor de Bloquear en el sistema de disponibilidad de datos externos puede secuestrar los fondos de los usuarios de BTCRollup mediante la producción de Bloquear en lugar de difundir realmente 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 y logramos retiros unilaterales de los usuarios?