Principales exploraciones y conflictos de la tecnología original de Bitcoin

La tecnología original de Bitcoin siempre ha enfrentado conflictos entre su capacidad para la adopción masiva y la funcionalidad que debería poseer. ¿El escalado y el volumen de transacciones implican comandos de transacción más complejos y un mayor espacio de transacción? ¿Significa que todas las funciones deben implementarse en un solo sistema de Bitcoin? En los primeros días, cuando el desarrollo de la tecnología del ecosistema de Bitcoin era incompleto, estos problemas parecían inherentes a Bitcoin en sí. Sin embargo, a medida que la tecnología ha avanzado, muchos de estos problemas se han vuelto más claros.

Este artículo enumera algunas de las cuestiones relacionadas, junto con los procesos a través de los cuales surgieron y fueron abordados. A través de este artículo, se puede ver la conexión entre estas cuestiones y la tecnología, así como los cambios en la cadena principal de Bitcoin y las "cadenas de prueba" relacionadas. La tecnología de Bitcoin ha sido continuamente explorada por varios proyectos y equipos (incluido Ethereum, que es una exploración de las imperfecciones de Bitcoin). Sin embargo, los cambios en la red principal de Bitcoin no fueron muy evidentes hasta la llegada de tecnologías como Taproot, que impulsaron el desarrollo de protocolos como Ordinals, lo que llevó a una nueva subida en el desarrollo.

Desde una perspectiva más amplia, al observar estos desarrollos y las tecnologías que han producido, podemos ver sus conexiones e inferir más direcciones para el desarrollo y la arquitectura general.

1.1 Lenguaje de secuencias de comandos de Bitcoin y varias reducciones de instrucciones

El lenguaje de programación de Bitcoin es un lenguaje de secuencias basado en pilas que utiliza notación polaca inversa, careciendo de declaraciones de control de bucle y condicionales (expansiones posteriores como Taproot & Taproot Script han mejorado esta capacidad). Por lo tanto, a menudo se dice que el lenguaje de secuencias de Bitcoin no es Turing completo, limitando sus capacidades.

Debido a estas limitaciones, los hackers no pueden utilizar este lenguaje de script para escribir bucles infinitos (que paralizarían la red) o código que pudiera provocar ataques de denegación de servicio, salvaguardando así la red Bitcoin de ataques de denegación de servicio. Los desarrolladores de Bitcoin también creen que la cadena de bloques principal no debe tener una completitud de Turing para evitar ciertos ataques y congestión de red.

Sin embargo, estas limitaciones significan que la red Bitcoin no puede ejecutar otros programas complejos o realizar algunas funciones "útiles". Los sistemas de blockchain posteriores desarrollados para resolver problemas específicos y satisfacer las necesidades de los usuarios han cambiado este aspecto. Por ejemplo, el lenguaje utilizado por Ethereum es Turing-completo.

Los tipos comunes de instrucciones de script de Bitcoin incluyen:

Palabras clave:

1. Constantes. por ejemplo, OP_0, OP_FALSE

2. Control de flujo. p. ej., OP_IF, OP_NOTIF, OP_ELSE, etc.

3. Operaciones de pila. p. ej., OP_TOALTSTACK (empuja la entrada a la pila auxiliar, retirándola de la pila principal), etc.

4. Operaciones de cadenas. por ejemplo, OP_CAT (concatena dos cadenas, deshabilitado), OP_SIZE (coloca la longitud de la cadena del elemento superior de la pila en la pila sin sacar el elemento)

5. Lógica bitwise. por ejemplo, OP_AND, OP_OR, OP_XOR

6. Lógica aritmética. p. ej., OP_1ADD (suma 1 a la entrada), OP_1SUB (resta 1 de la entrada)

7. Criptografía. p. ej., OP_SHA1 (hashes input with SHA-1 algorithm), OP_CHECKSIG

8. Pseudo palabras clave

9. Palabras clave reservadas

Tipos comunes de script de Bitcoin:

1. Transacción estándar pagando a una dirección Bitcoin (pago a la clave pública hash)

2. Transacción estándar de creación de Bitcoin (pago a la clave pública)

3. Salidas probadas como imposibles de gastar / salidas podables

4. Salidas de Cualquiera-Puede-Gastar

5. Transacción de rompecabezas

Los cinco tipos estándar de scripts de transacción incluyen: pagos a hash de clave pública (P2PKH), pagos a clave pública, multisig (limitado a un máximo de 15 claves), pagos a hash de script (P2SH) y salidas de datos (OP_RETURN).

Para obtener información más detallada sobre la escritura de Bitcoin, puede visitar: Bitcoin Wiki - Script.

Reducción de instrucciones admitidas en Bitcoin

Históricamente, Bitcoin ha sufrido varias reducciones en las instrucciones admitidas. En el siguiente gráfico, las partes rojas son las instrucciones que se han eliminado.

• Operaciones de cadena

（2）

(3) Operaciones aritméticas

¿Por qué reducir instrucciones? La seguridad es solo un aspecto a considerar. Si vemos la reducción de instrucciones a través del prisma del diseño en capas, podemos entender su racionalidad, permitiendo que el protocolo base sea más fundamental y estable. Tal vez Satoshi Nakamoto era consciente de este problema desde el principio, por eso redujo activamente las instrucciones. El pensamiento ordinario es construir un sistema pequeño que satisfaga directamente las necesidades del usuario con comandos completos y funciones del sistema, en lugar de un protocolo grande que requiere colaboración.

Esto también conduce a un hecho: solo Bitcoin es adecuado como red de primer nivel. Analicé este fenómeno en el artículo 'Altos Precios de Bitcoin Pueden Fomentar la Aparición de una Nueva Cadena Alternativa', considerando tanto perspectivas económicas como técnicas, y la posibilidad de la aparición de una cadena alternativa de Bitcoin. Sin embargo, desde las características fundamentales de Bitcoin y la perspectiva del diseño en capas, casi solo Bitcoin puede servir como infraestructura de red de primer nivel; incluso si existen cadenas alternativas, serían un producto de 1.5 capas. En el nivel de primer nivel, el artículo genuino es solo Bitcoin, y como mucho, otras cadenas pueden servir como bienes alternativos de menor calidad.

1.2. Historia, razones y significado del Fork de Bitcoin

En la historia del desarrollo de Bitcoin, aparte del problema de reducir las instrucciones, otro aspecto es el debate sobre el tamaño de bloque, que a menudo conduce a bifurcaciones duras de Bitcoin.

Cuando se estableció BTC, no había límite de tamaño de bloque para permitir un cierto número de transacciones que se procesaran dentro del mismo período de tiempo. Sin embargo, cuando los primeros precios de BTC eran muy bajos, el costo de las transacciones maliciosas también era muy bajo. Para abordar este problema, Satoshi Nakamoto lideró una bifurcación suave el 12 de septiembre de 2010, introduciendo un límite que los bloques no podían superar 1 MB de tamaño. Satoshi señaló que esta restricción era temporal, y que en el futuro, el límite de bloque podría aumentarse de manera controlada y gradual para satisfacer las necesidades de expansión.

Con la popularidad de Bitcoin, el problema de la congestión de transacciones en la red y el aumento de los tiempos de confirmación se ha vuelto cada vez más grave. En 2015, Gavin Andresen y Mike Hearn anunciaron que implementarían la propuesta BIP-101 en la nueva versión de BitcoinXT, con la esperanza de aumentar el límite del tamaño del bloque a 8 MB. Sin embargo, desarrolladores centrales como Greg Maxell, Luke Jr y Pieter Wuille se opusieron a esto, argumentando que elevaría la barrera para ejecutar un nodo completo y podría tener impactos incontrolables. Este debate finalmente se amplió tanto en alcance como en participación.

Desde el contenido anterior, vemos que Satoshi Nakamoto también expresó que “el límite de tamaño de bloque es una restricción temporal que puede aumentarse de manera controlada y gradual en el futuro para satisfacer las necesidades de expansión.” Pero ¿cuándo soportará un fork bloques más grandes, y puede resolver el problema dividir una cadena separada para admitir bloques grandes? En medio de controversias en curso, han surgido numerosos casos. Por ejemplo, el tamaño de bloque de BCH es de 8 MB, más tarde aumentado a 32 MB. BSV tiene un tamaño de bloque de 128 MB. Aparte de BCH (y más tarde BSV), este período también vio muchos otros forks de BTC; según BitMEXResearch, al menos 50 nuevas monedas forked aparecieron en el año siguiente al fork de BCH solamente.

Más adelante se mostrará que en la red principal de Bitcoin, Segwit y Taproot también aumentaron en cierta medida el espacio de bloque de 1 MB a 4 MB.

Las bifurcaciones de Bitcoin son una forma de exploración del desarrollo, que intenta satisfacer una gama más amplia de necesidades a través de cambios dentro de sí misma, incluidas las necesidades de usuarios, mineros, inversores, desarrolladores y más.

1.3. Varias Exploraciones Típicas en el Desarrollo de Bitcoin

Después de que Satoshi Nakamoto se fue, su sucesor Gavin Andresen tomó la iniciativa en el establecimiento de Bitcoin Core y la Fundación Bitcoin. Durante este período, las exploraciones sobre la escalabilidad de BTC, especialmente en el área de emisión de activos, persistieron.

(1) Colored Coins (染色币)

Yoni Assia, CEO de eToro, propuso por primera vez el concepto de monedas de colores en un artículo publicado el 27 de marzo de 2012. Esta idea continuó evolucionando y comenzó a tomar forma y a llamar la atención en foros como Bitcointalk. Finalmente, Meni Rosenfeld publicó un detallado libro blanco sobre monedas de colores el 4 de diciembre de 2012.

La idea detrás de las monedas de colores es representar una gama más amplia de activos y valores añadiendo marcas especiales (es decir, coloreando) a partes específicas de Bitcoin. En la implementación, las monedas de colores han surgido en varias entidades, ampliamente divididas en dos categorías:

1) Basado en OP_RETURN: Como propuso Flavien Charlon en 2013, utilizando Open Assets, que utiliza OP_RETURN (introducido en Bitcoin v0.9.0 para almacenar una pequeña cantidad de datos en Bitcoin, originalmente limitado a 40 bytes, más tarde aumentado a 80 bytes). El opcode se almacena en el script y las transacciones de “colorear” se completan mediante lectura externa (este modelo es similar a Ordinals, que dependen de un índice externo para determinar la legalidad de los activos).

2) Basado en OP_RETURN: Un ejemplo típico es el Protocolo EPOBC propuesto por ChromaWay en 2014, donde la información adicional de los activos EPOBC se almacena en el campo nSequence de las transacciones de Bitcoin, y la categoría y legalidad de cada activo EPOBC deben rastrearse hasta la transacción génesis para determinarlos.

(2) MasterCoin (OMNI)

JR Willett lanzó el concepto de MasterCoin el 6 de enero de 2012, llamándolo "el segundo libro blanco de Bitcoin", y lanzó oficialmente el proyecto a través de una OIC en julio de 2013, recaudando finalmente 5120 BTC (valorados en $500,000 en ese momento). La distinción entre MasterCoin y Colored Coins radica en que estableció una capa de nodo completa, que mantiene una base de datos de modelo de estado escaneando bloques de Bitcoin, residiendo en nodos fuera de la cadena de bloques. Este diseño proporciona funcionalidades más complejas que Colored Coins, como la creación de nuevos activos, intercambios descentralizados y mecanismos automatizados de retroalimentación de precios. En 2014, Tether también lanzó la stablecoin conocida como Tether USD (OMNI) en Bitcoin a través del protocolo Mastercoin.

(3) Contraparte

Counterparty fue lanzado oficialmente en 2014. Al igual que Colored Coins, Counterparty también utiliza OP_RETURN para almacenar datos en la red BTC. Sin embargo, a diferencia de las monedas de colores, los activos en Counterparty no existen en forma de UTXOs, sino que en su lugar, la información se carga a través de OP_RETURN para indicar transferencias de activos. Cuando un titular de activos firma una transacción que contiene datos especiales utilizando la dirección de tenencia, el activo se transfiere. A través de este método, Counterparty puede implementar la emisión de activos, el comercio y una plataforma compatible con contratos inteligentes de Ethereum.

Además, algunos puntos de vista también consideran a Ethereum, Ripple y BitShares como parte de un "Bitcoin 2.0" más amplio.

1.4 Imperfecciones de Bitcoin y Protocolos Estratificados

Las imperfecciones (o limitaciones) de Bitcoin se manifiestan principalmente en varios aspectos (las imperfecciones mencionadas en este artículo se basan en el resumen del libro blanco de Ethereum y no son necesariamente defectos reales).

1. Sistema de cuentas UTXO de Bitcoin

En los proyectos actuales de blockchain, principalmente existen dos tipos de métodos de registro: el modelo de cuenta/saldo y el modelo UTXO. Bitcoin utiliza el modelo UTXO, mientras que Ethereum, EOS y otros utilizan el modelo de cuenta/saldo.

En una billetera de Bitcoin, generalmente podemos ver el saldo de la cuenta; sin embargo, en el diseño original del sistema Bitcoin de Satoshi Nakamoto, no existía el concepto de un “saldo”. El “saldo de Bitcoin” es un derivado de las aplicaciones de billetera de Bitcoin. UTXO (Unspent Transaction Outputs) representa las salidas de transacciones no gastadas, y es un concepto central en la generación y verificación de transacciones de Bitcoin. Las transacciones forman una estructura en forma de cadena donde todas las transacciones legítimas de Bitcoin pueden rastrearse hasta las salidas de una o más transacciones previas. Estas cadenas comienzan con recompensas de minería y terminan con las salidas de transacciones no gastadas actuales.

Por lo tanto, en el mundo real, no hay bitcoins, solo UTXOs. Las transacciones de Bitcoin consisten en entradas y salidas de transacciones; cada transacción gasta una entrada para producir una salida, que luego se convierte en la "salida de transacción no gastada", o UTXO.

La implementación de contratos inteligentes presenta desafíos significativos con el modelo UTXO. Gavin Wood, el diseñador del Libro Amarillo de Ethereum, tiene un profundo entendimiento de UTXO. La característica más significativa de Ethereum es la de contratos inteligentes. Debido a los contratos inteligentes, es difícil para Gavin Wood implementar contratos inteligentes completos en Turing basados en UTXO. El modelo de cuenta, que es inherentemente orientado a objetos, registra cada transacción en la cuenta correspondiente (nonce++). Para facilitar la gestión de cuentas, se introduce un estado global donde cada transacción altera este estado global, análogo a cómo cada pequeño cambio afecta al mundo real. Así, Ethereum y las blockchains públicas posteriores se basan generalmente en varios tipos de sistemas de cuentas.

Otra grave falla de UTXO es su incapacidad para proporcionar un control fino sobre los límites de retiro de la cuenta, lo cual se discute en el libro blanco de Ethereum.

1. Lenguaje de script de Bitcoin, no completo en Turing

Si bien el lenguaje de script de Bitcoin puede admitir varios cálculos, no puede admitir todos los cálculos. La principal omisión es que el lenguaje de script de Bitcoin carece de declaraciones de bucle y declaraciones de control condicional. Por lo tanto, el lenguaje de script de Bitcoin no es Turing-completo, lo que limita sus capacidades. Sin embargo, estas limitaciones evitan que los piratas informáticos utilicen este lenguaje de script para crear bucles infinitos (que podrían paralizar la red) o código malicioso que podría provocar ataques DOS, protegiendo así la red de Bitcoin de ataques DOS. Los desarrolladores de Bitcoin también creen que la cadena de bloques central no debe ser Turing-completa para evitar ataques y congestión de la red. Sin embargo, la razón por la que un lenguaje no Turing-completo es más seguro es insuficiente, y dicho lenguaje solo puede realizar funciones limitadas.

1. Otras imperfecciones de Bitcoin: Seguridad, Escalabilidad

La centralización de la minería es un problema, donde el algoritmo de minería de Bitcoin permite esencialmente a los mineros hacer modificaciones menores al encabezado de bloque millones de veces hasta que la versión modificada del nodo tenga un hash menor que el valor objetivo. Este algoritmo de minería es susceptible a dos formas de ataques de centralización. En primer lugar, el ecosistema de minería está controlado por ASIC (Circuitos Integrados Específicos de Aplicación) y chips de computadora diseñados específicamente para la minería de Bitcoin, los cuales son miles de veces más eficientes en esta tarea. Esto significa que la minería de Bitcoin ya no es altamente descentralizada y equitativa, sino que requiere un capital sustancial para una participación efectiva. En segundo lugar, la mayoría de los mineros de Bitcoin ya no completan la validación de bloque localmente; en cambio, dependen de piscinas de minería centralizadas para proporcionar los encabezados de bloque. Este problema es significativo: actualmente, las tres principales piscinas de minería controlan indirectamente alrededor del 50% del poder de procesamiento en la red Bitcoin.

La escalabilidad es un problema importante para Bitcoin. Usando Bitcoin, los datos crecen aproximadamente 1 MB por hora. Si la red de Bitcoin procesara 2000 transacciones por segundo como Visa, crecería 1 MB cada tres segundos (1 GB por hora, 8 TB por año). Números de transacciones más bajos también han provocado controversia dentro de la comunidad de Bitcoin, ya que blockchains más grandes pueden mejorar el rendimiento, pero con el riesgo de centralización.

Desde la perspectiva del ciclo de vida del producto, algunas de las imperfecciones menores de Bitcoin pueden mejorarse dentro de su propio sistema, limitadas por el sistema actual. Sin embargo, estos problemas pueden resolverse sin tener en cuenta las limitaciones del antiguo sistema si se abordan en un nuevo sistema. Si se está desarrollando un nuevo sistema de blockchain, entonces estas mejoras funcionales menores también deben ser diseñadas y actualizadas.

Diseño en capas

El diseño en capas es una metodología y enfoque utilizado por los humanos para manejar sistemas complejos dividiendo un sistema en múltiples estructuras jerárquicas y definiendo las relaciones y funciones entre estas capas para lograr modularidad, mantenibilidad y escalabilidad del sistema, mejorando así la eficiencia y confiabilidad del diseño del sistema.

Para un sistema de protocolo amplio y extenso, el uso de capas tiene beneficios claros. Este enfoque hace que sea más fácil para las personas entender

, implementar y mejorar módulos. Por ejemplo, en redes informáticas, el modelo ISO/OSI es un diseño de siete capas, pero en la práctica, algunas capas pueden combinarse, como el protocolo TCP/IP de cuatro capas. Las ventajas específicas del apilamiento de protocolos incluyen la independencia y flexibilidad de cada capa, la divisibilidad estructural, la facilidad de implementación y mantenimiento, y la facilitación de los esfuerzos de estandarización.

Desde la perspectiva de los protocolos en capas, la posición de Bitcoin como capa fundamental significa que sus características como UTXO, no completitud de Turing, largos tiempos de bloque, capacidad de bloque pequeña y la desaparición de su fundador no son defectos, sino rasgos que debería tener una capa de red base.

Nota: El autor proporciona explicaciones más detalladas sobre el escalonamiento de protocolos en "Una visión general del sistema de conocimiento básico de construcción de capa 2 de Bitcoin V1.5 (Capa 2)."

2. Importantes Nuevas Tecnologías en el Desarrollo de Bitcoin (Expansión de Bloques y Mejora de Capacidades)

En la sección anterior, exploramos los principales conflictos de la tecnología original de Bitcoin y algunos casos exploratorios, muchos de los cuales llevaron a bifurcaciones duras o la creación de cadenas heterogéneas completamente nuevas. Sin embargo, dentro de la propia cadena de bloques de Bitcoin, estas exploraciones también han dado muchos resultados, fundamentalmente en forma de expansión de bloques y mejora de capacidades. Estos se manifiestan principalmente en los siguientes aspectos:

2.1. OP_RETURN

Los desarrolladores de Bitcoin siempre han buscado expandir las capacidades de Bitcoin, manifestadas de varias formas:

(1) Uso de OP_RETURN

OP_RETURN es un opcode de script utilizado para terminar un script y devolver el valor superior de la pila. Este opcode es similar a la función de retorno en lenguajes de programación. A lo largo de la historia de Bitcoin, la funcionalidad del opcode OP_RETURN ha sido modificada varias veces, y ahora se utiliza principalmente como un método para almacenar datos en el libro mayor. La funcionalidad del opcode OP_RETURN ha experimentado cambios significativos en el pasado, y ahora es un mecanismo importante para almacenar datos arbitrarios en la cadena.

Inicialmente, OP_RETURN se usaba para finalizar prematuramente la ejecución del script, con el resultado de la ejecución presentado como el elemento superior de la pila. Esta operación tenía inicialmente una vulnerabilidad que era fácilmente explotada, pero Satoshi Nakamoto la parcheó rápidamente.

Más cambios en la funcionalidad de OP_RETURN

En la actualización a Bitcoin Core v 0.9.0, los scripts de "salida OP_RETURN" se convirtieron en un tipo de salida estándar, lo que permite a los usuarios agregar datos a "salidas de transacciones no gastables". El volumen de datos disponible en dichos scripts estaba inicialmente limitado a 40 bytes, luego se aumentó a 80 bytes.

Almacenamiento de datos en la cadena de bloques:

Cambiar OP_RETURN para que siempre devuelva falso tuvo resultados interesantes. Dado que no se evalúan otros códigos de operación o datos después de OP_RETURN, los usuarios de la red comenzaron a usar este código de operación para almacenar datos en formatos arbitrarios.

Durante la era de Bitcoin Cash (BCH), desde el 1 de agosto de 2017 hasta el 15 de noviembre de 2018, la longitud de los datos que podían adjuntarse a las salidas de OP_RETURN se amplió a 220 bytes, lo que permitió datos más significativos para fomentar aplicaciones innovadoras en la cadena de bloques, como publicar contenido en las redes sociales de la cadena de bloques.

En BSV, el límite de 220 bytes aún se mantuvo durante un corto período. Más tarde, en enero de 2019, debido a que el opcode OP_RETURN termina el script de una manera que los nodos no verifican ningún opcode posterior, los nodos tampoco comprobaron si el script estaba dentro del límite máximo de tamaño de script de 520 bytes. En consecuencia, los operadores de nodos de la red decidieron aumentar el volumen máximo de transacciones a 100 KB, otorgando así a los desarrolladores más libertad para la innovación de aplicaciones, permitiendo que las nuevas aplicaciones coloquen datos más grandes y complejos en el libro mayor de Bitcoin. En ese momento, hubo un ejemplo de aplicación donde alguien colocó un sitio web completo en el libro mayor de BSV.

Aunque OP_RETURN tiene algunas expansiones funcionales, sus capacidades generales siguen siendo limitadas. Esto llevó a la tecnología de Testigo Segregado.

(2) SegWit (Testigo Segregado)

Testigo segregado, o SegWit, fue propuesto por primera vez por Pieter Wuille (desarrollador principal de Bitcoin y cofundador de Blockstream) en diciembre de 2015 y más tarde se convirtió en Bitcoin BIP 141. SegWit modifica ligeramente la estructura de datos de las transacciones en los bloques de Bitcoin para abordar los siguientes problemas:

1) Problema de maleabilidad de transacción.

2) En las pruebas SPV, la transferencia de firmas de transacciones se vuelve opcional, lo que reduce el volumen de datos de las pruebas de Merkle.

3) Aumento indirecto de la capacidad de bloques.

Los dos primeros elementos aumentan principalmente la seguridad y el rendimiento, con mayor impacto en las nuevas tecnologías siendo el tercer elemento, que aumentó indirectamente la capacidad de bloque (ver el concepto de peso de bloque a continuación), sentando las bases para la mejora de la capacidad de Bitcoin, y conduciendo a mejoras adicionales en Taproot (la segunda versión de Testigo Segregado).

A pesar de que la realización aumentó la capacidad del bloque, SegWit todavía está sujeto a límites de tamaño de bloque. El límite de tamaño de bloque de Bitcoin es de 1 M bytes, y dado que los datos del testigo no se incluyen en este límite, todavía hay una restricción en el tamaño total del bloque para evitar el abuso de los datos del testigo. Se introdujo un nuevo concepto llamado peso del bloque:

Peso del bloque = Tamaño base * 3 + Tamaño total

El tamaño base es el tamaño del bloque excluyendo los datos de testigos

El tamaño total es el tamaño total del bloque serializado según BIP 144, que incluye tanto los datos base como los datos de testigos.

SegWit restringe el peso del bloque <= 4 M.

SegWit también técnicamente permite la expansión de Bitcoin para usar la Red Lightning, lo cual no se detalla aquí.

(3) Taproot (Testigo segregado V2)

Si usas directamente la palabra Taproot, muchas personas podrían pensar que es un concepto nuevo, pero si entiendes que es la segunda versión de Segregated Witness, la mayoría captará la conexión. Taproot está asociado con BIPs 340, 341 y 342, llamados: BIP 340 (Firmas Schnorr para secp256k1), BIP 341 (Taproot: Reglas de gasto de la versión 1 de SegWit),

BIP 342 (Validación de scripts de Taproot).

En noviembre de 2021, Taproot se activó oficialmente como una bifurcación suave. Esta actualización combina BIP 340, BIP 341 y BIP 342. Entre ellos, BIP 340 introduce firmas Schnorr que pueden validar simultáneamente múltiples transacciones, reemplazando el Algoritmo de Firma Digital de Curva Elíptica (ECDSA), ampliando una vez más la capacidad de la red y acelerando el procesamiento de transacciones por lotes, brindando posibilidades para implementar contratos inteligentes complejos; BIP 341 implementa Árboles de Sintaxis Abstracta Merklizados (MAST) para optimizar el almacenamiento de datos de transacciones en la cadena de bloques; BIP 342 (Tapscript) utiliza el lenguaje de codificación de scripts de Bitcoin para mejorar las capacidades de scripts nativos de Bitcoin.

La expansión del espacio causada por Segwit y Taproot condujo a la creación de firmas Schnorr, árboles MAST y scripts de Taproot, cuya misión es expandir las funcionalidades de la red principal de Bitcoin.

2.2 Firmas Schnorr, MAST y Scripts de Taproot

Desde la Sección 2.1, observamos la exploración continua de Bitcoin en la escalabilidad y el mejoramiento de la capacidad, que culmina en el desarrollo de la tecnología Taproot, junto con varias tecnologías cruciales como Schnorr, MAST y Taproot Scripts, que realmente han ampliado las capacidades de Bitcoin.

(1) Firmas Schnorr

La evolución de Taproot, al expandir capacidades, requirió demandas específicas del algoritmo de firma, introduciendo así firmas Schnorr para reemplazar el algoritmo de firma digital de curva elíptica (ECDSA). Las firmas Schnorr son un esquema de firma digital que puede firmar transacciones y mensajes de manera eficiente y segura. Fueron descritas por primera vez por Claus Schnorr en un documento de 1991. Schnorr es aclamado por su simplicidad, seguridad demostrable y linealidad.

Ventajas de las Firmas Schnorr:

1) Las firmas de Schnorr ofrecen varios beneficios, incluyendo eficiencia y privacidad mejorada mientras se retienen todas las funcionalidades y suposiciones de seguridad de ECDSA. Permiten tamaños de firma más pequeños, tiempos de verificación más rápidos y una resistencia mejorada a ciertos tipos de ataques.

2) Una ventaja notable de las firmas Schnorr es la agregación de claves, que agrega múltiples firmas en una sola que es válida para la suma de sus claves. En otras palabras, Schnorr permite que múltiples partes cooperen para generar una sola firma que sea válida para el total de sus claves públicas. La agregación de firmas permite combinar las firmas de varios firmantes en una sola firma.

La agregación de claves puede reducir las tarifas de transacción y mejorar la escalabilidad subyacente, ya que las firmas electrónicas de configuraciones multisig ocupan el mismo espacio en un bloque que las de transacciones de una sola parte. Esta característica de Schnorr se puede utilizar para reducir el tamaño de los pagos multisig y otras transacciones relacionadas con multisig, como las transacciones de canales de la red Lightning.

3) Otra característica importante de las firmas Schnorr es su no maleabilidad.

4) Schnorr también ofrece numerosas ventajas en cuanto a la privacidad. Hace que los esquemas multisig sean indistinguibles de los tradicionales de una sola clave para los observadores externos, lo que dificulta diferenciar el gasto multisig del gasto de una sola firma en la cadena. Además, en configuraciones de multisig de n-de-m, Schnorr hace que sea más difícil para los observadores externos determinar qué participantes firmaron en una transacción y cuáles no lo hicieron.

Las firmas Schnorr se implementan en BIP-340 como parte de la actualización de bifurcación suave de Taproot y se activaron el 14 de noviembre de 2021, en el bloque 709,632. Schnorr hace que las firmas digitales de BTC sean más rápidas, seguras y fáciles de manejar. Es importante destacar que las firmas Schnorr son compatibles con las criptográficas de BTC, lo que permite que se introduzcan a través de una actualización de bifurcación suave.

(2) Árboles de sintaxis abstracta MAST

Hay una ligera ambigüedad en la abreviatura de MAST en chino e inglés. Oficialmente, BIP (BIP 114) y algunos artículos utilizan la abreviatura MAST para: Árbol de sintaxis abstracta merklizado. Otras fuentes traducen Árboles de scripts alternativos merklizados (MAST) al chino como Árboles de scripts de reemplazo merklizados (MAST). En el libro 'Dominando Bitcoin' y un artículo, se utiliza esta abreviatura: https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot-upgrade.

Los Árboles de Sintaxis Abstracta Merklizados y los Árboles de Script Alternativos Merklizados (MAST) parecen tener la misma función. Desde una perspectiva de traducción, personalmente creo que es mejor mantener el uso encontrado en el protocolo oficial de Bitcoin BIP.

El concepto detrás de MAST proviene de dos ideas: Árboles de Sintaxis Abstracta y Árboles de Merkle.

Los árboles de sintaxis abstracta (AST) pertenecen al ámbito de los principios de compiladores y la lingüística formal en la informática. Un árbol de sintaxis abstracta es una representación intermedia durante el proceso de compilación, utilizada para representar la estructura semántica del código fuente. Transforma el código fuente en una estructura de árbol, donde cada nodo representa una unidad semántica, y las aristas representan las relaciones entre ellos. Los árboles de sintaxis abstracta desempeñan un papel crucial en las etapas de análisis léxico y sintáctico del compilador, ayudando a comprender el significado del código fuente y llevar a cabo procesos posteriores de optimización y generación de código objetivo. En pocas palabras, un árbol de sintaxis abstracta (AST) es un método para describir un programa dividiéndolo en bloques independientes, lo que facilita el análisis y la optimización del programa. Para generar un AST, todas las ecuaciones y sus premisas deben estar conectadas con flechas hasta que se identifiquen todas las premisas. La imagen a continuación es un AST de un script.

Por otro lado, un árbol de Merkle se puede utilizar para verificar si un elemento pertenece a un conjunto sin necesidad de conocer todo el conjunto. Por ejemplo, las carteras de Verificación de Pago Simplificada de Bitcoin (carteras SPV) utilizan árboles de Merkle para verificar si una transacción existe dentro de un bloque, ahorrando ancho de banda al no descargar el bloque completo.

Para generar un árbol de Merkle, cada elemento se hashea individualmente para crear un identificador único; luego, estos identificadores se emparejan y se vuelven a hashear para crear un identificador para ese par; este proceso se repite hasta que solo quede un identificador, conocido como la “raíz de Merkle”, que es un identificador conciso que representa todo el conjunto.

Al verificar si un elemento pertenece a un conjunto, el propietario del conjunto puede proporcionarte todos los identificadores de ese elemento hasta la raíz de Merkle. Esto demuestra que el elemento realmente forma parte del conjunto.

En resumen, la tecnología detrás de AST te permite dividir un programa en múltiples bloques pequeños, mientras que un árbol de Merkle nos permite verificar que estos bloques son realmente partes de un programa completo, sin exponer el programa entero. Este es el principio básico de MAST, que permite a los gastadores reemplazar condiciones no utilizadas en una sola transacción con una prueba de Merkle, con los beneficios de reducir el tamaño de la transacción, mejorar la privacidad y respaldar contratos más grandes.

Hay muchos ejemplos de árboles MAST en línea, y aquellos familiarizados con el desarrollo de programas pueden entender claramente la lógica relacionada con un proceso MAST.

Con la llegada de los árboles de sintaxis abstracta MAST, se vuelve necesario extender las capacidades de sintaxis nativas de Bitcoin, lo que lleva a la creación de Scripts de Taproot.

(3) Scripts de Taproot

Introducido bajo el protocolo BIP 342, Taprootscript es una versión mejorada del script original de Bitcoin, esencialmente una colección de códigos de operación con comandos que admiten la implementación de otros BIP. Taprootscript también elimina el límite de tamaño de script de 10,000 bytes, proporcionando un mejor entorno para crear contratos inteligentes en la red Bitcoin. Esta actualización también sentó las bases para el posterior desarrollo de Ordinales, que utilizan scripts de gasto de ruta de script de Taproot para adjuntar datos adicionales. Se pueden encontrar más detalles en el sitio web oficial:

https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

Las capacidades de TaprootScript aún no se han utilizado completamente y futuros desarrollos demostrarán su potencial, especialmente en la conexión de la red de primera capa de Bitcoin con tecnologías de segunda capa, donde es probable que se utilicen más extensamente Taproot, MAST y TaprootScripts.

2.3 Ordinales, Inscripciones, BRC 20 y Otros Protocolos

Con herramientas fundamentales como Segwit, Taproot, Schnorr, MAST y Scripts de Taproot en el ecosistema de Bitcoin, han comenzado a surgir nuevas aplicaciones. Inicialmente, estas aplicaciones eran ligeras y simples.

(1) Protocolo Ordinales, Inscripciones y BRC 20

La creación del protocolo Ordinals está altamente asociada con el concepto de satoshis. El protocolo introduce los conceptos de ordinales e inscripciones. Los ordinales son un esquema de numeración que asigna un número único a cada satoshi en la red de Bitcoin de acuerdo con el orden en que fueron minados. En el protocolo, el identificador ordinal permanece inalterado independientemente de cómo se transfiera el satoshi entre diferentes billeteras. Los nodos completos de Bitcoin que ejecutan el software de código abierto de Rodarmor, ORD, pueden rastrear estos satoshis numerados, proporcionando un mecanismo preciso para que las personas sigan cada satoshi y los verifiquen de forma independiente.

Las inscripciones implican grabar información en los satoshis. Al aprovechar SegWit y Taproot, el protocolo de Ordinals permite grabar archivos más pequeños que 4 MB en cada satoshi en un bloque de Bitcoin, estas son las inscripciones, que pueden contener varios tipos de información como texto, imágenes o videos.

En términos simples, el esquema de numeración ordinal proporciona a cada satoshi un identificador único y rastreable, dándole características no fungibles. Las inscripciones permiten la adición de datos indivisibles en estos ordinales, similar a crear arte en un lienzo en blanco. En conjunto, permiten que Bitcoin albergue un nuevo estándar para los NFT. Esencialmente, Ordinals es como un protocolo NFT pero a diferencia de ETH u otras blockchains públicas donde los metadatos de NFT suelen almacenarse en IPFS o servidores centralizados, Ordinals incrusta metadatos en los datos de testigos de la transacción, como si estuvieran “grabados” en un satoshi específico.

BRC-20: Inspirado en el protocolo Ordinals, usuario de Twitter @domodata creó el estándar experimental de tokens fungibles BRC-20 en Bitcoin el 8 de marzo de 2023. Al asignar diferentes "atributos" a cada satoshi, el protocolo Ordinals crea NFT de la red BTC, mientras que BRC-20 lo hace proporcionando un "formato" y "atributos" uniformes para los tokens fungibles (FT) basados en BTC. BRC-20 emplea el protocolo Ordinals para escribir un texto JSON en una inscripción de BTC para implementar contratos de tokens, acuñar y transferir tokens. Los aspectos clave de la implementación incluyen el nombre del token, el suministro total y la acuñación máxima por ocasión. En el caso de las transacciones que impliquen transferencias o compra/venta, un NFT adicional realiza un seguimiento de los saldos fuera de la cadena. Un mecanismo de acuñación "por orden de llegada" ofrece oportunidades justas de emisión y participación. Sin embargo, la infraestructura relativamente poco desarrollada del ecosistema BTC y su empinada curva de aprendizaje, junto con la baja liquidez, facilitan que los tokens BRC-20 como ordi, sats y rats aumenten, creando un mito de creación de riqueza.

(2) Otros Protocolos - Atomicals, ARC 20

El desarrollo del protocolo Atomicals fue bastante dramático. Su fundador, Arthur, inicialmente quería desarrollar un proyecto DID sobre el recién lanzado protocolo Ordinals, pero se dio cuenta de que Ordinals tenía muchas limitaciones que no eran favorables para soportar algunas de las características que quería implementar. En consecuencia, el 29 de mayo de 2023, Arthur tuiteó sobre su concepto para el protocolo Atomicals, que fue lanzado posteriormente el 17 de septiembre de 2023, después de meses de desarrollo. Posteriormente, el protocolo Atomicals dio origen a conceptos como Dmint, Bitwork, ARC-20 y RNS, con planes futuros para introducir soluciones AVM y de división. Al igual que Ordinals y BRC-20, desplegar tokens fungibles en Atomicals resulta en la creación de ARC-20. Los lectores interesados en ARC-20 pueden leer más aquí: Tokens ARC-20.

(3) Otros Protocolos - Rune

A medida que evolucionaba el ecosistema, Casey Rodarmor, el creador de Ordinals, señaló que los tokens BRC-20 tienen la "consecuencia desafortunada de la dispersión de UTXO" y sugirió Runas como una solución alternativa basada en UTXO. Los protocolos existentes generalmente sufren de implementaciones complejas, malas experiencias de usuario, salidas de transacciones no gastadas (UTXOs) basura y operaciones que requieren tokens nativos.

La transferencia de Runes utiliza OP_RETURN, y el primer resultado de datos en el mensaje del protocolo se decodifica en una secuencia de enteros, interpretada como una serie de tuplas (ID, OUTPUT, AMOUNT). Si la cantidad de enteros decodificados no es un múltiplo de tres, el mensaje del protocolo es inválido. ID se refiere al ID del Token que se va a transferir, OUTPUT es el índice de salida asignado (es decir, a qué salida se asigna) y AMOUNT es la cantidad asignada. Después de procesar todas las asignaciones de tuplas, cualquier Token de Runes no asignado se asigna a la primera salida no OP_RETURN, pudiendo el resto ser inscrito con Tokens de Runes en la salida OP_RETURN que contiene el mensaje del protocolo.

La emisión de Runas se basa en el seguimiento de UTXO de tokens homogéneos. Si el mensaje del protocolo incluye un segundo envío de datos, representa una transacción de emisión. El segundo envío de datos se decodifica en dos enteros, SÍMBOLO y DECIMALES. Si quedan enteros adicionales, el mensaje del protocolo es inválido. SÍMBOLO es un símbolo legible básico de 26 caracteres, similar a los utilizados en nombres ordinales, con los únicos caracteres válidos siendo de la A a la Z. DECIMALES indican los lugares decimales a utilizar al emitir Runas. Si SÍMBOLO aún no se ha asignado, el Token de Runas se le asigna un valor de ID (comenzando desde 1). Si SÍMBOLO ya ha sido asignado o es uno de BITCOIN, BTC o XBT, no se crearán nuevas Runas. Esta es una característica especial del protocolo de Runas, no vincula los registros de saldo a las direcciones de billetera, sino que los almacena dentro del propio UTXO. Los nuevos Tokens de Runas comienzan desde la transacción de emisión, especificando la cantidad, símbolo y lugares decimales, y esta cantidad se asigna a UTXOs específicos. Los UTXOs pueden contener cualquier cantidad de Tokens de Runas, independientemente de su tamaño, y solo se utilizan para el seguimiento de saldos. Luego, la función de transferencia utiliza este UTXO, dividiéndolo en múltiples nuevos UTXOs de tamaño arbitrario que contienen diferentes cantidades de Runas, enviando los registros a otros. En comparación con BRC-20, Runas simplifica la capa de consenso, volviéndose más simple sin depender de datos fuera de la cadena y carecer de tokens nativos, lo que lo hace altamente adecuado para el modelo UTXO nativo de Bitcoin.

(4) Otros protocolos - BTC Stamps, SRC 20, SRC 721

El sistema de Bitcoin Stamps fue lanzado por Mike In Space en marzo de 2023, inicialmente como un proyecto de prueba en Counterparty, una capa 2 de Bitcoin que ha existido desde 2014. Debido a las actualizaciones en sus protocolos subyacentes, Stamps ha pasado completamente a Bitcoin, pasando a ser conocido como SRC-20 el verano pasado. Inicialmente, Mike imaginó Stamps como un método para acuñar NFTs permanentes de Bitcoin. Sin embargo, el protocolo se ha expandido para replicar BRC-20, un tipo de token reemplazable por lotes que ha prosperado en Bitcoin debido a la locura de la inscripción desencadenada por el lanzamiento de Ordinals de Casey Rodarmor en enero de 2023.

La principal diferencia entre Stamps y Ordinales radica en su arquitectura. Stamps almacena sus metadatos en salidas de transacción no gastadas (UTXO) con firma múltiple, mientras que Ordinales almacena sus metadatos en la parte de "testigo" de las transacciones de Bitcoin. Esta diferencia arquitectónica pone de manifiesto los compromisos realizados por los desarrolladores. Por ejemplo, el método UTXO de Stamps hace que no se puedan podar, por lo que aparentan ser permanentes, aunque su costo de fabricación es mayor que el de Ordinales. Por el contrario, el uso de datos de testigo por parte de Ordinales finalmente hace que sean podables, y su costo de fabricación es menor que el de Stamps.

Así, mientras que los Ordinales pueden ofrecer la mejor relación durabilidad-coste para los NFT de criptomonedas de hoy (que también se pueden obtener en Ethereum, pero a un mayor coste de construcción), parece que Stamps proporciona actualmente la mejor garantía de permanencia directa.

Tras la aparición de los sellos BTC, se desarrollaron SRC 20 y SRC 721, que funcionan de manera similar a BRC-20. BRC-20 está construido sobre el protocolo Ordinales, mientras que SRC-20 está construido sobre BTC STAMPS. Los lectores interesados pueden leer más sobre la documentación de SRC 20 y SRC 721 aquí:

Protocolo SRC 20

Protocolo SRC 721

Esto concluye la introducción a las nuevas tecnologías significativas en la red de la Capa 1 de Bitcoin. Para una mayor escalabilidad y mejora, el enfoque se trasladará a la infraestructura de capa superior de Bitcoin, como la Capa 2 de Bitcoin o soluciones que aprovechen la Red Lightning. Para obtener más información sobre este tema, se sugiere a los lectores que lean 'Una Guía Completa de la Infraestructura de la Capa 2 de Bitcoin, Versión 1.5' y 'Desde la Perspectiva de las Máquinas de Estado: Observando la Arquitectura y el Camino de Construcción de Futuras Aplicaciones Web3.0', u otros artículos relacionados con la construcción o diseño arquitectónico de la Capa 2 de Bitcoin.

3. Nuevo uso de tecnología y necesidades de desarrollo futuro

Basándonos en el contenido de la Sección 2, observamos que la evolución tecnológica dentro del ecosistema Bitcoin ha sentado las bases para aplicaciones más amplias. Sin embargo, dado que el desarrollo es un proceso y algunas tecnologías relacionadas todavía son inmaduras, existe una diferencia significativa entre las aplicaciones populares actuales y los usos comunes futuros.

3.1 Métodos de uso de nueva tecnología

De las secciones anteriores, vemos que la esencia del desarrollo tecnológico de Bitcoin se trata de expandir la capacidad y capacidades del bloque.

Expansión de bloques:Segregated Witness (SegWit) ha ampliado efectivamente la capacidad de bloque, aunque hay varias propuestas para recortar los datos de testigos, tales eventos son improbables, especialmente después de que los datos de testigos hayan adquirido más importancia.

Expansión de capacidades:Tecnologías como Taproot, Schnorr, MAST y Scripts de Taproot han mejorado las capacidades de Bitcoin. En particular, la combinación de MAST y Scripts de Taproot amplía las capacidades del lenguaje de script nativo de Bitcoin, permitiendo el manejo de escenarios más complejos. Sin embargo, la expansión de estas capacidades también aumenta la complejidad del desarrollo y la comprensión de Bitcoin, ya que el desarrollo de script no se realiza en un lenguaje de alto nivel. Además, la expansión de estas capacidades se queda atrás en comparación con la comprensión y el ritmo de aprendizaje de los usuarios en relación con la ampliación de la capacidad de los bloques.

La simplicidad de utilizar la expansión de bloques frente a la complejidad de la expansión de capacidad explica por qué los usuarios almacenan inicialmente pequeñas imágenes NFT en la red principal de Bitcoin, lo que lleva a la aparición de aplicaciones como BRC 20. La mayoría de las aplicaciones actualmente en la red principal de Bitcoin están explorando usos posteriores a la expansión de bloques. Una pequeña parte de las aplicaciones están comenzando a explorar la expansión de capacidad, como la conexión entre las capas primera y segunda en BEVM, que utiliza prominentemente los elementos básicos mencionados anteriormente. La combinación de firmas Schnorr, contratos MAST y la red de nodos livianos de Bitcoin (BTC L2) es un caso representativo de aprendizaje sobre cómo conectar las capas primera y segunda. Se esperan casos de expansión de capacidad más extensos en el futuro.

¿Dónde deben estar los límites de la expansión de la capacidad? Podemos juzgar desde la perspectiva del diseño en capas. Si estas capacidades están destinadas principalmente como conexiones entre la primera y segunda capas de Bitcoin, entonces no deberían volverse demasiado complicadas. Sin embargo, impulsados por la creatividad humana y el fuerte atractivo de la emisión y gestión de activos, algunos equipos o individuos explorarán más escenarios para la expansión de la capacidad.

3.2 Necesidades de Desarrollo Futuro

La razón más directa de la aparición de la tecnología blockchain es la moneda digital, por lo que la emisión y gestión de activos son necesidades directas dentro del ámbito de Bitcoin o blockchain. Desde la exploración de monedas de colores hasta aplicaciones como BRC 20 y ARC 20, así como ICOs e IDOs en Ethereum, todas estas son exploraciones de la emisión de activos. Aplicaciones como Uniswap, Préstamos y AMM se centran en la gestión de activos. Estos tipos de aplicaciones se han desarrollado en redes como Ethereum y, a medida que evoluciona la tecnología del ecosistema de Bitcoin, es probable que estas aplicaciones de gestión de activos se trasladen al ecosistema de Bitcoin, especialmente a la segunda capa de Bitcoin.

Solo después de satisfacer las necesidades de emisión y gestión de activos habrá capacidad y tiempo para desarrollar aplicaciones a gran escala para la era Web3.0 (también conocida como la Era del Valor). La arquitectura del sistema para futuras aplicaciones a gran escala de Web3.0 se discute en “Desde la Perspectiva de las Máquinas de Estado Visualizando la Segunda Capa de Bitcoin, Observando la Arquitectura de Aplicaciones Futuras de Web3.0 y el Camino de Construcción.”

El camino hacia la construcción es un proceso de satisfacer continuamente las necesidades, que se puede dividir en etapas a corto, mediano y largo plazo. El corto plazo implica nuevas aplicaciones tecnológicas en la red principal de Bitcoin y etapas simples de construcción de segunda capa basada en blockchain para cumplir con las principales expansiones de capacidad para diversas aplicaciones financieras. El mediano plazo implica etapas más avanzadas de construcciones de segunda capa basadas en blockchain y sistemas distribuidos de segunda capa, atendiendo a diversas aplicaciones financieras y de confianza. El largo plazo implica la construcción completa del ecosistema de Bitcoin a gran escala, construyendo verdaderamente la era Web3.0.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [Foresightnews], Todos los derechos de autor pertenecen al autor original [付少庆、SatoshiLab、万物岛 BTC 工作室]. Si hay objeciones a esta reimpresión, por favor póngase en contacto con el Gate Learnequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, se prohíbe copiar, distribuir o plagiar los artículos traducidos.