Prefácio

A emissão de ativos baseados em BTC sempre foi um tema quente. Desde as primeiras moedas coloridas em 2011 até o recentemente popular protocolo Ordinal, a comunidade BTC tem sido consistentemente capaz de criar novos jogadores e consenso, mas poucos permaneceram por aqui. No entanto, o Lightning Labs revelou planos ambiciosos para desenvolver stablecoins baseados em Taproot Assets. A Tether também anunciou que utilizaria o protocolo RGB para cunhar USDT na camada 1 do Bitcoin.

Isso significa que o outrora famoso OmniLayer (anteriormente Mastercoin) não é mais o maior player no ecossistema BTC. E os protocolos de ativos de validação do lado do cliente (CSV) estão começando a entrar na visão de todos. Esses protocolos não apenas 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 entre si e como se deve navegar e aproveitar as 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 próximo.

Moedas coloridas

O conceito de Moedas Coloridas foi articulado pela primeira vez por Yoni Assia, agora CEO da eToro, em seu artigo seminal “bitcoin 2.X (também conhecido como Bitcoin colorido)“ em 27 de março de 2012. O artigo postulava que a tecnologia subjacente do Bitcoin era tão fundamental e perfeita quanto o HTTP é para a Internet. Portanto, o protocolo de token Colored Coins foi projetado em cima do BTC.

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

Colored Coins é um protocolo desenvolvido para emissão de ativos na blockchain Bitcoin. Ele opera “colorindo” uma fração específica de bitcoins para significar outros ativos. Esses Bitcoins marcados ainda mantêm sua funcionalidade original, mas também representam outro ativo ou valor. A questão urgente, porém, era como essa ideia poderia se materializar na rede Bitcoin.

Em 3 de julho de 2014, a ChromaWay deu um passo significativo ao desenvolver o Protocolo Avançado Baseado em Pedidos de Moedas Coloridas (EPOBC), que simplificou bastante o processo de criação de moedas coloridas para desenvolvedores. Este foi o protocolo inaugural a 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. Questão de fungibilidade e valor mínimo de ligação Ao vincular 1.000 sats na transação genesis para uma moeda colorida, a unidade mínima dessa moeda colorida passa a ser 1 sat. Isso significa que o ativo ou token pode, teoricamente, ser dividido em no máximo 1.000 unidades (mas na prática é menor para evitar ataques de poeira). Por exemplo, o valor mínimo de satoshi já foi definido em 546 SATs e, para ordinais, é ainda mais alto).
2. Desafios de validação Para determinar a autenticidade e propriedade de uma moeda colorida, seu histórico de transações precisa ser rastreado e validado desde a transação de gênese até o UTXO atual. Portanto, carteiras dedicadas, nós completos e até scanners precisam ser desenvolvidos.
3. Risco potencial de censura do mineiro ColoredTransaction possui características distintas, como escrever metadados na saída, o que traz a possibilidade de censura do mineiro.

As Moedas Coloridas são essencialmente um sistema de rastreamento de ativos que usa 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 ativo específico, é necessário fornecer toda a cadeia de transferências desde a origem do ativo. Isso significa que a validação da validade de uma transação pode exigir uma longa cadeia de provas. Para resolver isso, foram feitas propostas como OP_CHECKCOLORVERIFY para ajudar a validar transações de moedas coloridas diretamente no BTC, mas a proposta não foi adotada.

O primeiro ICO em criptografia: Mastercoin

O conceito de Mastercoin foi inicialmente proposto por JR Willett. Em 2012, ele publicou um white paper intitulado “The Second Bitcoin Whitepaper”, que delineou a ideia de criar novos ativos ou tokens sobre o blockchain Bitcoin existente. Este conceito acabou ficando 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 (Oferta Inicial de Moedas), arrecadando com sucesso milhões de dólares. Esta é considerada a primeira ICO da história. Uma das aplicações mais notáveis do Mastercoin é o Tether (USDT), um conhecido stablecoin com garantia fiduciária, que foi inicialmente emitido na Omni Layer.

Na verdade, a ideia do Mastercoin é anterior às Moedas Coloridas. A razão pela qual estamos discutindo isso em segundo lugar é que, em comparação com as Moedas Coloridas, a MasterCoin é uma solução relativamente mais abrangente. MasterCoin estabeleceu uma camada completa de nós, 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 Bitcoin UTXOs para representar outros ativos.

A principal diferença entre os dois é que no blockchain, o Mastercoin registra apenas vários tipos de comportamentos de transação e não armazena informações de ativos relacionadas. Nos nós do Mastercoin, um banco de dados do modelo de estado é mantido pela varredura de blocos Bitcoin, e esse banco de dados reside nos nós fora do blockchain.

Comparado às moedas coloridas, o Mastercoin pode executar uma lógica mais complexa. Além disso, como não registra nem verifica estados no blockchain, suas transações não precisam ser consecutivas (continuamente coloridas).

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

Resumindo:

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

O conceito de validação do lado do cliente

Se quisermos entender o conceito de Validação do Lado do Cliente (CSV), precisamos voltar ao ano seguinte ao surgimento das Moedas Coloridas e da Mastercoin, que é 2013. Naquele ano, Peter Todd, um dos primeiros pesquisadores de Bitcoin e criptografia, lançou um artigo intitulado “Desembaraçando a mineração de criptomoedas: registro de data e hora, prova de publicação e validação”.“ Embora o título não mencione explicitamente a Validação do Lado do Cliente, uma leitura cuidadosa revela que este é um dos primeiros textos a introduzir o conceito.

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

Para seguir o pensamento de Peter Todd, primeiro precisamos entender qual 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 do gasto duplo. Por exemplo, se Alice quiser transferir alguns bitcoins para Bob, embora ela tenha assinado uma transação para transferir para Bob, Bob pode não saber fisicamente que tal transação existe. Portanto, precisamos de um local público para publicar as transações, e todos podem consultar as transações a partir daí.
2. Consenso de ordem: Em sistemas de computador, o tempo físico que normalmente vivenciamos não existe. Em sistemas distribuídos, o tempo costuma ser carimbos de data e hora de Lamport, que não fornecem uma medida para nosso tempo físico, mas ordenam nossas transações.
3. Validação (Opcional): A validação no Bitcoin envolve a verificação das assinaturas e dos valores transferidos nas transações BTC. No entanto, Peter Todd acredita que esta validação não é necessária para construir um sistema de tokens em cima do Bitcoin; é apenas uma opção de otimização.

Neste ponto, você deve se lembrar do OmniLayer, que discutimos anteriormente. O próprio OmniLayer não delega computação e validação de estado ao Bitcoin, mas reutiliza a segurança do Bitcoin. A Colored Coins, por outro lado, confia o rastreamento do estado ao Bitcoin. A existência destes dois sistemas já demonstrou que a validação não tem necessariamente de ocorrer na blockchain.

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

Primeiro, vamos ver o que precisa ser verificado:

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

É fácil perceber que, para ativos emitidos em Bitcoin, cada transação requer a verificação de todo o histórico de transações relevantes para garantir que os insumos referenciados não foram gastos e que o estado está correto. Isto é altamente impraticável. Então, como podemos melhorar isso?

Peter Todd sugere que podemos simplificar este processo mudando o foco da verificação. Em vez de confirmar que a produção 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, esse tipo de verificação pode ser feito de forma mais eficiente porque requer apenas uma pequena porção de dados de cada vez, e 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> -> CTransaction -> <merkle path> -> CTxIn

Mas como podemos armazenar essa árvore de compromissos no blockchain? É aqui que podemos introduzir o conceito de “selo de uso único”.

Selo de uso único

O selo de uso único é um dos conceitos básicos para a compreensão do CSV. É semelhante ao selo físico de uso único usado para proteger contêineres de carga. Um selo de uso único é um objeto único que pode ser fechado precisamente uma vez em uma 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. eu: selo
2. m: mensagem, que é a informação ou transação
3. w: testemunha, alguém ou algo que pode verificar o selo

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

1. Close(l, m) → w: Fecha o selo l na mensagem m, produzindo uma testemunha w.
2. Verify(l, w, m) → bool: Verifica 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 pode encontrar duas mensagens diferentes m1 e m2 de modo que a função Verify retorne verdadeiro para o mesmo selo.

Em termos simples, um Selo de Uso Único garante que um determinado ativo ou dado seja usado ou bloqueado apenas uma vez. No contexto do Bitcoin, isso geralmente significa que um UTXO só pode ser gasto uma vez. Assim, os resultados das transações Bitcoin podem ser vistos como selos de uso único e, quando um resultado é usado como entrada em outra transação, esse selo é “quebrado” ou “usado”.

Para ativos em Bitcoin, o próprio Bitcoin atua como “testemunha” (w) do selo de uso único. Isso ocorre 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 o dobro de 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 um banco de dados, onde armazenamos um compromisso com uma determinada mensagem e mantemos seu status como gasto ou não gasto.

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

1. Armazenamento de dados fora da cadeia: O histórico de transações, propriedade e outros dados relevantes de ativos que usam validação do lado do cliente são armazenados principalmente fora da cadeia. Isso 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 desses dados são registradas na cadeia por meio de compromissos. Esses compromissos permitem que as transações on-chain 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): Embora a maioria dos dados e validação ocorram fora da cadeia, os ativos que usam a validação do lado do cliente ainda podem aproveitar a segurança da cadeia de blocos subjacente (prova de publicação, ordem de transação) por meio de compromissos incorporados na -corrente.
4. Trabalho de validação realizado no lado do cliente: a maior parte do trabalho de validação é realizada no dispositivo do usuário. Isto significa que nem todos os nós da rede precisam 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 ser observado:

Ao transacionar e validar ativos com validação off-chain do lado do cliente, é necessário não apenas apresentar a chave privada que contém o ativo, mas também fornecer uma prova completa do caminho Merkle para o ativo correspondente.

RGB, o pioneiro do CSV

O conceito de RGB foi proposto por Giacomo Zucco, figura conhecida na comunidade, a partir de 2015. Este foi um período em que o Ethereum estava em ascensão, os ICOs (Ofertas Iniciais de Moedas) proliferavam e muitas tentativas foram feitas para criar projetos além do Bitcoin, como Mastercoin e Colored Coins.

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

Além das características mencionadas anteriormente de ativos que usam validação do lado do cliente, a principal diferença com RGB e protocolos de ativos anteriores é a adição de uma VM (Máquina Virtual) de execução para execução de contrato completo de Turing. Para garantir a segurança dos dados do contrato, foram projetados Schema e Interface. O Schema, semelhante ao 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 desses contratos são responsáveis por restringir comportamentos que excedem as expectativas durante a execução da VM. Por exemplo, RGB20 e RGB21 são responsáveis, respectivamente, por impor certas restrições a tokens fungíveis e não fungíveis durante as transações.

O mecanismo de compromisso usado em RGB, Pedersen Hash

Sua vantagem está na capacidade de se comprometer com um valor sem divulgá-lo. Usar Pedersen Hash para construir uma árvore Merkle significa que você pode criar uma árvore Merkle que protege a privacidade e pode ocultar seus valores. Essa estrutura é útil em certos protocolos de preservaçã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 em comparação com Taproot Assets.

Design de máquina virtual para simplicidade RGB → AluVM

O RGB teve como objetivo não apenas implementar um protocolo de ativos validados do lado do cliente, mas também estender a execução de máquinas virtuais completas de Turing e programação de contratos. Inicialmente, a RGB afirmava utilizar uma linguagem de programação chamada Simplicity, que gera uma prova de execução e permite a verificação formal (para evitar bugs) dos contratos nela escritos. Porém, o desenvolvimento desta linguagem não ocorreu como planejado, gerando complicações que acabaram prejudicando todo o protocolo RGB. Eventualmente, o RGB passou a utilizar 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 uso atual do Rust.

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

Os ativos validados do lado do cliente não podem ser continuamente negociados fora da cadeia com segurança porque ainda dependem de L1 para publicação e pedidos de transações. Isso significa que sem uma solução de escalonamento de camada 2, a velocidade de transação ainda será limitada pela velocidade de produção de blocos da testemunha L1. Isto implica que se as transações RGB forem conduzidas diretamente no Bitcoin, sob rigorosos requisitos de segurança, o tempo entre duas transações relacionadas precisaria 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 vários contratos (transações de compromisso) fora da cadeia. Esses contratos garantem que, se qualquer parte violar o acordo, a parte prejudicada poderá submeter o contrato (transação de compromisso) ao BTC para liquidação, recuperar seus fundos e penalizar o infrator. Em outras palavras, a Lightning Network garante a segurança das transações fora da cadeia por meio de protocolo e design teórico de jogos.

A RGB poderia construir sua própria infraestrutura de Lightning Network projetando detalhes de contrato de canal de pagamento adequados para a própria 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 nesta área e a participação de mercado da LND de mais de 90%.

Sidechain Prime do RGB

LNP-BP, o atual mantenedor do protocolo RGB, lançou uma proposta em junho de 2023 pela Maxim para uma solução de escalonamento de ativos validada do lado do cliente chamada Prime. Nele, Maxim criticou as soluções existentes de dimensionamento de sidechain e Lightning Network por serem muito complexas no desenvolvimento. Ele expressou sua convicção de que, 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 poderá ser concluído em apenas um ano.

Prime não foi projetado como um blockchain tradicional. Em vez disso, é uma camada modular de publicação de provas 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: são armazenadas na forma de Partial Merkle Trees (PMTs) e são produzidas e publicadas junto com os cabeçalhos dos blocos.
3. Selos de uso único: Este é um protocolo abstrato de selo de uso único projetado para evitar gastos duplos. Quando implementado no Bitcoin, ele pode ser vinculado a UTXOs, semelhante ao design RGB atual.
4. Protocolo de contrato inteligente: contratos fragmentados para RGB (que podem ser substituídos)

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

Protocolo de ativos CSV baseado em Taproot: Ativos Taproot

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

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

por roasbeef, CTO da Lighting Labs

Também como protocolo de ativos CSV, Taproot Assets possui um design mais conciso em comparação ao RGB. A maior diferença entre Taproot Assets e RGB em termos de escalabilidade do aplicativo está na VM de execução. Taproot Assets usa a mesma VM TaprootScript que o padrão nativo do BTC. Nos últimos anos, muitas das pesquisas para o BTC Nos últimos anos, muitas pesquisas de infraestrutura para o BTC foram baseadas no TapScript, mas devido à lenta atualização do BTC, não pode ser aplicado em um curto período de tempo, por isso é pode-se prever que o Taproot Assets será um campo de testes para essas novas ideias no futuro.

Diferenças entre ativos Taproot e RGB

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

Taproot Assets, devido à implementação de uma árvore de soma, possui alta eficiência de verificação e segurança. Permite que a verificação do estado e as transações sejam realizadas simplesmente com a posse de um comprovante, sem a necessidade de percorrer todo o histórico de transações. Em contraste, a utilização dos compromissos Pedersen pela RGB torna difícil verificar eficazmente a validade dos dados. Como resultado, o RGB exige o rastreamento do histórico de transações de insumos, o que pode se tornar 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 de nós leves, um recurso que anteriormente não estava disponível em protocolos de ativos construídos sobre Bitcoin.

2. VM de execução

Taproot Assets foi desenvolvido em resposta à atualização Taproot da rede Bitcoin. Ele utiliza TaprootScriptVM, que é o mecanismo de execução de script que vem com o Bitcoin após a atualização do Taproot. Além disso, utiliza vPSBT, uma variante do PSBT do Bitcoin, indicando que uma vez desenvolvido o mecanismo de canal relâmpago Taproot Assets, ele pode reutilizar imediatamente toda a infraestrutura atual do LND (Lightning Network Daemon), bem como produtos anteriores do Lightning Labs (LND atualmente detém mais de 90% de participação de mercado na rede relâmpago). Além disso, a recente proposta popular do BitVM é baseada no TaprootScript, o que teoricamente significa que todas essas melhorias poderiam eventualmente beneficiar o Taproot Assets.

No entanto, RGB opera de maneira um pouco diferente. Sua máquina virtual e regras de validação (SCHEMA) fazem parte de um sistema independente, formando um ecossistema um tanto fechado. RGB opera dentro de seu próprio ecossistema, e seu relacionamento com o ecossistema Bitcoin mais amplo não é tão próximo quanto alguns poderiam pensar. Por exemplo, com relação à atualização Taproot, a única interação real do RGB é a codificação de dados de compromisso no blockchain no Witness TapLeaf. Isso ilustra que o RGB e a atualização Taproot estão minimamente conectados.

3. Contratos Inteligentes

Na atual implementação do RGB, os contratos e o VM são fortemente enfatizados. No entanto, na Taproot Assets, não parece haver 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 são sincronizadas com os fragmentos de contrato individuais (UTXO). Além disso, embora os compromissos de Pedersen possam garantir o montante total dos activos, não está claro como outros estados seriam protegidos contra adulterações, uma vez que não houve muita explicação sobre isto.

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

4. Centro de Sincronização

O princípio básico mencionado anteriormente em relação aos ativos verificados no lado do cliente indica que possuir a Prova é tão importante quanto possuir a chave privada. Porém, existe o risco de perder o Comprovante, pois ele fica do lado do cliente. Como isso pode ser resolvido? No Taproot Assets, esse problema pode ser evitado através do uso de um “universo”. Um universo é uma árvore Merkle esparsa publicamente auditável que cobre um ou mais ativos. Ao contrário de uma árvore de ativos Taproot padrão, um universo não é usado para custodiar ativos Taproot. Em vez disso, compromete-se com um subconjunto de um ou mais históricos de ativos.

No sistema RGB, essa função é cumprida pelo Storm, que sincroniza dados de prova fora da cadeia por meio de uma rede ponto a ponto (p2p). No entanto, devido a razões históricas associadas à equipe de desenvolvimento RGB, essas equipes utilizam atualmente formatos de prova incompatíveis. A equipa do ecossistema RGB, DIBA, indicou que irá desenvolver “carbonado” para resolver este problema, mas o seu progresso não é claro.

5. Implementação de Engenharia

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

Uma breve olhada no futuro do escalonamento do BTC

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

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

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

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

Onde 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. Eles não deveriam e não precisam estar associados à própria cadeia. A forma de implementar a verificação levará a diferentes soluções de escalonamento para BTC.

Da perspectiva das implementações baseadas em verificação, temos três direções para escalar:

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

A implementação do OP-ZKP diretamente no TaprootScriptVM daria ao próprio Bitcoin a capacidade de realizar a verificação do ZKP. Isso, juntamente com alguns protocolos de liquidação de design do Covenant, poderia criar uma solução de escalonamento Zk-Rollup que herdaria a segurança do Bitcoin. No entanto, ao contrário da implantação de um contrato de verificação no Ethereum, as atualizações do Bitcoin são inerentemente lentas, e adicionar um código operacional tão especializado e potencialmente necessitado de atualização certamente será um desafio.

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

O design do BitVM garante que ele não se destina à lógica de transação comum. 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 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. Esse processo também gera uma cadeia de confiança de verificação, como a necessidade de apenas um verificador honesto entre 'n' verificadores, conhecido como Optimistic Rollups.

O BitVM incorre em sobrecarga significativa na cadeia, mas será que pode usar provas de fraude ZK para obter ganhos de eficiência? A resposta é não, pois a implementação de provas de fraude ZK depende da capacidade de realizar verificação ZKP on-chain, o que nos leva 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 evitar totalmente o conluio nos designs de CSV. O que podemos fazer é usar criptografia e design de protocolo para manter os danos causados por conluios maliciosos dentro de limites controláveis, tornando tais 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 enormemente os tipos e métodos de transações fora da cadeia que podem ser realizadas. Além disso, a verificação fora da cadeia também implica que os dados sejam mantidos fora da cadeia, geridos pelos próprios utilizadores, o que impõe maiores exigências à segurança do ambiente de execução do software e à estabilidade do software.

Tendência de evolução de escala

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 a computação do estado é empurrada para a Camada 2, mas a verificação ainda é retida na Camada 1. No futuro, poderíamos, de forma semelhante, empurrar a computação de verificaçã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.