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

Fuente: Bitcoin Magazine; Compilación: Wuzhu, Golden 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 originalmente se ejecutaban en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no tiene la intención de discutir la implementación actual en BTC, sino de discutir las capacidades de un Rollup idealizado que ha sido buscado durante mucho tiempo, que depende de la habilidad de BTC de verificar directamente la Prueba de conocimiento cero (ZKP) que no es compatible actualmente.

La estructura básica de Roll es la siguiente: una sola cuenta (denominada UTXO en BTC) que guarda los saldos de todos los usuarios en Rollup. Este UTXO contiene un compromiso que existe en forma de raíz de Merkle del árbol Merkle, comprometiendo todos los saldos actuales de cuenta en Rollup. Todos estos cuentas son autorizados con 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 la transacción para actualizar el saldo de la cuenta on-chain durante el proceso de transacción 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 están debidamente autorizados por el titular de la cuenta, y si el operador no actualiza el saldo de manera maliciosa para robar fondos de los usuarios o redistribuirlos deshonestamente a otros usuarios.

El problema es que si solo la raíz del árbol de Merkle se publica en la cadena, los usuarios pueden ver y acceder a ella, entonces ¿cómo colocarán 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 cambia el estado de la cuenta Rollup, la información se coloca directamente en la cadena de bloques. No es todo el árbol, 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 Rollup contendrá el saldo y las cuentas solo se agregan en las transacciones de actualización de Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Esto es esencialmente un resumen de qué cuentas han aumentado o disminuido los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup solo incluya los cambios de saldo de cuenta que han 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.

Esto permite ahorrar costos significativos y espacio de Bloquear (ahorrando dinero), al tiempo que permite a los usuarios mantener acceso a la información necesaria para una salida unilateral. Según las reglas de rollup, estos datos deben incluirse en el rollup oficial proporcionado por la cadena de Bloquear, y 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 para la extracción de usuarios es colocar los datos en otro lugar fuera de la cadena Bloquear. Esto plantea un problema sutil, ya que rollup aún necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas Bloquear se utilizan con este propósito, diseñadas específicamente para servir como capa de disponibilidad de datos para sistemas como rollup.

Esto crea un dilema de seguridad igualmente fuerte. 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 SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere la validación de que los datos existen en pruebas on-chain de otros, y al final del día es un problema de Máquina de oráculo. La cadena Bloquear de BTC no puede validar completamente nada más que lo que sucede dentro de su propia cadena Bloquear on-chain. Lo mejor que puede hacer es validar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en la cadena Bloquear generada se han transmitido realmente de forma pública. No puede verificar si la información externa realmente se ha hecho pública para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, crear 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 del valor y la estructura de incentivos de los 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 BTC o en otro lugar. Esta elección tiene un gran impacto en la seguridad y la soberanía de rollup, así como en su escalabilidad.

Por un lado, utilizar la cadena de bloques de BTC como capa de disponibilidad de datos establece un límite máximo para la escalabilidad de rollup. El espacio del bloque es limitado, lo que establece un límite en la cantidad de rollup que puede existir y en la cantidad total de transacciones que se pueden procesar fuera de la cadena para todos los rollup. Cada actualización de rollup requiere un espacio de bloque proporcional al número de cuentas con cambios en el saldo desde la última actualización. La teoría de la información solo permite que los datos se compriman 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 elimina el límite máximo de escalabilidad de los beneficios, 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 necesita 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 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 al producir Bloquear en lugar de difundir realmente ese Bloquear, para hacer 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 usuarios?