Los rollups se han convertido últimamente en el foco narrativo de la ampliación de Bitcoin, convirtiéndose en lo primero que realmente “roba el centro de atención” de Lightning Network en términos de una mayor participación mental. Los rollups pretenden ser una capa dos fuera de la cadena que no está sujeta ni restringida por las limitaciones de liquidez que son fundamentales para Lightning Network, es decir, los usuarios finales requieren que alguien les asigne (o “preste”) fondos con anticipación para poder para recibir dinero, o nodos de enrutamiento intermediarios que requieren saldos de canales que puedan facilitar el movimiento del monto del pago desde el remitente hasta el receptor.
Estos sistemas se desarrollaron originalmente para funcionar en Ethereum y otros sistemas completos de Turing, pero últimamente el enfoque se ha desplazado a migrarlos a cadenas de bloques basadas en UTXO, como Bitcoin. Este artículo no discutirá el estado actual de las cosas que se implementan actualmente en Bitcoin, pero sí discutirá la función de un paquete acumulativo idealizado que la gente busca a largo plazo dependiendo de las características que Bitcoin actualmente no admite, es decir, la capacidad de verifique las pruebas de conocimiento cero (ZKP) en Bitcoin directamente.
La arquitectura básica de un rollup es la siguiente: una sola cuenta (o en el caso de Bitcoin, UTXO), mantiene los saldos de todos los usuarios en el rollup. Este UTXO contiene un compromiso en forma de raíz merkle de un árbol merkle que se compromete con todos los saldos actuales de las cuentas existentes en el resumen. Todas estas cuentas están autorizadas mediante pares de claves públicas/privadas, por lo que para proponer un gasto fuera de la cadena, un usuario aún debe firmar algo con una clave. Esta parte de la estructura permite a los usuarios salir sin permiso cuando lo deseen; simplemente al crear una transacción que demuestre que su cuenta es parte del árbol merkle, pueden salir unilateralmente del paquete acumulativo sin el permiso del operador.
El operador del rollup debe incluir un ZKP en las transacciones que actualizan la raíz merkle de los saldos de las cuentas en la cadena en el proceso de finalizar las transacciones fuera de la cadena; sin este ZKP la transacción no será válida y, por lo tanto, no se podrá incluir en la cadena de bloques. Esta prueba permite a las personas verificar que todos los cambios en las cuentas fuera de la cadena fueron autorizados adecuadamente por el titular de la cuenta y que el operador no ha realizado una actualización maliciosa de los saldos para robar dinero de los usuarios o reasignarlo a otros usuarios de manera deshonesta.
El problema es que, si solo la raíz del árbol merkle se publica en la cadena donde los usuarios pueden verla y acceder a ella, ¿cómo pueden colocar su rama en el árbol para poder salir sin permiso cuando quieran?
Resúmenes adecuados
En un resumen adecuado, la información se coloca directamente en la cadena de bloques cada vez que se confirman nuevas transacciones fuera de la cadena y el estado de las cuentas acumuladas cambia. No el árbol completo, eso sería absurdo, sino la información necesaria para reconstruirlo. En una implementación ingenua, el resumen de todas las cuentas existentes en el resumen tendría saldos y cuentas simplemente agregados en la transacción que actualiza el resumen.
En implementaciones más avanzadas, se utiliza una diferencia de equilibrio. Esto es esencialmente un resumen de a qué cuentas se les ha agregado o restado dinero durante el transcurso de una actualización. Esto permite que cada actualización acumulativa solo incluya el cambios a los saldos de cuentas que se produzcan. Luego, los usuarios pueden simplemente escanear la cadena y “hacer los cálculos” desde el comienzo del resumen para llegar al estado actual de los saldos de las cuentas, lo que les permite reconstruir el árbol merkle de los saldos actuales.
Esto ahorra una gran cantidad de gastos generales y espacio de bloqueo (y, por lo tanto, dinero) y al mismo tiempo permite a los usuarios garantizar el acceso a la información necesaria para salir unilateralmente. La inclusión de estos datos en un resumen formal que utiliza la cadena de bloques para ponerlos a disposición de los usuarios está obligada por las reglas del resumen, es decir, una transacción que no incluye el resumen de la cuenta o la diferencia de la cuenta se considera una transacción no válida.
Validaciones
La otra forma de manejar el problema de la disponibilidad de datos para que los usuarios los retiren es colocar los datos en otro lugar además de la cadena de bloques. Esto introduce problemas sutiles; el resumen aún debe exigir que los datos estén disponibles en otro lugar. Tradicionalmente se utilizan otras blockchains para este propósito, diseñadas específicamente para funcionar como capas de disponibilidad de datos para sistemas como rollups.
Esto crea el dilema de que las garantías de seguridad sean igual de sólidas. Cuando los datos se publican directamente en la cadena de bloques de Bitcoin, las reglas de consenso pueden garantizar que sean correctos con absoluta certeza. Sin embargo, cuando se publica en un sistema externo, lo mejor que puede hacer es verificar una prueba SPV de que los datos se publicaron en otro sistema.
Esto implica verificar una certificación de que existen datos en otras cadenas, lo que en última instancia es un problema de Oracle. La cadena de bloques de Bitcoin no puede verificar nada completamente excepto lo que ocurre en su propia cadena de bloques, el mejor lo que puede hacer es verificar un ZKP. Sin embargo, un ZKP no puede verificar que un bloque que contiene datos acumulativos haya sido realmente transmitido públicamente después de su producción. No puede verificar que la información externa esté realmente disponible públicamente para todos.
Esto abre la puerta a ataques de retención de datos, en los que se crea un compromiso con los datos que se publican y se utiliza para avanzar en el resumen, pero los datos en realidad no están disponibles. Esto hace que los fondos de los usuarios estén más allá de su capacidad de retiro. La única solución real a esto es depender completamente del valor y la estructura de incentivos de sistemas completamente externos a Bitcoin.
El rock y el lugar duro
Esto crea un dilema en términos de acumulaciones. Cuando se trata del problema de la disponibilidad de datos, existe esencialmente una elección binaria entre publicar los datos en la cadena de bloques de Bitcoin o en otro lugar. Esta elección tiene enormes implicaciones tanto para la seguridad como para la soberanía de los rollups, así como para su escalabilidad.
Por un lado, el uso de la cadena de bloques de Bitcoin para la capa de disponibilidad de datos introduce un límite estricto en la cantidad de acumulaciones que se pueden escalar. Hay una cantidad limitada de espacio de bloques, y eso pone un límite superior a la cantidad de paquetes acumulativos que pueden existir al mismo tiempo y a cuántas transacciones pueden procesar todos los paquetes acumulativos en conjunto. fuera de cadena. Cada actualización acumulativa requiere un espacio de bloque proporcional a la cantidad de cuentas que han tenido cambios de saldo desde la última actualización. La teoría de la información solo permite comprimir los datos hasta cierto punto, y en ese punto ya no hay potencial para aumentar las ganancias.
Por otro lado, el uso de una capa diferente para la disponibilidad de datos elimina el techo rígido para las ganancias de escalabilidad, pero también introduce nuevos problemas de seguridad y soberanía. En un paquete acumulativo que utiliza Bitcoin para la disponibilidad de datos, literalmente no es posible que el estado del paquete cambie sin que los datos que los usuarios necesitan para retirar se publiquen atómicamente en la cadena de bloques. Con Validiums, esa garantía depende completamente de la capacidad de cualquier sistema externo que se utilice para resistir los juegos y la retención de datos.
Cualquier productor de bloques en el sistema de disponibilidad de datos externo ahora es capaz de mantener como rehenes los fondos de los usuarios de Bitcoin al producir un bloque y no transmitirlo para que los datos estén disponibles.
Entonces, ¿cuál será, si alguna vez llegamos a una implementación acumulativa ideal en Bitcoin que realmente permita el retiro unilateral del usuario? ¿La roca o el lugar duro?
