Autor: Chakra; Traducción: 0xjs@金财经
Hay muchos caminos para escalar Bitcoin. La primera parte de nuestra serie de artículos ya describió uno de los caminos "Soluciones de escalado nativo de Bitcoin". El otro camino es construir una capa de protocolo adicional sobre Bitcoin, llamada Capa 2. El aspecto más crítico de la solución de 2 capas es el puente bidireccional seguro y la herencia de la seguridad del consenso de Bitcoin.
cadena lateral
El concepto de cadenas laterales se remonta a 2014, cuando Blockstream presentó "Habilitación de la innovación Blockchain con cadenas laterales vinculadas". Representa un método de escalamiento relativamente básico.
¿Cómo funciona la cadena lateral?
Una cadena lateral es una cadena de bloques que opera independientemente de la cadena principal, tiene su propio protocolo de consenso y puede servir como campo de pruebas para la innovación de la cadena principal. Cuando ocurre un evento adverso en la cadena lateral, el daño se limita completamente a la propia cadena lateral sin ningún impacto en la cadena principal. Las cadenas laterales pueden adoptar protocolos de consenso con TPS (transacciones por segundo) más altos, mejorar la programabilidad en la cadena y facilitar una funcionalidad mejorada de BTC.
Las cadenas laterales pueden realizar la transferencia de Bitcoin entre diferentes cadenas de bloques a través de vinculaciones bidireccionales o unidireccionales. Pero en realidad, BTC sólo puede residir en la red principal de Bitcoin, por lo que se necesita un mecanismo de anclaje para vincular BTC en la cadena lateral con BTC en la red principal de Bitcoin.
Las vinculaciones unidireccionales requieren que los usuarios envíen BTC desde la red principal a una dirección no disponible para su destrucción y luego acuñen una cantidad equivalente de BTC en la cadena lateral, pero este proceso es irreversible. Las vinculaciones bidireccionales son una mejora de las vinculaciones unidireccionales, lo que permite que BTC se mueva hacia adelante y hacia atrás entre la cadena principal y las cadenas laterales. En lugar de ser destruido enviándolo a una dirección no disponible, una clavija bidireccional bloquea BTC mediante firmas múltiples u otros scripts de control, acuñando nuevos BTC en la cadena lateral. Cuando el usuario quiera regresar a la red principal, el BTC en la cadena lateral se destruirá y el BTC originalmente bloqueado se liberará en la red principal.
La implementación de una vinculación unidireccional es mucho más simple que una vinculación bidireccional porque no requiere administrar el estado relevante en la red principal de Bitcoin. Sin embargo, los activos de cadena lateral creados mediante vinculaciones unidireccionales pueden no tener valor porque carecen de un mecanismo de vinculación inversa.
Existen diferentes esquemas y niveles de seguridad para verificar las transacciones de bloqueo en la cadena principal y las transacciones de grabación en la cadena lateral. El método más simple es la verificación externa a través de participantes con múltiples firmas, pero esto conlleva altos riesgos de centralización. Una mejor opción es utilizar pruebas SPV para la verificación descentralizada. Sin embargo, dado que la red principal de Bitcoin carece de las capacidades de programación necesarias para realizar la verificación SPV, se deben utilizar otros métodos, generalmente un depósito en garantía de múltiples firmas.
Problemas y métodos.
Las principales críticas a las cadenas laterales incluyen:
1. Los activos entre cadenas dependen de verificadores: dado que la red principal de Bitcoin aún no puede implementar contratos inteligentes, las transferencias de activos entre cadenas no se pueden gestionar mediante una lógica de contrato sin confianza. La devolución de activos de una cadena lateral a Bitcoin se basa en un conjunto de validadores, lo que introduce suposiciones de confianza y riesgos de fraude.
2. Las cadenas laterales no pueden heredar la seguridad de la cadena principal: dado que las cadenas laterales se ejecutan de forma completamente independiente de la red principal, no pueden heredar la seguridad de la red principal, lo que puede provocar una reorganización maliciosa de los bloques.
Para resolver estos problemas, las cadenas laterales han adoptado métodos que incluyen confiar en instituciones autorizadas (federación), seguridad económica (PoS), mineros de Bitcoin descentralizados (minería fusionada) y módulos de seguridad de hardware (HSM). La custodia de fondos en Bitcoin y la producción de bloques en cadenas laterales pueden ser gestionadas por diferentes roles, introduciendo mecanismos de seguridad más complejos.
caso de estudio
Líquido
Una de las primeras formas de cadenas laterales fueron las cadenas laterales federadas, que dependían de un grupo preseleccionado de entidades para actuar como validadores responsables de la custodia de los activos en la red principal y la generación de bloques en la cadena lateral.
Liquid es un ejemplo clásico de cadena lateral federada, con 15 partes que actúan como validadores. La gestión de la clave privada no es pública y la verificación requiere 11 de 15 firmas. Estos 15 participantes también mantienen la producción de bloques en la cadena lateral de Liquid. El menor número de nodos en esta federación da como resultado mayores transacciones por segundo (TPS), logrando así objetivos de escalabilidad, y su principal área de aplicación es DeFi.
Sin embargo, el modelo de cadena lateral federada tiene importantes riesgos de seguridad de centralización.
Portainjerto（RSK）
RSK también es administrado por 15 nodos que son responsables de alojar los fondos de la red principal, y la verificación requiere solo 8 firmas. A diferencia de Liquid, las claves de firma múltiple de RSK se administran mediante un módulo de seguridad de hardware (HSM) y las instrucciones de enlace se firman según el consenso de prueba de trabajo (PoW), lo que evita que los validadores con acceso a claves manipulen directamente los fondos en garantía.
En términos de consenso de la cadena lateral, RSK adopta la minería fusionada y utiliza la potencia informática de la red principal para garantizar la seguridad de las transacciones de la cadena lateral. Cuando una gran parte de la potencia informática de la red principal se utiliza para la minería fusionada, se puede prevenir eficazmente el doble gasto. ataques a la cadena lateral. RSK ha mejorado sobre la base de la minería fusionada. A través del conocimiento de la bifurcación, realiza una intervención de consenso fuera de la cadena en el comportamiento de la bifurcación, garantizando así la seguridad de las cadenas laterales con baja potencia informática y reduciendo la posibilidad de ataques de doble gasto.
Sin embargo, la minería fusionada cambia los incentivos de los mineros, aumenta el riesgo de valor extraíble minero (MEV) y tiene el potencial de desestabilizar el sistema. Con el tiempo, la minería fusionada puede aumentar la centralización de la minería.
pilas
Stacks logra la misma finalidad que Bitcoin al anclar su historial de cadena a Bitcoin mediante el envío de hashes de sus bloques de cadena lateral en bloques de Bitcoin. Las bifurcaciones en Stacks solo pueden ocurrir cuando el propio Bitcoin se bifurca, lo que lo hace más resistente a los ataques de doble gasto.
sBTC presenta un nuevo modelo de token e incentivo que utiliza un puente de participación que permite hasta 150 validadores de la red principal. Los validadores deben apostar tokens STX para obtener acceso a depósitos y retiros aprobados. La seguridad de un puente de participación depende en gran medida del valor de los activos pignorados, lo que representa un riesgo para la seguridad entre cadenas de BTC durante períodos de fluctuaciones significativas de precios en los activos pignorados.
Actualmente se están debatiendo ampliamente en la comunidad otras propuestas de cadenas laterales.
Cadena de transmisión
La más notable de ellas es la propuesta Drivechain de Paul Sztorc en 2015, que dividió las tecnologías clave en BIP 300 (mecanismo de clavija) y BIP 301 (minería de fusión ciega). BIP 300 define la lógica para agregar nuevas cadenas laterales, similar a activar nuevas cadenas laterales a través de señales de minero (como bifurcaciones suaves). BIP 301 permite a los mineros de Bitcoin convertirse en productores de bloques en cadenas laterales sin verificar los detalles específicos de las transacciones.
Los mineros de Bitcoin también son responsables de aprobar las transacciones de retiro. Inician una propuesta de retiro creando una salida OP_RETURN en la transacción coinbase del bloque que minaron. Luego, otros mineros pueden votar sobre la propuesta apoyándola o oponiéndose a ella en cada bloque que minen. Una vez que una transacción de retiro cruza el umbral (13.150 bloques), se ejecuta y confirma en la cadena principal de Bitcoin.
De hecho, los mineros tienen control total sobre los fondos en Drivechain. Si se roban fondos, los usuarios sólo pueden salvarse a través de bifurcaciones suaves activadas por el usuario (UASF), sobre las cuales es difícil llegar a un consenso. Además, la posición única de los mineros en Drivechain aumenta el riesgo de MEV, como se ha demostrado en Ethereum.
cadena espacial
Spacechain adopta un enfoque diferente, utilizando una vinculación unidireccional permanente (P1WP), donde los usuarios destruyen BTC para obtener tokens en Spacechain, evitando por completo la cuestión de la seguridad de los fondos. Estos tokens solo se utilizan para ofertar por espacio de bloque en Spacechain y carecen de funcionalidad de reserva de valor.
Para garantizar la seguridad de la cadena lateral, Spacechain utiliza minería de fusión ciega, donde los usuarios pujan públicamente por el derecho a construir bloques utilizando ANYPREVOUT (APO). Los mineros de Bitcoin solo necesitan enviar encabezados de bloque de Spacechain en sus propios bloques sin validar los bloques de cadena lateral. Sin embargo, el lanzamiento de Spacechain requiere soporte de Bitcoin para Covenants, y la comunidad de Bitcoin todavía está debatiendo si es necesaria una bifurcación suave para agregar el código de operación de Covenant.
En general, Spacechain tiene como objetivo lograr una cadena lateral que sea tan descentralizada y resistente a la censura como Bitcoin, al tiempo que aumenta la programabilidad a través de su función de subasta en bloque.
cadena blanda
Softchain es otra propuesta de cadena lateral de clavija bidireccional (2wp) de Ruben Somsen que utiliza el mecanismo de consenso de PoW FP para asegurar la cadena lateral. En circunstancias normales, los nodos completos de Bitcoin solo necesitan descargar el encabezado del bloque Softchain para verificar la prueba de trabajo. Si se produce una bifurcación, descargan el bloque huérfano y el conjunto de compromisos UTXO correspondiente para verificar la validez del bloque.
Para el mecanismo 2wp, cuando se transfiere la vinculación, se creará una transacción de depósito en la cadena principal, y Softchain se referirá a esta transacción de la cadena principal para obtener fondos cuando se transfiera la vinculación, se creará una transacción de retiro; en Softchain, y la cadena principal cotizará esta transacción para retirar BTC después de un período de desafío más largo. Los mecanismos de enganche específicos de transferencia de entrada y salida requieren soporte de bifurcación suave, por lo que la propuesta se denomina Softchain.
La propuesta de Softchain agrega costos de verificación adicionales a los nodos completos de la red principal de Bitcoin, y la división del consenso dentro de Softchain puede afectar el consenso de la red principal y constituir un posible vector de ataque para Bitcoin.
Red relámpago
El documento técnico de Lightning Network se publicó en 2015 y se lanzó oficialmente en 2018. Como protocolo de pago punto a punto de segunda capa en la red Bitcoin, su objetivo es transferir una gran cantidad de transacciones de alta frecuencia de pequeñas cantidades a fuera de línea. procesamiento en cadena. Siempre se ha considerado el plan de expansión más prometedor de la red Bitcoin.
módulo principal
La implementación de Lightning Network se basa en varios módulos importantes dentro de Bitcoin, que juntos garantizan la seguridad de las transacciones de la red.
En primer lugar, existen transacciones prefirmadas. Estas transacciones se volvieron seguras después de la actualización de SegWit. SegWit separa las firmas del resto de los datos de la transacción, resolviendo problemas potenciales como la maleabilidad de las transacciones y la manipulación de transacciones de terceros y de segundos. La seguridad de los cálculos fuera de la cadena en Lightning Network está garantizada por compromisos irrevocables proporcionados por las contrapartes, que se ejecutan a través de transacciones prefirmadas. Una vez que los usuarios reciben una transacción prefirmada de una contraparte, pueden transmitirla a la cadena de bloques en cualquier momento para cumplir con su compromiso.
Lo siguiente es la firma múltiple. Las frecuentes transferencias de fondos fuera de la cadena entre dos partes requieren un medio controlado conjuntamente por ambas partes, por lo que requieren firmas múltiples, generalmente utilizando un esquema 2 de 2. Esto garantiza que las transferencias de fondos sólo puedan realizarse mediante consentimiento mutuo.
Sin embargo, la multifirma 2 de 2 puede generar problemas de vida en los que, si una de las partes no coopera, la otra parte no puede transferir ningún fondo desde la dirección multifirma, lo que resulta en la pérdida de los fondos originales. Los bloqueos de tiempo pueden resolver el problema de la actividad; al firmar previamente un contrato con un bloqueo de tiempo para la devolución de fondos, puede asegurarse de que incluso si una de las partes está inactiva, la otra aún pueda recuperar los fondos iniciales.
Finalmente, los bloqueos hash se utilizan para conectar múltiples canales estatales, creando un efecto de red. La preimagen hash sirve como medio de comunicación, coordinando operaciones correctas entre múltiples entidades.
flujo de operación
canal bidireccional
Para realizar transacciones utilizando Lightning Network, ambas partes primero deben abrir un canal de pago bidireccional en Bitcoin. Pueden realizar una cantidad ilimitada de transacciones fuera de la cadena y, después de completar todas las transacciones, enviar el estado más reciente a la cadena de bloques de Bitcoin para liquidar y cerrar el canal de pago.
En concreto, la implementación de canales de pago implica los siguientes pasos clave:
1. Cree una dirección de firmas múltiples. Ambas partes primero deben crear una dirección de firma múltiple 2 de 2 como bloqueo de fondos del canal. Cada parte posee la clave privada utilizada para la firma y proporciona su propia clave pública.
2. Inicialice el canal. Ambas partes transmiten una transacción en la cadena, bloqueando una cierta cantidad de Bitcoin en la dirección de firma múltiple como fondos iniciales del canal. Esta transacción se conoce como transacción "ancla" del canal.
3. Actualizar el estado del canal. Al realizar un pago dentro de un canal, ambas partes intercambian transacciones prefirmadas para actualizar el estado del canal. Cada actualización genera una nueva "transacción de compromiso" que representa la asignación actual de fondos. La transacción de compromiso tiene dos salidas, correspondientes a las participaciones en fondos de ambas partes.
4. Transmita el estado más reciente. Cualquier parte puede retirar su parte de los fondos en cualquier momento transmitiendo la última transacción de compromiso a la cadena de bloques. Para evitar que la otra parte transmita un estado obsoleto, cada transacción de compromiso va acompañada de una "transacción de penalización" correspondiente que permite a una parte reclamar todos los fondos de la otra parte si hace trampa.
5. Cerrar el canal. Cuando dos partes deciden cerrar un canal, pueden colaborar para generar una "transacción de liquidación" y transmitir la distribución final de fondos a la cadena de bloques. Esto liberará los fondos bloqueados en la dirección de firma múltiple a las direcciones personales de ambas partes.
6. Arbitraje en cadena. Si ambas partes no pueden ponerse de acuerdo sobre el cierre del canal, cualquiera de las partes puede transmitir unilateralmente la última transacción de compromiso para iniciar un procedimiento de arbitraje en cadena. Si no hay disputa dentro de un cierto período de tiempo (por ejemplo, un día), los fondos se distribuirán a ambas partes de acuerdo con la asignación en la transacción de compromiso.
red de pago
Al utilizar HTLC (Hash Time Lock Contract), los canales de pago se pueden interconectar para formar una red que admita enrutamiento de múltiples saltos. HTLC utiliza el bloqueo de hash como condición directa y el pago de firma con bloqueo de tiempo como condición de respaldo, lo que permite a los usuarios interactuar en función de imágenes previas con hash antes de que expire el bloqueo de tiempo.
Cuando no existe un canal directo entre dos usuarios, los pagos se pueden completar utilizando HTLC a través de rutas de enrutamiento. En este proceso, la preimagen hash R juega un papel crucial para garantizar la atomicidad del pago. Además, los bloqueos de tiempo en HTLC disminuirán a lo largo de la ruta, lo que garantiza que cada salto tenga tiempo suficiente para procesar y reenviar pagos.
Problemas
Fundamentalmente, Lightning Network elude los supuestos de confianza externa del puente de activos a través de canales estatales de igual a igual, al tiempo que aprovecha scripts de tiempo bloqueado para brindar la máxima protección a los activos contra fallas. Esto permite salidas unilaterales en caso de que una contraparte pierda actividad y deje de cooperar. Por lo tanto, Lightning Network es muy práctico en escenarios de pago, pero también tiene varias limitaciones, entre ellas:
1. 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 que excedan la capacidad del canal. Esto puede limitar ciertos casos de uso, como el comercio de materias primas.
2. Requisitos en línea y de sincronización: 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 un período prolongado, es posible que pierda algunas actualizaciones de estado del canal, lo que provocará una desincronización. Esto puede ser un desafío para los usuarios individuales y los dispositivos móviles, y también puede aumentar los costos operativos de los nodos.
3. Gestión de liquidez: la eficiencia del enrutamiento de Lightning Network depende de la distribución de liquidez entre canales. Si los fondos se distribuyen de manera desigual, ciertas vías de pago pueden dejar de ser válidas, lo que afectará la experiencia del usuario. La gestión del saldo de liquidez de un canal requiere ciertos recursos técnicos y financieros.
4. Problemas de privacidad: para encontrar rutas de pago viables, el algoritmo de enrutamiento de Lightning Network necesita conocer un cierto grado de capacidad del canal e información de conexión, lo que puede filtrar la privacidad del usuario, como la asignación de fondos y las contrapartes. La apertura y cierre de canales de pago también puede exponer información sobre los participantes.
RGB
El concepto original del protocolo RGB se inspiró en las ideas de Peter Todd sobre validación del lado del cliente y sellado único. Fue propuesto por Giacomo Zucco en 2016 como un protocolo de segunda capa escalable y que preserva la privacidad para Bitcoin.
Idea principal
Verificación del cliente
El proceso de verificación en una cadena de bloques implica transmitir bloques que consisten en transacciones a toda la red, lo que permite que cada nodo calcule y verifique las transacciones dentro de estos bloques. Esto crea efectivamente un bien público, con nodos en la red que ayudan a cada individuo que envía una transacción con verificación, y los usuarios brindan BTC como tarifa de transacción como recompensa por la verificación. La validación del lado del cliente está más centrada en el individuo y la validación de estado no la realizan globalmente sino que la realizan individuos involucrados en transiciones de estado específicas. Solo las partes que generan la transacción pueden verificar la legitimidad de estas transiciones de estado, lo que mejora significativamente la privacidad, reduce la carga de los nodos y mejora la escalabilidad.
Sello desechable
Las transiciones de estado entre pares son riesgosas y, sin acceso al historial completo de transición de estado, los usuarios pueden ser vulnerables al fraude, lo que resulta en gastos dobles. El sello desechable se propuso para solucionar este problema. Al utilizar objetos especiales que sólo se pueden utilizar una vez, garantizan que no se produzca doble gasto, mejorando así la seguridad. El modelo UTXO (Salida de transacción no gastada) de Bitcoin es la forma más adecuada de sellado único, protegido por el mecanismo de consenso de Bitcoin y el poder de hash de la red, lo que permite que los activos RGB hereden las características de seguridad de Bitcoin.
Promesa criptográfica
Los sellos únicos deben combinarse con compromisos criptográficos para garantizar que los usuarios comprendan claramente las transiciones de estado y eviten ataques de doble gasto. Una promesa de informar a otros que algo ha sucedido y que no se puede cambiar más adelante, sin revelar detalles específicos hasta que se requiera verificación. Esto se puede lograr utilizando funciones hash. En RGB, el contenido de un compromiso es una transición de estado que se señala al destinatario del activo RGB mediante el gasto de un UTXO. Luego, el destinatario del activo verifica el compromiso en función de datos específicos transmitidos fuera de la cadena por el gastador del activo.
Flujo de trabajo
RGB aprovecha el consenso de Bitcoin para garantizar la seguridad del doble gasto y la resistencia a la censura, mientras que todas las tareas de verificación de la transición estatal se delegan fuera de la cadena y las realiza únicamente el cliente que recibe el pago.
Para los emisores de activos RGB, la creación de un contrato RGB implica iniciar una transacción en la que se almacena un compromiso con información específica en un script OP_RETURN dentro de la condición de transacción Taproot.
Cuando el titular de un activo RGB quiere gastarlo, debe obtener la información relevante del destinatario del activo, crear una transacción RGB y enviar los detalles de esta transacción. Luego, el compromiso se coloca en un UTXO especificado por el destinatario del activo y se emite una transacción para gastar el UTXO original y crear un nuevo UTXO especificado por el destinatario. Cuando el destinatario del activo nota que el UTXO que almacena el activo RGB se ha gastado, puede verificar la validez de la transacción RGB a través del compromiso en la transacción de Bitcoin. Una vez que la verificación sea válida, podrán confirmar con confianza la recepción del activo RGB.
Para los destinatarios de activos RGB, el pagador debe proporcionar el estado inicial del contrato y las reglas de transición de estado, cada transacción de Bitcoin utilizada en la transferencia, la transacción RGB enviada para cada transacción de Bitcoin y evidencia de la validez de cada transacción de Bitcoin. El cliente del destinatario utiliza estos datos para verificar la validez de la transacción RGB. En esta configuración, el UTXO de Bitcoin actúa como un contenedor que contiene el estado del contrato RGB. El historial de transferencia de cada contrato RGB se puede representar como un gráfico acíclico dirigido (DAG), y el destinatario de un activo RGB solo puede acceder al historial relacionado con el activo que posee y no a ninguna otra rama.
pros y contras
Verificación ligera
En comparación con la verificación completa requerida por blockchain, el protocolo RGB reduce en gran medida el costo de verificación. Los usuarios no necesitan recorrer todos los bloques históricos para obtener el estado más reciente. Solo necesitan sincronizar el historial relacionado con los activos recibidos para verificar la validez. de la transacción.
Esta verificación liviana facilita las transacciones entre pares y reduce aún más la dependencia de proveedores de servicios centralizados, lo que mejora la descentralización.
Escalabilidad
El protocolo RGB solo requiere un compromiso de hash, hereda la seguridad de Bitcoin y prácticamente no consume espacio de bloque adicional de Bitcoin utilizando scripts Taproot. Esto permite una programación de activos compleja. Al usar UTXO como contenedor, el protocolo RGB naturalmente admite la concurrencia de activos RGB en diferentes ramas de transferencia no se bloquearán entre sí y se pueden usar al mismo tiempo.
privacidad
A diferencia de los protocolos típicos, sólo el destinatario del activo RGB tiene acceso al historial de la transferencia del activo. Una vez utilizados, no tienen acceso al historial de transferencias futuras, lo que garantiza en gran medida la privacidad del usuario. Las transacciones de activos RGB no están asociadas con transferencias de UTXO de Bitcoin, por lo que personas externas no pueden rastrear las transacciones RGB en la cadena de bloques de Bitcoin.
Además, RGB admite salida ciega, lo que significa que los pagadores no pueden determinar a qué UTXO se pagará un activo RGB, lo que mejora aún más la privacidad y la resistencia a la censura.
defecto
Cuando un activo RGB cambia de manos varias veces, el nuevo destinatario del activo puede enfrentar una carga de verificación considerable para verificar el largo historial de transferencias, lo que puede resultar en tiempos de verificación más largos y la pérdida de la capacidad de confirmar transacciones rápidamente. Para los nodos que se ejecutan en una cadena de bloques, el tiempo necesario para verificar una transición de estado después de recibir un nuevo bloque es en realidad limitado, ya que siempre están sincronizados con el último estado.
La comunidad está discutiendo la posibilidad de reutilizar cálculos históricos, y las pruebas ZK recursivas pueden permitir un tiempo y tamaño constantes de verificación del estado.
Enrollar
Descripción general
Rollup es la mejor solución de expansión en el ecosistema Ethereum, derivada de años de exploración desde los canales estatales hasta Plasma, y finalmente evolucionó a Rollup.
Rollup es una cadena de bloques independiente que recopila transacciones fuera de la cadena de Bitcoin, agrupa múltiples transacciones, ejecuta estas transacciones y envía lotes de datos y compromisos estatales a la cadena principal. Esto permite el procesamiento de transacciones fuera de la cadena y actualizaciones de estado. Para maximizar la escalabilidad, Rollup generalmente utiliza un secuenciador centralizado en esta etapa para mejorar la eficiencia de la ejecución sin comprometer la seguridad, ya que la seguridad está garantizada por la verificación de las transiciones de estado de Rollup por parte de la cadena principal.
A medida que la solución Rollup del ecosistema Ethereum se vuelve cada vez más madura, el ecosistema Bitcoin también comienza a explorar Rollups. Sin embargo, una diferencia clave entre Bitcoin y Ethereum es la falta de capacidad de programación para realizar los cálculos necesarios para crear rollups en cadena. Actualmente estamos trabajando principalmente en la implementación de Sovereign Rollups y OP Rollups.
Clasificación
Los paquetes acumulativos se pueden dividir en dos categorías principales: paquetes acumulativos optimistas (acumulados optimistas) y paquetes acumulativos de validez (acumulados ZK). La principal diferencia radica en el método de verificación de la transición de estado.
Optimistic Rollup adopta un método de verificación optimista durante el período de disputa después de que se envía cada lote de transacciones, cualquiera puede ver datos fuera de la cadena, plantear objeciones a los lotes problemáticos y enviar pruebas de error a la cadena principal, penalizando así al secuenciador. Si no se presenta ninguna prueba válida de error dentro 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 la verificación. 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 transición de estado del lote es correcta. Cada actualización requiere enviar una prueba de validez del lote de transacciones a la cadena principal, que verificará la prueba y confirmará inmediatamente la actualización del estado.
La ventaja de Optimistic Rollup es que es relativamente simple y requiere pocas modificaciones en la cadena principal, pero la desventaja es que el tiempo de confirmación de la transacción es más largo (dependiendo del período de disputa) y los requisitos de disponibilidad de datos son mayores. La ventaja de Validity Rollup es que la confirmación de la transacción es rápida, no se ve afectada por el período de disputa y puede garantizar la privacidad de los datos de la transacción, pero generar y verificar pruebas de conocimiento cero requiere una gran sobrecarga computacional.
Celestia también propuso el concepto de acumulaciones soberanas, donde los datos de transacciones de la acumulación se publican en una cadena de bloques de capa de disponibilidad de datos (DA) dedicada, que es responsable de la disponibilidad de los datos, mientras que la acumulación soberana en sí es responsable de la ejecución y liquidación.
Explorar y discutir
Los rollups basados en Bitcoin aún se encuentran en sus primeras etapas. Debido a las diferencias en el modelo contable y el lenguaje de programación de Ethereum, es un desafío copiar directamente 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 compatible con Bitcoin Sovereign Rollups. Los creadores de Rollups soberanos pueden utilizar Rollkit para publicar datos de disponibilidad en Bitcoin.
Rollkit está inspirado en Ordinals y utiliza transacciones Taproot para publicar datos. Las transacciones Taproot que cumplen con los estándares públicos de mempool pueden contener hasta 390 KB de datos, mientras que las transacciones Taproot no estándar publicadas directamente por los mineros pueden contener casi 4 MB de datos arbitrarios.
Básicamente, Rollkit proporciona una interfaz para leer y escribir datos en Bitcoin y proporciona un servicio de middleware para convertir Bitcoin en una capa DA.
La idea de una acumulación soberana fue recibida con considerable escepticismo. Muchos críticos afirman que el Rollup soberano basado en Bitcoin simplemente utiliza Bitcoin como tablero de anuncios y no hereda la seguridad de Bitcoin. De hecho, si solo se enviaran datos de transacciones a Bitcoin, solo aumentaría la actividad, asegurando que todos los usuarios puedan acceder y verificar datos relevantes a través de Bitcoin. Sin embargo, la seguridad solo puede ser definida por el propio Rollup soberano y no puede heredarse. Además, el espacio en bloque es extremadamente valioso en Bitcoin y enviar 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 Bitcoin Layer2 afirman ser ZK Rollups, están esencialmente más cerca de OP Rollups e involucran tecnología Validity Proof. Pero las capacidades de programación actuales de Bitcoin no son suficientes para soportar la verificación directa de Prueba de Validez.
El conjunto actual de códigos de operación de Bitcoin es tan limitado que ni siquiera puede calcular multiplicaciones directamente, y verificar las pruebas de validez requiere ampliar los códigos de operación, lo que depende en gran medida de la implementación de contratos recursivos. La comunidad está discutiendo activamente opciones que incluyen OP_CAT, OP_CHECKSIG, OP_TXHASH, etc. Idealmente, agregar OP_VERIFY_ZKP podría solucionar el problema sin realizar otras modificaciones, pero esto es poco probable. Además, las limitaciones del tamaño de la pila también han obstaculizado los esfuerzos para verificar las pruebas de validez en los scripts de Bitcoin, y muchas exploraciones están en curso.
Entonces, ¿cómo funcionan las pruebas de validez? La mayoría de los proyectos publican discrepancias en las declaraciones y pruebas de validez de las transacciones por lotes a Bitcoin en formato de inscripción y utilizan BitVM para una verificación optimista. En este esquema, el operador del puente actúa como una federación, gestionando los depósitos de los usuarios. Antes de que un usuario realice un depósito, la federación firma previamente el UTXO para garantizar que el depósito solo pueda ser reclamado legalmente por el operador. Una vez prefirmado, BTC se bloquea en una dirección Taproot de firma múltiple N/N.
Cuando un usuario solicita un retiro, Rollup envía la raíz del retiro con prueba de validez a la cadena de Bitcoin. Inicialmente, el operador paga de su bolsillo para satisfacer las necesidades de retiro de los usuarios y luego el contrato de BitVM verifica su validez. Si cada operador cree que la prueba es válida, le reembolsará al operador mediante firma múltiple; si alguien cree que hay fraude, se iniciará un proceso de impugnación y se sancionará a la parte equivocada.
Este proceso es esencialmente el mismo que OP Rollup, donde la suposición de confianza es 1/N: siempre que un validador sea honesto, el protocolo es seguro. En cuanto a la prueba de validez, el propósito no es facilitar la verificación en la red Bitcoin, sino facilitar la verificación para nodos individuales.
Sin embargo, la implementación técnica de esta solución puede enfrentar desafíos. En el proyecto OP Rollup de Ethereum, Arbitrum se ha estado desarrollando durante muchos años, pero su prueba de fraude aún se envía mediante nodos autorizados. Optimismo aún no es compatible con la prueba de fraude, lo que muestra la dificultad de hacerlo. implementación.
Con el apoyo de Bitcoin Covenant, las operaciones de prefirma en el puente BitVM se pueden realizar de manera más eficiente, algo que la comunidad aún debe lograr.
Desde la perspectiva de los atributos de seguridad, al enviar el hash del bloque Rollup a Bitcoin, Bitcoin gana la capacidad de resistir la reorganización y el doble gasto, mientras que Optimistic Bridge aporta un supuesto de seguridad 1/N. También se espera que mejore aún más la resistencia a la censura de Optimistic Bridge.
Conclusión: la capa 2 no es una panacea
Al analizar las distintas soluciones de dos niveles, quedó claro que cada solución tenía sus limitaciones. La eficacia de la Capa 2 depende en gran medida de las capacidades de la Capa 1 (es decir, Bitcoin) bajo ciertos supuestos de confianza.
El establecimiento exitoso de Lightning Network no sería posible sin las actualizaciones de SegWit y los bloqueos de tiempo; las confirmaciones eficientes en RGB no serían posibles sin las actualizaciones de Taproot; los paquetes acumulativos de validez en Bitcoin no serían posibles sin OP_CAT y otros Covenants...
Muchos maximalistas de Bitcoin creen que Bitcoin nunca debería cambiar, que no se deberían agregar nuevas características y que todos los defectos deberían abordarse con una solución de capa 2. Sin embargo, esto no es posible; la capa 2 no es una panacea. Necesitamos una Capa 1 más fuerte para construir una Capa 2 más segura, más eficiente y más escalable.
En nuestro próximo artículo, exploraremos los intentos de mejorar la programabilidad de Bitcoin.
