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

Fuente: Bitcoin Magazine; Recopilación: Five Baht, Golden Finance

Rollups recientemente se ha convertido en el foco de la expansión de BTC, convirtiéndose en la primera cosa que realmente ha robado el protagonismo de la Red Lightning, en términos de una atención más amplia. Rollups tiene como objetivo ser una capa off-chain de segundo nivel que no está restringida por las limitaciones de liquidez centrales de la Red Lightning, es decir, los usuarios finales necesitan que alguien les asigne (o ‘preste’) fondos con antelación para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo de pagos de remitente a destinatario.

Estos sistemas fueron originalmente implementados en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en su adaptación a blockchains basadas en UTXO, como BTC. Este artículo no tiene la intención de discutir la implementación actual en BTC, sino más bien las capacidades ideales de un rollup que ha sido buscado durante mucho tiempo, que depende de la capacidad de verificar Prueba de conocimiento cero (ZKP) directamente en BTC, una funcionalidad que BTC no admite actualmente.

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 Merkle del árbol Merkle, comprometiendo todos los saldos actuales de cuenta en Rollup. Todos estos cuentas están autorizados con una Llave pública/ Llave privada, por lo que para realizar gastos off-chain, los usuarios aún deben firmar cierto contenido con Llave secreta. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente demostrando que sus cuentas son parte del árbol Merkle, pueden salir unilateralmente de Rollup sin necesidad de 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 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 la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en la cuenta off-chain han sido adecuadamente autorizados por el titular de la cuenta, y si el operador no ha actualizado 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 ver y acceder a ella, pero ¿cómo colocan sus ramas en el árbol para que puedan salir sin permiso cuando lo deseen?

Rollup adecuado

En el Rollup adecuado, cada vez que se confirma una nueva transacción off-chain y el estado de la cuenta Rollupcambia, la información se colocará directamente en la cadena de bloques. No es el árbol completo, eso sería demasiado 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 incluirá 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 contenga cambios en el saldo de la cuenta que hayan ocurrido. 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 grandes gastos y espacio de bloqueo (ahorrando fondos), al tiempo que se permite a los usuarios garantizar 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 por la cadena de bloques, es decir, las transacciones que no incluyen un resumen de cuenta o diferencias de cuenta se consideran transacciones inválidas.

Período de validez

Otra forma de abordar el problema de la disponibilidad de datos de retiro de usuarios es colocar los datos en otro lugar fuera de la cadena Bloquear. Esto introduce un problema sutil, rollup todavía necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas Bloquear se utilizan para 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 poderoso. 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 de SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere una prueba de que los datos existen en otras pruebas on-chain, lo que finalmente es un problema de Máquina de oráculo. La cadena de Bitcoin no puede verificar completamente nada más que lo que ocurre 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 en el bloque después de ser generado realmente se transmiten públicamente. No puede verificar si la información externa realmente se hace pública para todos.

Esto abre la puerta a ataques de retención de datos, 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 extraer fondos. La única solución real es depender completamente del valor y la estructura de incentivos de sistemas fuera de BTC.

Entre la espada y la pared

Esto plantea un dilema para rollup. Cuando se trata de problemas de disponibilidad de datos, básicamente hay 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 para la escalabilidad de rollup. El espacio de bloqueo es limitado, lo que establece un límite para la cantidad de rollups que pueden existir al mismo tiempo y la cantidad total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere espacio de bloqueo 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 sentido.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite máximo de escalabilidad, pero también plantea nuevos problemas de seguridad y soberanía. En un 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 puede cambiar. Con Validiums, esta garantía depende completamente 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 transmitir realmente ese Bloquear, lo que permite que los datos estén disponibles.

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