Protocolo RGB

O que é RGB

RGB é um protocolo de contrato inteligente escalável e confidencial aplicável ao Bitcoin e à Lightning Network, desenvolvido pela Associação de Padrões LNP/BP. Ele adota os conceitos de propriedade privada e conjunta, oferecendo uma forma de computação distribuída completa de Turing, sem confiança e sem a necessidade de um blockchain, operando como um sistema de contrato inteligente de estado parcial validado pelo cliente.

História do Desenvolvimento do Protocolo RGB

História do protocolo RGB

RGB foi inicialmente concebido por Giacomo Zucco da BHB Network em 2016 como um 'sistema de ativos não baseado em blockchain'. No mesmo ano, Peter Todd introduziu os conceitos de selos de uso único e validação do lado do cliente. Inspirado por essas ideias, o RGB foi proposto em 2018. Em 2019, o desenvolvedor principal Maxim Orlovsky assumiu um papel de liderança no desenvolvimento do código RGB e no design do padrão fundamental. Maxim Orlovsky e Giacomo Zucco fundaram a Associação de Padrões LNP/BPhttps://www.lnp-bp.org) para levar o RGB do conceito à aplicação, com o apoio da Fulgur Ventures, Bitfinex, Fundação Hojo, Pandora Prime e DIBA. Após um extenso desenvolvimento, o RGB lançou sua primeira versão estável, V0.10, em abril de 2023. Em janeiro de 2024, os desenvolvedores principais do RGB anunciaram que a versão V0.11 seria lançada no início do primeiro semestre do ano.

Últimos Desenvolvimentos no Protocolo RGB

As novas funcionalidades do RGB V0.10 foram minuciosamente analisadas em outros relatórios. Embora o V0.11 ainda não tenha sido oficialmente lançado, aqui estão alguns dos últimos desenvolvimentos dos desenvolvedores e da comunidade:

• Próximo suporte para L-BTC

• Atualizações sobre a interoperabilidade e pontes entre cadeias cruzadas entre ativos RGB e ativos Liquid

No entanto, o RGB V0.11 será incompatível com o V0.10, o que acarretará custos significativos de migração para os projetos atuais. Além disso, devido ao lento progresso no desenvolvimento, muitos projetos estão aguardando o lançamento do V0.11.

Filosofia de Design RGB e Princípios de Operação

Os contratos inteligentes RGB utilizam validação do lado do cliente, o que significa que todos os dados são armazenados fora das transações de Bitcoin, ou seja, na blockchain do Bitcoin ou no estado dos canais Lightning. Isso permite que o sistema opere em cima da Lightning Network sem quaisquer alterações na mainnet BTC ou nos protocolos da Lightning Network, estabelecendo as bases para a escalabilidade e privacidade do protocolo.

RGB usa selos de uma vez definidos em Bitcoin UTXOs, fornecendo a qualquer pessoa com um registro do histórico do estado do contrato inteligente a capacidade de verificar sua singularidade. Em outras palavras, o RGB aproveita scripts do Bitcoin para implementar seu modelo de segurança e definir direitos de propriedade e acesso.

RGB é um Grafo Acíclico Direcionado (DAG) de transições de estado, onde os contratos são completamente isolados uns dos outros, e ninguém sabe de sua existência, exceto os proprietários de contrato (ou aqueles para quem o proprietário divulga informações do contrato).

Um Grafo Acíclico Direcionado (DAG) é uma estrutura de grafo especial que pode explicar vividamente sistemas ou relacionamentos complexos. Em um DAG, cada aresta pode ser pensada como uma rua de sentido único em uma cidade, que representa o aspecto "direcionado" do grafo. Suponha que nesta rede de ruas, não importa como você viaje, é impossível retornar ao ponto de partida e formar um ciclo fechado; isso representa a natureza "acíclica" do grafo. Em um DAG, não há sequência de nós que permita que você comece de um nó, viaje por uma série de arestas e retorne ao mesmo nó.

Aplicando esse conceito ao sistema RGB, cada contrato pode ser visto como um nó no gráfico, e as relações entre contratos (como a transferência de propriedade) podem ser vistas como arestas direcionadas. Essa estrutura garante que as relações entre os contratos sejam claras e ordenadas, sem formar loops fechados, ou seja, um contrato não pode afetar diretamente ou indiretamente a si mesmo.

Este design garante que os compromissos na transmissão de estado são únicos e imutáveis, impedindo gastos duplos e alcançando transições de estado eficientes e consistentes.

Mergulhando nos Contratos RGB

Depois de entender os princípios básicos do design arquitetônico do RGB, vamos olhar para a parte do contrato. No mundo atual dos contratos inteligentes, os criadores são obrigados a organizar ou executar o desenvolvimento do código do contrato inteligente por si mesmos. A filosofia de design do RGB considera essa prática indesejável, o que leva a vulnerabilidades de código de contrato mais elevadas e a múltiplos ataques de hackers. Portanto, o RGB tem como objetivo reduzir o risco de vulnerabilidades no desenvolvimento e a necessidade de auditorias, introduzindo o conceito de “Padrões de Esquema”. Os “Padrões de Esquema” são o código real dos contratos inteligentes. Os editores podem usá-los como “modelos de contrato” sem precisar codificar ou auditar código personalizado escrito para eles por algum contratante aleatório.

Escalabilidade flexível e boa interoperabilidade

Os contratos RGB são definidos de forma declarativa, não imperativa. Isso significa que a lógica do contrato não é definida por uma série de comandos ou etapas, mas por um conjunto de regras que descrevem seu comportamento e transições de estado, formando um Grafo Acíclico Direcionado (DAG) de mudanças de estado. A chave para as operações de estado local está no Schema. As operações em contratos RGB são locais, não globais. Cada nó (ou estado) tem suas próprias regras e é apenas responsável pelas suas transições de estado. Isso é diferente dos algoritmos globais em plataformas como o Ethereum, que exigem que cada estado siga o mesmo algoritmo. Essa característica torna o RGB suficientemente flexível e escalável, ao mesmo tempo que oferece boa interoperabilidade.

Criação Simplificada de Contrato Inteligente

Esquema define quais tipos de estados globais e próprios, selos e metadados são permitidos em transições de estado. O RGB usa a linguagem Contractum para escrever Esquemas RGB e AluVM (Máquina Virtual da Unidade Lógica Aritmética), simplificando a escrita de contratos inteligentes RGB. AluVM é baseado em um design de registrador sem acesso aleatório à memória, tornando-o altamente adequado para contratos inteligentes, execução de código remoto, computação distribuída e de borda, fornecendo uma base para vários casos de uso avançados de contratos inteligentes.

Como o RGB garante segurança e privacidade

Do próprio design do RGB:

• Privacidade sem transmissão global: Como mencionado, a validação do lado do cliente da RGB significa que o processo de validação ocorre apenas entre pares diretamente envolvidos, não em toda a rede. Essa abordagem de não transmissão global melhora a privacidade e a resistência à censura porque os detalhes do estado do contrato são visíveis apenas para os participantes relevantes e os mineradores não podem ver os detalhes da transação.

• Privacidade de dados em um ambiente de sandbox: Por outro lado, o RGB armazena todos os dados de operação em um esconderijo. Como o RGB não é baseado em blockchain, o armazenamento não é replicado para outros nós pares. O armazenamento controlado localmente pelos usuários reduz o risco de ataques externos e vazamentos de dados, garantindo a privacidade dos dados. O RGB é uma plataforma de computação onde cada programa (contrato inteligente) é isolado em seu ambiente de sandbox, oferecendo melhor escalabilidade e segurança do que plataformas baseadas em blockchain. No entanto, os dados off-chain também significam que há um risco de perda.

• Além da validação e armazenamento, o sistema de faturamento também garante segurança e privacidade. As operações de contrato em RGB são realizadas através da criação de faturas, que podem conter múltiplos pedidos de operação de contrato. Ao permitir que os usuários especifiquem e verifiquem explicitamente as operações de contrato, a precisão e segurança das operações são melhoradas. Ao mesmo tempo, o sistema de faturamento suporta a transmissão privada de pedidos de operação de contrato entre usuários, aumentando a privacidade das transações. Transições de estado, como transferências de tokens, são executadas através de faturas e comandos específicos.

Da Perspectiva de Interagir com BTC

O design da RGB está altamente ligado aos UTXOs. Nas interações com a mainnet do BTC, os usuários criam contratos fora da cadeia para emitir ativos RGB e alocá-los aos UTXOs do Bitcoin, semelhante à Lightning Network. Em seguida, transferências de ativos, interações de contrato e validações são realizadas fora da cadeia, conforme introduzido acima.

RGB se beneficia dos protocolos de assinatura aprimorados de multisig, baseados em adaptadores, e dos Contratos Bloqueados no Tempo de Ponto (PTLCs) trazidos pelas assinaturas de Schnorr, mas seus benefícios são puramente baseados no Bitcoin (ou seja, indiretos). Não há nada dentro do RGB que exija assinaturas (portanto, Schnorr não faz alterações internas), nem utiliza scripts do Bitcoin (portanto, o novo Tapscript não é útil).

BTC Security Lab, co-founded by ScaleBit, é um laboratório de segurança BTC dedicado que trabalha nos últimos desenvolvimentos do protocolo RGB. Seu objetivo é proteger a segurança do contrato, promovendo conjuntamente o crescimento contínuo e o fortalecimento do protocolo RGB e a construção de infraestrutura do ecossistema BTC.

Visão geral dos Projetos do Ecossistema RGB

BiHelix

• Site: https://www.bihelix.net/

• BiHelix é uma infraestrutura ecossistema Bitcoin otimizada para nós, construída na blockchain nativa do Bitcoin, incorporando o protocolo RGB e a Lightning Network. O objetivo é tornar o desenvolvimento mais fácil, expandir os casos de uso para o Bitcoin e enfrentar os desafios de escalabilidade e incompletude de Turing enfrentados pela blockchain do Bitcoin. BiHelix se esforça para criar um mundo criptográfico descentralizado mais justo para mineradores, validadores, provedores de serviços de nós, exchanges e usuários. Como a primeira infraestrutura construída no protocolo RGB, BiHelix irá desenvolver a próxima geração de cenários de aplicativos Bitcoin em larga escala. O projeto está atualmente em fase de desenvolvimento e ainda não está aberto para interação; fique ligado.

  Recursos do Projeto

• Baixa Limiar de Usuário: Utiliza o protocolo SLR (Security-Lightning-RGB), redesenhando o RGB e a Lightning Network com soluções inovadoras para nós de raio alcançarem pagamentos universais.

• Alta Confiabilidade e Escalabilidade: Emprega uma arquitetura de serviço em nuvem madura, aproveitando totalmente os recursos do rust-lightning para suportar funções de fábrica de canais, gerenciar eficientemente canais e criar canais em massa.

• Proteção de Segurança e Privacidade: Transmissão e armazenamento off-chain de dados de estado, usando provas recursivas de conhecimento zero, entre outras tecnologias, para randomizar pagamentos multipartes e seleção de caminho para proteção de privacidade.

• Amigável ao desenvolvedor: Fornece ferramentas de desenvolvimento abrangentes, incluindo documentação de código aberto, ferramentas, etc., e introduz o mecanismo de consenso social Schema, facilitando para os desenvolvedores construir aplicações.

  Carteira Iris

• Site: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1

• A Carteira IRIS, a primeira carteira Android desenvolvida pela equipe da Bitfinex, é dedicada à integração RGB e ferramentas relacionadas ao RGB, suportando ativos fungíveis e não fungíveis. A Carteira Iris permite operações de ativos RGB desde a emissão até o gasto e recebimento, agrupando todas as funcionalidades em um aplicativo de carteira familiar, enquanto abstrai o máximo possível de detalhes técnicos. Atualmente, é um aplicativo experimental recomendado para pequenas quantias de Bitcoin e ativos de baixo valor.

  DIBA

• Site: https://diba.io/

• DIBA é o primeiro mercado de NFT no Bitcoin usando o Protocolo RGB e a Lightning Network. Seu objetivo é moldar a compreensão dos ativos de arte não custodiados na blockchain do Bitcoin.

  Bitmask

• Website: https://bitmask.app/

• Criado pela DIBA, Bitmask é a primeira carteira NFT no ecossistema RGB, operável em navegadores da web e interagindo com contratos RGB semelhantes ao MetaMask no Ethereum. Atualmente, é frequentemente atualizado, aguardando o lançamento do V0.11.

  Pandora Prime Inc

• Site: https://pandoraprime.ch/

• Localizado no Vale Verify, na Suíça, o Pandora Prime também é membro fundador do LNP/BP. O Pandora Prime é dedicado a pioneirismo em Finanças Bitcoin usando a combinação de contratos inteligentes RGB e a Lightning Network. Eles começam com ativos programáveis no Bitcoin (RGBTC e CHFN), que podem escalar a capacidade de transação para níveis de VISA/MasterCard através da Lightning Network, ao mesmo tempo que fornecem facilidades para a troca fácil desses ativos. Seus produtos incluem MyCitadel (carteira), RGB Explorer (navegador) e Pandora Network, entre outros.

  MyCitadel

• Website: https://mycitadel.io/

• Uma marca da Pandora Prime, MyCitadel é a primeira carteira GUI que suporta RGB, criada pelos desenvolvedores da RGB em 2021. Ela oferece carteiras de desktop multiplataforma e carteiras iOS/iPad. A carteira móvel pode lidar com ativos RGB fungíveis.

  Explorador RGB

• Site: https://rgbex.io/

• Desenvolvido pela Pandora Prime, o RGB Explorer é o primeiro navegador a oferecer registro de ativos RGB e contratos inteligentes. Atualmente, ele suporta RGB 20, RGB 21, RGB 25, exibindo ativos como LNPBP, RGBTC, dCHF e RGBEX.

  Bitlight Labs (anteriormente Cosminmart)

• Website: https://bitlightlabs.com/

• Bitlight Labs desenvolve infraestrutura com base no protocolo RGB, preparando-se para implantar várias aplicações na Lightning Network, incluindo a Carteira Bitlight para utilidade RGB e Bitswap, um criador de mercado automatizado para BitcoinFi na Lightning Network e protocolo RGB.

RGB Memes & NFT

1. PPRGB

   • X: @PepeRgb20

   • PPRGB está atualmente emitido na rede Liquid, aguardando mapeamento para RGB após o lançamento do RGB V0.11 (V0.11 também está desenvolvendo funções de código para interface com a Liquid).

2. Inscrição MRGB

   • A inscrição MRGB é um token baseado na validação de estado de cliente do protocolo RGB e no sistema de contratos inteligentes. Ele opera nas camadas dois e três (off-chain) do ecossistema do Bitcoin e fornecerá código de protocolo subjacente de código aberto, permitindo que todas as cadeias públicas BRC20 usem diretamente esse sistema. Essa inovação traz um potencial significativo para as cadeias públicas BRC20, incluindo a redução do consumo de GAS, aceleração da velocidade de transação e melhoria do desempenho geral. Ao adotar o sistema MRGB, as cadeias públicas BRC20 poderão processar transações de forma mais eficiente e reduzir os custos de transação para os usuários. Ao mesmo tempo, o token de inscrição MRGB também servirá como consumível no processo de transação, aumentando assim a liquidez e escalabilidade do BTC.

3. Selo de Uso Único

   • X: @Single_Use_Seal

   • Seal, é uma coleção de 10k PFP, UDA raro e tokens em RGB20 e RGB21, nomeados após o conceito Single Use Seal de Peter Todd. Atualmente aguardando as carteiras Bitlight e Bitmask atualizarem para a versão v0.11 RGB, após o que serão emitidos nelas.

4. Bitman

   • X: @bitmancity

   • Vai emitir 10k UDA na diba, possivelmente através de uma venda privada + pública, com a missão de "transmitir o espírito do BTC." O projeto tem um propósito louvável e dará wl aos contribuidores do ecossistema BTC, com a maioria dos recursos da venda pública doados para LNP/BP.

BitVM

Por que BitVM?

BitVM (Bitcoin Virtual Machine) introduz um sistema que permite que qualquer computação seja verificada na blockchain do Bitcoin sem comprometer sua segurança ou alterar a rede. Este desenvolvimento abre as portas para computações complexas, como contratos inteligentes Turing-completos, com todas as computações sendo processadas off-chain para reduzir a congestão na blockchain do Bitcoin.

“Em termos simples, BitVM é um modelo computacional capaz de expressar contratos completos de Turing na rede Bitcoin.” Assim como RGB, BitVM não requer modificações nas regras de consenso da rede.

Em 9 de outubro de 2023, Robin Linus, co-fundador da desenvolvedora de blockchain ZeroSync, publicou o whitepaper do BitVM. Comparado ao RGB, o BitVM é bem mais jovem.

Arquitetura de Design da BitVM

Arquitetura

Similar ao Optimistic Rollups e à proposta Merkelize All The Things (MATT), com base em provas de fraude e protocolos de desafio-resposta, não exige alterações nas regras de consenso do Bitcoin. O BitVM demonstra que o Bitcoin é completo em Turing ao codificar provas de fraude dentro de grandes Taptrees.

Design de Circuito Gate

O Compromisso do Valor do Bit é o componente mais básico, permitindo que o comprometedor defina o valor específico de um bit como '0' ou '1'. Qualquer função computável pode ser representada como um circuito booleano, formando compromissos de portas lógicas. Construído através de portas NAND (portas lógicas universais), cada porta tem seu próprio compromisso. Qualquer circuito pode ser expresso combinando compromissos de portas. Cada etapa de execução é comprometida em um Tapleaf e combinada dentro do mesmo endereço Taproot.

O BitVM utiliza a atualização Taproot do Bitcoin criando uma estrutura semelhante a um circuito binário (chamado taptree) para alcançar sua funcionalidade. Dentro desse sistema, as condições de gastos para cada UTXO, representadas por instruções em um Script, formam a unidade básica do programa. Essas instruções geram saídas binárias (0 ou 1) dentro de um endereço Taproot, construindo assim todo o taptree. A saída do taptree pode ser considerada o resultado da execução de um circuito binário, semelhante a um programa executável. A complexidade dos programas que um taptree pode executar depende do número e da complexidade dos endereços Taproot que o compõem. Em resumo, o BitVM percebe a capacidade de executar programas mais complexos na rede Bitcoin traduzindo as instruções do Script do Bitcoin em operações binárias.

Os papéis participantes são duas partes

Atualmente, o modelo é limitado a duas partes e não pode ser expandido para incluir mais participantes. Além disso, para que o BitVM funcione corretamente, é necessário um grande número de pré-assinaturas (cálculos off-chain), tornando o BitVM bastante complexo e potencialmente ineficiente.

Provas de fraude e protocolo de desafio-resposta

Tanto o provador quanto o desafiante depositam uma quantia igual de BTC em uma transação como aposta (como entrada), e a saída desta transação incluirá um circuito lógico. Uma série de transações são pré-assinadas durante a fase de configuração para refutar declarações incorretas. BitVM é comparado aos Optimistic Rollups porque realiza a maior parte da computação fora da cadeia e envia algumas dessas computações para a cadeia para resolver disputas quando surgem.

Rollups otimistas são uma solução de dimensionamento de segunda camada que reduz a carga na camada base, movendo a computação e o armazenamento de dados para fora da cadeia. Em seguida, ele reúne várias transações e as publica na cadeia principal. Os Rollups otimistas assumem que todas as transações são válidas. No entanto, se os participantes da rede perceberem comportamento desonesto, eles podem iniciar uma prova de fraude. Uma prova de fraude é uma evidência de um cálculo incorreto de alguém. Elas são produzidas após uma inspeção.

Computação off-chain

Quase todas as atividades no BitVM são realizadas fora da cadeia. Isso inclui iniciar tarefas de computação, compartilhar dados e verificar reivindicações enviadas. O BitVM normalmente não realiza computações na blockchain do Bitcoin. Computações e verificações são publicadas na cadeia somente quando há uma disputa devido a suspeita de fraude. No entanto, se houver uma disputa, uma pequena parte do processo de disputa de fato é executada na cadeia, apenas o suficiente para determinar qual parte é desonesta.

Com o conhecimento de fundo acima, podemos entender melhor os princípios específicos da interação de duas partes do BitVM.

O modelo de interação de duas partes do BitVM envolve um provador e um verificador. Neste sistema, o provador primeiro cria e envia um contrato inteligente ou programa, em seguida, envia fundos para um endereço raiz mestre controlado em conjunto. Esses fundos são mantidos em um arranjo de multisig 2-de-2. O provador também precisa compartilhar informações suficientes com o verificador para provar que seu programa pode produzir a saída prometida.

A tarefa do verificador é executar o código do provador e verificar se a saída corresponde às expectativas. Se a saída não corresponder, o verificador desafiará o provador. Esse processo de interação de desafio-resposta envolve a troca de dados fora da cadeia e o uso de transações pré-assinadas para verificar a correção da computação.

Se um erro computacional for descoberto, o verificador pode provar publicamente o comportamento desonesto do provador através de uma prova de fraude on-chain. No sistema BitVM, se a resposta do provador for comprovadamente incorreta, eles perderão a aposta e os fundos serão confiscados. Por outro lado, se todas as respostas estiverem corretas, o provador mantém seus fundos. Esse mecanismo de incentivo econômico é projetado para evitar comportamentos desonestos.

Por fim, essa interação garante que a verificação computacional só seja transferida para a blockchain do Bitcoin em caso de disputa, realizando assim a grande maioria dos cálculos fora da cadeia. Esse design mantém a eficiência da rede Bitcoin, ao mesmo tempo que oferece a capacidade de executar programas mais complexos no Bitcoin.

Segurança do BitVM

Do ponto de vista do design arquitetônico, a segurança do BitVM é baseada principalmente nos seguintes aspectos:

Provas de Fraude

Em caso de disputa, os validadores podem desafiar as declarações incorretas do proponente por meio de provas de fraude. Esse mecanismo é semelhante aos Rollups Otimistas e não requer a alteração das regras de consenso do Bitcoin.

Protocolo de Desafio e Resposta

BitVM usa um protocolo de desafio-resposta, onde os proponentes e validadores assinam uma série de transações antecipadamente durante a fase de configuração do protocolo. Essas transações são usadas para resolver problemas quando surge uma disputa.

Computação Off-Chain com Verificação On-Chain

BitVM permite a execução de cálculos complexos fora da cadeia, enquanto a verificação e a resolução ocorrem apenas na cadeia no caso de uma disputa. Esta abordagem reduz o consumo de recursos na cadeia, mantendo a integridade e segurança da cadeia de blocos do Bitcoin.

Mecanismo de Depósito e Penalidade

Se um proponente fizer uma declaração incorreta, os validadores podem confiscar seu depósito. Esse mecanismo garante que os atacantes sempre percam seu depósito por ações incorretas.

Mecanismo de Contrato Bilateral

Esse mecanismo oferece uma melhor privacidade no BitVM e reduz os custos de transação, mas em comparação com o mecanismo multi-party do EVM, sua universalidade é um pouco reduzida.

Protocolo Nostr

Qual é o Protocolo Nostr

Nostr significa "Notas e Outras Coisas Transmitidas por Revezamento," indicando que é um protocolo de transmissão que envolve relés, sugerindo que não é um protocolo de transmissão peer-to-peer (P2P). De acordo com o Código do GitHubatualizar registros, este projeto foi lançado em novembro de 2020. O protocolo tem como objetivo criar o protocolo aberto mais simples para uma rede social global resistente à censura. É um protocolo social descentralizado que permite aos usuários criar, publicar e se inscrever em qualquer tipo de conteúdo sem controle ou intervenção de plataformas centralizadas ou instituições. Nostr se inspira no Bitcoin e na Lightning Network, empregando mecanismos criptográficos e de consenso semelhantes, bem como uma estrutura de dados baseada em eventos conhecida como Rede Nostr.

Componentes do Protocolo Nostr

Par de chaves pública e privada

Um par de chaves pública e privada constitui uma conta Nostr. Ao contrário do sistema tradicional de nome de usuário e senha, as contas Nostr usam um sistema de chave pública e privada semelhante às criptomoedas. Para simplificar, a chave pública pode ser considerada como o nome de usuário e a chave privada como a senha. É importante observar que uma vez que a chave privada é perdida, ela não pode ser redefinida como uma senha. As chaves públicas são prefixadas com npub1 e as chaves privadas com nsec1. É crucial garantir a guarda segura dessas chaves, pois elas não podem ser recuperadas se forem perdidas.

Cliente

Nostr é um protocolo para enviar informações pela internet, exigindo um software cliente para uso. Os clientes podem ser páginas da web, software de desktop ou aplicativos móveis. Os clientes leem informações dos relés e enviam dados recém-gerados para os relés para que outros clientes possam ler. As informações incluem assinaturas para garantir que os dados sejam enviados pelo remetente autêntico. O cliente usa a chave privada para criar assinaturas. Ao usar um cliente de desktop ou móvel pela primeira vez, a chave privada precisa ser armazenada nele. A chave pública pode ser obtida a partir da chave privada. Para clientes da web, não é recomendado salvar a chave privada diretamente neles; em vez disso, é melhor usar um plug-in para salvar a chave privada.

Relé

Relays podem ser compreendidos como os servidores backend do protocolo Nostr. Os clientes Nostr enviam informações para os relays, que podem (ou não) armazenar as informações e transmiti-las para todos os clientes conectados. É importante notar que os relays não são constantes; eles podem mudar significativamente ao longo do tempo. O protocolo Nostr depende dos relays para armazenar e recuperar dados. Se um usuário estiver enfrentando velocidades lentas do cliente, pode ser devido à velocidade lenta do relay conectado, e eles podem considerar adicionar alguns outros relays.

NIPs

NIPs (Nostr Implementação Possibilidades) são padrões usados para regular relés e software cliente compatíveis com Nostr, especificando o que deve, deveria ou poderia ser implementado. “NIP” refere-se a documentos de referência que delineiam como o protocolo Nostr opera. Nostr é um protocolo descentralizado, não monopolizado por nenhuma entidade centralizada (como o Twitter), significando que sua direção de desenvolvimento depende de todos os participantes. Podemos propor e advogar por mudanças e fornecer feedback sobre as ideias dos outros. Como membros ativos da comunidade do protocolo, todos têm uma certa influência na direção de desenvolvimento futuro da rede Nostr. NIPs no código principal foram aprovados e novas ideias podem ser adicionadas por meio de solicitações de pull.

Principais NIPs incluem:

• NIP-04: Criptografia de mensagens, usando o algoritmo secp256k1 para troca de chaves Diffie-Hellman, permitindo criptografia de ponta a ponta.

• NIP-05: Mapeia chaves públicas para nomes de domínio para fácil memorização, como mapear a chave pública do autor para o @NomandJamesdomínio.

• NIP-06: Frases mnemônicas, semelhantes às usadas em carteiras de criptomoedas.

• NIP-13: Prova de Trabalho. Este conceito antecede o Bitcoin e é amplamente utilizado em camadas de consenso POW de blockchain e no protocolo de sussurro do Ethereum. Envolve a conclusão de uma prova de trabalho computacionalmente intensiva antes de enviar uma mensagem, que o servidor de retransmissão receptor verifica. Fornecer essa prova significa gastar energia computacional, elevando o limite para bombardear retransmissões com mensagens indesejadas.

• NIP-22: Carimbos de tempo da mensagem. Informando servidores de retransmissão sobre o momento em que uma mensagem foi criada, permitindo que os relés aceitem seletivamente as mensagens. Os carimbos de tempo podem ser definidos para o passado ou futuro.

• NIP-40: Tempo de expiração. Informando servidores de retransmissão sobre quando uma mensagem expira para que possa ser excluída.

• NIP-57: Links de gorjetas da Lightning Network.

• NIP-65: Lista recomendada de serviços de retransmissão.

Eventos são os únicos Objetoestrutura no Nostr. Cada evento tem um gentilpara indicar o tipo de evento (qual ação o usuário tomou ou que informação eles receberam).

Operação do Protocolo Nostr

O protocolo Nostr opera por meio de relés. Esses relés permitem que os usuários no mesmo relé enviem arquivos Json uns aos outros.

Para ajudar a entender isso, considere um diagrama simplificado:

O diagrama inclui 3 relés e 3 clientes, cada cliente usando uma plataforma diferente.

Neste diagrama:

• Bob pode ver todos os tweets de Alice, mas nenhum de Mary (Bob nem sabe da existência de Mary).

• Alice pode ver todos os tweets de Bob, mas nenhum dos de Mary (Alice também não tem conhecimento da existência de Mary).

• Mary pode ver tweets de ambos Bob e Alice porque ela escreve dados apenas para Relay 3, mas pode ler dados de Relay 2 (que contém os dados de Bob e Alice).

Mergulho profundo nos contratos Nostr

Dado o protocolo Nostr como um protocolo aberto muito leve, ele fornece um conjunto de especificações de protocolo para plataformas de mídia social descentralizadas. Vamos realizar uma análise de código simples do protocolo:

A fundação do protocolo é um servidor WebSocket (conhecido como nostr-relay), que processa e armazena uma estrutura de dados muito simples chamada de Evento. É mostrado da seguinte forma:

{  "id": "<32-bytes sha256 dos dados do evento serializados>",  "pubkey": "<chave pública de 32 bytes codificada em hexadecimal do criador do evento>",  "created_at": "<timestamp unix em segundos>",  "kind": "<inteiro>",  "tags": [    ["e", "<32-bytes hex do id de outro evento>", "<URL de retransmissão recomendada>"],    ["p", "<32-bytes hex da chave>", "<URL de retransmissão recomendada>"],    ... // outros tipos de tags podem ser incluídos posteriormente  ],  "content": "<string arbitrária>",  "sig": "<assinatura de 64 bytes do hash sha256 dos dados do evento serializados, que é o mesmo que o campo 'id'>"}

Os eventos são sempre assinados (usando assinaturas do tipo Schnorr) e contêm dados estruturados que podem ter significados semânticos diferentes. Os XOnlyPubkeys do tipo Schnorr definidos no BIP340 (atualmente usados com o Bitcoin Taproot) são usados como "identidades" em todo o protocolo.

O cliente nostr é um aplicativo que pode se comunicar com o relé nostr e pode usar assinantes para se inscrever em qualquer conjunto de eventos.

Filtros representam o conjunto de todos os eventos Nostr que o cliente está interessado.

Os clientes não precisam se registrar ou criar contas, pois o cliente usa a chave pública do usuário para identificação. Cada vez que o cliente se conecta ao relé, ele envia o filtro de inscrição do usuário e, enquanto estiver conectado, o relé transmitirá os "eventos de interesse" para o cliente.

Os relés podem armazenar em cache as assinaturas dos clientes, mas isso não é obrigatório. Os clientes devem lidar com tudo no “lado do cliente”, enquanto os relés podem ser tão burros quanto uma pedra.

Clientes não conversam entre si. Mas os Relays podem. Isso permite que os relays busquem dados para o cliente que ele não possui e os clientes podem se inscrever em eventos fora do relay ao qual estão conectados.

À primeira vista, isso dá a impressão de que Nostr como um protocolo é inútil (por que não apenas assinar e despejar o JSON bruto e deixar o cliente descobrir?), mas uma análise mais aprofundada revela que o modelo de "servidor burro, cliente inteligente" pode descobrir algumas vantagens significativas no projeto de engenharia de protocolo descentralizado.

Totalmente descentralizado como um recurso chave do Nostr

Nostr serve como a camada de protocolo para aplicações sociais, transferindo Notas e outras Coisas via Relays sem depender de servidores centralizados. Sua total descentralização permite que qualquer aplicativo acesse livremente por meio de uma rede distribuída, fornecendo uma plataforma social aberta e sem permissão. Portanto, Nostr não oferece um produto direto ao consumidor para usuários, mas se concentra em implementar a infraestrutura social necessária no nível do protocolo. A capacidade de produto é fornecida por aplicativos de terceiros, e os usuários de diferentes aplicativos podem interagir socialmente entre si.

A vantagem do Nostr reside na sua oferta de uma rede social verdadeiramente livre e aberta, não afetada e não ameaçada por qualquer poder centralizado ou interesses. Os usuários podem expressar livremente suas opiniões e crenças sem medo de censura, proibições ou remoções de plataforma; os criadores de conteúdo podem livremente definir seus modelos de incentivo sem se preocupar em serem privados de renda ou enfrentar competição injusta. Os usuários do Nostr também podem escolher livremente seus círculos sociais sem medo de manipulação, desinformação ou violação de privacidade.

Nostr difere significativamente das mídias sociais tradicionais e possui as seguintes características e vantagens:

Descentralização: Nostr não depende de nenhum servidor centralizado ou plataforma, mas sim utiliza a rede Bitcoin para a transmissão e armazenamento de informações. Isso garante que os usuários não precisem se preocupar com roubo de dados, censura ou exclusão, e não estejam sujeitos às regras ou políticas de terceiros.

Autonomia: O Nostr permite aos usuários controlarem seus próprios dados e identidade. Os usuários podem livremente escolher quem desejam seguir e confiar, e expressar suas opiniões e ideias sem medo de serem banidos, bloqueados ou rebaixados, e sem sofrer interferência de anúncios ou conteúdo recomendado. A verificabilidade de usuários específicos também facilita a identificação de spam e conteúdo gerado por bots.

Abertura: Nostr é um protocolo aberto no qual qualquer pessoa pode participar e contribuir. Os usuários podem desenvolver e usar diferentes clientes, além de construir e executar seus próprios nodes (servidores que podem encaminhar e armazenar informações da Nostr). Os usuários também podem criar e usar diferentes tipos e tags, que são metadados usados para diferenciar e categorizar informações da Nostr. O processo é simples e flexívelEventoO formato suporta vários tipos de publicação: posts em redes sociais, conteúdo longo, mídia rica, e-commerce, etc. Além disso, a integração do Nostr com a Lightning Network facilitou um novo modelo de negócio mais justo, baseado em valor por valor.

Preocupações de segurança do Protocolo Nostr

Gerenciamento de Chave Privada

O protocolo Nostr utiliza pares de chaves públicas-privadas para contas, exigindo que os usuários gerenciem adequadamente suas chaves privadas. Uma vez perdida, a chave privada não pode ser recuperada. Isso pode representar um desafio para a maioria dos usuários, que podem não ter o conhecimento técnico e a experiência necessária para gerenciar suas chaves privadas com segurança.

Seleção de Relés

No protocolo Nostr, os usuários devem escolher e verificar os relays por conta própria. Escolher um relay não confiável ou malicioso pode resultar no vazamento, adulteração ou exclusão de suas informações.

Disseminação de Informação

No protocolo Nostr, as informações enviadas pelos usuários não se propagam por vários relés. Isso significa que se suas informações não forem recebidas e armazenadas por um número suficiente de relés, elas podem ser perdidas ou não vistas por outros usuários, exacerbando o problema dos silos de informação.

Armazenamento de Informações Discricionárias de Relays

Os relés no protocolo Nostr podem decidir livremente se desejam receber e armazenar as informações dos usuários. Isso pode levar alguns relés a optarem por receber e armazenar apenas informações que considerem valiosas ou alinhadas com seus interesses, enquanto ignoram ou rejeitam outras informações.

Extensões de Protocolo Maliciosas

Embora o protocolo Nostr defina alguns tipos de eventos e funcionalidades básicas, ele também permite que clientes e relays implementem seletivamente recursos adicionais. Isso pode levar à implementação de funcionalidades inseguras ou maliciosas por alguns clientes e relés, afetando a segurança e a privacidade dos usuários.

Manuseio de Informações

Devido à falta de uma camada de consenso no protocolo Nostr, alguns relays não processam mensagens com uma diferença significativa nos carimbos de data e hora e no tempo UNIX, deixando espaço para os clientes explorarem essa discrepância para forjar mensagens.

Visão geral do ecossistema Nostr

Jack Dorsey, co-fundador do Twitter e grande apoiador do protocolo Nostr, doou 14,17 Bitcoins (aproximadamente $245.000) para apoiar seu desenvolvimento em dezembro de 2022. Seu perfil X exibe proeminentemente seu endereço pessoal do Nostr, indicando sua afeição pelo protocolo.

Damus⚡️: Principais aplicações do protocolo Nostr

X：https://twitter.com/damusapp

Damus é um aplicativo social que suporta gorjetas de Bitcoin por meio da Lightning Network, substituindo o comum 'Like' ou thumbs-up por gorjetas. As baixas taxas de transação da Lightning Network tornam a gorjeta praticamente gratuita. Além do Damus, as aplicações do protocolo Nostr incluem a ferramenta de comunicação Anigma, a ferramenta de compartilhamento de texto Sendtr e o jogo de xadrez online Jeste, entre outros.

Principal Parceiro de Mídia do Protocolo Nostr: TGFB

TGFB é uma plataforma de educação cristã Bitcoin destinada a educar e equipar os cristãos para entender o Bitcoin e usá-lo para glorificar a Deus e beneficiar a humanidade. Uma parte significativa de seu conteúdo é dedicada a promover o protocolo Nostr por meio de podcasts hospedados por Jon e Jordan, explorando as implicações do protocolo de uma perspectiva cristã. Espera-se que a combinação do cristianismo, amplamente conhecido nos EUA e globalmente, o ETF de Bitcoin aprovado pela SEC e o protocolo Nostr construído na vasta base de usuários da Lightning Network, promova significativamente a adoção e o suporte do protocolo Nostr.

Protocolos Derivativos Nostr

Ativos Nostr + Taproot

O Protocolo de Ativos Nostr é um protocolo de código aberto que integra ativos Taproot e pagamentos nativos do Bitcoin (denominados em Satoshis) no ecossistema da Nostr, suportando interações com outros protocolos de pagamento, incluindo a Lightning Network e ativos Taproot.

Uma vez que os ativos são introduzidos, eles podem ser enviados e recebidos usando as chaves públicas e privadas do protocolo Nostr, com liquidação e segurança ainda dependentes da Lightning Network. O Protocolo de Ativos Nostr, embora construído na tecnologia Nostr, é um protocolo distinto que facilita funções transacionais básicas através de mensagens Nostr.

O serviço de custódia completo do Protocolo de Ativos Nostr envolve os usuários depositando seu Bitcoin ou outros ativos em uma carteira controlada pelo protocolo e, em seguida, executando instruções de implantação, cunhagem e transferência de tokens por meio de mensagens Nostr.

No entanto, o serviço de custódia total é controverso devido aos potenciais riscos de segurança. Os usuários não podem controlar totalmente seus ativos e, no caso de violação da plataforma ou golpe de saída, podem perder todos os seus ativos.

Além disso, após o seu lançamento em 30 de outubro, o Nostr experimentou uma alta demanda por depósitos de ativos, levando a manutenções frequentes do site e desligamentos, levantando preocupações sobre o histórico da equipe e a confiabilidade do projeto. Em 8 de novembro, o Protocolo de Ativos Nostr respondeu oficialmente a um comentário em chinês em um tweet, com alguns usuários ainda questionando a credibilidade do projeto. A comunidade Nostr manifestou forte oposição ao token associado a este protocolo de extensão.

Inscrição Nostr

Noscription é um protocolo de token experimental baseado em Nostr, permitindo que os usuários criem e negociem tokens semelhantes a brc-20, distintos dos tokens de ativos do Taproot.

Análise Comparativa

Implementação de Protocolo

• BitVM exige capacidades computacionais extremamente altas e atualmente só existe na teoria. Em termos de implementação comercial, RGB tem uma vantagem significativa com inúmeras aplicações já em uso. (A organização técnica por trás do RGB, LNP/BP, tem poucos desenvolvedores e é sem fins lucrativos, o que leva a um progresso de desenvolvimento lento). Nostr, prejudicado pelos gargalos comuns do SocialFi, também falhou em avançar ainda mais o ecossistema de aplicativos de seu protocolo.

  Proteção de Privacidade

• Tanto o RGB quanto o BitVM realizam cálculos off-chain, mas o protocolo RGB garante que terceiros não possam rastrear o histórico de ativos RGB na blockchain. Somente quando um usuário recebe um ativo, ele aprende sua história, uma característica não alcançável pelo BitVM. O protocolo Nostr, sendo um protocolo social, tem um alto grau de incerteza na transmissão de informações, potencialmente levando a vazamentos de informações, bloqueios, perdas e manipulações maliciosas devido a vulnerabilidades.

  Compatibilidade nativa com BTC

• Ambos RGB e BitVM não requerem alterações no protocolo Bitcoin; Nostr é construído na Lightning Network nativa, oferecendo uma boa compatibilidade nativa e uma experiência de desenvolvimento suave.

  Segurança de Protocolo

• O protocolo RGB opera off-chain em um ambiente de sandbox, garantindo a segurança dos dados. Seu sistema de faturamento também garante a segurança dos dados do ponto de vista do design. Em termos de interação com BTC, ele usa um mecanismo semelhante à Lightning Network para emissão de ativos.

• BitVM utiliza um modelo Rollup, executando dados off-chain também. As características da máquina virtual, combinadas com provas de fraude e um modelo de desafio-resposta, garantem a segurança do BitVM.

• Nostr usa um modelo de relé, onde o design engenhoso de transmissão de informações entre relés e algoritmos de criptografia garante a segurança das informações dentro do protocolo Nostr.

Na indústria Web3, não havia um laboratório especificamente focado na segurança do ecossistema Bitcoin até a criação do BTC Security Lab, que preenche essa lacuna ao fornecer suporte de segurança profissional e pesquisa para o ecossistema Bitcoin. ScaleBit e BiHelix visam liderar a corrida na segurança do ecossistema Bitcoin, estabelecendo padrões de segurança para a indústria e promovendo o desenvolvimento saudável do ecossistema.

Ecossistema e Comercialização

• Como protocolo social, Nostr supera tanto BitVM quanto RGB em base de usuários e popularidade de tráfego, tornando sua expansão de protocolo de ecossistema e comercialização de aplicativos mais abrangentes do que os outros dois.

• O protocolo RGB existe há algum tempo, com muitos projetos aguardando atualmente o lançamento do RGB V0.11.

• BitVM lançou seu whitepaper há apenas alguns meses e seu ecossistema ainda está em desenvolvimento.

O futuro destes três protocolos espera-se que dê origem a inúmeras Dapps nos domínios do SocialFi, GameFi e DeFi, trazendo uma nova onda de popularidade ao ecossistema BTC.

Agradecimentos especiais a Ausdin.eth, 0xLayman, Echo, Venus por suas contribuições para este relatório.

Aviso legal:

1. Este artigo é reproduzido a partir de[chaincatcher]. Todos os direitos autorais pertencem ao autor original [Zhejiang Chain Association, BiHelix, ScaleBit & Laboratório de Segurança BTC]. Se houver objeções a esta reprodução, por favor contate o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas 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 Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.