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

Rollups ha sido el foco de atención en la escalabilidad de BTC recientemente, convirtiéndose en la primera cosa en robar el protagonismo a Lighting Network y captar una atención más amplia. Rollups tiene como objetivo convertirse en una segunda capa fuera de la cadena (off-chain) que no está limitada o restringida por la liquidez central de Lighting Network, lo que significa que los usuarios finales necesitan que alguien les asigne (o 'preste') fondos con anticipación para poder recibir dinero, o que los nodos de enrutamiento necesitan tener saldo en los canales para facilitar el flujo completo de los pagos desde el remitente hasta el destinatario.

Estos sistemas se ejecutaron inicialmente en Ethereum y otros sistemas Turing completo, pero recientemente se ha centrado en portarlos a cadenas de bloques basadas en UTXO (como BTC). Este artículo no pretende discutir la situación actual de la implementación en BTC, sino discutir las características idealizadas de Rollup que la gente ha estado buscando durante mucho tiempo, lo que depende de la capacidad de BTC para verificar directamente la Prueba de conocimiento cero (ZKP), una función que actualmente no es compatible con BTC.

La estructura básica de Roll es la siguiente: una única cuenta (UTXO en BTC) que guarda 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 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, y así pueden salir de Rollup unilateralmente sin necesidad de permiso del operador.

El operador de Rollup debe incluir un ZKP en la transacción para actualizar la raíz Merkle del saldo de la cuenta on-chain durante la completa de la transacción off-chain. Sin este ZKP, la transacción sería inválida y no se podría incluir en la cadena de bloques. Esta prueba permite a las personas verificar si todos los cambios en la cuenta off-chain 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 Merkle en la cadena, los usuarios pueden verlo y acceder a él, pero ¿cómo colocan sus ramas en el árbol para poder salir sin permiso cuando lo deseen?

Rollup adecuado

En un Rollup adecuado, cada vez que se confirma una nueva transacción off-chain y cambia el estado de la cuenta Rollup, la información se coloca directamente en la cadena de bloques. No es el árbol completo, eso sería absurdo, sino la información necesaria para reconstruir el árbol. En una implementación sencilla, el resumen de todas las cuentas existentes en el Rollup contendrá el saldo, y las cuentas solo se agregarán en las transacciones que actualicen el Rollup.

En implementaciones más avanzadas, use diferencias de saldo. Básicamente, esto es un resumen de 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 escanear simplemente 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 una gran cantidad de gastos y espacio de Bloquear (lo que ahorra fondos), mientras que aún permite a los usuarios garantizar el acceso a la información requerida para la salida unilateral. Las reglas de rollup requieren que estos datos se incluyan en el rollup oficial proporcionado a los usuarios utilizando la cadena de Bloquear, lo que significa que las transacciones que no contienen resúmenes de cuenta o diferencias de cuenta se consideran inválidas.

Fecha de caducidad

Otra forma de abordar el problema de la disponibilidad de datos de retiro de usuarios es colocar los datos en otro lugar fuera de la cadena de Bloquear. Esto plantea problemas sutiles, ya que rollup todavía debe garantizar que los datos estén disponibles en otro lugar. Tradicionalmente, otras cadenas de Bloquear se utilizan con este propósito, especialmente diseñadas como capas de disponibilidad de datos para sistemas como rollup.

Esto ha creado un dilema de seguridad igualmente poderoso. Cuando los datos se publican directamente en la cadena de bloques de Bitcoin, las reglas de consenso pueden garantizar que estén absolutamente correctos. Sin embargo, cuando se publican en sistemas externos, lo mejor que pueden hacer es verificar una prueba SPV, es decir, que los datos se hayan publicado en otro sistema.

Esto requiere la validación de que los datos existen en otras pruebas on-chain, que es en última instancia un problema de Máquina de oráculo. La cadena de bloques de BTC no puede validar completamente cualquier cosa que no ocurra en su propia cadena de bloques, lo mejor que puede hacer es validar ZKP. Sin embargo, ZKP no puede verificar si los datos de rollup en la cadena de bloques, una vez generados, 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 con los datos publicados y utilizarlos para avanzar en el rollup, pero los datos en realidad no están disponibles. Esto hace que los usuarios no puedan extraer fondos. La única solución real es depender completamente del valor y la estructura de incentivos de sistemas diferentes 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 entre publicar 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, utilizar la cadena de bloques Bitcoin como capa de disponibilidad de datos establece un límite máximo en la escalabilidad de rollup. El espacio en bloque es limitado, lo que establece un límite en la cantidad de rollup que puede existir a la vez y en la cantidad total de transacciones que se pueden procesar off-chain en todos los rollup. Cada actualización de rollup requiere un espacio en 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 que los datos se compriman hasta cierto punto, y en este punto, no hay más potencial de escalabilidad.

Por otro lado, el uso de diferentes capas para lograr la disponibilidad de datos eliminará el límite rígido de ganancia de escalabilidad, pero también plantea 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 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 hace 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?