Las cadenas laterales federadas son la implementación de cadena lateral actualizable original de Bitcoin

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.

Cadenas laterales federadas son actualmente el único tipo implementado de cadena lateral de Bitcoin (el documento más reciente esta página). La idea de utilizar un sistema federado de paridad y consenso era en realidad un apéndice en el documento técnico original sobre las cadenas laterales. No había un diseño concreto para ningún tipo de vinculación bidireccional que involucrara a los mineros, por lo que una vinculación federada se describió como una forma de implementar una cadena lateral ahora y actualizar a una vinculación verificada bidireccional utilizando pruebas de verificación de pago simple (SPV) similares a qué cadenas blandas hacer, cuando algo fue diseñado concretamente que era seguro y desplegable. También se señaló que, en términos de incentivos, para sistemas muy pequeños podría ser peligroso usar una vinculación basada en mineros, ya que podrían robarle a un grupo muy pequeño de personas sin mucho consenso sobre cómo hacer algo al respecto del sistema Bitcoin más amplio. . Las federaciones podrían ser útiles para sistemas más pequeños donde el grupo de usuarios no es lo suficientemente grande como para desincentivar a los mineros a robar monedas.

La idea general es tener efectivamente una cadena de bloques en la que un grupo seleccionado de partes confiables custodie bitcoin vinculado al sistema usando multisig y produzca los bloques en la cadena lateral, firmándolos con claves criptográficas en lugar de usar prueba de trabajo. Todo el modelo de seguridad se basa en tener un conjunto decentemente grande de distintos participantes en el grupo o federación, que están muy distribuidos geográficamente y son conocidos públicamente.

Las federaciones utilizan un umbral de miembros tanto para la custodia de bitcoin en la cadena principal como para la firma de bloques, es decir, un multigrado 5 de 7. Esto se hace en lugar de exigir que los siete miembros firmen para equilibrar los dos riesgos principales de dicho sistema: robo versus pérdida. La federación en conjunto puede robar todos los fondos bloqueados en una cadena lateral federada si deciden cooperar juntos para hacerlo; es por eso que todo el modelo de seguridad se basa en muchos actores diferentes en muchas jurisdicciones legales diferentes. Desea que sea extremadamente difícil e improbable que muchos gobiernos diferentes cooperen para obligar a una federación a hacer algo malicioso, por lo que desea que se necesite una gran cantidad de personas para firmar las cosas. Por otro lado, si requiere que los siete miembros firmen todo, entonces todo lo que se necesita es que un solo miembro pierda el acceso a sus claves para provocar la pérdida permanente de todos los fondos en la cadena lateral. Por lo tanto, se requiere que firme la mayoría de los miembros, pero no todos. Esto deja cierto margen de error para la pérdida de claves y, al mismo tiempo, requiere que se coaccione a un gran número de miembros o que conspiren para provocar un robo de fondos.

Esto hace que el modelo de seguridad del sistema sea bidireccional en términos de umbrales de seguridad. Como se indicó anteriormente, para que los fondos sean robados activamente, cinco de los siete participantes en esta situación hipotética deben coludirse o ser obligados a coludirse para robar los fondos de la cadena lateral. Sin embargo, solo tres de los siete participantes deben perder, destruir o ser obligados a deshabilitar sus claves para dejar los fondos de la cadena lateral congelados y sin poder moverlos, posiblemente de forma permanente. Los umbrales son un acto de equilibrio entre estos dos riesgos.

Ambos deben ser simultáneamente lo suficientemente altos para que sea poco probable que ocurran los peores casos.

Aparte de estas propiedades principales, hay un alto grado de libertad en la forma en que podría implementar una cadena lateral federada, tanto en términos de cómo diseñar la cadena lateral en sí como en cómo manejar la gestión de claves para la firma de bloques y las claves de custodia de clavijas.

Líquido

Liquid fue la primera cadena lateral federada implementada en Bitcoin, diseñada para transacciones privadas entre intercambios para el comercio y la emisión de otros activos como monedas estables o tokens de acciones. Su código base se basa casi en su totalidad en el propio Bitcoin. Una de las características centrales de la red Liquid fue la implementación de Transacciones confidenciales, una función que utiliza pruebas de rango criptográfico para ocultar los montos que se envían en las transacciones, pero aún así brinda una garantía bajo ciertas suposiciones de que no se gasta dinero que no existe. Líquido también implementado Activos confidenciales, una extensión de Transacciones confidenciales. Los activos confidenciales ocultan qué token se gasta además de la cantidad.

Estas dos características combinadas brindan una solución sólida a una de las grandes deficiencias posibles con una cadena lateral federada: la censura. Una mayoría mínima (en nuestra federación hipotética de 5 de 7 anterior) podría estar de acuerdo en censurar transacciones específicas o UTXO si todos tuvieran motivos para hacerlo, como actividad ilegal sospechosa o confirmada. En tal caso, incluso tendrían un incentivo racional para hacerlo, para no dar a los gobiernos una razón para ir tras todo el sistema. Las transacciones/activos confidenciales pueden proporcionar un nivel de privacidad lo suficientemente alto como para que, incluso si una federación tiene motivos para censurar ciertos tipos de transacciones, tendría muchas dificultades para identificarlos.

Una transacción de vinculación en Liquid es un proceso de dos pasos relativamente simple. Un usuario que desea conectarse toma la dirección multisig de la federación y luego "modifica" cada clave pública involucrada en ella usando pago por contrato con una dirección Liquid que controlan, para crear nuevas claves públicas. Los miembros de la federación pueden derivar las claves privadas coincidentes una vez que conocen la dirección de Liquid utilizada. Hasta que se revele esa información, nadie, ni siquiera la federación, sabe que una transacción a esta dirección modificada es una vinculación de Liquid. Luego, el usuario transmite la transacción en la cadena principal y espera 100 confirmaciones. Una vez que se han acumulado las confirmaciones, el usuario puede enviar una transacción en la red de Liquid para enviarse sus monedas a sí mismo. Esta transacción utiliza una entrada especial que contiene la dirección de Liquid con la que ajustaron las claves de la federación, una firma que prueba que la controlan y una prueba de Merkle que muestra que la transacción de conexión de la cadena principal tiene al menos 100 confirmaciones.

El proceso de peg-out es mucho más simple. Un usuario construye una transacción que quema bitcoin en Liquid usando OP_RETURN, contiene una dirección para enviar a la cadena principal y una prueba especial de conocimiento cero de uno de los miembros de la federación (cual está oculta). Cuando los miembros de la federación vean una transacción de este tipo con una prueba de miembro válida, firmarán un retiro en la cadena principal. La prueba se implementa para evitar retiros fraudulentos o inválidos y permite que cualquier miembro de la federación proporcione la prueba para hacer cumplir la lista blanca o las restricciones en los peg-outs. Cualquiera puede vincular bitcoin libremente a la red de Liquid, pero se requiere una relación con un miembro de la federación para realizar la vinculación.

En términos de administración de claves y manejo de la seguridad, Blockstream desarrolló módulos de seguridad de hardware (HSM) para manejar las claves y realizar operaciones de firma. Estos dispositivos protegen las claves utilizadas para la firma de bloques y las entradas y salidas de clavijas, manteniéndolas seguras contra la manipulación o la extracción de claves. Con el fin de proporcionar algún medio de recuperación en caso de que los dispositivos fallidos pierdan claves, pero también para proteger contra la extracción de claves con fines maliciosos, las copias de seguridad de cada clave de miembro se mantienen encriptadas de manera que requieren que tanto ese miembro como Blockstream cooperen para descifrar la clave para cargarla en un nuevo HSM. Ninguna de las partes puede descifrar la copia de seguridad por su cuenta. Una última línea de defensa contra la pérdida de claves son las claves de retiro de emergencia. Cada dirección a la que la federación barre las monedas conectadas tiene dos caminos de gasto: el umbral requerido de la federación, y después de aproximadamente un mes de bloqueo de tiempo (aunque el período de tiempo podría cambiarse) el umbral requerido de las llaves de emergencia. Se trata de un segundo juego de claves que puede mantener la federación, otra parte o una combinación de ellas para garantizar que las monedas se puedan recuperar si se pierden demasiadas claves de la federación. La federación mueve regularmente las monedas en la cadena principal bajo su custodia antes de que expire el bloqueo de tiempo, por lo que mientras la federación no haya fallado, esta ruta de emergencia nunca se podrá gastar. Actualmente Blockstream mantiene las claves de recuperación que están distribuidas geográficamente.

Por último, hay una funcionalidad llamada "Federaciones dinámicas". Esto permite que una gran mayoría de la federación actualice la membresía, agregando o eliminando miembros. Esto se hace a través de una actualización de software para el software de firma después de decidir qué nuevos miembros agregar o eliminar y luego un período de señalización de un mes. Si, durante un mes, las cuatro quintas partes de los bloques señalaron el cambio de federación, la red se “bifurca” para reconocer a la nueva federación como firmantes del bloque. Luego, la red comienza a usar nuevas direcciones de conexión con la nueva federación, pero sigue reconociendo las antiguas durante un mes adicional para garantizar que no se invaliden conexiones durante el cambio de federación. Tampoco está permitido eliminar a tantos miembros de la federación que no queden suficientes para firmar retiros de direcciones antiguas. Todos estos aspectos de las actualizaciones de la federación son parte de las reglas de consenso y los HSM los aplican o validan.

Raíz (RSK)

Rootstock es una cadena lateral federada con muchas diferencias de diseño frente a Liquid. En primer lugar, es esencialmente un clon de copiar y pegar de Ethereum en términos de funcionalidad. Es totalmente compatible con Solidity, el lenguaje de secuencias de comandos utilizado por Ethereum, por lo que cualquier contrato implementado en Ethereum es fácilmente transferible a Rootstock. La razón para hacer esto es, obviamente, que Ethereum tiene mucha demanda y puede ofrecer una funcionalidad de la que Bitcoin no es capaz. Obviamente, existen muchas desventajas y riesgos en la arquitectura de Ethereum, pero no se puede negar que existe demanda.

Otra diferencia importante en términos de arquitectura es lo que hace la federación: administran colectivamente un multisig que custodia los fondos en la cadena principal, pero la federación en circunstancias normales no participa en la acuñación de bloques. Esto lo hacen los mineros de Bitcoin a través de la minería fusionada, lo que les permite extraer Bitcoin y Rootstock al mismo tiempo. Si bien esto no proporciona una diferencia de seguridad significativa para Bitcoin vinculado a la cadena Rootstock, proporciona algo para otros activos emitidos en la cadena lateral. La federación siempre puede robar el Bitcoin en la cadena principal si hay suficiente colusión, pero debido a que los mineros realmente extraen la cadena lateral, puede continuar y permitir que se sigan negociando los otros activos. Si esos otros activos tienen suficiente valor, incluso sin estar respaldados por bitcoin real, el token Rootstock BTC aún debería tener suficiente demanda en el mercado para pagar tarifas para utilizar otros activos para incentivar a los mineros a seguir extrayendo.

Sin embargo, la participación de los mineros no es absoluta. Siempre que la mayoría de los mineros de Bitcoin también extraigan Rootstock, tienen el control total de la organización de transacciones y la extracción en bloques, pero si ese porcentaje de mineros cae al rango de la mitad (o un poco menos), existen reglas de consenso que permiten la federación para firmar puntos de control evitando reorganizaciones antes del punto de control. Si la tasa de hash cae más drásticamente que eso, incluso son capaces de hacerse cargo como firmantes de bloque, como los miembros de la federación de Liquid. Es un sistema muy dinámico que puede funcionar tanto sin mineros como sin la federación para que la cadena de bloques siga avanzando.

El proceso de vinculación es muy simple: envíe bitcoins a la dirección de vinculación de RSK y luego espere suficientes confirmaciones. Después de que se hayan acumulado suficientes confirmaciones, un contrato inteligente de Solidity en la cadena lateral reconocerá la transacción y la acreditará en una cuenta en la cadena lateral controlada por la misma clave a la que estaba bloqueado el UTXO que conectó. La vinculación también está controlada por un contrato inteligente, que se comunicará con los HSM de la federación, que firmarán una transacción de retiro de la cadena principal cuando así lo indique el contrato.

Cuando Roostock lanzó por primera vez, todo lo que se requería para conectarse era que la mayoría de los HSM de la federación firmaran la transacción después de que el contrato inteligente en la cadena lateral se lo indicara. En 2020 implementaron un nuevo mecanismo de vinculación llamado POWPeg. Esta actualización permitió a los HSM validar las pruebas SPV de los mineros. Los HSM ahora se niegan a firmar transacciones de conexión saliente a menos que la mayoría del conjunto actual de mineros de RSK se base en la transacción desde el inicio de la conexión saliente. En última instancia, el modelo de seguridad se reduce a que los HSM permanezcan seguros, pero a menos que la mayoría de ellos sean manipulados y se extraigan las claves, no firmarán sin una prueba de trabajo suficiente que certifique las conexiones.

Cerrar

La gente ha estado trabajando en el diseño de cadenas laterales durante ocho años, y mientras nosotros han ido a través de cuatro diferentes diseños (y hay algunos más por ahí: estos son solo los que han ganado terreno entre los Bitcoiners técnicos), actualmente no hay nada implementado excepto cadenas federadas. Es posible que los sistemas federados no sean la cadena lateral sin confianza que mucha gente quiere, pero siguen siendo sistemas muy útiles, especialmente en cualquier contexto donde la única forma de satisfacer la demanda del mercado es confiar en un único custodio para arbitrar algo. Las federaciones se convierten inmediatamente en una mejora predeterminada al distribuir el riesgo de contraparte entre varios jugadores.

Bueno, eso es cadenas laterales federadas en pocas palabras. El último artículo que viene a continuación analiza todas las desventajas y aspectos negativos de las principales propuestas actuales, al menos algunas ideas de alto nivel sobre lo que la gente realmente quiere de una cadena lateral "perfecta" y cómo lograrlo potencialmente.

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.