🚨RGB 0.12 RC1 já está disponível Nos meus 2 anos de acompanhamento 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 devs RGB mudem 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 do protocolo Desta vez, a mudança está principalmente na camada de consenso, com a nova arquitetura introduzindo pela primeira vez zk-AluVM, uma máquina virtual compacta e de alto desempenho Turing-complete zk projetada para verificação de clientes Se você não sabe muito sobre RGB, você pode pensar que é o sistema de contrato inteligente mais nativo do BTC, é claro, não apenas BTC, mas todas as cadeias públicas no modo UTXO podem usar o protocolo RGB para concluir contratos inteligentes off-chain De volta à atualização, na arquitetura, há também 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 percetível é a unificação do estado do contrato, que costumava ter três tipos de estados de contrato (FT / NFT / outros) e agora todos eles são unificados, e um novo modelo de token pode ser necessário (o modelo v0.11 anterior deve ser inválido) 🔶 Melhorias nos pagamentos Há algumas melhorias importantes aqui, e vou escolher as 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 lightning, etc., suportam um-para-muitos ou muitos-para-um 🔶 Otimização do desempenho A versão antiga dos dados de remessa 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