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.
En el próximo artículo que analiza diferentes diseños de implementación de cadenas laterales, vamos a revisar cadenas blandas. Este es otro de Rubén SomsenLas propuestas de un mecanismo de cadena lateral. Esto difiere mucho de las cadenas espaciales, el diseño cubierto en mi artículo anterior. Requiere un cambio específico en el protocolo Bitcoin Core específicamente estructurado para implementar una cadena lateral, impone un nuevo costo de validación en los nodos completos de Bitcoin y tiene soporte para un mecanismo de vinculación bidireccional que no depende de una federación para custodiar fondos.
El bloque de construcción
El núcleo de la idea se basa en una propuesta anterior de Somsen llamada Pruebas de fraude PoW, un mecanismo para mejorar la seguridad de la verificación de pago simplificada (SPV) para billeteras. La idea se basa en una simple observación sobre una cadena de bloques: si se produce un bloque no válido, es probable que haya una bifurcación en la cadena de bloques, ya que cualquier minero honesto que exista se negará a construir sobre el bloque no válido y eventualmente extraerá uno válido. Un bloque no válido que se produce y ningún tenedor creado por mineros honestos significa esencialmente que ha habido una falla completa en el proceso de consenso de la red, por lo que las probabilidades estadísticas de que eso suceda son insignificantemente pequeñas. Por lo tanto, la aparición de una bifurcación puede verse como una especie de señal de que “Oye, algo podría haber sucedido aquí, así que deberías revisar esto”. Los clientes podrían usar bifurcaciones como esta como una especie de alarma de que deberían descargar estos bloques y verificar lo que está sucediendo.
Sin embargo, esto presenta un problema fundamental: para verificar un bloque, debe tener un conjunto UTXO. Para tener un conjunto UTXO, debe haber verificado todos los bloques anteriores en la cadena para construirlo. Entonces, ¿cómo funciona esto como un mecanismo SPV? La respuesta son los compromisos establecidos por la UTXO.
Cada bloque debe validarse con el conjunto UTXO, una base de datos de cada bitcoin que existe que aún no se ha gastado y actualmente es solo una base de datos local que cada nodo construye y guarda a medida que escanea la cadena de bloques desde el principio. Un compromiso de conjunto UTXO toma el conjunto UTXO, crea un árbol de Merkle e idealmente confirma el hash dentro de cada bloque. Esto le permite recibir un bloque con algunos datos adicionales (una rama de Merkle para cada entrada de cada transacción que demuestre que estaba en el último compromiso establecido de UTXO) y verificarlo de esa manera. Si un sistema utilizó un esquema de compromiso de este tipo desde el principio, y en realidad fue utilizado por una gran cantidad de usuarios que verificaron completamente la cadena, entonces proporcionarían una garantía de seguridad casi equivalente a un nodo completo. Cada vez que ocurre una división en cadena, puede descargar todos los bloques involucrados y asegurarse de que la cadena que está siguiendo sea válida. Si ambos lados de la división son válidos, el más largo sigue ganando. Sin embargo, si uno de ellos no es válido, esto le permitirá detectarlo de inmediato.
La clavija bidireccional
Como parte del diseño de la cadena de software, los nodos de la cadena principal tendrían que descargar y validar los encabezados de bloque para cada cadena de software y, en el caso de cualquier cadena dividida, descargar y validar esos bloques utilizando los compromisos del conjunto UTXO. Esto formaría la base del mecanismo de pegout para habilitar un peg de dos vías. Para migrar monedas a la cadena lateral, el usuario crearía una transacción de cadena principal asignándolas a una cadena blanda específica y luego señalaría esa transacción cuando se confirme para reclamar monedas en la cadena lateral. Por el contrario, haría lo contrario al intentar salir de la cadena lateral. Aquí es donde entran en juego las pruebas de fraude PoW. Durante un pegout, la idea es crear una transacción en la cadena principal que haga referencia a una transacción de retiro en la cadena lateral. Esas monedas no se podrían gastar hasta después de una ventana de confirmación larga (digamos un año) y permanecerían “bloqueadas en la cadena blanda” si la transacción de retiro en la cadena lateral se reorganizara o se descubriera que no es válida. Esto último se descubriría porque, en el caso de una división en cadena, el nodo de la cadena principal descargará todos los bloques a cada lado de la división y los verificará mediante compromisos establecidos de UTXO.
La ventana de confirmación larga para las clavijas es para que incluso un pequeño porcentaje de mineros honestos pueda tener tiempo suficiente para producir un solo bloque válido que divida la cadena y active una validación de todo desde ese punto con compromisos establecidos por UTXO. Esto permite que los nodos de la cadena principal detecten clavijas de salida fraudulentas de la cadena lateral antes de que se confirme el retiro en la cadena principal, lo que invalida esa transacción sin exigirles que validen toda la cadena lateral, lo que no sería diferente a un aumento del tamaño del bloque.
Parámetros de seguridad y riesgos
Este diseño crea algunas preguntas en términos del nivel de seguridad basado en ciertas variables y cómo una cadena lateral de este tipo interactuaría con los mineros. En primer lugar, cualquier cadena de software debe implementarse con un requisito de dificultad mínima para los bloques, de modo que si la tasa de hash es demasiado baja en lugar de la dificultad para ajustarse por debajo de este mínimo, los bloques en la cadena lateral simplemente tomarían más tiempo para encontrarlos, es decir, el intervalo de bloque sería aumentar. Esto es necesario debido a que los nodos de la cadena principal de validación a prueba de fraude de PoW deben realizarse como parte de este diseño. Si la dificultad de la cadena blanda es demasiado baja, sería fácil para los mineros bifurcar maliciosamente la cadena blanda de forma regular y realizar de manera efectiva un ataque de denegación de servicio (DoS) contra los nodos de la cadena principal al aumentar la cantidad de datos adicionales que obtienen. hay que validar.
La minería fusionada es una solución a este problema. Si todos los mineros de Bitcoin también minaron bloques en la cadena lateral, entonces el problema de los ataques DoS en la cadena principal mediante la creación de divisiones en la cadena blanda se resuelve tan bien como puede ser. Requeriría tanto trabajo dividir la cadena blanda como la cadena principal, evitando ataques arbitrarios y de bajo costo para aumentar la cantidad de datos necesarios para validar la cadena principal. Sin embargo, al resolver el problema del ataque DoS, crea otro problema: aumenta el costo de validación de los mineros.
Si los mineros también van a extraer las cadenas blandas, entonces deben ejecutar los nodos para asegurarse de que los bloques que están extrayendo sean válidos. Si no lo son, corren el riesgo de quedarse huérfanos y perder los ingresos por tarifas de un bloque no válido. Si se activaran muchas cadenas blandas costosas de verificar, como las cadenas de clones de Ethereum o las grandes cadenas de bloques, esto podría hacer que la minería fuera más centralizada y costosa para participar. Los mineros tienen que validar una cadena para saber que no están construyendo sobre un bloque no válido. y perder dinero, así que esto no es realmente opcional. Encarecer la validación socava los esfuerzos por maximizar la descentralización de la minería.
El mayor problema es el riesgo de que un error de consenso en una cadena blanda cause una división por consenso de la propia cadena principal. Existe el riesgo de que las principales reorganizaciones de la cadena lateral invaliden una transacción de clavija de salida válida en el lado de la cadena lateral justo cuando el lado de la cadena principal está a punto de volverse válido. Recuerde, los nodos de la cadena principal también siguen los encabezados de la cadena blanda. Esto podría conducir a la división de la cadena principal si diferentes partes de la red están en diferentes lados de una división de cadena blanda justo cuando se valida una conexión de cadena lateral en la cadena principal. Los errores de consenso no deterministas en la cadena blanda también podrían causar una división de la cadena principal, es decir, si algunos nodos consideraran que un conector no es válido pero otros lo consideraron válido.
Esta conexión más profunda con el consenso de la cadena principal hace que este diseño de cadena lateral sea algo arriesgado y potencialmente algo que no debería hacerse. Como mínimo, las cadenas blandas deben activarse una a la vez en bifurcaciones individuales, en lugar de implementar una sola bifurcación que permitiría girar las cadenas blandas a voluntad. El hecho de que en este diseño las divisiones en cadena hagan que los nodos de la cadena principal verifiquen más datos hace que la capacidad de simplemente activar muchas cadenas blandas a la vez sea un vector de ataque en la cadena principal.
Las cadenas blandas se involucran más en la capa de consenso de la cadena principal que las cadenas espaciales, lo que conlleva muchos riesgos, pero permiten una vinculación bidireccional nativa y, por lo tanto, más espacio potencial para diferentes casos de uso. A continuación, repasaré las cadenas de transmisión y luego algunas reflexiones finales sobre las cadenas laterales en general.
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.
