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

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

Los rollups se han convertido recientemente en el centro de atención de la escalabilidad de BTC, convirtiéndose en la primera cosa que realmente ha robado el protagonismo de la Lighting Network, en términos de atención más amplia. Los rollups tienen como objetivo ser una segunda capa off-chain que no esté restringida o limitada por la liquidez central de Lighting Network, es decir, los usuarios finales necesitan que alguien asigne (o ‘preste’) 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 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 tiene la intención de discutir el estado actual de implementación en BTC, sino más bien discutir las capacidades ideales de Rollup que la gente ha estado persiguiendo a largo plazo, lo que depende de la capacidad actualmente no admitida en BTC de verificar Prueba de conocimiento cero (ZKP) directamente en BTC.

La estructura básica de Roll es la siguiente: una sola UTXO (en BTC, Unspent Transaction Output) 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 las cuentas 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 con una transacción que sus cuentas forman parte del árbol de Merkle, pueden salir de Rollup unilateralmente sin necesitar el permiso del operador.

Los operadores de Rollup deben incluir una demostración de conocimiento cero (ZKP) en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta en la cadena de bloques on-chain durante la realización de transacciones off-chain. Sin esta ZKP, la transacción sería 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 están debidamente autorizados por el titular de la cuenta y si el operador no está actualizando el saldo de manera malintencionada 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 verla y acceder a ella, ¿como pueden colocar 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 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 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. Básicamente, esto resume qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto hace que cada actualización de Rollup solo incluya cambios en el saldo de la cuenta que han 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 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 asegurar el acceso a la información necesaria para una salida unilateral. 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, 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 de usuarios es colocar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea problemas sutiles, ya que rollup aún necesita garantizar 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 una capa de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema en el que la seguridad es igualmente sólida. Cuando los datos se publican directamente en la cadena de bloques Bitcoin, 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 verificar que los datos existan en una prueba on-chain de otros oráculos. Este es finalmente un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada que ocurra fuera de su propia cadena de bloques, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup de un bloque realmente se han difundido públicamente después de su generación. No puede verificar si la información externa realmente está disponible para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, crear compromisos sobre los datos publicados y utilizarlos para impulsar rollup, pero los datos no están realmente disponibles. Esto impide que los usuarios retiren fondos. La única solución real es depender completamente del valor y la estructura de incentivos de 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 de BTC o en otro lugar. Esta elección tiene un impacto significativo en la seguridad, la soberanía y la escalabilidad de rollup.

Por un lado, utilizar la cadena de bloques de BTC como capa de disponibilidad de datos establecerá un límite máximo para la escalabilidad de rollup. El espacio de bloquear 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 se pueden procesar fuera de la cadena. Cada actualización de rollup requiere espacio de bloquear 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 máximo de escalabilidad de los beneficios, pero también plantea nuevos problemas de seguridad y soberanía. En el caso de Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que los usuarios necesitan extraer no se publican automáticamente en la cadena de bloques, el estado de Rollup no puede cambiar. Con Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado para resistir el engaño y ocultar los 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, lo que hace que los datos estén disponibles.

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