Ordinals fue lanzado por el desarrollador Casey Rodarmor el 20 de enero de 2023 en la red principal de Bitcoin como un protocolo de pedidos para "Satoshis". Los “Satoshis” son la unidad más pequeña de Bitcoin, y cada Bitcoin se compone de un Compuesto por 100 millones de Satoshis (1 btc = 10^8 sat), el protocolo Ordinals le da a cada Satoshi una identidad única.
Las inscripciones de Ordinals son tokens no fungibles (NFT) creados sobre el protocolo Ordinals y contienen datos como imágenes, texto y videos.
En comparación con Ethereum NFT, podemos simplemente pensar que el protocolo Ordinals implementa tokenID y la inscripción implementa metadatos.
TokenID proporciona un identificador único para cada NFT, lo que permite a los usuarios distinguir los tokens entre sí. TokenID es lo que hace que las NFT sean verdaderamente únicas.
Ethereum tiene una buena programabilidad, lo que facilita la implementación de TokenID. Sin embargo, en Bitcoin, implementaciones similares suelen requerir el uso de redes de segunda capa. Plataformas como Counterparty y Stacks ya han implementado NFT basadas en Bitcoin, pero la inscripción Ordinals tiene diferencias fundamentales con respecto a otras arquitecturas de NFT de Bitcoin.
El protocolo Ordinals utiliza el modelo de transacción UTXO de Bitcoin. UTXO es similar a un sistema de efectivo, a diferencia del modelo tradicional basado en el saldo de la cuenta.
En la cadena de bloques de Bitcoin, todos los saldos se almacenan en una lista llamada Salidas de transacciones no gastadas (UTXO). Cada UTXO contiene una cierta cantidad de Bitcoin, junto con información sobre su propietario y si se puede gastar. Puede considerarlo como un cheque en efectivo con el nombre del propietario, que puede transferirse a otra persona con la firma del propietario. Para una dirección específica, la suma de todos sus montos UTXO representa el saldo de la billetera de esa dirección. Al iterar a través de todos los UTXO, podemos obtener el saldo actual para cada dirección. Sumar todas las cantidades de UTXO nos da la circulación total de Bitcoin.
Para comprender mejor el modelo de pago en la red Bitcoin, veamos un ejemplo en el que A envía n Bitcoin a B. El siguiente diagrama ilustra el proceso en el que A envía 3 Bitcoin a B.
Para el usuario A, primero debe determinar el conjunto de todos los UTXO que posee, es decir, todos los Bitcoins que el usuario A puede controlar;
A selecciona uno o más UTXO de este conjunto como entrada de la transacción. La suma de las cantidades de estos insumos es m (2+0,8+0,5=3,3 BTC), que es mayor que el monto a pagar n (3 BTC);
El usuario A establece dos salidas para la transacción, una salida se paga a la dirección de B, la cantidad es n (3 BTC) y la otra salida se paga a la propia dirección de cambio de A, la cantidad es mn-fee (3.3-3-0.001 =0,299 BTC). La billetera de un usuario generalmente consta de varias direcciones. Generalmente, cada dirección solo se usa una vez y el cambio se devuelve a una nueva dirección de forma predeterminada;
Después de que el minero empaqueta la transacción y la carga en la cadena para su confirmación, B puede recibir la información de la transacción. Debido a que el tamaño del bloque tiene un límite superior (aproximadamente 1 MB), los mineros darán prioridad a las transacciones con tasas de transacción altas (fee_rate=tarifa/tamaño) para obtener la tarifa más alta a cambio.
Según el protocolo Ordinals, el número de “Satoshi” se basa en el orden en que se extraen, y dado que cada BTC “Satoshi” se genera a través de recompensas mineras, su número de serie se puede determinar mediante la trazabilidad.
Supongamos que el usuario A obtiene el Satoshi número 100-110 mediante la minería (10 Satoshis se almacenan en su conjunto en el mismo UTXO con el ID adc123). Cuando el usuario A quiere pagar 5 satoshis al usuario B, elige usar el ID abc123 como entrada de la transacción, de los cuales 5 satoshis se entregan al usuario B y 5 satoshis se devuelven al usuario A como cambio. Estas dos copias de 5 “Satoshi” son un todo y están almacenadas en dos UTXO con ID abc456 y abc789 respectivamente. La identificación de UTXO anterior y el número de "Satoshi" solo se muestran como ejemplos. En situaciones reales, el número mínimo de “Satoshi” enviados está limitado a 546 y la identificación UTXO no se expresa de esta forma.
En la transacción anterior, la ruta de circulación de los 10 Satoshis del Usuario A es:
La minería produce 10 “Satoshi”, numerados [100, 110). Indica que los “Satoshi” del 100 al 109 están almacenados en el UTXO con el ID abc123 y su propietario es el usuario A.
Cuando A transfiere dinero, 10 “satoshis” se dividen en dos partes, cada una con 5 “satoshis”. Usado aquí “Primero en llegar, primero en ser atendido” El principio es que el orden numérico de “Satoshi” se determina de acuerdo con su índice en el resultado de la transacción. Suponiendo que el orden de salida es primero el usuario A, luego el usuario B, luego los números de serie de los 5 “satoshis” restantes del usuario A son [100, 105), que se almacenan en el UTXO con el id abc456, y los 5 “del usuario B satoshis” El número de secuencia es [105, 110) y se almacena en el UTXO con id abc789.
Los metadatos de las inscripciones ordinales no se almacenan en una ubicación específica. En cambio, estos metadatos están incrustados en los datos de los testigos de la transacción (datos de los testigos, campo de testigos), por lo que se les llama "inscripción", porque estos datos están "grabados" como una inscripción en partes específicas de la transacción de Bitcoin. , y estos datos están adjuntos a "Satoshi" específicos. Este proceso de inscripción se implementa a través de Segregated Witness (SegWit) y Taproot, que incluye dos etapas: confirmar y revelar, y puede inscribir cualquier forma de contenido (como texto, imagen o video) en el "satoshi" designado.
SegWit es una actualización de 2017 que resultó en una bifurcación suave de la cadena de bloques Bitcoin. La actualización separa efectivamente las transacciones de Bitcoin en dos partes al agregar una sección de "datos de testigos" que puede admitir datos arbitrarios.
Testigo segregado separa los datos de transacciones y testigos (firmas) en partes separadas y permite almacenar datos arbitrarios en la parte testigo.
Técnicamente, la implementación de Segregated Witness significa que las transacciones ya no necesitan incluir datos de testigos (y no ocuparán el 1 MB de espacio que Bitcoin asignó originalmente para los bloques). En cambio, al final de un bloque, se crea un espacio separado adicional para los datos de los testigos. Admite transferencias de datos arbitrarias y tiene un "peso de bloque" con descuento que inteligentemente mantiene grandes cantidades de datos dentro de los límites de tamaño de bloque de Bitcoin para evitar la necesidad de una bifurcación dura.
Implementada en noviembre de 2021, Taproot es una actualización multifacética diseñada para mejorar la privacidad, escalabilidad y seguridad de Bitcoin. Taproot crea un sistema que facilita el almacenamiento de datos de testigos arbitrarios y relaja los límites sobre la cantidad de datos arbitrarios que se pueden colocar en una transacción de Bitcoin. El objetivo inicial de esta actualización es mejorar aún más los contratos inteligentes basados en Bitcoin, como los contratos de tiempo limitado, que normalmente se expresan en datos de testigos.
Los ordinales almacenan metadatos en un script de gasto en la ruta del script Taproot.
En primer lugar, debido a la forma en que se almacenan los scripts Taproot, podemos almacenar el contenido de la inscripción en los scripts de gastos de ruta del script Taproot, que casi no tienen restricciones en el contenido, al mismo tiempo que recibimos descuentos en los datos de los testigos, lo que hace que almacenar el contenido de la inscripción sea relativamente económico. Dado que el consumo de scripts de Taproot solo se puede realizar desde la salida de Taproot ya existente, las inscripciones se acuñan mediante un proceso de confirmación/revelación de dos etapas. Primero, en la transacción de confirmación, se crea una salida Taproot que promete un script que contiene el contenido de la inscripción. Luego, en la transacción de revelación, se inicia una transacción tomando como entrada el UTXO correspondiente a esa inscripción. En ese momento, el contenido de la inscripción correspondiente se hizo público en todo Internet.
Este enfoque reduce en gran medida el consumo de recursos. Si no utiliza el script Taproot, la información del testigo se almacena en el resultado de la transacción. De esta forma, mientras no se consuma esta salida, la información del testigo siempre se almacenará en el conjunto UTXO. Por el contrario, si se utiliza P2TR, la información del testigo no aparecerá en la transacción generada durante la fase de confirmación, por lo que no se escribirá en el conjunto UTXO. Solo cuando se consuma este UTXO aparecerá la información del testigo en la entrada de la transacción durante la fase de revelación. P2TR permite escribir metadatos en la cadena de bloques de Bitcoin, pero nunca aparece en el conjunto UTXO. Dado que mantener/modificar el conjunto UTXO requiere más recursos, este enfoque puede ahorrar muchos recursos.
Aunque el nombre de BRC-20 es muy similar al ERC-20 de Ethereum, las diferencias técnicas entre los dos son realmente significativas. El estado de tenencia de los tokens ERC-20 se guarda en la cadena y se puede obtener el consenso de la red en la cadena, mientras que BRC-20 es solo una inscripción especial del protocolo Ordinals, creada por el usuario de Twitter @domodata el 8 de marzo de 2023, que utiliza ordinal. inscripciones de datos JSON para implementar contratos de tokens, acuñar y transferir tokens. El json implementado es el siguiente:
{
"p": "brc-20",//Protocol: Helps offline accounting systems identify and handle brc-20 events
"op": "deploy",//op operation: event type (Deploy, Mint, Transfer)
"tick": "ordi", //Ticker: identifier of the brc-20 token, 4 letters in length (can be emoji)
"max": "21000000",//Max supply: The maximum supply of brc-20 tokens
"lim": "1000"//Mint limit: The limit on the minting amount of brc-20 tokens each time
}
Las operaciones correspondientes son mint y transfer, y los dos formatos son casi iguales. Cuando op es Transferencia, el destinatario de la transferencia de la inscripción es el destinatario del “Satoshi” correspondiente a la inscripción. Por lo tanto, la transferencia de BRC-20 debe ir acompañada de la transferencia de la propiedad de Bitcoin y no simplemente consumirse como una tarifa de gestión.
BRC-20 implementa un mecanismo de “primero en llegar, primero en ser atendido”. Los despliegues repetidos y el exceso de menta no son válidos. La organización centralizada deducirá el saldo actual que debería tener el usuario en función de cada OP registrado en la cadena, y emitirá un juicio sobre la validez de la transacción.
En este proceso, las inscripciones se 'adjuntan' al "Satoshi" transaccional. Los mineros de Bitcoin no procesarán estas inscripciones. Desde la perspectiva de la cadena, todavía no se diferencian de otros “Satoshis”. Todos ellos son considerados "Satoshis" comunes y corrientes. Se transfiere “Cong”.
Para el protocolo BRC-20, trata la inscripción como un libro de contabilidad que registra el despliegue, acuñación y transferencia de tokens BRC-20. Dado que los contratos inteligentes no se pueden ejecutar en Bitcoin, los tokens BRC-20 no pueden consultar información relevante sobre el token actual mediante la ejecución de contratos inteligentes. Por lo tanto, BRC-20 utiliza consultas fuera de la cadena, es decir, utiliza un servidor centralizado para recuperar bloques de Bitcoin, registrar las operaciones de implementación, acuñación y transferencia de todos los tokens BRC-20 para consultar el saldo final de los tokens BRC-20 de cada usuario.
En pocas palabras, el libro mayor BRC-20 está descentralizado y registrado en la cadena Bitcoin, pero el proceso de liquidación está centralizado. Actualmente existen dos sitios web, brc-20.io y unisat.io, que admiten consultas relacionadas con tokens BRC-20.
La centralización del proceso de liquidación puede hacer que diferentes plataformas tengan resultados diferentes al consultar un determinado saldo de cuenta. Aunque todas las operaciones se registran en la cadena, es responsabilidad del cliente verificar estas operaciones. Si estos proveedores de servicios centralizados no divulgan sus reglas de verificación, en realidad no hay garantía para todo el ecosistema BRC-20.
De hecho, en la tarde del 23 de abril, UniSat lanzó la plataforma comercial BRC-20, pero debido a vulnerabilidades en la biblioteca de códigos, sufrió una gran cantidad de ataques de doble gasto. La dirección bc1pwturekq4w455l64ttze8j7mnhgsuaupsn99ggd0ds23js924e6ms9fxyht inicialmente acuñó los Ordinals NFT transferidos e intentó transferir 5,000 ORDI y 35,000 ORDI a su propia dirección de la nada, y trató de vender los ordi acuñados de la nada a otros usuarios. Posteriormente, Unisat suspendió el acceso al sitio web y llevó a cabo una investigación, descubriendo finalmente que 70 transacciones estaban afectadas.
Si Unisat no hubiera recuperado el error esa noche, se estimó que el daño causado por el ataque de doble gasto superaría el millón de dólares. Cómo garantizar que la recuperación y verificación del servidor centralizado esté libre de errores es el problema más importante que debe resolverse durante el desarrollo de BRC-20.
La esencia de la inscripción Ordinal es: en la red Bitcoin con la ayuda de aTaproot El script construye una capa de contabilidad simple para contar y registrar activos y datos.
Dado que solo implica contabilidad, esto significa que no habrá procesos de ejecución y verificación de scripts similares a los contratos inteligentes, y debe depender en gran medida de la gestión centralizada fuera de la cadena y de los resultados de informes.
Por lo tanto, a excepción de BRC-20, todas las inscripciones de Ordinales deben basarse en servicios fuera de línea fuera de la red Bitcoin para el mantenimiento del estado, siempre que impliquen transferencias de estado (como transacciones). Si el servicio estatal subyacente no está disponible o es defectuoso, esto puede provocar pérdidas de activos, porque la red Bitcoin no puede evitar que se carguen inscripciones no válidas en la cadena. La plataforma centralizada deberá decidir de quién es la inscripción válida, y ésta será válida en la plataforma.
Este método centralizado de negociación y fijación de precios brinda a la plataforma centralizada una oportunidad importante para comportamientos maliciosos. Además, la combinación de la paradoja lógica de la inscripción "por orden de llegada" y el mecanismo por el cual los mineros priorizan el embalaje en función de las tarifas de minería permite a los mineros y a los robots de vanguardia acuñar una gran cantidad de inscripciones populares antes que otros, lo que resulta en una proceso de acuñación injusto.
Sin embargo, predecir y evaluar el desarrollo de cosas nuevas es un desafío. La introducción de la inscripción Ordinal sin duda ha provocado un debate dentro de la comunidad Bitcoin sobre el papel fundamental y la esencia de Bitcoin. Esta discusión podría conducir potencialmente a una bifurcación en Bitcoin, centrándose en la seguridad y la programabilidad. Parece que se está abriendo la caja de Pandora.
Ordinals fue lanzado por el desarrollador Casey Rodarmor el 20 de enero de 2023 en la red principal de Bitcoin como un protocolo de pedidos para "Satoshis". Los “Satoshis” son la unidad más pequeña de Bitcoin, y cada Bitcoin se compone de un Compuesto por 100 millones de Satoshis (1 btc = 10^8 sat), el protocolo Ordinals le da a cada Satoshi una identidad única.
Las inscripciones de Ordinals son tokens no fungibles (NFT) creados sobre el protocolo Ordinals y contienen datos como imágenes, texto y videos.
En comparación con Ethereum NFT, podemos simplemente pensar que el protocolo Ordinals implementa tokenID y la inscripción implementa metadatos.
TokenID proporciona un identificador único para cada NFT, lo que permite a los usuarios distinguir los tokens entre sí. TokenID es lo que hace que las NFT sean verdaderamente únicas.
Ethereum tiene una buena programabilidad, lo que facilita la implementación de TokenID. Sin embargo, en Bitcoin, implementaciones similares suelen requerir el uso de redes de segunda capa. Plataformas como Counterparty y Stacks ya han implementado NFT basadas en Bitcoin, pero la inscripción Ordinals tiene diferencias fundamentales con respecto a otras arquitecturas de NFT de Bitcoin.
El protocolo Ordinals utiliza el modelo de transacción UTXO de Bitcoin. UTXO es similar a un sistema de efectivo, a diferencia del modelo tradicional basado en el saldo de la cuenta.
En la cadena de bloques de Bitcoin, todos los saldos se almacenan en una lista llamada Salidas de transacciones no gastadas (UTXO). Cada UTXO contiene una cierta cantidad de Bitcoin, junto con información sobre su propietario y si se puede gastar. Puede considerarlo como un cheque en efectivo con el nombre del propietario, que puede transferirse a otra persona con la firma del propietario. Para una dirección específica, la suma de todos sus montos UTXO representa el saldo de la billetera de esa dirección. Al iterar a través de todos los UTXO, podemos obtener el saldo actual para cada dirección. Sumar todas las cantidades de UTXO nos da la circulación total de Bitcoin.
Para comprender mejor el modelo de pago en la red Bitcoin, veamos un ejemplo en el que A envía n Bitcoin a B. El siguiente diagrama ilustra el proceso en el que A envía 3 Bitcoin a B.
Para el usuario A, primero debe determinar el conjunto de todos los UTXO que posee, es decir, todos los Bitcoins que el usuario A puede controlar;
A selecciona uno o más UTXO de este conjunto como entrada de la transacción. La suma de las cantidades de estos insumos es m (2+0,8+0,5=3,3 BTC), que es mayor que el monto a pagar n (3 BTC);
El usuario A establece dos salidas para la transacción, una salida se paga a la dirección de B, la cantidad es n (3 BTC) y la otra salida se paga a la propia dirección de cambio de A, la cantidad es mn-fee (3.3-3-0.001 =0,299 BTC). La billetera de un usuario generalmente consta de varias direcciones. Generalmente, cada dirección solo se usa una vez y el cambio se devuelve a una nueva dirección de forma predeterminada;
Después de que el minero empaqueta la transacción y la carga en la cadena para su confirmación, B puede recibir la información de la transacción. Debido a que el tamaño del bloque tiene un límite superior (aproximadamente 1 MB), los mineros darán prioridad a las transacciones con tasas de transacción altas (fee_rate=tarifa/tamaño) para obtener la tarifa más alta a cambio.
Según el protocolo Ordinals, el número de “Satoshi” se basa en el orden en que se extraen, y dado que cada BTC “Satoshi” se genera a través de recompensas mineras, su número de serie se puede determinar mediante la trazabilidad.
Supongamos que el usuario A obtiene el Satoshi número 100-110 mediante la minería (10 Satoshis se almacenan en su conjunto en el mismo UTXO con el ID adc123). Cuando el usuario A quiere pagar 5 satoshis al usuario B, elige usar el ID abc123 como entrada de la transacción, de los cuales 5 satoshis se entregan al usuario B y 5 satoshis se devuelven al usuario A como cambio. Estas dos copias de 5 “Satoshi” son un todo y están almacenadas en dos UTXO con ID abc456 y abc789 respectivamente. La identificación de UTXO anterior y el número de "Satoshi" solo se muestran como ejemplos. En situaciones reales, el número mínimo de “Satoshi” enviados está limitado a 546 y la identificación UTXO no se expresa de esta forma.
En la transacción anterior, la ruta de circulación de los 10 Satoshis del Usuario A es:
La minería produce 10 “Satoshi”, numerados [100, 110). Indica que los “Satoshi” del 100 al 109 están almacenados en el UTXO con el ID abc123 y su propietario es el usuario A.
Cuando A transfiere dinero, 10 “satoshis” se dividen en dos partes, cada una con 5 “satoshis”. Usado aquí “Primero en llegar, primero en ser atendido” El principio es que el orden numérico de “Satoshi” se determina de acuerdo con su índice en el resultado de la transacción. Suponiendo que el orden de salida es primero el usuario A, luego el usuario B, luego los números de serie de los 5 “satoshis” restantes del usuario A son [100, 105), que se almacenan en el UTXO con el id abc456, y los 5 “del usuario B satoshis” El número de secuencia es [105, 110) y se almacena en el UTXO con id abc789.
Los metadatos de las inscripciones ordinales no se almacenan en una ubicación específica. En cambio, estos metadatos están incrustados en los datos de los testigos de la transacción (datos de los testigos, campo de testigos), por lo que se les llama "inscripción", porque estos datos están "grabados" como una inscripción en partes específicas de la transacción de Bitcoin. , y estos datos están adjuntos a "Satoshi" específicos. Este proceso de inscripción se implementa a través de Segregated Witness (SegWit) y Taproot, que incluye dos etapas: confirmar y revelar, y puede inscribir cualquier forma de contenido (como texto, imagen o video) en el "satoshi" designado.
SegWit es una actualización de 2017 que resultó en una bifurcación suave de la cadena de bloques Bitcoin. La actualización separa efectivamente las transacciones de Bitcoin en dos partes al agregar una sección de "datos de testigos" que puede admitir datos arbitrarios.
Testigo segregado separa los datos de transacciones y testigos (firmas) en partes separadas y permite almacenar datos arbitrarios en la parte testigo.
Técnicamente, la implementación de Segregated Witness significa que las transacciones ya no necesitan incluir datos de testigos (y no ocuparán el 1 MB de espacio que Bitcoin asignó originalmente para los bloques). En cambio, al final de un bloque, se crea un espacio separado adicional para los datos de los testigos. Admite transferencias de datos arbitrarias y tiene un "peso de bloque" con descuento que inteligentemente mantiene grandes cantidades de datos dentro de los límites de tamaño de bloque de Bitcoin para evitar la necesidad de una bifurcación dura.
Implementada en noviembre de 2021, Taproot es una actualización multifacética diseñada para mejorar la privacidad, escalabilidad y seguridad de Bitcoin. Taproot crea un sistema que facilita el almacenamiento de datos de testigos arbitrarios y relaja los límites sobre la cantidad de datos arbitrarios que se pueden colocar en una transacción de Bitcoin. El objetivo inicial de esta actualización es mejorar aún más los contratos inteligentes basados en Bitcoin, como los contratos de tiempo limitado, que normalmente se expresan en datos de testigos.
Los ordinales almacenan metadatos en un script de gasto en la ruta del script Taproot.
En primer lugar, debido a la forma en que se almacenan los scripts Taproot, podemos almacenar el contenido de la inscripción en los scripts de gastos de ruta del script Taproot, que casi no tienen restricciones en el contenido, al mismo tiempo que recibimos descuentos en los datos de los testigos, lo que hace que almacenar el contenido de la inscripción sea relativamente económico. Dado que el consumo de scripts de Taproot solo se puede realizar desde la salida de Taproot ya existente, las inscripciones se acuñan mediante un proceso de confirmación/revelación de dos etapas. Primero, en la transacción de confirmación, se crea una salida Taproot que promete un script que contiene el contenido de la inscripción. Luego, en la transacción de revelación, se inicia una transacción tomando como entrada el UTXO correspondiente a esa inscripción. En ese momento, el contenido de la inscripción correspondiente se hizo público en todo Internet.
Este enfoque reduce en gran medida el consumo de recursos. Si no utiliza el script Taproot, la información del testigo se almacena en el resultado de la transacción. De esta forma, mientras no se consuma esta salida, la información del testigo siempre se almacenará en el conjunto UTXO. Por el contrario, si se utiliza P2TR, la información del testigo no aparecerá en la transacción generada durante la fase de confirmación, por lo que no se escribirá en el conjunto UTXO. Solo cuando se consuma este UTXO aparecerá la información del testigo en la entrada de la transacción durante la fase de revelación. P2TR permite escribir metadatos en la cadena de bloques de Bitcoin, pero nunca aparece en el conjunto UTXO. Dado que mantener/modificar el conjunto UTXO requiere más recursos, este enfoque puede ahorrar muchos recursos.
Aunque el nombre de BRC-20 es muy similar al ERC-20 de Ethereum, las diferencias técnicas entre los dos son realmente significativas. El estado de tenencia de los tokens ERC-20 se guarda en la cadena y se puede obtener el consenso de la red en la cadena, mientras que BRC-20 es solo una inscripción especial del protocolo Ordinals, creada por el usuario de Twitter @domodata el 8 de marzo de 2023, que utiliza ordinal. inscripciones de datos JSON para implementar contratos de tokens, acuñar y transferir tokens. El json implementado es el siguiente:
{
"p": "brc-20",//Protocol: Helps offline accounting systems identify and handle brc-20 events
"op": "deploy",//op operation: event type (Deploy, Mint, Transfer)
"tick": "ordi", //Ticker: identifier of the brc-20 token, 4 letters in length (can be emoji)
"max": "21000000",//Max supply: The maximum supply of brc-20 tokens
"lim": "1000"//Mint limit: The limit on the minting amount of brc-20 tokens each time
}
Las operaciones correspondientes son mint y transfer, y los dos formatos son casi iguales. Cuando op es Transferencia, el destinatario de la transferencia de la inscripción es el destinatario del “Satoshi” correspondiente a la inscripción. Por lo tanto, la transferencia de BRC-20 debe ir acompañada de la transferencia de la propiedad de Bitcoin y no simplemente consumirse como una tarifa de gestión.
BRC-20 implementa un mecanismo de “primero en llegar, primero en ser atendido”. Los despliegues repetidos y el exceso de menta no son válidos. La organización centralizada deducirá el saldo actual que debería tener el usuario en función de cada OP registrado en la cadena, y emitirá un juicio sobre la validez de la transacción.
En este proceso, las inscripciones se 'adjuntan' al "Satoshi" transaccional. Los mineros de Bitcoin no procesarán estas inscripciones. Desde la perspectiva de la cadena, todavía no se diferencian de otros “Satoshis”. Todos ellos son considerados "Satoshis" comunes y corrientes. Se transfiere “Cong”.
Para el protocolo BRC-20, trata la inscripción como un libro de contabilidad que registra el despliegue, acuñación y transferencia de tokens BRC-20. Dado que los contratos inteligentes no se pueden ejecutar en Bitcoin, los tokens BRC-20 no pueden consultar información relevante sobre el token actual mediante la ejecución de contratos inteligentes. Por lo tanto, BRC-20 utiliza consultas fuera de la cadena, es decir, utiliza un servidor centralizado para recuperar bloques de Bitcoin, registrar las operaciones de implementación, acuñación y transferencia de todos los tokens BRC-20 para consultar el saldo final de los tokens BRC-20 de cada usuario.
En pocas palabras, el libro mayor BRC-20 está descentralizado y registrado en la cadena Bitcoin, pero el proceso de liquidación está centralizado. Actualmente existen dos sitios web, brc-20.io y unisat.io, que admiten consultas relacionadas con tokens BRC-20.
La centralización del proceso de liquidación puede hacer que diferentes plataformas tengan resultados diferentes al consultar un determinado saldo de cuenta. Aunque todas las operaciones se registran en la cadena, es responsabilidad del cliente verificar estas operaciones. Si estos proveedores de servicios centralizados no divulgan sus reglas de verificación, en realidad no hay garantía para todo el ecosistema BRC-20.
De hecho, en la tarde del 23 de abril, UniSat lanzó la plataforma comercial BRC-20, pero debido a vulnerabilidades en la biblioteca de códigos, sufrió una gran cantidad de ataques de doble gasto. La dirección bc1pwturekq4w455l64ttze8j7mnhgsuaupsn99ggd0ds23js924e6ms9fxyht inicialmente acuñó los Ordinals NFT transferidos e intentó transferir 5,000 ORDI y 35,000 ORDI a su propia dirección de la nada, y trató de vender los ordi acuñados de la nada a otros usuarios. Posteriormente, Unisat suspendió el acceso al sitio web y llevó a cabo una investigación, descubriendo finalmente que 70 transacciones estaban afectadas.
Si Unisat no hubiera recuperado el error esa noche, se estimó que el daño causado por el ataque de doble gasto superaría el millón de dólares. Cómo garantizar que la recuperación y verificación del servidor centralizado esté libre de errores es el problema más importante que debe resolverse durante el desarrollo de BRC-20.
La esencia de la inscripción Ordinal es: en la red Bitcoin con la ayuda de aTaproot El script construye una capa de contabilidad simple para contar y registrar activos y datos.
Dado que solo implica contabilidad, esto significa que no habrá procesos de ejecución y verificación de scripts similares a los contratos inteligentes, y debe depender en gran medida de la gestión centralizada fuera de la cadena y de los resultados de informes.
Por lo tanto, a excepción de BRC-20, todas las inscripciones de Ordinales deben basarse en servicios fuera de línea fuera de la red Bitcoin para el mantenimiento del estado, siempre que impliquen transferencias de estado (como transacciones). Si el servicio estatal subyacente no está disponible o es defectuoso, esto puede provocar pérdidas de activos, porque la red Bitcoin no puede evitar que se carguen inscripciones no válidas en la cadena. La plataforma centralizada deberá decidir de quién es la inscripción válida, y ésta será válida en la plataforma.
Este método centralizado de negociación y fijación de precios brinda a la plataforma centralizada una oportunidad importante para comportamientos maliciosos. Además, la combinación de la paradoja lógica de la inscripción "por orden de llegada" y el mecanismo por el cual los mineros priorizan el embalaje en función de las tarifas de minería permite a los mineros y a los robots de vanguardia acuñar una gran cantidad de inscripciones populares antes que otros, lo que resulta en una proceso de acuñación injusto.
Sin embargo, predecir y evaluar el desarrollo de cosas nuevas es un desafío. La introducción de la inscripción Ordinal sin duda ha provocado un debate dentro de la comunidad Bitcoin sobre el papel fundamental y la esencia de Bitcoin. Esta discusión podría conducir potencialmente a una bifurcación en Bitcoin, centrándose en la seguridad y la programabilidad. Parece que se está abriendo la caja de Pandora.