¿Cómo ven los profesionales de la industria de 2010 el camino de construcción de BTC diez años después?

Autor: Shinobi, co-fundador de BTC Podcast Block Digest; Traducción: Wuzhu, Golden Finance

Este artículo es un ensayo escrito por Shinobi hace diez años, que explora cómo era el BTC en el año 2020.

El primer artículo de esta serie se puede encontrar haciendo clic en "¿Cómo ven los profesionales de la industria el ecosistema BTC una década después en 2010?"

Ya estamos empezando a ver que las semillas del potencial de la segunda capa se desarrollan a partir del idioma base de la primera década. Aunque la red de rayos todavía está bastante limitada, realmente está comenzando a florecer. Esto es solo la primera versión limitada que se ha designado y desplegado hasta ahora. Ya se han desplegado varios tipos de cadenas laterales: Liquid, RSK e incluso una cadena de tokens vinculada a BTC desarrollada por Commerceblock. Esto es solo el comienzo.

###SCHNORR y TAPROT

No pasó mucho tiempo antes de que tuviéramos una combinación de Schnorr y Taproot. Desde el punto de vista de Schnorr, se trata de un esquema de firma de verificación por lotes que cuesta menos y es el siguiente gran paso adelante en la optimización de la construcción de scripts multifirma de BTC. Inicialmente, un multisig es solo cuestión de enviarlo con todas las claves públicas y scripts multisig metidos en la salida de la transacción, y todo esto debe incluirse en la entrada para poder usarlo. P2SH optimiza el aspecto de salida al incluir una clave pública multifirma y un hash de longitud constante del script, lo que ahorra que cualquiera envíe a una dirección multifirma y solo agrega costos al remitente. Podría decirse que SegWit "optimiza" aún más al presenciar descuentos para hacer que los UTXO que cuestan multisig sean más baratos. Schnorr lleva todas estas optimizaciones incrementales al extremo. Combina claves públicas individuales en una sola clave, y todos pueden colaborar para crear una firma para ella y luego verificarla. Esto proporciona un ahorro de costes significativo para todas las tecnologías que utilizan multifirma, incluida la capa 2, como la (Lightning) Lightning Network y las cadenas laterales federadas, y también aporta beneficios de privacidad al hacer que todas estas UTXO multifirma sean indistinguibles de las UTXO de firma única.

Ahora, esto no hace que todo sea mágicamente completamente secreto. El estado (transacciones) de los canales de rayos aún requiere rutas de clave separadas para que las transacciones de penalización respondan al estado antiguo. Esto significa que deben estar en los scripts de salida que crean la huella digital. Taproot resuelve este problema a través de su magia criptográfica, permitiéndole presentar un árbol de merkle con condiciones de gasto diferentes, solo se requiere la condición y la prueba de merkle hasta la raíz de merkle para gastar, a una apariencia normal de clave pública Schnorr. Ahora, puede ocultar la ruta del script de penalización utilizando taproot. Puede ocultar cualquier ruta de script condicional utilizando Taproot, ocultándola debajo de una clave Schnorr que parece muy normal, permitiendo que todos los participantes lleguen a un consenso sobre algo y realicen transacciones que parecen muy normales.

###SIGHASH_ANYPREVOUTPUT

SIGHASH_ANYPREVOUTPUT (anteriormente conocido como SIGHASH_NOINPUT) tiene el potencial de convertirse en el próximo nuevo primitivo. Es una actualización de formato de clave pública/nueva bandera de sighash. La bandera de sighash especifica qué parte de la transacción se enviará con la firma. La existencia de esta función es para permitir que usted realice operaciones como firmar solo sus entradas y salidas, pero permitir que otros agreguen sus propias entradas y salidas a la transacción sin invalidarla. Sin embargo, actualmente, la firma debe enviarse desde la UTXO exacta de la transacción exacta. Entre otras cosas, SIGHASH_ANYPREVOUT puede enviar la firma al script de UTXO en lugar de a una UTXO específica real. Esto permite una nueva forma (eltoo) de construir el estado de los canales de rayos, sin necesidad de claves de castigo o manejo de estados antiguos, permitiendo que el receptor incaute todos los fondos. En cambio, si el estado actual del canal falla en una competencia de doble gasto, simplemente se puede reutilizar el estado antiguo, garantizando que todos obtengan su saldo actual del canal en la cadena en lugar del saldo caducado anterior. Esto se puede lograr simplemente reutilizando el mismo script en la posición correcta y usando SIGHASH_ANYPREVOUT.

Esto elimina muchos riesgos, como perder el estado actual del canal, lo que podría resultar en que una transacción de multa retenga sus fondos por accidente. También puede lograr más funcionalidades. Ahora, podemos tener canales de rayos con más de 2 participantes e incluso apilar "subcanales" sobre estos canales. Además, SIGHASH_ANYPREVOUT y eltoo pueden crear Statechains, que es una construcción de canal colaborativo que permite que nuevos participantes entren y salgan completamente fuera de la cadena, asumiendo que la coalición no conspirará con los participantes pasados para engañar a nadie. Esto abre muchas posibilidades para lo que he llamado el protocolo "Protocolo UTXO estático multiparte".

###OP_CHECKTEMPLATEVERIFY

OP_CTV es una propuesta presentada por Jeremy Rubin que tiene como objetivo implementar un 'contrato' muy básico en BTC. Los contratos son restricciones más complejas en el uso de un BTC, no solo firmas de ciertas claves. El tipo de contrato que Rubin propone implementar es 'plantilla'. Básicamente, esto permite que el script de UTXO exija que la transacción de gasto cree salidas precisas específicas. Por lo tanto, una vez que se crea un UTXO utilizando OP_CTV, se hace cumplir por consenso, lo que significa que el UTXO debe gastarse en una dirección específica, con el monto definido en el script de ese UTXO. Incluso puede encadenarlos para que uno de ellos se vea obligado a generar varios más, y luego esos UTXO se vean obligados a generar varios más, y así sucesivamente.

Esto es ampliamente aplicable en cualquier lugar. En entornos de alto costo, una entidad custodia puede crear una UTXO individual, con la garantía del 100% de acuerdo con las reglas de consenso de que los fondos de todos sus clientes eventualmente serán controlados por los clientes, incluso si actualmente no pueden acceder a estos fondos de inmediato. Esto tiene un gran potencial de sinergia con los canales multiparte (fábrica de canales), ya que la extracción a gran escala realizada de esta manera también puede crearse simultáneamente y utilizarse como fábrica de canales. OP_CTV puede usarse para crear canales de pago que funcionen al menos en una dirección, sin que el receptor participe o posea claves en línea para recibir pagos (recuerde que puede apilar canales entre sí). Incluso puede usarse para permitir que un solo canal maneje más HTLC a la vez, atándolos juntos utilizando el mismo truco que en el ejemplo de custodia múltiple. Incluso podría crear potencial para un nuevo tipo de coinjoin.

###Integrar todos los elementos

Suponiendo que todas las propuestas anteriores sean adoptadas e incorporadas en Bitcoin, realmente creo que, aparte de los desarrolladores que realmente trabajan en estas áreas avanzadas, la gente ni siquiera sabe qué tipo de protocolos y servicios se construirán utilizando estos lenguajes originales. O cosas extrañas sin líneas divisorias claras entre los servicios o protocolos.

Permitirán canales multipartitos teóricamente ilimitados en cuanto al número de participantes, que pueden apilarse sobre subcanales de participantes en canales base. Se pueden construir canales sobre estos 'fábricas de canales' para que las personas puedan recibir pagos sin necesidad de poseer las claves de una billetera caliente en línea. Estos canales multipartitos se pueden apilar a su vez en canales unificados (cadenas de estado), ¡permitiendo a los participantes entrar o salir de la cadena sin actividad en la cadena! La construcción de 'unión de canales' permitirá que la liquidez se mueva relativamente sin problemas entre diferentes canales, lo que permitirá una variedad de cosas que la gente ni siquiera ha empezado a considerar realmente.

Mi última oración en esta sección es: simplemente considerar lo que se puede hacer con lo que considero como parte directa de la pila de protocolos de BTC en sí misma. Si empiezas a investigar los servicios de custodia centralizada y qué subconjuntos de BTC pueden ofrecer estos servicios sin verse afectados por regulaciones legales, entonces puedes hacer mucho más.