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 el enfoque se ha centrado en trasladarlos a blockchains basadas en UTXO (por ejemplo, BTC). Este artículo no pretende discutir la implementación actual en BTC, sino más bien las capacidades ideales de Rollup que la gente ha estado persiguiendo durante mucho tiempo, lo cual depende de las capacidades actualmente no admitidas en BTC, es decir, la capacidad de verificar Prueba de conocimiento cero (ZKP) directamente en BTC.

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

El operador de Rollup debe incluir una prueba de conocimiento nulo (ZKP) en la transacción para actualizar la raíz Merkle del saldo de la cuenta on-chain durante el proceso de transacción fuera de la cadena (off-chain). Sin esta 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 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 verlo y acceder a él, entonces ¿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 fuera de la cadena y el estado de la cuenta de Rollupcuenta cambia, 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, el resumen de todas las cuentas existentes en Rollup contendrá saldos, y las cuentas solo se agregan en las transacciones actualizadas de Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldo. Básicamente, esto resume qué cuentas aumentaron o disminuyeron los fondos durante el proceso de actualización. Esto permite que cada actualización de Rollup solo contenga cambios en el saldo de la cuenta que ocurrieron. Luego, los usuarios pueden simplemente escanear la cadena y ‘calcular’ desde el comienzo de 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 bloque (ahorrando así fondos), al tiempo que permite a los usuarios asegurar 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 bloques, es decir, las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Período de validez

Otra forma de abordar el problema de la disponibilidad de los datos de extracción de usuarios es colocar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea problemas sutiles, ya que rollup aún debe asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se han utilizado para este propósito, diseñadas específicamente 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 es absolutamente correcto. Sin embargo, cuando se publica en un sistema externo, lo mejor que puede hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere la verificación de que los datos existen en pruebas on-chain externas, lo que en última instancia es un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada que no suceda en su propio bloque on-chain, lo mejor que puede hacer es verificar la prueba de conocimiento cero. Sin embargo, la prueba de conocimiento cero no puede verificar si los datos de rollup contenidos en el bloque después de la generación se han difundido públicamente. No puede verificar si la información externa se ha hecho pública para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para impulsar el rollup, pero los datos no están realmente disponibles. Esto hace que los usuarios no puedan retirar los fondos. La única solución real es depender completamente de sistemas de valor y estructuras de incentivos que no sean BTC.

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 datos en la cadena de bloques de BTC o en otro lugar. Esta elección tiene un impacto significativo 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 para la escalabilidad de rollup. El espacio de bloqueo es limitado, lo que establece un límite para la cantidad de rollup que puede 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 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 punto.

Por otro lado, el uso de diferentes capas 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 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 de Rollup no puede cambiar. Con Validiums, esta garantía depende completamente de la capacidad de los sistemas externos utilizados para resistir el fraude y ocultar 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 el Bloquear real, lo que permite que los datos estén disponibles.

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