Escrito por: Investigación de Chakras
Además de la solución de expansión nativa mencionada en el primer volumen, otra ruta de expansión para Bitcoin utiliza una capa adicional de protocolo además de Bitcoin, llamada Capa 2. Los dos puntos más críticos de la solución de Capa 2 son el puente bidireccional seguro y la herencia de la seguridad de consenso de Bitcoin.
Cadena lateral
El origen del concepto de cadena lateral se remonta a "Habilitación de innovaciones blockchain con cadena lateral vinculada" presentado por blockStream en 2014. Es un plan de expansión relativamente simple.
principio de funcionamiento
La cadena lateral es una cadena de bloques que funciona de forma completamente independiente de la cadena principal. Tiene su propio protocolo de consenso y puede utilizarse como campo de pruebas para la innovación de la cadena principal. Cuando ocurre un evento maligno en la cadena lateral, el daño se limita completamente a la propia cadena lateral y no tiene impacto en la cadena principal. La cadena lateral puede utilizar un protocolo de consenso con un TPS más alto para aumentar las capacidades de programación en la cadena y lograr la mejora de BTC.
La cadena lateral puede realizar la transferencia de Bitcoin entre diferentes cadenas de bloques a través de una vinculación bidireccional o unidireccional. Por supuesto, de hecho, BTC solo puede permanecer en la red Bitcoin, por lo que necesitamos un mecanismo de anclaje para hacer la cadena lateral. El BTC de la cadena está conectado al BTC de la red Bitcoin.
La vinculación unidireccional requiere que los usuarios envíen BTC en la red principal a una dirección no disponible para su destrucción, y luego se obtendrá la cantidad correspondiente de BTC en la cadena lateral, pero el proceso no se puede revertir. La vinculación bidireccional es una actualización adicional de la vinculación unidireccional, que permite que BTC se mueva hacia adelante y hacia atrás entre la cadena principal y las cadenas laterales. En lugar de enviarlo a una dirección no disponible para su destrucción, la vinculación bidireccional bloqueará BTC a través de scripts de control, como firmas múltiples y acuñación de nuevos BTC en la cadena lateral. Cuando el usuario quiera regresar a la red principal, el BTC en la cadena lateral se quemará y el B TC originalmente bloqueado se liberará en la red principal.
La implementación de la vinculación unidireccional es mucho más simple que la de la vinculación bidireccional, porque no es necesario administrar el estado relevante en la red Bitcoin, pero los activos de la cadena lateral generados a través de la vinculación unidireccional pueden no tener valor debido a la Falta de mecanismo de anclaje inverso.
Existen diferentes soluciones y diferentes niveles de seguridad para la verificación de transacciones de bloqueo en la cadena principal y transacciones de destrucción en la cadena lateral. La más sencilla es utilizar la verificación externa por parte de participantes con múltiples firmas, pero el riesgo de centralización es alto. Una mejor opción es utilizar SPV Proof para lograr una verificación descentralizada. Por supuesto, dado que la red principal de Bitcoin carece de las capacidades de programación necesarias, no se puede realizar la verificación SPV y solo se pueden elegir otros métodos, generalmente la custodia con múltiples firmas.
Preguntas e ideas
Hay dos problemas principales por los que se critican las cadenas laterales:
La dependencia de los activos entre cadenas de los verificadores: dado que la red principal de Bitcoin aún no puede implementar contratos inteligentes, es imposible manejar la transferencia de activos entre cadenas a través de una lógica de contrato sin confianza al cruzar de la cadena lateral a Bitcoin. , es necesario contar con un grupo de verificadores para completar la operación, existe una presunción de confianza y existe riesgo de fraude.
La cadena lateral no puede heredar la seguridad de la cadena principal: la cadena lateral se ejecuta de forma completamente independiente de la red principal y no puede heredar la seguridad de la red principal. Pueden ocurrir eventos como una reorganización de bloques maliciosa.
En este sentido, las ideas de cadenas laterales incluyen la dependencia de la autoridad (tipo de alianza), la dependencia de la seguridad económica (PoS), la dependencia de los mineros de Bitcoin descentralizados (Merged Mining), la dependencia de los módulos de seguridad de hardware (HSM), la custodia de fondos y la cadena lateral. En Bitcoin, diferentes roles pueden ser responsables de la producción de bloques de la cadena, introduciendo así mecanismos de seguridad más complejos.
Introducción del caso
Líquido
La primera forma de cadena lateral es la cadena lateral de alianza, en la que múltiples entidades seleccionadas de antemano sirven como verificadores y son responsables de la custodia de los fondos principales de la red y la producción de bloques de la cadena lateral.
Liquid es el representante de la cadena lateral de la alianza, con 15 participantes que actúan como verificadores. El método de gestión de la clave privada no se revela y se requieren 11 firmas para la verificación. Los bloques de la cadena lateral de Liquid también son mantenidos conjuntamente por 15 participantes. La cadena de alianza con una cantidad baja de nodos puede lograr un TPS más alto y lograr objetivos de expansión.
El enfoque de la cadena lateral de la alianza tiene importantes riesgos de seguridad centralizados.
Portainjerto (RSK)
RSK también tiene 15 nodos que actúan como custodios de fondos de la red principal y solo se necesitan 8 firmas para la verificación. La diferencia con Liquid es que la clave de firma múltiple es administrada por el módulo de seguridad de hardware HSM, y la instrucción de desconexión se firma de acuerdo con el consenso de PoW para evitar que el verificador que posee la clave manipule directamente los fondos en garantía.
En términos de consenso de la cadena lateral, RSK utiliza Merged Mining para utilizar la potencia informática de la red principal para garantizar la seguridad de las transacciones en la cadena lateral. Cuando la proporción de potencia informática minera fusionada en la red principal es alta, puede prevenir mejor el lado. que la cadena se vea comprometida. Ataque de doble flor. RSK ha realizado mejoras en Merged Mining para garantizar la seguridad de las cadenas laterales con tasas de hash bajas. Adopta un método compatible con la bifurcación para realizar una intervención de consenso fuera de la cadena en el comportamiento de la bifurcación y reducir la probabilidad de doble gasto.
Sin embargo, Merged Mining cambia los incentivos de los mineros e intensifica los riesgos de MEV, lo que en última instancia puede desestabilizar el sistema. A largo plazo, Merged Mining puede aumentar la centralización de la minería.
pilas
Stacks ancla la historia de la cadena Stacks a Bitcoin al enviar el hash de bloque de la cadena lateral al bloque de Bitcoin. Tiene la misma finalidad que Bitcoin. La bifurcación de Stacks solo puede ser causada por la bifurcación de Bitcoin. resistir el doble gasto.
sBTC presenta un nuevo token STX y un modelo de incentivo, utilizando un método de puente de compromiso que permite hasta 150 validadores de la red principal. En el llamado puente de apuestas, los validadores deben apostar tokens STX para obtener permiso para aprobar depósitos y retiros. La seguridad del puente de garantía depende en gran medida del valor de los activos prometidos. Cuando el valor de los activos prometidos fluctúa violentamente, la seguridad de la cadena cruzada de BTC se daña fácilmente. Si el valor de los activos pignorados es menor que el valor de los activos entre cadenas, el validador tiene un incentivo para hacer el mal.
También hay algunas propuestas de cadenas laterales que se están debatiendo ampliamente en la comunidad.
Cadena de transmisión
La que ha llamado más la atención es Drivechain propuesta por Paul Sztorc en 2015. A las tecnologías clave del plan se les ha asignado BIP 300 (mecanismo de clavija) y BIP 301 (minería fusionada a ciegas). BIP 300 define en detalle la lógica de agregar una nueva cadena lateral. Activar una nueva cadena lateral es similar a activar una bifurcación suave a través de señales de minero. BIP 301 permite a los mineros de Bitcoin convertirse en productores de bloques de cadena lateral sin verificar el contenido específico de la transacción.
Los mineros de Bitcoin también son responsables de aprobar las transacciones de retiro. Los mineros primero deben crear una salida OP_RETURN en la transacción de base de monedas del bloque que minaron para proponer una transacción de retiro. Después de eso, cada minero puede votar sobre la propuesta. Puede votar a favor o en contra de la propuesta en cualquier momento. Una vez que una transacción de retiro excede el umbral (13150 bloques), la transacción de retiro se ejecuta oficialmente y la confirma la cadena principal de Bitcoin.
De hecho, los mineros tienen control total sobre los fondos en Drivechain. Si los fondos son robados, los usuarios solo pueden salvarse a través de UASF (soft fork activado por el usuario), pero es muy difícil llegar a un consenso. Además, la posición única de los mineros en Drivechain exacerba los riesgos de MEV, como ya se ha demostrado en Ethereum.
cadena espacial
Spacechain ha adoptado un enfoque diferente, utilizando la vinculación perpetua de 1 vía (P1WP). Los usuarios queman BTC para obtener tokens en Spacechain, omitiendo directamente la cuestión de la seguridad de los fondos. Este token solo se puede utilizar para subastar espacio en bloque en la cadena espacial y no tiene ninguna función de almacenamiento de valor.
Para garantizar la seguridad de la cadena lateral, Spacechain adopta la minería de fusión ciega. Otros usuarios utilizan ANYPREVOUT (APO) para ofertar públicamente por el derecho a construir bloques. Los mineros de Bitcoin solo necesitan confirmar el encabezado del bloque de Spacechain en el bloque. bloque lateral. Sin embargo, el lanzamiento de Spacechain requiere el apoyo de Covanent, y la comunidad Bitcoin todavía está discutiendo la necesidad de una bifurcación suave para agregar el código de operación de Covanent.
En general, Spacechain puede realizar una cadena lateral con las mismas propiedades de descentralización y resistencia a la censura que Bitcoin y más programabilidad a través de la función de ofertar por bloques en Bitcoin.
cadena blanda
Softchain es una propuesta de cadena lateral de 2wp propuesta por el autor de Spacechain, Ruben Somsen. Utiliza el mecanismo de consenso PoW FP para garantizar la seguridad de la cadena lateral. En circunstancias normales, el nodo completo de Bitcoin solo necesita descargar el encabezado del bloque de la cadena suave y verificar la prueba de trabajo. Cuando se produce una bifurcación, descargue el bloque huérfano y el compromiso de conjunto UTXO correspondiente para verificar la validez del bloque.
Para el mecanismo 2wp, durante la vinculación, se crea una transacción de depósito en la cadena principal y se hace referencia a la transacción de la cadena principal en la cadena blanda para obtener fondos; durante la vinculación, se crea una transacción de retiro en la cadena blanda y la transacción de retiro; Se hace referencia a la transacción en la cadena principal para recuperar fondos BTC, y el proceso de retiro debe esperar un largo período de desafío antes de poder completarse. Los mecanismos específicos de entrada y salida requieren soporte de bifurcación suave, por lo que la solución se llama Softchain.
La solución Softchain impone costos de verificación adicionales a todos los nodos de la red principal de Bitcoin. La división del consenso de Softchain puede afectar el logro del consenso de la red principal y convertirse en un posible medio de ataque a la red principal de Bitcoin.
Red relámpago
Lightning Network publicó un documento técnico en 2015 y se lanzó oficialmente en 2018. Como protocolo de pago p2p de capa 2 en Bitcoin, su objetivo es transferir una gran cantidad de transacciones de alta frecuencia y pequeñas cantidades al procesamiento fuera de la cadena. Durante mucho tiempo, se ha considerado la tecnología más avanzada de la red Bitcoin. Un plan de expansión prometedor.
módulo principal
La implementación de Lightning Network es inseparable de varios módulos importantes en Bitcoin, que juntos garantizan la seguridad de las transacciones de Lightning Network.
La primera es la transacción prefirmada. Las transacciones prefirmadas solo se volvieron seguras y disponibles después de la actualización de SegWit. SegWit separa las firmas del resto de los datos de la transacción, resolviendo problemas como posibles dependencias circulares, manipulación de transacciones de terceros y manipulación de transacciones de terceros. La seguridad de la informática bajo la cadena Lightning Network está garantizada por el compromiso irrevocable asumido por la otra parte, y este compromiso se realiza mediante transacciones prefirmadas. Después de recibir la transacción prefirmada de la otra parte, el usuario puede transmitir la transacción a la cadena en cualquier momento para completar el cumplimiento de la promesa.
El segundo es la firma múltiple. Las transferencias frecuentes de fondos fuera de la cadena entre dos partes requieren un operador. Este operador requiere que ambas partes mantengan ciertos derechos de control, por lo que se requieren firmas múltiples. Generalmente se utiliza 2/2 firmas múltiples, lo que garantiza la transferencia de fondos. debe realizarse con el mutuo consentimiento de ambas partes.
Sin embargo, la firma múltiple 2/2 causará problemas de vida, es decir, si la otra parte no coopera, el usuario no puede transferir ningún activo desde la dirección de firma múltiple, lo que resultará en la pérdida de los fondos originales. Los bloqueos de tiempo pueden resolver el problema de la vida. Al firmar previamente un contrato con un bloqueo de tiempo para devolver los fondos, se puede garantizar que incluso si una de las partes queda inactiva, la otra parte pueda recuperar los fondos iniciales.
Finalmente, está el bloqueo hash, que puede conectar múltiples canales de estado y construir una red. La imagen original del hash se utilizará como medio de comunicación para coordinar el funcionamiento correcto de múltiples entidades.
Ejecutar proceso
canal bidireccional
Ambas partes que utilizan Lightning Network para realizar transacciones primero deben abrir un canal de pago bidireccional en Bitcoin. Ambas partes pueden realizar cualquier cantidad de transacciones fuera de la cadena. Una vez completadas todas las transacciones, el estado más reciente se enviará a la cadena de Bitcoin. para completar la liquidación y cerrar el pasillo de pago.
En concreto, la implementación de canales de pago implica los siguientes pasos clave:
Cree una dirección de firma múltiple. Ambas partes del canal primero deben crear una dirección de firma múltiple 2 de 2 como dirección de bloqueo de fondos del canal. Cada parte posee una clave privada de firma y proporciona su propia clave pública.
Inicialice el canal. Ambas partes transmiten una transacción en la cadena y bloquean una cierta cantidad de Bitcoin en la dirección de firma múltiple como fondos iniciales del canal. Esta transacción se denomina transacción "ancla" del canal.
Actualizar el estado del canal. Al realizar un pago dentro del canal, ambas partes actualizan el estado del canal intercambiando transacciones prefirmadas. Cada actualización generará una nueva "transacción de compromiso", que representa el estado actual de la asignación de fondos. La transacción de compromiso tiene dos salidas, correspondientes a las participaciones en fondos de ambas partes.
Transmitir el estado más reciente. Cualquiera de las partes del canal puede transmitir la última transacción de compromiso a la cadena de bloques en cualquier momento para retirar su parte de los fondos. Para evitar que la otra parte transmita el estado anterior, cada transacción de compromiso tiene una "transacción de castigo" correspondiente. Si la otra parte hace trampa, puede obtener todos los fondos de la otra parte.
Cierra el canal. Cuando dos partes deciden cerrar un canal, pueden cooperar para generar una "transacción de liquidación" que transmite el estado final de distribución de fondos a la cadena de bloques. De esta manera, los fondos bloqueados en la dirección de firmas múltiples se liberan a las direcciones personales de ambas partes.
Arbitraje en cadena. Si las dos partes no pueden llegar a un acuerdo al cerrar el canal, cualquiera de las partes puede transmitir unilateralmente la última transacción de compromiso e iniciar el proceso de arbitraje en cadena. Si no hay objeciones dentro de un período de tiempo determinado (como 1 día), los fondos se enviarán a ambas partes de acuerdo con la asignación de la transacción comprometida.
red de pago
Los canales de pago se pueden conectar entre sí para formar una red que admita enrutamiento de múltiples saltos, implementado a través de HTLC. HTLC utiliza el bloqueo de hash como condición directa y el pago con firma con bloqueo de tiempo como condición de respaldo. Los usuarios pueden interactuar con la imagen original con hash antes de que expire el bloqueo de tiempo.
Cuando no existe un canal directo entre dos usuarios, el pago se puede completar con la ayuda de HTLC entre enrutadores. La preimagen hash R juega un papel clave en todo el proceso, asegurando la atomicidad del pago. Al mismo tiempo, el bloqueo de tiempo de HTLC está configurado para disminuir a lo largo del camino, asegurando que cada salto tenga tiempo suficiente para procesar y reenviar el pago.
Problemas
En esencia, Lightning Network evita la suposición de confianza externa del puente de activos a través de canales de estado p2p, al tiempo que utiliza secuencias de comandos de bloqueo de tiempo para proporcionar la máxima garantía de activos y protección contra fallas. Cuando la otra parte pierde actividad y no coopera, se puede completar la retirada unilateral. Por lo tanto, Lightning Network tiene un alto valor en escenarios de pago, pero también tiene muchas limitaciones, entre ellas:
Límite de capacidad del canal. La capacidad del canal de pago en Lightning Network está limitada por los fondos bloqueados iniciales y no puede admitir pagos grandes que excedan la capacidad del canal. Esto puede limitar ciertos escenarios de aplicación, como el comercio de materias primas.
En línea y sincronizado. Para recibir y reenviar pagos de manera oportuna, los nodos de Lightning Network deben permanecer en línea. Si un nodo está fuera de línea durante mucho tiempo, es posible que pierda algunas actualizaciones de estado del canal, lo que hace que el estado no esté sincronizado. Esto puede ser un desafío para los usuarios individuales y los dispositivos móviles, y también aumenta el costo de las operaciones de los nodos.
Gestión de la liquidez. La eficiencia del enrutamiento de Lightning Network depende de la distribución de liquidez de los canales. Si los fondos se distribuyen de manera desigual, algunas vías de pago pueden fallar, lo que afecta la experiencia del usuario. La gestión del saldo de liquidez del canal requiere ciertos costes técnicos y de capital.
Violación de la privacidad. Para encontrar rutas de pago disponibles, el algoritmo de enrutamiento de Lightning Network requiere cierto nivel de conocimiento de la capacidad del canal y la información de conectividad. Esto puede revelar la privacidad de algunos usuarios, como la distribución de fondos, las contrapartes, etc. La apertura y cierre de canales de pago también puede exponer información sobre participantes relevantes.
RGB
La idea original del protocolo RGB se inspiró en los conceptos de verificación del lado del cliente y sellado único propuestos por Peter Todd. Fue propuesto por Giacomo Zucco en 2016. Es un protocolo de segunda capa de Bitcoin escalable y que preserva la privacidad. .
Idea principal
Verificación del cliente
El proceso de verificación de blockchain consiste en transmitir los bloques compuestos de transacciones a todos, permitiendo que cada nodo calcule las transacciones en el bloque y complete la verificación. En realidad, esto crea un bien público, es decir, los nodos de la red ayudan a cada individuo que envía una transacción a completar la verificación, y los usuarios proporcionan BTC como tarifa de manejo como incentivo para ayudar con la verificación. La verificación del lado del cliente está más centrada en el individuo. La verificación de estado no se realiza globalmente, sino que la verifican personas que participan en transiciones de estado específicas. Solo las partes que generan la transacción verifican la validez de la transición de estado. Esto mejora significativamente la privacidad y también la reduce. la carga sobre los nodos y mejora la escalabilidad.
Sello desechable
Existe un peligro oculto en la transición de estado de punto a punto. Si los usuarios no pueden recopilar el historial completo de transición de estado, pueden ser defraudados y gastar dos veces. Para solucionar este problema se propone un sellado desechable que utiliza un objeto especial que solo se puede utilizar una vez para garantizar que no se produzca doble gasto y mejorar la seguridad. UTXO de Bitcoin es el objeto sellado de una sola vez más adecuado, garantizado por el mecanismo de consenso de Bitcoin y la potencia informática de toda la red, por lo que los activos RGB pueden heredar la seguridad de Bitcoin.
Promesa criptográfica
El sello único debe combinarse con el compromiso de cifrado para garantizar que el usuario conozca la transición de estado y evitar la aparición de ataques de doble gasto. El llamado compromiso es informar a otros que algo sucedió y no se puede modificar más adelante, pero no es necesario exponer eventos específicos hasta el momento en que se requiere verificación. Podemos usar una función hash para realizar un compromiso. En RGB, el contenido del compromiso es la transición de estado. A través del gasto de UTXO, el destinatario del activo RGB recibirá la señal de transición de estado y luego verificará el compromiso con los datos específicos transmitidos fuera de la cadena por el gastador. el activo.
Proceso de trabajo
RGB utiliza el consenso de Bitcoin para garantizar la seguridad del doble gasto y la resistencia a la censura, y toda la verificación de las transferencias estatales se transfiere fuera de la cadena y solo la verifica el cliente que acepta el pago.
Para el emisor de activos RGB, se debe crear un contrato RGB al iniciar una transacción, y el compromiso de la información específica se almacenará en el script OP_RETURN de una determinada condición de gasto en la transacción Taproot.
Cuando el titular de un activo RGB quiere gastar, necesita obtener información relevante del destinatario del activo, crear una transacción RGB, confirmar los detalles de la transacción RGB y colocar el valor del compromiso en el UTXO especificado por el destinatario del activo. y emita una transacción que gaste el UTXO original y cree el UTXO especificado por el destinatario. Cuando el destinatario del activo observa que el UTXO que originalmente almacenó el activo RGB se ha gastado, puede verificar la validez de la transacción RGB a través del compromiso en la transacción Bitcoin. Una vez que la verificación es válida, cree que efectivamente ha recibido el activo. Activo RGB.
Para el destinatario de los activos RGB, el pagador debe proporcionar el estado inicial y las reglas de transición de estado del contrato, las transacciones de Bitcoin utilizadas para cada transferencia, las transacciones RGB confirmadas por cada intercambio de Bitcoin y la validez de cada transacción de Bitcoin. verificado por el cliente del destinatario en base a estos datos, verifica la validez de la transacción RGB. Entre ellos, el UTXO de Bitcoin se utiliza como contenedor para guardar el estado del contrato RGB. El historial de transferencia de cada contrato RGB se puede expresar como un gráfico acíclico dirigido. El destinatario del activo RGB solo puede obtener la información relacionada con el RGB. activo que posee y no puede acceder a otras sucursales.
Ventajas y desventajas
Verificación ligera
En comparación con la verificación completa de la cadena de bloques, el protocolo RGB reduce en gran medida el costo de la verificación. Los usuarios no necesitan recorrer todos los bloques históricos para obtener el estado más reciente, solo necesitan sincronizar los registros históricos relacionados con los activos que reciben para verificar. la efectividad de la transacción.
Esta verificación liviana facilita las transacciones entre pares, lo que elimina aún más la necesidad de proveedores de servicios centralizados y aumenta el nivel de descentralización.
Escalabilidad
El protocolo RGB solo hereda la seguridad de Bitcoin a través del compromiso de un hash. A través de los scripts Taproot, casi no hay consumo de espacio adicional en la cadena de Bitcoin, lo que hace posible una programabilidad compleja de los activos. Debido al uso de UTXO como contenedor, el protocolo RGB tiene una concurrencia natural de activos RGB en diferentes ramas de transferencia que no se bloquearán entre sí y se pueden gastar al mismo tiempo.
Privacidad
A diferencia de los protocolos generales, solo el destinatario de los activos RGB puede obtener el estado de transferencia histórico de los activos RGB. Una vez que se completa el gasto, no se puede obtener el estado de transferencia futura, lo que garantiza significativamente la privacidad del usuario. No existe correlación entre las transacciones de activos RGB y la transferencia de Bitcoin UTXO, y otros no pueden obtener rastros de las transacciones RGB en la cadena de Bitcoin.
Además, RGB también admite gastos ciegos y el pagador no puede saber en qué UTXO se pagarán los activos RGB, lo que mejora aún más la privacidad y aumenta la resistencia a la censura.
insuficiente
Cuando los activos RGB cambian de manos muchas veces, los nuevos usuarios que reciben activos se verán obligados a verificar un historial de transferencias prolongado, lo que resulta en una carga de verificación más pesada, el tiempo de verificación puede ser más largo y se pierde la capacidad de confirmar rápidamente. Para los nodos que permanecen ejecutándose en la cadena de bloques, dado que el último estado siempre está sincronizado, el tiempo para recibir la transferencia rápida del estado de verificación de la nueva zona es limitado cada vez.
La comunidad está discutiendo la posibilidad de reutilizar cálculos históricos, y ZK Proof recursivo tiene la oportunidad de lograr una verificación de estado de tamaño y tiempo constante.
Enrollar
Descripción general
Rollup es la mejor solución de expansión a la que ha llegado el ecosistema Ethereum después de años de exploración, desde los canales estatales hasta Plasma y finalmente Rollup.
Rollup es una cadena de bloques independiente que recopila transacciones fuera de la cadena de Bitcoin, empaqueta múltiples transacciones en un lote y las ejecuta, y envía los datos y los compromisos de estado de este lote a la cadena principal, realizando transacciones fuera de la cadena y actualizaciones de estado. Para lograr la máxima expansión, Rollup generalmente utiliza un secuenciador centralizado en esta etapa para mejorar la eficiencia de la ejecución sin perder seguridad, porque la seguridad está garantizada por la verificación de las transiciones de estado de Rollup en la cadena principal.
A medida que madura la solución Rollup del ecosistema Ethereum, el ecosistema Bitcoin también ha comenzado a experimentar con Rollup. Sin embargo, la diferencia más crítica entre Bitcoin y Ethereum es la falta de capacidades de programación y la incapacidad de realizar los cálculos necesarios para construir Rollup en la cadena. Esto hace que la gente actualmente solo intente implementar Rollup soberano y OP Rollup.
Clasificación
Según los diferentes métodos de verificación de la transferencia de estado, el Rollup se puede dividir en dos categorías principales, el Rollup Optimista y el Rollup de Validez (ZK Rollup).
Optimistic Rollup adopta un método de verificación optimista. Durante el período de disputa después de enviar cada lote de transacciones, cualquiera puede verificar los datos fuera de la cadena, plantear objeciones a los lotes de transacciones problemáticos, enviar pruebas de fraude a la cadena principal y perder el secuenciador. Si no hay pruebas de fraude válidas después del período de disputa, el lote de transacciones se considera válido y la actualización del estado se confirma en la cadena principal.
Validity Rollup utiliza Validity Proof para completar la verificación, y Sequencer utiliza un algoritmo de prueba de conocimiento cero para generar una prueba de validez concisa para cada lote de transacciones, lo que demuestra que la transferencia de estado del lote es correcta. Cada actualización debe enviar el lote de transacciones a. la cadena principal prueba de validez, la cadena principal verifica la prueba y luego comprende y confirma la actualización del estado.
La ventaja de Optimistic Rollup es que es relativamente sencillo de implementar y requiere menos modificaciones en la cadena principal. Pero se necesita más tiempo para confirmar las transacciones (dependiendo del período de objeción) y requiere una mayor disponibilidad de datos. Las transacciones de Validity Rollup se confirman rápidamente, no dependen de períodos de objeción y los datos de las transacciones pueden permanecer privados, pero generar y verificar pruebas de conocimiento cero requiere una gran sobrecarga computacional.
Celestia también propuso el concepto de un resumen soberano. Los datos de las transacciones del resumen se publican en una cadena de bloques de capa DA dedicada, que es responsable de la disponibilidad de los datos, y el resumen soberano en sí es responsable de la ejecución y liquidación.
Explorar y discutir
La acumulación de Bitcoin aún se encuentra en sus primeras etapas. Debido a las diferencias entre el modelo contable y el lenguaje de programación y Ethereum, es difícil copiar directamente la experiencia práctica de Ethereum. La comunidad de Bitcoin está explorando activamente soluciones innovadoras.
Resumen de soberanía
El 5 de marzo de 2023, se anunció Rollkit como el primer marco para admitir acumulaciones soberanas de Bitcoin. Los creadores de acumulaciones soberanas pueden publicar datos de disponibilidad de Bitcoin a través de Rollkit.
Rollkit está inspirado en Ordinals y publica datos a través de transacciones Taproot. Una transacción Taproot estándar a través del mempool público puede contener hasta 390 KB de datos, y una transacción Taproot no estándar emitida directamente por un minero puede contener casi 4 MB de datos arbitrarios.
El trabajo real de Rollkit es proporcionar una interfaz para que Rollup soberano lea y escriba datos en Bitcoin, proporcione servicios de middleware a los clientes y convierta Bitcoin en una capa DA.
La idea de una acumulación soberana ha sido recibida con mucho escepticismo, y muchos oponentes afirman que una acumulación soberana de Bitcoin no es más que usar Bitcoin como un tablero de anuncios y es completamente incapaz de heredar la seguridad de Bitcoin. De hecho, si solo envía datos de transacciones a Bitcoin, solo puede mejorar la vida, es decir, todos los usuarios pueden obtener los datos correspondientes para su verificación a través de Bitcoin, pero la seguridad solo puede ser definida por el propio Rollup soberano y no puede heredarse. Además, el espacio en bloque es escaso en Bitcoin, y enviar los datos completos de la transacción puede no ser una buena decisión.
Resumen de operaciones operativas y resumen de validez
Aunque muchos proyectos de segunda capa de Bitcoin se llaman a sí mismos ZK Rollup, que está esencialmente más cerca de un OP Rollup, pero involucra tecnología de Prueba de Validez en el proceso, las capacidades de programación de Bitcoin aún no son suficientes para soportar la verificación directa de Prueba de Validez.
Actualmente, el conjunto de códigos de operación de Bitcoin es muy limitado y ni siquiera puede calcular directamente la multiplicación. La verificación de Validity Proof requiere la expansión de códigos de operación y también depende en gran medida de la implementación de contratos recursivos. Los que actualmente se están discutiendo en la comunidad incluyen OP_CAT, OP_CHECKSIG. OP_TXHASHetc. Por supuesto, si pudiéramos agregar un OP_VERIFY_ZKP directamente, tal vez no necesitaríamos ninguna otra modificación, pero obviamente esto es poco probable. Además, las limitaciones en el tamaño de la pila también obstaculizan los esfuerzos para verificar la prueba de validez en los scripts de Bitcoin, y se están explorando muchos intentos.
Entonces, ¿cómo funciona la prueba de validez? La mayoría de los proyectos publican la declaración y la prueba de validez de los lotes de transacciones en Bitcoin en forma de inscripciones y utilizan BitVM para una verificación optimista. BitVM Bridge reemplaza aquí la solución tradicional de firmas múltiples. El operador de Bridge formará una alianza de N personas para programar los depósitos de los usuarios. Antes de que los usuarios realicen un depósito, la alianza deberá firmar previamente el UTXO que se generará para garantizar que el depósito solo pueda ser cobrado legalmente por el Operador. Después de obtener la prefirma, BTC se bloqueará en una dirección Taproot de firma múltiple N/N.
Cuando un usuario emite una solicitud de retiro, Rollup enviará la Prueba de validez con la raíz de retiro a la cadena Bitcoin. El Operador primero cubrirá las necesidades de retiro del usuario de su propio bolsillo y luego verificará la validez a través del contrato BitVM. Si cada Operador cree que el certificado es válido, se le reembolsará mediante firma múltiple; siempre que alguien crea que hay fraude, se llevará a cabo un proceso de impugnación y se eliminará a la parte equivocada.
En realidad, este proceso es el mismo que OP Rollup. La suposición de confianza es 1/N. Siempre que un verificador sea honesto, el protocolo es seguro.
Sin embargo, puede haber dificultades en la implementación técnica de esta solución. En el proyecto OP Rollup de Ethereum, Arbitrum se ha desarrollado durante muchos años, y la prueba de fraude actual todavía la envían nodos autorizados. Optimism anunció recientemente que es compatible con la prueba de fraude, lo que demuestra lo difícil que es implementarlo.
En cuanto a la operación prefirmada en el puente BitVM, con el apoyo de Bitcoin Covanent se puede implementar de manera más eficiente, lo que aún está esperando el consenso de la comunidad.
En términos de atributos de seguridad, al enviar el hash del bloque Rollup a Bitcoin, se obtiene la resistencia a la reorganización y al doble gasto, y el uso del Puente Optimista trae un supuesto de seguridad 1/N. Sin embargo, la resistencia a la censura del puente aún puede. esperar a que mejore el desarrollo.
Conclusión: la capa 2 no es una panacea
Al observar tantas soluciones de Capa 2, podemos encontrar fácilmente que cada solución está limitada en las tareas que puede realizar. Bajo ciertos supuestos de confianza, los efectos que la Capa 2 puede lograr dependen en gran medida de la Capa 1, es decir, las capacidades nativas de Bitcoin.
Sin las actualizaciones de SegWit y los bloqueos de tiempo, Lightning Network no se puede construir con éxito sin las actualizaciones de Taproot, los compromisos RGB no se pueden enviar con éxito sin OP_CAT y otros Covanent, el Validity Rollup en Bitcoin no se puede construir con éxito...
Muchos Bitcoin Maxi creen que Bitcoin nunca debe cambiarse y que no se deben agregar nuevas características. Todos los defectos deben resolverse mediante la Capa 2. Esto es imposible. La Capa 2 no es una panacea. Necesitamos una Capa 1 más poderosa para construir una Capa 2 más segura, eficiente y escalable.
En el próximo artículo, presentaremos intentos de mejorar la programabilidad en Bitcoin, así que estad atentos.
