Prefácio

Emitir ativos com base no BTC sempre foi um tema quente. Desde as primeiras Moedas Coloridas em 2011 ao recentemente popular protocolo Ordinal, a comunidade BTC tem conseguido consistentemente criar novos jogadores e consenso, mas poucos ficaram por aqui. No entanto, a Lightning Labs revelou planos ambiciosos para desenvolver stablecoins com base em ativos Taproot. O Tether também anunciou que iria utilizar o protocolo RGB para cunhar USDT na camada 1 do Bitcoin.

Isto significa que o outrora famoso OmniLayer (anteriormente Mastercoin) já não é o maior player no ecossistema BTC. E os protocolos de ativos de validação do lado do cliente (CSV) estão a começar a entrar na visão de todos. Estes protocolos não só mantêm a integridade dos protocolos tradicionais de ativos Bitcoin mas também melhoram a escalabilidade. No entanto, uma série de protocolos de ativos dentro do ecossistema Bitcoin, levanta questões pertinentes: Como eles diferem uns dos outros e como se deve navegar e aproveitar oportunidades neste cenário?

Este artigo tem como objetivo orientar os leitores através de uma revisão abrangente dos vários protocolos de ativos que surgiram na história do Bitcoin. Além disso, procura aprofundar as trajetórias potenciais para a evolução dos protocolos de ativos baseados em Bitcoin num futuro previsível.

Moedas Coloridas

O conceito de Moedas Coloridas foi articulado pela primeira vez por Yoni Assia, agora CEO da eToro, no seu artigo seminal “bitcoin 2.X (aka Colored bitcoin)“em 27 de março de 2012. O artigo postuava que a tecnologia subjacente do Bitcoin era tão fundamental e sem falhas como o HTTP é para a internet. Portanto, o protocolo do token Colored Coins foi concebido em cima do BTC.

Yoni Assia previu a criação de economias BTC 2.0 através desta inovação, permitindo a qualquer comunidade gerar múltiplas moedas desta forma. Utilizar a tecnologia subjacente do Bitcoin para liquidação de transações e prevenção de gastos duplos era, na altura, uma ideia pioneira.

O Colored Coins é um protocolo concebido para emitir ativos na cadeia de blocos Bitcoin. Opera “colorindo” uma fração específica de bitcoins para significar outros ativos. Estes Bitcoins marcados continuam a manter a sua funcionalidade original, mas também representam outro ativo ou valor. A questão premente, no entanto, era como esta ideia poderia materializar-se na rede Bitcoin.

Em 3 de julho de 2014, a ChromaWay deu um passo significativo ao desenvolver o Enhanced Colored Coins Order-Based Protocol (EPOBC), que simplificou muito o processo de criação de moedas coloridas para programadores. Este foi o protocolo inaugural para empregar a função OP_RETURN do Bitcoin Script.

O resultado ficou assim:

Tal implementação é muito concisa, mas também traz muitos problemas:

1. Fungibilidade e emissão de valor mínimo de ligação Ao vincular 1000 sats na transação de génese para uma moeda colorida, a unidade mínima dessa moeda colorida torna-se 1 sat. Isto significa que o activo ou token pode teoricamente ser dividido num máximo de 1000 unidades (mas na prática é mais baixo para evitar ataques de poeira. Por exemplo, o valor mínimo de satoshi já foi fixado em 546 SATs e, para Ordinais, é ainda maior).
2. Desafios de validação Para determinar a autenticidade e a propriedade de uma moeda colorida, o seu histórico de transações precisa ser rastreado e validado desde a transação de génese até ao UTXO atual. Portanto, carteiras dedicadas, nós completos e até mesmo um scanner precisam ser desenvolvidos.
3. Potencial risco de censura do mineiro ColorredTransaction tem características distintas, como escrever metadados na saída, isso traz a possibilidade de censura do minerador.

As Moedas Coloridas são essencialmente um sistema de seguimento de ativos que utiliza as regras de validação do Bitcoin para rastrear transferências de ativos. No entanto, para provar que qualquer saída específica (txout) representa um activo específico, tem de fornecer toda a cadeia de transferências a partir da origem do activo. Isto significa que validar a validade de uma transação pode exigir uma longa cadeia de provas. Para resolver isso, propostas como OP_CHECKCOLORVERIFY foram feitas para ajudar a validar as transações da Colored Coin diretamente no BTC, mas a proposta não foi adotada.

A primeira ICO em Cripto: Mastercoin

O conceito de Mastercoin foi inicialmente proposto por J.R. Willett. Em 2012, publicou um whitepaper intitulado “The Second Bitcoin Whitepaper”, que delineava a ideia de criar novos ativos ou tokens em cima da blockchain Bitcoin existente. Este conceito acabou por ser conhecido como “MasterCoin”, que mais tarde foi renomeado para Omni Layer.

Em 2013, o projeto Mastercoin conduziu uma versão inicial do que hoje chamamos de ICO (Initial Coin Offering), angariando com sucesso milhões de dólares. Este é considerado o primeiro ICO da história. Uma das aplicações mais notáveis da Mastercoin é o Tether (USDT), uma conhecida stablecoin fiat colateralizada, que foi inicialmente emitida na Camada Omni.

Na verdade, a ideia da Mastercoin era anterior às Moedas Coloridas. A razão pela qual estamos a discutir em segundo lugar é que, em comparação com as Moedas Coloridas, a MasterCoin é uma solução relativamente mais abrangente. A MasterCoin estabeleceu uma camada de nós completa, oferecendo funcionalidades mais complexas, como contratos inteligentes. Em contraste, as Moedas Coloridas são mais simples e diretas, concentrando-se principalmente em “colorir” ou marcar UTXOs Bitcoin para representar outros ativos.

A principal diferença entre os dois é que na cadeia de blocos, a Mastercoin regista apenas vários tipos de comportamentos de transação e não armazena informações de ativos relacionadas. Nos nós da Mastercoin, uma base de dados do modelo de estado é mantida através da análise de blocos de Bitcoin, e esta base de dados reside nos nós fora da cadeia de blocos.

Em comparação com as Moedas Coloridas, a Mastercoin pode executar uma lógica mais complexa. Além disso, porque não registra nem verifica estados na cadeia de blocos, as suas transações não precisam de ser consecutivas (continuamente coloridas).

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

Em resumo:

A principal diferença entre Mastercoin e Colored Coins é que a Mastercoin não mantém todos os dados necessários para o protocolo na cadeia de blocos. Em vez disso, pega de boleia no sistema de consenso do Bitcoin para gerir a sua própria publicação e encomenda de transações e, em seguida, mantém 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. Este protocolo irá incorporar informações de ativos no tapleaf, permitindo funções como pagamentos condicionais. Ao mesmo tempo, a OmniBolt está a trabalhar na integração do Stark na infraestrutura Lightning Network da Omni Layer.

O Conceito de Validação do Lado do Cliente

Se quisermos compreender o conceito de Validação do Lado do Cliente (CSV), precisamos de voltar ao ano seguinte ao surgimento das Moedas Coloridas e Mastercoin, que é 2013. Nesse ano, Peter Todd, um dos primeiros investigadores de Bitcoin e criptografia, lançou um artigo intitulado “Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation. ” Embora o título não mencione explicitamente a Validação do Lado do Cliente, uma leitura cuidadosa revela que esta é uma das primeiras peças escritas a introduzir o conceito.

Peter Todd tem procurado formas de tornar a operação do Bitcoin mais eficiente. Ele desenvolveu um conceito mais complexo de validação do lado do cliente com base na ideia de carimbos de data-hora. Além disso, introduziu o conceito de “selo de uso único”, que será mencionado mais adiante.

Para seguir o pensamento de Peter Todd, primeiro precisamos perceber que problema o Bitcoin realmente resolve. De acordo com Peter Todd, o Bitcoin aborda três questões:

1. Prova de publicação: A essência da prova de publicação é resolver o problema da dupla despesa. Por exemplo, se Alice quiser transferir alguns bitcoins para o Bob, embora tenha assinado uma transação para transferir para o Bob, Bob pode não saber fisicamente que tal transação existe. Portanto, precisamos de um local público para publicar transações, e todos podem consultar as transações a partir daí.
2. Consenso da ordem: Nos sistemas informáticos, o tempo físico que normalmente experimentamos não existe. Em sistemas distribuídos, o tempo é muitas vezes os timestamps Lamport, que não fornecem uma medida para o nosso tempo físico mas ordenam as nossas transações.
3. Validação (Opcional): A validação em Bitcoin envolve a verificação de assinaturas e os montantes transferidos nas transações BTC. No entanto, Peter Todd acredita que esta validação não é necessária para construir um sistema de token em cima do Bitcoin; é apenas uma opção de otimização.

Neste ponto, talvez se lembre do OmniLayer, que discutimos anteriormente. O OmniLayer em si não delega computação de estado e validação ao Bitcoin, mas reutiliza a segurança do Bitcoin. As Moedas Coloridas, por outro lado, confiam o seguimento do estado à Bitcoin. A existência destes dois sistemas já demonstrou que a validação não tem necessariamente de ocorrer na cadeia de blocos.

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

Primeiro, vamos ver o que precisa de ser verificado:

1. Estado (verificação da lógica da transação)
2. Verifique se as entradas (TxIN) são válidas para evitar gastos duplos.

É fácil notar que, para ativos emitidos em Bitcoin, todas as transações requerem a verificação de todo o histórico de transações relevante para garantir que as entradas referenciadas não foram gastas e o estado está correto. Isto é altamente impraticável. Então, como podemos melhorar isto?

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

A estrutura da árvore de compromissos proposta por Peter Todd é a seguinte:

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

Mas como podemos armazenar essa árvore de compromisso na cadeia de blocos? É aqui que podemos introduzir o conceito de “selo de utilização única”.

Selo de Utilização Única

O selo de uso único é um dos conceitos centrais para a compreensão do CSV. É semelhante ao selo físico de uso único usado para proteger os contentores de carga. Um selo de uso único é um objeto único que pode ser fechado precisamente uma vez numa mensagem. Em termos simples, 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
2. m: mensagem, que é a informação ou transação
3. w: testemunha, alguém ou algo que possa verificar o selo

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

1. Fechar (l, m) → w: Feche o selo l na mensagem m, produzindo uma testemunha W.
2. Verificar (l, w, m) → bool: Verifique se o selo l foi fechado na mensagem m.

A segurança de uma implementação de selo de uso único significa que um invasor não consegue encontrar duas mensagens diferentes m1 e m2 de tal forma que a função Verify retorna true para o mesmo selo.

Em termos simples, um Selo de Utilização Única garante que um determinado activo ou dado só é utilizado ou bloqueado uma vez. No contexto do Bitcoin, isso normalmente significa que um UTXO só pode ser gasto uma vez. Assim, as saídas das transações Bitcoin podem ser vistas como selos de uso único, e quando uma saída é usada como entrada em outra transação, esse selo é “quebrado” ou “usado”.

Para ativos em Bitcoin, o próprio Bitcoin atua como a “testemunha” (w) para o selo de uso único. Isto porque, para verificar uma transação Bitcoin, os nós devem 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 usado, as regras de consenso do Bitcoin e a rede de nós honestos rejeitarão essa transação.

Para simplificar ainda mais:

Um selo de uso único trata qualquer blockchain como uma base de dados, onde armazenamos um compromisso com uma determinada mensagem e mantemos o seu estado como gasto ou não gasto.

Resumindo o acima exposto, os ativos que utilizam a validação do lado do cliente têm as seguintes características:

1. Armazenamento de dados fora da cadeia: O histórico de transações, a propriedade e outros dados relevantes dos ativos que utilizam a validação do lado do cliente são armazenados principalmente fora da cadeia. Isto reduz muito a necessidade de armazenamento de dados em cadeia e ajuda a aumentar a privacidade.
2. Mecanismo de Compromisso: Embora os dados dos ativos sejam armazenados fora da cadeia, as alterações ou transferências destes dados são registadas na cadeia através de compromissos. Estes compromissos permitem que as transações em cadeia façam referência a estados fora da cadeia, garantindo a integridade e a imutabilidade dos dados fora da cadeia.
3. Testemunhas na cadeia (não necessariamente BTC): Mesmo que a maioria dos dados e validação ocorram fora da cadeia, os ativos que usam a validação do lado do cliente ainda podem alavancar a segurança da cadeia de blocos subjacente (prova de publicação, ordenação de transações) através de compromissos incorporados na cadeia.
4. Trabalho de validação feito no lado do cliente: A maior parte do trabalho de validação é feito no dispositivo do utilizador. Isto significa que nem todos os nós da rede precisam de participar na validação de cada transação; apenas as partes envolvidas precisam verificar a validade da transação.

Para aqueles que usam ativos com validação do lado do cliente, há um ponto adicional a observar:

Ao transacionar e validar ativos com validação do lado do cliente fora da cadeia, é necessário não só apresentar a chave privada que detém o activo mas também fornecer uma prova completa do caminho Merkle para o activo correspondente.

RGB, o pioneiro do CSV

O conceito de RGB foi proposto por Giacomo Zucco, uma figura bem conhecida na comunidade, depois de 2015. Este foi um período em que o Ethereum estava em ascensão, as ICOs (Initial Coin Offerings) estavam a proliferar e foram feitas muitas tentativas para criar projetos para além do Bitcoin, como Mastercoin e Moedas Coloridas.

Giacomo Zucco ficou desapontado com estes desenvolvimentos. Ele acreditava que nenhum destes projetos correspondia ao potencial do Bitcoin e que as tentativas anteriores de implementar tokens no Bitcoin eram inadequadas. Durante este tempo, ele encontrou Peter Todd e ficou fascinado com as ideias de Todd sobre a validação do lado do cliente (CSV). Isto levou-o a propor a ideia do RGB.

Para além das características anteriormente mencionadas dos ativos que utilizam a validação do lado do cliente, a principal diferença com os protocolos de activos RGB e anteriores é a adição de uma VM de execução (Máquina Virtual) para a execução completa do contrato. Para garantir a segurança dos dados do contrato, o Esquema e a Interface foram concebidos. O Esquema, semelhante ao da Ethereum, declara o conteúdo e as funções de um contrato, enquanto a Interface é responsável pela implementação de funções específicas, semelhantes às interfaces em linguagens de programação.

Os esquemas destes contratos são responsáveis por restringir comportamentos que excedem as expectativas durante a execução da VM. Por exemplo, o RGB20 e o RGB21 são responsáveis respectivamente pela imposição de certas restrições aos tokens fungíveis e não fungíveis durante as transações.

O mecanismo de compromisso utilizado no RGB, Pedersen Hash

A sua vantagem reside na sua capacidade de comprometer-se com um valor sem o divulgar. Usar o Pedersen Hash para construir uma árvore Merkle significa que pode criar uma árvore Merkle que protege a privacidade que pode esconder os seus valores. Esta estrutura é útil em certos protocolos de preservação da privacidade, tais como alguns projetos de criptomoeda anónimos. No entanto, pode não ser adequado para ativos CSV, que serão mencionados mais adiante em comparação com os Ativos Taproot.

Design de Máquina Virtual para Simplicidade RGB → AluVM

O RGB teve como objetivo não só implementar um protocolo de ativos validado do lado do cliente mas também estender a execução completa da máquina virtual e a programação de contratos da Turing-. Inicialmente, o RGB alegou usar uma linguagem de programação chamada Simplicidade, que gera uma prova de execução e permite a verificação formal (para evitar bugs) de contratos escritos nela. No entanto, o desenvolvimento desta linguagem não correu como planeado, levando a complicações que acabaram por dificultar todo o protocolo RGB. Eventualmente, o RGB começou a usar uma VM chamada AluVM, desenvolvida pela Maxim, com o objetivo de evitar qualquer comportamento indefinido, semelhante ao Simplicity original. Diz-se que o novo AluVM será substituído no futuro por uma linguagem de programação chamada Contractum, afastando-se do seu uso atual de Rust.

Direção de escala da camada 2 RGB: Rede Lightning ou Sidechain?

Os ativos validados do lado do cliente não podem ser negociados continuamente com segurança fora da cadeia porque ainda dependem do L1 para publicação e ordenação de transações. Isto significa que sem uma solução de escalonamento de camada 2, a sua velocidade de transação ainda é limitada pela velocidade de produção do bloco da sua testemunha L1. Isto implica 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 teria de ser de pelo menos dez minutos de intervalo (tempo de bloqueio do BTC), o que é muitas vezes inaceitavelmente lento.

RGB e a Rede Lightning

Em termos simples, a Lightning Network opera fazendo com que as partes de uma transação assinem um monte de contratos (transações de compromisso) fora da cadeia. Estes contratos asseguram que, se alguma das partes violar o acordo, a parte lesada pode submeter o contrato (transação de compromisso) ao BTC para liquidação, recuperar os seus fundos e penalizar o infrator. Por outras palavras, a Lightning Network garante a segurança das transações fora da cadeia através do protocolo e do design teórico do jogo.

O RGB poderia construir a sua própria infra-estrutura da Lightning Network concebendo detalhes do contrato do canal de pagamento adequados para o próprio RGB. No entanto, construir tal infraestrutura não é fácil devido à alta complexidade da Lightning Network, especialmente considerando os anos de trabalho da Lightning Labs neste campo e a quota de mercado da LND de mais de 90%.

Sidechain Prime do RGB

O LNP-BP, o atual mantenedor do protocolo RGB, divulgou uma proposta em junho de 2023 da Maxim para uma solução de escalonamento de ativos validada do lado do cliente chamada Prime. Nele, Maxim criticou as soluções existentes de scaling sidechain e Lightning Network por serem demasiado complexas no desenvolvimento. Expressou a sua convicção de que, para além do Prime, os outros métodos de expansão, incluindo os canais Lightning de vários nós NUCLEUS e as fábricas de canais Ark/Enigma, exigiriam mais de dois anos de desenvolvimento. No entanto, o Prime pode ser concluído em apenas um ano.

O Prime não foi concebido como uma cadeia de blocos tradicional. Em vez disso, é uma camada modular de publicação de prova criada especificamente para validação do lado do cliente. Consiste em quatro componentes principais:

1. Serviço de timestamping: Este serviço pode finalizar uma sequência de transações em apenas 10 segundos.
2. Provas: Estes são armazenados na forma de Parcial Merkle Trees (PMTs) e são produzidos e publicados ao lado de cabeçalhos de bloco.
3. Selos de uso único: Este é um protocolo abstrato de selo de uso único projetado para evitar gastos duplos. Quando implementado no Bitcoin, pode ser vinculado a UTXOs, semelhante ao design RGB atual.
4. Protocolo de Contrato Inteligente: Contratos compartilhados para RGB (que podem ser substituídos)

A partir disso, podemos ver que, para resolver a questão dos tempos de confirmação da transação em RGB, o Prime utiliza um serviço de timestamping para confirmar rapidamente as transações fora da cadeia e empacotá-las com IDs em blocos. Ao mesmo tempo, as provas de transação no Prime podem ser ainda consolidadas através de PMTs e depois ancoradas no BTC de forma semelhante a um checkpoint.

Protocolo de ativos CSV baseado em Taproot: Ativos Taproot

O Taproot Assets é um protocolo de ativos CSV baseado no Taproot, concebido para emitir ativos 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 é a utilização da segurança e estabilidade do Bitcoin juntamente com a velocidade, escalabilidade e baixo custo da Rede Lightning. O protocolo foi concebido e desenvolvido pela roasbeef, o CTO da Lightning Labs. A Roasbeef é provavelmente a única pessoa no planeta que liderou pessoalmente o desenvolvimento tanto de um cliente Bitcoin (BTCD) como de um cliente da Lightning Network (LND), demonstrando 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, porque o hash em si é genérico e pode representar quaisquer dados. Com a atualização Taproot, o Bitcoin ganhou a capacidade de executar contratos inteligentes (TapScript). Com base nisto, a codificação de ativos do Taproot Assets cria essencialmente uma definição de token semelhante ao ERC20 ou ERC721. Assim, o Bitcoin não só adquire a capacidade de definir ativos mas também ganha a capacidade de escrever contratos inteligentes, lançando as bases para uma infraestrutura de contrato inteligente token para o Bitcoin.

A estrutura de codificação do Taproot Assets é a seguinte:

por roasbeef, CTO da Lighting Labs

Também como protocolo de ativos CSV, o Taproot Assets tem um design mais conciso em comparação com o RGB. A maior diferença entre o Taproot Assets e o RGB em termos de escalabilidade da aplicação reside na VM de execução, o Taproot Assets utiliza a mesma VM TaprootScript que o padrão nativo do BTC. Nos últimos anos, muitas das pesquisas para o BTC Nos últimos anos, muita pesquisa de infraestrutura para o BTC foi baseada no TapScript, mas devido à lenta atualização do BTC, não pode ser aplicada num curto período de tempo, pelo que pode ser previsto que o Taproot Assets será um campo de testes para estas novas ideias no futuro.

Diferenças entre Taproot Assets e RGB

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

O Taproot Assets, devido à implementação de uma árvore de somas, tem alta eficiência de verificação e segurança. Permite que a verificação do estado e as transações sejam conduzidas simplesmente por possuir uma prova, sem a necessidade de percorrer todo o histórico de transações. Em contraste, o uso dos compromissos da Pedersen pela RGB torna difícil verificar eficazmente a validade das entradas. Como resultado, o RGB requer rastreio através do histórico de transações de entradas, o que pode tornar-se um fardo significativo à medida que as transações se acumulam ao longo do tempo. O design da árvore de soma de Merkel também permite que o Taproot Assets facilite facilmente a verificação do nó leve, um recurso que anteriormente não estava disponível em protocolos de ativos construídos sobre o Bitcoin.

2. Execução VM

O Taproot Assets foi desenvolvido em resposta à actualização Taproot da rede Bitcoin. Utiliza o TaprootScriptVM, que é o motor de execução de scripts que vem com o Bitcoin após a atualização do Taproot. Além disso, utiliza VPSBT, uma variante do PSBT da Bitcoin, indicando que uma vez desenvolvido o mecanismo de canal relâmpago Taproot Assets, pode reutilizar imediatamente toda a infraestrutura atual do LND (Lightning Network Daemon), bem como os produtos anteriores da Lightning Labs (o LND detém atualmente mais de 90% de quota de mercado na rede relâmpago). Além disso, a recente proposta popular da BitVM baseia-se no TaprootScript, o que teoricamente significa que todas estas melhorias poderão eventualmente beneficiar os Ativos Taproot.

No entanto, o RGB opera de forma um pouco diferente. A sua máquina virtual e as regras de validação (SCHEMA) fazem parte de um sistema independente, formando um ecossistema um tanto fechado. O RGB opera dentro do seu próprio ecossistema, e a sua relação com o ecossistema Bitcoin mais amplo não é tão próxima como alguns podem pensar. Por exemplo, no que diz respeito à atualização Taproot, a única interação real do RGB é a codificação de dados de compromisso na cadeia de blocos no Witness TapLEAF. Isto ilustra que o RGB e a actualização Taproot estão apenas minimamente ligados.

3. Contratos Inteligentes

Na implementação atual do RGB, os contratos e a VM são fortemente enfatizados. No entanto, em Taproot Assets, não parece haver um foco em contratos inteligentes, pelo menos não ainda. A implementação atual do RGB ainda não explicou como as modificações no Estado Global se sincronizam com estilhaços de contrato individuais (UTXO). Além disso, embora os compromissos da Pedersen possam garantir a quantidade total de ativos, não está claro como outros estados estariam protegidos contra adulteração, uma vez que não houve muita explicação sobre isso.

Por outro lado, o Taproot Assets tem um design mais simples, mas atualmente apenas armazena saldos de ativos e não lida com estados mais complexos, tornando prematuras as discussões de contratos inteligentes. No entanto, de acordo com a Lightning Labs, há planos para se concentrar no design de contratos inteligentes para o Taproot Assets no próximo ano.

4. Centro de Sincronização

O princípio básico mencionado anteriormente relativamente aos ativos que são verificados no lado do cliente indica que a posse da Prova é tão importante como a posse da chave privada. No entanto, existe o risco de perder a Prova, uma vez que é mantida do lado do cliente. Como é que isso pode ser resolvido? No Taproot Assets, este problema pode ser evitado através do uso de um “universo”. Um universo é uma árvore Merkle esparsa auditável publicamente que cobre um ou mais ativos. Ao contrário de uma árvore de ativos Taproot padrão, um universo não é usado para custódia de ativos Taproot. Em vez disso, compromete-se com um subconjunto de um ou mais históricos de ativos.

No sistema RGB, esta função é cumprida pelo Storm, que sincroniza dados de prova fora da cadeia através de uma rede ponto a ponto (p2p). No entanto, devido a razões históricas associadas à equipa de desenvolvimento RGB, estas equipas utilizam atualmente formatos de prova incompatíveis. A equipa do ecossistema RGB, DIBA, indicou que vai desenvolver “carbonado“para resolver esta questão, mas o seu progresso não é claro.

5. Implementação de engenharia

Todas as bibliotecas utilizadas pelo Taproot Assets estão bem testadas, uma vez que o Lightning Labs tem o seu próprio cliente Bitcoin (BTCD), cliente Lightning Network (LND) e uma vasta gama de implementações de bibliotecas de carteira. Em contraste, a maioria das bibliotecas utilizadas para a implementação RGB são auto-definidas. Do ponto de vista dos padrões da indústria, a implementação do RGB ainda está em fase experimental.

Um breve olhar sobre o futuro do escalonamento BTC

Continuando a discussão, torna-se evidente que os protocolos de ativos validados pelo cliente ultrapassaram o âmbito dos protocolos tradicionais e estão agora a caminhar para o escalonamento computacional.

Muitas pessoas afirmam que, no futuro, o Bitcoin existirá como 'ouro digital', enquanto outros blockchains criarão ecossistemas de aplicações. No entanto, tenho uma opinião diferente. Como visto em muitas discussões em fóruns Bitcoin, fala-se muito sobre várias alt-coins e a sua expectativa de vida fugaz. O rápido desaparecimento destas moedas alt-coins transformou o capital e o esforço que as rodeiam em bolhas. Já temos o Bitcoin como uma base sólida de consenso; não há necessidade de construir novas soluções de Camada 1 (L1) apenas para protocolos de aplicação. O que devemos fazer é alavancar o Bitcoin, esta infraestrutura robusta, para construir um mundo descentralizado mais a longo prazo.

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

Do ponto de vista do design da aplicação, o Bitcoin escolheu desde cedo uma filosofia centrada não na computação em cadeia mas na verificação (completude de Turing e estado para contratos inteligentes). A essência de uma blockchain é uma máquina de estado replicada. Se o consenso de uma blockchain se concentrar na computação em cadeia, é difícil argumentar que fazer com que todos os nós da rede repitam esses cálculos é uma abordagem razoável ou escalável. Se o foco está na verificação, então validar transações fora da cadeia pode ser a abordagem mais adequada para a escalabilidade do Bitcoin.

Onde é que ocorre a verificação? Isto é crucial.

Para os desenvolvedores que criam protocolos em cima do Bitcoin, como usar o Bitcoin para verificação crítica, ou mesmo para colocar a verificação fora da cadeia, e como projetar esquemas seguros, são questões para os próprios projetistas de protocolo. Não devem nem precisam de estar associados à própria cadeia. Como implementar a verificação levará a diferentes soluções de escalonamento para o BTC.

Do ponto de vista das implementações baseadas em verificação, temos três direções para o dimensionamento:

1.Verificação em cadeia (OP-ZKP)

Implementar o OP-ZKP diretamente no TaprootScriptVM dotaria o próprio Bitcoin da capacidade de realizar a verificação ZKP. Isto, juntamente com alguns protocolos de liquidação de design da Covenant, poderia criar uma solução de escalabilidade Zk-Rollup que herda a segurança do Bitcoin. No entanto, ao contrário da implementação de um contrato de verificação no Ethereum, as actualizações do Bitcoin são inerentemente lentas, e adicionar um código de opinião tão especializado e potencialmente carente de actualização está fadado a ser um desafio.

2.Verificação em semi-on-chain (BitVM)

O design do BitVM garante que não se destina à lógica de transação comum. Robin Linus indicou também 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 dos cálculos de verificação não ocorrerá na cadeia, mas fora da cadeia. A razão significativa para projetar em torno do Taproot do Bitcoin é utilizar o TapscriptVM para verificação computacional quando necessário, herdando teoricamente a segurança do Bitcoin. Este processo também gera uma cadeia de confiança de verificação, tal como precisar apenas de um verificador honesto entre 'n' verificadores, conhecido como Rollups otimistas.

O BitVM incorre em sobrecarga significativa na cadeia, mas pode usar provas de fraude ZK para ganhos de eficiência? A resposta é não, uma vez que a implementação das provas de fraude ZK depende da capacidade de realizar a verificação ZKP em cadeia, levando-nos de volta às dificuldades da abordagem OP-ZKP.

3.Verificação fora da cadeia (Validação do lado do cliente, Lightning Network)

A verificação completa fora da cadeia refere-se aos protocolos de ativos CSV discutidos anteriormente e à Lightning Network. Como visto nas discussões anteriores, não podemos impedir totalmente o conluio em projetos CSV. O que podemos fazer é usar criptografia e design de protocolo para manter os danos causados pelo conluio malicioso dentro de limites controláveis, tornando essas ações não lucrativas.

As vantagens e desvantagens da verificação fora da cadeia são igualmente claras. A vantagem é que utiliza recursos mínimos na cadeia e tem um enorme potencial de escalabilidade. A desvantagem é que é quase impossível herdar totalmente a segurança do Bitcoin, o que limita muito os tipos e métodos de transações fora da cadeia que podem ser conduzidas. Além disso, a verificação fora da cadeia implica também que os dados são mantidos fora da cadeia, geridos pelos próprios utilizadores, o que impõe exigências mais elevadas à segurança do ambiente de execução do software e à estabilidade do software.

Tendência de escalonamento e evolução

Atualmente, as soluções populares da Camada 2 no Ethereum, em termos de paradigma, validam os cálculos da Camada 2 através da Camada 1, o que significa que o cálculo do estado é empurrado para a Camada 2, mas a verificação continua a ser mantida na Camada 1. No futuro, poderemos igualmente empurrar a computação de verificação para fora da cadeia, liberando ainda mais o desempenho da infraestrutura blockchain atual.

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.