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

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

Rollups recientemente se ha convertido en el foco de la escalabilidad de BTC, convirtiéndose en la primera verdadera competencia para la Red Lightning, con una mayor atención en general. Rollups tiene como objetivo ser una capa secundaria fuera de la cadena, no limitada o restringida por la liquidez central de la Red Lightning, es decir, los usuarios finales necesitan asignar (o ‘prestar’) fondos con anticipación para recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo total del pago desde el remitente hasta el destinatario.

Estos sistemas se desarrollaron inicialmente para funcionar 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 situación actual de implementación en BTC, sino más bien discutir las capacidades idealizadas de Rollup que las personas han estado persiguiendo a largo plazo, las cuales dependen de la capacidad de BTC actualmente no compatible: 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 almacena 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 que para realizar gastos fuera de la cadena, 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 creando una prueba de transacción que demuestre que su cuenta es parte del árbol de Merkle, lo que les permite abandonar Rollup unilateralmente sin el permiso del operador.

Los operadores de Rollup deben incluir una ZKP en las transacciones para actualizar la raíz de Merkle del saldo de la cuenta en la cadena de bloques al completar las transacciones fuera de la cadena. Sin esta ZKP, la transacción será inválida y no se puede incluir en el bloque. Esta prueba permite a las personas verificar si todos los cambios en la cuenta fuera de la cadena están autorizados correctamente por el titular de la cuenta y si el operador no actualiza el saldo maliciosamente para robar los 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 verla 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 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 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 el Rollup contendría el saldo y las cuentas solo se agregarían en transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldos. Esto esencialmente resume qué cuenta ha 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 Merkle del saldo actual.

De esta manera, se pueden ahorrar muchos gastos y espacio en Bloquear (y, por lo tanto, ahorrar dinero), al tiempo que se permite a los usuarios garantizar el acceso a la información necesaria para salir unilateralmente. Las reglas del rollup requieren que estos datos se incluyan en el rollup oficial proporcionado por la cadena Bloquear a los usuarios, y las transacciones que no incluyen un resumen o 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 almacenar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea problemas sutiles, ya que rollup aún necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de 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 de seguridad igualmente desafiante. Cuando los datos se publican directamente en la cadena de bloques Bitcoin, las reglas de consenso pueden garantizar que sea absolutamente correcto. Sin embargo, cuando se publica en sistemas externos, lo mejor que puede 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 otras pruebas on-chain, que en última instancia es un problema de Máquina de oráculo. La cadena de Bloquear de BTC no puede verificar completamente nada que suceda fuera de su propia cadena de Bloquear, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos rollup en la cadena de Bloquear se han transmitido públicamente después de su generación. No puede verificar si la información externa realmente se ha hecho pública para todos.

Esto abrió la puerta a los ataques de retención de datos, es decir, crear compromisos con los datos publicados y utilizarlos para impulsar 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 sistemas distintos a BTC.

Dilema

Esto presenta 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 impacto significativo en la seguridad, la soberanía y la escalabilidad de rollup.

Por un lado, utilizar la cadena de bloques BTC como capa de disponibilidad de datos establecerá un límite máximo para la escalabilidad de rollup. El espacio en la cadena de bloques 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 en la cadena de bloques proporcional al número de cuentas cuyos saldos han cambiado desde la última actualización. La teoría de la información solo permite comprimir los datos hasta cierto punto, y en este sentido, no hay más potencial de escalabilidad.

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

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