Spacechains: cómo funciona esta nueva propuesta de cadena lateral de Bitcoin

Nodo de origen: 1544330

Spacechains es una cadena lateral de Bitcoin propuesta que ofrece un mecanismo de vinculación unidireccional que utiliza un diseño de mina de combinación ciega.

La idea de las cadenas laterales como mecanismo de escalado y extensión de funciones para Bitcoin es un concepto muy antiguo. Una especie de idea básica de "ancestro" de las cadenas laterales, fusionar cadenas minadas, incluso se remonta a antes de que Satoshi desapareciera.

Esa propuesta era simplemente la idea de dos cadenas completamente separadas y no relacionadas siendo explotadas por el mismo grupo de mineros, sin capacidad para mover nada entre cadenas. los propuesta original de cadena lateral fue hecho en 2014 por muchas de las personas que fundaron Blockstream literalmente una semana después de la publicación del artículo. La idea básica era poder hacer que las monedas se movieran de un lado a otro entre la cadena de bloques principal de Bitcoin y otras cadenas laterales, con pruebas de verificación de pago simple (SPV) que se utilizan para demostrar que las cosas son válidas cuando envía monedas de una cadena a la otra. Esto nunca llegó a buen término debido a las complejidades en la implementación en torno a las reorganizaciones de la cadena, el potencial de robo y los riesgos de la centralización minera (todos los cuales se pueden leer en la sección cuatro de la Papel blanco bitcoin).

Los mecanismos de clavija para las cadenas laterales pueden ser de dos variedades, unidireccionales y bidireccionales. Los significados deberían ser obvios: en una clavija bidireccional, las monedas pueden moverse de un lado a otro entre la cadena principal y la cadena lateral, y en una clavija unidireccional, solo pueden moverse de la cadena principal a la cadena lateral y nunca retroceder. Actualmente, la única forma de vinculación de cadena lateral bidireccional implementada en Bitcoin es a través de un consenso federado, lo que significa que la vinculación está garantizada por un conjunto confiable de "custodios" que mantienen el control de los fondos vinculados a la cadena lateral en una billetera multisig hasta que se retiran.

Sin embargo, la gente ha seguido trabajando en otros diseños para clavijas de cadenas laterales que no están federadas. Aquí voy a repasar la propuesta Spacechain de Ruben Somsen como un ejemplo. Es un mecanismo de clavija unidireccional que utiliza un diseño de mina de combinación ciega, similar a Pablo Stztorc's. Esto significa que las monedas solo pueden entrar en la cadena lateral y nunca salir, y que los mineros no tienen que ejecutar un nuevo software para obtener una compensación por minar la cadena lateral (sin embargo, como explicaré más adelante, pueden beneficiarse más al hacerlo).

La propuesta de la cadena espacial

La minería combinada requiere que los mineros ejecuten los nodos tanto de la cadena Bitcoin como de cualquier otra cadena que estén minando, con el fin de compilar los bloques para ambas cadenas y comprometerse con ellos en el encabezado del bloque Bitcoin que están minando. La minería de combinación ciega aprovecha el hecho de que, en realidad, los mineros de Bitcoin solo necesitan tener el encabezado del bloque de la otra cadena para comprometerse en su bloque de Bitcoin, alguien más puede tomarse la molestia de armar el bloque para la otra cadena.

El mecanismo propuesto por Somsen para esto puede utilizar CUALQUIER PREVOUT (APO) para permitir la competencia abierta para que cualquiera pueda competir para construir el siguiente bloque de la cadena lateral mientras se garantiza que solo se puede comprometer un bloque por bloque de la cadena principal de Bitcoin. Otro beneficio de la propuesta de Ruben es que no requiere una bifurcación suave específica para habilitar la posibilidad de implementar cadenas espaciales. Eltoo/ANYPREVOUT se propone para los beneficios de Lightning Network, lo que permite cadenas de estado flexibles, así como fábricas de canales. Las cadenas espaciales son simplemente otra posibilidad de las muchas cosas para las que habilitar ANYPREVOUT allanaría el camino.

La idea general de su propuesta de minería de fusión ciega es que, al hacer uso de APO, puede predefinir un conjunto largo de transacciones que toman el mismo UTXO inicial y se comprometen a recrearlo siempre. Entonces, imagine un solo UTXO satoshi, con cada transacción creada previamente que garantice que ese mismo UTXO se recrea como una salida cuando se confirma. Piense en ello como una especie de marcador, este UTXO especial es el identificador que permite que cualquiera que mire la cadena de bloques principal de Bitcoin sepa: "Aquí es donde encuentro un compromiso con los bloques de la cadena lateral X". Sin embargo, esto deja abierto un problema: las tarifas de los mineros. Si esa UTXO tiene que ser recreada con la misma cantidad, no hay fondos para pagar las tasas.

Esto puede solucionarse utilizando SUSPIRO_SINGLE (la firma de una entrada solo firma esa única entrada y la salida correspondiente) y SIGHASH_CUALQUIERA PUEDE PAGAR (las personas pueden agregar libremente entradas y salidas adicionales sin invalidar la firma, siempre que la entrada/salida que usa SIGHASH_SINGLE se deje como está, para no invalidar esa firma). Luego, cualquiera puede agregar una entrada y cambiar la salida para pagar las tarifas de los mineros por la transacción.

Este es también el mecanismo que se utiliza para comprometerse con el encabezado del bloque del bloque de la cadena lateral. De la misma manera que Taproot se compromete con el árbol de diferentes condiciones de gasto ajustando la clave pública normal con la raíz de Merkle del árbol, cualquiera puede modificar la clave pública normal con el hash de encabezado de bloque del bloque de cadena lateral. Los nodos de la cadena lateral pueden revelar y transmitir ese encabezado de bloque con un puntero a la transacción en la cadena principal para demostrar que realmente se extrajo. A partir de ahí, los nodos de la cadena lateral harían toda la validación normal para garantizar que el bloque de la cadena lateral siga las reglas de consenso adecuadas y transmitir los bloques reales a través de la red de la cadena lateral al igual que en la cadena principal.

Si una de las transacciones utilizadas para comprometerse con los bloques de la cadena lateral en la cadena principal se usó para comprometerse con un bloque no válido, o incluso con datos completamente basura, cuando los nodos de la cadena lateral vean la transacción de compromiso utilizada en la cadena, pueden suceder dos cosas: una, un bloque no válido se propagará a través de la red de la cadena lateral y, cuando no pase las comprobaciones de validación, quedará huérfano; o dos, los datos nunca se revelan, en cuyo caso el siguiente bloque de la cadena lateral se construirá sobre el último bloque realmente revelado y se comprometerá con él, y se ignorará el compromiso no revelado. Esta segunda posibilidad sigue el mismo tipo de lógica de cadena más larga que la cadena principal, por lo que incluso si se revela algo más tarde, aún quedará huérfano debido a los bloques futuros que no se construyeron sobre él.

Pero aún existe el problema del doble gasto. Cualquier persona con la clave privada utilizada para generar el marcador UTXO podría gastar dos veces cualquiera de las transacciones predefinidas utilizadas para comprometerse con bloques de cadena lateral e invalidar todo el conjunto a partir de ese momento.

Esto se resuelve insertando la firma en el script de bloqueo de la propia UTXO. Esto bloquea la firma en la entrada y salida, garantizando la recreación del marcador UTXO en la próxima transacción que lo use. Debido a que esa firma se aprobará y verificará automáticamente cuando se gaste la UTXO, no es posible simplemente reemplazarla con otra y gastarla en un destino diferente.

Esto deja un último problema pendiente. En teoría, sería posible enviar varias transacciones seguidas en un solo bloque de Bitcoin, de modo que los mineros confirmen una gran cantidad de bloques de cadena lateral en un solo bloque de cadena principal. Se podría abusar de esto para un ataque de denegación de servicio a la red de cadena lateral.

Para resolver este problema, se puede insertar un bloqueo de tiempo relativo CHECKSEQUENCEVERIFY (CSV) en el script del marcador UTXO para garantizar que solo se pueda confirmar una transacción que utilice el marcador UTXO dentro de un solo bloque de cadena principal determinado.

En conjunto se ve así: 

Fuente

También vale la pena señalar que se pueden implementar dos variantes de este diseño con CHECKTEMPLATEVERIFY (CTV) o sin ningún cambio. Estas dos variantes de diseño simplemente tienen compensaciones subóptimas.

La variante de CTV usaría esa funcionalidad para comprometerse con la cadena de transacciones usando CTV en lugar de APO con el truco que incluye la firma dentro del script de bloqueo de UTXO. CTV se compromete con todas las salidas de una transacción que gasta el CTV UTXO, pero no se compromete con ninguna entrada además de sí misma.

Esto significa que puede agregar entradas, pero no salidas, a una transacción de CTV. Por lo tanto, puede traer su propia tarifa como en el diseño APO, pero no puede agregar un compromiso al encabezado del bloque de cadena lateral.

Entonces, lo que debemos hacer aquí es crear una transacción completamente fuera de la cadena de transacciones de CTV para el compromiso de cadena lateral para crear un UTXO que sea suficiente para pagar la tarifa de la transacción de CTV (porque no puede crear una nueva salida de cambio en esa transacción, el 100% de la entrada que agrega se destina a tarifas), y dentro de la transacción que prepara la tarifa UTXO es donde nos comprometemos con un encabezado de bloque de cadena lateral. Entonces, primer paso: una transacción que crea una salida de pago de tarifas y un compromiso con un encabezado de bloque de cadena lateral. Segundo paso: tomamos la salida de la tarifa y la agregamos como entrada a la transacción CTV, que cuando se confirma, "mina" nuestro bloque de cadena lateral específico. Esta variante se ve así:

Fuente

La siguiente variante simplemente usa transacciones prefirmadas. Podría implementarse hoy, pero debido a las limitaciones de lo que puede hacer el script, requiere que todas las tarifas de las transacciones sean pagadas por adelantado por quien crea la cadena espacial.

La cadena de transacciones comienza con un solo UTXO y en una cadena crea dos salidas. El primer resultado es el marcador UTXO, que indica que la cadena de transacciones está relacionada con una cadena espacial específica, el segundo es un UTXO de valor pequeño que cualquier persona puede gastar abiertamente, lo que permite adjuntarle otra entrada/salida. Esta segunda transacción es donde cualquiera puede comprometerse abiertamente para ser el primero en gastar esa segunda salida de la cadena de transacciones de la cadena espacial y usarla para comprometerse con su encabezado de bloque de cadena lateral.

En la variante de CTV, el bloque de cadena lateral tenía que comprometerse en una transacción secundaria porque CTV no permite agregar nuevas salidas en una transacción que gasta una entrada bloqueada por CTV. Esta variante requiere el uso de una transacción secundaria porque si agrega nuevas entradas o salidas a la cadena prefirmada, alteraría el TXID de la transacción e invalidaría todas las transacciones prefirmadas que vienen después. Esta variante se ve así: 

Fuente

La única desventaja de esta última variante es que si quien firmó previamente todas las transacciones para usarlas en los compromisos de bloque de la cadena lateral no elimina las claves privadas que se usaron para hacerlo, puede detener la cadena de manera efectiva gastando el doble del marcador actual UTXO en cualquier momento. tiempo.

Y ahí lo tienes. Esta es la propuesta más reciente para un diseño de cadena lateral en Bitcoin, y se puede implementar de tres maneras diferentes, con la advertencia obvia de que la ruta de implementación que se puede hacer ahora tiene el problema de requerir que alguien elimine una clave privada.

Este artículo es simplemente el primero de una serie relacionada con las principales propuestas de diseño de cadena lateral que se han publicado para Bitcoin desde el diseño original de 2014. Ojo con el resto.

Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.

Sello de tiempo:

Mas de Bitcoin Magazine