RGB é um protocolo de contrato inteligente escalável e confidencial aplicável ao Bitcoin e à Lightning Network, desenvolvido pela LNP/BP Standards Association. Ele adota os conceitos de propriedade privada e conjunta, oferecendo uma forma de computação distribuída completa de Turing, sem confiança, sem a necessidade de uma blockchain, operando como um sistema de contrato inteligente de estado parcial validado pelo cliente.
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, RGB foi proposto em 2018. Em 2019, o desenvolvedor principal Maxim Orlovsky assumiu um papel de liderança no desenvolvimento de código RGB e no design de padrões fundamentais. 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 analisadas minuciosamente em outros relatórios. Embora o V0.11 ainda não tenha sido oficialmente lançado, aqui estão alguns dos últimos desenvolvimentos dos programadores e da comunidade:
Suporte futuro para L-BTC
Atualizações sobre a interoperabilidade e as pontes entre ativos RGB e ativos Liquid
No entanto, o RGB V0.11 será incompatível com o V0.10, o que levará a custos significativos de migração para os projetos atuais. Além disso, devido ao lento progresso de desenvolvimento, muitos projetos estão atualmente à espera do lançamento do V0.11.
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 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 uso único definidos em UTXOs do Bitcoin, fornecendo a qualquer pessoa com um registro do histórico de 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 estão completamente isolados uns dos outros, e ninguém sabe da sua existência exceto os proprietários dos contratos (ou aqueles a 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. Num DAG, cada aresta pode ser vista como uma rua de sentido único numa cidade, o que representa o aspeto "direcionado" do grafo. Suponha que nesta rede de ruas, não importa como viaje, é impossível regressar ao ponto de partida e formar um ciclo fechado; isto representa a natureza "acíclica" do grafo. Num DAG, não existe uma sequência de nós que permita começar a partir de um nó, percorrer uma série de arestas e regressar ao mesmo nó.
Aplicando este 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. Esta estrutura garante que as relações entre contratos sejam claras e ordenadas, sem formar loops fechados, o que significa que um contrato não pode afetar-se diretamente ou indiretamente.
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.
Depois de entender os princípios básicos do projeto arquitetônico da RGB, vejamos 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 conta própria. A filosofia de design da RGB considera esta prática indesejável, levando a maiores vulnerabilidades de código de contrato e múltiplos ataques de hackers. Portanto, o RGB visa reduzir o risco de vulnerabilidades no desenvolvimento e a necessidade de auditorias, introduzindo o conceito de "Padrões de Esquema". "Padrões de esquema" são o código real dos contratos inteligentes. Os editores podem usá-los como "modelos de contrato" sem a necessidade de codificar ou auditar o código personalizado escrito para eles por algum contratante aleatório.
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 o seu comportamento e transições de estado, formando um Grafo Acíclico Direcionado (DAG) de mudanças de estado. A chave das operações de estado local está no Schema. As operações nos contratos RGB são locais, não globais. Cada nó (ou estado) tem as suas próprias regras e é apenas responsável pelas suas transições de estado. Isso é diferente de algoritmos globais em plataformas como 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 fornece uma boa interoperabilidade.
O esquema define quais tipos de estados globais e possuídos, selos e metadados são permitidos em transições de estado. RGB usa a linguagem Contractum para escrever Esquemas RGB e AluVM (Máquina Virtual de Unidade Lógica Aritmética), simplificando a escrita de contratos inteligentes RGB. AluVM é baseado em um projeto 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.
Do próprio design do RGB:
Privacidade sem transmissão global: Como mencionado, a validação do lado do cliente do RGB significa que o processo de validação ocorre apenas entre pares diretamente envolvidos, não em toda a rede. Esta abordagem de não transmissão global aumenta 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 mineiros não podem ver os detalhes da transação.
Privacidade de dados num ambiente de sandbox: Por outro lado, o RGB armazena todos os dados de operação num esconderijo. Uma vez que o RGB não é baseado em blockchain, o armazenamento não é replicado para outros nós pares. O armazenamento controlado localmente pelos utilizadores reduz o risco de ataques externos e fugas de dados, garantindo a privacidade dos dados. O RGB é uma plataforma de computação onde cada programa ("contrato inteligente") está isolado no seu ambiente de sandbox, oferecendo melhor escalabilidade e segurança do que as plataformas baseadas em blockchain. No entanto, os dados fora da cadeia também significam que existe um risco de perda.
Além da validação e armazenamento, o sistema de faturação também garante segurança e privacidade. As operações de contrato na 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 utilizadores 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 faturação suporta a transmissão privada de pedidos de operação de contrato entre utilizadores, melhorando a privacidade das transações. As transições de estado, como transferências de tokens, são executadas através de faturas e comandos específicos.
O design da RGB está altamente ligado aos UTXOs. Em interações com a mainnet BTC, os usuários criam contratos off-chain para emitir ativos RGB e alocá-los aos UTXOs do Bitcoin, semelhante à Lightning Network. Em seguida, as transferências de ativos, interações de contratos e validações são realizadas off-chain, como introduzido acima.
RGB beneficia dos protocolos de assinatura melhorados multisig, baseados em adaptadores e Contratos Bloqueados no Tempo (PTLCs) trazidos pelas assinaturas 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 nenhuma alteração interna), nem utiliza scripts do Bitcoin (portanto, o novo Tapscript não é útil).
O Laboratório de Segurança BTC, co-fundado pela ScaleBit, é um laboratório de segurança BTC dedicado que trabalha nos últimos desenvolvimentos do protocolo RGB. O seu objetivo é proteger a segurança dos contratos, promovendo em conjunto o crescimento contínuo e o fortalecimento do protocolo RGB e a construção da infraestrutura do ecossistema BTC.
BiHelix
Website: https://www.bihelix.net/
BiHelix é uma infraestrutura de 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 do 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ó, 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 aplicação em grande escala do Bitcoin. O projeto está atualmente em fase de desenvolvimento e ainda não está aberto para interação; fique atento.
Recursos do Projeto
Limiar de utilizador baixo : Utiliza o protocolo SLR (Security-Lightning-RGB), reembalando RGB e a Lightning Network com soluções inovadoras para os nós de relâmpago atingirem pagamento universal.
Alta Confiabilidade e Escalabilidade: Utiliza uma arquitetura madura de serviços em nuvem, aproveitando totalmente as características 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 multipartidários e seleção de caminho para proteção de privacidade.
Amigável para desenvolvedores: Fornece ferramentas de desenvolvimento abrangentes, incluindo documentação de código aberto, ferramentas, etc., e introduz o mecanismo de consenso social Schema, tornando mais fácil para os desenvolvedores construir aplicações.
Carteira Iris
Website: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1
A Carteira IRIS, a primeira carteira para Android desenvolvida pela equipa Bitfinex, é dedicada à integração RGB e ferramentas relacionadas com RGB, suportando ativos fungíveis e não-fungíveis. A Carteira Iris permite operações de ativos RGB desde a emissão até à despesa e receção, embalando todas as funcionalidades numa aplicação de carteira familiar, abstraindo o máximo possível os detalhes técnicos. Atualmente, é uma aplicação experimental recomendada para pequenas quantias de Bitcoin e ativos de baixo valor.
DIBA
Website: https://diba.io/
DIBA é o primeiro mercado NFT no Bitcoin usando o Protocolo RGB e a Lightning Network. O seu objetivo é moldar a compreensão de ativos artísticos não custodiados na blockchain do Bitcoin.
Bitmask
Website: https://bitmask.app/
Criado pela DIBA, o 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 da V0.11.
Pandora Prime Inc
Website: https://pandoraprime.ch/
Localizada no Vale Verify, Suíça, a Pandora Prime é também membro fundador da LNP/BP. A Pandora Prime dedica-se a pioneirismo em Finanças Bitcoin usando a combinação de contratos inteligentes RGB e a Lightning Network. Começam com ativos programáveis em Bitcoin (RGBTC e CHFN), que podem aumentar a capacidade de transação para os níveis da VISA/MasterCard através da Lightning Network, ao mesmo tempo que fornecem instalações para a troca fácil desses ativos. Os 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. Oferece carteiras de desktop multiplataforma e carteiras iOS/iPad. A carteira móvel pode lidar com ativos RGB fungíveis.
Explorador RGB
Website: https://rgbex.io/
Desenvolvido pela Pandora Prime, o RGB Explorer é o primeiro navegador a oferecer registo de ativos RGB e contratos inteligentes. Atualmente, suporta RGB 20, RGB 21, RGB 25, exibindo ativos como LNPBP, RGBTC, dCHF e RGBEX.
Bitlight Labs (anteriormente Cosminmart)
Website: https://bitlightlabs.com/
A Bitlight Labs desenvolve infraestruturas baseadas no protocolo RGB, preparando-se para implementar 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.
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 interagir com a Liquid).
Inscrição MRGB
Selo de Uso Único
Seal, é uma coleção de 10k PFP, UDA raro e tokens em RGB20 e RGB21, nomeados após o conceito de Selo de Uso Único de Peter Todd. Atualmente à espera das carteiras Bitlight e Bitmask para atualizarem para a versão v0.11 RGB, após o que serão emitidos nelas.
Bitman
X: @bitmancity
Irá 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á privilégios àqueles que contribuíram para o ecossistema BTC, com a maioria das receitas da venda pública doadas para LNP/BP.
BitVM (Máquina Virtual Bitcoin) introduz um sistema que permite que qualquer cálculo seja verificado na blockchain do Bitcoin sem comprometer sua segurança ou alterar a rede. Este desenvolvimento abre as portas para cálculos complexos, como contratos inteligentes completos de Turing, com todos os cálculos sendo processados fora da cadeia 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. Tal como o RGB, o 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 é muito mais jovem.
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. BitVM demonstra que o Bitcoin é Turing-completo na codificação de provas de fraude dentro de grandes Taptrees.
Design de Circuito Gate
O Compromisso de Valor de 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 passo de execução é comprometido em um Tapleaf e combinado dentro do mesmo endereço Taproot.
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 deste sistema, as condições de gasto para cada UTXO, representadas por instruções em um Script, formam a unidade básica do programa. Estas instruções geram saídas binárias (0 ou 1) dentro de um endereço Taproot, construindo assim todo o taptree. O resultado do taptree pode ser considerado 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 realiza 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 está limitado a duas partes e não pode ser expandido para incluir mais participantes. Além disso, para o BitVM funcionar 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 quantidade igual de BTC em uma transação como aposta (como entrada), e o resultado dessa transação incluirá um circuito lógico. Uma série de transações é pré-assinada durante a fase de configuração para refutar declarações incorretas. BitVM é comparado aos Rollups otimistas porque realiza a maior parte da computação fora da cadeia e submete algumas dessas computações na cadeia para resolver disputas quando surgem.
Os Rollups Otimistas são uma solução de escalonamento de segunda camada que reduz a carga na camada base ao mover a computação e o armazenamento de dados fora da cadeia. Em seguida, agrupa várias transações e publica-as na cadeia principal. Os Rollups Otimistas pressupõem que todas as transações são válidas. No entanto, se os participantes da rede notarem comportamento desonesto, podem iniciar uma prova de fraude. Uma prova de fraude é evidência de um cálculo incorreto de alguém. São produzidos após uma inspeção.
Computação fora da cadeia
Quase todas as atividades no BitVM são realizadas off-chain. 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. As computações e verificações são publicadas on-chain apenas em caso de disputa devido a suspeita de fraude. No entanto, se houver uma disputa, uma pequena parte do processo de disputa é realmente executada on-chain, apenas o suficiente para determinar qual parte é desonesta.
Com o conhecimento de fundo acima, podemos compreender 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, depois envia fundos para um endereço raiz mestre controlado em conjunto. Estes fundos são mantidos em um acordo de multisignatura 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. Este processo de interação de desafio-resposta envolve a troca de dados off-chain e o uso de transações pré-assinadas para verificar a correção da computação.
Se for descoberto um erro computacional, 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 provada como incorreta, eles perderão a aposta e os fundos. Pelo contrário, se todas as respostas estiverem corretas, o provador mantém os seus fundos. Este mecanismo de incentivo económico é projetado para prevenir comportamentos desonestos.
Em última análise, essa interação garante que a verificação computacional só é transferida para a blockchain do Bitcoin em caso de disputa, realizando assim a grande maioria das computações fora da cadeia. Este design mantém a eficiência da rede Bitcoin, proporcionando 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 baseia-se principalmente nos seguintes aspectos:
Provas de Fraude
No caso de uma disputa, os validadores podem desafiar as declarações incorretas do proponente através de provas de fraude. Este mecanismo é semelhante aos Rollups Otimistas e não requer a alteração das regras de consenso do Bitcoin.
Protocolo de Desafio-Resposta
O BitVM utiliza um protocolo de desafio-resposta, no qual 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
O BitVM permite a execução de cálculos complexos fora da cadeia, enquanto a verificação e resolução apenas ocorrem 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 Penalização
Se um proponente fizer uma declaração incorreta, os validadores podem confiscar o seu depósito. Este mecanismo garante que os atacantes sempre perdem o seu depósito por ações incorretas.
Mecanismo de Contrato Bilateral
Este mecanismo proporciona uma melhor privacidade no BitVM e reduz os custos de transação, mas, em comparação com o mecanismo multi-party do EVM, a sua universalidade é um pouco reduzida.
Qual é o Protocolo Nostr
Nostr significa "Notas e Outras Coisas Transmitidas por Relés," 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 visa 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 subscrever qualquer tipo de conteúdo sem controle ou intervenção de plataformas ou instituições centralizadas. Nostr se inspira no Bitcoin e na Lightning Network, empregando mecanismos criptográficos e de consenso similares, bem como uma estrutura de dados baseada em eventos conhecida como a Rede Nostr.
Par de Chave 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 a criptomoedas. Para simplificar, a chave pública pode ser considerada como o nome de usuário e a chave privada como a senha. É importante notar que, uma vez perdida a chave privada, esta 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 segurança dessas chaves, pois 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 lêem informações dos relés e enviam dados recém-gerados para os relés para outros clientes lerem. 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 diretamente a chave privada neles; em vez disso, é melhor usar um plugin para salvar a chave privada.
Relé
Relays podem ser entendidos como os servidores de 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 a ter velocidades lentas de cliente, pode dever-se à velocidade lenta do relay conectado, e eles podem considerar adicionar alguns outros relays.
NIPs
NIPs (Nostr Implementation Possibilities) são padrões usados para regular relés e software de 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 de outras pessoas. Como membros ativos da comunidade do protocolo, todos têm uma certa influência na direção futura do desenvolvimento da rede Nostr. Os NIPs no código-base principal foram aprovados e novas ideias podem ser adicionadas através de solicitações de extração.
As principais NIPs incluem:
NIP-04: Encriptação de mensagens, utilizando o algoritmo secp256k1 para troca de chaves Diffie-Hellman, permitindo a encriptação de ponta a ponta.
NIP-05: Mapeia chaves públicas para nomes de domínio para fácil recordaçã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 de POW blockchain e no protocolo de sussurro do Ethereum. Envolve concluir uma prova de trabalho computacionalmente intensiva antes de enviar uma mensagem, que o servidor de retransmissão receptor verifica. Fornecer esta prova significa gastar energia computacional, elevando o limiar para o envio de relés com mensagens lixo.
NIP-22: Carimbos de hora das mensagens. Informar aos servidores de retransmissão a hora em que uma mensagem foi criada, permitindo que os relés aceitem seletivamente as mensagens. Os carimbos de hora podem ser configurados para o passado ou futuro.
NIP-40: Tempo de expiração. Informar os servidores de retransmissão de quando uma mensagem expira para que possa ser deletada.
NIP-57: Links de dicas da Lightning Network.
NIP-65: Lista recomendada de serviços de retransmissão.
Eventos são os únicos Objeto
estrutura em Nostr. Cada evento tem um tipo
para indicar o tipo de evento (que ação o usuário realizou ou que informação recebeu).
O protocolo Nostr opera através de retransmissores. Estes retransmissores permitem que os utilizadores no mesmo retransmissor enviem ficheiros Json uns aos outros.
Para ajudar a entender isso, considere um diagrama simplificado:
O diagrama inclui 3 relés e 3 clientes, cada cliente utilizando uma plataforma diferente.
Neste diagrama:
Bob pode ver todos os tweets de Alice, mas nenhum dos de Mary (Bob nem sequer 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 tanto de Bob quanto de 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).
Dado o protocolo Nostr como um protocolo aberto muito leve, 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 base 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 serializado>", "pubkey": "<32 bytes chave pública em formato hexadecimal do criador do evento>", "created_at": "<carimbo de data/hora Unix em segundos>", "kind": "<inteiro>", "tags": [ ["e", "<32 bytes hexadecimal do id de outro evento>", "<URL de retransmissão recomendada>"], ["p", "<32 bytes hexadecimal da chave>", "<URL de retransmissão recomendada>"], ... // outros tipos de tags podem ser incluídos posteriormente ], "content": "<cadeia de caracteres arbitrária>", "sig": "<assinatura de 64 bytes do hash sha256 dos dados do evento serializado, 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 diferentes significados semânticos. 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 é uma aplicação que pode comunicar com o nostr-relay e pode usar subscritores para subscrever a qualquer conjunto de eventos.
Os filtros representam o conjunto de todos os eventos Nostr em que o cliente está interessado.
Os clientes não precisam de se registar ou criar contas, uma vez que o cliente utiliza a chave pública do utilizador para identificação. Cada vez que o cliente se conecta ao relay, ele submete o filtro de subscrição do utilizador e, enquanto estiver conectado, o relay transmitirá os "eventos de interesse" para o cliente.
Os relés podem armazenar em cache as subscrições 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.
Os clientes não falam uns com os outros. Mas os Relays podem. Isso permite que os relays busquem dados para o cliente que ele não tem e os clientes podem subscrever eventos fora do relay ao qual estão conectados.
À primeira vista, isso dá a impressão de que Nostr como 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 'servidor burro, cliente inteligente' pode descobrir algumas vantagens significativas na engenharia do design de protocolo descentralizado.
A Nostr serve como a camada de protocolo para aplicações sociais, transferindo Notas e outros Materiais através de Relays sem depender de quaisquer servidores centralizados. Sua completa descentralização permite que qualquer aplicação aceda livremente através de uma rede distribuída, fornecendo uma plataforma social aberta e sem permissões. Portanto, a Nostr não oferece um produto direto ao consumidor para os utilizadores, mas concentra-se em implementar a infraestrutura social necessária ao nível do protocolo. A capacidade de produto é fornecida por aplicações de terceiros, e os utilizadores de diferentes aplicações podem interagir socialmente entre si.
A vantagem do Nostr reside na sua disponibilização de uma rede social verdadeiramente livre e aberta, não afetada e não ameaçada por qualquer poder centralizado ou interesses. Os utilizadores podem expressar livremente as suas opiniões e crenças sem medo de censura, proibições ou desplataformações; os criadores de conteúdo podem definir livremente os seus modelos de incentivo sem se preocuparem em serem privados de rendimentos ou enfrentarem competição desleal. Os utilizadores do Nostr também podem escolher livremente os seus círculos sociais sem receio de manipulação, desinformação ou violação de privacidade.
Nostr difere significativamente das redes sociais tradicionais e tem as seguintes características e vantagens:
Descentralização: A Nostr não depende de servidores ou plataformas centralizadas, mas sim utiliza a rede Bitcoin para 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: A Nostr permite aos utilizadores controlar os seus próprios dados e identidade. Os utilizadores podem escolher livremente quem querem seguir e em quem confiar, e expressar as suas opiniões e ideias sem medo de serem banidos, bloqueados ou rebaixados, e sem sofrer interferências de publicidade ou de conteúdo recomendado. A verificabilidade de utilizadores específicos também torna mais fácil identificar spam e conteúdo gerado por bots.
Abertura: Nostr é um protocolo aberto em que qualquer pessoa pode participar e contribuir. Os usuários podem desenvolver e usar diferentes clientes, bem como construir e executar seus próprios nós (servidores que podem encaminhar e armazenar informações do 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 do Nostr. O sistema é simples e flexível Evento
O formato suporta vários tipos de publicação: posts em redes sociais, conteúdo longo, mídia rica, comércio eletrônico, etc. Além disso, a integração da Nostr com a Lightning Network facilitou um novo modelo de negócio mais justo, baseado no valor por valor.
Gestão de Chave Privada
O protocolo Nostr utiliza pares de chaves públicas-privadas para contas, exigindo que os utilizadores gerenciem adequadamente as suas chaves privadas. Uma vez perdida, a chave privada não pode ser recuperada. Isto pode representar um desafio para a maioria dos utilizadores, que podem não ter o conhecimento técnico e experiência necessários para gerir as chaves privadas de forma segura.
Seleção de Revezamento
No protocolo Nostr, os utilizadores devem escolher e verificar os relés por conta própria. Escolher um relé não confiável ou malicioso poderia resultar no vazamento, manipulação ou exclusão das suas informações.
Divulgação de Informações
No protocolo Nostr, a informação enviada pelos utilizadores não se propaga por vários relés. Isto significa que se a sua informação não for recebida e armazenada por um número suficiente de relés, poderá ser perdida ou não vista por outros utilizadores, agravando o problema dos silos de informação.
Armazenamento de Informações Discricionárias dos Relays
Os relés no protocolo Nostr podem decidir livremente se querem receber e armazenar as informações dos utilizadores. Isso pode levar alguns relés a optar por receber e armazenar apenas as informações que consideram valiosas ou que estão alinhadas com os seus interesses, enquanto ignoram ou rejeitam outras informações.
Extensões de Protocolo Maliciosas
Embora o protocolo Nostr defina alguns tipos básicos de eventos e funcionalidades, também permite que os clientes e relés implementem seletivamente funcionalidades adicionais. Isso poderia levar à implementação de funcionalidades inseguras ou maliciosas por parte de alguns clientes e relés, afetando a segurança e privacidade dos utilizadores.
Tratamento de Informações
Devido à falta de uma camada de consenso no protocolo Nostr, alguns relés 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 falsificar mensagens.
Visão geral do ecossistema Nostr
Jack Dorsey, co-fundador do Twitter e grande apoiante do protocolo Nostr, doou 14,17 Bitcoins (aproximadamente $245,000) para apoiar o seu desenvolvimento em dezembro de 2022. O seu perfil X exibe proeminentemente o seu endereço pessoal do Nostr, indicando a sua afinidade com o protocolo.
Damus⚡️: Principais aplicações do protocolo Nostr
X:https://twitter.com/damusapp
Damus é um aplicativo social que suporta gorjetas de Bitcoin via a Lightning Network, substituindo o comum 'Gostei' ou polegar para cima com gorjetas. As baixas taxas de transação da Lightning Network tornam as gorjetas praticamente sem custos. 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 capacitar cristãos a compreender o Bitcoin e usá-lo para glorificar a Deus e beneficiar a humanidade. Uma parte significativa do seu conteúdo é dedicada à promoção do protocolo Nostr através de podcasts apresentados por Jon e Jordan, explorando as implicações do protocolo numa perspetiva cristã. A combinação do cristianismo, amplamente conhecido nos EUA e globalmente, do ETF de Bitcoin aprovado pela SEC e do protocolo Nostr construído na vasta base de usuários da Lightning Network, espera-se que promova significativamente a adoção e o apoio ao protocolo Nostr.
Ativos Nostr + Taproot
O Protocolo de Ativos Nostr é um protocolo de código aberto que integra ativos Taproot e pagamentos nativos de Bitcoin (denominados em Satoshis) no ecossistema Nostr, suportando interações com outros protocolos de pagamento, incluindo a Lightning Network e ativos Taproot.
Uma vez introduzidos os ativos, podem ser enviados e recebidos utilizando as chaves públicas e privadas do protocolo Nostr, com a liquidação e segurança ainda dependentes da Lightning Network. O Protocolo de Ativos Nostr, embora construído com base na tecnologia da Nostr, é um protocolo distinto que facilita funções transacionais básicas através de mensagens da Nostr.
O serviço de custódia completa do Protocolo de Ativos Nostr envolve os utilizadores a depositarem o seu Bitcoin ou outros ativos numa carteira controlada pelo protocolo e, em seguida, a executarem instruções de implantação, cunhagem e transferência de tokens através de mensagens Nostr.
No entanto, o serviço de custódia total é controverso devido aos potenciais riscos de segurança. Os utilizadores não podem controlar totalmente os seus ativos e, no caso de uma violação da plataforma ou esquema de saída, poderiam perder todos os seus ativos.
Além disso, após o seu lançamento em 30 de outubro, a Nostr enfrentou uma grande procura de depósitos de ativos, levando a frequentes manutenções e encerramentos do site, levantando preocupações sobre a experiência da equipe e a confiabilidade do projeto. Em 8 de novembro, o Protocolo de Ativos da Nostr respondeu oficialmente a um comentário em chinês sobre 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.
Nostr + Inscription
Noscription é um protocolo de token experimental baseado em Nostr, permitindo aos usuários criar e negociar tokens semelhantes a brc-20, distintos dos tokens de ativos Taproot.
BitVM exige capacidades computacionais extremamente elevadas e atualmente apenas existe na teoria. Em termos de implementação comercial, o 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 lento no desenvolvimento). O 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 como o BitVM realizam cálculos fora da cadeia, mas o protocolo RGB garante que terceiros não consigam rastrear o histórico dos ativos RGB na blockchain. Apenas quando um utilizador recebe um ativo é que ele aprende a sua história, uma funcionalidade que 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 fugas de informação, bloqueios, perdas e adulterações maliciosas devido a vulnerabilidades.
Compatibilidade nativa com BTC
Tanto RGB como BitVM não requerem alterações no protocolo Bitcoin; Nostr é construído na Lightning Network nativa, oferecendo uma compatibilidade nativa relativamente boa e uma experiência de desenvolvimento suave.
Segurança do Protocolo
O protocolo RGB opera off-chain num ambiente de sandbox, garantindo a segurança dos dados. O seu sistema de faturação também garante a segurança dos dados do ponto de vista do design. Em termos de interação com o BTC, utiliza um mecanismo semelhante à Lightning Network para a emissão de ativos.
O BitVM usa 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.
O Nostr utiliza um modelo de retransmissão, onde o design engenhoso da transmissão de informações entre retransmissores e algoritmos de criptografia garante a segurança das informações dentro do protocolo Nostr.
Na indústria Web3, não existia um laboratório especificamente focado na segurança do ecossistema Bitcoin até à criação do BTC Security Lab, que preenche esta lacuna ao fornecer suporte de segurança profissional e pesquisa para o ecossistema Bitcoin. ScaleBit e BiHelix têm como objetivo 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, o Nostr ultrapassa tanto o BitVM quanto o 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 abrangente do que os outros dois.
O protocolo RGB existe há algum tempo, com muitos projetos aguardando atualmente o lançamento do RGB V0.11.
O 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 numerosas Dapps nos domínios do SocialFi, GameFi e DeFi, trazendo uma nova onda de popularidade ao ecossistema BTC.
Um agradecimento especial a Ausdin.eth, 0xLayman, Echo, Venus pelas suas contribuições para este relatório.
RGB é um protocolo de contrato inteligente escalável e confidencial aplicável ao Bitcoin e à Lightning Network, desenvolvido pela LNP/BP Standards Association. Ele adota os conceitos de propriedade privada e conjunta, oferecendo uma forma de computação distribuída completa de Turing, sem confiança, sem a necessidade de uma blockchain, operando como um sistema de contrato inteligente de estado parcial validado pelo cliente.
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, RGB foi proposto em 2018. Em 2019, o desenvolvedor principal Maxim Orlovsky assumiu um papel de liderança no desenvolvimento de código RGB e no design de padrões fundamentais. 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 analisadas minuciosamente em outros relatórios. Embora o V0.11 ainda não tenha sido oficialmente lançado, aqui estão alguns dos últimos desenvolvimentos dos programadores e da comunidade:
Suporte futuro para L-BTC
Atualizações sobre a interoperabilidade e as pontes entre ativos RGB e ativos Liquid
No entanto, o RGB V0.11 será incompatível com o V0.10, o que levará a custos significativos de migração para os projetos atuais. Além disso, devido ao lento progresso de desenvolvimento, muitos projetos estão atualmente à espera do lançamento do V0.11.
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 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 uso único definidos em UTXOs do Bitcoin, fornecendo a qualquer pessoa com um registro do histórico de 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 estão completamente isolados uns dos outros, e ninguém sabe da sua existência exceto os proprietários dos contratos (ou aqueles a 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. Num DAG, cada aresta pode ser vista como uma rua de sentido único numa cidade, o que representa o aspeto "direcionado" do grafo. Suponha que nesta rede de ruas, não importa como viaje, é impossível regressar ao ponto de partida e formar um ciclo fechado; isto representa a natureza "acíclica" do grafo. Num DAG, não existe uma sequência de nós que permita começar a partir de um nó, percorrer uma série de arestas e regressar ao mesmo nó.
Aplicando este 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. Esta estrutura garante que as relações entre contratos sejam claras e ordenadas, sem formar loops fechados, o que significa que um contrato não pode afetar-se diretamente ou indiretamente.
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.
Depois de entender os princípios básicos do projeto arquitetônico da RGB, vejamos 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 conta própria. A filosofia de design da RGB considera esta prática indesejável, levando a maiores vulnerabilidades de código de contrato e múltiplos ataques de hackers. Portanto, o RGB visa reduzir o risco de vulnerabilidades no desenvolvimento e a necessidade de auditorias, introduzindo o conceito de "Padrões de Esquema". "Padrões de esquema" são o código real dos contratos inteligentes. Os editores podem usá-los como "modelos de contrato" sem a necessidade de codificar ou auditar o código personalizado escrito para eles por algum contratante aleatório.
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 o seu comportamento e transições de estado, formando um Grafo Acíclico Direcionado (DAG) de mudanças de estado. A chave das operações de estado local está no Schema. As operações nos contratos RGB são locais, não globais. Cada nó (ou estado) tem as suas próprias regras e é apenas responsável pelas suas transições de estado. Isso é diferente de algoritmos globais em plataformas como 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 fornece uma boa interoperabilidade.
O esquema define quais tipos de estados globais e possuídos, selos e metadados são permitidos em transições de estado. RGB usa a linguagem Contractum para escrever Esquemas RGB e AluVM (Máquina Virtual de Unidade Lógica Aritmética), simplificando a escrita de contratos inteligentes RGB. AluVM é baseado em um projeto 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.
Do próprio design do RGB:
Privacidade sem transmissão global: Como mencionado, a validação do lado do cliente do RGB significa que o processo de validação ocorre apenas entre pares diretamente envolvidos, não em toda a rede. Esta abordagem de não transmissão global aumenta 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 mineiros não podem ver os detalhes da transação.
Privacidade de dados num ambiente de sandbox: Por outro lado, o RGB armazena todos os dados de operação num esconderijo. Uma vez que o RGB não é baseado em blockchain, o armazenamento não é replicado para outros nós pares. O armazenamento controlado localmente pelos utilizadores reduz o risco de ataques externos e fugas de dados, garantindo a privacidade dos dados. O RGB é uma plataforma de computação onde cada programa ("contrato inteligente") está isolado no seu ambiente de sandbox, oferecendo melhor escalabilidade e segurança do que as plataformas baseadas em blockchain. No entanto, os dados fora da cadeia também significam que existe um risco de perda.
Além da validação e armazenamento, o sistema de faturação também garante segurança e privacidade. As operações de contrato na 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 utilizadores 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 faturação suporta a transmissão privada de pedidos de operação de contrato entre utilizadores, melhorando a privacidade das transações. As transições de estado, como transferências de tokens, são executadas através de faturas e comandos específicos.
O design da RGB está altamente ligado aos UTXOs. Em interações com a mainnet BTC, os usuários criam contratos off-chain para emitir ativos RGB e alocá-los aos UTXOs do Bitcoin, semelhante à Lightning Network. Em seguida, as transferências de ativos, interações de contratos e validações são realizadas off-chain, como introduzido acima.
RGB beneficia dos protocolos de assinatura melhorados multisig, baseados em adaptadores e Contratos Bloqueados no Tempo (PTLCs) trazidos pelas assinaturas 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 nenhuma alteração interna), nem utiliza scripts do Bitcoin (portanto, o novo Tapscript não é útil).
O Laboratório de Segurança BTC, co-fundado pela ScaleBit, é um laboratório de segurança BTC dedicado que trabalha nos últimos desenvolvimentos do protocolo RGB. O seu objetivo é proteger a segurança dos contratos, promovendo em conjunto o crescimento contínuo e o fortalecimento do protocolo RGB e a construção da infraestrutura do ecossistema BTC.
BiHelix
Website: https://www.bihelix.net/
BiHelix é uma infraestrutura de 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 do 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ó, 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 aplicação em grande escala do Bitcoin. O projeto está atualmente em fase de desenvolvimento e ainda não está aberto para interação; fique atento.
Recursos do Projeto
Limiar de utilizador baixo : Utiliza o protocolo SLR (Security-Lightning-RGB), reembalando RGB e a Lightning Network com soluções inovadoras para os nós de relâmpago atingirem pagamento universal.
Alta Confiabilidade e Escalabilidade: Utiliza uma arquitetura madura de serviços em nuvem, aproveitando totalmente as características 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 multipartidários e seleção de caminho para proteção de privacidade.
Amigável para desenvolvedores: Fornece ferramentas de desenvolvimento abrangentes, incluindo documentação de código aberto, ferramentas, etc., e introduz o mecanismo de consenso social Schema, tornando mais fácil para os desenvolvedores construir aplicações.
Carteira Iris
Website: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1
A Carteira IRIS, a primeira carteira para Android desenvolvida pela equipa Bitfinex, é dedicada à integração RGB e ferramentas relacionadas com RGB, suportando ativos fungíveis e não-fungíveis. A Carteira Iris permite operações de ativos RGB desde a emissão até à despesa e receção, embalando todas as funcionalidades numa aplicação de carteira familiar, abstraindo o máximo possível os detalhes técnicos. Atualmente, é uma aplicação experimental recomendada para pequenas quantias de Bitcoin e ativos de baixo valor.
DIBA
Website: https://diba.io/
DIBA é o primeiro mercado NFT no Bitcoin usando o Protocolo RGB e a Lightning Network. O seu objetivo é moldar a compreensão de ativos artísticos não custodiados na blockchain do Bitcoin.
Bitmask
Website: https://bitmask.app/
Criado pela DIBA, o 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 da V0.11.
Pandora Prime Inc
Website: https://pandoraprime.ch/
Localizada no Vale Verify, Suíça, a Pandora Prime é também membro fundador da LNP/BP. A Pandora Prime dedica-se a pioneirismo em Finanças Bitcoin usando a combinação de contratos inteligentes RGB e a Lightning Network. Começam com ativos programáveis em Bitcoin (RGBTC e CHFN), que podem aumentar a capacidade de transação para os níveis da VISA/MasterCard através da Lightning Network, ao mesmo tempo que fornecem instalações para a troca fácil desses ativos. Os 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. Oferece carteiras de desktop multiplataforma e carteiras iOS/iPad. A carteira móvel pode lidar com ativos RGB fungíveis.
Explorador RGB
Website: https://rgbex.io/
Desenvolvido pela Pandora Prime, o RGB Explorer é o primeiro navegador a oferecer registo de ativos RGB e contratos inteligentes. Atualmente, suporta RGB 20, RGB 21, RGB 25, exibindo ativos como LNPBP, RGBTC, dCHF e RGBEX.
Bitlight Labs (anteriormente Cosminmart)
Website: https://bitlightlabs.com/
A Bitlight Labs desenvolve infraestruturas baseadas no protocolo RGB, preparando-se para implementar 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.
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 interagir com a Liquid).
Inscrição MRGB
Selo de Uso Único
Seal, é uma coleção de 10k PFP, UDA raro e tokens em RGB20 e RGB21, nomeados após o conceito de Selo de Uso Único de Peter Todd. Atualmente à espera das carteiras Bitlight e Bitmask para atualizarem para a versão v0.11 RGB, após o que serão emitidos nelas.
Bitman
X: @bitmancity
Irá 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á privilégios àqueles que contribuíram para o ecossistema BTC, com a maioria das receitas da venda pública doadas para LNP/BP.
BitVM (Máquina Virtual Bitcoin) introduz um sistema que permite que qualquer cálculo seja verificado na blockchain do Bitcoin sem comprometer sua segurança ou alterar a rede. Este desenvolvimento abre as portas para cálculos complexos, como contratos inteligentes completos de Turing, com todos os cálculos sendo processados fora da cadeia 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. Tal como o RGB, o 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 é muito mais jovem.
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. BitVM demonstra que o Bitcoin é Turing-completo na codificação de provas de fraude dentro de grandes Taptrees.
Design de Circuito Gate
O Compromisso de Valor de 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 passo de execução é comprometido em um Tapleaf e combinado dentro do mesmo endereço Taproot.
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 deste sistema, as condições de gasto para cada UTXO, representadas por instruções em um Script, formam a unidade básica do programa. Estas instruções geram saídas binárias (0 ou 1) dentro de um endereço Taproot, construindo assim todo o taptree. O resultado do taptree pode ser considerado 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 realiza 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 está limitado a duas partes e não pode ser expandido para incluir mais participantes. Além disso, para o BitVM funcionar 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 quantidade igual de BTC em uma transação como aposta (como entrada), e o resultado dessa transação incluirá um circuito lógico. Uma série de transações é pré-assinada durante a fase de configuração para refutar declarações incorretas. BitVM é comparado aos Rollups otimistas porque realiza a maior parte da computação fora da cadeia e submete algumas dessas computações na cadeia para resolver disputas quando surgem.
Os Rollups Otimistas são uma solução de escalonamento de segunda camada que reduz a carga na camada base ao mover a computação e o armazenamento de dados fora da cadeia. Em seguida, agrupa várias transações e publica-as na cadeia principal. Os Rollups Otimistas pressupõem que todas as transações são válidas. No entanto, se os participantes da rede notarem comportamento desonesto, podem iniciar uma prova de fraude. Uma prova de fraude é evidência de um cálculo incorreto de alguém. São produzidos após uma inspeção.
Computação fora da cadeia
Quase todas as atividades no BitVM são realizadas off-chain. 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. As computações e verificações são publicadas on-chain apenas em caso de disputa devido a suspeita de fraude. No entanto, se houver uma disputa, uma pequena parte do processo de disputa é realmente executada on-chain, apenas o suficiente para determinar qual parte é desonesta.
Com o conhecimento de fundo acima, podemos compreender 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, depois envia fundos para um endereço raiz mestre controlado em conjunto. Estes fundos são mantidos em um acordo de multisignatura 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. Este processo de interação de desafio-resposta envolve a troca de dados off-chain e o uso de transações pré-assinadas para verificar a correção da computação.
Se for descoberto um erro computacional, 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 provada como incorreta, eles perderão a aposta e os fundos. Pelo contrário, se todas as respostas estiverem corretas, o provador mantém os seus fundos. Este mecanismo de incentivo económico é projetado para prevenir comportamentos desonestos.
Em última análise, essa interação garante que a verificação computacional só é transferida para a blockchain do Bitcoin em caso de disputa, realizando assim a grande maioria das computações fora da cadeia. Este design mantém a eficiência da rede Bitcoin, proporcionando 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 baseia-se principalmente nos seguintes aspectos:
Provas de Fraude
No caso de uma disputa, os validadores podem desafiar as declarações incorretas do proponente através de provas de fraude. Este mecanismo é semelhante aos Rollups Otimistas e não requer a alteração das regras de consenso do Bitcoin.
Protocolo de Desafio-Resposta
O BitVM utiliza um protocolo de desafio-resposta, no qual 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
O BitVM permite a execução de cálculos complexos fora da cadeia, enquanto a verificação e resolução apenas ocorrem 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 Penalização
Se um proponente fizer uma declaração incorreta, os validadores podem confiscar o seu depósito. Este mecanismo garante que os atacantes sempre perdem o seu depósito por ações incorretas.
Mecanismo de Contrato Bilateral
Este mecanismo proporciona uma melhor privacidade no BitVM e reduz os custos de transação, mas, em comparação com o mecanismo multi-party do EVM, a sua universalidade é um pouco reduzida.
Qual é o Protocolo Nostr
Nostr significa "Notas e Outras Coisas Transmitidas por Relés," 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 visa 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 subscrever qualquer tipo de conteúdo sem controle ou intervenção de plataformas ou instituições centralizadas. Nostr se inspira no Bitcoin e na Lightning Network, empregando mecanismos criptográficos e de consenso similares, bem como uma estrutura de dados baseada em eventos conhecida como a Rede Nostr.
Par de Chave 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 a criptomoedas. Para simplificar, a chave pública pode ser considerada como o nome de usuário e a chave privada como a senha. É importante notar que, uma vez perdida a chave privada, esta 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 segurança dessas chaves, pois 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 lêem informações dos relés e enviam dados recém-gerados para os relés para outros clientes lerem. 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 diretamente a chave privada neles; em vez disso, é melhor usar um plugin para salvar a chave privada.
Relé
Relays podem ser entendidos como os servidores de 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 a ter velocidades lentas de cliente, pode dever-se à velocidade lenta do relay conectado, e eles podem considerar adicionar alguns outros relays.
NIPs
NIPs (Nostr Implementation Possibilities) são padrões usados para regular relés e software de 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 de outras pessoas. Como membros ativos da comunidade do protocolo, todos têm uma certa influência na direção futura do desenvolvimento da rede Nostr. Os NIPs no código-base principal foram aprovados e novas ideias podem ser adicionadas através de solicitações de extração.
As principais NIPs incluem:
NIP-04: Encriptação de mensagens, utilizando o algoritmo secp256k1 para troca de chaves Diffie-Hellman, permitindo a encriptação de ponta a ponta.
NIP-05: Mapeia chaves públicas para nomes de domínio para fácil recordaçã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 de POW blockchain e no protocolo de sussurro do Ethereum. Envolve concluir uma prova de trabalho computacionalmente intensiva antes de enviar uma mensagem, que o servidor de retransmissão receptor verifica. Fornecer esta prova significa gastar energia computacional, elevando o limiar para o envio de relés com mensagens lixo.
NIP-22: Carimbos de hora das mensagens. Informar aos servidores de retransmissão a hora em que uma mensagem foi criada, permitindo que os relés aceitem seletivamente as mensagens. Os carimbos de hora podem ser configurados para o passado ou futuro.
NIP-40: Tempo de expiração. Informar os servidores de retransmissão de quando uma mensagem expira para que possa ser deletada.
NIP-57: Links de dicas da Lightning Network.
NIP-65: Lista recomendada de serviços de retransmissão.
Eventos são os únicos Objeto
estrutura em Nostr. Cada evento tem um tipo
para indicar o tipo de evento (que ação o usuário realizou ou que informação recebeu).
O protocolo Nostr opera através de retransmissores. Estes retransmissores permitem que os utilizadores no mesmo retransmissor enviem ficheiros Json uns aos outros.
Para ajudar a entender isso, considere um diagrama simplificado:
O diagrama inclui 3 relés e 3 clientes, cada cliente utilizando uma plataforma diferente.
Neste diagrama:
Bob pode ver todos os tweets de Alice, mas nenhum dos de Mary (Bob nem sequer 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 tanto de Bob quanto de 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).
Dado o protocolo Nostr como um protocolo aberto muito leve, 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 base 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 serializado>", "pubkey": "<32 bytes chave pública em formato hexadecimal do criador do evento>", "created_at": "<carimbo de data/hora Unix em segundos>", "kind": "<inteiro>", "tags": [ ["e", "<32 bytes hexadecimal do id de outro evento>", "<URL de retransmissão recomendada>"], ["p", "<32 bytes hexadecimal da chave>", "<URL de retransmissão recomendada>"], ... // outros tipos de tags podem ser incluídos posteriormente ], "content": "<cadeia de caracteres arbitrária>", "sig": "<assinatura de 64 bytes do hash sha256 dos dados do evento serializado, 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 diferentes significados semânticos. 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 é uma aplicação que pode comunicar com o nostr-relay e pode usar subscritores para subscrever a qualquer conjunto de eventos.
Os filtros representam o conjunto de todos os eventos Nostr em que o cliente está interessado.
Os clientes não precisam de se registar ou criar contas, uma vez que o cliente utiliza a chave pública do utilizador para identificação. Cada vez que o cliente se conecta ao relay, ele submete o filtro de subscrição do utilizador e, enquanto estiver conectado, o relay transmitirá os "eventos de interesse" para o cliente.
Os relés podem armazenar em cache as subscrições 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.
Os clientes não falam uns com os outros. Mas os Relays podem. Isso permite que os relays busquem dados para o cliente que ele não tem e os clientes podem subscrever eventos fora do relay ao qual estão conectados.
À primeira vista, isso dá a impressão de que Nostr como 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 'servidor burro, cliente inteligente' pode descobrir algumas vantagens significativas na engenharia do design de protocolo descentralizado.
A Nostr serve como a camada de protocolo para aplicações sociais, transferindo Notas e outros Materiais através de Relays sem depender de quaisquer servidores centralizados. Sua completa descentralização permite que qualquer aplicação aceda livremente através de uma rede distribuída, fornecendo uma plataforma social aberta e sem permissões. Portanto, a Nostr não oferece um produto direto ao consumidor para os utilizadores, mas concentra-se em implementar a infraestrutura social necessária ao nível do protocolo. A capacidade de produto é fornecida por aplicações de terceiros, e os utilizadores de diferentes aplicações podem interagir socialmente entre si.
A vantagem do Nostr reside na sua disponibilização de uma rede social verdadeiramente livre e aberta, não afetada e não ameaçada por qualquer poder centralizado ou interesses. Os utilizadores podem expressar livremente as suas opiniões e crenças sem medo de censura, proibições ou desplataformações; os criadores de conteúdo podem definir livremente os seus modelos de incentivo sem se preocuparem em serem privados de rendimentos ou enfrentarem competição desleal. Os utilizadores do Nostr também podem escolher livremente os seus círculos sociais sem receio de manipulação, desinformação ou violação de privacidade.
Nostr difere significativamente das redes sociais tradicionais e tem as seguintes características e vantagens:
Descentralização: A Nostr não depende de servidores ou plataformas centralizadas, mas sim utiliza a rede Bitcoin para 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: A Nostr permite aos utilizadores controlar os seus próprios dados e identidade. Os utilizadores podem escolher livremente quem querem seguir e em quem confiar, e expressar as suas opiniões e ideias sem medo de serem banidos, bloqueados ou rebaixados, e sem sofrer interferências de publicidade ou de conteúdo recomendado. A verificabilidade de utilizadores específicos também torna mais fácil identificar spam e conteúdo gerado por bots.
Abertura: Nostr é um protocolo aberto em que qualquer pessoa pode participar e contribuir. Os usuários podem desenvolver e usar diferentes clientes, bem como construir e executar seus próprios nós (servidores que podem encaminhar e armazenar informações do 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 do Nostr. O sistema é simples e flexível Evento
O formato suporta vários tipos de publicação: posts em redes sociais, conteúdo longo, mídia rica, comércio eletrônico, etc. Além disso, a integração da Nostr com a Lightning Network facilitou um novo modelo de negócio mais justo, baseado no valor por valor.
Gestão de Chave Privada
O protocolo Nostr utiliza pares de chaves públicas-privadas para contas, exigindo que os utilizadores gerenciem adequadamente as suas chaves privadas. Uma vez perdida, a chave privada não pode ser recuperada. Isto pode representar um desafio para a maioria dos utilizadores, que podem não ter o conhecimento técnico e experiência necessários para gerir as chaves privadas de forma segura.
Seleção de Revezamento
No protocolo Nostr, os utilizadores devem escolher e verificar os relés por conta própria. Escolher um relé não confiável ou malicioso poderia resultar no vazamento, manipulação ou exclusão das suas informações.
Divulgação de Informações
No protocolo Nostr, a informação enviada pelos utilizadores não se propaga por vários relés. Isto significa que se a sua informação não for recebida e armazenada por um número suficiente de relés, poderá ser perdida ou não vista por outros utilizadores, agravando o problema dos silos de informação.
Armazenamento de Informações Discricionárias dos Relays
Os relés no protocolo Nostr podem decidir livremente se querem receber e armazenar as informações dos utilizadores. Isso pode levar alguns relés a optar por receber e armazenar apenas as informações que consideram valiosas ou que estão alinhadas com os seus interesses, enquanto ignoram ou rejeitam outras informações.
Extensões de Protocolo Maliciosas
Embora o protocolo Nostr defina alguns tipos básicos de eventos e funcionalidades, também permite que os clientes e relés implementem seletivamente funcionalidades adicionais. Isso poderia levar à implementação de funcionalidades inseguras ou maliciosas por parte de alguns clientes e relés, afetando a segurança e privacidade dos utilizadores.
Tratamento de Informações
Devido à falta de uma camada de consenso no protocolo Nostr, alguns relés 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 falsificar mensagens.
Visão geral do ecossistema Nostr
Jack Dorsey, co-fundador do Twitter e grande apoiante do protocolo Nostr, doou 14,17 Bitcoins (aproximadamente $245,000) para apoiar o seu desenvolvimento em dezembro de 2022. O seu perfil X exibe proeminentemente o seu endereço pessoal do Nostr, indicando a sua afinidade com o protocolo.
Damus⚡️: Principais aplicações do protocolo Nostr
X:https://twitter.com/damusapp
Damus é um aplicativo social que suporta gorjetas de Bitcoin via a Lightning Network, substituindo o comum 'Gostei' ou polegar para cima com gorjetas. As baixas taxas de transação da Lightning Network tornam as gorjetas praticamente sem custos. 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 capacitar cristãos a compreender o Bitcoin e usá-lo para glorificar a Deus e beneficiar a humanidade. Uma parte significativa do seu conteúdo é dedicada à promoção do protocolo Nostr através de podcasts apresentados por Jon e Jordan, explorando as implicações do protocolo numa perspetiva cristã. A combinação do cristianismo, amplamente conhecido nos EUA e globalmente, do ETF de Bitcoin aprovado pela SEC e do protocolo Nostr construído na vasta base de usuários da Lightning Network, espera-se que promova significativamente a adoção e o apoio ao protocolo Nostr.
Ativos Nostr + Taproot
O Protocolo de Ativos Nostr é um protocolo de código aberto que integra ativos Taproot e pagamentos nativos de Bitcoin (denominados em Satoshis) no ecossistema Nostr, suportando interações com outros protocolos de pagamento, incluindo a Lightning Network e ativos Taproot.
Uma vez introduzidos os ativos, podem ser enviados e recebidos utilizando as chaves públicas e privadas do protocolo Nostr, com a liquidação e segurança ainda dependentes da Lightning Network. O Protocolo de Ativos Nostr, embora construído com base na tecnologia da Nostr, é um protocolo distinto que facilita funções transacionais básicas através de mensagens da Nostr.
O serviço de custódia completa do Protocolo de Ativos Nostr envolve os utilizadores a depositarem o seu Bitcoin ou outros ativos numa carteira controlada pelo protocolo e, em seguida, a executarem instruções de implantação, cunhagem e transferência de tokens através de mensagens Nostr.
No entanto, o serviço de custódia total é controverso devido aos potenciais riscos de segurança. Os utilizadores não podem controlar totalmente os seus ativos e, no caso de uma violação da plataforma ou esquema de saída, poderiam perder todos os seus ativos.
Além disso, após o seu lançamento em 30 de outubro, a Nostr enfrentou uma grande procura de depósitos de ativos, levando a frequentes manutenções e encerramentos do site, levantando preocupações sobre a experiência da equipe e a confiabilidade do projeto. Em 8 de novembro, o Protocolo de Ativos da Nostr respondeu oficialmente a um comentário em chinês sobre 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.
Nostr + Inscription
Noscription é um protocolo de token experimental baseado em Nostr, permitindo aos usuários criar e negociar tokens semelhantes a brc-20, distintos dos tokens de ativos Taproot.
BitVM exige capacidades computacionais extremamente elevadas e atualmente apenas existe na teoria. Em termos de implementação comercial, o 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 lento no desenvolvimento). O 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 como o BitVM realizam cálculos fora da cadeia, mas o protocolo RGB garante que terceiros não consigam rastrear o histórico dos ativos RGB na blockchain. Apenas quando um utilizador recebe um ativo é que ele aprende a sua história, uma funcionalidade que 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 fugas de informação, bloqueios, perdas e adulterações maliciosas devido a vulnerabilidades.
Compatibilidade nativa com BTC
Tanto RGB como BitVM não requerem alterações no protocolo Bitcoin; Nostr é construído na Lightning Network nativa, oferecendo uma compatibilidade nativa relativamente boa e uma experiência de desenvolvimento suave.
Segurança do Protocolo
O protocolo RGB opera off-chain num ambiente de sandbox, garantindo a segurança dos dados. O seu sistema de faturação também garante a segurança dos dados do ponto de vista do design. Em termos de interação com o BTC, utiliza um mecanismo semelhante à Lightning Network para a emissão de ativos.
O BitVM usa 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.
O Nostr utiliza um modelo de retransmissão, onde o design engenhoso da transmissão de informações entre retransmissores e algoritmos de criptografia garante a segurança das informações dentro do protocolo Nostr.
Na indústria Web3, não existia um laboratório especificamente focado na segurança do ecossistema Bitcoin até à criação do BTC Security Lab, que preenche esta lacuna ao fornecer suporte de segurança profissional e pesquisa para o ecossistema Bitcoin. ScaleBit e BiHelix têm como objetivo 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, o Nostr ultrapassa tanto o BitVM quanto o 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 abrangente do que os outros dois.
O protocolo RGB existe há algum tempo, com muitos projetos aguardando atualmente o lançamento do RGB V0.11.
O 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 numerosas Dapps nos domínios do SocialFi, GameFi e DeFi, trazendo uma nova onda de popularidade ao ecossistema BTC.
Um agradecimento especial a Ausdin.eth, 0xLayman, Echo, Venus pelas suas contribuições para este relatório.