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

Fuente: Bitcoin Magazine; Compilado por Wu Zhu, Golden Finance

Rollups se ha convertido recientemente en el foco de la escalabilidad de BTC, convirtiéndose en la primera cosa que realmente ha robado el protagonismo de la Lighting Network en términos de una atención más amplia. Rollups tiene como objetivo ser una segunda capa off-chain que no está restringida o limitada por la Liquidez central de Lighting Network, es decir, los usuarios finales necesitan que alguien asigne (o “preste”) fondos con anticipación para recibir dinero, o los Nodos intermedios necesitan saldos de canal para facilitar el flujo completo del pago desde el remitente hasta el receptor.

Estos sistemas se desarrollaron inicialmente para operar en Ethereum y otros sistemas Turing completo, pero recientemente 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 características idealizadas de Rollup que se han buscado a largo plazo, las cuales dependen de capacidades que actualmente no son compatibles con BTC, es decir, la capacidad de verificar zk-SNARKs directamente en BTC.

La arquitectura básica de Roll es la siguiente: una sola cuenta (UTXO en BTC) almacena el saldo de todos los usuarios en Rollup. Esta UTXO contiene un compromiso que existe en forma de raíz de Merkle de un árbol de Merkle, comprometiendo todos los saldos actuales de la cuenta existentes en Rollup. Todas estas cuentas están autorizadas con llaves públicas/privadas, por lo que los usuarios aún deben firmar cierto contenido con una llave secreta para solicitar gastos fuera de la cadena. Esta parte de la estructura permite a los usuarios salir en cualquier momento sin permiso, simplemente haciendo una transacción que demuestre 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 cero (ZKP) en la transacción para actualizar la raíz de Merkle del saldo de la cuenta en la cadena en el proceso de completar la transacción fuera de la cadena. Sin esta prueba de conocimiento cero, 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 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, ¿cómo pueden colocar sus ramas en el árbol para poder salir en cualquier momento sin permiso?

Rollup adecuado

En un 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, todos los resúmenes de cuenta existentes en el Rollup contendrán saldos y las cuentas solo se agregarán en transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza la diferencia de saldos. 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 contenga solo cambios en los saldos de las cuentas 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.

De esta manera, se pueden ahorrar una gran cantidad de gastos y espacio de bloqueo (lo que ahorra dinero), al tiempo que se permite a los usuarios garantizar el acceso a la información necesaria para salir unilateralmente. Según las reglas de rollup, estos datos deben incluirse en el rollup formal proporcionado por la cadena de bloques, 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 garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas Bloquear se utilizan para este propósito, diseñadas específicamente como una capa de disponibilidad de datos para sistemas como rollup.

Esto crea un dilema de seguridad igualmente poderoso. Cuando los datos se publican directamente en la cadena de bloques de BTC, 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 verificar que los datos existan en una prueba en cadena de otro on-chain, lo cual es en última instancia un problema de Máquina de oráculo. La cadena de Bloquear de BTC no puede verificar completamente nada más que lo que ocurre en su propia cadena de Bloquear, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup incluidos en el Bloquear se difunden realmente después de la generación. No puede verificar si la información externa realmente se hace pública para todos.

Esto abrió la puerta a los ataques de retención de datos, es decir, crear compromisos sobre datos publicados y utilizarlos para impulsar rollup, pero en realidad los datos no están disponibles. Esto impide que los usuarios retiren fondos. La única solución real es depender completamente del valor y la estructura de incentivos de sistemas fuera de BTC.

Entre la espada y la pared

Esto ha llevado a rollup a un dilema. Cuando se trata de problemas de disponibilidad de datos, básicamente existe una elección binaria entre publicar los datos en la cadena de bloques 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 bloqueo 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 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 expansión en este sentido.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite máximo de escalabilidad de los beneficios, pero también traerá nuevos problemas de seguridad y soberanía. En un 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 del 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 secuestrar los fondos de los usuarios de BTCRollup al producir Bloquear en lugar de transmitir efectivamente ese Bloquear, lo que permite que los datos estén disponibles.

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