Transferência fora da cadeia: o caminho evolutivo dos protocolos de ativos Bitcoin

Introdução

A emissão de ativos baseados em BTC sempre foi um tema quente. Desde o primeiro aparecimento das Moedas Coloridas em 2011 até o recentemente popular Protocolo Ordinal, a comunidade BTC sempre foi capaz de trazer novos jogadores e consenso. No entanto, poucos resistiram ao teste do tempo. Com o ambicioso Lightling Labs anunciando seu plano para construir uma moeda estável sobre os ativos Taproot, e Tether declarando sua escolha de RGB para cunhar USDT na primeira camada do Bitcoin, fica claro que o outrora famoso OmniLayer (Mastercoin) não é mais o maior jogador no ecossistema BTC. Os protocolos de ativos de validação do lado do cliente (CSV) estão começando a ganhar atenção, diferindo dos protocolos tradicionais de ativos BTC por também incorporarem recursos para a escalabilidade do Bitcoin. Mas diante de tantos protocolos de ativos no ecossistema BTC, é preciso perguntar: quais são suas diferenças? E como devemos escolher e encontrar as nossas próprias oportunidades entre estes numerosos protocolos de ativos?

Este artigo tem como objetivo orientar os leitores na revisão de vários protocolos de ativos que apareceram na história do Bitcoin, investigando a trajetória potencial dos protocolos de ativos baseados em Bitcoin em um futuro próximo.

Moedas coloridas

A ideia das Moedas Coloridas foi proposta pela primeira vez por Yoni Assia, o atual CEO da eToro, em um artigo escrito em 27 de março de 2012, intitulado “bitcoin 2.X (também conhecido como Bitcoin colorido)”. O artigo postula que o Bitcoin, como tecnologia subjacente, é perfeito, assim como o HTTP é a base da Internet. Portanto, com base na reutilização do BTC, o protocolo de token Colored Coins foi projetado.

Yoni Assia pretendia criar uma economia BTC 2.0 através deste método – qualquer comunidade poderia criar uma variedade de moedas desta forma. Esta abordagem de usar Bitcoin como tecnologia subjacente para compensar transações e evitar gastos duplos foi, sem dúvida, uma ideia muito ousada na época.

Por ser um protocolo de emissão de ativos baseado em Bitcoin, o método da Colored Coins consiste em “colorir” uma determinada quantidade de Bitcoin para representar esses ativos. Esses Bitcoins marcados permanecem funcionalmente Bitcoins, mas também representam outro ativo ou valor. Mas como essa ideia poderia ser implementada no Bitcoin?

Em 3 de julho de 2014, a ChromaWay desenvolveu um protocolo de moedas coloridas (EPOBC) baseado em Pay-to-Script-Hash (P2SH) aprimorado, que simplificou o processo para os desenvolvedores criarem moedas coloridas. Este foi o primeiro protocolo a adotar a funcionalidade OP_RETURN do Bitcoin Script.

A implementação final é mostrada na imagem a seguir:

)

Esta implementação é muito sucinta, mas também traz muitos problemas:

Tokens homogeneizados e valor mínimo de ligação

Na transação genesis, se uma moeda colorida estiver vinculada a 1000 sats, a menor unidade dividida dessa moeda colorida é 1 sat. Isso significa que o ativo ou token pode ser dividido ou alocado em no máximo 1000 partes (mas isso é apenas teórico, para evitar ataques de poeira, por exemplo, o sat costumava ser definido em 546 SAT, e posteriormente para ordinal que é maior ).

Problemas de verificação

Para verificar a autenticidade e propriedade de uma moeda colorida, é necessário rastrear e verificar desde a transação de gênese do ativo até o UTXO atual. Portanto, é essencial desenvolver uma carteira dedicada e um full node acompanhante, e até mesmo um navegador.

Risco Potencial de Censura dos Mineiros

Devido às características distintas do ColoredTransaction, que envolve a gravação de informações de metadados na saída, existe a possibilidade de censura do minerador.

As moedas coloridas são essencialmente um sistema de rastreamento de ativos, utilizando as regras de verificação do Bitcoin para rastrear transferências de ativos. Porém, para provar que qualquer saída específica (txout) representa um determinado ativo, é necessária toda uma cadeia de transferência desde a origem do ativo até o presente. Isto significa que a verificação da legitimidade de uma transação pode exigir uma longa cadeia de provas. Para resolver este problema, houve uma proposta para OP_CHECKCOLORVERIFY ajudar na verificação direta da exatidão das transações de Moedas Coloridas no BTC, mas esta proposta não foi aprovada.

A primeira ICO na indústria de criptomoedas: Mastercoin

O conceito inicial de Mastercoin foi proposto por JR Willett. Em 2012, ele publicou um whitepaper intitulado “The Second Bitcoin Whitepaper”, que descreveu o conceito de criação de novos ativos ou tokens na blockchain existente do Bitcoin, mais tarde conhecida como “MasterCoin”. Posteriormente, foi renomeado como Omni Layer.

O projeto Mastercoin conduziu uma venda inicial de tokens (o que hoje chamamos de ICO ou Oferta Inicial de Moedas) em 2013, arrecadando com sucesso milhões de dólares. Esta é considerada a primeira ICO da história. A aplicação mais notável do Mastercoin é o Tether (USDT), o stablecoin fiduciário mais conhecido, que foi inicialmente emitido na Omni Layer.

Na verdade, o conceito de Mastercoin é anterior às Moedas Coloridas. A razão pela qual é discutido aqui é que, em comparação com as moedas coloridas, o Mastercoin é uma solução relativamente mais complexa. Mastercoin estabeleceu uma camada completa de nós, oferecendo assim funcionalidades mais complexas (como contratos inteligentes), enquanto Colored Coins era mais simples e direta, focando principalmente em “colorir” ou marcar Bitcoin UTXOs para representar outros ativos.

A principal diferença das Moedas Coloridas é que a Mastercoin publica apenas vários tipos de comportamentos de transação na cadeia, sem registrar informações de ativos relacionadas. Nos nós Mastercoin, um banco de dados de modelo de estado é mantido através da varredura de blocos Bitcoin em nós fora da cadeia.

Comparado às moedas coloridas, o Mastercoin pode executar uma lógica mais complexa. E por não registrar estado e realizar validação na cadeia, suas transações não necessitam de continuidade (coloração contínua).

No entanto, para implementar a lógica complexa do Mastercoin, os usuários precisam confiar no estado no banco de dados off-chain dos nós ou executar seus próprios nós Omni Layer para verificação.

Resumindo:

A principal diferença entre Mastercoin e Colored Coins é que Mastercoin optou por não manter todos os dados necessários para o protocolo on-chain. Em vez disso, usou parasitamente o sistema de consenso do BTC para implementar sua própria publicação e ordenação de transações, enquanto mantinha o estado em um banco de dados fora da cadeia.

De acordo com informações fornecidas pela OmniBolt: Omni Layer está propondo um novo protocolo de ativos UBA (UTXO Based Asset) para Tether, que utilizará a atualização Taproot para codificar informações de ativos em tapleaf, permitindo funcionalidades como pagamentos condicionais. Enquanto isso, OmniBolt está introduzindo Stark na infraestrutura Lightning Network da OmniLayer.

O conceito de validação do lado do cliente

Para entender o conceito de validação do lado do cliente, precisamos voltar ao ano seguinte ao surgimento das Moedas Coloridas e da Mastercoin, que é 2013. Naquele ano, Peter Todd publicou um artigo: “Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation”. Embora o título do artigo não pareça diretamente relacionado à validação do lado do cliente, uma leitura cuidadosa revela que ele contém os primeiros pensamentos esclarecedores sobre a validação do lado do cliente.

Peter Todd, um dos primeiros pesquisadores em Bitcoin e criptografia, sempre procurou um método para tornar a operação do Bitcoin mais eficiente. Ele desenvolveu um conceito mais complexo de validação do lado do cliente baseado no conceito de carimbos de data/hora. Além disso, introduziu o conceito de “selo de uso único”, que será mencionado mais adiante.

Seguindo os pensamentos de Peter Todd, vamos primeiro entender os problemas que o BTC (Bitcoin) realmente resolveu. Na opinião de Peter Todd, o BTC resolveu três problemas:

Prova de Publicação

A essência da prova de publicação é resolver o problema do gasto duplo. Por exemplo, Alice tem alguns bitcoins que deseja transferir para Bob. Embora ela assine uma transação para transferir para Bob, Bob pode não saber fisicamente da existência da transação. Portanto, é necessário que haja um local público para publicar as transações, onde todos possam consultá-las.

Consenso de pedido

Nos sistemas informáticos, o tempo físico que normalmente percebemos não existe. Em sistemas distribuídos, o tempo é frequentemente representado por carimbos de data/hora Lamport, que não medem nosso tempo físico, mas ordenam nossas transações.

Validação (opcional)

A validação no BTC refere-se à verificação de assinaturas e valores de transferência de BTC. Porém, aqui, Peter Todd acredita que esta validação não é necessária para construir um sistema de tokens em cima do BTC, mas sim uma opção de otimização.

Neste ponto, você pode pensar no Ominilayer mencionado anteriormente. A própria Ominilayer não delega o cálculo e verificação do estado ao BTC, mas ainda reutiliza a segurança do BTC. As Moedas Coloridas, por outro lado, delegam o rastreamento do estado ao BTC. A existência de ambos demonstra que a validação não precisa necessariamente ocorrer na cadeia.

Então, como a validação do lado do cliente valida efetivamente as transações?

Vamos primeiro ver o que precisa ser validado:

• Estado (validação da lógica de transação)

• Insira a validade do TxIn (para evitar gastos duplos)

É evidente que para ativos emitidos em BTC, cada transação requer a verificação de todo o histórico de transações relacionadas para garantir que o insumo referenciado não foi gasto e que o estado está correto. Isso é altamente ineficiente. Então, como pode ser melhorado?

Peter Todd acredita que podemos simplificar este processo mudando o foco da validação. Em vez de confirmar que um resultado não foi gasto duas vezes, este método centra-se na confirmação de que os inputs da transação foram publicados e não estão em conflito com outros inputs. Ao ordenar as entradas em cada bloco e utilizar uma árvore Merkle, esse tipo de validação pode ser feita de forma mais eficiente, pois cada validação requer apenas uma pequena porção de dados, e não todo o histórico da cadeia daquela entrada.

Peter Todd propôs a estrutura de uma árvore de compromisso da seguinte forma:

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

Mas como armazenamos essa árvore de compromissos na cadeia? Isto nos leva ao conceito de selo descartável.

Selo de uso único

O selo de uso único é um dos conceitos centrais para a compreensão da validação do lado do cliente, semelhante aos selos físicos de uso único usados para proteger contêineres de carga no mundo real. Um selo descartável é um objeto único que pode fechar uma mensagem com precisão uma vez. Em suma, um selo de utilização única é um mecanismo abstrato utilizado para evitar gastos duplos.

Para SealProtocol, existem três elementos e duas ações.

Elementos básicos:

1. l: selar, isto é, selar
2. m: mensagem, mensagem
3. In: testemunha, testemunha

Operações básicas: Existem duas operações básicas:

1. Close(l,m) → w: no selo de fechamento do messagemupper, gere um testemunhoIn。
2. Verify(l,w,m) → bool: Verifique seallVocê está nas notícias?está fechado.

A implementação do selo de uso único é em termos de segurança. Duas mensagens diferentes não podem ser encontradas por um invasor m1 e m2 e faz com que a função Verify retorne o mesmo sealtrueof.

Em primeiro lugar, o Selo de Uso Único é um conceito que garante que um determinado ativo ou dado seja usado ou bloqueado apenas uma vez. No contexto do Bitcoin, isso geralmente significa que um UTXO (saída de transação não gasta) só pode ser gasto uma vez. Portanto, a saída de uma transação Bitcoin pode ser considerada um selo único, e quando essa saída é usada como entrada para outra transação, o selo é “quebrado” ou “usado”.

Para ativos CSV no BTC, o próprio Bitcoin atua como uma “testemunha” selada única. Isso ocorre porque, para validar uma transação Bitcoin, um nó deve verificar se cada entrada da transação faz referência a um UTXO válido e não gasto. Se uma transação tentar gastar duas vezes um UTXO que já foi gasto, as regras de consenso do Bitcoin e os nós honestos em toda a rede rejeitarão a transação.

Pode ser mais simples?

selo de uso único Ou seja, qualquer blockchain é considerado um banco de dados. Armazenamos de alguma forma a promessa de uma determinada mensagem neste banco de dados e mantemos um status consumido ou a ser consumido para ela.

Sim, é simples assim.

Resumindo, os ativos verificados pelo cliente possuem as seguintes características:

1. Armazenamento de dados fora da cadeia: a maior parte do histórico de transações, propriedade e outros dados relacionados de ativos verificados pelo cliente são armazenados fora da cadeia. Isso reduz bastante as necessidades de armazenamento de dados em cadeia e ajuda a melhorar a privacidade.
2. Mecanismo de compromisso: Embora os dados dos ativos sejam armazenados fora da cadeia, as alterações ou transferências destes dados serão registadas na cadeia através de compromissos. Esses compromissos permitem que as transações on-chain façam referência a estados fora da cadeia, garantindo assim a integridade e a não adulteração dos dados fora da cadeia.
3. Testemunha on-chain (não necessariamente BTC): Embora a maioria dos dados e verificações sejam off-chain, os ativos verificados pelo cliente ainda podem aproveitar a segurança da cadeia subjacente (emissão de provas, ordenação de transações) por meio de compromissos incorporados na -corrente.
4. A verificação é feita no lado do cliente: a maior parte do trabalho de verificação é feita no dispositivo do usuário. Isto significa que todos os nós da rede não precisam participar na verificação de cada transação, apenas os participantes envolvidos precisam verificar a validade da transação.

Para quem usa a verificação de ativos do lado do cliente, há outro ponto a ser observado:

Ao negociar fora da cadeia e verificar ativos verificados pelo cliente, você não deve apenas mostrar a chave privada que contém o ativo, mas também comprovar o caminho Merkel completo do ativo correspondente.

O pioneiro em validação do lado do cliente (CSV): RGB

O conceito de RGB foi proposto por Giacomo Zucco, figura conhecida na comunidade, a partir de 2015. Devido à ascensão do Ethereum e à proliferação de ICOs, e antes das ICOs, muitas pessoas tentaram fazer coisas fora do Bitcoin, como projetos Mastercoin e Colored Coins. .

Giacomo Zucco expressou decepção. Ele acredita que esses projetos são inferiores ao Bitcoin e que as formas anteriores de implementação de tokens no Bitcoin são inadequadas. No processo, ele conheceu Peter Todd e ficou fascinado com a ideia de Peter Todd de validação do lado do cliente. Então ele começou a propor a ideiaRGB .

A maior diferença entre o RGB e os protocolos de ativos anteriores é que, além dos recursos mencionados anteriormente de verificação de ativos do lado do cliente, ele também adiciona uma VM de execução para implementar um mecanismo de execução de contrato Turing-completo. Além disso, para garantir a segurança dos dados do contrato, também são projetados Schema e Interface. Schema é semelhante ao Ethereum, declarando o conteúdo e funções do contrato, enquanto Interface é responsável pela implementação de funções específicas, assim como a interface nas linguagens de programação.

Os esquemas desses contratos são responsáveis por restringir comportamentos que não excedam o comportamento esperado quando a VM é executada, como RGB20 e RGB21, que são respectivamente responsáveis por algumas restrições nas transações de tokens fungíveis e tokens não fungíveis.

Mecanismo de compromisso do RGB: Pedersen Hash

Em termos de mecanismos de compromisso, o RGB adota o Pedersen Hash. Sua vantagem está em poder se comprometer com um valor sem divulgá-lo. Usar o Pedersen Hash para construir uma árvore Merkle significa que você pode criar uma árvore Merkle protegida por privacidade que oculta os valores dentro dela. Essa estrutura pode ser usada em determinados protocolos específicos de proteção de privacidade, como alguns projetos anônimos de criptomoeda. No entanto, pode não ser adequado para ativos CSV, que serão mencionados posteriormente na comparação com Taproot Assets.

Design de máquina virtual RGB: da simplicidade ao AluVM

RGB visa não apenas implementar um protocolo de ativos validado pelo cliente, mas também estender a execução de máquinas virtuais completas de Turing e programação de contratos. No design inicial do RGB, ele afirmava usar uma linguagem de programação chamada Simplicity. Esta linguagem se caracteriza por gerar uma prova de execução durante a execução de expressões, facilitando a verificação formal dos contratos nela escritos (para evitar bugs). Porém, o desenvolvimento desta linguagem não foi ideal e acabou encontrando dificuldades. Isso levou diretamente ao difícil nascimento do protocolo RGB naquele ano. Por fim, o RGB passou a utilizar o AluVM, desenvolvido pela Maxim, com o objetivo de evitar qualquer comportamento indefinido, semelhante ao Simplicity inicial. O novo AluVM será substituído no futuro por uma linguagem de programação chamada Contractum, atualmente usando Rust.

Direção de expansão da camada 2 do RGB: Lightning Network ou Sidechain?

Os ativos validados pelo cliente não podem conduzir transações contínuas fora da cadeia com segurança. Como os ativos validados pelo cliente ainda dependem de L1 para publicação e sequenciamento de transações, sua velocidade de transação é limitada pela velocidade de geração de blocos de sua testemunha L1. Isto significa que se as transações RGB forem realizadas diretamente no Bitcoin, sob rígidos requisitos de segurança, o tempo entre duas transações relacionadas precisa ser de pelo menos dez minutos (tempo de bloqueio do BTC). Sem dúvida, essa velocidade de transação é inaceitável na maioria dos casos.

RGB e a rede Lightning

Simplificando, o princípio da Lightning Network é que as duas partes envolvidas em uma transação assinam vários contratos (transações de compromisso) fora da cadeia. Estes garantem que, se qualquer parte violar o contrato, a parte prejudicada poderá submeter o contrato (transação de compromisso) ao BTC para liquidação, recuperar seus fundos e penalizar a outra parte. Em outras palavras, a Lightning Network garante a segurança das transações fora da cadeia por meio do design de protocolos e da teoria dos jogos.

RGB pode construir sua própria infraestrutura Lightning Network projetando regras de contrato de canal de pagamento adequadas para si, mas a complexidade da Lightning Network é extremamente alta e construir esse sistema não é uma tarefa fácil. No entanto, em contraste, a Lightnling Labs cultiva este campo há muitos anos e a LND tem mais de 90% de participação de mercado.

Cadeia lateral do RGB: Prime

LNP-BP, atualmente mantendo o protocolo RGB, com a Maxim lançando uma proposta chamada Prime em junho de 2023, um esquema de expansão de ativos validado pelo cliente. Nele, ele criticou os esquemas existentes de expansão da cadeia lateral e da Lightning Network como sendo muito complexos em desenvolvimento. Maxim indicou que acredita que além do Prime, outros métodos de expansão incluem canais Lightning de vários nós NUCLEUS e fábricas de canais Ark/Enigma, ambos os quais requerem mais de dois anos de desenvolvimento. No entanto, o Prime pode ser concluído em apenas um ano.

Prime não é um design de blockchain tradicional, mas uma camada modular de publicação de provas projetada para validação do cliente, consistindo em quatro partes:

1. Serviço de carimbo de data/hora: determina uma sequência de transação em apenas 10 segundos.

2. Prova: Armazenado no formato PMT, produzido e publicado junto com o cabeçalho do bloco.

3. Selo Único: Um protocolo abstrato de selo único, garantindo proteção contra gastos duplos. Se implementado no Bitcoin, pode ser vinculado ao UTXO, semelhante ao design RGB atual.

4. Protocolo de Contrato Inteligente: Contratos Fragmentáveis - RGB (substituível).

Para resolver o problema dos tempos de confirmação de transações RGB, Prime usa um serviço de carimbo de data/hora para confirmar rapidamente as transações fora da cadeia e encapsular as transações e IDs em blocos. Simultaneamente, as provas de transação no Prime podem ser posteriormente mescladas por meio do PMT e depois ancoradas no BTC de maneira semelhante aos pontos de verificação.

Protocolo de ativos CSV baseado em Taproot: ativos Taproot

Taproot Assets é um protocolo de ativos CSV baseado em Taproot, usado para emitir ativos validados pelo cliente no blockchain Bitcoin. Esses ativos podem ser negociados instantaneamente, em grandes volumes e com baixo custo através da Lightning Network. O núcleo do Taproot Assets reside no aproveitamento da segurança e estabilidade da rede Bitcoin e na velocidade, escalabilidade e baixo custo da Lightning Network. Este protocolo foi projetado e desenvolvido pelo CTO roasbeef da Lightnling Labs, que pode ser a única pessoa neste planeta que liderou pessoalmente o desenvolvimento de um cliente Bitcoin (BTCD) e de um cliente Lightning Network (LND), e tem um profundo conhecimento de BTC.

As transações Taproot carregam apenas o hash raiz do script de ativos, tornando difícil para observadores externos identificar se elas envolvem ativos Taproot, já que o hash em si é genérico e pode representar qualquer dado. Com a atualização do Taproot, o Bitcoin ganhou a capacidade de contratos inteligentes (TapScript). Com base nisso, a codificação de ativos Taproot Assets é semelhante à criação de uma definição de token semelhante a ERC20 ou ERC721. Assim, o Bitcoin não tem apenas a função de definição de ativos, mas também a capacidade de redigir contratos inteligentes, estabelecendo as bases para a infraestrutura de contratos inteligentes de token no Bitcoin.

A estrutura de codificação do Taproot Assets é a seguinte: [A descrição termina aqui, indicando que a próxima parte do artigo provavelmente se aprofunda nos detalhes técnicos da estrutura de codificação do Taproot Assets.]

Imagem via Lightning Labs CTO roasbeef

Como protocolos de ativos CSV (CoinSwap), os Taproot Assets são projetados para serem mais simplificados em comparação com RGB. Eles maximizam o uso dos avanços atuais no ecossistema BTC, como a atualização Taproot e PSBT (Transações Bitcoin Parcialmente Assinadas). A diferença mais significativa entre Taproot Assets e RGB em termos de extensibilidade do aplicativo está na VM (Máquina Virtual) de execução. Taproot Assets emprega TaprootScriptVM, que é o mesmo que a VM nativa usada pelo BTC. Nos últimos anos, muitos estudos de infraestrutura para BTC foram baseados no TapScript. No entanto, devido ao ritmo lento das atualizações do BTC, esses estudos não foram implementados rapidamente, tornando a Taproot Assets um potencial campo de testes para essas novas ideias.

Onde os ativos Taproot e RGB diferem?

1. Validação de transação e facilidade de uso do Light Node

Devido à implementação de uma árvore de soma, o Taproot Assets apresenta alta eficiência e segurança de verificação (a verificação e a transação podem ser realizadas simplesmente com um comprovante de detenção, sem percorrer todo o histórico de transações). Em contraste, a utilização dos compromissos Pedersen pela RGB dificulta a validação eficaz dos dados, exigindo que a RGB rastreie o histórico de transações, o que se torna um fardo significativo ao longo do tempo. O design da árvore de soma de Merkel também facilita a verificação de nós leves no Taproot Assets, um recurso não presente em protocolos de ativos anteriores construídos em BTC.

1. VM de execução

O Taproot Assets surgiu após a atualização do Taproot. Eles utilizam TaprootScriptVM, o mecanismo de execução de script inerente à atualização pós-Taproot do Bitcoin, e vPSBT, uma variante do PSBT do BTC. Assim que o mecanismo de canal relâmpago do Taproot Assets for concluído, ele poderá reutilizar imediatamente toda a infraestrutura LND atual e produtos anteriores do Lightning Labs (o LND atualmente domina mais de 90% da rede relâmpago). A recente proposta BitVM, também baseada em TaprootScript, teoricamente suporta Taproot Assets. No entanto, a VM e as regras de validação (SCHEMA) do RGB são independentes, formando um ecossistema relativamente fechado. O desenvolvimento do RGB está em grande parte confinado ao seu ecossistema, e a sua integração com o ecossistema Bitcoin não é tão próxima como se poderia pensar. Por exemplo, a única relação do RGB com a atualização do Taproot é a codificação dos dados de comprometimento da cadeia no TapLeaf da Witness.

1. Contratos Inteligentes

Na implementação atual do RGB, os contratos e a VM são fortemente enfatizados. No entanto, os contratos inteligentes ainda não apareceram no Taproot Assets. Atualmente, o RGB não explica como as modificações no Estado Global são sincronizadas com fragmentos de contrato individuais (UTXO), nem como os compromissos da Pedersen, que apenas garantem a quantidade total de ativos, detectam adulteração de outros estados. Em contraste, os Taproot Assets, com seu design mais simples, atualmente armazenam apenas saldos de ativos e carecem de armazenamento estatal extensivo, tornando prematura a discussão sobre contratos inteligentes. No entanto, o Lightning Labs indicou que a Taproot Assets se concentrará no design de contratos inteligentes no próximo ano.

1. Centro de sincronização

Conforme entendido a partir dos princípios básicos da verificação de ativos do lado do cliente, possuir a Prova é tão importante quanto possuir a chave privada. Mas e se a Prova for perdida no lado do cliente do usuário? No Taproot Assets, esse problema pode ser resolvido por meio de um ‘universo’. O Universo é uma árvore Merkle esparsa publicamente auditável, cobrindo um ou mais ativos. Ao contrário das árvores de ativos Taproot convencionais, o Universo não hospeda ativos Taproot. Em vez disso, compromete-se com um subconjunto de um ou mais históricos de ativos. No RGB, esse papel é desempenhado pelo Storm, que sincroniza dados de prova fora da cadeia via P2P. No entanto, devido a razões históricas das equipes de desenvolvimento do RGB, estes formatos de prova são atualmente incompatíveis. A equipe do ecossistema RGB, DIBA, está supostamente desenvolvendo o 'carbonado' para resolver este problema, embora o progresso não seja claro.

1. Implementação de Engenharia

Todas as bibliotecas usadas pelo Taproot Assets são testadas ao longo do tempo, já que o Lightning Labs tem seu próprio cliente Bitcoin (BTCD), cliente de rede relâmpago (LND) e inúmeras implementações de biblioteca de carteira. Em contraste, a maioria das bibliotecas usadas em RGB são autodefinidas e, do ponto de vista do padrão industrial, a implementação do RGB ainda está em fase experimental.”

Uma breve discussão sobre o futuro da expansão do BTC

À medida que a discussão avança, torna-se evidente que a validação de protocolos de ativos pelo lado do cliente ultrapassou o domínio das especificações de protocolo e está se aventurando em direção à expansão computacional.

Muitas pessoas acreditam que o Bitcoin existirá como ouro digital no futuro, com outras cadeias criando o ecossistema de aplicativos. No entanto, tenho uma opinião diferente. Como visto em muitas discussões nos fóruns do BTC, elas geralmente giram em torno de vários altcoins e de sua existência de curta duração. O rápido desaparecimento dessas altcoins transforma o capital e os esforços que os cercam em bolhas. Com a forte base de consenso do Bitcoin, não há necessidade de construir um novo L1 para protocolos de aplicação. O que precisamos fazer é aproveitar esta infraestrutura robusta do Bitcoin para construir um mundo descentralizado de mais longo prazo.

Menos computação na cadeia, mais validação na cadeia

Do ponto de vista do design, o Bitcoin desde o início optou por não se concentrar na computação em cadeia, mas em vez disso em uma filosofia centrada na validação (completude e estado de Turing para contratos inteligentes). Blockchain é essencialmente uma máquina de estado replicada. Se o consenso de uma cadeia é baseado na computação on-chain, é difícil justificar a lógica e a escalabilidade de fazer com que todos os nós da rede repitam esses cálculos. Se nos concentrarmos na validação, então a validação da eficácia das transações fora da cadeia pode ser a estratégia de expansão mais adequada para o BTC.

Onde ocorre a validação? Isso é importante

Para desenvolvedores de protocolos baseados no Bitcoin, como usar o Bitcoin para validações críticas, ou mesmo para colocar validações fora da cadeia, e como projetar esquemas de segurança, são questões para os próprios projetistas de protocolos. Estes não devem e não precisam estar associados à própria cadeia. Portanto, a forma como a validação é implementada levará a diferentes estratégias de expansão para o BTC.

Com base na perspectiva de implementação da validação, temos três direções de expansão:

1. 1. Validação em cadeia (OP-ZKP)
2. Se o OP-ZKP for implementado diretamente no TaprootScriptVM, isso significa integrar os recursos de validação do ZKP no próprio BTC, juntamente com alguns projetos Covenant para protocolos de liquidação, criando um plano de expansão Zk-Rollup que herda a segurança do BTC. No entanto, ao contrário da implantação de um contrato de validação no Ethereum, o lento processo de atualização do BTC, juntamente com um código operacional tão especializado e potencialmente necessitando de atualização, torna-o um desafio.
4. 2. Validação semi-on-chain (BitVM)
5. O design do BitVM não se destina a servir a lógica de transação regular. Robin Linus também indicou que o futuro do BitVM reside na criação de um mercado gratuito entre cadeias para vários SideChains. A abordagem do BitVM é considerada semi-on-chain porque a maioria desses cálculos de validação não acontecem na cadeia, mas sim fora da cadeia. No entanto, uma razão significativa para projetar em torno do Taproot do BTC é utilizar TapScriptVM para validação computacional quando necessário, herdando teoricamente a segurança do BTC. Este processo também gera uma cadeia de confiança de validação. Por exemplo, é suficiente que um dos 'n' validadores seja honesto, semelhante ao Optimistic Rollups.
6. Os custos on-chain do BitVM são altos, mas será que ele pode usar provas de fraude ZK para melhorar a eficiência? A resposta é não, porque a implementação de provas de fraude ZK é baseada na capacidade de realizar validação ZKP on-chain, o que nos traz de volta ao dilema do esquema OP-ZKP.
8. 3. Validação fora da cadeia (validação do lado do cliente, Lightning Network)
9. Com a validação ocorrendo inteiramente fora da cadeia, voltamos aos protocolos de ativos CSV discutidos anteriormente e à Lightning Network. Em discussões anteriores, observou-se que, no design de CSV, não podemos impedir completamente a adulteração colusiva. O que podemos fazer é usar criptografia e design de protocolo para manter os danos do conluio malicioso dentro de uma faixa controlável, tornando tal comportamento não lucrativo.
10. Os prós e contras da validação fora da cadeia são claros. A vantagem é o uso mínimo de recursos on-chain, com enorme potencial de expansão. A desvantagem é que é quase impossível aproveitar totalmente a segurança do BTC, limitando enormemente os tipos e métodos de transações fora da cadeia. Além disso, a validação fora da cadeia também significa que os dados são mantidos fora da cadeia, geridos pelos utilizadores, o que exige requisitos mais elevados para a segurança do ambiente de execução do software e estabilidade do software.

Tendência de Evolução da Expansão

Atualmente, o popular Layer2 no Ethereum, em essência, usa o Layer1 para validar a eficácia computacional do Layer2. Ou seja, os cálculos de estado são transferidos para a Camada2, mas a validação permanece na Camada1. No futuro, poderemos, de forma semelhante, reduzir os cálculos de validação para fora da cadeia, estimulando ainda mais o desempenho da atual infraestrutura de blockchain.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [espelho]. Todos os direitos autorais pertencem ao autor original [Ben77]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.