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

Fuente: Bitcoin Magazine; Compilado por: 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 eclipsado a la Lighting Network en términos de atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no está sujeta a las restricciones de liquidez centrales de Lighting Network, es decir, los usuarios finales necesitan que alguien les 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 fueron originalmente implementados en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO, como BTC. Este artículo no pretende discutir el estado actual de la implementación en BTC, sino discutir las características de un rollup idealizado que ha sido buscado durante mucho tiempo, lo cual depende de la capacidad de BTC de verificar directamente Prueba de conocimiento cero (ZKP), una funcionalidad que actualmente no es compatible con 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 llave pública/llave privada, por lo tanto, 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 de 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 Merkle del saldo de la cuenta on-chain al completar las transacciones off-chain. Si no hay un ZKP, la transacción será inválida y no se puede incluir en el Bloquear. 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 actualiza el saldo con malicia 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 verlo y acceder a él, ¿cómo pueden colocar sus ramas en el árbol para poder salir en cualquier momento sin permiso?

Rollup adecuado

En Rollup adecuado, cada vez que se confirma una nueva transacción off-chain 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 absurdo, sino la información necesaria para reconstruir el árbol. En una implementación simple, los resúmenes de todas las cuentas existentes en Rollup contendrán saldos y las cuentas solo se agregarán en las transacciones de actualización de Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Básicamente, esto resume qué cuentas han aumentado o disminuido sus 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 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 saldo actual.

Esto puede ahorrar una gran cantidad de gastos y espacio de Bloquear (ahorrando así dinero), al tiempo que permite a los usuarios garantizar el acceso a la información necesaria para salir unilateralmente. Las reglas de rollup requieren que estos datos se incluyan en el rollup formal proporcionado a los usuarios utilizando la cadena de Bloquear, por lo que las transacciones que no incluyen un resumen de cuenta o diferencias de cuenta se consideran 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 otros lugares fuera de la cadena Bloquear. Esto introduce un problema sutil, rollup aún necesita asegurar que los datos estén disponibles en otros lugares. Tradicionalmente, otras cadenas Bloquear se utilizan para este propósito, diseñadas específicamente como capas 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 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 la validación de que los datos existen en pruebas de otros bloques, lo que finalmente es un problema de Máquina de oráculo. La cadena de bloques de BTC no puede validar completamente cualquier cosa que no suceda en su propio bloque de enlace, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos rollup contenidos en el bloque se han transmitido públicamente después de su generación. No puede verificar si la información externa se ha hecho realmente pública para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, crear compromisos sobre la publicación de datos y utilizarlos para avanzar en rollup, pero en realidad los datos no están 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 a BTC.

En una encrucijada

Esto ha planteado 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 BTC o en otro lugar. Esta decisión tiene un gran impacto en la seguridad, soberanía y escalabilidad de rollup.

Por un lado, utilizar la cadena de bloques Bitcoin como capa de disponibilidad de datos establecerá un límite estricto a la escalabilidad de rollup. El espacio de bloque es limitado, lo que establece un límite en la cantidad de rollup que puede existir en un momento dado, así como en la cantidad total de transacciones que todos los rollup pueden procesar off-chain. 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 punto.

Por otro lado, el uso de capas diferentes 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 Rollup que utiliza BTC para lograr la disponibilidad de datos, si los datos que los usuarios desean extraer no se publican automáticamente en la cadena de bloques, el estado de Rollup no puede cambiar. En Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado para resistir el fraude 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 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, logrando verdaderamente retiros unilaterales de los usuarios?