Análisis profundo de los mecanismos de diseño subyacentes y las limitaciones del protocolo Runes

1. Runes( Protocolo de Runes)

En el último año, el tema más destacado en el ámbito del web3 ha sido, sin duda, la explosión del ecosistema de inscripciones. Su origen se remonta al protocolo Ordinals, que otorga un número único a cada satoshi en Bitcoin. El desarrollador principal de Ordinals, Casey, presentó el código base del protocolo Runes ya en septiembre del año pasado, pero no se ha lanzado oficialmente. Esto llevó a que algunos proyectos bifurcaran el código anticipadamente y lanzaran protocolos como RunesAlpha. A pesar de las controversias, el crecimiento de cientos de millones de dólares en capitalización de mercado en solo unos meses también demuestra el enorme potencial del protocolo Runes.

Se espera que la versión oficial del protocolo Runes se lance oficialmente en la mainnet de Bitcoin alrededor del 20 de abril de 2024. Esto significa que los desarrolladores del proyecto, los proveedores de billeteras y las plataformas de intercambio de NFT/FT enfrentarán un gran desafío: ¿cómo adaptar directamente la mainnet sin una red de prueba?

Este artículo sistematizará la evolución de los campos subyacentes del proyecto Runes, ayudando a los lectores a comprender fundamentalmente las diferencias entre Runes y los protocolos FT como Brc20, Arc20, para que puedan evaluar y participar de manera racional.

2. Método de registro de datos en la cadena de Bitcoin

En Bitcoin, hay principalmente dos métodos para adjuntar datos fuera de la cadena a la cadena: grabado y marcado.

2.1 Principios básicos de grabado

Runes utiliza una técnica de grabado, que es un método para registrar información directamente en la cadena. En concreto, se trata de escribir datos en el campo op-return de los UTXO (salidas de transacción no gastadas) de Bitcoin. Esta función comenzó en la versión 0.9 del cliente Bitcoin Core en 2014. OP_RETURN creó una salida verificable pero no consumible, que permite almacenar datos en la cadena de bloques.

En el explorador de bloques de Bitcoin, se puede ver fácilmente la información op-return adjunta a la transacción. Por ejemplo, la salida #3 de una transacción puede ser un rectángulo circular cerrado, lo que indica que no puede ser transferido o consumido nuevamente. Esto es como el área de notas de la transacción, que se guarda de forma permanente en el espacio de almacenamiento de Bitcoin y se puede encontrar a través del índice del hash de la transacción.

2.2 Principios básicos de grabado

Los protocolos como Ordinals/brc20 integran metadatos en los datos de testigo de las transacciones. Este proceso se lleva a cabo mediante Testigos Aislados y "pago a Taproot" (P2TR), e incluye dos fases: presentación y revelación, que requieren completar dos transacciones.

P2TR es un tipo de salida de transacción introducido en la actualización Taproot de Bitcoin en 2021, que permite almacenar diferentes condiciones de transacción de manera más privada. En concreto, las direcciones P2TR se generan utilizando un hash de script, proporcionando un script real (que contiene datos de inscripción) al gastar. Por lo tanto, para subir los datos de inscripción, primero se debe generar un UTXO (transacción de envío) pagado a esta dirección P2TR generada por el script, y luego al gastar este UTXO, se debe proporcionar un script real en el script de testigo, lo que permite subir los datos de inscripción a la cadena (revelar la transacción).

El protocolo Ordinals establece que las inscripciones se vinculan al primer satoshi del primer input después de completar estas dos transacciones.

2.3 Comparación de dos esquemas de datos en la cadena

Grabado:

• Ventajas: lógica simple e intuitiva, bajo costo de transacción, no ocupa el pool de memoria de los nodos completos.
• Desventajas: limitado a una longitud de 80 bytes, se requiere una codificación de datos altamente comprimida.

Grabado:

• Ventajas: casi no hay restricciones de tamaño, posee cierta capacidad de protección de la privacidad, soporta múltiples formas de juego (como bloqueo temporal, prueba de trabajo).
• Desventajas: requiere dos transacciones en la cadena, el costo final es alto y ejerce una gran presión sobre el pool de memoria de los nodos completos.

3. Análisis del diseño subyacente de Runes

3.1 Runes versión 0.11

Los campos del protocolo Runes en sus primeras etapas se dividen en tres partes: edicts (información de transferencia de activos), etching (información de despliegue de activos) y burn (quema).

Cuando la información en op_Return se decodifica y presenta la información de edicts en el formato correcto, el analizador fuera de la cadena calculará la situación de transferencia de activos del usuario, el campo output especifica el objetivo de la transferencia.

El contenido de grabado define la información principal sobre el despliegue de activos. En comparación con ERC721, la principal diferencia radica en que los campos limit y term restringen la cantidad de acuñación y el intervalo de acuñación. Esto refleja la diferencia fundamental entre los proyectos de inscripciones y runas y la emisión de activos a través de contratos inteligentes de Ethereum. Debido a la falta de verificación de contratos inteligentes en la cadena, el protocolo de inscripciones define de manera uniforme la forma en que se emiten los activos y los usuarios participan en la acuñación para lograr un lanzamiento justo.

3.2 Runes versión 0.18

Los campos del protocolo Runes en la última versión se dividen en cuatro aspectos:

1. edictos: definen la dirección de transferencia de activos, se añade el parámetro pointer para modificar la dirección de transferencia predeterminada, adaptándose a la situación donde múltiples activos Runes se transfieren simultáneamente, reduciendo la cantidad de codificación y los costos de transacción.

2. Mint: nuevo campo, limita que una transacción solo pueda acuñar un activo, equilibrando la línea de salida entre usuarios técnicos y usuarios comunes.

3. grabado: La forma de despliegue de activos ha cambiado significativamente. Los principales cambios incluyen:

   • El ID de activo se cambia a formato de cadena, ahorrando espacio de codificación.
   • el campo terms introduce los parámetros height y offset, permitiendo al emisor especificar el punto de inicio y final de la acuñación.
   • el parámetro cap controla el número total de emisiones.
   • Introducir reglas de liberación de longitud de nombre para controlar recursos escasos.
   • Utilizar tecnología de grabado (commit y reveal) para el despliegue, proporcionando protección de la privacidad.

4. turbo: nuevo campo, reservado para futuros cambios en el protocolo.

4. Evaluación del nuevo protocolo de Runas

Ventajas:

• Se ajusta a las necesidades del mercado y resuelve el problema de los activos de baja calidad que prevalecen en el ecosistema de inscripciones.
• Integrar el protocolo Ordinals, con una base de usuarios lista para usar.
• Como protocolo FT, compensa las deficiencias de Ordinals en el funcionamiento del mercado.
• Utilizando op_Return para registrar datos en la cadena, proporcionando una capacidad de libro mayor flexible y una alta seguridad.

Desventajas:

• Existen desafíos en el momento del mercado, el tiempo de desarrollo ajustado puede afectar el desarrollo inicial del ecosistema.
• Las reglas son complejas, y la longitud del nombre del activo puede aumentar el riesgo de que los usuarios sean víctimas de phishing.
• Existen dudas sobre la compatibilidad futura, en comparación con otros protocolos, la disposición en L2 o BVM parece un poco rezagada.