Ayer, el creador de Ordinals, Casey Rodarmor, publicó un blog en el que presenta un nuevo protocolo de token fungible (FT), Runes.
En cuanto a si Bitcoin necesita FT, Casey Rodarmor afirmó en su tweet que FT tiene dos caras. Por un lado, el 99,99% de los FT son "mierda" y estafas que debilitan la pureza de Bitcoin; por otro lado, aportan muchos ingresos por comisiones, desarrolladores y usuarios al ecosistema de Bitcoin. "A la gente le encantan los tokens y son como los casinos cyberpunk, por lo que es probable que los ingresos por tarifas sean sustanciales y continuos hasta que se alivien por completo las preocupaciones sobre los presupuestos de seguridad (cibernética). "
Añadió que ya han surgido protocolos FT como BRC-20, RGB y Taproot. En comparación con los protocolos simples en cadena, protocolos como RGB y Taproot son complejos y pueden plantear desafíos a la experiencia del usuario. BRC-20 es muy simple y puede proporcionar una buena experiencia de usuario en comparación con RGB/Taproot, que requiere una infraestructura de almacenamiento y recuperación de datos fuera de la cadena; pero el problema con los tokens BRC 20 es que generan "UTXO basura" y ocupan bits de espacio.
Rodarmor dijo que Runes es un protocolo basado en UTXO que se adapta a Bitcoin de forma más natural y promueve la minimización de las colecciones de UTXO al evitar la creación de "UTXO basura".
El siguiente contenido proviene de la publicación del blog de Casey Rodarmor y fue compilado por Odaily Planet Daily
No estoy seguro de si crear un nuevo protocolo de token fungible (FT) para Bitcoin sea una buena idea. El 99,9% del FT son estafas y memes. Sin embargo, no parece que vayan a desaparecer pronto, al igual que los casinos no parecen desaparecer pronto.
La creación de un buen protocolo FT para Bitcoin puede generar considerables ingresos por tarifas de transacción, atención de los desarrolladores y usuarios de Bitcoin. Además, si el protocolo tiene una huella más pequeña en la cadena e incentiva la gestión responsable de UTXO, puede reducir el daño en comparación con los protocolos existentes. Por ejemplo, el actualmente popular BRC-20 ha llevado a la generación de una gran cantidad de UTXO basura.
Si comparamos los protocolos FT existentes, encontraremos que tienen varias diferencias importantes:
Complejidad: ¿Qué tan complejo es el protocolo? ¿Es fácil de implementar? ¿Es fácil adoptar?
Experiencia del usuario: ¿Existen detalles de implementación que afecten negativamente a la experiencia del usuario? En particular, los protocolos que se basan en datos fuera de la cadena tienen una huella más ligera dentro de la cadena, pero introducen una complejidad significativa y requieren que los usuarios ejecuten sus propios servidores o descubran e interactúen con servidores existentes.
Modelo de estado: los protocolos basados en UTXO encajan de forma más natural en Bitcoin y promueven la minimización del conjunto de UTXO al evitar la creación de UTXO "basura".
Tokens nativos: los protocolos con tokens nativos necesarios para el funcionamiento del protocolo son engorrosos, retirables y, naturalmente, menos adoptados.
Según las dimensiones anteriores, los resultados de la comparación de los protocolos FT existentes en el ecosistema Bitcoin son los siguientes:
BRC-20: No basado en UTXO, y bastante complejo ya que requiere el uso de teoría ordinal en algunas operaciones;
RGB: muy complejo, se basa en datos fuera de la cadena, se ha desarrollado durante mucho tiempo y no se ha adoptado;
Contraparte: Tiene tokens nativos necesarios para determinadas operaciones, en lugar de los basados en UTXO;
Omni Layer: tiene tokens nativos necesarios para determinadas operaciones, en lugar de los basados en UTXO;
Activos Taproot: un poco complicados y se basan en datos fuera de la cadena.
Para Bitcoin, ¿cómo sería un protocolo FT simple basado en UTXO con una buena experiencia de usuario? A continuación, me gustaría presentarles una solución genial llamada "Runas".
(1. Información general
Los saldos de runas se mantienen en UTXO; UTXO puede contener cualquier cantidad de runas.
Una transacción contiene un mensaje de protocolo si contiene una salida cuya clave pública de script contiene OP_RETURN seguida de una inserción de datos con una R mayúscula ASCII. El mensaje de protocolo son todos los datos enviados después del primero.
Las runas ingresadas en transacciones con mensajes de protocolo no válidos se destruirán, lo que permitirá que futuras actualizaciones cambien la forma en que se asignan o crean las runas, evitando que los clientes más antiguos asignen saldos de runas incorrectamente.
Los números enteros se codifican con el prefijo int, donde el dígito inicial en int determina su longitud en bytes.
(2) Transferencia
La primera inserción de datos en un mensaje de protocolo se decodifica en una secuencia de números enteros.
Estos números enteros se interpretan como una secuencia de tuplas (ID, SALIDA, CANTIDAD). Si el número de números enteros decodificados no es múltiplo de 3, el mensaje de protocolo no es válido.
ID es el ID numérico de la ejecución que se asignará
SALIDA es el índice de la salida a asignar
IMPORTE es la cantidad de ejecuciones que se asignarán
La identificación está codificada como delta. Esto permite asignar la misma runa varias veces para evitar duplicar la ID de la runa completa. Por ejemplo, tupla: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Realice las siguientes asignaciones:
ID 100, salida 1, 20 runas
ID 100, salida 2, 10 runas
id 120, salida 1, 5 runas
AMOUNT 0 es la abreviatura de "todas las runas restantes".
Después de que se hayan procesado todas las asignaciones de tuplas, las runas no asignadas se asignan a la primera salida que no sea OP_RETURN (si corresponde). Se ignorarán las tareas adicionales.
Las runas se pueden quemar asignándolas a la salida OP_RETURN que contiene el mensaje de protocolo.
(3)Problema
Si el mensaje de protocolo tiene un segundo envío de datos, es una transacción de emisión. El segundo envío de datos se decodifica en dos números enteros, SÍMBOLO y DECIMALES. Si quedan números enteros adicionales, el mensaje de protocolo no es válido.
Una transacción de emisión puede crear cualquier número de runas de emisión utilizando el ID 0 en la tupla de asignación, hasta un máximo de 2^128 - 1.
SYMBOL es un símbolo de codificación base de 26 bits legible por humanos, similar al símbolo utilizado en los nombres ordinales de satélite. Los únicos caracteres válidos son de la A a la Z.
DECIMALES es el número de dígitos después del punto decimal que se debe utilizar al mostrar las runas emitidas.
Si el SÍMBOLO no ha sido asignado, se asigna a una runa publicada y la runa publicada recibe la siguiente ID de runa numérica disponible (comenzando desde 1).
Si ya se ha asignado SÍMBOLO, o es BITCOIN, BTC o XBT, no se creará ninguna runa nueva. Se ignorarán las asignaciones de transacciones de liberación que utilicen un ID de runa de 0, pero se seguirán procesando otras asignaciones.
(4) NOTA
Al mostrar saldos de UTXO, el saldo de Bitcoin nativo de UTXO se puede mostrar con el ID de runa 0 y los símbolos BITCOIN, BTC o XBT.
Para mantener el protocolo simple, (Runes) no adopta un mecanismo para evitar la sentadilla de símbolos. De hecho, una forma eficaz y sencilla de evitar la vinculación de símbolos es permitir solo la asignación de símbolos por encima de una determinada longitud, que disminuye con el tiempo y finalmente llega a cero y permite todos los símbolos. Esto evitaría la asignación de símbolos ideales cortos al principio del protocolo y alentaría a los recién llegados a competir por símbolos ideales, si dicha competencia tiene sentido.
Escrito al final
¿Esta solución realmente funciona para el mercado? No tengo ni idea.
Es lo más simple posible, no depende de datos fuera de la cadena, no tiene tokens nativos y encaja perfectamente en el modelo UTXO nativo de Bitcoin. Un esquema de este tipo podría atraer a usuarios de otros esquemas con una peor huella en la cadena y atraer la atención de los desarrolladores y usuarios hacia Bitcoin, animándolos a adoptar el propio Bitcoin.
El mundo del Financial Times, por otro lado, es un abismo completamente irredimible de engaño y codicia, por lo que podría desaparecer.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
¿Reemplazar BRC-20 para activar el ecosistema BTC? El fundador de Ordinals trae un nuevo protocolo Runes
Original | Casey Rodarmor
Compilado | Odaily Planet Daily
Ayer, el creador de Ordinals, Casey Rodarmor, publicó un blog en el que presenta un nuevo protocolo de token fungible (FT), Runes.
En cuanto a si Bitcoin necesita FT, Casey Rodarmor afirmó en su tweet que FT tiene dos caras. Por un lado, el 99,99% de los FT son "mierda" y estafas que debilitan la pureza de Bitcoin; por otro lado, aportan muchos ingresos por comisiones, desarrolladores y usuarios al ecosistema de Bitcoin. "A la gente le encantan los tokens y son como los casinos cyberpunk, por lo que es probable que los ingresos por tarifas sean sustanciales y continuos hasta que se alivien por completo las preocupaciones sobre los presupuestos de seguridad (cibernética). "
Añadió que ya han surgido protocolos FT como BRC-20, RGB y Taproot. En comparación con los protocolos simples en cadena, protocolos como RGB y Taproot son complejos y pueden plantear desafíos a la experiencia del usuario. BRC-20 es muy simple y puede proporcionar una buena experiencia de usuario en comparación con RGB/Taproot, que requiere una infraestructura de almacenamiento y recuperación de datos fuera de la cadena; pero el problema con los tokens BRC 20 es que generan "UTXO basura" y ocupan bits de espacio.
Rodarmor dijo que Runes es un protocolo basado en UTXO que se adapta a Bitcoin de forma más natural y promueve la minimización de las colecciones de UTXO al evitar la creación de "UTXO basura".
El siguiente contenido proviene de la publicación del blog de Casey Rodarmor y fue compilado por Odaily Planet Daily
No estoy seguro de si crear un nuevo protocolo de token fungible (FT) para Bitcoin sea una buena idea. El 99,9% del FT son estafas y memes. Sin embargo, no parece que vayan a desaparecer pronto, al igual que los casinos no parecen desaparecer pronto.
La creación de un buen protocolo FT para Bitcoin puede generar considerables ingresos por tarifas de transacción, atención de los desarrolladores y usuarios de Bitcoin. Además, si el protocolo tiene una huella más pequeña en la cadena e incentiva la gestión responsable de UTXO, puede reducir el daño en comparación con los protocolos existentes. Por ejemplo, el actualmente popular BRC-20 ha llevado a la generación de una gran cantidad de UTXO basura.
Si comparamos los protocolos FT existentes, encontraremos que tienen varias diferencias importantes:
Según las dimensiones anteriores, los resultados de la comparación de los protocolos FT existentes en el ecosistema Bitcoin son los siguientes:
Para Bitcoin, ¿cómo sería un protocolo FT simple basado en UTXO con una buena experiencia de usuario? A continuación, me gustaría presentarles una solución genial llamada "Runas".
(1. Información general
Los saldos de runas se mantienen en UTXO; UTXO puede contener cualquier cantidad de runas.
Una transacción contiene un mensaje de protocolo si contiene una salida cuya clave pública de script contiene OP_RETURN seguida de una inserción de datos con una R mayúscula ASCII. El mensaje de protocolo son todos los datos enviados después del primero.
Las runas ingresadas en transacciones con mensajes de protocolo no válidos se destruirán, lo que permitirá que futuras actualizaciones cambien la forma en que se asignan o crean las runas, evitando que los clientes más antiguos asignen saldos de runas incorrectamente.
Los números enteros se codifican con el prefijo int, donde el dígito inicial en int determina su longitud en bytes.
(2) Transferencia
La primera inserción de datos en un mensaje de protocolo se decodifica en una secuencia de números enteros.
Estos números enteros se interpretan como una secuencia de tuplas (ID, SALIDA, CANTIDAD). Si el número de números enteros decodificados no es múltiplo de 3, el mensaje de protocolo no es válido.
La identificación está codificada como delta. Esto permite asignar la misma runa varias veces para evitar duplicar la ID de la runa completa. Por ejemplo, tupla: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Realice las siguientes asignaciones:
AMOUNT 0 es la abreviatura de "todas las runas restantes".
Después de que se hayan procesado todas las asignaciones de tuplas, las runas no asignadas se asignan a la primera salida que no sea OP_RETURN (si corresponde). Se ignorarán las tareas adicionales.
Las runas se pueden quemar asignándolas a la salida OP_RETURN que contiene el mensaje de protocolo.
(3)Problema
Si el mensaje de protocolo tiene un segundo envío de datos, es una transacción de emisión. El segundo envío de datos se decodifica en dos números enteros, SÍMBOLO y DECIMALES. Si quedan números enteros adicionales, el mensaje de protocolo no es válido.
Una transacción de emisión puede crear cualquier número de runas de emisión utilizando el ID 0 en la tupla de asignación, hasta un máximo de 2^128 - 1.
SYMBOL es un símbolo de codificación base de 26 bits legible por humanos, similar al símbolo utilizado en los nombres ordinales de satélite. Los únicos caracteres válidos son de la A a la Z.
DECIMALES es el número de dígitos después del punto decimal que se debe utilizar al mostrar las runas emitidas.
Si el SÍMBOLO no ha sido asignado, se asigna a una runa publicada y la runa publicada recibe la siguiente ID de runa numérica disponible (comenzando desde 1).
Si ya se ha asignado SÍMBOLO, o es BITCOIN, BTC o XBT, no se creará ninguna runa nueva. Se ignorarán las asignaciones de transacciones de liberación que utilicen un ID de runa de 0, pero se seguirán procesando otras asignaciones.
(4) NOTA
Al mostrar saldos de UTXO, el saldo de Bitcoin nativo de UTXO se puede mostrar con el ID de runa 0 y los símbolos BITCOIN, BTC o XBT.
Para mantener el protocolo simple, (Runes) no adopta un mecanismo para evitar la sentadilla de símbolos. De hecho, una forma eficaz y sencilla de evitar la vinculación de símbolos es permitir solo la asignación de símbolos por encima de una determinada longitud, que disminuye con el tiempo y finalmente llega a cero y permite todos los símbolos. Esto evitaría la asignación de símbolos ideales cortos al principio del protocolo y alentaría a los recién llegados a competir por símbolos ideales, si dicha competencia tiene sentido.
Escrito al final
¿Esta solución realmente funciona para el mercado? No tengo ni idea.
Es lo más simple posible, no depende de datos fuera de la cadena, no tiene tokens nativos y encaja perfectamente en el modelo UTXO nativo de Bitcoin. Un esquema de este tipo podría atraer a usuarios de otros esquemas con una peor huella en la cadena y atraer la atención de los desarrolladores y usuarios hacia Bitcoin, animándolos a adoptar el propio Bitcoin.
El mundo del Financial Times, por otro lado, es un abismo completamente irredimible de engaño y codicia, por lo que podría desaparecer.