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

Rollups se ha convertido en el centro de atención de la expansión de BTC últimamente, convirtiéndose en la primera cosa que realmente ha robado la atención de Lighting Network y ha ganado una atención más amplia. Rollups tiene como objetivo convertirse en una segunda capa fuera de la cadena, no restringida por la liquidez central de Lighting Network, lo que significa que los usuarios finales necesitan que alguien les asigne (o 'preste') fondos de antemano para recibir el dinero, o que los nodos intermediarios necesitan equilibrio de canal para facilitar el flujo completo de los pagos del remitente al destinatario.

Estos sistemas se ejecutaron originalmente en Ethereum y otros sistemas Turing completos, pero recientemente se ha centrado en portarlos a blockchains basadas en UTXO (como BTC). Este artículo no pretende discutir la implementación actual en BTC, sino más bien las características de Rollup idealizadas que se han perseguido durante mucho tiempo, que dependen de la capacidad de verificar directamente las Pruebas de conocimiento cero (ZKP) en BTC, una capacidad que BTC no admite actualmente.

La arquitectura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) mantiene 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, que compromete todos los saldos actuales de cuenta en Rollup. Todos estos cuentas están autorizados con Llave pública/Llave privada, por lo que los usuarios aún deben firmar cierto contenido con Llave secreta para realizar 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 unilateralmente de Rollup sin permiso del operador.

El operador de Rollup debe incluir una ZKP en la transacción para actualizar la raíz de Merkle del saldo de la cuenta en la cadena de bloques durante el proceso de transacción fuera de la cadena. Sin esta ZKP, 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, pero ¿cómo pueden colocar sus ramas en el árbol para poder retirarse 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 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, los resúmenes de todas las cuentas existentes en Rollup contendrán los saldos, y las cuentas solo se agregarán en las transacciones de actualización de Rollup.

En implementaciones más avanzadas, utiliza la diferencia de saldo. Básicamente, esto resume qué cuentas han aumentado o disminuido los 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 puede ahorrar mucho gasto y espacio de Bloquear (ahorrando así fondos), mientras se permite a los usuarios garantizar el acceso a la información necesaria para una salida unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup oficial proporcionado a los usuarios mediante la cadena de Bloquear, y las transacciones que no incluyen un resumen de cuenta o una diferencia de cuenta se consideran inválidas.

Plazo de validez

Otra forma de abordar el problema de la disponibilidad de datos de extracción de usuarios es almacenar los datos en otro lugar fuera de la cadena de bloques. Esto plantea un problema sutil, ya que rollup aún necesita asegurarse de que los datos estén disponibles en otro lugar. Tradicionalmente, se han utilizado otras cadenas de bloques para este propósito, diseñadas específicamente como una capa de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema de seguridad igualmente fuerte. Cuando los datos se publican directamente en la cadena BTC Bloquear, las reglas de Consenso pueden garantizar que sean 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 verificar que los datos existan en pruebas en cadena de bloques. En última instancia, esto es un problema de Máquina de oráculo. La cadena de bloques de BTC no puede verificar completamente nada que ocurra fuera de su propia cadena de bloques, lo mejor que puede hacer es verificar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup contenidos en el bloque después de la generación realmente se difunden públicamente. No puede verificar si la información externa realmente se hace pública para todos.

Esto abre la puerta a los ataques de retención de datos, es decir, la creación de compromisos para publicar datos y su uso 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 sistemas fuera de BTC.

Dilema

Esto ha creado un dilema para rollup. 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 de 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 de BTC como capa de disponibilidad de datos establece un límite máximo para la escalabilidad de rollup. El espacio de bloque 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 bloque 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 ese sentido.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos elimina el límite máximo de escalabilidad, 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 el uso de Validiums, esta garantía depende completamente de la capacidad del sistema externo utilizado 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 un Bloquear en lugar de transmitirlo realmente, 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, logrando verdaderamente retiros unilaterales de los usuarios?