🚨RGB 0.12 RC1 já está disponível Nos meus 2 anos de rastreamento do protocolo RGB, este foi provavelmente o momento mais emocionante Apenas 14 horas atrás, no github RGB-WG, Maxim finalmente anunciou a versão RC1, que será a versão mais estável do RGB, e ele também sugeriu que todos os desenvolvedores RGB mudassem para a versão mais recente o mais rápido possível, e o próximo capítulo do ecossistema BTC está chegando Vamos mergulhar 👇 🧵 ———————— 🔶 Simplificação de protocolo Desta vez, a mudança está principalmente na camada de consenso, com a nova arquitetura introduzindo pela primeira vez o zk-AluVM, uma máquina virtual Turing-complete zk compacta e de alto desempenho projetada para verificação do cliente Se você não sabe muito sobre RGB, pode pensar que é o sistema de contrato inteligente mais nativo do BTC, é claro, não apenas o BTC, mas todas as cadeias públicas no modo UTXO podem usar o protocolo RGB para concluir contratos inteligentes fora da cadeia Voltando à atualização, na arquitetura, também existem algumas otimizações de refatoração do estado do contrato + verificação de consenso, que não serão mostradas em detalhes aqui De acordo com o Github, desta vez v0.12 - Redução de 4x na quantidade de código de consenso > e redução de 2x na biblioteca padrão; - > reduzir o número de tipos de dados em 30% em parâmetros genéricos na API 🔶 O estado é unificado Talvez para as pessoas comuns, a mudança mais perceptível seja a unificação do estado do contrato, que costumava ter três tipos de estados de contrato (FT/NFT/outro) e agora todos eles estão unificados, e um novo modelo de token pode ser necessário (o modelo anterior v0.11 deve ser inválido) 🔶 Melhorias de pagamento Existem alguns aprimoramentos importantes aqui, e vou escolher os principais 1. Contratos multiativos Agora é possível incluir vários tokens interoperáveis em um contrato, que podem ser chamados de forma independente ou conjunta ex: Por exemplo, posso definir 100 moedas + 500 NFTs + alguns outros anexos em um contrato (o mais básico) 2. Scripts de pagamento Por exemplo, CoinJoin/PayJoin com várias assinaturas, processamento em lote de transações, operação de canal relâmpago, etc., suportam um-para-muitos ou muitos-para-um 🔶 Otimização de desempenho A versão antiga dos dados de consignação precisa ser totalmente carregada na memória, a v0.12 é alterada para autenticação de streaming, a memória ocupa apenas algumas centenas de bytes e é adequada para carteiras móveis/hardware Não vou escrever mais, e será diferente do uso de todos