jakiro
Autor: Chakra;
Este artículo es la Parte III publicada por la serie de expansión de Bitcoin publicada por Chakra.
La primera parte se refiere al artículo anterior «>Revisión del esquema de expansión nativa de Bitcoin: Segwit y Taproot«,,
La segunda parte se refiere al artículo anterior «>Escalabilidad de bitcoin: solución de Layer2 y análisis relacionado de proyectos«» «.
La tercera parte es este artículo, como sigue:
Descripción general
En comparación con la cadena de bloques integral, como Ethereum, Bitcoin Script se considera extremadamente limitado y solo puede realizar operaciones básicas, y ni siquiera admite la multiplicación y la eliminación.Más importante aún, los datos de la cadena de bloques apenas pueden acceder a los scripts, lo que resulta en graves deficiencias en la flexibilidad y la programación.Por lo tanto, las personas han estado trabajando duro para dejar que el guión de Bitcoin se den cuenta de la introspectura.
La provincia interna se refiere a la capacidad de la inspección de script de bitcoin y los datos de la transacción de restricción.Esto permite que el script controle el uso de fondos basados en detalles de transacciones específicos para lograr funciones más complejas.En la actualidad, la mayoría de los códigos de operación de Bitcoin presionan los datos proporcionados por el usuario a la pila o manipulan los datos existentes en la pila.Sin embargo, el código de operación interno puede llevar los datos de transacción actuales (como la marca de tiempo, la cantidad, TXID, etc.) a la pila, de modo que los gastos de UTXO puedan controlarse más finamente.
A partir de ahora, solo hay tres códigos operativos principales en los scripts de Bitcoin para admitir la provincia: CheckLockTimeoverify, CheckSeNVerify y CheckSig, y sus variantes CheckSigverify, CheckSigadd, CheckMultisig y CheckMulti.
El contrato (el pacto también se puede traducir como «restricciones»).Muchos contratos se logran a través del código operativo provincial interno.
Bitcoin actualmente tiene dos contratos, CSV (CheckSequenceVerify) y CLTV (CheckLockTimeoverify) se basan en contratos basados en el tiempo y son la base de muchas soluciones de expansión (como Lightning Network).Esto muestra que la solución de expansión de Bitcoin depende seriamente de la provincia y el contrato.
¿Cómo agregamos condiciones a la transferencia de tokens?En el campo de las criptomonedas, nuestro método más utilizado es lograr a través del compromiso y generalmente a través del hash.Para demostrar que se cumplen los requisitos de transferencia, el mecanismo de firma también se requiere para verificar.Por lo tanto, hay muchos ajustes al hash y las firmas en el contrato.
A continuación, describiremos la propuesta del código operativo del pacto ampliamente discutida.
CTV (checkTemplateify) BIP-119
CTV (checkTemplatingverify) es una propuesta de actualización de bitcoin en BIP-119, que ha atraído la atención generalizada de la comunidad.CTV permite que los scripts de salida especifiquen plantillas en transacciones, incluidas Nversion, NlockTime, ScriptSig Hash, Contado de entrada, hash de secuencia, conteo de salida, hash de salida, índice de entrada y otros campos.Estos límites de plantilla son implementados por las promesas hash.Esto limita efectivamente el tiempo, los métodos y las cantidades de la transacción futura UTXO.
Vale la pena señalar que la entrada TXID está excluida de este hash.Esta exclusión es necesaria porque en los testigos tradicionales y de aislamiento, cuando se usa el tipo de firma de suspirh_all predeterminado, TXID depende del valor en ScriptPubKey.La inclusión de TXID puede causar dependencias de circulación en los compromisos hash y no se puede construir.
El método interno de CTV es extraer directamente la información de transacción especificada para las operaciones hash y luego comparar con el compromiso en la pila.Esta provincia interna requiere bajos requisitos para el espacio en la cadena, pero carece de cierta flexibilidad.
La base de la solución de capas de 2 bitcoin (como Lightning Network) es la transacción nominada.El signo previo generalmente se refiere a la generación y firma de transacciones por adelantado, pero no las transmite antes de cumplir con ciertas condiciones.En esencia, CTV implementa una forma más estricta de NickName -Name, publicando las promesas prefirmadas en la cadena y limitado a la plantilla predefinida.
CTV se propuso originalmente para aliviar la congestión de Bitcoin, que también puede llamarse control congestionado.Cuando la congestión es grave, CTV puede prometer múltiples transacciones futuras en una sola transacción para evitar transmitir transacciones múltiples durante las horas pico, y completar las transacciones reales después de que se alivie la congestión.Esto puede ser particularmente útil durante los intercambios.Además, la plantilla se puede utilizar para implementar la bóveda para evitar la piratería.Dado que el flujo de fondos es predeterminado, los piratas informáticos no pueden usar el script CTV para apuntar UTXO a su dirección.
CTV puede mejorar significativamente la segunda capa de red.Por ejemplo, en la red Lightning, CTV puede crear un árbol de tiempo de espera y fábricas de canales extendiendo un solo UTXO a un árbol CTV.Además, CTV también admite transacciones atómicas en el protocolo ARK a través de ATLC.
Apo (sighash_anyprevout) BIP-118
BIP-118 introdujo un nuevo tipo de logotipo de hash firma a Tapscript, cuyo objetivo es promover una lógica de gastos más flexible, llamada sighash_anyprevout.Apo y CTV tienen muchas similitudes.Al resolver el ciclo entre ScriptPubKeys y TXID, el método APO es eliminar la información de entrada relevante y firmar solo la salida, de modo que la transacción puede unirse dinámicamente a diferentes utxo.
Lógicamente, la operación de verificación de firma OP_CHECKSIG (y sus variantes) ejecuta tres funciones:
1. Cada parte de la transacción de gastos de ensamblaje.
2. Hachs para ellos.
3. Verifique si el hash ha sido firmado por una clave determinada.
Los detalles específicos de la firma son muy flexibles, y el logotipo de Sighash determina qué campos de la transacción.Según la definición del código de operación de la firma en BIP 342, el logotipo de Sighash se divide en Sighash_all, Sighash_None, Sighash_single y Sighashonecanpay.Sighash_anyonecanpay controla la entrada, mientras que otra salida de control.
Sighash_all es el logotipo de Sighash predeterminado para firmar todas las salidas;Sighash_anyonecanpay se puede configurar con los primeros tres logotipos de Sighash.Si se establece sighash_anyonecanpay, solo la entrada especificada está firmada;
Obviamente, estos logotipos de Sighash no pueden eliminar el impacto de la entrada, incluso si es sighash_anyonecanpay, también necesita prometer una entrada.
Por lo tanto, BIP 118 propone sighash_anyprevout.La firma APO no necesita ser prometida para ingresar UTXO (denominada previa), pero solo necesita firmar la salida para proporcionar una mayor flexibilidad para el control de Bitcoin.Al prever la construcción de las transacciones y la creación de firmas de un solo tiempo correspondientes y las claves públicas, los activos enviados a la dirección de clave pública deben ser utilizadas mediante transacciones preconstruidas para lograr contratos.La flexibilidad de la APO también se puede usar para la reparación de la transacción;Además, para múltiples billeteras de firma, no confiar en las entradas que se han gastado hará que la operación sea más conveniente.
Debido a la eliminación del ciclo entre ScriptPubKeys y la entrada TXID, la APO puede ejecutar la provincia interna agregando datos de salida al testigo, aunque esto aún requiere un consumo adicional de espacio de testigos.
Para los lindests como las redes de rayos y las bóvedas (bóvedas), la APO reduce las necesidades de preservar el estado intermedio y reduce en gran medida los requisitos de almacenamiento y la complejidad.El caso de uso más directo de la APO es eltoo.La APO también se puede usar para simular la función CTV, aunque requiere que las personas almacenen transacciones de firma y pre -firma, que es más costosa y más eficiente que CTV.
La principal crítica de APO se concentra en TI requiere una nueva versión clave, y esto no se puede lograr con una simple compatibilidad hacia atrás.Además, el nuevo tipo de hash de firma puede traer riesgos potenciales de pago dual.Después de una amplia gama de discusiones comunitarias, APO ha agregado firmas convencionales al mecanismo de firma original para aliviar las preocupaciones de seguridad, obteniendo así el código BIP-118.
OP_Vault BIP-345
BIP-345 propone agregar dos nuevos códigos operativos, OP_Vault y OP_Vault_recover.Durante este retraso, las transacciones se realizaron antes de la ruta de recuperación «Revocar».
Los usuarios pueden crear bóveda creando una dirección de grifo específica. puede restaurar los tokens en cualquier momento antes de completar.
¿Cómo implementa OP_Vault interrumpido por retiro de retiro del tiempo?OP_Vault se implementa reemplazando el script Op_Vault utilizado por un script especificado, a fin de actualizar efectivamente la hoja única del mástil, mientras mantiene los nodos de hoja de grifos restantes sin cambios.Este diseño es similar a TLUV, pero OP_Vault no admite la actualización de las claves internas.
Al introducir plantillas durante la actualización del script, puede limitar el pago.El número de bloqueos de tiempo es especificado por Op_Vault.
BIP-345 está diseñado para bóvedas. cierto retraso para el pago regular.El dispositivo del usuario continuará monitoreando el gasto de la biblioteca de seguros.
El problema de costos es necesario para implementar bóveda a través de BIP-345, especialmente para la restauración de transacciones.Las posibles soluciones incluyen CPFP (el subnodo es pagado por el nodo principal), el punto de anclaje temporal y el nuevo logotipo de hash de firma sighash_group.
TLUV (TapleAfupDingify)
El esquema TLUV se construye alrededor de Taproot, cuyo objetivo es resolver efectivamente el problema de compartir la salida UTXO.El principio de guía es que cuando se usa la salida de grifo de tap, las teclas internas y el mástil (Tapscript Trie) pueden actualizarse parcialmente mediante la conversión cifrada y la estructura interna de la dirección de taproot, como se menciona en el script TLUV.Esto hace posible la implementación de la función del pacto.
El concepto del esquema TLUV es crear una nueva dirección de Taproot introduciendo el nuevo código operativo TapleAf_Update_verify.Esto se puede implementar realizando las siguientes operaciones o múltiples:
-
Actualizar la clave interna
-
Poda Merkle Path
-
Eliminar el script que actualmente se está ejecutando
-
Agregue nuevos pasos al final del camino de Merkle
Específicamente, TLUV acepta tres entradas:
-
Especifique cómo actualizar la clave pública interna.
-
Especifique un nuevo paso para la ruta de Merkle.
-
Especifique cuántos pasos para eliminar el script actual y/o recortar la ruta de Merkle.
El código operativo TLUV calcula el scriptPubkey actualizado y verifica si la salida de entrada actual correspondiente se gasta en este scriptpubkey.
La inspiración de TLUV proviene del concepto de coinpool.Hoy en día, el grupo de fondos United solo necesita firmar una transacción previa a la firma para crear, pero si desea salir sin una licencia, debe crear una firma doble.TLUV permite salir sin permisos con licencia, sin pre -firma.Por ejemplo, un socio grupal puede usar Taproot para construir un UTXO compartido para reunir sus fondos.Pueden usar la clave Taproot para transferir fondos internamente, o pueden firmar conjuntamente para iniciar el pago afuera.Las personas pueden retirarse del grupo de fondos compartidos en cualquier momento para eliminar su ruta de pago, y otras aún pueden completar el pago a través de la ruta original, y la salida del individuo no expondrá otra información sobre otras personas en el interior.En comparación con las transacciones que no son de inicio, este modelo es más eficiente y más privado.
El código operativo TLUV ha implementado algún límite de gastos al actualizar el Taproot TRIE original, pero no se da cuenta de una auto -intervención de la cantidad de salida.Por lo tanto, se necesita un nuevo código operativo en_out_amount.Este código operativo empuja los dos elementos a la pila: la cantidad de UTXO y la cantidad de salida correspondiente de esta entrada, y luego las personas que usan TLUV deben usar el símbolo de computación matemática para verificar si los fondos se conservan adecuadamente en el scriptPubkey actualizado.
Las provincias internas con las cantidades de salida aumentan la complejidad, porque se requiere que la cantidad de satoshis esté representada por hasta 51 dígitos, pero el script solo permite operaciones matemáticas de 32 dígitos.Esto requiere redefinir el comportamiento del código operativo para actualizar el operador en el script o usar el size_group para reemplazar el in_out_amount.
TLUV tiene el potencial de convertirse en una solución al segundo piso de la descentralización, pero su confiabilidad de ajustar Taproot Trie aún debe confirmarse.
Mate
Matt (Merkleize All the Thing) tiene como objetivo lograr tres objetivos: merkleizando el estado, merkleizando el guión, merkleizando el rendimiento, para lograr contratos inteligentes generales.
-
Merkleizing the State: esto implica la construcción de Merkle Trie, donde cada nodo de hoja representa el valor hash de un estado, mientras que Merkle Root refleja el estado general del contrato.
-
Merkleizing el script: esto se refiere al uso de Tapscript para formar un mástil, donde cada nodo de hoja representa una posible ruta de conversión de estado.
-
Merkleizing the Performing: Merkleization se realiza a través del mecanismo de desafío de compromiso y fraude encriptado.Para cualquier función de cálculo, los participantes pueden calcular debajo de la cadena y luego publicar el compromiso f (x) = y.Si otros participantes encuentran el resultado del error f (x) = z, pueden lanzar un desafío.El arbitraje se realiza a través de una búsqueda de dos puntos, similar al principio del encierro optimista.
Ejecución de Merkel
Para lograr Matt, el lenguaje de script de bitcoin debe tener las siguientes funciones:
-
La salida obligatoria tiene un script específico (y el número de TI)
-
Adjunte un dato a la salida
-
Lea los datos de la entrada actual (u otra entrada)
El segundo punto es importante: los datos dinámicos significa que el estado se puede calcular a través de los datos de entrada proporcionados por los consumidores, porque esto permite a Analog State Machine determinar el siguiente estado y datos adicionales.El esquema Matt se implementa a través del código de operación OP_CHECONTRACTROCTVERIFY (OP_CCV).
Cantidad de salida de control: el método más directo es para la provincia directamente;OP_CCV utiliza un método de verificación de retraso, como OP_Vault, donde se agrega la cantidad de entrada de todas las entradas en el CCV como el límite inferior de la cantidad de salida.El retraso se debe a que esta prueba ocurre durante la transacción, no durante la entrada de evaluación del script.
En vista de la universalidad de la prueba de fraude, algunas variantes de contratos de Matt deberían poder lograr todo tipo de contratos inteligentes o 2 capas de estructuras, aunque se requieren requisitos adicionales (como el bloqueo de capital y el retraso en el desafío); la transacción.Por ejemplo, utilizando un mecanismo de desafío de compromiso y fraude encriptado para simular la función OP_ZK_VERIFY y realizar los acumulaciones sin confianza en Bitcoin.
En la práctica, las cosas han sucedido.Johan Toras Halseth utiliza el código operativo OP_CHECKCONTRACTRACTRACTRACTRACTRACTROVERIFY en la propuesta de Matt Soft Fork para lograr ElfTrace, que permite que cualquier programa que admite la compilación de RISC-V verifique en la cadena de bloques de bitcoin, de modo que uno de los contratos en el contrato puede pasar el contrato a través de El contrato.
CSFS (OP_CHECKSIGFROMSTACK)
A partir de la introducción del código operativo APO, aprendimos que OP_CHECKSIG (y sus operaciones relacionadas) es responsable de ensamblar transacciones, firmas de computación y verificación hash.Sin embargo, estos mensajes de verificación operativos se negocian con serializados por el código de operación y no pueden especificar ningún otro mensaje.En pocas palabras, el papel de OP_CHECKSIG (y sus operaciones relacionadas) es verificar si el UTXO gastado como una transacción está autorizado por el titular de la firma para usar el mecanismo de firma para proteger la seguridad de Bitcoin.
CSFS, como su nombre indica, es verificar la firma desde la pila.El código operativo CSFS recibe tres parámetros de la pila: firma, mensaje y clave pública, y verifica la efectividad de la firma.Esto significa que las personas pueden transmitir cualquier noticia a la pila y verificar a través de los CSF para lograr algunas innovaciones de Bitcoin.
La flexibilidad de los CSF les permite realizar mecanismos tales como firmas de pago, encomendación de autorización, contratos de contratos de profecía, garantías de protección de pago dual y una autoinstrospección de transacciones más importante.El principio del uso de CSFS para la transacción es muy simple: si el contenido de transacción utilizado por OP_CHECKSIG es empujado a la pila por testigos, y usa la misma clave pública y firmas para verificar OP_CSFS y OP_CHECKSIG, y si ambas verificación se aproban con éxito, transmiten cualquiera El contenido del mensaje para OP_CSFS es el mismo que las transacciones de gastos serializados (como otros datos) del uso oculto OP_CHECKSIG.Luego obtenemos datos de transacción verificados en la pila, que se pueden usar para restringir la transacción de gastos utilizando otros códigos operativos.
Los CSF a menudo aparecen con OP_CAT, porque OP_CAT puede conectarse a diferentes campos de transacciones para completar la serialización, a fin de seleccionar con mayor precisión los campos de transacción requeridos por la provincia.Sin OP_CAT, el script no se puede volver a calcular a partir de los datos que se pueden verificar por separado.
Los CSF pueden implementar códigos operativos como CLTV, CSV, CTV, APO, lo que lo convierte en un código operativo de ahorro multi -funcional.Por lo tanto, también ayuda a la solución de escalabilidad de Bitcoin 2.La desventaja es que necesita agregar una copia completa de la transacción de firma a la pila, lo que puede aumentar significativamente el tamaño de la transacción usando CSFS.Por el contrario, la sobrecarga de ahorro del código operativo de ahorro en un solo propósito como CLTV y CSV es muy pequeño, pero es necesario realizar cambios de consenso para agregar cada nuevo código operativo provincial interno especial.
Txhash (OP_TXHASH)
OP_TXHASH es un código operativo provincial interno simple que permite al operador elegir campos específicos y empujarlo a la pila.Específicamente, OP_TXHASH aparece un logotipo de Txhash desde la pila, calcula (etiqueta con etiquetas) txhash y luego empuja el hash generado de regreso a la pila.
Debido a la similitud de TXHASH y CTV, una gran cantidad de discusiones en la comunidad tienen una gran cantidad de discusiones en los dos.
TXHASH puede considerarse como una actualización general de CTV.A diferencia de otros códigos operativos del pacto, TXHASH no necesita presenciar los datos necesarios en la prueba, lo que reduce aún más los requisitos de almacenamiento. utilizado como CTV y APO.
Desde la perspectiva de la construcción de un contrato, TXHash es más propicio para crear un «contrato adicional». El valor fijo y la coincidencia de valor fijo;Luego, use el código operativo Rolling SHA256.La libertad es Beh a este estado medio.
Se espera que el campo TXFieldselector definido en la especificación TXHASH se expanda a otros códigos operativos, como OP_TX.
BIP relacionado con TXHASH está actualmente en borrador de GitHub y aún no se ha distribuido.
OP_CAT
OP_CAT es un misterioso código operativo.Al final, OP_CAT fue aprobado bajo BIP-347, que se llama la propuesta de BIP más probable recientemente.
De hecho, el comportamiento de OP_CAT es muy simple: conecta dos elementos de la pila.¿Cómo implementa la función del pacto?
De hecho, la capacidad de conectar dos elementos corresponde a una poderosa estructura de datos cifrada: Merkle Trie.Para construir Merkle Trie, solo necesita conectarse y operaciones hash, y el script de bitcoin proporciona funciones hash.Por lo tanto, utilizando OP_CAT, en teoría podemos verificar Merkle para demostrar que este es uno de los métodos de verificación livianos más comunes en la tecnología blockchain.
Como se mencionó anteriormente, los CSF pueden lograr una solución de pacto común con la ayuda de OP_CAT.De hecho, incluso si no hay CSFS, OP_CAT puede darse cuenta de la provincia de transacciones utilizando la estructura firmada por Schnorr.
En la firma de Schnorr, el mensaje que debe firmarse está compuesto por los siguientes campos:
Estos campos incluyen los elementos principales de la transacción.Al colocarlos en scriptpubkey o testigo, y utilizando OP_CAT BINDING OP_SHA256, podemos construir una firma Schnorr y usar OP_CHECKSIG para la verificación.Si se pasa la verificación, la pila retendrá los datos de transacción verificados para lograr la transacción de la introspección.Esto nos permite extraer y «verificar» cada parte, como su entrada, salida, dirección de destino o bitcoin involucrado.
Con respecto a la ciencia de la contraseña específica, puede consultar el artículo «Tricks Cat y Schnorr» de Andrew Poelstra.
En general, la versatilidad de OP_CAT le permite simular casi cualquier código operativo del pacto.Muchos códigos operativos del pacto dependen de la función de OP_CAT, lo que mejora enormemente su posición en la tabla de fusión.Teóricamente, basándose en OP_CAT y en el código operativo Bitcoin existente, esperamos construir un rollo de confianza de BTC ZK.Starknet, Chakra y otros socios del ecosistema están promoviendo activamente la realización de este objetivo.
en conclusión
Cuando exploramos las diversas estrategias para expandir Bitcoin y mejorar su programalidad, es obvio que los caminos que avanzan implican la fusión de mejora nativa, cálculo de la cadena y funciones de script complejas.
Si no hay una capa básica flexible, es imposible construir una capa de dos más flexible.
La expansión del cálculo bajo la cadena es una tendencia futura, pero la programación de Bitcoin necesita avances para respaldar mejor esta escalabilidad y convertirse en una moneda global real.
Sin embargo, la naturaleza informática en Bitcoin es fundamentalmente diferente de la naturaleza informática de Ethereum.Bitcoin solo admite la «verificación» como forma de computación y no puede realizar la computación general, y Ethereum es esencialmente la compensación.Se puede ver desde un punto: Ethereum cobra la tarifa de gas a las transacciones irrazonables, mientras que Bitcoin no se cobra.
El contrato es un contrato inteligente basado en la verificación en lugar de la informática.Además de algunos tesorería de Nakamoto, parece que todos piensan que los contratos son una buena opción para mejorar Bitcoin.Sin embargo, la comunidad todavía está argumentando ferozmente qué método debe usarse para implementar el contrato.
Apo, Op_Vault y TLUV se aplican directamente.Los entusiastas de la red de Lightning elegirán APO para lograr la simetría LN;OP_CAT y TXHASH son más abundantes, y la probabilidad de vulnerabilidades de seguridad es menor.CTV y CSFS han ajustado el método de procesamiento de blockchain, CTV implementa la salida retrasada y CSFS realiza firmas retrasadas.Matt se destaca con la estrategia de ejecución optimista y prueba de fraude, y utiliza la estructura de Merkle Trie para lograr contratos inteligentes generales, pero la función provincial aún requiere nuevos códigos operativos.
Vemos que la comunidad de Bitcoin está discutiendo activamente la posibilidad de obtener convenios a través de horquillas suaves.Starknet ha anunciado oficialmente la adición del ecosistema de bitcoin, y planea lograr un acuerdo en la red de bitcoin dentro de los seis meses posteriores a la fusión de OP_CAT.Chakra continuará prestando atención a los últimos desarrollos del ecosistema de bitcoin, promoverá la fusión de las bifurcaciones suaves OP_CAT y utilizará la construcción programática de convenios para construir una capa de asentamiento de bitcoin más segura y eficiente.
