Golden Hardcore | Bitcoin puede marcar el comienzo de la mayor actualización en 2020 ¿Qué es Tapscript? Lee el texto

Golden Finance lanzó recientemente la columna Hardcore para brindar a los lectores introducciones o interpretaciones detalladas de proyectos populares. Aunque Bitcoin cayó bruscamente el 12 de marzo, la gente en el círculo de divisas se vio muy afectada. Pero como inversor, aún debe prestar más atención al progreso tecnológico, después de todo, el progreso tecnológico es la fuente de valor de Bitcoin. Así como el "Testigo segregado" en 2017 presenció el mercado alcista de Bitcoin en 2017, se espera que el nuevo avance tecnológico de Bitcoin saque a Bitcoin del atolladero. Como dijimos en la "Interpretación completa de la tercera reducción a la mitad de BTC", uno de los desarrollos a los que vale la pena prestar atención en 2020 es la bifurcación blanda Schnorr/Taproot/Tapscript. Esta bifurcación planificada incluirá tres mejoras de Bitcoin. Protocolos BIP 340, 341 y 342. Realizaremos una serie de interpretaciones de estos tres BIPs.En los dos últimos números de Hardcore, interpretamos BIP340 firmado por Schnorr y BIP341 firmado por Taproot. Este problema se centra en Tapscript. Vea qué es el protocolo Tapscript y cómo activar el Protocolo de mejora de Bitcoin (o BIP), disfrúteloTapscript (BIP 342) La tercera parte de esta propuesta de actualización, BIP 342, describe una actualización complementaria a Schnorr y Taproot, llamada Tapscript. Como se describe en nuestro primer artículo sobre Schnorr/Taproot/Tapscript, Bitcoin Script se utiliza para determinar la estrategia de gasto de Bitcoin. BIP 342 mejora el algoritmo hash para las firmas para que podamos verificar los scripts taproot, introduce flexibilidad, agrega nuevos códigos de operación para mejorar la funcionalidad del contrato inteligente de Bitcoin y también cambia algunas restricciones en los requisitos de recursos. ¿Qué son los códigos de operación? Los códigos de operación, abreviatura de códigos de operación, son básicamente instrucciones o comandos de secuencias de comandos. Estos comandos pueden devolver "VERDADERO" o "FALSO" para transacciones de envío/recepción. Por ejemplo, la directiva del script especifica el número de firmas requeridas para desbloquear el script. También indican la cantidad de bitcoins transados ​​y la dirección del destinatario. Los códigos de operación se pueden usar para eliminar elementos de la pila y realizar cálculos, luego agregar el resultado nuevamente a la pila. Recuerde que, como lenguaje de programación basado en pilas, las instrucciones de script se ejecutan en orden desde la parte superior de la pila hasta la parte inferior. ¿Qué es Tapscript? Como una versión mejorada del lenguaje de programación Bitcoin (script), Tapscript es más fácil de agregar nuevas funciones y proporciona verificabilidad por lotes basada en las firmas de Schnorr. ¿Qué es la verificación de lotes? El primer artículo de la serie Schnorr/Taproot/Tapscript. Tapscript también complementa las mejoras a la estructura de Bitcoin Script propuestas en BIP 341 (Taproot), que requería cambios en ciertos códigos de operación, y BIP 342, que aborda los cambios que deben realizarse. Otra forma de entender Tapscript es considerar el árbol Merkle de Taproot, donde cada hoja (hoja) es una secuencia de comandos, que se puede llamar una versión de hoja, similar al control de versión de secuencia de comandos de SegWit. Pero la diferencia es que el guión no se mostrará al pagar, sino solo al gastar. Diferentes hojas pueden tener diferentes versiones, donde solo se muestran las hojas realmente utilizadas. Tapscript es una versión hoja de la versión 0 bajo Taproot. Tapscript comparte la mayoría de las operaciones con los scripts tradicionales y SegWit Bitcoin, pero con algunas diferencias: el código de operación de la firma verifica las firmas Schnorr (en lugar de las firmas ECDSA). Los códigos de operación de firma múltiple OP_CHECKMULTISIG y OP_CHECKMULTISIGVERIFY se reemplazan por el código de operación OP_CHECKSIGADD, lo que permite la verificación por lotes de firmas mediante Schnorr. Dado que la verificación de firmas es la operación que requiere más CPU en Bitcoin Script, estos códigos de operación son fundamentales para lograr las ganancias de eficiencia asociadas con los esquemas de firmas múltiples basados ​​en Schnorr. Actualmente, el script para 2 de 3 transacciones de firmas múltiples es el siguiente: 2 <clave pública A> <clave pública B> <clave pública C> 3 CHECKMULTISIG usa Taproot/Tapscript, que se puede verificar en lotes forma de crear la misma política de firmas múltiples, su secuencia de comandos es: <A pubkey> OP_CHECKSIG <B pubkey> OP_CSADD <C pubkey> Para simplificar las actualizaciones de bifurcación suave. La introducción del nuevo código de operación OP_SUCCESS es más fácil de verificar que el mecanismo OP_NOP actualmente en uso. Los códigos de operación que anteriormente no estaban disponibles generalmente devolvían un estado "FALSO", Tapscript los devolverá con un estado "VERDADERO". Siempre que estos códigos de operación existan en su secuencia de comandos, puede usarlos incondicionalmente, con el beneficio práctico de poder redefinir los códigos de operación a valores arbitrarios y no requerir compatibilidad con versiones anteriores. Este nuevo mecanismo de extensión de scripts con nuevos códigos de operación es más fácil de coordinar y usar que los mecanismos de control de versiones existentes. Como consecuencia, es de esperar que abra el camino para que se agreguen códigos de operación más útiles a Bitcoin Script en el futuro. Es posible que los códigos de operación NOP existentes se hayan agregado específicamente para tener un mecanismo de actualización para que podamos agregar fácilmente nuevos códigos de operación al lenguaje de secuencias de comandos de Bitcoin. Pero hasta ahora solo se usan para CHECKLOCKTIMEVERIFY y CHECKSEQUENCEVERIFY. Para ser compatibles con las bifurcaciones blandas, estos NOP solo pueden hacer una de dos cosas: 1) abortar o 2) no hacer nada en absoluto. Debido a que redefinen el NOP, actualmente los códigos de operación CHECKLOCKTIMEVERIFY y CHECKSEQUENCEVERIFY no pueden modificar la pila de ninguna manera. Como resultado, no sacan el argumento de la pila y siempre debe seguirlo con OP_DROPafter. El código de operación no hace nada (es decir, NOP), Tapscript es una solución que introduce un nuevo código de operación OP_SUCCESS que "devuelve VERDADERO". Estos códigos de operación se usan solo cuando se usan, y no hasta que hayan definido la semántica de bloqueo en la red. Como resultado, los números de código de operación deshabilitados e indefinidos "devolverán VERDADERO". Posteriormente, estos códigos de operación se pueden redefinir para que sean cualquier cosa, ya que todo es bifurcado, compatible con "return TRUE". El hash de la firma (SIGHASH) se calcula de manera diferente que en los scripts antiguos o en el testigo segregado BIP143 v0. ¿Qué es un hash firmado? En resumen, el hash de firma es la firma de Bitcoin, que indica qué partes de la transacción están firmadas. Usando scriptsigs, las firmas prueban que tiene derecho a gastar ciertos bitcoins. Estas firmas se construyen de tal manera que se agrega un byte a la firma que especifica de qué manera se firma la transacción. Por lo tanto, ya se están implementando e implementando algunos SIGHASH. El más utilizado es SIGHASH_ALL, donde se firma todo excepto scriptsigs. Mientras que cuando solo se firma la entrada actual y todo lo demás en la transacción no se considera parte de la firma, se usa algo como SIGHASH_ANYONECANPAY, el compromiso no se incluye. Se han propuesto una serie de mejoras para estos tipos de SIGHASH, como condiciones en las que solo desea firmar ciertos aspectos de una transacción y condiciones en las que puede especificar qué condiciones le interesan (y cuáles no) cuando gasta bitcoins. SIGHASH ha propuesto una serie de indicadores sobre cómo hacer esto, incluido SIGHASH_NOINPUT. Funciona protegiendo diferentes partes de la transacción. La idea detrás de SIGHASH_NOINPUT es que no le importa qué entrada específica se proporciona, no le importa cuál es el ID de transacción que proporcionó la entrada para la transacción, pero sí le importa la cantidad. Antes de SegWit, que era la solución de maleabilidad propuesta en 2015, era en sí misma una solución de maleabilidad. Debido a las preocupaciones y los riesgos que rodean a SIGHASH_NOINPUT, la comunidad no lo incorporó al protocolo Bitcoin (pero la introducción de SegWit volvió a abrir la puerta para esta actualización). El principal beneficio de SIGHASH_NOINPUT es que simplifica enormemente los canales de pago como Lightning Network. Una propuesta para cambiar la forma en que funciona Lightning es eltoo, que simplifica el uso del canal al transferir estados anteriores no válidos para que el canal no tenga que cerrarse cuando alguien intente hacer trampa. Esto requiere cambios en el script de bitcoin. En particular, los cambios involucran la forma en que se aplican las firmas a las transacciones (es decir, el sistema Sighash), que permite a los usuarios reequilibrar con otras entradas. A pesar de algunos ajustes a algunos de los tipos de sighash existentes, la propuesta de Schnorr/Taproot/Tapscript proporciona una funcionalidad que no es para nada similar a BIP 118, a saber, SIGHASH_NOINPUT (ha habido mucha discusión sobre varias formas de hacerlo seguro). En lugar de incluir SIGHASH_NOINPUT, Tapscript proporciona varios mecanismos de flexibilidad (como claves públicas etiquetadas) que permitirían abrir esta funcionalidad sin aumentar el costo. Este mecanismo facilitará que futuras bifurcaciones suaves amplíen el código de operación de verificación de firma con nuevos tipos de sighash u otros cambios. Con Tapscript, las claves públicas que comienzan con bytes que no conoce se validan automáticamente. Por lo tanto, se pueden introducir nuevos tipos de esquemas de firma y nuevos esquemas sighash sin agregar nuevos códigos de operación Checkig para cada esquema. Las características como SIGHASH_NOINPUT se pueden incluir sin costo adicional como nuevas versiones de clave pública. Tapscript también cambia los límites de recursos. Por ejemplo, los scripts de Bitcoin hoy en día tienen un límite de tamaño de script de 10 000 bytes, que se eliminará. También elimina la limitación en el número de códigos de operación. Dado que scriptCode no se incluye directamente en el hash de la firma (solo indirectamente a través del hash tapleaf precalculado), el tiempo de CPU dedicado a la verificación de la firma ya no es proporcional al tamaño del script ejecutado. En Tapscript, la cantidad de códigos de operación firmados no cuenta para el BIP141 o los límites antiguos de sigop. El antiguo límite de sigop hacía engorroso seleccionar transacciones en la creación de bloques, porque era una restricción asociada con pesos. En cambio, el número de códigos de operación firmados por Tapscript está limitado por el peso del testigo. Tapscript junto con BIP 340/341 amplía el número de posibles aplicaciones interesantes de Bitcoin, como los contratos especiales de Taproot. Los contratos Taproot especiales permiten la ejecución de contratos multipartidistas más complejos y abren posibilidades para organizaciones autónomas descentralizadas (DAO) basadas en Bitcoin. ¿Cómo la activación de BIP 340–342 en Bitcoin agrega actualizaciones al protocolo Bitcoin? Una vez que se envía un BIP, se escribe el código para que coincida con la especificación, que luego se envía como una solicitud de extracción. Después de esta fase, los usuarios y desarrolladores votan sobre la solicitud de incorporación de cambios. Incluso cuando se fusiona, los usuarios pueden votar ejecutando el código nuevo (o no ejecutando y manteniendo el código anterior). La actualización de Schnorr/Taproot/Tapscript se encuentra actualmente en la fase de comentarios de la comunidad (en la imagen a continuación). El siguiente paso es trabajar en el código, obtener una solicitud de extracción para Bitcoin y preparar la red para la prueba. Aunque el siguiente diagrama muestra que el progreso se produce de forma lineal, puede haber algunos bucles de retroalimentación entre los comentarios de la comunidad y la fase de implementación del protocolo (por ejemplo, las propuestas pueden sufrir más cambios cuando la especificación se transforma en un código de trabajo). Una descripción general de cómo BIP ingresó al protocolo Bitcoin Desde la actualización de SegWit en 2017, se puede ver que el uso de BIP 9 (que requiere que el 95% de los mineros indiquen que están listos para activarse) puede generar diferencias entre los diferentes participantes en la comunidad, los desarrolladores/usuarios y los mineros Juega un tira y afloja. Algunos creen que los mineros de Bitcoin pueden usar BIP 9 como una herramienta poderosa para forjar el protocolo en su propio beneficio. Por ejemplo, SegWit no se pudo activar a través de BIP 9, sino que se movió a una variante creada por shaolinfry, la bifurcación suave activada por el usuario o BIP 148. Para activar BIP 340–342, el desarrollador de Bitcoin, Matt Carallo, se basó en las lecciones aprendidas de la actualización de SegWit y propuso una "limpieza de gran consenso" como un posible enfoque. La propuesta combina las propiedades deseables de BIP 8 y ​​BIP 9 y se ve así: 1. El método de activación se implementa inicialmente de manera similar al estándar BIP 9 (generalmente requiere que el 95 % de los mineros estén listos en un plazo de un año) , 2. Si falla la activación de este método, la comunidad tardará seis meses en discutir los motivos de la actualización inactiva 3. Los usuarios pueden optar por implementar BIP 8 con un período de activación de dos años. Este método de activación intenta equilibrar el seguimiento de los deseos de la comunidad, pero al mismo tiempo hace que el período de activación sea lo suficientemente largo para garantizar que los cambios en el protocolo de Bitcoin no sienten un precedente negativo. El momento es indeterminado, ya que no se sabe si se producirán problemas inesperados al traducir estas sugerencias en un código de trabajo. No veremos la activación de BIP 340-342 hasta finales de 2020 o quizás más tarde. Schnorr/Taproot/Tapscript es posiblemente el cambio más significativo en Bitcoin hasta la fecha, mejorando la escalabilidad, la privacidad y la funcionalidad de contratos inteligentes. Tomando la adopción de SegWit como un estándar, aunque tomará al menos dos años, si no más, ver su adopción generalizada, las ganancias para Bitcoin serán profundas.

Tags：

Huobi Exchange