Así que te han puesto la venda naranja y ahora tienes BTC. Bien por ti, más vale tarde que nunca.
Entonces, oíste el adagio sagrado de esta industria: ni tus llaves, ni tus monedas. Con el agravante de los horrores de varios asaltos y hackeos de CEX, finalmente decidiste autocustodiar tus bitcoins.
Enhorabuena, ahora eres dueño de tu propio destino financiero. Hurra, ¿no?
Te das cuenta de que realizar transacciones en Bitcoin es estúpidamente caro, tan caro que avergonzaría a las notoriamente altas tarifas de Ethereum. Porque, a diferencia de esas malditas ballenas, tú no tienes un millón de dólares en bitcoins para gastar: cada transacción que hagas en la cadena principal te afectará mucho.
¿Y ahora qué? Seguro que tiene que haber una forma mejor.
Abandonar el nido
Cuando posea bitcoins (BTC, la criptomoneda) fuera de Bitcoin (cadena principal, la cadena de bloques), no tendrá la seguridad y protección de la cadena principal, por lo que deberá heredar los supuestos de confianza de la cadena o capa en la que se encuentre, así como el token representativo de BTC que posea (si procede).
Desgraciadamente, este es el trueque iBitnevitable que tendrás que hacer... por ahora.
El objetivo de este artículo es proporcionar una visión general de los distintos enfoques y puentes de escalado que existen, así como esbozar los sacrificios de confianza en los que tendrás que incurrir en cada uno de ellos. Además, expondremos las deficiencias de cada uno, y por qué todavía no existe una solución de escalado de Bitcoin que sea capaz de "exportar" BTC sin comprometer significativamente la seguridad y protección de la cadena principal.
Los términos Bitcoin y mainchain se utilizarán indistintamente. Comencemos.
Red del Rayo
Lanzada en enero de 2018, la Lightning Network es uno de los primeros intentos de escalar Bitcoin. En esencia, la Lightning Network se compone de una red de canales de pago, donde cada canal de pago es fundamentalmente un contrato multisig 2-de-2 (aprovechando HTLCs) entre dos partes en Bitcoin.
Lo que hace que la Red Lightning funcione, es que existen múltiples canales de pago que mantienen una conexión con el peer al que quieres enviar tus bitcoins. Así, aunque no tengas una conexión directa con Bob, siempre que tengas una conexión con Alice (que tiene una conexión con Bob), puedes iniciar el pago desde tu nodo Lightning y pagar a Bob a través de Alice.
En teoría, puedes realizar transacciones con cualquiera siempre que tu contraparte comparta al menos un par mutuo (con suficiente liquidez). De ahí el término "red" en Lightning Network.
tldr
Cuando Bob quiere abrir un canal de pago con Alice, combinan sus claves para generar un contrato multisig 2-de-2, que actuará como dirección del canal. Entonces, Bob transmite dos transacciones: su transacción de compromiso (para gastar sus fondos de vuelta a su monedero de financiación si Alice no responde) y su transacción de financiación (Bob deposita sus bitcoins en el multisig 2-de-2). Del mismo modo, Alice también transmite su transacción de compromiso y su transacción de financiación. Ten en cuenta que es importante que la primera transacción de compromiso esté firmada por ambas partes antes de que nadie financie el canal de pago. Esto es para asegurar que los fondos no se queden atascados en el multisig en caso de que alguna de las partes se desconecte.
Una vez establecido el canal de pago, Bob y Alice son libres de gastar los bitcoins dentro del multisig tantas veces y como consideren oportuno. Cuando "envías" fondos, en realidad estás actualizando la transacción de compromiso compartida que tienes con la otra parte para reflejar el último estado de los balances, invalidando el compromiso anterior. La transacción de compromiso nunca se envía onchain cuando el canal de pago sigue activo, y sólo la conocen Bob y Alice. La transacción de compromiso sólo se publica al cerrarse el canal de pago.
Cuando Bob quiere cerrar un canal (y devolver sus bitcoins a la cadena principal), hay dos maneras de hacerlo: cooperativamente con Alice, o no cooperativamente (cierre forzado). En un cierre cooperativo (camino feliz), tanto Bob como Alice están de acuerdo en su parte de los saldos del multisig, y ambos firman una nueva transacción que gasta los fondos de vuelta a sus respectivas carteras inmediatamente.
Sin embargo, en un escenario de cierre forzado (camino infeliz), Bob o Alice pueden no estar disponibles o no estar dispuestos a firmar cooperativamente la transacción de cierre. En este caso, la parte que inicia el cierre forzoso pasará su saldo a un contrato de arbitraje, permitiendo a su par impugnarlo dentro del retraso del CSV (también conocido como periodo de disputa). En el caso de que esta parte intentara "hacer trampa" (publicando una transacción de compromiso más antigua), su par simplemente publica la transacción de compromiso más reciente, reclamando para sí los fondos de la parte tramposa del contrato de arbitraje.
[lightning.engineering] ilustrado: La reclamación fallida de Bob de cierre forzoso de 8 BTC
Para ilustrarlo, supongamos que Bob y Alice tienen un saldo "real" de 4 BTC y 6 BTC respectivamente (el canal de pago contiene 10 bitcoins en total). Si Bob inicia un cierre forzado y afirma que tiene 8 BTC en el canal de pago (publicando una transacción de compromiso más antigua), Alice puede simplemente publicar la última transacción de compromiso y reclamar los 8 BTC de Bob del contrato de arbitraje. Esto servirá como elemento disuasorio para Bob, asegurando que las partes no necesiten confiar la una en la otra al abrir un canal Lightning.
ni tu nodo, ni tus monedas.
La cuestión con la red Lightning, es que no puedes auto-custodiarte a menos que dirijas tu propio nodo Lightning. De lo contrario, debes depositar tu BTC en un nodo Lightning de confianza para poder utilizar la red, donde tus bitcoins forman parte de su libro mayor interno y realizan transacciones en tu nombre. Si el nodo Lightning que tiene tu depósito se equivoca, entonces tu BTC corre con ellos y no tienes recurso. Esto es básicamente peor que depositar tus bitcoins en un CEX de confianza - quiero decir, ¡al menos estás tratando con Binance o Coinbase!
Si decidieras gestionar tu propio nodo Lightning, tendrías que estar constantemente conectado para vigilar las infracciones del canal por parte de tus compañeros. Aunque puedes asignar nodos Watchtower para que te ayuden a controlar las infracciones (almacenarán los compromisos que se generan en cada transacción que realices en el canal de pago para impugnar los cierres forzados fraudulentos en tu nombre), básicamente vuelves a confiar en entidades centralizadas. De nuevo, ¡también podrías confiar en Binance o Coinbase en lugar de en una empresa de vigilancia aleatoria para salvaguardar tus bitcoins!
[Sam Aiken] ilustrado: la torre de vigilancia LN en acción
Por si lo anterior no fuera suficiente para disuadirte, si diriges tu propio nodo Lightning, entonces tendrás que gestionar manualmente la liquidez de tu propio nodo en relación con tus pares. Por ejemplo, si un canal de pago sólo tiene 10 BTC en total, entonces el saldo máximo que cualquiera de las partes puede mantener entre sí es de 10 BTC. Si quieres realizar una transacción con alguien con quien no tienes una conexión directa, tendrás que confiar en otros nodos Lightning que tengan conexiones tanto contigo como con tu contraparte, también con suficiente liquidez para enrutar el pago. Ahora puedes ver por qué la gestión de la liquidez es muy engorrosa para el corredor de nodos medio.
Por lo tanto, la mayoría de los nodos Lightning simplemente prescinden de esto y se conectan a nodos de enrutamiento, que son nodos Lightning bien capitalizados (muy probablemente gestionados por grandes instituciones) dedicados a enrutar pagos. Se sitúan entre los nodos Lightning como un canal intermediario, actuando como un cuasi-emparejador de pagos en toda la red. Como resultado, la red tiende a la centralización en este sentido: en el momento de escribir estas líneas, los 10 principales nodos Lightning representan más del 75% de toda la capacidad de la red.
[LnRouter.app] Nodos Lightning activos, filtrados por capacidad
Phoenix Wallet, desarrollada por ACINQ, es un intento de simplificar la autocustodia en la Red Lightning para el usuario medio. Al descargar su aplicación de monedero, tu teléfono se convierte automáticamente en tu propio nodo Lightning. Para simplificar la gestión de la liquidez y el enrutamiento de los pagos, tu nodo Lightning se conectará al nodo ACINQ, confiando en ACINQ como router para tus pagos entrantes y salientes.
No obstante, deberá conectarse periódicamente y vigilar que no se produzcan infracciones; de lo contrario, seguirá estando a merced de ACINQ. Por improbable que sea, en el caso de que ACINQ intente forzar el cierre de su canal con un compromiso obsoleto, deberá conectarse para impugnarlo y presentar el compromiso más reciente correcto. De lo contrario, podría perder sus fondos a manos de ACINQ.
conclusión
La Lightning Network está diseñada para los administradores de nodos. En el mundo real, sin embargo, no todo el mundo necesita gestionar su propio nodo, no es realista ni práctico.
Por desgracia, la Lightning Network no está pensada para el usuario medio de BTC que no sea un geek. El hecho de que tengas que ejecutar un nodo solo para mantener la autocustodia, junto con su caso de uso restrictivo de ser estrictamente una red de pagos (no programable para desbloquear de forma nativa casos de uso más ricos como DeFi), relega el protocolo a los márgenes del verdadero Bitcoiner que ejecuta su propio nodo.
Ni tu nodo, ni tus monedas. Y no es ideal para el usuario medio.
Cadenas de estados
Statechains como concepto toma prestado en gran medida de los canales de pago de Lightning, en el que ambos permiten transacciones offchain ilimitadas que finalmente serán "liquidadas" en Bitcoin a su cierre.
tldr
A diferencia de los canales Lightning (que son multisigs 2-de-2), la dirección de depósito UTXO de una statechain es creada completamente offchain por el operador, que es una entidad de confianza que genera key shares tanto para sí misma como para el propietario actual del UTXO. El propietario del UTXO que desea iniciar una statechain colabora con el operador (entidad de confianza) para crear una dirección en la que se forma la clave pública correspondiente a partir de las acciones de clave tanto del primer propietario como del operador. A partir de aquí, el propietario financia la cadena de estado con el UTXO (o bitcoins) y, a continuación, crea una transacción de respaldo (con la colaboración del operador), que es un bloqueo de tiempo que permitirá al propietario reclamar unilateralmente su UTXO cuando expire.
[Nik/Coinmonks] Statechains en acción: transferencia de UTXO de Alice a Bob
Si el propietario actual desea transferir la propiedad del UTXO a un nuevo propietario, el operador simplemente volverá a generar participaciones en claves que equivalgan a la misma dirección de depósito y borrará su participación en claves con el antiguo propietario. Entonces, el nuevo propietario crea una transacción de respaldo (con la cooperación del operador) pero con un timelock más corto. Cada vez que una cadena de estados cambie de manos, el operador borrará la clave compartida anterior y cofirmará la transacción de respaldo del nuevo propietario, que tendrá un bloqueo temporal más corto que el del propietario anterior, es decir, hasta que el bloqueo temporal no pueda acortarse más (lo que obliga a crear una nueva cadena de estados para el nuevo propietario).
De esta forma, el antiguo propietario no puede retirar unilateralmente fondos de la cadena de estados en lugar del nuevo propietario. Porque para salir cooperativamente de la cadena de estados (retirada instantánea), el antiguo propietario necesita que el operador firme conjuntamente su transacción de salida (cosa que el operador ya no puede hacer, ya que ha eliminado su anterior clave compartida que podía firmar conjuntamente la transacción), de lo contrario el antiguo propietario tiene que esperar a que expire su bloqueo temporal para poder enviar su transacción de respaldo. Sin embargo, incluso si el operador se desconecta cuando el nuevo propietario quiere salir de la cadena de estados, siempre puede enviar su transacción de respaldo y reclamar los fondos antes que el antiguo propietario, ya que su transacción de respaldo tiene un bloqueo temporal más corto.
en el operador de confianza
Por si no fuera suficientemente obvio, el operador es el único punto de fallo de las cadenas de estados. Los nuevos propietarios tienen que confiar en que el operador ha eliminado su clave anterior y no se confabulará para reclamar cooperativamente fondos para el propietario anterior. Dado que el servidor del operador es básicamente una caja cerrada web2, el nuevo propietario no tiene forma de verificar la eliminación de la clave anterior del operador (a menos que sea el propio operador).
Mercury Layer, un proyecto de stateechain, pretende eliminar este factor de confianza. Utilizando una variante ciega de Schnorr, el operador de Mercury no conoce la cadena Bitcoin en sí. Así, el operador no tiene ni idea de para qué dirección de depósito está cofirmando, ni de los detalles de las transacciones de respaldo, ni se entera de las firmas que genera. Asumiendo que el mismo operador maneja múltiples cadenas de estado, Mercury esencialmente firmará a ciegas cada solicitud entrante de co-firma que le llegue, sin conocimiento de lo que su firma permitirá. Esto evita la colusión selectiva por parte del operador, garantizando que la generación de claves y la firma se realizan correctamente en su servidor, ya que simplemente no tienen ningún incentivo para ser maliciosos (no saben lo que está en juego debido a la firma ciega).
[Ruben Somsen] el operador está firmando mensajes ciegos - no sabe si se trata de transacciones Bitcoin o de algo totalmente distinto.
Sin embargo, a pesar de los esfuerzos de Mercury, las statechains siguen estando muy limitadas. Sólo puedes "enviar" a la statechain la cantidad exacta de BTC que has depositado, ya que statechains en su esencia es simplemente un protocolo de transferencia de propiedad de direcciones en lugar de facilitar realmente las transferencias UTXO como Lightning Network. Además, en el caso de que el operador se desconecte, todos los "envíos" se detendrán, y tendrás que esperar a que expire tu largo timelock antes de que puedas reclamar tus fondos de nuevo a Bitcoin a través de una transacción de respaldo.
conclusión
Aunque las statechains ofrecen un ingenioso "truco" para transferir UTXOs por encima del coste y las limitaciones de Bitcoin, siguen siendo inadecuadas para transferencias de UTXO a gran escala y de alta frecuencia de diferentes cantidades. En este contexto, las statechains son incluso más restrictivas que Lightning Network: aparte de poder transferir únicamente el UTXO exacto con el que se ha financiado la statechain, también hay que lidiar con la misma falta de programabilidad que impide desbloquear casos de uso más ricos distintos de los pagos (es decir, DeFi).
Al fin y al cabo, las statechains son exactamente eso: un protocolo de transferencia de propiedad de direcciones de confianza minimizada. Al menos Lightning funciona para los corredores de nodos.
Statechains: divertido para los desarrolladores, no tanto para los demás.
Custodia BTC
Las soluciones de custodia de BTC (llamadas "bitbancos" por los OG), a pesar de ser una bofetada ideológica en la cara de los "verdaderos" Bitcoiners, sigue siendo irónicamente una de las vías más seguras (y también más convenientes) para que el usuario medio realice transacciones con sus bitcoins de forma barata, rápida y razonablemente segura.
Los custodios de confianza de BTC se encuentran en su mayoría entre las criptoinstituciones más antiguas, y gozan de gran prestigio en el sector, e incluso en TradFi.
tldr
Las soluciones de custodia de BTC, que se explican por sí solas, suelen implicar a entidades de renombre en las que los depositantes confían lo suficiente para que actúen como custodios de todos los bitcoins depositados en ellas. Después, acuñarían tokens representativos en diferentes cadenas (y entornos), donde cada unidad estará respaldada 1:1 por la cantidad de bitcoins que el custodio tenga en reserva (en teoría).
Al vivir en una cadena más barata y rápida que Bitcoin, estos tokens representativos de BTC (por ejemplo, wBTC, cbBTC, etc.) permiten a sus titulares utilizarlo a través de DeFi, obtener rendimientos denominados en BTC y realizar transacciones entre sí en un entorno de ejecución mucho más rápido y barato.
en el custodio confiamos
[BitGo] BitGo: el custodio de confianza de wBTC
Huelga decir que los usuarios de soluciones de custodia de BTC deben confiar plenamente en el custodio del token representativo de BTC que poseen. Diferentes entidades de custodia conllevarían distintos niveles de riesgo, según la interpretación desde la perspectiva del titular.
Por ejemplo, un usuario estaría más inclinado a utilizar wBTC de BitGo si es alguien que valora la trayectoria histórica, la liquidez del intercambio y su carácter OG. Del mismo modo, las personas en el otro lado del espectro podrían preferir cbBTC de Coinbase si son alguien que pone mayor énfasis en las regulaciones claras, la transparencia y el respeto por el debido proceso americano y el estado de derecho. Esto es análogo a las consideraciones de alguien a la hora de decidir entre USDT de Tether o USDC de Circle para su stablecoin de elección - ¡o simplemente tener ambas!
conclusión
Aunque las soluciones de custodia de BTC sirven actualmente de puente útil para los usuarios de BTC que de otro modo no se autocustodiarían, siguen siendo una solución provisional en el mejor de los casos.
Cuando tienes wBTC, estás confiando en BitGo de la misma manera que confiarías en un CEX cuando tienes fondos depositados con ellos. Lo mismo ocurre con cbBTC de Coinbase, BBTC de Binance y muchos otros custodios de BTC.
Un fallo de seguridad y un encuentro con el poderoso Lazarus (esperemos que no), ¡y ahí van tus bitcoins para financiar las armas nucleares de Kim!
Federados BTC
Imagina wBTC, pero en lugar de tener sólo a BitGo como custodio, también tienes a Wintermute, ChorusOne y otras instituciones que se unen a la fiesta y reciben las llaves del reino.
Dime, ¿qué es mejor que un custodio? ¡Un montón de ellos!
tldr
Los puentes BTC federados son esencialmente un puente BTC de custodia colectiva. Implican a varias entidades acreditadas que forman un conjunto de firmantes, por lo que se necesita una mayoría para autorizar transacciones con bitcoins depositados entre ellas.
La idea es eliminar el riesgo de un único punto de fallo presente en las soluciones de custodia de BTC. De la misma forma que utilizarías un monedero multisig en lugar de un EOA para autocustodiar la mayor parte de tus ahorros, la idea es que al distribuir los privilegios de firma entre varias entidades de confianza, puedes depositar menos confianza en cada firmante individual.
Por tanto, para comprometer una configuración federada de BTC (y robar los bitcoins almacenados en ella), el atacante necesitaría comprometer a la mayoría de las entidades que forman parte del conjunto de firmantes. Comprometer Coinbase es difícil. Pero comprometer Coinbase, OKX, Wintermute y Fireblocks sin ser detectado, es una empresa bastante ambiciosa para cualquier atacante potencial.
multisigs y MPC
Simplificando demasiado, hay principalmente dos formas de distribuir privilegios de firma en una configuración federada de BTC: mediante construcciones multisig (multifirma) y/o MPC (computación multiparte). No voy a entrar en los detalles de implementación de cada una (son muchos), pero la idea principal es que en una firma múltiple, la dirección "compartida" se genera en la cadena y cada firmante posee una clave privada totalmente independiente. Esto significa que cuando una transacción de la dirección compartida es firmada colectivamente por los firmantes, la firma se registra en la cadena.
Con MPC, la dirección "compartida" se genera fuera de la cadena y cada firmante posee una clave parcial. Al firmar una transacción onchain, los firmantes calcularán conjuntamente una firma combinando sus claves compartidas. Desde la perspectiva de la cadena de bloques, parecería que la firma es simplemente una firma estándar procedente de un firmante, mientras que en realidad es generada colectivamente fuera de la cadena por el conjunto de firmantes como parte de la construcción de la MPC.
Por supuesto, existen matices y compensaciones entre cada enfoque. Aunque entrar en detalles está fuera del alcance de este artículo, te recomiendo que leas este manual de Fireblocks sobre MPC vs. Multi-sig si eres un friki que quiere profundizar en los detalles.
en la federación confiamos
En teoría, todo esto suena muy seguro. Tienes a las mejores instituciones de criptomonedas, cada una con su propia reputación en juego, salvaguardando colectivamente el puente federado de BTC. ¿Qué podría salir mal?
Menos confianza no significa que no haya confianza. Con un puente federado de BTC, la selección del firmante es de vital importancia. La federación debe incluir un número suficiente de firmantes, un umbral de mayoría seguro (al menos dos tercios) y estar suficientemente distribuida geográficamente. Por no mencionar que cada firmante debe tener ya una reputación suficientemente buena que esté dispuesto a proteger, además de tener un interés personal en el éxito del puente federado.
Para mí, de las instituciones que son firmantes de al menos un puente BTC federado actualmente vivo, hay honestamente sólo un puñado de ellas en las que confiaría los ahorros de mi vida. Cruzando los dedos, tienes la confiable Coinbase - luego probablemente Galaxy, Wintermute, y Fireblocks. No estoy diciendo que el resto sean instituciones dudosas, pero confiarles el 100% de los ahorros de mi vida es otra cuestión.
En resumen, no sirve de nada tener 15 firmantes en tu federación, cuando 10 de ellos no aplican buenas prácticas de seguridad o incluso son francamente incompletos. El problema es que es más fácil encontrar 15 firmantes de excelente reputación con una gran opsec, por no hablar de 50 firmantes.
¿Cuando todo el mundo dice tener buena reputación y ser seguro? Voilà, ¡sólo unos pocos lo son realmente!
Dicho esto, opino que los puentes federados de BTC siguen siendo la mejor forma de "exportar" BTC a otras cadenas (o capas) externas a la cadena principal de Bitcoin. Espere que los cypherpunks se revuelquen en sus tumbas, pero una federación cuidadosamente curada de firmantes de calidad sería en la mayoría de los casos más segura que cualquier alternativa sin permisos que sea posible en las circunstancias actuales.
Después de todo, hay una razón por la que la mayoría de las representaciones de BTC que se ven hoy en día se basan principalmente en una federación de firmantes. Tenemos solvBTC, pumpBTC, Lombard's LBTC, Stacks' sBTC, Avalanche's BTC.b, Bitlayer's WBTC, Liquid's L-BTC, Merlin's MBTC - todos ellos requieren que se confíe en la federación de firmantes que cada uno ha creado respectivamente. Pero como es difícil encontrar firmantes realmente reputados, no se sorprenda de encontrar múltiples casos de solapamientos de firmantes entre federaciones, en los que el mismo firmante formaría parte de dos o más configuraciones de puentes. Por ejemplo, Cobo es firmante de solvBTC, pumpBTC y Merlin's MBTC. O Chorus.one, firmante del LBTC de Lombard y del sBTC de Stacks.
Incluso hay casos en los que dos firmantes de una federación forman parte del mismo ecosistema o entidad. Por ejemplo, BTC.b de Avalanche incluye a Avascan y Ava Labs como parte de su federación de 8 firmantes. Asumiendo un umbral de mayoría de 5 de 8 (el mínimo necesario), eso deja al atacante con "sólo" 3 firmantes a los que sobornar o comprometer (y amenazar seriamente la seguridad del puente BTC.b).
Lombard LBTC
Algunos proyectos reconocen la importancia de la opsec del firmante y han tomado medidas para minimizar este vector de ataque. Por ejemplo, Lombard emplea un enfoque de seguridad de varios niveles al obligar a su Consorcio (conjunto de firmantes) a ejecutar CubeSigner, una plataforma de gestión de claves sin custodia construida por Cubist que utiliza enclaves Nitro sellados con HSM. En la práctica, CubeSigner permite que las claves permanezcan en un hardware seguro desde la generación de la dirección hasta la firma de la transacción - nadie, ni siquiera Cubist o los propios firmantes, puede ver las claves y mucho menos que atacantes externos puedan extraerlas.
Sin embargo, al igual que usted confía en Ledger en cuanto a la integridad e incorruptibilidad de los monederos físicos de Ledger que tiene en casa, los titulares de LBTC de Lombard también tendrían que confiar en Cubist en cuanto a la integridad e incorruptibilidad de las instancias de CubeSigner gestionadas por los firmantes del Consorcio; de lo contrario, volveríamos a confiar en que cada firmante del Consorcio no estropee su propio opsec.
[Lombard] ilustrado: Arquitectura Lombard LBTC
Además, todo ello sin tener en cuenta el riesgo de una posible colusión de firmantes, por improbable que parezca. El simple hecho es que si una mayoría de los firmantes del Consorcio Lombard se confabulan, podrán comprometer el BTC mantenido a través de las direcciones del Consorcio y robar los fondos de los usuarios.
conclusión
Como industria, nos haríamos un flaco favor si nos contentáramos con la selección de representaciones de BTC que tenemos hoy en día. Es duro, pero hay que decirlo: no tiene sentido Bitcoin (y de hecho, toda esta industria) si sólo unas pocas ballenas selectas con los bolsillos para pagar las tasas de transacción de la cadena principal son las únicas que pueden realizar transacciones con BTC de una manera libre de confianza. Toda esta noción de BTC como el dinero sano y fiable para las masas, dejaría de existir cuando la única forma realista para la mayoría de la gente de ahorrar, gastar y realizar transacciones con BTC les obligue a depositar su confianza en entidades dirigidas por humanos falibles bajo jurisdicción estatal.
Los puentes BTC federados han allanado el camino para que la gente tenga y realice transacciones con BTC de forma rápida y barata, sin dejar de ser relativamente seguros en comparación con otras alternativas disponibles. Pero nunca se han concebido como el fin último del escalado de Bitcoin, sino más bien como un medio para alcanzar un fin.
Suficientemente bueno hasta ahora, pero desde luego no la solución del santo grial que la industria (y el mercado) necesitan desesperadamente.
Portainjerto rBTC
[Rootstock] Rootstock: una de las soluciones de escalado originales de Bitcoin
Lanzada en enero de 2018, Rootstock es la primera y más duradera cadena lateral de Bitcoin. Aprovecha la minería merge para el consenso y emplea un puente bidireccional federado de BTC en el que también se utiliza rBTC para pagar las tarifas de gas en Rootstock.
¿El truco? El puente BTC federado de Rootstock no requiere una suposición de mayoría honesta para ser seguro.
Ahora que tengo su atención, entremos en materia.
fusión-minería
La cadena Rootstock emplea la minería merge para alcanzar el consenso. A diferencia de las cadenas PoS (en las que la proporción de sus activos apostados en relación con el conjunto de apuestas representa su poder de voto), las cadenas merge-mined intentan aprovechar la capacidad de hashrate que ya se está utilizando para minar Bitcoin ampliándola para validar la cadena Rootstock. Esto permite a los mineros de Bitcoin asegurar simultáneamente tanto Bitcoin como Rootstock con la misma infraestructura y consumo de energía, permitiéndoles obtener recompensas mineras de ambas redes con el mismo gasto. Si está más familiarizado con PoS, merge-mining sería análogo a restaking - el mismo recurso (por ejemplo, ETH) se utiliza para asegurar simultáneamente tanto la cadena PoS nativa (a través de plataformas de staking líquido) como las redes PoS externas (restableciendo su LST para asegurar las redes de su elección).
[Alexei Zamyatin] ilustrado: merge-mining
En el momento de escribir estas líneas, el ~80% de los mineros de Bitcoin han optado por participar en el proceso de minería por fusión de Rootstock: ¡cada PoW de un bloque de Rootstock heredará ahora el ~80% de la potencia de hashing de Bitcoin!
Para facilitar un mayor rendimiento en la cadena, los bloques de Rootstock están diseñados para ser minados más rápido que los de Bitcoin (por lo tanto, tienen una dificultad menor que Bitcoin). A día de hoy, el tiempo medio de bloque de Rootstock es de unos 25 segundos, frente a los 10 minutos de Bitcoin.
tldr
Para incorporar BTC a la cadena, Rootstock ha implementado un tipo especial de configuración federada de BTC que viene con un toque de hardware. Los pegnatarios (firmantes) deben ejecutar el módulo de seguridad de hardware de Rootstock, llamado PowHSM. El PowHSM es un dispositivo a prueba de manipulaciones responsable de almacenar la clave del firmante que forma parte del esquema multisig de la federación. Al igual que la implementación del CubeSigner de Lombard, el PowHSM está diseñado para garantizar que las claves permanezcan en el hardware seguro desde su generación hasta la firma: nadie, ni siquiera Rootstock o los propios firmantes, puede ver las claves y mucho menos los atacantes externos pueden extraerlas.
El contrato Bridge en Rootstock ejecuta Bitcoin SPV, dándole una visión de Bitcoin desde Rootstock de forma no fidedigna. Para las transacciones de peg-in, los pegnatories esperan a que el depósito de BTC del usuario en Bitcoin acumule 100 confirmaciones antes de informar al Bridge, por lo que este acuñará rBTC al usuario tras la verificación del depósito de BTC del usuario (a través de Bitcoin SPV).
Para las transacciones "peg-out", el puente aceptará primero la solicitud de "peg-out". Después de 4000 confirmaciones de bloque (en Rootstock), el puente crea la transacción Bitcoin peg-out correspondiente a esa solicitud para que los pegnatarios la firmen. A continuación, cada PowHSM recibirá esta orden (a través de Powpeg, también conocido como nodos completos de Rootstock) y activará al pegnatario para que firme la transacción. Una vez que la mayoría de los pegnatorios firmen la transacción, el multisig Bitcoin de Rootstock liberará la cantidad correspondiente de BTC a la dirección Bitcoin del usuario que realiza la retirada.
malditas sean las colusiones
Lo que diferencia a la implementación del puente federado de BTC de Rootstock de las demás es que no requiere una asunción de confianza honestamente mayoritaria por parte de su conjunto de firmantes para que el puente permanezca seguro. En otras palabras, aunque la mayoría de los firmantes de Rootstock se confabulen, no podrán poner en peligro el puente y robar los fondos de los usuarios.
¿Cómo es posible? La razón es que Rootstock es capaz de desacoplar la generación de transacciones de la firma de transacciones y emparejarla con la firma segura HSM conectada a Powpeg.
Para ilustrarlo, en una construcción multisig o MPC típica, sus firmantes generan y firman transacciones. Tomando Lombard como ejemplo, un usuario debe enviar primero una solicitud de peg-out interactuando onchain con un contrato puente Lombard. Uno de los firmantes de Lombard la recogerá y generará la solicitud del usuario como una transacción Bitcoin antes de proponerla al Consorcio para su aprobación. Tras la aprobación de la mayoría, el multisig Bitcoin de Lombard liberará la cantidad de BTC correspondiente al usuario que retira el dinero. Se espera que esto sea representativo en todos los puentes BTC federados, con pequeñas variaciones (intrascendentes).
A continuación, observe que el firmante Lombard es el que genera la transacción Bitcoin facilitando el peg-out del usuario. En caso de colusión mayoritaria de firmantes, el firmante (con la bendición de la mayoría) podrá proponer una transacción fraudulenta al Consorcio para su aprobación por mayoría. Esta es la razón por la que los puentes federados de BTC casi siempre han implicado un supuesto de seguridad por mayoría honesta, es decir, ¡hasta Rootstock!
[IOV Labs] ilustrado: arquitectura de Powpeg de Rootstock
Rootstock es único en el sentido de que los pegnatorios no generan transacciones Bitcoin correspondientes a la solicitud de peg-out de un usuario. Esto se debe a que el contrato Bridge en Rootstock es el que construye la transacción Bitcoin para el usuario, que a su vez es validada por los mineros Bitcoin que han optado por participar en el proceso de minería merge de la cadena. Los Pegnatories no juegan ningún papel en la generación de la transacción - su función es simplemente ejecutar el PowHSM, que se conecta a Powpeg y firmará "automáticamente" la transacción ya construida una vez recibida.
Para visualizarlo, imagina que visitas la interfaz de Uniswap para realizar un intercambio. En primer lugar, tu monedero (por ejemplo, Metamask) generará datos de transacción basados en lo que pretendes hacer (por ejemplo, "cambiar X ETH por USDC"), que luego aparecerán en tu monedero físico (por ejemplo, Ledger) para que los firmes. En este escenario, el que hace clic en la interfaz Uniswap es análogo al usuario que retira, la cartera que genera los datos de la transacción es análoga al contrato Bridge en Rootstock, y el que pulsa los botones físicos en la cartera de hardware es análogo al PowHSM de pegnatory-run que firma la transacción recibida.
en el hardware en el que confiamos.
Recordemos que la blockchain de Rootstock está ahora fusionada con el 80% de la potencia de hashing de Bitcoin. Por lo tanto, a menos que quieras ir por el camino difícil y tratar de comprometer el puente rBTC poseyendo >40% del poder hash de Bitcoin y manteniéndolo durante al menos 4000 bloques de Rootstock (~28 horas), como posible atacante estarías mejor apuntando a la integridad de la implementación PowHSM de Rootstock en su lugar. Al igual que confiaría en Cubist a la hora de anular el riesgo opsec del firmante de Lombard, el usuario también tendría que confiar en Rootstock Labs para asegurarse de que el PowHSM ejecutado por los pegnatarios no tiene ningún error o puerta trasera encubierta que pueda ser explotada por Rootstock, un posible atacante o incluso los propios pegnatarios.
En defensa de Rootstock, han tomado medidas para reducir el grado de confianza que los usuarios deben depositar en ellos mediante el código abierto del firmware PowHSM. Sin embargo, como el propio firmware se implementa sobre Ledger Nano S o Intel SGX, los usuarios siguen teniendo que confiar en Ledger o Intel (como fabricantes) en su palabra de que el chip Secure Element es realmente seguro y que no introducirán canales encubiertos, generadores de números aleatorios sesgados o cualquier forma de puerta trasera en sus dispositivos.
conclusión
Aprovechando la defensa en profundidad (también conocida como seguridad por capas), Rootstock ha logrado lo que ningún otro ha hecho: implementar un puente federado de BTC que no requiere una asunción mayoritaria honesta para la seguridad de los fondos depositados por sus usuarios.
Pero, de nuevo, menos confianza no significa que no haya confianza. Sigue siendo necesario confiar en la composición del conjunto de 12 pegnatarios de Rootstock, al igual que se confía en los conjuntos de firmantes de otras configuraciones de puentes federados. Aunque en el caso de Rootstock, dado que los pegnatorios no tienen poder para manipular los datos de la transacción ("simplemente" ejecutan el PowHSM), se elimina el riesgo de colusión honesta mayoritaria y "sólo" se confía en los pegnatorios por su fiabilidad. Sin embargo, en el caso de que la mayoría de los pegnatories se desconecten, se corre el riesgo de que sus fondos queden atrapados en el multisig Bitcoin de Rootstock.
Además, también debe confiar en la seguridad de la implementación de PowHSM de Rootstock. Esto incluye confiar en que las instalaciones de firmware en los PowHSM se realizan correctamente, y también confiar en Ledger y/o Intel en cuanto a la integridad de sus dispositivos.
[Rootstock] el panorama general: Rootstock y la cadena principal de Bitcoin
El puente rBTC de Rootstock es, de hecho, una mejora importante con respecto a los puentes federados de BTC existentes, pero el hecho es que sigue siendo necesario que el usuario deposite cierto nivel de confianza en ciertas partes de la pila. Aunque no voy a negar que la seguridad ofrecida por la configuración del puente federado de Rootstock ya es más que suficiente para el 99% de los tokens y representaciones que existen, voy a hacer un inciso cuando se trata de BTC - un puente de confianza minimizada no sólo es preferible, sino más bien un requisito previo.
Rootstock se merece un montón de flores por tener (en mi opinión) no sólo la mejor implementación de puente BTC federado, sino también el mejor puente BTC general que está actualmente en marcha y funcionando - equilibrando elegantemente la necesidad de seguridad y eficiencia de capital con su diseño.
Sin embargo, el trabajo aún no ha terminado.
BTC garantizado
Aparte de Lightning, los puentes de BTC colateralizados representan una de las pocas formas conocidas de "exportar" BTC a una cadena o capa escalable de forma verdaderamente libre de permisos.
Sin reputaciones de por medio, sin necesidad de entidades de confianza. Diseñado para que cualquiera pueda unirse, pero con un nivel de confianza mínimo, los usuarios no necesitan confiar en nadie en absoluto.
Aquí, el dinero en efectivo es literalmente el rey.
tldr
La idea es sencilla: por cada 1 $ de BTC depositado en el puente colateralizado de BTC, habría al menos más de 1 $ de otros activos que lo respaldaran.
¿Y la aplicación? No tanto.
Aunque existen pequeñas variaciones, podemos clasificar principalmente los puentes BTC colateralizados en dos tipos de implementación: Puentes estilo CDP y puentes ponderados por estacas.
Interlay iBTC
CDP significa posición de deuda colateralizada, popularizada por MakerDAO y se encuentra principalmente en proyectos de stablecoin descentralizados como LUSD de Liquity y DAI de MakerDAO. Para acuñar un token de deuda (también conocido como LUSD o DAI), los usuarios deben depositar una garantía (es decir, wBTC, ETH) que supere el valor de la deuda máxima permitida de la posición. El ratio de colateralización dependerá de la volatilidad y el riesgo percibidos del activo colateral: los activos seguros de "primera clase" tenderán a obtener un ratio más bajo, mientras que los activos de cola larga requerirán un ratio de colateralización más alto para compensar su riesgo percibido. Si el ratio de colateralización cae por debajo de un determinado umbral (es decir, el 110%), las cámaras entrarán en liquidación y los propietarios de las posiciones correrán el riesgo de perder toda su garantía.
El iBTC de Interlay es un ejemplo de implementación de puente de BTC al estilo CDP, en el que cada dólar de BTC puenteado debe estar respaldado por más de un dólar de garantía en la cadena de destino. Para acuñar iBTC, los depositarios deben depositar primero una garantía en Interlay antes de depositar BTC en la cadena principal. La cantidad de iBTC que se puede acuñar corresponde al valor de la garantía del aclamador en Interlay: si la garantía bloqueada vale 160 $, los aclamadores sólo pueden acuñar 100 $ de iBTC en Interlay(160% CR). Si el valor de la garantía del acaparador cae por debajo del ratio de liquidación, cualquiera podrá quemar iBTC para rescatar su garantía con una prima (110%), lo que garantiza que el sistema se mantenga sano, ya que los liquidadores vigilarán constantemente las cámaras acorazadas en busca de una oportunidad para extraer primas de liquidación.
[Interlay] ilustrado: Interlay iBTC
Para canjear iBTC por BTC en Bitcoin, los usuarios primero envían una solicitud a un vaulter, que procesará la retirada enviando la cantidad correspondiente de BTC al usuario desde su bóveda de Bitcoin. Si el vaulter se desconecta o simplemente se niega a canjear BTC, el usuario puede reclamar al vaulter una garantía proporcional al valor de su canje de iBTC, más una recompensa por "canje fallido". De este modo, se incentiva a los depositarios a canjear BTC para el usuario, para no arriesgarse a pagar una prima al usuario con su garantía bloqueada en Interlay.
Umbral tBTC
Por otro lado, los puentes ponderados por estacas son básicamente puentes BTC federados, pero en lugar de restringir el conjunto de firmantes a unas pocas entidades de confianza elegidas a dedo, cualquiera puede participar como firmante estacando sus activos en el puente (y ejecutando el software necesario para operar como firmante para el puente). Los privilegios de firma se distribuyen a través de multisig y/o MPC, dependiendo de los detalles de implementación de cada puente.
Echemos ahora un vistazo al tBTC de Threshold, posiblemente la implementación de puente de BTC ponderada por participaciones más destacada. Threshold aprovecha el MPC para generar la dirección de depósito de Bitcoin de su puente, cada una de las cuales consta de 100 firmantes. Los firmantes se eligen mediante un proceso aleatorio (a través de Sortition Pool), en el que la probabilidad de que un firmante sea elegido es igual a su porcentaje de $T apostados en relación con el conjunto de firmantes: si usted ha apostado 10 $T y el conjunto de firmantes tiene 800 $T apostados en total, su probabilidad de ser seleccionado como firmante para esa dirección de depósito de Bitcoin será del 1,25%. Asumiendo 100 firmantes para una dirección de depósito Bitcoin, puedes esperar que tu nodo componga al menos 1 firmante del conjunto. Además, dado que utiliza el algoritmo ECDSA de Threshold para la generación y firma de monederos, 51 de los 100 firmantes deben cooperar para mover fondos fuera de las direcciones de depósito Bitcoin de Threshold.
[Chaos Labs] ilustrado: Umbral tBTC
Cada 14 días, el puente generará una nueva dirección de depósito Bitcoin para los depósitos BTC de los usuarios basándose en la composición actual de las apuestas de Threshold. Aparte de permitir a los nuevos apostadores convertirse en firmantes de las futuras direcciones de depósito Bitcoin de Threshold, esto también logra la seguridad hacia adelante: incluso si una mayoría corrupta llegara a formar la composición de apostadores de Threshold, sólo comprometerá las nuevas direcciones de depósito Bitcoin generadas a partir de ese momento. En otras palabras, si usted utilizó Threshold para puentear su BTC (y acuñar tBTC) antes de que la mayoría corrupta se hiciera cargo de la composición de la apuesta, su BTC permanecerá almacenado de forma segura en la dirección de depósito Bitcoin controlada por el entonces seguro conjunto de firmantes de la mayoría honesta.
iBTC - en la garantía confiamos
Ambos modelos de puente (estilo CDP y ponderado por participaciones) no imponen en su diseño un conjunto cerrado de entidades privilegiadas. La identidad del firmante y su reputación no importan en este caso: lo único que importa para la seguridad de los puentes son las garantías bloqueadas en el sistema.
En el caso del puente CDP de Interlay, los usuarios tienen que confiar en la garantía que respalda cada iBTC. Si el puente acepta activos dudosos como garantía, correrá el riesgo de una infra-colateralización: los liquidadores pueden no estar motivados para liquidar las bóvedas si la garantía que reciben a cambio no tiene un mercado líquido o un descubrimiento de precios eficiente. Para entenderlo mejor, imagine que usted es un liquidador y pregúntese: ¿está dispuesto a liquidar una cámara pagando una prima del 10% por una memecoin con escasa liquidez en la cadena y susceptible de sufrir oscilaciones de precio del 20% cada hora?
Como usuario, es inevitable que tenga que confiar en la red de oráculos que transmite las fuentes de precios de los activos de garantía en Interlay. Los oráculos no se construyen de la misma manera - mientras que algunos tienen una muestra considerable para sus fuentes de precios e implementan prácticas de seguridad robustas, otros pueden ser un poco más sospechosos. De hecho, a menudo el eslabón más débil ha resultado ser el oráculo en lugar de la garantía del CDP o la implementación de sus contratos inteligentes.
tBTC - en los estaqueros confiamos
Naturalmente, al ser un puente ponderado por las participaciones, los titulares de tBTC tendrían que confiar en que la composición de las participaciones en $T de Threshold siga estando descentralizada, y que ninguna entidad o coalición pueda abarcar más del 51% de los $T apostados, presentes o futuros.
Aunque la seguridad hacia adelante de Threshold limitará el daño sólo a futuros depósitos de BTC después del punto de compromiso (composición de la apuesta), no se puede estar seguro de cuándo ocurre esto realmente. El atacante puede simplemente dividir sus saldos de $T apostados entre varias direcciones, lo que hace que parezca que sus saldos están en manos de varias partes cuando en realidad están controlados por la misma entidad. Esto se ve agravado por la incapacidad del algoritmo de firma subyacente de Threshold para identificar a los firmantes que se comportan mal (al menos en tBTC v1), lo que permite a los posibles atacantes pasar desapercibidos a medida que se introducen lentamente en el conjunto de firmantes y (finalmente) forman una mayoría de apuestas. Al parecer, lo anterior preocupa lo suficiente a Threshold como para decidir lanzar el puente con un conjunto de firmantes autorizados, en el que sólo se permite firmar a entidades acreditadas y verificadas, lo que convierte a Threshold, al menos en su forma actual, en un puente BTC casi federado.
Pero por el bien del argumento, supongamos que el puente se hace sin permisos - el token $T ha alcanzado miles de millones en capitalización de mercado, y que sería muy poco probable que cualquier atacante pudiera acumular $T hasta el 51% de la composición de apuestas del puente. Incluso en este estado de "final del juego", el puente sigue estando limitado por la capacidad: los depósitos de BTC de los usuarios sólo se consideran económicamente seguros si el conjunto de firmantes puede perder más en garantías apostadas que lo que podría ganar robando los fondos de los usuarios en todas las direcciones Bitcoin depositadas que controlan colectivamente.
Para cuantificar lo anterior, imaginemos un escenario en el que un total de 10 millones de dólares de valor T se apuestan en Umbral. También para simplificar, supongamos que el conjunto de firmantes permanece invariable en todo momento. Dado que se necesitan 51 de 100 para firmar, se puede decir que la seguridad económica del puente vale 5,1 millones de dólares, que es el valor máximo de la garantía disponible para que Umbral acuchille a los firmantes deshonestos. Teóricamente, una vez que la suma de depósitos de usuarios en BTC a través de direcciones de depósito Bitcoin controladas haya alcanzado un total de más de 5,1 millones de dólares, sería rentable para los firmantes confabularse y desviar los fondos de los usuarios. Aunque en la práctica el conjunto de firmantes no será fijo en varias direcciones de depósito de Bitcoin (para acomodar a los nuevos firmantes y a los que ya no lo son), la teoría del juego sigue en pie: una mayoría de firmantes deshonestos es capaz de comprometer el puente siempre que el valor de los depósitos de BTC de los usuarios en las direcciones de depósito de Bitcoin controladas sea superior a la garantía que pueden perder.
conclusión
Aparte de Lightning, sólo los puentes BTC colateralizados pueden afirmar que son realmente permisivos. Por desgracia, también conllevan una serie de enigmas y supuestos de confianza implícitos que existen fuera del propio puente.
La seguridad de los puentes estilo CDP está básicamente entrelazada con la composición de la garantía que aceptan para respaldar el puente. Si el puente se restringe únicamente a activos de alta calidad (es decir, ETH), entonces tendría que competir con otros protocolos DeFi en rendimiento para atraer a dichos activos: ¿por qué un titular de ETH depositaría contigo cuando puede obtener mayores rendimientos en otros protocolos?
CDP-style bridges are also highly capital-inefficient — in the case of Interlay, at least $1.6 worth of collateral is needed in order to mint $1 worth of iBTC. You can only lower the collateralization ratio down to a certain threshold: set it too low (<110%), and you’re staring at a barrel of failed liquidations and the risk of the bridge failing due to being straddled by bad debt.
También está la cuestión de la seguridad del oráculo. Para que las liquidaciones ordenadas sean posibles en primer lugar, los puentes de tipo CDP dependen de fuentes de precios sólidas y precisas procedentes del oráculo. Lo que significa que, por defecto, los usuarios también tendrían que confiar en la red o el proveedor del oráculo del puente.
En cuanto a los puentes ponderados por estacas, la distribución de estacas es el factor decisivo - después de todo, determinan quién formará parte del conjunto de firmantes cuando se generen las nuevas direcciones de depósito Bitcoin del puente. Los usuarios deben confiar en que la distribución de la propiedad del token de estaca esté lo suficientemente descentralizada como para que ninguna entidad o coalición pueda alcanzar la mayoría, ahora y en el futuro.
Además, los puentes de estaca ponderada son fundamentalmente de capacidad limitada (aunque mucho mejor que los puentes de estilo CDP) - sólo pueden asegurar económicamente los depósitos de BTC de los usuarios hasta el valor total de la garantía de estaca de una mayoría potencial de firmantes deshonestos. Esto limita de forma efectiva la cantidad de BTC que se puede almacenar de forma segura en las múltiples direcciones de depósito del puente: bajo ninguna circunstancia el valor total de los depósitos de BTC de los usuarios en esas direcciones debe superar el valor total de la garantía apostada de la mayoría de firmantes que las controlan.
Las representaciones no son iguales
Salir de la cadena principal tiene sus propios matices. Es cierto que las representaciones de BTC externas a Bitcoin nunca serán tan seguras como tener BTC en la cadena principal, pero a veces no necesitas tanta seguridad para tu dinero. No todo el mundo es millonario.
Aunque creo que la mayoría de las capas y puentes de escalado de BTC que se han comentado anteriormente seguirán siendo razonablemente seguros en un futuro próximo, creo que es importante que, como usuario de BTC autocustodiado, al menos seas consciente de las opciones que tienes en el mercado hoy en día. Espero que a través de este artículo, el usuario medio de BTC esté ahora mejor informado sobre las ventajas y desventajas de la confianza que existen cuando se navega a través de diferentes entornos de autocustodia.
En nuestro próximo artículo de la serie, exploraremos el descubrimiento de BitVM, un paradigma de computación en Bitcoin que permite ejecutar programas en Bitcoin de forma optimista. Esto significa que maneja la mayor parte de la computación fuera de la cadena y por lo tanto no se ve obstaculizada por las limitaciones de Bitcoin. Sin embargo, si alguien no está de acuerdo con el resultado, puede plantear una disputa en la cadena de Bitcoin. Si hay trampas, la persona fraudulenta queda al descubierto y es castigada. Como primer paso, esto permitirá la construcción de puentes BTC de confianza minimizada desde Bitcoin a capas de escalado externas por primera vez. En el futuro BitVM podría incluso permitir verdaderos rollups de Bitcoin donde los datos de las transacciones se almacenen en la blockchain de Bitcoin.
La cadena híbrida de BOB fusiona los puntos fuertes de la seguridad de Bitcoin y las herramientas de última generación de EVM, heredando lo mejor de ambos mundos. Siendo pionera en la primera implementación práctica de BitVM del mundo, BOB será el hogar de transacciones bitcoin seguras y baratas y DeFi - ¡he aquí Bitcoin nativo, fuera de Bitcoin!
¿Suena demasiado bueno para ser verdad? Manténgase en sintonía para la Parte 2 - una inmersión profunda en la Cadena Híbrida de BOB, la puerta de entrada a Bitcoin DeFi.
Si crees que me he dejado algo que merezca la pena mencionar, ponte en contacto conmigo a través de X/Twitter: siempre estoy abierto a sugerencias y comentarios. Además, si este artículo te ha resultado útil, ¡republícalo y agradece que te guste!
