Artículo reimpreso de: Comunidad china de Runes
Con el auge de BTCFi, Omnity ha lanzado el nuevo protocolo de extensión programable de capa uno de Bitcoin REE. Sumado a los años de acumulación del equipo en interoperabilidad cross-chain (Omnity hub), Omnity se ha convertido en uno de los jugadores más importantes y exploratorios en el campo de BTCFi.
Sitio web oficial: https://www.omnity.network/
En mi opinión, Omnity Network está explorando una solución técnica eficiente, altamente combinable y con alta tolerancia a fallos para la "expansión y mejora de la programabilidad" del ecosistema Bitcoin.
1. En escenarios de trading de alta frecuencia, a través de soluciones cross-chain de activos de Bitcoin de nivel Trustless como Omnity Hub, se trasladan a cadenas de contratos inteligentes de alta velocidad más desarrolladas como Bitlayer, Solana, Base.
2. En escenarios de grandes fondos y frecuencia normal de transacciones DeFi, se utiliza REE para construir directamente en la capa uno de Bitcoin.
Hub y REE son independientes, con una composibilidad flexible, lo que sienta una base sólida para la innovación de los desarrolladores. ¡Esperamos que surjan innovaciones disruptivas en el campo de BTCFi!
Los interesados pueden leer este artículo primero. Para ver la versión original en inglés, consulte el enlace a continuación.
White paper de REE: https://x.com/louisliubj/status/1861588938475086166
A continuación se presenta la versión en chino, ¡disfruta!
REE: Capa de ejecución de Bitcoin sin cadenas cruzadas y Turing completa.
REE introduce una capa de ejecución descentralizada de Bitcoin que habilita contratos inteligentes Turing completos para aplicaciones BTCFi. Sin necesidad de cruzar activos, REE mejora la programabilidad de la red principal de Bitcoin y mantiene la experiencia de usuario nativa de Bitcoin.
¿Qué es REE?
El Entorno de Intercambio de Runes (REE) es una capa de ejecución descentralizada de Bitcoin que proporciona contratos inteligentes combinables para Bitcoin L1 sin necesidad de cruzar activos. REE mejora el mecanismo de transacciones de múltiples firmas de Bitcoin a través de contratos inteligentes en la capa de ejecución descentralizada, participando directamente en las transacciones de la red principal de Bitcoin.
Figura 0. Transacción de múltiples firmas de Bitcoin
Las transacciones de múltiples firmas son transacciones de Bitcoin que incluyen entradas de múltiples participantes, una técnica que ha sido utilizada por el ecosistema de Bitcoin durante años. Normalmente, un participante actúa como coordinador, utilizando PSBT (Transacción de Bitcoin parcialmente firmada) para agregar la firma de cada parte involucrada y luego difundir la transacción a la red de Bitcoin. Algunos ejemplos notables de transacciones de múltiples firmas incluyen CoinJoin, wallets de múltiples firmas y custodios.
En escenarios de múltiples firmas, los participantes pueden ser programas además de humanos. En un entorno DeFi, los traders suelen comerciar con protocolos (contratos inteligentes) como contraparte. La filosofía de REE es permitir que los protocolos BTCFi participen en transacciones de múltiples firmas de Bitcoin, trasladando todo el proceso de firma a la blockchain pública, logrando así la descentralización.
Figura 1. Coordinación de múltiples firmas descentralizadas (DMSC)
La figura 1 muestra el flujo general de la Coordinación de Múltiples Firmas Descentralizadas (DMSC). La configuración involucra a un trader, múltiples protocolos BTCFi (A, B y C) y un coordinador en una blockchain pública. El coordinador agrega firmas y difunde la transacción final.
El proceso de DMSC es el siguiente:
1. Etapa de negociación
Los traders inician transacciones negociando los términos con múltiples protocolos. Cada protocolo representa una entidad que posee activos de Bitcoin y está preparada para comerciar según reglas específicas. Ejemplos de protocolos incluyen intercambios descentralizados, protocolos de préstamos, stablecoins, etc.
2. Etapa de firma
Después de la negociación, se construye un PSBT para reflejar la transacción. El coordinador luego llama a cada protocolo para firmar el PSBT. Cada protocolo (A, B y C) verifica su parte de la transacción y aprueba su inclusión mediante firma.
3. Etapa de difusión
Una vez que el PSBT esté completamente firmado, el Coordinador lo convierte en una transacción de Bitcoin y la difunde a la red. Así, la transacción se completa en Bitcoin.
REE elige ICP (Internet Computer Protocol) como la blockchain pública para DMSC. En otras palabras, REE es la infraestructura de Bitcoin DMSC sobre ICP.
¿Por qué REE?
Bitcoin es la blockchain más segura y descentralizada del mundo, pero su limitada capacidad de programación restringe su uso en aplicaciones financieras complejas. REE complementa las soluciones existentes de Bitcoin L2 al ofrecer programación avanzada y contratos inteligentes Turing completos, mientras mantiene la auto-custodia y minimiza las suposiciones de confianza.
Figura 2. REE no es Bitcoin L2.
A diferencia de la mayoría de L2, los contratos inteligentes de REE interactúan directamente con el modelo UTXO de Bitcoin, logrando una programación avanzada mientras mantienen la auto-custodia. Los traders no necesitan bloquear sus activos de Bitcoin en un puente cross-chain. Interactúan con el contrato inteligente firmando el PSBT con su billetera de Bitcoin y completando instantáneamente la liquidación de la transacción en Bitcoin.
Por otro lado, entre las soluciones conocidas de mejora de la programabilidad en Bitcoin L1, DMSC tiene ventajas significativas sobre otras soluciones. Aprovecha modernas blockchains públicas para mejorar la programabilidad de Bitcoin en lugar de depender de nuevos códigos OP. Además, DMSC puede ser compatible con todos los activos de metaprotocolo basados en UTXO sin necesidad de actualizar el metaprotocolo y el indexador.
Tabla 1. Comparación de soluciones técnicas de programabilidad en Bitcoin L1.
Finalmente, ICP puede ser la blockchain más adecuada para DMSC. REE utiliza la tecnología Chain Fusion de ICP para gestionar de manera segura las claves privadas y las firmas de Bitcoin, habilitando DMSC mientras mantiene el modelo de seguridad de Bitcoin. A través de la integración nativa de Bitcoin de ICP y un indexador en cadena, REE es compatible con Runes (el protocolo de metadatos de Bitcoin basado en UTXO más ampliamente aceptado) de una manera minimizada en confianza.
¿Cómo funciona REE?
Bajo la influencia de Ethereum, la gran mayoría de las plataformas de contratos inteligentes tienen un modelo de estado basado en cuentas, lo que también influye en el modo de pensar de los desarrolladores de contratos inteligentes. Sin embargo, el estado en cadena de Bitcoin está basado en UTXO. REE introduce el modelo Exchange-Pool para cerrar la brecha. El modelo Exchange-Pool se adapta a la gestión del estado UTXO de Bitcoin y puede implementarse fácilmente en cadenas públicas basadas en cuentas como ICP. Este modelo se compone de tres conceptos simples:
1. Coin es la unidad de activos de Bitcoin basada en UTXO. BTC y Runes son aceptados como Coin en REE.
2. Exchange es una instancia de protocolo BTCFi que opera en la plataforma REE, utilizada para facilitar el intercambio de Coin.
3. El pool de fondos es la clave pública (Chain Key) que el Exchange utiliza para mantener Coin y firmar transacciones de Bitcoin. Según la lógica del Exchange, los usuarios ingresan un saco de Coin en el pool y obtienen otro saco de Coin a cambio. Normalmente, un Exchange gestiona múltiples pools, cada uno con datos de Coin y estado.
Los constructores de Bitcoin ahora pueden crear una variedad de protocolos BTCFi utilizando el Exchange de REE, logrando varios métodos públicos de contratos inteligentes en ICP.
Figura 3. Arquitectura de REE
La figura 3 muestra el proceso de completar una transacción de Bitcoin en REE, involucrando múltiples componentes como dos Exchanges, el coordinador de REE y la interfaz frontal. A continuación se presenta un desglose paso a paso del proceso:
1. Solicitud de precio: el trader inicia el proceso a través de la interfaz frontal, realizando una solicitud de transacción. Esto puede involucrar seleccionar la transacción o tipo de operación que desea ejecutar, como intercambiar en ExchangeA y luego hacer staking en ExchangeB.
2. Construir PSBT: una vez que el trader acuerde los términos de la transacción, la interfaz frontal construye el PSBT con la ayuda del SDK de TypeScript de REE.
3. El trader firma el PSBT: el trader revisa y firma el PSBT con su billetera de Bitcoin, esencialmente aprobando la transacción para su posterior procesamiento.
4. Llamar al Orquestador/Coordinador: la interfaz frontal envía el PSBT al Orquestador/Coordinador de REE. El Orquestador/Coordinador de REE actúa como coordinador, supervisando la ejecución de la transacción.
5. Verificar entradas: antes de que el Orquestador/Coordinador ejecute la transacción REE, se deben verificar todas las entradas del PSBT para asegurar que sean gastables y contengan realmente los activos que afirman tener. El Orquestador/Coordinador depende de Ord Canister (el indexador en cadena de Runes) para completar esta tarea.
6. El Exchange firma el PSBT: después de la verificación, el Orquestador/Coordinador de REE se comunica con el Exchange relevante para firmar el PSBT. El Exchange verifica que los datos del PSBT cumplen con sus condiciones de transacción y firma uno por uno.
7. Difundir transacción: después de que todos los Exchanges relevantes firmen el PSBT, el coordinador de REE difunde la transacción completamente firmada a la red de Bitcoin. Luego, la transacción se confirma en la blockchain de Bitcoin, completando todo el proceso.
El Orquestador/Coordinador de REE es responsable de garantizar la consistencia del estado, notificando al Exchange cuando cualquier Exchange se niega a firmar para revertir el estado.
Antes de que cualquier persona use el Exchange, debe ser inicializado por su constructor:
1. Despliegue (paso 0.1): el constructor despliega el canister del Exchange en la misma subred de ICP que el Orquestador/Coordinador de REE. Aunque el canister puede llamarse a través de subredes, esto conlleva retrasos innecesarios.
2. Registro (Paso 0.2): el constructor se registra en el Orquestador/Coordinador de REE para el Exchange.
Los constructores del Exchange son responsables del mantenimiento del Exchange, incluyendo actualizaciones y recargas de ciclos para mantener su funcionamiento. Omnity proporcionará instalaciones generales para los constructores del Exchange para facilitar su uso, pero son opcionales y reemplazables.
Características del sistema
Programabilidad
El Exchange REE es un contrato inteligente de ICP independiente que puede aprovechar plenamente las funciones de la blockchain subyacente. Se recomienda a los lectores visitar la documentación técnica de ICP para obtener más información sobre el desarrollo de contratos inteligentes de ICP.
Documentación técnica de ICP:
https://internetcomputer.org/docs/current/home
Aquí hay algunos consejos:
1. Cálculos intensivos como el reconocimiento facial pueden ejecutarse dentro de los contratos inteligentes de ICP.
https://medium.com/dfinity/the-next-step-for-deai-on-chain-inference-enabling-face-recognition-589183203fc2
2. El contenedor de Bitcoin de ICP podría ser el contrato inteligente más grande del mundo, ocupando 500 GB de almacenamiento en cadena, con un costo anual de solo 2500 dólares.
https://github.com/dfinity/bitcoin-canister
3. Omnity Hub es un stack de interoperabilidad en cadena completo sobre ICP, lo que significa que no se requieren reles o indexadores fuera de la cadena. Omnity Hub se conecta directamente a decenas de blockchains heterogéneas a través de una interfaz RPC.
https://explorer.omnity.network/
Composibilidad
La composibilidad de los contratos inteligentes de REE asegura una integración fluida entre protocolos, habilitando protocolos financieros innovadores al combinar la liquidez y unidades lógicas dentro de un marco de minimización de confianza.
REE ofrece una composibilidad al estilo Bitcoin. Cada exchange solo se preocupa por lo que recibe (entrada) y lo que ofrece (salida); siempre que las entradas/salidas sean razonables, acepta participar en la transacción. Las transacciones REE pueden involucrar múltiples exchanges, cada uno de los cuales recibe y contribuye con algunas monedas. Con la cooperación del exchange, el coordinador es responsable de garantizar la atomicidad de las transacciones de múltiples firmas. La atomicidad compositiva significa que una transacción de múltiples firmas tiene éxito por completo o se revierte completamente en caso de que cualquier parte falle. Esto es crucial en aplicaciones DeFi.
Normalmente, los traders proporcionan la entrada inicial al primer exchange; la salida del primer exchange entra en el segundo exchange, y así sucesivamente, hasta que la salida final del último exchange se entrega al trader. El orden de firma del PSBT sigue esta lógica: el primer exchange solo aceptará proporcionar su entrada y firmar el PSBT si el trader ha firmado su entrada, y así sucesivamente.
Conceptualmente, la composibilidad de los exchanges se asemeja a los comandos Unix en tuberías. Sin embargo, no es solo eso. Cualquier entidad (trader o exchange) puede proporcionar entradas a otras entidades sin preocuparse por el orden. Por ejemplo, las entradas del trader se dan al segundo exchange o a exchanges posteriores; el exchange proporciona entradas iniciales y tarifas de la red Bitcoin en lugar del trader.
Además, el trader no necesariamente es un individuo; puede ser un proceso fuera de la cadena o un contrato inteligente de ICP. Esto abre la posibilidad de agregadores de ingresos en cadena o fuera de cadena o bots de arbitraje. A través de un poderoso stack de Chain Fusion, REEExchange puede interactuar con otras blockchains. Por ejemplo, los cambios de estado en Ethereum o Solana pueden activar transacciones REE, y viceversa.
Perfil de riesgo
El receptor (el trader que comercia con el pool de fondos) revisa el PSBT que contiene todos los términos de la transacción antes de firmar, representados por entradas y salidas. Una vez firmado, ninguna persona, incluido el propio trader, el exchange, REE, los nodos de ICP y los mineros de Bitcoin, puede modificar la transacción. En otras palabras, el receptor no asume ningún riesgo de custodia.
Normalmente, la ejecución de cada transacción REE provoca un cambio de estado en un pool de fondos específico, lo que hace que los términos de transacción obtenidos en consultas anteriores se invaliden. Teniendo en cuenta que el retraso en la ejecución de transacciones REE (en segundos) es mucho menor que en Bitcoin (en minutos), las transacciones REE generalmente se procesan en orden. Sin embargo, pueden ocurrir fallos de transacción cuando múltiples traders comercian con el mismo pool de fondos al mismo tiempo.
El fallo de una transacción no implica la pérdida de activos; el trader solo necesita consultar de nuevo e intentar ejecutar nuevamente.
Los creadores de mercado (traders que proporcionan liquidez al pool de fondos) asumen el riesgo de custodia al transferir el control de los activos al exchange. Por lo tanto, enfrentan riesgos de contratos inteligentes relacionados con la lógica del Exchange, lo que subraya la importancia de la auditoría y la reputación de los creadores de Exchange.
Las suposiciones de seguridad de los creadores de mercado incluyen las plataformas ICP y REE. Sin embargo, la seguridad de ICP (con un valor de decenas de miles de millones de dólares) cumple con los requisitos de seguridad de los protocolos BTCFi en todos los casos conocidos.
Consistencia del estado de Bitcoin
Las limitaciones de los scripts de Bitcoin en el soporte de BTCFi no solo se deben a las limitaciones funcionales de los códigos de operación, sino también en gran medida porque no pueden mantener un estado complejo en cadena. En comparación, los exchanges en REE pueden mantener y gestionar el estado con facilidad. Sin embargo, el estado del exchange en REE debe ser consistente con Bitcoin; de lo contrario, las transacciones de REE no se podrán liquidar en Bitcoin.
Para evitar fallos en la liquidación, el coordinador verifica que todas las entradas de transacción no hayan sido gastadas. Cada exchange también verifica que las entradas y salidas de la transacción cumplan con sus criterios. Este enfoque asegura que solo se utilicen entradas válidas y verificadas para liquidar transacciones.
Sin embargo, incluso si estas entradas son verificadas antes de la ejecución de la transacción, no se puede garantizar la liquidación después. Los traders pueden intencional o inadvertidamente utilizar las mismas entradas para otra transacción de Bitcoin.
REE debe percibir los cambios en tiempo real en la red Bitcoin y responder en consecuencia. Con el soporte de la integración nativa de Bitcoin y el indexador en cadena de Runes, REE puede ser la única capa de ejecución de Bitcoin que logra esto sin depender de procesos centralizados fuera de la cadena.
Figura 4. Estado de transacción de REE
El Orquestador/Coordinador de REE es el componente que gestiona el ciclo de vida de todas las transacciones REE. Es responsable de notificar eventos de cambio de estado relacionados con el Exchange.
Figura 5. Gestión del estado del pool de fondos
Los Exchanges gestionan el estado basado en pools de fondos. En particular, el estado del pool de fondos debe organizarse como una cadena de estado vinculada a una secuencia de transacciones ejecutadas en ese pool de fondos. El pool de fondos siempre maneja las consultas y ejecuta nuevas transacciones según la cabeza de la cadena de estado. Según las notificaciones de eventos del Orquestador/Coordinador, el pool de fondos ejecuta confirmaciones o retrocesos.
Además, dado que la alta volatilidad de las tarifas de la red Bitcoin no permite métodos económicamente viables para garantizar que las transacciones se incluyan en bloques dentro de un marco de tiempo específico. En caso de que las tarifas de la red Bitcoin aumenten, hay dos métodos para acelerar la liquidación: RBF (Replace-By-Fee, reemplazo por tarifa) y CPFP (Child Pays for Parent, el hijo paga por el padre). RBF requiere reconstruir la transacción, lo que lleva a una mala experiencia de usuario.
REE utiliza CPFP, lo que significa que cuando las tarifas de la red Bitcoin aumentan, las transacciones subsiguientes deben subsidiar transacciones anteriores en el mismo pool de fondos que no se han incluido en bloques. El subsidio de tarifas sigue siendo un mecanismo de libre mercado: los traders solo inician transacciones posteriores si anticipan que, a pesar del aumento de costos, aún podrán obtener ganancias.
Rendimiento
El rendimiento de la capa de ejecución generalmente se mide por dos métricas: capacidad (en TPS) y latencia. En REE, los traders pueden ejecutar transacciones secuencialmente con solo unos pocos segundos de latencia, sin tener que esperar la confirmación del bloque para proceder al siguiente paso. En términos de latencia, REE ha mejorado el rendimiento de Bitcoin en 100 veces.
Las transacciones en serie de REE se liquidarán en forma de lotes en la cadena de Bitcoin. Dado que una transacción en el memory pool puede tener hasta 25 transacciones subsiguientes, cada bloque de Bitcoin puede liquidar hasta 25 transacciones para un único pool de transacciones REE. Por lo tanto, 25 puede ser considerado como el límite superior de la capacidad de un único pool de transacciones REE.
Los diferentes pools de transacciones pueden permitir la ejecución de transacciones en paralelo. Cuando la competencia de precios no es necesaria, los constructores de Exchanges pueden agregar pools redundantes para mejorar la concurrencia. Por ejemplo, distribuir tokens en 10 pools para un airdrop con 100,000 receptores puede reducir significativamente la probabilidad de que las transacciones fallen debido a que múltiples usuarios reclaman simultáneamente.
En un solo pool de transacciones, se puede lograr concurrencia dentro del pool gestionando múltiples UTXOs que contienen el mismo tipo de moneda. Sin embargo, esto requiere algoritmos más complejos de selección, división y fusión de UTXOs. Los Exchanges futuros pueden explorar estas tecnologías avanzadas para proporcionar una mejor experiencia de usuario.
Costos
Los principales costos de las transacciones REE para los usuarios provienen de las tarifas de la red Bitcoin. REE minimiza el tamaño de las transacciones de liquidación utilizando el tipo de dirección P2TR.
Los constructores asumen los costos operativos del Exchange en ICP (ciclos). Aunque ICP es muy rentable, los constructores necesitan generar ingresos dentro o fuera del protocolo para asegurar la sostenibilidad económica de su Exchange.
MEV
REE es una capa de ejecución que delega el ordenamiento de transacciones a la subred de ICP donde se encuentra el contenedor del Orquestador/Coordinador de REE. Aunque teóricamente es posible, no se ha escuchado que los nodos de la subred de ICP extraigan MEV al reordenar transacciones.
Lo más importante es que no hay el concepto de deslizamiento en REE; cuando el trader firma el PSBT, todas las entradas y salidas de la transacción ya están establecidas. Si la entrada proveniente del fondo de Exchange ha sido gastada, la transacción fallará. Por lo tanto, si una transacción REE es adelantada, automáticamente fallará, dejando al corredor asumir el riesgo de precio por sí solo.
Gobernanza
REE será gestionado por Omnity SNS DAO, responsable de supervisar actualizaciones de protocolo, ajustes de parámetros y hoja de ruta de desarrollo. La gobernanza en cadena de SNS asegura la transparencia del desarrollo sostenible del ecosistema REE y la toma de decisiones impulsada por la comunidad.
Casos de uso
Replicar protocolos DeFi de Ethereum o Solana a Bitcoin es una forma directa de aprovechar REE. Aquí se enumeran algunos ejemplos para detallar.
AMM DEX (Intercambio descentralizado de creadores de mercado automáticos)
RichSwap, un AMM DEX construido por Omnity, se lanzará simultáneamente con la mainnet de REE. Como el primer exchange en REE, RichSwap sirve para los siguientes propósitos:
1. RichSwap valida la funcionalidad y rendimiento de la plataforma REE.
2. RichSwap es de código abierto, proporcionando ejemplos completos para los constructores de BTCFi.
3. Otros protocolos BTCFi pueden aprovechar RichSwap para acelerar la liquidez.
4. RichSwap tiene un mecanismo incorporado de captura de valor de tokens, que otros protocolos BTCFi pueden aprovechar.
Aunque RichSwap es el primer exchange, no tiene privilegios. Después del lanzamiento de la mainnet, REE se transformará rápidamente en una plataforma abierta, aceptando registros sin permiso de cualquier protocolo BTCFi conforme a las especificaciones técnicas (incluidos AMM DEX).
Préstamo
Los protocolos de préstamos basados en REE pueden soportar múltiples pools de fondos, cada uno con diferentes configuraciones, parámetros de riesgo y tipos de activos respaldados. Cada pool que permite pedir prestado BTC utilizando Runes de primera categoría puede tener diferentes tasas de interés, tasas de colateral y umbrales de liquidación. Puede optar por devolver un token a los proveedores de liquidez (LPs). Al integrarse con oráculos en ICP, el protocolo de préstamos puede determinar de manera descentralizada el valor del colateral o activar el proceso de liquidación.
Token de staking de liquidez
Implementar staking de Bitcoin L1 en REE es factible, pero integrar los protocolos de staking existentes (como Babylon) es una posibilidad más interesante. Los usuarios depositan Bitcoin en el Exchange y reciben LST en formato Runes. Luego, LSTExchange se combina con el protocolo de staking de Babylon en Bitcoin L1, mientras gestiona de manera no confiable las delegaciones y recompensas de staking en la cadena de Babylon. Omnity Hub ya se ha integrado con Osmosis a través de una arquitectura de cadena completa y verificación de cliente ligero. Por lo tanto, la interacción entre contratos inteligentes de ICP y aplicaciones de cadena de Cosmos ya no enfrenta obstáculos técnicos.
Hoja de ruta
1. Cuarto trimestre de 2024, publicación del white paper de REE.
2. Primer trimestre de 2025, lanzamiento de la mainnet de REE junto con RichSwap.
3. En el segundo trimestre de 2025, apertura del registro de Exchange a socios de Omnity.
4. En la segunda mitad de 2025, registro de Exchange completamente abierto.
Conclusión
REE representa un avance en la programabilidad de Bitcoin, logrando contratos inteligentes seguros y Turing completos sin depender de la cruzada de activos o bifurcaciones. Este modelo de ejecución sin cadena cruzada tiene el potencial de fomentar un ecosistema BTCFi que utilice la liquidez y seguridad de Bitcoin en un entorno completamente sin confianza y sin permisos.
