By Bitcoin Revista - Hace 6 meses - Tiempo de lectura: 6 minutos
Antes de que fueran geniales: pactos en la producción de líquidos
Desde el Bitcoin La comunidad se embarcó en discusiones sobre la optimización de los convenios, ha habido un interés creciente en aprender más sobre sus compensaciones y los convenios ya implementados en el Red liquida.
A la luz de este interés renovado y para fomentar una mayor discusión, revisemos algunas de las ofertas de convenios actuales de Liquid, comparándolas con las principales propuestas sobre Bitcoin y examinar sus respectivos casos de uso.
Historia de los pactos sobre el líquido.
Covenants on Liquid se remonta al despliegue de la primera cadena lateral de Elements, Alpha. Esta cadena lateral introdujo los códigos de operación OP_CHECKSIGFROMSTACK (CSFS) y OP_DETERMINISTICRANDOM junto con muchos otros en Elements. Alpha también habilitó versiones fijas de códigos de operación deshabilitados al principio Bitcoin, Tales como OP_CAT—un código de operación que muchos están optando por revisar en el creciente diálogo en las redes sociales. Estos nuevos códigos de operación mejoraron aún más la expresividad de la versión de Bitcoin Script disponible en Elements y prueba de concepto Bóveda de Möser-Eyal-Sirer fue desarrollado utilizando CSFS para ilustrar las nuevas posibilidades.
Uno de los aprendizajes de la implementación de CSFS fue que hace que los convenios sean más complejos al requerir que los datos de las transacciones se coloquen en la pila al realizar un gasto de convenio. También se observó a partir de la experiencia de los desarrolladores que con los convenios CSFS, los datos de las transacciones que componen el hash de la firma deben reconstruirse en la pila, lo que podría obligar a los desarrolladores a enviar datos irrelevantes para las entradas/salidas de las transacciones que les interesan.
Para simplificar la construcción de pactos, se crearon más de 30 nuevos códigos de operación llamados códigos de operación de introspección se introdujeron en Taproot de Liquid actualizar para un enfoque más modular. Los códigos de operación de introspección con CSFS, por ejemplo, permiten la inspección de partes más granulares de la transacción durante un gasto colocándola en la pila. Esto alivia la responsabilidad de recopilar datos de transacciones parciales a través del testigo y, por lo tanto, el hash de firma en la pila.
Propuestas de pacto líderes
Actualmente, la Bitcoin La comunidad está discutiendo una larga lista de posibles propuestas de pactos, que incluyen SIGHASH_ANYPREVOUT (APO), OP_TXHASH, CSFS, OP_CAT, OP_TLUV, el código de operación MATT OP_CHECKCONTRACTVERIFY (CCV), OP_VAULT y OP_CHECKTEMPLATEVERIFY (CTV). Sencillez, un lenguaje de secuencias de comandos de próxima generación que podría implementar una funcionalidad similar a muchos convenios en un nivel inferior, también es una ruta potencial para Bitcoin (revisaremos esto más adelante).
Se ha hablado mucho sobre el código de operación VAULT, que se creó para abordar la necesidad de encontrar formas más sencillas de proteger bitcoin para los usuarios. Este código de operación permitiría bloquear monedas en una dirección que solo puede gastarse en dos direcciones: una billetera activa después de un bloqueo de tiempo o inmediatamente en una billetera fría. Se han propuesto varias otras variantes de esquemas, pero dependen de que se adopte primero el CTV.
CTV es un código de operación que lee un hash de la pila y lo compara con un hash de un subconjunto específico de los datos de la transacción de gasto. Su flexibilidad promete permitir un conjunto diverso de aplicaciones que incluyen, entre otras: control de congestión, bóvedas y grupos de pagos rudimentarios.
Además de los códigos de operación, ha habido propuestas de sighashes para habilitar convenios. Las dos propuestas más populares para este propósito son APO y SIGHASH_GROUP. APO es una evolución del código de operación SIGHASH_NOINPUT, que es ampliamente reconocido como un requisito previo para implementar eltoo. Una de las muchas mejoras posibles con eltoo es la eliminación del mecanismo de penalización que obliga a la otra parte a perder fondos cuando transmite un estado de canal desactualizado. Esto permite una Lightning Network más fácil de usar y eficiente.
Lograr una funcionalidad similar con códigos de operación líquidos
Si bien Liquid no tiene los códigos de operación CTV y VAULT, sí tiene CSFS y CAT por pactos. Al utilizar estos códigos de operación definidos de manera más estricta con los códigos de operación de introspección antes mencionados, los desarrolladores han abierto nuevas posibilidades financieras con funcionalidades similares a CTV y VAULT para aumentar la cadena lateral.
Por ejemplo, Burak, un experimentado desarrollador de Liquid y creador del protocolo de capa 2 Ark, ha demostrado una emulación de BÓVEDA usando códigos de operación de Liquid Covenant en una discusión con James O'Beirne en X.
De manera similar, CSFS hizo posible una forma de lograr la funcionalidad APO. Este manifestación utilizó varios códigos de operación que habilitarían protocolos de capa 2 como eltoo en Liquid hoy en día, pero adolece de una complejidad adicional y un tamaño de transacción mayor en comparación con el uso propuesto del convenio tipo APO. Además, la construcción no se aplica a las transacciones Taproot, lo que introduciría su propia forma de complejidad adicional.
Códigos de operación líquidos en acción
Muchas aplicaciones ya han aprovechado los códigos de operación de covenant en Liquid. Steven Roose, un proponente del pacto que recientemente se define una especificación para el OP_TXHASH previamente ideado, ha desarrollado un solicitud en línea. para bonos de fidelidad en Liquid. Este pacto se aplica a fondos que se quemarían si se presentara en el testigo evidencia de un doble gasto.
dinero fujiFuji USD (FUSD), una moneda estable algorítmica desarrollada por Vulpem Ventures, es otro ejemplo notable. Se basa exclusivamente en información de Oracle para mantener su vinculación y puede emitirse de forma descentralizada. Utiliza un combinación de verificaciones de firmas y códigos de operación de introspección para lograr esto, y la parte más importante es que todo es auditable en cadena.
Otras aplicaciones de convenios sobre Liquid incluyen contratos de opciones y préstamos confidenciales basados en activos. El equipo de Blockstream Research publicó un whitepaper el año pasado (ver adjunto del blog) sobre el primero, explicando cómo se podría construir dicho contrato de opciones utilizando el nuevo conjunto de códigos de operación introspectivos. Estos nuevos códigos de operación permiten a los usuarios crear sin confianza tokens que representen ambos lados de un contrato de opción de compra cubierto y vender la posición opuesta que desean tomar. Los contratos realizados de esta manera también admiten cumplimientos parciales, lo que significa que el usuario que creó el contrato puede vender posiciones que representan un múltiplo de una cantidad mínima especificada por el usuario del activo colateral, llamado "tamaño del contrato".
¿Por qué no consumir líquido primero?
A este tenor, Bitcoin El ecosistema continúa teniendo un debate saludable sobre los códigos de operación de covenant, Liquid ofrece su propio conjunto de herramientas, que atienden objetivos similares pero con implementaciones distintas. A medida que evolucione el diálogo, será intrigante presenciar la interacción entre BitcoinLas propuestas nativas de Liquid y las características ya concretas y vivas relacionadas con el pacto y la emulación de Bitcoin Propuestas de pacto implementadas utilizando Elements Script.
Otra nueva tecnología en el horizonte es Sencillez, un lenguaje de programación verificable para el blockchain. El lenguaje Simplicity se define por operaciones con una semántica muy estrecha que pueden crear programas expresivos cuando se componen juntos. El lenguaje también es verificable, lo que significa que se pueden establecer métodos para probar matemáticamente afirmaciones hechas en programas Simplicity.
La naturaleza expresiva de Simplicity permite que los códigos de operación de Script se transfieran sin problemas, lo que garantiza una mayor confiabilidad y menos comportamientos inesperados. Bitcoin investigador Sanket Kanjalkar Ya ha realizado este trabajo para CTV. Usando Jerga, más legible BitcoinEn un lenguaje de programación centrado en Simplicity, pudo replicar la semántica en una prueba de concepto viable que cualquiera puede probar hoy.
Bitcoin los desarrolladores pronto tendrán la oportunidad de utilizar s-lang en un entorno real gracias a la integración de Simplicity de Liquid, prevista para el segundo trimestre de 2. s-lang traerá la construcción de aplicaciones más complejas a Liquid, como bóvedas y delegación. El borrador del PR está disponible para su revisión en el siguiente liga.
Con una larga historia de Liquid como uno de los primeros en adoptar ideas que luego se trasladaron a Bitcoin, una sugerencia para aquellos que buscan mostrar la viabilidad de sus propuestas es probarlo en vivo en Liquid para validar las ideas primero, ya que se ha demostrado que múltiples códigos de operación relacionados con covenant son emulables utilizando códigos de operación de introspección y covenant de Liquid existentes.
Entonces, la próxima vez que alguien sugiera un nuevo pacto, vale la pena preguntarse: ¿por qué no probarlo primero con Liquid?
Se trata de un puesto de invitado por Randy Naar. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Revista.
Fuente original: Bitcoin Revista