visión general

en comparación con las blockchains completas de Turing como Ethereum, se considera que la programación de Bitcoin es altamente restrictiva, capaz solo de realizar operaciones básicas e incluso carece de soporte para multiplicación y división. Además, los datos propios de la cadena de bloques son casi inaccesibles para los scripts, lo que resulta en una falta significativa de flexibilidad y capacidad de programación. Por lo tanto, ha habido un esfuerzo prolongado para permitir que los scripts de Bitcoin logren la introspección.

La introspección se refiere a la capacidad de los scripts de Bitcoin de inspeccionar y restringir los datos de transacción. Esto permite que los scripts controlen el uso de los fondos basándose en detalles de transacción específicos, lo que permite funcionalidades más complejas. Actualmente, la mayoría de los opcodes de Bitcoin empujan datos suministrados por el usuario en la pila o manipulan datos existentes en la pila. Sin embargo, los opcodes de introspección pueden empujar datos de la transacción actual (como marcas de tiempo, cantidades, txid, etc.) en la pila, lo que permite un control más granular sobre el gasto de UTXO.

Hasta ahora, solo tres códigos principales en el script de Bitcoin admiten inspección: checklocktimeverify, checksequenceverify y checksig, junto con sus variantes checksigverify, checksigadd, checkmultisig y checkmultisigverify.

El pacto, simplemente dicho, se refiere a restricciones sobre cómo se transfieren las monedas, lo que permite a los usuarios especificar cómo se distribuyen los utxos. Muchos pactos se implementan a través de opcodes de introspección, y las discusiones sobre la introspección ahora se han categorizado bajo el tema de los pactos en Gate.io.Bitcoin optech.

Bitcoin tiene actualmente dos convenios, CSV (CheckSequenceVerify) y CLTV (CheckLockTimeVerify), ambos convenios basados en el tiempo que son fundamentales para muchas soluciones de escalado como Lightning Network. Esto ilustra cómo las soluciones de escalado de Bitcoin se basan en gran medida en la introspección y los convenios.

¿cómo agregamos condiciones a la transferencia de monedas? En el criptoespacio, nuestro método más común es a través de compromisos, a menudo implementados mediante hashes. Para demostrar que se cumplen los requisitos de transferencia, también se necesitan mecanismos de firma para la verificación. Por lo tanto, existen numerosos ajustes de hashes y firmas dentro de los convenios.

a continuación, describiremos la propuesta ampliamente discutida del código de operación del pacto.

ctv (checktemplateverify) bip-119

ctv (checktemplateverify) es una propuesta de mejora de Bitcoin contenida en BIP-119 que ha captado la atención significativa de la comunidad. CTV permite que el script de salida especifique una plantilla para gastar los fondos en una transacción, incluyendo campos como nversión, nlocktime, scriptsig hash, conteo de entradas, secuencias hash, conteo de salidas, salidas hash, índice de entrada. Estas restricciones de plantilla se implementan a través de un compromiso hash, y cuando se gastan los fondos, el script verifica si los valores hash de los campos especificados en la transacción de gasto coinciden con los valores hash en el script de entrada. Esto confina efectivamente el tiempo, el método y la cantidad de transacciones futuras de ese UTXO.

notablemente, el txid de entrada está excluido de este hash. esta exclusión es necesaria, ya que en las transacciones heredadas y segwit, el txid depende de los valores en el scriptpubkey al usar el tipo de firma default sighash_all. incluir el txid llevaría a una dependencia circular en el compromiso de hash, lo que lo haría imposible de construir.

ctv implementa la introspección extrayendo directamente la información de transacción especificada para su hash y comparándola con el compromiso en la pila. este método de introspección requiere menos espacio en la cadena pero carece de cierta flexibilidad.

La base de las soluciones de capa dos de Bitcoin, como Lightning Network, son las transacciones pre-firmadas. La prefirma generalmente se refiere a generar y firmar transacciones por adelantado, pero no transmitirlas hasta que se cumplan ciertas condiciones. Esencialmente, CTV implementa una forma más rigurosa de pre-firma, publicando el compromiso de pre-firma en Chain, restringido a la plantilla predefinida.

ctv fue propuesto inicialmente para aliviar la congestión en bitcoin, que también puede ser referida como control de congestión. Durante períodos de alta congestión, ctv puede comprometerse con múltiples transacciones futuras dentro de una sola transacción, evitando la necesidad de transmitir múltiples transacciones durante los momentos de mayor demanda y completando las transacciones reales una vez que la congestión disminuye. Esto podría ser particularmente útil durante las corridas bancarias de intercambio. Además, la plantilla también se puede utilizar para implementar bóvedas para protegerse contra ataques de piratería informática. Dado que la dirección de los fondos está predeterminada, los piratas informáticos no pueden dirigir utxos utilizando scripts de ctv a sus propias direcciones.

ctv puede mejorar significativamente las redes de capa dos. Por ejemplo, en la red Lightning, ctv puede permitir la creación de árboles de tiempo de espera y fábricas de canales al expandir un único utxo en un árbol de ctv, abriendo múltiples canales de estado con solo una transacción y una confirmación. Además, ctv también admite intercambios atómicos en el protocolo ark a través de atlc.

apo (sighash_anyprevout) bip-118

bip-118 introduce un nuevo tipo de bandera de hash de firma para tapscript, con el objetivo de facilitar una lógica de gasto más flexible conocida como sighash_anyprevout. apo y ctv comparten muchas similitudes. al abordar el problema cíclico entre scriptpubkeys y txids, el enfoque de apo es excluir la información de entrada relevante y solo firmar las salidas, lo que permite a las transacciones vincularse dinámicamente a diferentes utxos.

Lógicamente, la operación de verificación de firma op_checksig (y sus variantes) realiza tres funciones:

1. ensamblar las partes de la transacción de gasto.
2. hashearlos.
3. verificando que el hash haya sido firmado por una clave dada.

los detalles de la firma tienen mucha flexibilidad, con la decisión sobre qué campos de transacción firmar determinada por la bandera de sighash. según la definición de códigos de operación de firma en bip 342, las banderas de sighash se dividen en sighash_all, sighash_none, sighash_single y sighash_anyonecanpay. sighash_anyonecanpay controla las entradas, mientras que las otras controlan las salidas.

sighash_all es la bandera de sighash predeterminada, que firma todas las salidas; sighash_none no firma ninguna salida; sighash_single firma una salida específica. sighash_anyonecanpay se puede configurar con las tres primeras banderas de sighash. Si se establece sighash_anyonecanpay, solo se firma la entrada especificada; de lo contrario, todas las entradas deben ser firmadas.

claramente, estas banderas de sighash no eliminan la influencia de las entradas, incluso sighash_anyonecanpay, que requiere comprometerse con una entrada.

así, bip 118 propone sighash_anyprevout. la firma apo no necesita comprometerse con el utxo de entrada gastado (conocido como prevout), sino que solo necesita firmar las salidas, lo que proporciona una mayor flexibilidad en el control de bitcoin. mediante la construcción previa de transacciones y la creación de claves públicas y firmas de un solo uso correspondientes, los activos enviados a esa dirección de clave pública deben ser gastados a través de la transacción preconstruida, lo que implementa un pacto. la flexibilidad de apo también se puede utilizar para la reparación de transacciones; si una transacción está atascada en la cadena debido a tarifas bajas, se puede crear fácilmente otra transacción para aumentar la tarifa sin necesidad de una nueva firma. además, para billeteras de múltiples firmas, no depender de las entradas gastadas hace que las operaciones sean más convenientes.

Ya que elimina el ciclo entre scriptpubkeys e input txids, apo puede realizar introspección añadiendo datos de salida en el witness, aunque esto aún requiere un consumo adicional de espacio en el witness.

para los protocolos fuera de la cadena como la red de relámpagos y las bóvedas, apo reduce la necesidad de guardar estados intermedios, lo que reduce en gran medida los requisitos de almacenamiento y complejidad. El caso de uso más directo de apo es eltoo, que simplifica las fábricas de canales, construye torres de vigilancia ligeras y económicas, y permite salidas unilaterales sin dejar estados erróneos, mejorando el rendimiento de la red de relámpagos de muchas maneras. Apo también se puede utilizar para simular funciones de ctv, aunque requiere que los individuos almacenen firmas y transacciones prefirmadas, lo que es más costoso y menos eficiente que ctv.

la principal crítica de apo se centra en su necesidad de una nueva versión de clave, que no se puede implementar simplemente siendo compatible con versiones anteriores. además, el nuevo tipo de hash de firma puede introducir riesgos potenciales de doble gasto. después de extensas discusiones en la comunidad, apo ha añadido firmas regulares sobre el mecanismo de firma original para aliviar las preocupaciones de seguridad, obteniendo así el código bip-118.

op_vault bip-345

bip-345 propone la adición de dos nuevos opcodes, op_vault y op_vault_recover, que, combinados con ctv, implementan un convenio especial que permite a los usuarios hacer cumplir un retraso en el gasto de monedas específicas. Durante este retraso, una transacción previamente realizada puede ser "revertida" a través de un camino de recuperación.

los usuarios pueden crear una bóveda creando una dirección de taproot específica que debe contener al menos dos scripts en su mastín: uno con el opcode op_vault para facilitar el proceso de retiro esperado, y otro con el opcode op_vault_recover para asegurar que las monedas se puedan recuperar en cualquier momento antes de la finalización del retiro.

¿Cómo implementa op_vault retiros con bloqueo de tiempo interrumpibles? Op_vault lo logra reemplazando el script op_vault gastado con un script especificado, actualizando efectivamente una sola hoja del árbol mientras deja sin cambios el resto de los nodos hoja de taproot. Este diseño es similar al de tluv, excepto que op_vault no admite actualizaciones a la clave interna.

al introducir una plantilla durante el proceso de actualización del script, es posible limitar los pagos. el parámetro de bloqueo de tiempo se especifica mediante op_vault, y la plantilla del opcode ctv restringe el conjunto de salidas que se pueden gastar a través de esta ruta de script.

bip-345 está diseñado específicamente para bóvedas, aprovechando op_vault y op_vault_recover para proporcionar a los usuarios un método custodial seguro que utiliza una clave altamente segura (como una billetera de papel o un multisig distribuido) como camino de recuperación, al mismo tiempo que configura un cierto retraso para los pagos regulares. Los dispositivos de los usuarios monitorean continuamente los gastos de la bóveda, y si ocurre una transferencia inesperada, los usuarios pueden iniciar una recuperación.

La implementación de Vault a través de BIP-345 requiere consideración de problemas de costos, especialmente para transacciones de recuperación. Las posibles soluciones incluyen CPFP (Child Pays for Parent), anclajes temporales y nuevas banderas de hash de firma de grupo de Sighash.

tluv (tapleafupdateverify)

el esquema tluv se basa en taproot y tiene como objetivo abordar eficientemente el problema de salir de los utxos compartidos. El principio rector es que cuando se gasta una salida de taproot, se pueden realizar actualizaciones parciales en la clave interna y el mástil (tapscript trie) a través de transformaciones criptográficas y la estructura interna de la dirección de taproot, como se describe en el script tluv. Esto permite la implementación de funciones de convenio.

El concepto del esquema tluv es crear una nueva dirección taproot basada en la entrada de gasto actual mediante la introducción de un nuevo opcode, tapleaf_update_verify. Esto se puede lograr realizando una o más de las siguientes acciones:

1. actualizar la clave pública interna
2. recortar la ruta de Merkle
3. eliminar el script que se está ejecutando actualmente
4. agregar un nuevo paso al final del camino de Merkle

específicamente, tluv acepta tres entradas:

1. uno que especifica cómo actualizar la clave pública interna.
2. uno que especifica un nuevo paso para la ruta de Merkle.
3. uno que especifica si eliminar o no el script actual y/o cuántos pasos de la ruta de Merkle recortar.

El opcode tluv calcula el scriptpubkey actualizado y verifica que la salida correspondiente a la entrada actual se gaste en este scriptpubkey.

tluv está inspirado en el concepto de coinpool. hoy en día, se pueden crear grupos conjuntos utilizando solo transacciones prefirmadas, pero si se desea realizar salidas no autorizadas, sería necesario crear un número de firmas que crece exponencialmente. Sin embargo, tluv permite salidas no autorizadas sin ninguna pre-firma. Por ejemplo, un grupo de socios podría utilizar taproot para construir un utxo compartido, agrupando sus fondos juntos. Pueden mover fondos internamente utilizando la clave taproot o firmar conjuntamente para iniciar pagos externamente. Las personas pueden salir del grupo compartido de fondos en cualquier momento, eliminando sus rutas de pago, mientras que otras personas aún pueden completar pagos a través de las rutas originales, y la salida de la persona no expone información adicional sobre otras personas en el interior. Este modo es más eficiente y privado en comparación con las transacciones no agrupadas.

El opcode tluv logra restricciones de gasto parcial actualizando el árbol de taproot original, pero no implementa la introspección del monto de salida. Por lo tanto, también se necesita un nuevo opcode, in_out_amount. Este opcode empuja dos elementos a la pila: la cantidad de la utxo para esta entrada y la cantidad para la salida correspondiente, luego se espera que aquellos que usan tluv utilicen operadores matemáticos para verificar que los fondos se mantengan adecuadamente en el scriptpubkey actualizado.

La introspección de las cantidades de salida añade complejidad porque las cantidades en satoshis necesitan hasta 51 bits para representarse, pero los scripts solo permiten operaciones matemáticas de 32 bits. Esto requiere redefinir el comportamiento del opcode para actualizar los operadores en los scripts o usar sighash_group para reemplazar in_out_amount.

tluv tiene potencial como solución para grupos de financiación descentralizados de capa 2, aunque todavía se necesita confirmación en cuanto a la fiabilidad de ajustar el trie de taproot.

matt

matt (merkleize all the things) tiene como objetivo lograr tres objetivos: merkleizar el estado, merkleizar el script y merkleizar la ejecución, lo que permite contratos inteligentes universales.

1. merkleizar el estado: esto implica construir un árbol de Merkle, donde cada nodo hoja representa el hash de un estado, con la raíz de Merkle que encarna el estado general del contrato.
2. merkleizando el script: esto se refiere a la formación de un mástil utilizando tapscript, donde cada nodo hoja representa una posible ruta de transición de estado.
3. merkleizing execution: la ejecución se merkleiza a través de compromisos criptográficos y un mecanismo de desafío de fraude. para cualquier función computacional, los participantes pueden calcular fuera de la cadena y luego publicar un compromiso, f(x)=y. si otros participantes encuentran un resultado erróneo, f(x)=z, pueden iniciar un desafío. la arbitraje se lleva a cabo mediante búsqueda binaria, similar al principio de rollup optimista.

merkleizing de la ejecución

para implementar matt, el lenguaje de script de bitcoin necesita tener las siguientes funcionalidades:

1. forzar una salida para tener un script determinado (y sus cantidades)
2. adjuntar un fragmento de datos a una salida
3. leer los datos desde la entrada actual (o desde otra)

El segundo punto es crucial: los datos dinámicos significan que el estado puede ser calculado a través de los datos de entrada proporcionados por el gastador, ya que esto permite la simulación de una máquina de estados, capaz de determinar el siguiente estado y datos adicionales. El esquema de Matt implementa esto a través del opcode op_checkcontractverify (op_ccv), una fusión de los opcodes op_checkoutputcontractverify y op_checkinputcontractverify previamente propuestos, utilizando un parámetro de flags adicional para especificar el objetivo de la operación.

control sobre las cantidades de salida: el método más directo es la introspección directa; sin embargo, las cantidades de salida son números de 64 bits, lo que requiere aritmética de 64 bits, lo que presenta una complejidad significativa en la secuencia de comandos de Bitcoin. op_ccv adopta un enfoque de verificación aplazada, al igual que op_vault, donde todas las entradas al mismo resultado con ccv tienen sus cantidades de entrada sumadas, sirviendo como un límite inferior para la cantidad de esa salida. El aplazamiento se debe a que esta verificación ocurre durante el proceso de transacción en lugar de durante la evaluación del script de las entradas.

dada la universalidad de las pruebas de fraude, ciertas variantes del contrato matt deberían ser capaces de implementar todo tipo de contratos inteligentes o construcciones de capa 2, aunque se deben evaluar con precisión requisitos adicionales (como la retención de capital y los retrasos en el período de desafío); se requiere más investigación para evaluar qué aplicaciones son aceptables para las transacciones. por ejemplo, utilizando compromisos criptográficos y mecanismos de desafío de fraude para simular la función op_zk_verify, logrando rollups sin confianza en bitcoin.

en la práctica, las cosas ya están sucediendo. Johan Torås Halseth ha utilizado el opcode op_checkcontractverify de la propuesta de bifurcación suave de Matt para implementarelftrace, que permite que cualquier programa que admita compilación risc-v sea verificado en la cadena de bloques de Bitcoin, lo que permite que una parte dentro de un protocolo de contrato acceda a fondos a través de la verificación del contrato, y así vincule la verificación nativa de Bitcoin.

csfs (op_checksigfromstack)

desde la introducción del opcode apo, hemos aprendido que op_checksig (y sus operaciones relacionadas) son responsables de ensamblar transacciones, de hacer hash y de verificar firmas. sin embargo, el mensaje verificado por estas operaciones se deriva de la serialización de la transacción utilizando el opcode, y no permite especificar ningún otro mensaje. en términos simples, op_checksig (y sus operaciones relacionadas) sirven para verificar a través del mecanismo de firma si la utxo que se gasta como entrada de transacción ha sido autorizada para ser gastada por el titular de la firma, protegiendo así la seguridad de Bitcoin.

csfs, como su nombre lo sugiere, verifica la firma desde la pila. El opcode csfs recibe tres parámetros de la pila: una firma, un mensaje y una clave pública, y verifica la validez de la firma. Esto significa que las personas pueden pasar cualquier mensaje a la pila a través del testigo y verificarlo a través de csfs, lo que permite algunas innovaciones en Bitcoin.

La flexibilidad de csfs le permite implementar mecanismos como firmas de pago, delegación de autorización, contratos de oráculo, bonos de protección contra doble gasto y, lo más importante, introspección de transacciones. El principio de uso de csfs para la introspección de transacciones es bastante simple: si el contenido de la transacción utilizado por op_checksig se empuja a la pila a través del testigo, y la misma clave pública y firma se utilizan para verificar tanto con op_csfs como con op_checksig, y si ambas verificaciones pasan con éxito, entonces el contenido del mensaje arbitrario pasado a op_csfs es el mismo que la transacción de gasto serializada (y otros datos) implícitamente utilizados por op_checksig. Luego obtenemos datos de transacción verificados en la pila, que se pueden utilizar para aplicar restricciones a las transacciones de gasto con otros opcodes.

csfs a menudo aparece junto con op_cat porque op_cat puede conectar diferentes campos de la transacción para completar la serialización, lo que permite una selección más precisa de los campos de transacción necesarios para la introspección. Sin op_cat, el script no puede volver a calcular el hash a partir de los datos que se pueden verificar por separado, por lo que lo que realmente puede hacer es comprobar si el hash corresponde a un valor específico, lo que significa que las monedas solo pueden gastarse a través de una transacción específica única.

csfs puede implementar opcodes como cltv, csv, ctv, apo, etc., lo que lo convierte en un opcode de introspección versátil. Por lo tanto, también ayuda en las soluciones de escalabilidad para la capa2 de Bitcoin. La desventaja es que requiere agregar una copia completa de la transacción firmada en la pila, lo que puede aumentar significativamente el tamaño de las transacciones destinadas a la introspección utilizando csfs. En contraste, los opcodes de introspección de propósito único como cltv y csv tienen un sobrecosto mínimo, pero agregar cada nuevo opcode de introspección especial requiere cambios de consenso.

txhash (op_txhash)

op_txhash es un código de operación habilitado para introspección directa que permite al operador seleccionar y empujar el hash de un campo específico en la pila. Específicamente, op_txhash saca un indicador de txhash de la pila y calcula un txhash (etiquetado) basado en ese indicador, luego empuja el hash resultante de vuelta a la pila.

debido a las similitudes entre txhash y ctv, ha surgido una considerable cantidad de discusión dentro de la comunidad con respecto a los dos.

txhash puede considerarse como una actualización universal de ctv, que ofrece una plantilla de transacción más avanzada que permite a los usuarios especificar partes de una transacción de gasto de manera explícita, abordando muchos problemas relacionados con las tarifas de transacción. A diferencia de otros códigos operativos de convenio, txhash no requiere una copia de los datos necesarios en el testigo, reduciendo aún más los requisitos de almacenamiento; a diferencia de ctv, txhash no es compatible con nop y solo se puede implementar en tapscript; la combinación de txhash y csfs puede servir como una alternativa a ctv y apo.

desde la perspectiva de la construcción de pactos, txhash es más propicio para crear "pactos aditivos," donde todas las partes de los datos de transacción que desea fijar se empujan a la pila, se hashan juntas, y el hash resultante se verifica que coincida con un valor fijo; ctv es más adecuado para crear "pactos sustractivos," donde todas las partes de los datos de transacción que desea mantener libres se empujan a la pila. luego, utilizando un opcode sha256 en rollo, el hash comienza desde un estado intermedio fijo que se compromete con un prefijo de los datos de hash de transacción. las partes libres se hashan en este estado intermedio.

se espera que el campo txfieldselector definido en la especificación txhash se expanda a otros opcodes, como op_tx.

El BIP relacionado con el txhash está actualmente en estado de borrador en Github y no se le ha asignado un número.

op_cat

op_cat es un código de operación envuelto en misterio, originalmente abandonado por Satoshi Nakamoto debido a preocupaciones de seguridad, recientemente ha provocado una intensa discusión entre los principales desarrolladores de bitcoin e incluso ha estimulado la cultura de los memes en Internet. En última instancia, op_cat fue aprobada bajo BIP-347 y ha sido llamada la propuesta de BIP con más probabilidades de ser aprobada en los últimos tiempos.

de hecho, el comportamiento de op_cat es bastante simple: concatena dos elementos de la pila. ¿Cómo habilita la funcionalidad del convenio?

De hecho, la capacidad de concatenar dos elementos corresponde a una poderosa estructura de datos criptográficos: el Trie de Merkle. Para construir un Merkle Trie, solo se necesitan operaciones de concatenación y hashing, y las funciones de hash están disponibles en los scripts de Bitcoin. Por lo tanto, con op_cat, teóricamente podemos verificar las pruebas de Merkle dentro de los scripts de Bitcoin, que es uno de los métodos de verificación ligeros más comunes en la tecnología blockchain.

como se mencionó anteriormente, csfs, con la ayuda de op_cat, puede implementar un esquema de convenio universal. de hecho, sin csfs, aprovechando la estructura de las firmas de schnorr, op_cat en sí mismo puede lograr la introspección de transacciones.

en las firmas de Schnorr, el mensaje que debe ser firmado está compuesto por los siguientes campos:

estos campos contienen los elementos principales de una transacción. al colocarlos en el scriptpubkey o testigo y usar op_cat combinado con op_sha256, podemos construir una firma schnorr y verificarla usando op_checksig. si la verificación pasa, la pila retiene los datos de transacción verificados, logrando la introspección de la transacción. esto nos permite extraer y "verificar" varias partes de la transacción, como sus entradas, salidas, direcciones de destino o las cantidades de Bitcoin involucradas.

para principios criptográficos específicos, uno podría referirse al artículo de andrew poelstra, "cat and schnorr tricks".

En resumen, la versatilidad de op_cat le permite emular casi cualquier opcode de convenio. Una multitud de opcodes de convenio dependen de la funcionalidad de op_cat, lo que avanza significativamente su posición en la lista de fusión. Teóricamente, confiando únicamente en op_cat y en los opcodes existentes de Bitcoin, esperamos construir un rollup zk de BTC con confianza minimizada. StarkNet, Chakra y otros socios del ecosistema están empujando activamente para que esto suceda.

conclusión

a medida que exploramos las diversas estrategias para escalar Bitcoin y mejorar su programabilidad, queda claro que el camino a seguir implica una combinación de mejoras nativas, cálculos fuera de la cadena y capacidades de scripting sofisticadas.

sin una capa base flexible, es imposible construir una capa secundaria más flexible.

La escalabilidad de la computación fuera de la cadena es el futuro, pero la programabilidad de Bitcoin debe superarse para admitir mejor esta escalabilidad y convertirse en una verdadera moneda global.

sin embargo, la naturaleza del cálculo en bitcoin es fundamentalmente diferente de la de ethereum. bitcoin solo admite la “verificación” como forma de cálculo y no puede realizar cálculos generales, mientras que ethereum es inherentemente computacional, siendo la verificación un subproducto del cálculo. esta diferencia es evidente desde un punto: ethereum cobra una tarifa de gas por transacciones que no se ejecutan, mientras que bitcoin no lo hace.

los convenios representan una forma de contrato inteligente basado en la verificación en lugar de la computación. excepto por algunos fundamentalismos de satoshi, parece que todos consideran los convenios una buena opción para mejorar Bitcoin. sin embargo, la comunidad continúa debatiendo acaloradamente sobre qué enfoque se debe utilizar para implementar los convenios.

apo, op_vault, y tluv tienden hacia aplicaciones directas, y elegirlos puede lograr aplicaciones específicas de una manera más barata y eficiente. Los entusiastas de la red lightning preferirían apo para lograr ln-simetría; aquellos que buscan implementar una bóveda serían mejor atendidos por op_vault; para construir coinpool, tluv ofrece más privacidad y eficiencia. op_cat y txhash son más versátiles, con una probabilidad menor de vulnerabilidades de seguridad, y pueden implementar más casos de uso cuando se combinan con otros opcodes, quizás a costa de la complejidad del script. ctv y csfs han ajustado el procesamiento de la cadena de bloques, con ctv implementando salidas tardías y csfs implementando firmas tardías. matt se destaca con su estrategia de ejecución optimista y pruebas de fraude, utilizando la estructura del árbol de merkle para implementar contratos inteligentes universales, aunque aún requiere nuevos opcodes para capacidades introspectivas.

vemos que la comunidad de Bitcoin está discutiendo activamente la posibilidad de obtener convenios a través de una bifurcación suave. starknet ha anunciado oficialmente su entrada en el ecosistema de Bitcoin, planeando implementar liquidaciones en la red de Bitcoin dentro de seis meses después de la fusión de op_cat. chakra continuará monitoreando los últimos desarrollos en el ecosistema de Bitcoin, impulsará la fusión de la bifurcación suave op_cat y aprovechará la programabilidad que brindan los convenios para construir una capa de liquidación de Bitcoin más segura y eficiente.

descargo de responsabilidad:

1. Este artículo es reimpreso de [ Espejo]. Todos los derechos de autor pertenecen al autor original [chakra]. si hay objeciones a esta reimpresión, por favor contacte al Aprender en la puertaequipo y lo resolverán rápidamente.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. las traducciones del artículo a otros idiomas son realizadas por el equipo de aprendizaje de Gate.io. a menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.