Escrito por: Investigación de Chakras

Descripción general

En comparación con las cadenas de bloques completas de Turing, como Ethereum, los scripts de Bitcoin se consideran muy limitados y solo pueden realizar operaciones básicas y ni siquiera admiten la multiplicación y la división. Más importante aún, los datos de la cadena de bloques en sí son casi imposibles de leer mediante scripts, lo que resulta en una grave falta de flexibilidad y baja programabilidad. Por lo tanto, la gente lleva mucho tiempo intentando encontrar formas de hacer que los Bitcoin Scripts sean introspectivos.

La introspección se refiere a la capacidad de permitir que los scripts de Bitcoin inspeccionen y limiten los datos de las transacciones. Esto permite que los scripts controlen el uso de fondos en función de los detalles específicos de una transacción, lo que permite una funcionalidad más compleja. La mayoría de los códigos de operación actuales de Bitcoin (Opcodes) solo tienen dos funciones: insertar datos proporcionados por el usuario en la pila u operar con datos existentes en la pila. El código de operación de introspección puede enviar los datos de la transacción actual (como la marca de tiempo, el monto, el ID de la transacción, etc.) a la pila para proporcionar un control más detallado sobre cómo se gasta UTXO.

Actualmente, solo tres códigos de operación principales en Bitcoin Script admiten la introspección: CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY y CHECKSIG; también tiene variantes como CHECKSIGVERIFY, CHECKSIGADD, CHECKMULTISIG y CHECKMULTISIGVERIFY.

En pocas palabras, un contrato es una restricción sobre cómo se pueden transferir los tokens. Los usuarios pueden especificar el método de distribución de UTXO a través del contrato. Muchos contratos se implementan mediante códigos de operación de introspección, y la introspección ahora se analiza en las entradas de contratos en Bitcoin Optech.

Actualmente, Bitcoin tiene dos contratos, CSV (CheckSequenceVerify) y CLTV (CheckLockTimeVerify), ambos contratos por tiempo, que son la base de muchos planes de expansión, como Lightning Network. También podemos ver en esto que el plan de expansión de Bitcoin se basa en gran medida en la introspección y los contratos.

¿Cómo agregar restricciones a la transferencia de tokens? En el mundo del cifrado, el método más utilizado es el compromiso, que a menudo se implementa mediante hash. Para demostrar que cumplimos con los requisitos de transferencia, debemos verificarlo mediante un mecanismo de firma. Por lo tanto, hay muchos ajustes en los hashes y las firmas del contrato.

A continuación describimos la propuesta de código de operación de contrato ampliamente discutida.

CTV (CheckTemplateVerify) BIP-119

CTV (CheckTemplateVerify) es una actualización de Bitcoin muy discutida por la comunidad y incluida en BIP-119. CTV permite que el script de salida especifique la plantilla para usar los fondos en la transacción de gastos, incluidos nVersion, nLockTime, hash scriptSig, recuento de entrada, hash de secuencias, recuento de salida, hash de salida, índice de entrada y otros campos de la transacción. las restricciones se pasan a través de un hash. Para lograr esto, el script de gasto futuro verificará que el valor hash del campo especificado en la transacción de gasto coincida con el valor hash en el script de entrada. Estas plantillas en realidad limitan el tiempo, el método, la cantidad y otros detalles. de la transacción de gasto futuro de UTXO.

Vale la pena señalar que el TXID de entrada está excluido de la promesa de hash. Esta exclusión es necesaria, ya sea en transacciones Legacy o Segwit, en el tipo de firma predeterminado SIGHASH_ALL, se debe generar el TXID en función del valor de scriptPubKey. Por lo tanto, incluir el TXID provocará un bucle en la promesa hash, que no se podrá generar correctamente.

La forma en que CTV implementa la introspección es obtener directamente la información especificada de la transacción a través de un nuevo código de operación, aplicar hash y compararla con el compromiso en la pila. Este método de introspección consume menos espacio en la cadena, pero carece de cierta flexibilidad.

La base de las soluciones de segunda capa de Bitcoin, como Lightning Network, son las transacciones prefirmadas. La firma previa generalmente se refiere a generar y firmar transacciones por adelantado, pero no transmitirlas a la red hasta que se cumplan ciertas condiciones. En esencia, CTV implementa una función de firma previa más estricta: publica el compromiso firmado previamente directamente en la cadena y las transacciones solo se pueden realizar de acuerdo con la plantilla previa.

CTV se propuso originalmente para aliviar la congestión de Bitcoin, lo que también puede denominarse control de congestión. Cuando Bitcoin está relativamente congestionado, CTV se puede utilizar para realizar múltiples transacciones futuras a través de una sola transacción sin tener que transmitir múltiples transacciones durante la congestión, y luego completar la transacción real después de que se alivie la congestión del bloque. El control de la congestión puede ser de gran ayuda cuando un intercambio experimenta una corrida. Además, las plantillas también se pueden utilizar para implementar bóvedas para evitar ataques de piratas informáticos. Dado que se determina el destino de los fondos, el hacker no puede enviar el UTXO utilizando el script CTV a su propia dirección.

CTV puede aportar enormes mejoras a las redes de capa 2. Por ejemplo, para la implementación de Timeout Trees y fábricas de canales en Lightning Network, a través de CTV, un único UTXO se puede expandir a un árbol CTV y se pueden abrir múltiples canales estatales al mismo tiempo, mientras que solo hay una transacción y una confirmación. en la cadena. Además, CTV también brinda soporte para transacciones atómicas ATLC en el protocolo Ark.

APO (SIGHASH_ANYPREVOUT) BIP-118

BIP-118 propone un nuevo tipo de indicador hash firmado para tapscript para facilitar la escritura de una lógica de gasto más flexible, llamado SIGHASH_ANYPREVOUT. APO y CTV son similares en muchos aspectos. Frente al problema del bucle entre scriptPubKeys y TXID, la solución de APO es excluir la información relacionada de entrada y solo firmar la salida, de modo que las transacciones puedan vincularse dinámicamente a diferentes UTXO.

Lógicamente dividida, la operación de verificación de firma OP_CHECKSIG (y sus códigos de operación similares) tiene tres funciones:

1. Ensamblar las distintas partes de una transacción de gasto

2. Ha golpeado.

3. Verifique que el hash haya sido firmado por la clave proporcionada.

El contenido específico de la firma tiene mucho margen de ajuste. Los campos de transacción que se ensamblan para la firma están determinados por el indicador SIGHASH. De acuerdo con la definición del código de operación de firma BIP 342, los indicadores SIGHASH se dividen en SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, SIGHASH_ANYONECANPAY, etc., entre los cuales SIGHASH_ANYONECANPAY controla la entrada y el resto controla la salida.

SIGHASH_ALL es el indicador SIGHASH predeterminado, que firma todas las salidas; SIGHASH_NONE no firma ninguna salida; SIGHASH_SINGLE firma una salida específica. SIGHASH_ANYONECANPAY se puede configurar junto con los primeros tres indicadores SIGHASH. Si se configura SIGHASH_ANYONECANPAY, solo se firmará la entrada especificada; de lo contrario, todas las entradas deberán firmarse.

Obviamente, ninguna de estas banderas SIGHASH puede eliminar el impacto de la entrada. Incluso SIGHASH_ANYONECANPAY requiere un compromiso con una entrada.

Por tanto, BIP 118 propone SIGHASH_ANYPREVOUT. Las firmas APO no requieren que se gaste el UTXO de entrada (llamado PREVOUT), sino solo la salida, lo que proporciona una mayor flexibilidad para el control de Bitcoin. Al preconstruir la transacción y construir la firma de un solo uso y la clave pública correspondientes, los activos enviados a la dirección de la clave pública deben gastarse a través de la transacción preconstruida para implementar el contrato. La flexibilidad de APO también se puede utilizar para reparar transacciones. Si una transacción se atasca en la cadena debido a tarifas bajas, se puede crear fácilmente otra transacción con tarifas más altas sin requerir nuevas firmas. Además, en el caso de las carteras de firmas múltiples, las firmas no dependen de entradas gastadas, lo que facilita la operación.

Dado que se elimina el bucle entre scriptPubKeys y el TXID de entrada. APO puede implementar la introspección agregando datos de salida en el testigo (Testigo). Por supuesto, esto todavía requiere un consumo adicional de espacio de datos del testigo.

Para protocolos fuera de cadena como Lightning Network y Vault, APO reduce el estado intermedio que debe guardarse, lo que reduce en gran medida los requisitos y la complejidad del almacenamiento. El caso de uso más directo de APO es Eltoo, que simplifica la fábrica de canales, construye una torre de vigilancia liviana y económica y permite la salida unilateral sin dejar un estado de error, mejorando el rendimiento de Lightning Network en todos los aspectos. APO también se puede utilizar para simular las funciones de CTV, pero requiere que las personas almacenen firmas y transacciones prefirmadas, lo que es más costoso y no tan eficiente como CTV.

La principal crítica a APO es que requiere una nueva versión de clave, lo que no se puede lograr mediante pura compatibilidad con versiones anteriores. Además, los nuevos tipos de hash de firma pueden introducir riesgos potenciales de doble gasto. Después de extensas discusiones en la comunidad, APO solicitó la adición de una firma común además de la firma original. El problema de seguridad se solucionó y APO recibió el número BIP-118.

OP_VAULT BIP-345

BIP-345 propone agregar dos nuevos códigos de operación, OP_VAULT y OP_VAULT_RECOVER, que se combinarán con CTV para implementar un contrato dedicado que permita a los usuarios forzar un período de demora en el gasto de tokens específicos. Durante el período de demora, los datos anteriores se pueden restaurar. a través de la ruta de recuperación. Gaste "Deshacer".

Los usuarios pueden construir una bóveda creando una dirección Taproot específica. El MAST debe contener al menos dos scripts, un script OP_VAULT para facilitar el proceso de retiro esperado y otro script OP_VAULT_RECOVER para garantizar que, en cualquier momento antes de que se complete el retiro, las monedas puedan. ser restaurado.

OP_VAULT ¿Cómo implementar retiros interrumpibles con bloqueo de tiempo? En pocas palabras, el código de operación OP_VAULT logra una cosa: reemplaza el script OP_VAULT gastado con el script especificado, completando en realidad la actualización de un solo nodo hoja de MAST, dejando los nodos hoja restantes sin cambios. El diseño es similar a TLUV, excepto que OP_VAULT no admite actualizaciones de claves internas.

La introducción de plantillas durante el proceso de actualización del script puede lograr el efecto de limitar los pagos. Entre ellos, el parámetro de bloqueo de tiempo lo especifica OP_VAULT, y la plantilla aportada por el código de operación CTV limita el conjunto de salidas gastadas a través de esta ruta de script.

BIP-345 nació para bóvedas. Con OP_VAULT y OP_VAULT_RECOVER, los usuarios pueden tener un método de depósito seguro con una clave altamente segura (billetera de papel, firma múltiple distribuida) como ruta de recuperación, y el resto de la configuración de pago diario son ciertos gastos. demorado. El dispositivo del usuario monitorea continuamente los gastos de la bóveda y, si ocurre una transferencia inesperada, el usuario puede restaurarla.

BIP-345 requiere consideraciones de costos al implementar bóvedas, especialmente al restaurar transacciones. Las posibles soluciones incluyen CPFP, anclajes temporales y nuevos indicadores hash de firma como SIGHASH_GROUP.

TLUV (TapleafUpdateVerify)

La solución TLUV se basa en Taproot y tiene como objetivo resolver el problema de la salida eficiente de UTXO compartido. La idea rectora es que cuando se gasta una salida de Taproot, podemos actualizar parcialmente la clave interna y MAST utilizando la estructura interna y la transformación criptográfica de la dirección de Taproot de acuerdo con los pasos de actualización descritos en el script TLUV, realizando así la función de contrato. .

La idea de la solución TLUV es que a través de un nuevo código de operación TAPLEAF_UPDATE_VERIFY, pueda crear una nueva dirección Taproot basada en la entrada de consumo actual realizando una o más de las siguientes operaciones:

• Actualizar clave pública interna

• trazado de recorte merkle

• Eliminar el nodo hoja que se está ejecutando actualmente

• Agregue un nuevo nodo hoja al final de la ruta de Merkle

Específicamente, TLUV recibe tres entradas:

• Uno especifica cómo actualizar la clave pública interna.

• Uno especifica un nuevo nodo hoja para la ruta Merkle

• Uno especifica si se elimina el nodo hoja actual y/o cuántos nodos hoja de ruta de Merkle se eliminan.

El código de operación TLUV calcula la scriptPubKey actualizada y verifica que la salida correspondiente a la entrada actual consuma esa scriptPubKey.

El escenario inspirador de TLUV es CoinPool. Hoy en día es posible crear un grupo federado utilizando solo transacciones prefirmadas, pero si desea lograr una salida sin permiso, necesita crear una cantidad exponencialmente mayor de firmas, mientras que TLUV permite una salida sin permiso sin ninguna firma previa. Por ejemplo, un grupo de socios utilizó Taproot para crear un UTXO compartido que agrupaba los fondos de cada uno. Pueden usar claves Taproot para mover fondos internamente y también pueden firmar conjuntamente para iniciar pagos externamente. Las personas pueden retirarse del fondo compartido en cualquier momento y eliminar su propia ruta de pago. Otros aún pueden completar los pagos a través de la ruta original. Al mismo tiempo, el retiro del individuo no expondrá información adicional sobre otras personas internas. En comparación con las transacciones no agrupadas, este método es más eficiente y privado.

El código de operación TLUV implementa restricciones de gasto parciales al actualizar el MAST original, pero no implementa la introspección de la cantidad de salida. Por lo tanto, también es necesario incluir un nuevo código de operación IN_OUT_AMOUNT, que envía dos datos a la pila: la cantidad de esta entrada UTXO y la cantidad de la salida correspondiente, y luego espera que la persona que usa TLUV use operadores matemáticos para verificar que los fondos están correctamente reservados en scriptPubKey actualizado.

La introspección de la cantidad de salida agrega otra capa de complejidad, ya que la cantidad de Bitcoin requiere hasta 51 bits para representarse en satoshis, pero el script solo permite operaciones matemáticas de 32 bits y debe actualizarse en el script redefiniendo el operador de comportamiento del código de operación. , o utilice SIGHASH_GROUP en lugar de IN_OUT_AMOUNT.

Se espera que TLUV proporcione una solución para grupos de fondos descentralizados de Capa 2. Por supuesto, la confiabilidad de los ajustes de la clave pública de Taproot aún no se ha confirmado.

MATE

MATT (Merkleize All The Things) intenta lograr tres objetivos: estado basado en Merkle, scripts basados ​​en Merkle y ejecución basada en Merkle, y luego implementar contratos inteligentes universales.

Estado de Merkle: construya un Merkle Trie, en el que cada nodo hoja sea el valor hash del estado y Merkle Root represente el estado de todo el contrato.

Script Merkle: es decir, MAST compuesto por Tapscript. Cada nodo hoja es una posible ruta de transición de estado.

Ejecución de Merkle: la ejecución de Merkle se logra mediante compromisos cifrados y mecanismos de desafío de fraude. Para cualquier función de cálculo, los participantes pueden calcular fuera de la cadena y luego liberar un compromiso, f (x) = y, y otros participantes descubren que el resultado del cálculo es incorrecto f. (x) = z, puede desafiar y arbitrar mediante el método de dicotomía, que es el mismo principio que Optimistic Rollup.

Desafíos de fraude habilitados por Merkle

Para implementar MATT, los scripts de programación de Bitcoin deben tener la siguiente funcionalidad:

1. Forzar una salida para que tenga scripts específicos (y sus cantidades)

2. Agregar un dato a una salida

3. Leer datos de la entrada actual (u otra entrada)

El segundo punto es muy importante: los datos dinámicos significan que el estado se puede calcular a partir de los datos de entrada proporcionados por el consumidor, porque esto proporciona una simulación de la máquina de estados y puede determinar el siguiente estado con datos adicionales. La solución MATT se implementa proponiendo el código de operación OP_CHECKCONTRACTVERIFY (OP_CCV), que es una fusión de los códigos de operación OP_CHECKOUTPUTCONTRACTVERIFY y OP_CHECKINPUTCONTRACTVERIFY propuestos originalmente, y utiliza un parámetro de banderas adicional para especificar el objeto de la operación.

Control de la cantidad de salida: la forma más directa es mediante introspección directa. Sin embargo, la cantidad de salida es un número de 64 bits y requiere operaciones de 64 bits, lo cual es muy complejo en la implementación de scripts de Bitcoin. CCV adopta un método de verificación retrasada, similar a OP_VAULT. Todas las entradas con CCV a la misma salida tienen sus cantidades de entrada sumadas como el límite inferior de la cantidad de salida. El retraso se debe a que la verificación se realiza durante la transacción y no durante la evaluación del script ingresado.

Dada la generalidad de la protección contra el fraude, alguna variante del contrato MATT debería permitir todo tipo de contratos inteligentes o construcciones de segunda capa, aunque es necesario evaluar con precisión requisitos adicionales (como el bloqueo de capital y los retrasos en el período de desafío); para evaluar qué Aplicación es una transacción aceptable. Por ejemplo, el mecanismo de desafío de fraude y compromiso criptográfico se utiliza para simular la función OP_ZK_VERIFY para implementar un paquete acumulativo sin confianza en Bitcoin.

De hecho, ya está sucediendo. Johan Torås Halseth implementó elftrace utilizando el código de operación OP_CHECKCONTRACTVERIFY en la propuesta de bifurcación suave MATT, que puede verificar todos los programas que admiten la compilación RISC-V en la cadena de Bitcoin, lo que permite que una de las partes del contrato reciba fondos a través del contrato, logrando un puente. a la verificación nativa de Bitcoin.

CSFS (OP_CHECKSIGFROMSTACK)

Desde la introducción del código de operación APO, hemos aprendido que OP_CHECKSIG (y sus operaciones relacionadas) es responsable de ensamblar transacciones, hash y verificar firmas. Sin embargo, el mensaje que verifica se obtiene serializando la transacción utilizando este código de operación y no se permite especificar ningún otro mensaje. En pocas palabras, OP_CHECKSIG (y sus operaciones relacionadas) funcionan a través del mecanismo de firma para verificar si el UTXO utilizado como entrada de transacción está autorizado para ser gastado por el titular de la firma, protegiendo así la seguridad de Bitcoin.

CSFS, como sugiere el nombre, verifica las firmas de la pila. El código de operación 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 se pueden pasar mensajes arbitrarios a la pila a través de datos testigo y hacer que CSFS los verifique. lo que hace que algunas innovaciones en la moneda sean posibles.

Las características flexibles de CSFS le permiten implementar múltiples mecanismos, como firmas de pago, delegación de autoridad, contratos de Oracle, bonos de protección de doble gasto, etc. y, lo que es más importante, puede realizar una introspección de transacciones. El principio de utilizar CSFS para la introspección de transacciones es muy simple. Si el contenido de la transacción utilizado por OP_CHECKSIG se envía a la pila a través del testigo, se utilizan la misma clave pública y firma para verificar el contenido tanto con CSFS como con OP_CHECKSIG. , entonces el contenido de cualquier mensaje pasado a CSFS es el mismo que el de la transacción de gasto serializada (y otros datos) utilizado implícitamente para OP_CHECKSIG. Hemos verificado los datos de la transacción en la pila y podemos aplicar otros códigos de operación al límite de la transacción.

CSFS generalmente aparece junto con OP_CAT, porque OP_CAT puede conectar diferentes campos de la transacción para completar la serialización y puede seleccionar con mayor precisión los campos de la transacción que deben ser introspeccionados. Sin OP_CAT, el script no puede recalcular el hash a partir de datos que se pueden verificar individualmente, por lo que todo lo que realmente puede hacer es verificar si el hash es igual a un valor específico, lo que significa que la moneda solo se puede gastar a través de una única transacción específica.

CSFS puede implementar CLTV, CSV, CTV, APO y otros códigos de operación. Es un código de operación de introspección general, por lo que también puede ayudar al plan de expansión de la Capa 2 de Bitcoin. La desventaja es que es necesario agregar una copia completa de la transacción firmada a la pila, lo que puede aumentar significativamente el tamaño de las transacciones que desea realizar introspección con CSFS. En comparación, los códigos de operación de introspección de propósito único como CLTV y CSV utilizan una sobrecarga mínima, pero agregar cada nuevo código de operación de introspección especial requiere un cambio de consenso.

TXHASH (OP_TXHASH)

OP_TXHASH es un código de operación de introspección muy sencillo que permite al operador seleccionar un hash de un campo para insertarlo en la pila. Específicamente, OP_TXHASH sacará un indicador txhash de la pila, calculará un txhash (etiquetado) basado en ese indicador y enviará el hash resultante a la pila.

Debido a las similitudes entre TXHASH y CTV, ha habido mucha discusión sobre los dos en la comunidad.

TXHASH puede verse como una actualización general de CTV, que proporciona una plantilla de transacción más avanzada que permite a los usuarios gastar explícitamente una parte de una transacción, lo que resuelve muchos problemas relacionados con las tarifas de transacción. En comparación con otros códigos de operación de contrato, TXHASH no necesita proporcionar una copia de los datos requeridos en el testigo, lo que reduce aún más la necesidad de almacenamiento. A diferencia de CTV, TXHASH no es compatible con NOP y solo se puede implementar en la combinación de TXHASH y; CSFS puede considerarse como una alternativa a CTV y APO.

Desde la perspectiva de la forma en que se construye el contrato, TXHASH facilita la implementación de un "contrato aditivo" al insertar todas las partes de los datos de la transacción que desea fijar en la pila, combinarlas todas juntas y verificar que el hash resultante coincide con el valor fijo de CTV. Es más fácil implementar "contratos sustractivos", colocando todas las partes de los datos de la transacción que desea mantener libres en la pila. Luego use OP_SHA256 rodante para comenzar desde un estado intermedio fijo que confirma el prefijo de los datos hash de la transacción. La parte libre se convierte en hash a este estado intermedio.

Se espera que el campo TxFieldSelector definido en la especificación TXHASH se extienda a otros códigos de operación, como OP_TX.

El BIP relacionado con TXHASH se encuentra actualmente en estado de borrador en Github y aún no ha sido numerado.

OP_CAT

OP_CAT es un código de operación bastante misterioso. Fue abandonado por Satoshi Nakamoto debido a problemas de seguridad. Recientemente ha provocado una gran cantidad de discusiones entre los desarrolladores principales de Bitcoin e incluso desencadenó una cultura Meme en Internet. Al final, OP_CAT fue aprobado por. BIP-347 y fue Mucha gente la llama la propuesta BIP con mayor probabilidad de ser aprobada en un futuro cercano.

De hecho, OP_CAT se comporta de forma muy sencilla: concatena dos elementos de la pila en uno. ¿Cómo implementar la función de contrato?

De hecho, la función de empalmar dos elementos corresponde a una poderosa estructura de datos criptográficos, el Merkle Trie. El proceso de construcción de Merkle Trie solo requiere dos operaciones: empalme y hash, y en los scripts de Bitcoin, las funciones hash están disponibles. Por lo tanto, con OP_CAT, teóricamente podemos verificar Merkle Proof en un script de Bitcoin, que es el método de verificación liviano más comúnmente utilizado en blockchain.

Como se mencionó anteriormente, CSFS, con la ayuda de OP_CAT, puede implementar un esquema de contrato común. De hecho, el propio OP_CAT puede implementar la introspección de transacciones sin CSFS, aprovechando la estructura de las firmas Schnorr.

En la firma Schnorr, el mensaje que debe firmarse se compone de los siguientes campos:

Estos campos contienen los elementos principales de la transacción. Al colocarlos en un scriptPubKey o testigo, usando OP_CAT y OP_SHA256, podemos construir una firma Schnorr y verificarla usando OP_CHECKSIG. Si se supera la verificación, los datos de la transacción verificada se retienen en la pila, lo que permite la introspección de la transacción, con la capacidad de extraer y "examinar" varias partes de la transacción, como sus entradas, salidas, dirección de destino o la cantidad de Bitcoin. involucrado.

Para conocer principios de criptografía específicos, consulte el artículo CAT y Schnorr Tricks publicado por Andrew Poelstra.

En resumen, la flexibilidad de OP_CAT le permite emular casi cualquier código de operación de contrato, y una gran cantidad de códigos de operación de contrato dependen de la funcionalidad de OP_CAT, lo que lo coloca significativamente por delante en la lista de fusión. En teoría, confiando únicamente en OP_CAT y los códigos de operación de Bitcoin existentes, podemos esperar construir un BTC ZK Rollup que minimice la confianza, y Starknet, Chakra y otros socios ecológicos están promoviendo esto activamente.

Conclusión

A medida que exploramos múltiples estrategias para escalar Bitcoin y aumentar su programabilidad, está claro que el camino a seguir implica una combinación de mejoras nativas, computación fuera de la cadena y capacidades sofisticadas de secuencias de comandos.

Sin una capa base flexible, no se puede construir una segunda capa más flexible.

La expansión de la informática fuera de la cadena es el futuro, pero debe haber un gran avance en la programabilidad de Bitcoin para respaldar mejor la expansión y convertirse en una moneda del mundo real.

Sin embargo, los cálculos de Bitcoin y Ethereum son en realidad fundamentalmente diferentes. Bitcoin solo admite la "verificación" como forma de cálculo y no puede realizar cálculos generales, mientras que Ethereum es de naturaleza computacional y la verificación es un subproducto del cálculo. Esta diferencia se puede ver desde un punto: Ethereum cobra una tarifa en forma de Gas por transacciones fallidas, mientras que Bitcoin no.

El contrato implementa una forma de contrato inteligente basado en la verificación en lugar del cálculo. En cuanto a los contratos, todos, excepto un puñado de fundamentalistas de Satoshi, parecen pensar que los contratos son una buena opción para mejorar Bitcoin. Sin embargo, la comunidad continúa debatiendo sobre qué método se debe utilizar para implementar el contrato.

APO, OP_VAULT y TLUV están más sesgados hacia aplicaciones directas y elegirlas puede implementar aplicaciones específicas de una manera más económica y eficiente. Los entusiastas de Lightning Network preferirán APO porque puede implementar LN-Symmetry; si desea implementar una bóveda, es mejor usar OP_VAULT para construir CoinPool, use TLUV para mayor privacidad y eficiencia; OP_CAT y TXHASH son más versátiles y es menos probable que tengan vulnerabilidades de seguridad. Al combinarlos con otros códigos de operación, se pueden lograr más casos de uso, aunque, por supuesto, es posible que deban pagar por la complejidad del script. CTV y CSFS han realizado ajustes en el proceso de procesamiento de blockchain. CTV ha implementado salida retrasada y CSFS ha implementado firmas retrasadas. MATT es relativamente único, utiliza las ideas de ejecución optimista y a prueba de fraude, y utiliza la estructura de Merkle Trie para implementar contratos inteligentes universales, pero aún necesita nuevos códigos de operación para brindar funciones de introspección.

Hemos visto que la comunidad Bitcoin ya está discutiendo intensamente la posibilidad de permitir que Bitcoin obtenga contratos a través de soft forks. Starknet anunció oficialmente su entrada al ecosistema Bitcoin y planea implementar la liquidación en la red Bitcoin dentro de los seis meses posteriores a la fusión OP_CAT. Chakra continuará prestando atención a las últimas tendencias en el ecosistema de Bitcoin, promoverá la fusión de las bifurcaciones suaves OP_CAT y utilizará la programabilidad aportada por la introspección y los contratos para construir una capa de liquidación de Bitcoin más segura y eficiente.

Gracias a Jeffrey, Ben, Mutourend y Lynndell por su revisión y sugerencias sobre este artículo.