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

Introdução

Emitir ativos com base no BTC sempre foi um tema quente. Desde a primeira aparição das Moedas Coloridas em 2011 ao 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 os ambiciosos Lightling Labs a anunciar o seu plano de construir uma moeda estável sobre os ativos Taproot, e o Tether a declarar a sua escolha de RGB para cunhar USDT na primeira camada do Bitcoin, fica claro que o já famoso OmniLayer (Mastercoin) já não é o maior player no ecossistema BTC. Os protocolos de ativos de validação do lado do cliente (CSV) estão a começar a ganhar atenção, diferindo dos protocolos tradicionais de ativos BTC, incorporando também funcionalidades para a escalabilidade do Bitcoin. Mas perante uma multiplicidade de protocolos de ativos no ecossistema BTC, é preciso perguntar: quais são as 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, aprofundando a trajetória potencial dos protocolos de ativos baseados em Bitcoin num futuro previsível.

Moedas Coloridas

A ideia das Moedas Coloridas foi proposta pela primeira vez por Yoni Assia, o atual CEO da eToro, num artigo escrito em 27 de março de 2012, intitulado “bitcoin 2.X (aka bitcoin colorido).” O artigo postera que o Bitcoin, como tecnologia subjacente, é perfeito, muito parecido com o HTTP é a base da internet. Portanto, com base na reutilização do BTC, o protocolo token Colored Coins foi concebido.

Yoni Assia tinha como objetivo 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 o Bitcoin como tecnologia subjacente para compensar transações e evitar gastos duplos foi sem dúvida uma ideia muito ousada na altura.

Como um protocolo para a emissão de ativos com base em Bitcoin, o método das Moedas Coloridas é “colorir” uma certa quantidade de Bitcoin para representar esses ativos. Estes Bitcoins marcados permanecem funcionalmente Bitcoins, mas também representam outro activo ou valor. Mas como é que esta ideia pode ser implementada no Bitcoin?

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

A implementação final é mostrada na seguinte imagem:

)

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

Tokens Homogeneizados e Valor de Ligação Mínimo

Na transação de génese, se uma moeda colorida estiver ligada a 1000 sats, a menor unidade dividida desta moeda colorida é 1 sat. Isto significa que o activo ou token pode ser dividido ou alocado num máximo de 1000 partes (mas isso é apenas teórico, para evitar ataques de poeira, por exemplo, o sat costumava ser definido em 546 SAT, e depois para ordinal que é mais alto).

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 activo até ao UTXO atual. Portanto, é essencial desenvolver uma carteira dedicada e acompanhar o nó completo, e até mesmo um navegador.

Risco potencial de censura de mineiros

Devido às características distintas do ColorredTransaction, que envolve escrever informações de metadados na saída, existe a possibilidade de censura do mineiro.

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. No entanto, para provar que qualquer saída específica (txout) representa um determinado activo, é necessária uma cadeia de transferência inteira da origem do activo até ao presente. Isto significa que verificar a legitimidade de uma transação pode exigir uma longa cadeia de provas. Para resolver este problema, houve uma proposta para OP_CHECKCOLORVERIFY para ajudar a verificar diretamente a 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 J.R. Willett. Em 2012, publicou um whitepaper intitulado “The Second Bitcoin Whitepaper”, que descrevia o conceito de criação de novos ativos ou tokens na blockchain existente do Bitcoin, mais tarde conhecida como “MasterCoin”. Posteriormente, foi renomeado 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 da Mastercoin é o Tether (USDT), a stablecoin fiduciária mais conhecida, que foi inicialmente emitida na camada Omni.

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

A principal diferença das Moedas Coloridas é que a Mastercoin só publica vários tipos de comportamentos de transação na cadeia, sem registar informações de ativos relacionadas. Nos nós Mastercoin, uma base de dados de modelo de estado é mantida através da análise de blocos de Bitcoin em nós fora da cadeia.

Em comparação com as Moedas Coloridas, a Mastercoin pode executar uma lógica mais complexa. E porque não registra o estado e realiza validação na cadeia, as suas transações não requerem continuidade (coloração contínua).

No entanto, para implementar a lógica complexa da Mastercoin, os utilizadores precisam de confiar no estado da base de dados fora da cadeia dos nós ou executar os seus próprios nós Omni Layer para verificação.

Em resumo:

A principal diferença entre Mastercoin e Colored Coins é que a Mastercoin optou por não manter todos os dados necessários para o protocolo na cadeia. Em vez disso, usou de forma parasitária o sistema de consenso do BTC para implementar a sua própria publicação e ordenação de transações, mantendo o estado numa base de dados fora da cadeia.

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

O conceito de validação do lado do cliente

Para compreender o conceito de validação do lado do cliente, precisamos de voltar ao ano seguinte ao surgimento das Moedas Coloridas e Mastercoin, que é 2013. Nesse ano, Peter Todd publicou um artigo: “Desentrelaçando a Mineração de Crypto-Coin: Timestamping, Proof-of-Publication e Validation.” Embora o título do artigo não pareça diretamente relacionado com a validação do lado do cliente, uma leitura cuidadosa revela que contém os primeiros pensamentos de esclarecimento sobre a validação do lado do cliente.

Peter Todd, um dos primeiros investigadores em Bitcoin e criptografia, sempre esteve à procura de um método para tornar a operação da Bitcoin mais eficiente. Ele desenvolveu um conceito mais complexo de validação do lado do cliente com base no conceito de timestamps. Além disso, introduziu o conceito de “selo de uso único”, que será mencionado mais tarde.

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:

Proprova de publicação

A essência da prova de publicação é resolver o problema da dupla despesa. Por exemplo, a Alice tem alguns bitcoins que quer transferir para o Bob. Embora assine uma transação para transferir para o Bob, Bob pode não saber fisicamente da existência da transação. Por isso, tem de haver um local público para publicar transações, onde todos possam consultá-las.

Consenso do Pedido

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

Validação (Opcional)

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

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

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

Vamos primeiro ver o que precisa ser validado:

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

• Validade de entrada TxIN (para evitar gastos duplos)

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

Peter Todd acredita que podemos simplificar este processo alterando o foco da validação. Em vez de confirmar que uma saída não foi gasta duas vezes, este método concentra-se em confirmar que as entradas da transação foram publicadas e não estão em conflito com outras entradas. Ao ordenar as entradas em cada bloco e usar uma árvore Merkle, este tipo de validação pode ser feito de forma mais eficiente, uma vez que cada validação requer apenas uma pequena parte dos dados, não todo o histórico da cadeia dessa entrada.

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

CTXin - > CTXout - > <merkle path> - > Transação - > <merkle path> - - CTXin >

Mas como armazenamos essa árvore de compromisso na cadeia? Isto leva-nos ao conceito de um selo de utilização única.

Selo de Utilização Única

O selo de uso único é um dos conceitos centrais para entender a validação do lado do cliente, semelhante aos selos físicos de uso único usados para proteger contêineres de transporte de carga no mundo real. Um selo de uso único é um objeto único que pode fechar com precisão uma mensagem uma vez. Resumindo, um selo de uso único é um mecanismo abstrato usado para evitar gastos duplos.

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

Elementos básicos:

1. l：selo, isto é, selo
2. m：mensagem, mensagem
3. Em：testemunha, testemunha

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

1. Fechar (l, m) → w: no selo de fechamento do messagemupper, gere um WitnessIN.
2. Verificar (l, w, m) → bool: Verificar SEALEstá nas notícias? está fechado.

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

Em primeiro lugar, o Selo de Utilização Única é um conceito que garante que um determinado activo ou dados só são utilizados ou bloqueados uma vez. No contexto do Bitcoin, isso normalmente 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 única “testemunha” selada. Isto 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 é considerada uma base de dados. Armazenamos a promessa de uma determinada mensagem nesta base de dados de alguma forma e mantemos um estado de consumo ou a ser consumido para ela.

Sim, é simples assim.

Resumindo, os ativos verificados pelo cliente têm 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. Isto reduz consideravelmente as necessidades de armazenamento de dados na 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 para esses dados serão registadas na cadeia através de compromissos. Estes compromissos permitem às transações em cadeia fazer referência a estados fora da cadeia, garantindo assim a integridade e a não adulteração dos dados fora da cadeia.
3. Testemunha em cadeia (não necessariamente BTC): Embora a maioria dos dados e verificação estejam fora da cadeia, os ativos verificados pelo cliente ainda podem tirar proveito da segurança da cadeia subjacente (emissão de provas, ordenação de transações) através de compromissos incorporados na cadeia.
4. A verificação é feita no lado do cliente: A maior parte do trabalho de verificação é feito no dispositivo do utilizador. Isto significa que todos os nós da rede não precisam de participar na verificação de cada transação, apenas os participantes envolvidos precisam verificar a validade da transação.

Para aqueles que usam a verificação de ativos do lado do cliente, há outro ponto a ser notado:

Ao negociar fora da cadeia e verificar ativos verificados pelo cliente, deve não só mostrar a chave privada que detém o activo, mas também mostrar a prova do percurso completo de Merkel do activo correspondente.

O Pioneiro na Validação do Lado do Cliente (CSV): RGB

O conceito de RGB foi proposto por Giacomo Zucco, uma figura bem conhecida na comunidade, depois 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 os projetos Mastercoin e Moedas Coloridas.

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

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

Os esquemas destes contratos são responsáveis por restringir comportamentos que não excedem o comportamento esperado quando a vm é executada, tais 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. A sua vantagem reside em poder comprometer-se com um valor sem o revelar. Usar o Pedersen Hash para construir uma árvore Merkle significa que pode criar uma árvore Merkle protegida pela privacidade que esconde os valores dentro dela. Esta estrutura pode ser usada em determinados protocolos específicos de proteção de privacidade, tais como alguns projetos anónimos de criptomoeda. No entanto, pode não ser adequado para ativos CSV, que serão mencionados mais adiante na comparação com Taproot Assets.

Design de máquina virtual do RGB: Da Simplicidade ao AluVM

O RGB visa não só implementar um protocolo de ativos validado pelo cliente mas também estender à execução completa da máquina virtual e à programação de contratos da Turing-complete. No início do design do RGB, alegava usar uma linguagem de programação chamada Simplicidade. Esta linguagem caracteriza-se por gerar uma prova de execução enquanto executa expressões, facilitando a verificação formal dos contratos nela escritos (para evitar bugs). No entanto, o desenvolvimento desta linguagem não foi o ideal e acabou por encontrar dificuldades. Isso levou diretamente ao difícil nascimento do protocolo RGB naquele ano. Em última análise, o RGB começou a usar o AluVM, desenvolvido pela Maxim, com o objetivo de evitar qualquer comportamento indefinido, semelhante ao Simplicity inicial. Diz-se que o novo AluVM será substituído no futuro por uma linguagem de programação chamada Contractum, atualmente a usar 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 com segurança fora da cadeia. Como os ativos validados pelo cliente ainda dependem do L1 para publicação e sequenciamento de transações, a sua velocidade de transação é limitada pela velocidade de geração de blocos da sua testemunha L1. Isto significa que se as transações RGB forem conduzidas diretamente no Bitcoin, sob rígidos requisitos de segurança, o tempo entre duas transações relacionadas tem de ser de pelo menos dez minutos (tempo de bloqueio do BTC). Sem dúvida, essa velocidade de transação é quase inaceitável na maioria dos casos.

RGB e a Rede Lightning

Simplificando, o princípio da Lightning Network é que as duas partes envolvidas numa transação assinam um monte de contratos (transações de compromisso) fora da cadeia. Estes asseguram que, se alguma das partes violar o contrato, a parte lesada pode submeter o contrato (transação de compromisso) ao BTC para liquidação, recuperar os seus fundos e penalizar a outra parte. Por outras palavras, a Lightning Network garante a segurança das transações fora da cadeia através do design de protocolos e da teoria dos jogos.

O RGB pode construir a sua própria infra-estrutura da Lightning Network concebendo regras de contrato de canal de pagamento adequadas a si próprio, mas a complexidade da Rede Lightning é extremamente alta e construir este sistema não é uma tarefa fácil. No entanto, em contraste, a Lightnling Labs cultiva este campo há muitos anos e o LND tem mais de 90% de quota de mercado.

Sidechain do RGB: Prime

LNP-BP, atualmente mantendo o protocolo RGB, com a Maxim a lançar uma proposta chamada Prime em junho de 2023, um esquema de expansão de ativos validado pelo cliente. Nele, criticou os esquemas de expansão existentes da sidechain e da Lightning Network como sendo demasiado complexos no desenvolvimento. Maxim indicou que acredita que, além do Prime, outros métodos de expansão incluem os canais Lightning de vários nós NUCLEUS e as 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.

O Prime não é um design tradicional de blockchain mas uma camada de publicação de prova modular concebida para validação do cliente, composta por quatro partes:

1. Serviço de carimbo de data/hora: Determinar uma sequência de transações em 10 segundos.

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

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

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

Para resolver o problema dos tempos de confirmação de transações RGB, o Prime utiliza 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 através do PMT e ancoradas no BTC de forma semelhante aos checkpoints.

Protocolo de ativos CSV baseado em Taproot: Ativos Taproot

O Taproot Assets é um protocolo de ativos CSV baseado no Taproot, usado para emitir ativos validados pelo cliente na cadeia de blocos Bitcoin. Estes ativos podem ser negociados instantaneamente, em grandes volumes e a baixo custo através da Lightning Network. O núcleo do Taproot Assets reside em alavancar a segurança e a estabilidade da rede Bitcoin e a velocidade, escalabilidade e baixo custo da Rede Lightning. Este protocolo foi concebido e desenvolvido pelo CTO roasbeef da Lightnling Labs, que pode ser a única pessoa neste planeta que liderou pessoalmente o desenvolvimento tanto de um cliente Bitcoin (BTCD) como de um cliente da Lightning Network (LND), e tem uma compreensão profunda do BTC.

As transações Taproot apenas carregam o hash raiz do script de ativos, tornando difícil para os observadores externos identificarem se envolvem ativos Taproot, uma vez que o próprio hash é genérico e pode representar quaisquer dados. Com a atualização Taproot, o Bitcoin ganhou a capacidade de contratos inteligentes (TapScript). Com base nisto, a codificação de ativos do Taproot Assets é semelhante à criação de uma definição de token semelhante ao ERC20 ou ERC721. Assim, o Bitcoin não só tem a função de definição de ativos mas também a capacidade de escrever contratos inteligentes, estabelecendo as bases para a infraestrutura de contrato inteligente 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 em 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 concebidos para serem mais simplificados em comparação com o RGB. 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 o Taproot Assets e o RGB em termos de extensibilidade da aplicação reside na VM de execução (Máquina Virtual). Os ativos Taproot empregam o TaprootScriptVM, que é o mesmo que a VM nativa usada pelo BTC. Nos últimos anos, muitos estudos de infraestruturas para o BTC têm sido baseados no TAPScript. No entanto, devido ao ritmo lento das actualizações do BTC, estes estudos não foram implementados rapidamente, tornando o Taproot Assets um potencial campo de testes para estas novas ideias.

Onde é que o Taproot Assets e o RGB diferem?

1. Validação de Transacções e Simpatia dos Nódos-Luz

Devido à implementação de uma árvore de somas, os ativos Taproot possuem alta eficiência de verificação e segurança (a verificação e a transação podem ser realizadas simplesmente com uma prova de detenção, sem percorrer todo o histórico de transações). Em contraste, o uso dos compromissos da Pedersen pelo RGB dificulta a validação eficaz das entradas, exigindo que o RGB rastreia 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 do nó leve no Taproot Assets, uma característica não presente nos protocolos de ativos anteriores construídos no BTC.

1. Execução VM

Os ativos Taproot surgiram após a atualização do Taproot. Utilizam o TaprootScriptVM, o motor de execução de scripts inerente à actualização pós-Taproot do Bitcoin, e o VPSBT, uma variante do PSBT do BTC. Uma vez concluído o mecanismo de canal relâmpago do Taproot Assets, pode 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 no TaprootScript, apoia teoricamente o 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á largamente confinado no 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 actualização Taproot é a codificação de dados de compromisso da cadeia no TapLEAF da Testemunha.

1. Contratos Inteligentes

Na implementação atual do RGB, os contratos e as 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 se sincronizam com estilhaços de contrato individuais (UTXO), nem como os compromissos da Pedersen, que apenas asseguram a quantidade total de ativos, detectam adulteração com outros estados. Em contraste, os Taproot Assets, com o seu design mais simples, atualmente apenas armazenam saldos de ativos e carecem de armazenamento estatal extenso, tornando prematura a discussão dos contratos inteligentes. No entanto, a Lightning Labs indicou que a Taproot Assets vai focar-se no design de contratos inteligentes no próximo ano.

1. Hub de Sincronização

Conforme entendido a partir dos princípios básicos da verificação de ativos do lado do cliente, a posse da Prova é tão importante quanto a posse da chave privada. Mas e se a Prova for perdida do lado do cliente do utilizador? No Taproot Assets, este problema pode ser resolvido através de um 'universo'. O Universo é uma árvore Merkle esparsa auditável publicamente, que cobre 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, este papel é desempenhado pelo Storm, que sincroniza os dados de prova fora da cadeia via P2P. No entanto, devido a razões históricas das equipas de desenvolvimento do RGB, estes formatos de prova são atualmente incompatíveis. A equipa do ecossistema do RGB, DIBA, está supostamente a desenvolver 'carbonado' para resolver este problema, embora o progresso não seja claro.

1. Implementação de engenharia

Todas as bibliotecas utilizadas pelo Taproot Assets são testadas pelo tempo, uma vez que o Lightning Labs tem o seu próprio cliente Bitcoin (BTCD), cliente de rede relâmpago (LND) e inúmeras implementações de carteira lib. Em contraste, a maioria das bibliotecas utilizadas no 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 dos protocolos de activos do lado do cliente ultrapassou o domínio das especificações do protocolo e está a aventurar-se no sentido da expansão computacional.

Muitas pessoas acreditam que o Bitcoin existirá como ouro digital no futuro, com outras cadeias a criar o ecossistema de aplicações. No entanto, tenho uma opinião diferente. Como visto em muitas discussões em fóruns BTC, eles geralmente giram em torno de várias altcoins e da sua existência de curta duração. O rápido desaparecimento destas altcoins transforma o capital e os esforços que os rodeiam 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 de fazer é alavancar esta infraestrutura robusta do Bitcoin para construir um mundo descentralizado a mais longo prazo.

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

Do ponto de vista do design, o Bitcoin no início optou por não se concentrar na computação em cadeia mas sim numa filosofia centrada na validação (completude de Turing e estado para contratos inteligentes). Blockchain é essencialmente uma máquina de estado replicada. Se o consenso de uma cadeia é baseado na computação em cadeia, é 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, validar a eficácia das transações fora da cadeia pode ser a estratégia de expansão mais adequada para o BTC.

Onde é que ocorre a validação? Isto é importante

Para os desenvolvedores de protocolos em cima do 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 assuntos para os próprios projetistas de protocolo. 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 da implementação da validação, temos três direções para a expansão:

1. 1.Validação em cadeia (OP-ZKP)
2. Se o OP-ZKP for implementado diretamente no TaprootScriptVM, significa integrar capacidades de validação ZKP no próprio BTC, juntamente com alguns designs 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 de operação tão especializado e potencialmente que precisa de upgrade, torna-o um desafio.
4. 2.Validação semi-em cadeia (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 da BitVM reside na criação de um mercado livre de cadeias cruzadas para vários SideChains. A abordagem do BitVM é considerada semi-on-chain porque a maioria destes cálculos de validação não acontece na cadeia, mas sim fora da cadeia. No entanto, uma razão significativa para conceber em torno do Taproot do BTC é utilizar o 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 se um dos 'n' validadores for honesto, semelhante ao Optimistic Rollups.
6. Os custos na cadeia da BitVM são elevados, mas pode usar provas de fraude ZK para melhorar a eficiência? A resposta é não, porque a implementação das provas de fraude ZK baseia-se na capacidade de realizar a validação ZKP na cadeia, o que nos leva 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, foi notado que no design CSV, não podemos prevenir completamente a adulteração colusiva. O que podemos fazer é usar criptografia e design de protocolo para manter o dano de conluio malicioso dentro de uma faixa controlável, tornando esse comportamento não rentável.
10. Os prós e contras da validação fora da cadeia são claros. A vantagem é o uso mínimo de recursos na cadeia, com um enorme potencial de expansão. A desvantagem é que é quase impossível alavancar totalmente a segurança do BTC, limitando muito 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 da evolução da expansão

Atualmente, a popular Camada2 no Ethereum, em essência, usa a Camada1 para validar a eficácia computacional da Camada2. Ou seja, os cálculos de estado são empurrados para a Camada2, mas a validação permanece na Camada1. No futuro, podemos igualmente empurrar para baixo os cálculos de validação fora da cadeia, liberando ainda mais o desempenho da atual infraestrutura blockchain.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [espelho]. Todos os direitos de autor pertencem ao autor original [Ben77]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.