CheckTemplateVerify (CTV) es una propuesta de bifurcación suave para Bitcoin especificada en el Propuesta de mejora de Bitcoin (BIP) 119. Su objetivo es habilitar nuevos casos de uso para la red al agregar un tipo básico de "pacto" o contrato inteligente, que es más de lo que se puede lograr en este momento.
¿Por qué Pactos?
Bitcoin, tal como es, no posee mucha flexibilidad en su programabilidad en el nivel básico de las transacciones, y ciertamente no tanta flexibilidad como la que tiene en el nivel de las claves públicas y privadas utilizadas para firmar transacciones.
Un programador puede actualmente controlar las entradas de una transacción con Secuencia de comandos de Bitcoin, restringiendo lo que se puede hacer antes de que se gaste una transacción, pero no pueden controlar para qué tipos de transacciones se permite firmar. En otras palabras, en la mayoría Contratos inteligentes de Bitcoin hoy, un usuario puede controlar cómo se puede desbloquear una moneda definiendo las restricciones necesarias para cumplir. Pero no pueden controlar muy bien qué se puede hacer con esa moneda una vez desbloqueada.
Por ejemplo, se puede definir una cierta cantidad de tiempo antes de que una transacción se pueda gastar con un bloqueo de tiempo, bloqueando efectivamente esa transacción hasta que se alcance la altura de bloque especificada. En este caso, se imponen restricciones a cuando se pueden gastar los fondos, evitando que la clave correcta desbloquee esos fondos y los gaste. Sin embargo, después de que expire ese tiempo y se alcance la altura del bloque en la cadena de bloques de Bitcoin, la clave puede desbloquear esos fondos y gastarlos libremente. El cuando está restringida, pero no la qué or cómo.
Por lo tanto, los convenios tienen el poder de desbloquear un nuevo conjunto de posibilidades en la forma en que se puede programar Bitcoin al permitir una predefinición de qué salidas son aceptables, en lugar de solo controlar las entradas. Aunque convenios complejos con infinitas posibilidades podrían generar riesgos de seguridad para la red al permitir consecuencias inesperadas o no deseadas, la propuesta de CTV es, en su mayor parte, simple.
¿Qué es CTV?
En resumen, CTV permite que un usuario de Bitcoin restrinja la forma en que puede gastar bitcoin, incluso si tiene la clave del bitcoin que desea gastar.
Más importante aún, CTV permite que estas restricciones de gasto se apliquen de forma no interactiva. Algunos casos de uso habilitados por CTV podría ser posible hoy, pero la mayoría de las veces el conjunto de usuarios que participan en el acuerdo de contrato inteligente necesitaría estar en línea e interactuar manualmente para coordinar las reglas de gasto, lo que no siempre es posible. CTV permite que estas restricciones se apliquen programáticamente, sin necesidad de interacción manual por parte de los participantes, lo que aumenta la confiabilidad del convenio.
Hoy, puedes gastar tus UTXO como quieras. En un mundo posterior a CTV, podría establecer reglas sobre sus UTXO para controlar o limitar las posibles formas en que podría gastar esas monedas. No cuándo se gastan, sino cómo. Al traer este tipo de nuevas características a Bitcoin, una comunidad más diversa conjunto de casos de uso podría habilitarse y podría surgir un nuevo ecosistema de aplicaciones.
Algunas de las funcionalidades que CTV podría habilitar para Bitcoin incluyen mejoras en seguridad, privacidad y escalabilidad. Con la activación de CTV, los usuarios podrían crear soluciones de custodia más sofisticadas, como bóvedas, que podrían permitir a un usuario de Bitcoin predefinir el gasto programado y limitado de bitcoin desde el almacenamiento en frío hasta el almacenamiento en caliente, limitando así el daño de un posible pirateo. . CTV también podría traer grupos de pago, un tipo de acuerdo en el que un grupo de personas puede compartir un solo UTXO y reequilibrar fondos entre ellos sin confianza, no solo aumentando su privacidad sino también permitiendo mejores oportunidades de escalamiento para Bitcoin. Además, CTV podría sobrecargar Lightning Network con mejoras en la creación y redención de canales, así como en hash contratos bloqueados por tiempo (HTLC), aumentando así la eficiencia y la liquidez en el protocolo de segunda capa de Bitcoin.
¿Cómo funciona CTV?
Debajo del capó, CTV trae una nueva código de operación para Bitcoin, una nueva adición al conjunto de operaciones disponibles en Secuencia de comandos de Bitcoin.
BIP119 agrega el nuevo código de operación OP_CHECKTEMPLATEVERIFY a Bitcoin a través de OP_NOP4, implementando un cambio de consenso en el protocolo a través de una bifurcación suave.
Actualmente, los OP_NOP numerados (OP_NOP1 y OP_NOP4 a OP_NOP10) se ignoran cuando se usan sin invalidar la transacción; más notablemente, son reservados códigos de operación que se pueden aprovechar para agregar nuevos códigos de operación al protocolo. Sin embargo, eso no es cierto para OP_NOP en sí mismo (sin números), ya que es un código de operación de "no operación".
BIP119 busca resignificar OP_NOP4 para asumir un rol de verificación en forma de OP_CHECKTEMPLATEVERIFY, procedimiento que fue también apalancado por la adición de OP_CHECKLOCKTIMEVERIFY y OP_CHECKSEQUENCEVERIFY al protocolo, resignificando OP_NOP2 y OP_NOP3, respectivamente.
OP_CHECKTEMPLATEVERIFY realiza tres comprobaciones cuando se ejecuta. Primero, naturalmente, verifica si hay al menos un elemento en la pila. Si lo hay, comprueba si el elemento tiene exactamente 32 bytes, el tamaño de un hash SHA-256. Si hay un elemento en la pila y tiene 32 bytes, CTV verificará si coincide con el hash de la transacción en t
El índice de entrada actual.
Este paso, verificar si el elemento coincide con el hash, es exactamente donde ocurre la aplicación. Aquí, el programa está verificando si la transacción que se le pasa es parte del conjunto de transacciones especificadas previamente por el contrato (o convenio) como las "posibles", las que recibirían aprobación. Este conjunto de transacciones habría sido previamente definido por el usuario en un contrato.
Aunque no es necesario para la construcción de contratos que se pueden hacer cumplir con CTV, Rana es un lenguaje de programación en desarrollo diseñado específicamente para este propósito. Abstrae los detalles de programación de bajo nivel para facilitar la creación de contratos inteligentes para Bitcoin con, por ejemplo, componentes: piezas de código reutilizables que mejoran la legibilidad y la usabilidad de un programa.
Los programadores primero crean una plantilla con Sapio, especificando algunas condiciones, que luego genera una lista de transacciones de bitcoin parcialmente firmadas (PSBT) que se pueden aprovechar para definir un conjunto exhaustivo de transacciones para gastar, lo que nos permite restringir el conjunto de permitido salidas en una transacción a un conjunto que es menores que el conjunto de todos salidas posibles.
CHECKTEMPLATEVERIFY se compromete previamente a una transacción al restringir la mayoría de los datos que determinan todos los posibles ID de transacción (TXID) con anticipación. Esto significa que, dado un UTXO específico y un contrato, generalmente puede precalcular todos los TXID. Aunque restrictivo, se supone que al conocer los TXID por adelantado, el convenio es más fácil de hacer cumplir ya que el universo de transacciones a verificar es restringido.
La función hash específica que analiza el código de operación DefaultCheckTemplateVerifyHash procesa partes de una transacción de manera serial, comenzando con la versión y el tiempo de bloqueo. A continuación, la función procesa el hash scriptSig si la transacción no es una transacción SegWit, y luego procesa el número de entradas, el hash de las secuencias y el número de salidas. Por último, la función calcula el hash de las salidas y el índice de entrada.
Al comprometerse con (o determinar) la mayoría de estos por adelantado, no solo se puede determinar el TXID de antemano, sino que también permite que solo algunos de ellos se configuren más adelante (para que sean maleables) y hace que la validación sea más eficiente, ya que muchos los campos ya habían sido hash.
"La idea de ordenar los campos de una manera particular era que si en algún momento en el futuro tuvieras algo como OP_CAT en Bitcoin, podrías estar manipulando estos en la pila", dijo Jeremy Rubin, el autor de BIP119. Bitcoin Magazine. "Hay algún beneficio para ellos en orden de cuán probable es que los cambie mediante programación".
“Por lo tanto, parte del pensamiento era que nVersion es lo menos probable que se cambie, el índice de entrada es lo más probable que se cambie y todo lo demás cae en el medio en ese orden”, agregó Rubin.
La suposición es que es más probable que un desarrollador de Bitcoin que programa un convenio cambie programáticamente la información sobre las salidas que las entradas, dado el hecho de que un convenio trata de restringir cómo se puede gastar una moneda.
Por lo tanto, lo que hace OP_CHECKTEMPLATEVERIFY es comprobar si la transacción está permitida. En otras palabras, hace cumplir las restricciones impuestas por el pacto programado con Sapio.
Pero esa verificación solo ocurre si el elemento en la pila tiene un tamaño de 32 bytes. De lo contrario, CTV OP_NOP el elemento en la pila, lo que significa que no fallará la ejecución, sino que "no hará nada".
Esta sutil diferencia busca adaptarse a desarrollos futuros que podrían construirse después de CTV, por ejemplo, una "versión dos de CTV" que le agrega un byte de bandera, lo que hace que el elemento tenga 33 bytes. Entonces, en lugar de usar CTV para verificarlo, ya que solo verifica elementos de 32 bytes, el elemento sería verificado por la "CTV versión dos" que verifica 33 bytes. Y eso sería posible porque OP_NOP permitió que continuara la evaluación del script. Si hubiera fallado, la evaluación no habría continuado y, por lo tanto, el elemento no se habría verificado con la "versión dos de CTV".
"Las transacciones con un CTV de 33 bytes aún serían rechazadas por la red bajo las reglas de estandarización con estos cambios, pero serían válidas si un minero las colocara en un bloque", explicó Rubin. “Esto asegura la expectativa de que se le asignará un significado específico en el futuro, desalentando el uso descuidado”.
¿Será CTV la próxima actualización de Bitcoin?
El proceso de actualización de Bitcoin es conocido por su enfoque metódico y cuidadoso, una característica vital para la supervivencia de la red y la corrección garantizada de cada nueva adición al código. Por lo tanto, no está muy claro si CTV podría agregarse o no a Bitcoin en el corto plazo.
Aunque no es una propuesta nueva (el BIP se creó en enero de 2020), los desarrolladores destacados de Bitcoin argumentan que debe haber pruebas y debates más extensos sobre los cambios sugeridos, especialmente cuando se relaciona con posibles optimizaciones y una consideración más detallada de las alternativas.
CTV, al momento de escribir este artículo, agregaría un conjunto limitado de nuevas posibilidades a Bitcoin, ya que busca implementar una forma de convenios de bajo riesgo en el protocolo. Rubin dijo Bitcoin Magazine que el objetivo es enviar algo eso permite una nueva funcionalidad para Bitcoin y es "probablemente una de las bifurcaciones blandas más simples en términos del impacto en la validación de Bitcoin que hemos hecho".
“Actualizaciones como CLTV o CSV, por ejemplo, requerían una bifurcación suave para agregar un código de operación y una bifurcación suave para hacer cumplir por consenso el campo nLockTime y nSequence (datos contextuales), mientras que la validez de CTV solo verifica una propiedad inherente a la transacción, Rubin agregó.
Rubin también dijo que siente que "hay un poco de doble rasero" aplicado en las revisiones de su propuesta por parte de la comunidad de desarrolladores.
“Este es un listón mucho más alto al que se somete a CTV que cualquier cosa que hayamos hecho anteriormente”, dijo. Bitcoin Magazine. "Si bien siempre debemos buscar elevar el nivel", aclaró Rubin, "no debe pasar sin reconocer que CTV ya cumple o supera el nivel de pruebas y aplicaciones de bifurcaciones anteriores".
A principios de este mes, el desarrollador de Bitcoin y Lightning Network en Spiral, Matthew Corallo, tuiteó que "en ningún momento de la historia de Bitcoin ha sido o
está bien proponer enviar las cosas al consenso... sin considerar alternativas". Corallo reclamaciones que Rubin, y aquellos que trabajan y apoyan a CTV en general, durante los últimos dos años no han podido mostrar "un enfoque más formal para compararlo con alternativas".
“El impulso de CTV se siente… mal en casi todos los sentidos”, Corallo adicional. "En lugar de ingeniería colaborativa, se siente como 'construí esto, hagámoslo' mientras se ignoran los comentarios".
El director de investigación de Blockstream, Andrew Poelstra, también comparte el deseo de una mayor experimentación y análisis. Cuando se le preguntó si CTV sería la mejor opción actual de Bitcoin para ampliar la funcionalidad para admitir convenios, dijo Bitcoin Magazine que "sugeriría que no", y agregó que "CTV no es la única forma propuesta de implementar convenios en Bitcoin, y se enfrenta a una compensación entre seguridad y generalidad que deja espacio en cualquier dirección".
“Una forma en que esto podría funcionar es que CTV puede ser la forma más eficiente de implementar 'convenios sustractivos', en los que los usuarios restringen la mayoría de los datos de transacciones y dejan solo una pequeña parte libre”, dijo Poelstra. “Mientras tanto, otras propuestas como códigos de operación de introspección puede ser mejor para 'convenios adicionales' donde la mayoría de los datos de transacción son gratuitos y solo una pequeña cantidad está restringida. Si esto es cierto, y la comunidad necesita más tiempo para explorar esto, entonces realmente querríamos APO y CTV y pactos de propósito general.”
Un pobre SIGHASH_ANYPREVOUT, es otra propuesta para agregar nueva funcionalidad a Bitcoin, especificada en BIP118. Su autor, Christian Decker, investigador de Blockstream que se enfoca en escalar soluciones para Bitcoin, dijo Bitcoin Magazine que también considera que APO y CTV son adiciones "complementarias y no competidoras" de Bitcoin.
“Ambos son beneficiosos”, dijo Decker. “Así que estoy de acuerdo en que deberíamos activarlos juntos cuando ambos estén listos, revisados y probados”.
Por el momento, la preparación para la activación es un tema delicado en la comunidad de Bitcoin. De hecho, parte del rechazo contra CTV por parte de algunos desarrolladores se basa en un supuesto sentido de urgencia representado por los defensores de CTV. Apresurarse en la implementación podría ser dañino si los cambios que no están listos terminan añadiéndose al código de Bitcoin.
Decker dijo Bitcoin Magazine que se siente cómodo esperando más tiempo para que su propuesta se agregue a Bitcoin si eso significa que se empleará un proceso de prueba más sólido, aunque dijo que comprende el deseo de los defensores de CTV de activarlo lo antes posible.
“No creemos que sea beneficioso impulsar un cambio y que APO debe implementarse con urgencia”, dijo Decker. “Cuanto más tiempo se pueda cocer la propuesta, más ojos podrán revisarla y resaltar las debilidades potenciales. El tiempo de los revisores y desarrolladores es el recurso más escaso de Bitcoin, por lo que queremos ser respetuosos con eso, a pesar de tener algunas implementaciones [de prueba de concepto] de eltoo, por ejemplo".
En diciembre de 2021, en un esfuerzo por atraer más miradas a su propuesta, Rubin montó un recompensa de errores para CTV y su BIP especificado, diciendo que otorgaría $ 10,000 a cualquiera que encontrara una falla "sustancial" en la bifurcación suave sugerida. La recompensa tiene desde crecido inmensamente, pero algunos desarrolladores, incluidos Coral y Adam Back, el legendario cypherpunk y director ejecutivo de Blockstream, cuestionó la iniciativa de Rubin y sugirió que probablemente no era la mejor solución para conseguir más revisores.
A pesar del rechazo a los convenios por parte de partes de la comunidad, Poelstra dijo que cree que “no hay una resistencia real en la comunidad de Bitcoin a ninguna de estas ideas; realmente solo necesitamos personas que los defiendan e impulsen la comunicación pública, las herramientas, los vectores de prueba, la exploración de casos de uso, etc., de la forma en que Jeremy lo ha hecho con CTV”.
Además de acaloradas discusiones en Twitter, la propuesta de Rubin ha recibido comentarios y preguntas más formales en el lista de correo de desarrollo de bitcoin. Los desarrolladores que recientemente han dado su opinión sobre CTV incluyen miguel folkson, Peter Todd y Lucas Dashjr. Decker también ha compartió sus pensamientos en la intersección entre la CTV y su propuesta. Poelstra compartió comentarios y sugerencias para CTV con Bitcoin Magazine.
“Si CTV es la forma en que la comunidad de Bitcoin quiere ir, hay dos formas en las que sugeriría mejorarlo: la primera sería cambiar su estructura hash para que sea útil para aplicaciones de pacto más generales”, dijo. “Cómo hacer esto, exactamente, es un área activa de investigación sobre la que espero que aprendamos mucho más en las próximas semanas. Tal vez CTV debería tener 'banderas sighash' análogas a las banderas existentes para los controles de firma".
“En segundo lugar, sugeriría cambiar ligeramente el CTV
simplemente empujar el hash de la transacción a la pila y requerir que el usuario use el código de operación EQUALVERIFY existente para verificar que coincida con una plantilla determinada”, agregó. "Esto le costará a los usuarios comunes de CTV un solo byte de datos de testigos de transacciones, al tiempo que ampliará el espacio de diseño para futuras extensiones de Bitcoin".
Rubin, por otro lado, dijo Bitcoin Magazine que él cree que es más útil enviar CTV tal como está, aunque brinde una funcionalidad limitada, e iterar sobre funciones adicionales más adelante.
En resumen, aunque BIP119 ha estado generando mucho revuelo entre la comunidad de Bitcoin, el camino futuro para la actualización propuesta no está claro. El deseo de los defensores de aumentar el alcance de la funcionalidad de Bitcoin para adaptarse a nuevos casos de uso choca con el enfoque más cauteloso de algunos veteranos.
Además, dada la historia de Bitcoin de solo impulsar actualizaciones que logran un consenso abrumador y han sido revisadas a fondo, puede haber un camino lleno de baches para CTV mientras Rubin intenta abogar por su propuesta de mejora. El desarrollador ha hecho un esfuerzo adicional en la creación de un sitio web dedicado con muchos recursos para educar a los Bitcoiners interesados sobre las posibilidades que CTV podría habilitar, pero su entusiasmo por un protocolo de Bitcoin con nuevas funciones aún no ha recibido la bendición de figuras importantes en la comunidad de desarrollo de Bitcoin.
Por ahora, BIP119 parece estancado, presionado entre quienes están a favor de agregar nuevos casos de uso emocionantes a Bitcoin y quienes justifican un enfoque más cuidadoso antes de promulgar un cambio de consenso en el sistema monetario más revolucionario del mundo, una red que debería durar miles de años y no puede permitirse ningún paso en falso.
En general, puede pasar algún tiempo antes de que las dos cohortes lleguen a un acuerdo, pero a medida que la propuesta reúne más comprensión e interés entre los miembros de la comunidad, se allana el camino para llegar a un consenso.
Un agradecimiento especial a Rubin, quien pacientemente ayudó al autor a superar algunas lagunas en su comprensión. Para obtener una explicación más detallada de los aspectos técnicos de BIP119, vea este taller de hace un par de años (primera parte y la segunda parte). Una transcripción está disponible en este enlace. Otros recursos útiles son esta conversacion, este episodio de podcast y este otro, así como una conversación entre Rubin y Poelstra. Para ser parte de la conversación sobre BIP119 y escuchar las últimas discusiones sobre el tema, unirse a la lista de correo de bitcoin-dev.
