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

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

Los rollups se han convertido recientemente en el foco del escalado de BTC, convirtiéndose en lo primero que realmente “roba el espectáculo” de Lighting Network, en términos de una atención más amplia. Los rollups están diseñados para ser una capa 2 fuera de la cadena que no está restringida ni restringida por las restricciones centrales de Liquidez de Lighting Network, es decir, el usuario final necesita que alguien asigne (o “preste”) los fondos por adelantado para recibir el dinero, o el enrutamiento intermedio Nodo necesita el saldo del canal para facilitar el flujo del monto del pago desde el remitente hasta el receptor.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO, como 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 características del Rollup idealizado que se ha perseguido durante mucho tiempo, que depende de la capacidad de verificar ZKP (Prueba de conocimiento cero) directamente en BTC, una función que BTC no soporta actualmente.

La estructura básica de Roll es la siguiente: una sola cuenta (UTXO en BTC) 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 cuenta en Rollup. Todas estas cuentas están autorizadas con la llave pública/llave privada, por lo tanto, para realizar gastos off-chain, los usuarios aún deben firmar ciertos contenidos con la llave secreta. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente haciendo una prueba de transacción que su cuenta es parte del árbol de Merkle, pueden salir unilateralmente de Rollup sin permiso del operador.

El operador de Rollup debe incluir una ZKP en la transacción para actualizar la raíz de Merkle del saldo de la cuenta en la cadena de bloques durante el proceso de completar transacciones fuera de la cadena. 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 el saldo de la cuenta fuera de la cadena están debidamente autorizados por el titular de la cuenta y si el operador no actualiza 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, ¿cómo colocan sus ramas en el árbol para poder salir sin permiso cuando lo deseen?

Rollup adecuado

En un Rollup adecuado, cada vez que se confirma una nueva transacción off-chain y el estado de la cuenta Rollup cambia, 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á 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 han ocurrido. Luego, los usuarios simplemente pueden 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 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 diferencias 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 Bloquear. Esto introduce problemas sutiles, ya que rollup aún debe asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas 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 de seguridad igualmente poderoso. Cuando los datos se publican directamente en la cadena Bitcoin, las reglas del consenso pueden garantizar que sean absolutamente correctos. Sin embargo, cuando se publican en sistemas externos, lo mejor que pueden hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere una prueba de que los datos existen en otras pruebas en cadena, lo cual es en última instancia un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente cualquier cosa que ocurra fuera de su propia cadena de bloques, lo mejor que puede hacer es verificar la ZKP. Sin embargo, la ZKP no puede verificar si el bloque que contiene los datos de rollup realmente se difunde públicamente después de ser generado. No puede verificar si la información externa realmente se hace pública para todos.

Este ataque de retención de datos abre la puerta a crear compromisos en torno a la publicación de datos y utilizarlos para impulsar el rollup, pero los datos no están realmente disponibles, lo que impide a los usuarios extraer sus fondos. La única solución real es depender completamente de un sistema de valor y estructura de incentivos fuera de BTC.

En un dilema

Esto ha llevado a rollup a un dilema. Cuando se trata de problemas de disponibilidad de datos, básicamente hay una elección binaria entre publicar datos en la cadena de bloques de BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad, soberanía y 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 para la escalabilidad de rollup. El espacio de bloques 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 un espacio de bloques 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 duro de ganancia de escalabilidad, pero también traerá nuevos problemas de seguridad y soberanía. En 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 de Rollup no puede cambiar. Con Validiums, esta garantía depende completamente de la capacidad de los sistemas externos utilizados 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 apropiarse de los fondos de los usuarios de BTCRollup al producir Bloquear en lugar de difundir el Bloquear real, lo que permite que los datos estén disponibles.

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