Drivechains permite a los operadores de nodos de cadena lateral pagar a los mineros para minar, ¡y más!

Este es un editorial de opinión de Shinobi, un educador autodidacta en el espacio de Bitcoin y presentador de podcasts de Bitcoin orientado a la tecnología.

Esta vez voy a desglosar y discutir cómo funcionan las cadenas de transmisión; se propusieron inicialmente en 2015. De todas las propuestas discutidas hasta ahora, las cadenas de transmisión son las más antiguas y las más desarrolladas en términos de detalles de implementación y diseño específicos, documentados en BIP. 300 y 301. Paul Sztorc, el creador del concepto, tenía en mente algunos objetivos principales de diseño y, aunque esto no es del todo completo, aquí hay algunos:

• Aísle cada cadena lateral para que cualquier falla o problema solo afecte a quienes la usan.
• Permita que las cadenas laterales giren sin necesidad de una nueva bifurcación para cada una.
• Habilite la transferencia de bitcoin dentro y fuera de una cadena lateral con una vinculación bidireccional.
• Permita la experimentación gratuita en el diseño que espera que haga obsoleta la necesidad de altcoins.

Hay dos aspectos principales de todo el diseño, por lo que hay dos BIP separados. El primero es el mecanismo de clavija (BIP300), que es lo que permite que funcione la clavija bidireccional. Sztorc diseñó algo llamado depósito de tasa de hash, que, en los términos más básicos, permite a los mineros como un grupo amorfo custodiar colectivamente las monedas en todas las cadenas laterales. El segundo es un esquema de minería fusionado "ciego", donde el objetivo es permitir que los mineros de bitcoin sean los productores de bloques a un nivel de consenso sin que se requiera validar la cadena lateral para hacerlo. Ambas piezas juntas presentan un mecanismo de vinculación bidireccional y una forma para que los mineros de bitcoin participen en la minería de las cadenas laterales mientras intentan mitigar el riesgo de centralización que presenta.

BIP300 especifica la lógica para la propuesta de una nueva cadena lateral, la activación de una nueva cadena lateral, la propuesta de un conjunto de retiros agrupados, la aprobación de dicho conjunto de retiros, la lógica de validación para transacciones de retiro reales y la validación para transacciones de depósito.

La activación de una nueva cadena lateral bajo la propuesta de la cadena de transmisión es muy similar al proceso de una bifurcación suave activada a través de la señalización del minero. La principal diferencia es, por supuesto, que en realidad no es una bifurcación suave: una sola bifurcación para activar las reglas de consenso de la cadena de transmisión permite a los mineros, en cualquier momento, señalar para activar una nueva cadena lateral. dentro de reglas de consenso de la cadena de transmisión. Para proponer la activación de una nueva cadena lateral, un minero debe colocar datos OP_RETURN en la salida de su base de monedas que incluya un identificador único para esa cadena lateral, una clave pública para usar en operaciones de depósito, datos de versión, descripciones legibles por humanos y hashes del cliente de software. y el historial de GitHub (no hay una aplicación de consenso aquí, solo datos para que los humanos hagan referencia).

Cuando un minero propone activar una nueva cadena lateral e incluir todos los datos necesarios en su base de monedas, se convierte en una especie de período de "señalización del minero" sobre si crear o no esta nueva cadena lateral desde el punto de vista del consenso de la cadena principal. Un minero puede usar un formato especial para incluir una propuesta en sus salidas de base de monedas, y otros mineros pueden crear otra salida siguiendo un segundo formato para señalar la activación. Una nueva propuesta de cadena lateral requiere que el 90% de los bloques en un período de dificultad señalen la activación para que se confirme la creación de una nueva cadena lateral. Esto crea el mecanismo de clavija para habilitar la cadena lateral, pero la interacción entre la cadena lateral y la cadena principal tiene más matices que eso.

En este punto, cualquiera puede colocar monedas en la cadena lateral. Para conectarse a la cadena lateral, un usuario simplemente crea una transacción de dos entradas con su propia entrada y el UTXO correspondiente al saldo de la cadena lateral con una única salida que asigna todo a la cadena lateral. Esto garantiza que la cadena lateral solo tenga un único UTXO que contenga todos los fondos bloqueados en él. Los retiros se manejan mediante la votación de los mineros. La cadena principal no comprende quién posee qué en la cadena lateral, y la cadena principal considerará válido cualquier retiro aprobado por los mineros dentro del mecanismo de votación. Debido a esto, hay un largo retraso en el proceso de retiro. Hay dos fases en el proceso de retiro de una cadena lateral: una propuesta de retiro (paquete) y luego la fase de votación de retiro. Los mineros deben crear una salida OP_RETURN en su transacción de base de monedas con un hash de la transacción de retiro propuesta para proponer un retiro. Este hash, sin embargo, similar a sighash, marca solo el compromiso con una parte de una transacción en lugar de con la totalidad. No se compromete con la entrada UTXO que representa fondos bloqueados en una cadena de transmisión o la salida que devuelve todo lo que no se retira a una cadena lateral especial UTXO. Esto se debe a que cualquier depósito en la cadena de transmisión crearía un nuevo UTXO y, por lo tanto, invalidaría el compromiso con la transacción de retiro cuando las personas fueran a validarlo.

A partir de aquí, comienza el período de votación de los mineros sobre la propuesta de retiro. Una vez que se ha propuesto un paquete, los mineros pueden votar si lo aprueban o no. Cada bloque que se extrae permite que el minero incremente un contador de aprobación, hacia arriba o hacia abajo en uno o dos para abstenerse de hacer cualquier cosa. Existen algunas limitaciones específicas además de esto, porque es posible tener más de un paquete para una sola cadena lateral: si un minero elige votar "sí" (aumentar el contador en uno) por un paquete de retiro para una cadena lateral, entonces debe vote "no" (baje el contador en uno) por cada otro paquete asociado con esa cadena lateral específica.

Esto es para garantizar que no haya "retiros dobles", donde alguien tiene una salida en múltiples paquetes que le pagarían más bitcoins en la cadena principal de lo que se les debe.

Por otro lado, los mineros también pueden votar no por cada paquete propuesto. Se supone que esto funciona como una especie de alarma para todos de que un minero que valida estos retiros (asegurándose de que sean monedas de propiedad legítima en la cadena lateral que se retira) ha notado que sucede algo no válido. Recuerde, un punto clave de este diseño es que los mineros no tienen que validar nada en la cadena lateral, por lo que, a menos que elijan hacerlo de todos modos, muchos mineros pueden estar votando paquetes que no están verificando. Esta función de alarma está diseñada para que reciban una alerta de que deben verificar los paquetes para asegurarse de que no se produzca un retiro fraudulento.

Una vez que un paquete ha alcanzado el umbral requerido (13,150 90 bloques, o aproximadamente 2017 días), la transacción que realmente procesa el retiro se vuelve válida y puede confirmarse. Pero, ¿qué hace la gente si los mineros aprueban un retiro fraudulento que roba dinero de la cadena lateral? La propuesta de Sztorc es participar en una bifurcación suave activada por el usuario (UASF) para invalidar la transacción de salida no válida. Esto presenta un gran riesgo en términos de consenso para la cadena principal. El UASF en XNUMX fue un movimiento de alto riesgo que apenas tuvo éxito y Bitcoin era mucho más pequeño de lo que es hoy. Cuanto más crezca Bitcoin, más difícil será coordinar tales acciones.

Si recuerdas de la artículo sobre cadenas espaciales, ese diseño se basó en la minería fusionada ciega (BMM). El diseño BMM de Ruben Somsen es en realidad la segunda variante de eso, siendo el primero el diseño de Sztorc como se establece en BIP301. La especificación BMM en las cadenas de transmisión se compone de dos mensajes: un mensaje de solicitud y un mensaje de aceptación. Ambos se coordinan respectivamente a través de un tipo de transacción especial en la cadena principal y una salida especial en la transacción de base de monedas de un minero.

La transacción de solicitud la construye quienquiera que esté creando bloques de cadena lateral. El objetivo de BMM es que esta persona puede ser alguien que no esté minando, por lo que la transacción de solicitud está ahí para permitirles pagar a los mineros para confirmar su bloque de cadena lateral propuesto. La propuesta de bloque de cadena lateral construye una transacción que incluye el hash del bloque de cadena lateral, el ID asignado a la cadena lateral cuando se creó y los últimos cuatro bytes del encabezado del bloque de cadena principal anterior. Hay tres reglas de consenso adicionales que se aplican a este tipo de transacciones. Primero, una transacción de solicitud no es válida a menos que también haya una salida de aceptación coincidente en la transacción de base de monedas de ese bloque. Esto es para garantizar que los mineros no puedan cobrar una tarifa de la solicitud sin aceptar y extraer también el bloque de la cadena lateral. En segundo lugar, para cada cadena lateral solo se permite incluir una transacción de solicitud en un bloque de cadena principal. Esto es para garantizar que solo se pueda extraer un bloque de cualquier cadena lateral por bloque de cadena principal. Por último, los últimos cuatro bytes del bloque de la cadena principal anterior deben coincidir. Esto garantiza que una solicitud solo sea válida para ser extraída en el siguiente bloque, y dichas transacciones no se pueden extraer más tarde y robar dinero de un proponente de bloque de cadena lateral después de que se haya extraído el bloque de otra persona.

La salida de aceptación es muy simple: datos del encabezado del mensaje y el hash del bloque de la cadena lateral. Si un minero está ejecutando un nodo de cadena de transmisión, simplemente puede ignorar las transacciones de solicitud y siempre incluir su propia salida de aceptación en su base de monedas para extraer sus propios bloques de cadena lateral. Juntos, estos dos aspectos permiten a los mineros operar un nodo de cadena lateral ellos mismos u otro no minero para hacerlo y pagarle al minero para extraer sus bloques. La idea es que, si los propios mineros no ejecutan las cadenas laterales y consumen los costos adicionales de validación, alguien más puede hacerlo por ellos. Si hay competencia entre los no mineros que intentan ganar tarifas en la cadena lateral, es probable que sigan subiendo la tarifa que están dispuestos a pagar a los mineros en su transacción de solicitud hasta que represente la mayoría de las tarifas que ganan, con los no mineros. el minero solo se queda con un pequeño porcentaje de las ganancias y paga el resto a los mineros.

Esa es la mecánica detrás de cómo funcionan las cadenas de transmisión. A continuación, cadenas laterales federadas, y luego, un desglose de todos los aspectos negativos y negativos que puede tener cada diseño.

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.