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

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

Rollups se ha convertido recientemente en el foco de la expansión de BTC, convirtiéndose en la primera cosa que realmente le ha robado protagonismo a la Lighting Network, en términos de una atención más amplia. Rollups tiene como objetivo ser una capa dos off-chain que no está restringida o limitada por la liquidez central de Lighting Network, es decir, los usuarios finales necesitan que alguien les asigne (o ‘preste’) fondos con antelación para poder recibir dinero, o los nodos intermedios necesitan saldos de canal para facilitar el flujo total del monto del pago desde el remitente hasta el destinatario.

Estos sistemas originalmente se ejecutaban en Ethereum y otros sistemas Turing completo, pero recientemente el enfoque se ha trasladado a su implementación en cadenas de bloques basadas en UTXO (por ejemplo, BTC). Este artículo no pretende discutir el estado actual de la implementación en BTC, sino más bien discutir las capacidades ideales de Rollup perseguidas a largo plazo por las personas, las cuales dependen de funcionalidades 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 sola cuenta (en BTC, UTXO) que guarda los saldos de todos los usuarios en Rollup. Este UTXO contiene un compromiso que existe en forma de raíz de Merkle de un árbol de Merkle que promete todos los saldos actuales de las cuentas existentes en Rollup. Todas estas cuentas están autorizadas mediante llaves públicas/privadas, por lo que para hacer gastos fuera de la cadena, los usuarios aún deben firmar ciertos contenidos con una llave secreta. 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 de manera unilateral sin necesidad de permiso del operador.

Los operadores de Rollup deben incluir un ZKP en las transacciones para actualizar el saldo de la cuenta en la cadena on-chain durante el proceso de completar transacciones off-chain. Sin este ZKP, la transacción será inválida y no puede incluirse en el bloque. Esta prueba permite a las personas verificar si todos los cambios en la cuenta off-chain han sido autorizados adecuadamente por el titular de la cuenta, y si el operador no ha actualizado 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, pero ¿cómo colocan sus ramas en el árbol para que puedan salir sin permiso cuando lo deseen?

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 de Rollup, 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 el Rollup contendrá los saldos, y las cuentas solo se agregarán en las transacciones de actualización del Rollup.

En implementaciones más avanzadas, se utiliza una diferencia de saldo. Básicamente, esto es 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 contenga 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 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í capital), al tiempo que permite a los usuarios asegurar 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 a través de la cadena de Bloquear, por lo que las transacciones que no incluyen un resumen de cuenta o diferencias de cuenta se consideran inválidas.

Periodo de validez

Otra forma de abordar el problema de la disponibilidad de datos de extracción del usuario es colocar los datos en otro lugar fuera de la cadena de bloques. Esto plantea un problema sutil, ya que rollup aún necesita garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de bloques se utilizan con este propósito, diseñadas específicamente como una 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 de bloques Bitcoin, las reglas de consenso pueden garantizar que son absolutamente correctos. Sin embargo, cuando se publican en un sistema externo, lo mejor que pueden hacer es verificar la prueba SPV, es decir, que los datos se han publicado en otro sistema.

Esto requiere validar que los datos existen en otras pruebas on-chain, lo que es en última instancia 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 de rollup de Bloquear después de generarse realmente se transmiten públicamente. 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 la publicación de datos y utilizarlos para impulsar rollup, pero en realidad los datos no están 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 al BTC.

Entrar y salir de la situación difícil

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, la soberanía y la escalabilidad de Rollup.

Por un lado, utilizar la cadena de bloques de Bitcoin como capa de disponibilidad de datos establece un límite máximo a la escalabilidad de rollup. El espacio de bloques es limitado, lo que establece un límite al número de rollups que pueden existir y a la cantidad total de transacciones que se pueden procesar fuera de la cadena. Cada actualización de rollup requiere un espacio de bloque proporcional al número 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 ganancias de escalabilidad, 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 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 engaño 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 realmente ese Bloquear, lo que permite que los datos estén disponibles.

Entonces, ¿cómo sería si realmente logramos una implementación Rollup ideal en BTC y logramos la retirada unilateral de los usuarios?