Bitcoin Magazine: ¿Cuáles son los desafíos de 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 Red Lightning en términos de atención más amplia. Rollups tiene como objetivo ser una capa fuera de la cadena, sin las restricciones de Liquidez del núcleo de la Red Lightning, es decir, los usuarios finales necesitan que alguien les asigne (o ‘preste’) fondos con anticipación para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo completo de la cantidad de pago desde el remitente hasta el destinatario.

Estos sistemas originalmente se ejecutaban 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 tiene la intención de discutir la implementación actual en BTC, sino más bien analizar las características idealizadas de Rollup que la gente ha estado persiguiendo a largo plazo, las cuales dependen de la capacidad de verificar directamente conocimiento cero (ZKP) en BTC, una funcionalidad que actualmente no admite.

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 que para realizar gastos fuera de la cadena, 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, y así pueden salir de Rollup de manera unilateral sin permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar el 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 el saldo de 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 fondos de los usuarios o redistribuirlos deshonestamente a otros usuarios.

La pregunta es, si solo se publica la raíz del árbol de Merkle en la cadena, y los usuarios pueden ver y acceder a ella, ¿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. 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á saldos y las cuentas solo se agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, utiliza diferencias de saldo. Básicamente, esto resume qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup solo incluya cambios en el saldo de la cuenta que ocurrieron. 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 permitirá ahorrar una gran cantidad de gastos y espacio de bloqueo (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 oficial proporcionado a los usuarios mediante la cadena de bloques, por lo que las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Periodo 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 bloques. Esto plantea sutiles problemas, ya que rollup todavía necesita asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de bloques se utilizan con este propósito, 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 verificar que los datos existan en una prueba de otro on-chain, lo que finalmente es un problema de Máquina de oráculo. La cadena de bloques Bloquear de BTC no puede verificar completamente cualquier cosa que suceda fuera de su propia cadena de bloques Bloquearon, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup incluidos en el Bloquear generado se difunden realmente de manera pública. No puede verificar si la información externa está realmente disponible para todos.

Esta apertura de ataque de retención de datos permite la creación de compromisos para publicar datos y utilizarlos para avanzar en rollup, pero los datos no están realmente disponibles. Esto hace que los usuarios no puedan retirar fondos. La única solución real es depender completamente de un sistema de valor y estructura de incentivos que no sea BTC.

En medio de un dilema

Esto plantea un dilema para rollup. 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, 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 establece un límite máximo en la escalabilidad de rollup. El espacio de bloque es limitado, lo que establece un límite en la cantidad de rollups que pueden existir al mismo tiempo y en la cantidad total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere un espacio de bloque proporcional al número 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 expansión en este sentido.

Por otro lado, el uso de capas diferentes 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 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 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 produciendo Bloquear en lugar de transmitir realmente ese Bloquear, lo que hace que los datos estén disponibles.

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