Ontem, o criador do Ordinals, Casey Rodarmor, publicou um blog apresentando um novo protocolo de token fungível (FT), Runas.
Sobre se o Bitcoin precisa do FT, Casey Rodarmor afirmou em seu tweet que o FT tem dois lados. Por um lado, 99,99% dos FTs são “merdas” e golpes, que enfraquecem a pureza do Bitcoin; por outro lado, trazem muitas receitas de taxas, desenvolvedores e usuários para o ecossistema Bitcoin. “As pessoas adoram tokens e são como cassinos cyberpunk, então a receita de taxas provavelmente será substancial e contínua até que as preocupações com os orçamentos de segurança (cibernética) sejam totalmente aliviadas.”
Ele acrescentou que protocolos FT como BRC-20, RGB e Taproot já surgiram. Comparados aos protocolos on-chain simples, protocolos como RGB e Taproot são complexos e podem representar desafios para a experiência do usuário. O BRC-20 é muito simples e pode fornecer uma boa experiência ao usuário em comparação com RGB/Taproot, que requer infraestrutura de armazenamento e recuperação de dados fora da cadeia; mas o problema com os tokens BRC 20 é que eles geram "UTXO de lixo" e ocupam espaço de moedas em bits.
Rodarmor disse que Runes é um protocolo baseado em UTXO que se adapta ao Bitcoin de forma mais natural e promove a minimização de coleções UTXO, evitando a criação de “UTXOs indesejados”.
O conteúdo a seguir vem da postagem do blog de Casey Rodarmor e foi compilado por Odaily Planet Daily
Não tenho certeza se criar um novo protocolo Fungible Token (FT) para Bitcoin é uma boa ideia. 99,9% do FT são fraudes e memes. No entanto, eles não parecem desaparecer tão cedo, assim como os cassinos não parecem desaparecer tão cedo.
A criação de um bom protocolo FT para Bitcoin pode trazer receitas consideráveis de taxas de transação, atenção do desenvolvedor e usuários para o Bitcoin. Além disso, se o protocolo tiver uma presença menor na cadeia e incentivar o gerenciamento responsável do UTXO, poderá reduzir os danos em comparação aos protocolos existentes. Por exemplo, o atualmente popular BRC-20 levou à geração de uma grande quantidade de lixo UTXO.
Se compararmos os protocolos FT existentes, descobriremos que eles apresentam várias diferenças importantes:
Complexidade: Quão complexo é o protocolo? É fácil de implementar? É fácil adotar?
Experiência do usuário: existem detalhes de implementação que impactam negativamente a experiência do usuário? Em particular, os protocolos que dependem de dados fora da cadeia têm uma pegada mais leve na cadeia, mas introduzem uma complexidade significativa e exigem que os utilizadores executem os seus próprios servidores ou descubram e interajam com os servidores existentes.
Modelo de Estado: Os protocolos baseados em UTXO se adaptam mais naturalmente ao Bitcoin e promovem a minimização do conjunto UTXO, evitando a criação de UTXOs “lixo”.
Tokens nativos: Os protocolos com tokens nativos necessários para a operação do protocolo são complicados, retiráveis e, naturalmente, menos amplamente adotados.
Com base nas dimensões acima, os resultados da comparação dos protocolos FT existentes no ecossistema Bitcoin são os seguintes:
BRC-20: Não baseado em UTXO, e bastante complexo pois requer o uso da teoria ordinal em algumas operações;
RGB: Muito complexo, depende de dados off-chain, foi desenvolvido há muito tempo e não foi adotado;
Contraparte: possui tokens nativos necessários para determinadas operações, em vez de baseados em UTXO;
Omni Layer: Possui tokens nativos necessários para determinadas operações, em vez de baseados em UTXO;
Taproot Assets: Um pouco complicado e depende de dados fora da cadeia.
Para o Bitcoin, como seria um protocolo FT simples, baseado em UTXO, com uma boa experiência do usuário? A seguir, gostaria de apresentar a vocês uma solução muito legal chamada "Runas".
(1. Visão Geral
Os saldos de runas são mantidos em UTXO; UTXO pode conter qualquer número de runas.
Uma transação contém uma mensagem de protocolo se contiver uma saída cujo pubkey de script contém OP_RETURN seguido por um push de dados R em maiúscula ASCII. A mensagem do protocolo consiste em todos os dados enviados após o primeiro.
A entrada de runas em transações com mensagens de protocolo inválidas será destruída, permitindo que futuras atualizações alterem a forma como as runas são alocadas ou criadas, evitando que clientes mais antigos aloquem incorretamente saldos de runas.
Os números inteiros são codificados como prefixo int, onde o dígito inicial em int determina seu comprimento em bytes.
(2) Transferência
O primeiro envio de dados em uma mensagem de protocolo é decodificado em uma sequência de números inteiros.
Esses inteiros são interpretados como uma sequência de tuplas (ID, OUTPUT, AMOUNT). Se o número de inteiros decodificados não for múltiplo de 3, a mensagem do protocolo será inválida.
ID é o ID numérico da execução a ser atribuída
OUTPUT é o índice da saída a ser atribuída
AMOUNT é a quantidade de corridas a serem alocadas
O ID é codificado como delta. Isso permite que a mesma runa seja atribuída várias vezes para evitar a duplicação do ID completo da runa. Por exemplo, tupla: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Faça as seguintes atribuições:
ID 100, saída 1, 20 runas
ID 100, saída 2, 10 runas
id 120, saída 1, 5 runas
AMOUNT 0 é a abreviação de "todas as runas restantes".
Depois que todas as atribuições de tupla forem processadas, quaisquer runas não atribuídas serão atribuídas à primeira saída não OP_RETURN (se houver). Tarefas extras serão ignoradas.
Runas podem ser gravadas atribuindo-as à saída OP_RETURN que contém a mensagem do protocolo.
(3)Problema
Se a mensagem do protocolo tiver um segundo envio de dados, é uma transação de emissão. O segundo envio de dados é decodificado em dois números inteiros, SYMBOL e DECIMALS. Se forem deixados números inteiros adicionais, a mensagem do protocolo será inválida.
Uma transação de emissão pode criar qualquer número de runas de emissão usando o ID 0 na tupla de atribuição, até um máximo de 2^128 - 1.
SYMBOL é um símbolo de codificação base de 26 bits legível por humanos, semelhante ao símbolo usado em nomes sat ordinais. Os únicos caracteres válidos são de A a Z.
DECIMALS é o número de dígitos após o ponto decimal que deve ser usado ao exibir runas emitidas.
Se o SÍMBOLO não tiver sido atribuído, ele será atribuído a uma runa publicada e a runa publicada receberá o próximo ID de runa numérico disponível (começando em 1).
Se o SYMBOL já tiver sido alocado, ou for BITCOIN, BTC ou XBT, nenhuma nova runa será criada. As alocações de transação de liberação usando um ID de runa 0 serão ignoradas, mas outras alocações ainda serão processadas.
(4) NOTA
Ao exibir saldos UTXO, o saldo Bitcoin nativo do UTXO pode ser exibido com a runa ID 0 e os símbolos BITCOIN, BTC ou XBT.
Para manter o protocolo simples, (Runes) não adota um mecanismo para evitar a ocupação de símbolos. Na verdade, uma maneira simples e eficiente de evitar a vinculação de símbolos é permitir apenas a alocação de símbolos acima de um determinado comprimento, que diminui com o tempo e, eventualmente, chega a zero e permite todos os símbolos. Isto evitaria a atribuição de símbolos curtos e ideais no início do protocolo e encorajaria os retardatários a competir por símbolos ideais - se tal competição fizer sentido.
Escrito no final
Essa solução realmente funciona para o mercado? Eu não faço ideia.
É tão simples quanto possível, não depende de dados fora da cadeia, não possui tokens nativos e se encaixa perfeitamente no modelo UTXO nativo do Bitcoin. Tal esquema poderia atrair usuários de outros esquemas com uma pegada pior na rede e chamar a atenção de desenvolvedores e usuários para o Bitcoin, encorajando-os a adotar o próprio Bitcoin.
O mundo do FT, por outro lado, é um abismo completamente irremediável de engano e ganância, por isso pode ser eliminado.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Substituir o BRC-20 para ativar o ecossistema BTC? Fundador da Ordinals traz novo protocolo Runes
Original | Casey Rodarmor
Compilado | Odaily Planet Daily
Ontem, o criador do Ordinals, Casey Rodarmor, publicou um blog apresentando um novo protocolo de token fungível (FT), Runas.
Sobre se o Bitcoin precisa do FT, Casey Rodarmor afirmou em seu tweet que o FT tem dois lados. Por um lado, 99,99% dos FTs são “merdas” e golpes, que enfraquecem a pureza do Bitcoin; por outro lado, trazem muitas receitas de taxas, desenvolvedores e usuários para o ecossistema Bitcoin. “As pessoas adoram tokens e são como cassinos cyberpunk, então a receita de taxas provavelmente será substancial e contínua até que as preocupações com os orçamentos de segurança (cibernética) sejam totalmente aliviadas.”
Ele acrescentou que protocolos FT como BRC-20, RGB e Taproot já surgiram. Comparados aos protocolos on-chain simples, protocolos como RGB e Taproot são complexos e podem representar desafios para a experiência do usuário. O BRC-20 é muito simples e pode fornecer uma boa experiência ao usuário em comparação com RGB/Taproot, que requer infraestrutura de armazenamento e recuperação de dados fora da cadeia; mas o problema com os tokens BRC 20 é que eles geram "UTXO de lixo" e ocupam espaço de moedas em bits.
Rodarmor disse que Runes é um protocolo baseado em UTXO que se adapta ao Bitcoin de forma mais natural e promove a minimização de coleções UTXO, evitando a criação de “UTXOs indesejados”.
O conteúdo a seguir vem da postagem do blog de Casey Rodarmor e foi compilado por Odaily Planet Daily
Não tenho certeza se criar um novo protocolo Fungible Token (FT) para Bitcoin é uma boa ideia. 99,9% do FT são fraudes e memes. No entanto, eles não parecem desaparecer tão cedo, assim como os cassinos não parecem desaparecer tão cedo.
A criação de um bom protocolo FT para Bitcoin pode trazer receitas consideráveis de taxas de transação, atenção do desenvolvedor e usuários para o Bitcoin. Além disso, se o protocolo tiver uma presença menor na cadeia e incentivar o gerenciamento responsável do UTXO, poderá reduzir os danos em comparação aos protocolos existentes. Por exemplo, o atualmente popular BRC-20 levou à geração de uma grande quantidade de lixo UTXO.
Se compararmos os protocolos FT existentes, descobriremos que eles apresentam várias diferenças importantes:
Com base nas dimensões acima, os resultados da comparação dos protocolos FT existentes no ecossistema Bitcoin são os seguintes:
Para o Bitcoin, como seria um protocolo FT simples, baseado em UTXO, com uma boa experiência do usuário? A seguir, gostaria de apresentar a vocês uma solução muito legal chamada "Runas".
(1. Visão Geral
Os saldos de runas são mantidos em UTXO; UTXO pode conter qualquer número de runas.
Uma transação contém uma mensagem de protocolo se contiver uma saída cujo pubkey de script contém OP_RETURN seguido por um push de dados R em maiúscula ASCII. A mensagem do protocolo consiste em todos os dados enviados após o primeiro.
A entrada de runas em transações com mensagens de protocolo inválidas será destruída, permitindo que futuras atualizações alterem a forma como as runas são alocadas ou criadas, evitando que clientes mais antigos aloquem incorretamente saldos de runas.
Os números inteiros são codificados como prefixo int, onde o dígito inicial em int determina seu comprimento em bytes.
(2) Transferência
O primeiro envio de dados em uma mensagem de protocolo é decodificado em uma sequência de números inteiros.
Esses inteiros são interpretados como uma sequência de tuplas (ID, OUTPUT, AMOUNT). Se o número de inteiros decodificados não for múltiplo de 3, a mensagem do protocolo será inválida.
O ID é codificado como delta. Isso permite que a mesma runa seja atribuída várias vezes para evitar a duplicação do ID completo da runa. Por exemplo, tupla: [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]
Faça as seguintes atribuições:
AMOUNT 0 é a abreviação de "todas as runas restantes".
Depois que todas as atribuições de tupla forem processadas, quaisquer runas não atribuídas serão atribuídas à primeira saída não OP_RETURN (se houver). Tarefas extras serão ignoradas.
Runas podem ser gravadas atribuindo-as à saída OP_RETURN que contém a mensagem do protocolo.
(3)Problema
Se a mensagem do protocolo tiver um segundo envio de dados, é uma transação de emissão. O segundo envio de dados é decodificado em dois números inteiros, SYMBOL e DECIMALS. Se forem deixados números inteiros adicionais, a mensagem do protocolo será inválida.
Uma transação de emissão pode criar qualquer número de runas de emissão usando o ID 0 na tupla de atribuição, até um máximo de 2^128 - 1.
SYMBOL é um símbolo de codificação base de 26 bits legível por humanos, semelhante ao símbolo usado em nomes sat ordinais. Os únicos caracteres válidos são de A a Z.
DECIMALS é o número de dígitos após o ponto decimal que deve ser usado ao exibir runas emitidas.
Se o SÍMBOLO não tiver sido atribuído, ele será atribuído a uma runa publicada e a runa publicada receberá o próximo ID de runa numérico disponível (começando em 1).
Se o SYMBOL já tiver sido alocado, ou for BITCOIN, BTC ou XBT, nenhuma nova runa será criada. As alocações de transação de liberação usando um ID de runa 0 serão ignoradas, mas outras alocações ainda serão processadas.
(4) NOTA
Ao exibir saldos UTXO, o saldo Bitcoin nativo do UTXO pode ser exibido com a runa ID 0 e os símbolos BITCOIN, BTC ou XBT.
Para manter o protocolo simples, (Runes) não adota um mecanismo para evitar a ocupação de símbolos. Na verdade, uma maneira simples e eficiente de evitar a vinculação de símbolos é permitir apenas a alocação de símbolos acima de um determinado comprimento, que diminui com o tempo e, eventualmente, chega a zero e permite todos os símbolos. Isto evitaria a atribuição de símbolos curtos e ideais no início do protocolo e encorajaria os retardatários a competir por símbolos ideais - se tal competição fizer sentido.
Escrito no final
Essa solução realmente funciona para o mercado? Eu não faço ideia.
É tão simples quanto possível, não depende de dados fora da cadeia, não possui tokens nativos e se encaixa perfeitamente no modelo UTXO nativo do Bitcoin. Tal esquema poderia atrair usuários de outros esquemas com uma pegada pior na rede e chamar a atenção de desenvolvedores e usuários para o Bitcoin, encorajando-os a adotar o próprio Bitcoin.
O mundo do FT, por outro lado, é um abismo completamente irremediável de engano e ganância, por isso pode ser eliminado.